エージェント型アプリケーションの費用管理はモデル選択以上の課題である

アプリケーションが実行する LLM の呼び出しにはすべてコストがかかります。特にエージェント型アプリケーションでは、LLM への呼び出し回数が膨大になります。

ユーザーの単一のリクエストは、計画立案、ツール選択、情報取得、合成といった複数のステップに展開され、それぞれがモデルの呼び出しとなります。これらすべてのコストは、月末の請求書で一つのまとまった項目として表示されます。

プロトタイプ段階ではこの点は問題になりませんが、実際のトラフィックが発生すると、インフラコストの中で大きな割合を占めるようになります。そして、通常の計算リソースにはない厄介な性質を持っています。つまり、エージェントのコストは利用量に対して非線形に増加するのです。

会話の履歴（コンテキスト）がターンごとに蓄積されるため、大量のデータを返すツールを使用すると、そのコストは一度きりではありません。同じトレス（追跡）内の後続のすべてのステップでコストが発生します。なぜなら、そのデータはモデルへ再送信される会話の一部となるからです。

つまり、トラフィックが倍になっても、インタラクションのパターンが変われば推論コストはそれ以上に跳ね上がります。このため、コスト管理は可観測性（オプサーバビリティ）の重要な要素であり、スケーリングにおけるコスト制御も極めて重要になります。単に「何が高額か」を把握するだけでなく、「どうすればコストを下げられるか」まで示せる可観測性が求められます。

コスト最適化が機能開発に優先順位で劣ることが多い

本番環境のエージェントコスト最適化においてよくある問題は、それが誰かの明確な担当業務ではなく、かつ時間がかかり退屈な作業であるため、誰も手を上げないという点です。

この作業に高度な技術は不要です。テレメトリデータを読み込み、スパンを支出額でランク付けし、コストと品質スコアを相関させて「支出に見合わないステップ」を見つけ出します。最後に、高コストのスパンを特定した関数までトレースし、範囲を限定した小さな修正（diff）を提案するだけです。

これはエージェントが得意とする問題の形です。必要な証拠はすべて容易にアクセスできる構造化データとして利用可能で、分析は機械的であり、意思決定も根拠に基づいて行われます。高コストなエージェントに対する自然な答えは、その支出を管理する役割を持つ別のエージェントです。

さらに良いことに、このプロセスはループ構造になっているため、継続的かつ自律的に実行できます。診断は機械的な工程で、修正内容は比較的小さく迅速にレビュー可能です。具体的には、ペイロードの削減、プロンプトの短縮、キャッシュの追加、冗長な呼び出しの統合、過剰なリソース割り当てのモデルのダウングレードなどが挙げられます。重要なのは、検証が極めて容易である点です。一度変更を適用すれば、同じ証拠データによってコストが本当に下がったかどうかを即座に確認できます。

地道ではあるものの解決は機械的であり、検証も安価です。まさにエージェントが活躍する理想的な領域と言えます。

エージェントに任せる

Arize AX では、コスト制御機能をプラットフォーム内で直接動作する管理型エージェントとして提供しています。新しいエージェント選択画面では、Signal やデバッグ用エージェントと並んで表示されます。

image「コストエージェント」は、シグナルやデバッグ用エージェントと共に「新しいエージェントの選択画面」に並んで配置されます。

コストエージェントの設定は、実は非常にシンプルです。実行する統合先を選び、読み取りを許可するトレーシングプロジェクト（ここでは LangGraph で構築されたマルチエージェント型金融アシスタント「live-fin-langgraph」）を選択します。このプロジェクトでは、スーパーバイザーが金融データの取得や Web 調査を行うエージェントとの間で質問を振り分け、最終的な要約を作成しています。また、実行頻度として「1 回限り」か「スケジュール実行」かの選択も可能です。

imageコストエージェントの設定画面：統合先の選択、読み取り可能なトレーシングプロジェクトの指定、および実行頻度の設定を行います。

ただし、ここで注意すべき重要な選択肢が 2 つあります。1 つ目は「リポジトリ接続」です。GitHub のスキルを紐付けることで、エージェントはテレメトリーデータだけでなく、実装コードそのものも読み取れるようになります。これにより、単に問題の診断を行うだけでなく、問題解決に向けたプルリクエスト（PR）を直接作成することも可能になります。

2 つ目は「自動化モード」です。一度きりのセッションで試すこともできますし、スケジュールに従って自動的に実行させることで、最小限の手動介入でループが完結する運用も実現できます。

起動前にはタスクのプロンプトが表示され、これを編集することも可能です。これは、明らかな制約や過去に試された戦略など、追加のドメインコンテキストを付与するための優れた方法です。

image 本番環境への展開前には、タスクプロンプトを確認・編集できるため、すでに試した制約や戦略を追加することが可能です。

実世界での結果

エージェントはサンドボックス内で実行され、動作中のライブトランスクリプトを監視したり、必要に応じて中断したりできます。今回の例では、実行に要したのは 16 分と 62 ステップでした。

image 16 分の実行結果：LLM スパンが 500、すべて gpt-4o-mini を使用し、研究エージェントノードでのトークン使用量に最大 20 倍のばらつきがありました。

最初に報告されたのは、「最も明白な問いに対しては特に報告すべき点がない」という事実でした。

30 日間のベースライン：LLM スパン 500、100% gpt-4o-mini。まず良いニュースから、最先端モデルの誤用はありません。モデル選択はすでに最適化されています。

