Databricks、AI エージェントの年間浪費コスト 100 万ドルを 1 時間で削減する手法を公開

Databricks のエンジニアたちは、業務の効率化と加速のために AI エージェントを積極的に活用しています。これらのエージェントは、さまざまな基盤モデルへのアクセスだけでなく、システムログや利用状況テーブル、サポートチケット、ウィキなどの関連アーティファクトにアクセスするためのツールを提供する MCP サーバーにも接続する必要があります。

以前の記事で、大規模な AI コスト管理にはモデル選択の最適化に加え、エージェントがツールをどのように使用するかについても最適化が必要だとお伝えしました。今回の記事では、エージェントによるツールの利用におけるコスト削減の取り組みと、その過程で直面した課題、そして Unity Gateway での OpenTelemetry（OTel）トレーシングが分析から年間 120 万ドルの節約に至るまでの道のりをわずか 1 時間に短縮させた方法について解説します。

開発者がエージェントを構築できるようにしたのは生産性の飛躍的な向上につながりましたが、利用が増えるにつれてコストも上昇しました。そこでいくつかの最適化策を検討する中で、「失敗したツール呼び出しによる隠れたコスト」に注目しました。具体的には、ツールが誤動作した場合、それを呼び出したエージェントは即座にエラーを報告して停止することは稀です。代わりに、再試行や推測を行い、最終的には問題をごまかしながら処理を進めます。その間、トークンと開発者の時間が静かに浪費され続けます。

この種の無駄は非常に危険です。外側からはタスクが完了したように見え、集計されたコストダッシュボードではトークン使用量が 10% 程度増加しているだけと表示されるため、単なる利用量の増加と誤解されやすいのです。

Unity Gateway の tracing と Genie One を活用し、エージェント fleet におけるこの疑念を検証しました。その結果、ツールサーバーに 7 つの小さなバグが見つかり、これらが年間約 49.9 ドル万トークンの無駄と、12,000 時間に及ぶエンジニアのエージェント待ち時間を生んでいることが判明しました。全体として、これは年間推定 120 ドル万 の生産性損失に相当します。

これら 7 つのバグをすべて特定し、その影響を定量化して修正するまでにかかったのは約 1 時間でした。本稿では、私たちが実施したプロセスと、エージェント向けツール構築において得た教訓について解説します。

AI エージェントと MCP のアクティビティを監視する方法

Databricks でコーディングや社内ワークフローのために AI エージェントを広く展開し始めた当初、エージェントのツール呼び出しや全体的な活動状況が見えないため、コストを管理することも、完全に把握することも不可能でした。この課題を解決するため、私たちは Unity Gateway を活用しました。Unity Gateway は、MCP ツールの呼び出しごとに自動的に OpenTelemetry トレースを生成します。これには、ツールの名前、引数、エラー（発生した場合）、トークン使用量、レイテンシ、そして呼び出しを紐付けるためのセッション ID が含まれています。これらのトレースは単一のテーブルに格納され、任意の時間枠におけるエージェントの行動を正確に記録します。新しい計測機能の実装は不要でした。ゲートウェイはすでにすべての呼び出しパス上に存在しているため、データはすぐに利用可能でした。

これにより、AI エージェントのコスト管理がより具体的で実行可能なものになります。単にトークンの総使用量を見るだけでなく、無駄遣いがどのツールやエラー、エージェントセッションに起因するのかを特定できるようになるのです。

データが揃った今、次は分析と探索です。

• 最も頻繁に発生するツールのエラーは何ですか？
• エージェントがそのエラーに遭遇した際、回復までに何ターンかかるのでしょうか？
• 各エラーがトークン数と実際の待機時間にどの程度のコストを課しているのでしょうか？

通常、こうした分析で最も時間がかかるのは SQL の記述やスキーマの調査です。しかし Genie One を使えば、トレーステーブルを指差すだけでこれらの質問を自然な英語で投げかけ、数分で回答が得られます。私たちが 1 時間で費やしたのは、クエリを書くことではなく、その回答を読み解くことにほとんどでした。

トレースから明らかになった事実：MCP ツール障害がいかに AI エージェントのコストを押し上げるか

Genie One は、「エージェントが Jira の呼び出しで無駄なループに陥っているようだ」といった漠然とした疑念を、数分でランク付けされ定量化されたバグリストへと変換しました。以下は、24 時間の単一ウィンドウにおける例で、Jira および Google ドライブ/ドキュメントツールのサーバーで見つかったバグを示しています：

例えば、1 日に 535 件発生する最も頻度の高いバグを挙げましょう。Jira の issues.search ツールには fields パラメータが存在しますが、サーバー側は以下のような処理を行っていました。

