Databricksでは、エンジニアがAIエージェントを広く使用して作業を効率化しています。これらのエージェントは、さまざまな基盤モデルだけでなく、関連するアーティファクト（システムログ、使用状況テーブル、サポートチケット、Wikiなど）へのアクセスを可能にするMCPサーバーのツールにもアクセスする必要があります。以前のブログでは、規模でのAIコスト管理にはモデル選択の最適化だけでなく、エージェントのツール使用方法の最適化も必要であると共有しました。この記事では、エージェントのツール使用におけるコスト削減の機会をどのように探したか、途中で直面した課題、Unity GatewayのOTelトレーシングが分析から年間120万ドルの節約までの道のりを1時間に短縮した方法について説明します。
開発者がエージェントを構築できるようにすることは生産性の大きな向上でしたが、使用量が増えるにつれてコストも増加しました。私たちはいくつかの最適化を調査し始めましたが、その中の1つの疑念は、失敗したツール呼び出しの隠れたコストでした。具体的には、ツールが誤動作すると、呼び出し元のエージェントは大声で失敗することはほとんどありません。代わりに、リトライ、推測、そして最終的に問題を回避し、その間ずっと静かにトークンと開発者時間を消費します。この種の無駄は危険です。外部から見るとタスクはまだ完了しており、集計コストダッシュボードはトークン支出の10%の増加を示す可能性がありますが、これは使用量の増加として誤解されやすいです。
我々は、Unity GatewayのトレーシングとGenie Oneを使用して、エージェント群におけるこの疑念を調査しました。その結果、ツールサーバーに7つの小さなバグが見つかり、推定年間49.9万ドルのトークンと、エージェントの待ち時間として年間約12,000エンジニア時間を浪費していました。全体として、年間120万ドルの生産性損失に相当します。
7つのバグをすべて見つけ、定量化し、修正するのに約1時間かかりました。この記事では、私たちがたどったプロセスと、エージェント用のツールを構築することについて学んだことを説明します。
AIエージェントとMCPアクティビティの監視方法
当初、Databricksでコーディングと内部ワークフローにAIエージェントを広く展開したとき、エージェントのツール呼び出しや全体的なアクティビティの可視性が欠如していたため、コストを管理または完全に理解することは不可能でした。これを解決するために、Unity Gatewayを活用しました。これは、ツール名、引数、エラー（如果有）、トークン数、レイテンシ、および呼び出しを関連付けるセッションIDを含む、すべてのMCPツール呼び出しに対してOpenTelemetryトレースを自動的に発行します。これらのトレースは、エージェントが任意の時間ウィンドウで何をしたかを正確に記録する単一のテーブルに格納されます。新しい計装は不要で、ゲートウェイはすべての呼び出しの経路上にあるため、データはすぐに利用できました。
これにより、AIエージェントのコスト管理がより実用的になり、総トークン支出だけでなく、無駄な支出を特定のツール、エラー、エージェントセッションに帰属させることができます。
データが利用可能になったので、次のステップは探索です：どのツールエラーが最も頻繁に発生するか？エージェントがエラーに遭遇したとき、回復に何ターンかかるか？各エラーのトークンと待ち時間のコストは？通常、この種の分析で高価な部分はSQLとスキーマの探索です。しかし、Genie Oneを使用すると、トレーステーブルを指し示し、これらの正確な質問を平文で尋ねるだけで、数分で回答が得られました。私たちの1時間のほとんどは、クエリを書くのではなく、それらの回答を読むことに費やされました。
トレースが明らかにしたもの：MCPツールの障害がAIエージェントのコストを押し上げる仕組み
Genie Oneは、漠然とした疑念（"エージェントがJira呼び出しで苦労しているようだ"）を、ランク付けされた定量化されたバグリストに数分で変えました。以下は、単一の24時間ウィンドウでの例で、JiraとGoogle Drive/Docsツールサーバーのバグを示しています：
最高量のバグを例にとると、1日535回の失敗があります。Jiraのissues.searchツールはfieldsパラメータを受け取り、サーバーは次のようにしました：それは「key,summary,status」のようなカンマ区切り文字列を期待していました。しかし、配列は「フィールドのリスト」の意味的に自然なJSONタイプであり、モデルはJSON規約の背景知識と、同じセッション内の隣接するツール呼び出しからそれを推測しました。だから、合理的な呼び出し元が渡すであろう構造化された値を渡しました。リストにはsplit()がないため、サーバーは'list' object has no attribute 'split'を発生させました。これは、何が間違っていたかをエージェントに何も伝えない生のPythonトレースバックです。そこでエージェントは再び推測しました。同じリストを再試行して同じように失敗することもあれば、スキーマを再読したり、試行錯誤にフォールバックしたりしました。平均して、回復に12ターンかかり、セッションの30%がエラーを複数回経験しました。1つのsplit()呼び出しが、年間推定8.7万ドルのトークンと4,850時間のエージェント待ち時間を費やしていました。
Google Driveの「Invalid field selection」エラーは、量においてさらに顕著でした。エラーの49.6%が発生しました。記事はここで截断されています。
これらの発見は、ツール設計の重要性を強調しています。モデルはあいまいな入力に対して推測を行うため、ツールは予期しない入力でクラッシュするのではなく、変化を優雅に処理する必要があります。エージェントがツールを実際にどのように使用するかを観察することで、より堅牢なツールを設計し、エラーと無駄を減らすことができます。Databricksのエンジニアは、Unity GatewayとGenie Oneを介してエージェントツールの使用におけるかなりの節約を発見し、このプロセスを組織全体に広めて継続的なコスト最適化を実現しています。