わずか1時間で、年間100万ドルの無駄なAIエージェント費用を削減した方法

Databricksのエンジニアは、業務の効率化と迅速化のためにAIエージェントを大いに活用しています。そして、これらのエージェントは、さまざまな基盤モデルだけでなく、関連するアーティファクト（システムログ、利用状況テーブル、サポートチケット、Wikiなど）へのアクセスを可能にするツールを備えたMCPサーバーへのアクセスも必要とします。以前のブログでは、大規模なAIコストの管理には、モデルの選択だけでなく、エージェントによるツールの使用方法も最適化する必要があることを共有しました。この記事では、エージェントのツール使用におけるコスト削減の探索方法、その過程で直面した課題、そしてUnity GatewayでのOTelトレースによって、分析から年間120万ドルの削減を達成するまでの道のりがどのようにわずか1時間に短縮されたかについて説明します。

開発者が独自のエージェントを構築できるようにしたことは、生産性を飛躍的に向上させましたが、使用量が増加するにつれてコストも上昇しました。私たちはいくつかの最適化の調査を開始しましたが、その中で、失敗したツール呼び出しによる隠れたコストがあるのではないかという疑念を抱きました。具体的には、ツールが正常に動作しない場合、呼び出し元のエージェントが明確なエラーを出すことは滅多にありません。代わりに、リトライや推測を繰り返し、最終的には問題を回避しようとするため、その過程でトークンと開発者の時間が静かに消費されてしまいます。このような無駄は危険です。外部からはタスクが完了しているように見え、全体のコストダッシュボードにはトークン消費量が10%増加したと表示されるだけで、単に使用量が増えたと誤解されやすいためです。

私たちは、Unity Gatewayのトレース機能とGenie Oneを使用して、エージェント群におけるこの疑念を調査しました。その結果、ツールサーバーに7つの小さなバグが見つかりました。これらにより、推定で年間49万9,000ドルのトークンが無駄になり、エージェントの待ち時間として年間約12,000の開発者時間が失われていました。全体として、これは生産性の損失として推定年間120万ドルに相当します。

これら7つのバグをすべて特定し、定量化し、修正するのにかかった時間はわずか1時間ほどでした。この記事では、私たちが実行したプロセスと、そこから得られたエージェント向けツール構築に関する教訓について説明します。

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

Databricksでコーディングや社内ワークフロー向けにAIエージェントを広く導入し始めた当初は、エージェントのツール呼び出しや全体的なアクティビティを可視化できなかったため、コストの管理や完全な把握すら不可能な状態でした。これを解決するために、私たちはUnity Gatewayを活用しました。これにより、ツール名、引数、エラー（存在する場合）、トークン数、レイテンシ、および呼び出しを紐付けるセッションIDを含む、すべてのMCPツール呼び出しに対するOpenTelemetryトレースが自動的に出力されます。これらのトレースは、任意の時間枠でエージェントが実行した内容を正確に記録する単一のテーブルに保存されます。新たなインストルメンテーションは不要であり、ゲートウェイはすでにすべての呼び出しの経路上に存在するため、データはすぐに利用可能な状態でした。

これにより、AIエージェントのコスト管理がより実践的になります。単にトークンの総消費量を見るだけでなく、無駄な消費の原因を特定のツール、エラー、エージェントセッションに帰属させることができるようになります。

データが利用可能になった今、次のステップは探索です：

• どのツールのエラーが最も頻繁に再発しているか？
• エージェントがエラーに遭遇した際、回復までに何ターンかかるか？
• 各エラーは、トークンと実時間の待ち時間の面でどれだけのコストがかかっているか？

通常、この種の分析で最も手間がかかるのは、SQLの作成やスキーマの探索です。しかし、Genie Oneを使用すれば、トレーステーブルを指定して、これらの質問を自然な英語でそのまま尋ねるだけで、数分で回答を得ることができました。費やした1時間の大部分は、クエリの作成ではなく、それらの回答を読み解くことに使われました。

トレースが明らかにしたこと：MCPツールの失敗がAIエージェントのコストを押し上げる仕組み

Genie Oneは、「エージェントがJiraの呼び出しで無駄な動きをしているようだ」という漠然とした疑念を、わずか数分でランク付けされ定量化されたバグリストへと変換しました。以下は、JiraおよびGoogle Drive/Docsのツールサーバーにおけるバグを示す、ある24時間のデータ例です：

最も発生件数の多いバグ（1日あたり535回の失敗）を例に挙げてみましょう。Jiraの issues.search ツールは fields パラメータを受け取りますが、サーバーは以下のように処理していました：