コスト最適化において最も obvious な施策は、より安価なモデルへの切り替えですが、今回のツールはこの単純な戦略を既に超え、より深い分析を開始しています。支出をノード別に内訳すると、財務データと Web 調査を担当するエージェントノードが全体の 72% を占め、スーパーバイザーが 15%、サマライザーが 12% でした。そこでツールは、各エージェントの具体的な動作内容に注目し始めました。

エージェントノードのトークン使用量は、エージェント自身が選んだ言葉を使えば「過酷」なものでした。中央値（p50）は 616 トークン、上位 95 パーセンタイル（p95）が 10,240 トークン、最大値は 11,983 トークンです。中央値と尾部の間に 20 倍の開きがありました。

この異常な使用量の尾端をたどると、原因は単一の関数 read_webpage（tools.py に定義）にあることが分かりました。この関数は呼び出しごとに最大 50,000 文字（約 12,500 トークン）を返す仕様でした。また、問題のメカニズムも特定できました。取得したウェブページの内容が LangGraph の共有状態 AgentState.messages に格納され、同じトレース内の後続ステップで毎回モデルに再送信されているのです。一度に大きなページを取得すると、その後の 3〜4 つの LLM 呼び出しが膨れ上がります。サンプル内にはそのような呼び出しが 71 回含まれていました。

さらに 3 つの発見がありました。第一に、631,654 トークンのプロンプト全体でキャッシュヒットはゼロでした。スーパーバイザーが使用するシステムプロンプトは実は 2 種類だけで、合計 184 回呼び出されていますが、平均トークン数が 688 と OpenAI の自動キャッシュ閾値である 1,024 トークンを下回っているため、その繰り返しも一切キャッシュされませんでした。サマライズノードではメッセージの役割（role）を誤って設定しており、生 API ペイロードを含む会話履歴全体を再読み込みしていました。さらに、2 つの金融ツールは直近の期間のみが必要なのに、複数年にわたる時系列データを返していました。

これらはコンテキスト管理に関する課題ですが、エージェント自体が十分に賢く、これらの問題を直接解決する能力を持っています。

直接的な修正

リポジトリが接続されていたため、調査の結果はプルリクエストとして提出されました。

image調査の結果、プルリクエストには 6 つの変更が含まれることになりました。これらを適用することで、月間の請求額を約 35〜40% 削減できます。

各変更がもたらす推定節約効果は以下の通りです。まず、ウェブページ読み込み機能の出力を 5 万文字から 6 千文字に制限しました。次に、要約ツールの役割とメッセージフィルタリングを見直しました。さらに、set_llm_cache() を経由して InMemoryCache を実装し、2 つの金融ツールの呼び出し上限を limit=2 に設定しました。また、スーパーバイザーへのコンテキスト入力も最後の 4 メッセージに絞り込みました。最後に、スーパーバイザー用の LLM を独立したインスタンスとして分離しました。これにより、将来的にはロールごとのモデルルーティングが可能になります。

特に興味深いのは、この最後の改修です。これは直接的なコスト削減を目的としたものではなく、将来の最適化を実現するためのリファクタリングです。ファイルにアクセスしている最中に、入念なエンジニアなら当然行うような作業であり、単なるコストパターンのマッチングから生じる発想とは一線を画しています。

その後、エージェントはマージ後の監視事項を提示してプロセスを完結させます。具体的には、エージェントノードの p95（遅延時間の 95 パーセンタイル）が現在の約 10,240 トークンから 2,500〜3,000 トークンに低下する見込みです。また、次の改善ポイントも特定しました。スーパーバイザーのシステムプロンプトをさらに約 340 トークン増やすと、自動キャッシュの閾値を超え、月間のルーティング呼び出し 184 回すべてでキャッシュヒットが期待できるようになります。

エージェントに求められる成果とは、メカニズムを説明した上で優先順位をつけた発見リスト、差分（diff）、その後のテレメトリがどうなるべきかという検証可能な予測、そして次のアクションへの誘導です。

最終的なリリース責任は人間にあります

この仕組みにおいて、エージェントが独断で本番環境へデプロイすることはありません。コスト管理エージェントは提案を行うのみで、プルリクエストもまた提案の形をとります。エンジニアがその差分を読み込み、判断を下します。中には却下されるケースもあります。例えば「read_webpage」の出力を 6,000 文字に制限するといった判断は、調査用エージェントがページからどの程度の情報を必要とするかという製品上の判断であり、コスト削減だけが目的ではありません。

これはまさにエージェントが果たすべき役割です。500 のスパンを読み込み、重要な 71 件の呼び出しを特定し、「ツールペイロードが静かに 4 回再送信されていたことが真の原因だった」という結論に至る作業を行います。製品変更に関する最終的な判断は、あくまで人間の裁量に委ねられます。

導入のステップ

コスト追跡機能は本日、AX で一般提供を開始しました。この機能では、すべての LLM コールをスパンレベルとトレースレベルで課金計算し、一般的なモデルにはデフォルト設定を用意しています。また、カスタム料率やキャッシュトークン、推論用トークン、ティア別価格設定にも対応しています。機能を有効化し、登録されたモデルがデフォルト値と一致しているか確認するだけで、このループ全体を支える基盤が整います。

コスト管理エージェントを含むマネージドエージェントは、現在エンタープライズ版のベータプログラムとして提供されています。エンジニアが四半期ごとに監査を行う代わりに、毎週エージェントにトレースを監査させたい場合は、Arize のアカウントチームまでお問い合わせください。

エージェントのコスト管理は、モデルそのものだけに関わる話ではない。

この投稿は、Arize AI で最初に公開されました。