このパラメータは「key,summary,status」のようなカンマ区切りの文字列を想定していました。しかし、「フィールドのリスト」という意味において JSON 型として自然なのは配列であり、モデルは JSON の慣習に関する背景知識や、同じセッション内での隣接するツール呼び出しから、このように推論しました。そのため、妥当な呼び出し元が送るはずの構造化された値を渡してしまったのです。

リストには .split() メソッドが存在しないため、サーバーは「'list' object has no attribute 'split'」というエラーを返しました。これは生々しい Python のトレースバックであり、エージェントに対して自分がどこを間違えたのかを一切示していません。そこでエージェントは再度推測を試みました。同じリストを再試行して失敗するケースもあれば、スキーマを読み直したり、試行錯誤に頼ったりする場合もありました。平均すると回復までに 12 回 のやり取りが必要で、セッションの 30% はこのエラーに一度以上遭遇しました。たった一つの .split() 呼び出しの不備が、年間約 87,000 ドルのトークンコストと、4,850 時間に及ぶエージェントの待機時間を生んでいました。

Google Drive の「無効なフィールド選択」エラーは、その発生規模においてさらに目立つものでした。drive_file_get 呼び出しの実に 49.6% が失敗していたのです。これは、モデルがドライブ API の有効そうなフィールド名（id, name, mimeType など）を渡し続けていたためで、しかしツールのエンドポイント側はそれらの名前を受け付けていなかったからです。

真の教訓：AI エージェントと LLM 向けの MCP ツール設計とは

明白な結論は「エラーメッセージをもっと良く書くこと」です。データもこれを裏付けています。回復コストは、エラーメッセージの質とほぼ完璧に比例しています。

「エラーメッセージを改善すればいい」というのはもはや古びた話です。より興味深い問いは、なぜモデルがこれらのツールを最初から「誤り」と判断したのかという点です。実際には、多くのケースでモデルは正しく呼び出していました。

MCP ツールのシグネチャは、意図的に不完全に記述されていることがよくあります。これはあえて緩やかに保っているのです：一般性を高めるため、そして何より、各パラメータの説明がトークンコストを消費するためです。モデルは呼び出しごとにそのコストを負担しているからです。その結果、シグネチャの記述が曖昧な場合、モデルは合理的な推測で穴を埋めます。リストに対して JSON 配列を返すのは、まさに合理的な推論の一つです。

バグの原因は、モデルがツールを誤って呼び出したことではありませんでした。むしろ問題だったのは、サーバーが複数の合理的な解釈のうち一つしか受け付けず、他を受け付けた瞬間にクラッシュしてしまった点にあります。

したがって、設計原則は直感的な発想とは逆になります。エージェント向けのツールは、LLM が自然に呼び出す方法に合わせて適応すべきです。具体的には、リストを文字列に変換する、省略されたパラメータにデフォルト値を設定する、予期しない引数を受け入れるなどです。不完全なシグネチャは「柔軟性」への約束であり、ツールはその約束を呼び出し側で守るべきです。作者が想定した特定の形式と一致しなかったという理由だけで、最初の入力に対してクラッシュしてはいけません。

簡単な部分：1 時間で無駄な AI エージェント支出を削減した方法

実際の修正作業自体は単純で、この話の面白い核心ではありません。Genie One が「どのエラーから優先的に直すか」や「モデルが実際に何を出力していたか」という順位付けされたリストを提供してくれた後、ツールサーバー全体への適用はコーディングエージェントを使って一瞬で完了しました。発見・定量化・修正という一連のループには、約 1 時間しかかかりませんでした。

最も稀缺でコストのかかるステップは、修正コードを書くことではありませんでした。重要なのは「何を直すべきか」を知ることです。トレーシングと Genie One を組み合わせることで、このステップは研究プロジェクトから、誰でも口頭で質問できるような日常的なタスクへと変わりました。

ループを完結させる：AI エージェントのコストを継続的に監視・削減する方法

より多くの実務がエージェントに移行するにつれ、静かに発生するツールの失敗は、主要なコストセンターとして浮上します。これは「利用量の増加」という名目の奥に隠れており、誰もアラートを受け取らない厄介なものです。

こうした問題を検出するためのループは安価で反復可能です。Unity Gateway がエージェントの挙動を可視化し、Genie One が SQL を使わずにその挙動を検索可能にします。

これらを組み合わせることで、チームは AI エージェントを監視し、MCP ツールの失敗を診断し、無駄な AI 支出を削減するための反復可能な手法を手に入れます。もしあなたが自社のツールでエージェントを実行しているなら、同じことを実践してください。呼び出しをトレーシングし、Genie One に何が繰り返し失敗しているかを問いかけてみてください。

Genie One を用いた Unity Gateway のトレース分析の始め方

Unity Gateway は一般提供（GA）となりました。これにより、ベータ版として公開された統合トレーステーブルを通じて、すべての AI 活動を監視できるようになりました。

こちら のドキュメントで、始め方をご確認ください。