サーバーは "key,summary,status" のようなカンマ区切りの文字列を想定していました。しかし、「フィールドのリスト」を表すセマンティクスとして自然なJSONの型は配列（array）であり、モデルはJSONの規約に関する背景知識や、同じセッション内の隣接するツール呼び出しからそのように推論しました。そのため、モデルは一般的な呼び出し元が送るであろう、以下のような構造化された値を渡しました：

リストには .split() が存在しないため、サーバーは 'list' object has no attribute 'split' という生のPythonトレースバックを返しました。これは、エージェントに対して何が間違っていたのかを一切伝えません。そのため、エージェントは再び推測を試みました。同じリストを再試行して同様に失敗することもあれば、スキーマを読み直したり、試行錯誤を繰り返したりすることもありました。平均して、回復までに12ターンを要し、セッションの30%でこのエラーが複数回発生していました。わずか1つの .split() 呼び出しが、推定で年間8万7,000ドルのトークンコストと、4,850時間のエージェントの待ち時間を引き起こしていたのです。

Google Driveの Invalid field selection エラーは、発生件数の面でさらに顕著でした。すべての drive_file_get 呼び出しの49.6%が失敗していたのです。これは、モデルがツールのエンドポイントで受け付けられない、一見正しそうなDrive APIのフィールド名（id、name、mimeType）を渡し続けたためです。

本当の教訓：AIエージェントとLLMのためのMCPツールの設計方法

明らかな教訓は「より適切なエラーメッセージを作成する」ということであり、データもそれを裏付けています。回復コストは、エラーメッセージの品質とほぼ完全に相関しています：

しかし、「優れたエラーメッセージが役立つ」というのは、今に始まったことではありません。より興味深い問いは、そもそも*なぜ*モデルがこれらのツールを「誤って」呼び出したのかということです。ほとんどの場合、実際にはそうではありませんでした。

MCPツールのシグネチャは、意図的に大まかに定義されていることがよくあります。これらを意図的に緩くしているのは、汎用性を持たせるためでもあり、コンテキストトークンを節約するためでもあります。パラメータの説明が増えるたびに、モデルが呼び出しごとに支払うトークンコストが発生するためです。その結果、シグネチャのフィールド定義が曖昧な場合、モデルは妥当な推測でその隙間を埋めることになります。そして、フィールドのリストに対してJSON配列は妥当な推測です。バグは、モデルがツールを誤って呼び出したことではありませんでした。サーバーが複数の妥当な解釈のうち1つしか受け入れず、それ以外でクラッシュしたことが原因でした。

したがって、設計原則は反射的なものとは逆になります。 エージェント向けのツールは、LLMが自然に呼び出す方法に適応すべきである（例：リストを強制的に文字列に変換する、省略されたパラメータにデフォルト値を設定する、予期しない引数を吸収するなど）。緩く定義されたシグネチャは柔軟性の約束であり、ツールは、作成者が想定した単一の形式に一致しない最初の入力でクラッシュするのではなく、受信側でその約束を果たすべきです。

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

修正自体は単純であり、この話の面白い部分ではありません。Genie Oneが、修正すべきエラーとモデルが実際に送信していた内容のランク付けされたリストを提示してくれた後は、コーディングエージェントを使ってツールサーバー全体に修正を適用するだけの簡単な作業でした。ループ全体（発見、定量化、修正）にかかった時間は約1時間でした。

手間がかかり、コストが高かったステップは、修正コードを書くことではありませんでした。何を修正すべきかを知ることでした。トレースとGenie Oneの組み合わせにより、そのステップは調査プロジェクトから、声に出して質問できるシンプルな問いへと変わりました。

ループを閉じる：AIエージェントのコストを継続的に監視し、削減する方法

より多くの実務がエージェントに移行するにつれ、ツールのサイレントエラーは主要なコスト要因（コストセンター）となります。これは「利用量の増加」の影に隠れ、誰にもアラートを送らない性質のものです。これらを捉えるループは低コストで再現可能です。Unity Gatewayがエージェントの動作を観測可能にし、Genie Oneがその動作をSQLなしでクエリ可能にします。

これらにより、チームはAIエージェントを監視し、MCPツールのエラーを診断し、無駄なAI支出を削減するための再現可能な方法を手に入れることができます。自社のツールに対してエージェントを実行している場合は、同様のことを行ってみてください。呼び出しをトレースし、何がうまくいっていないのかをGenie Oneに尋ねてみましょう。

Genie Oneを使用したUnity Gatewayトレース分析を開始する

Unity Gatewayは一般提供（GA）されており、現在はベータ版である統合トレーステーブルを使用して、すべてのAIアクティビティを監視できるようになりました。開始方法については、 ドキュメントをご覧ください。 

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事