チャウラ氏は、AI活用を巡る現在の状況について、「トークンを大量に使って試行錯誤すること自体が重視されている段階」だと述べる。同氏によると、その背景には、AIエージェント特有のコスト構造がある。

　SaaSではユーザー数や利用プラン、クラウドでは従量課金やオートスケーリングなど、利用量を管理するための仕組みが発達してきた。一方、AIエージェントでは、コードからモデルを何度も呼び出したり、処理を繰り返したりすることでコストが発生する。こうした動きを制御する仕組みは十分に整っていないという。

　この状態についてチャウラ氏は、「エージェント時代には、まだ適切な『コントロールプレーン』がありません」と指摘する。続けて、「モデルゲートウェイには、利用量に上限を設けたり、より安価なモデルに切り替えたりする仕組みがあります。しかし、今回焦点を当てるのは、コードがモデルを呼び出す部分です」と強調する。

「どのエージェントが使ったのか」が分からなければ制御できない

　コスト管理の第一歩としてチャウラ氏が挙げるのが、「attribution」（帰属）の把握だ。

　AI利用のコストはモデルを呼び出す際に発生する。しかし、請求総額だけを把握しても、その原因となった処理を特定できなければ改善につなげにくい。

　「どのエージェントの、どの実行がそのモデル呼び出しを行ったのか分からなければ、コストを制御できません」（チャウラ氏）

　例えば、あるエージェントが必要以上にループを繰り返している場合や、処理を続けるうちにコンテキストが過度に大きくなっている場合がある。

　チャウラ氏は、不要なループやコンテキストの肥大化など、コスト増の原因となっている処理をその場で抑えるポリシーが必要だと指摘する。「予算上限による停止は、最後の手段としてのみ実行すべきです」（同氏）

AIエージェントのコストは「リクエスト」ではなく「実行」で見る

　既存のトークン管理では、モデルへのリクエスト単位で利用量を監視する仕組みが多い。

　しかしチャウラ氏とコウル氏は、それだけではAIエージェント特有のコスト増を捉え切れないと考えているという。

　例えば、1つのエージェントがツールを何度も呼び出したり、複数のサブエージェントを生成したり、コンテキストを膨らませ続けたりするケースがある。既存のコスト管理は大規模言語モデル（LLM）への1回ごとのリクエストを監視する仕組みが中心だが、AIエージェントは1つの仕事を完了するまでにモデルやツールを繰り返し呼び出す。

　チャウラ氏らは、個々のモデル呼び出しだけを見るのではなく、一連の処理全体を「agent run」として捉え、その単位でコストを追跡、制御する必要があると説明した。

　そこで両氏が紹介するのが「TokenOps」という仕組みだ。AIエージェントの実行状況を観測し、コストを記録した上で、設定したポリシーに応じて実行中の処理へ介入する。

予算超過なら「即停止」ではなく、まず動作を変える

　TokenOpsの特徴としてコウル氏が強調したのが、「halt」と「steer」という2種類の制御だ。

• halt
  • 設定した予算を超えたエージェントを停止する一般的な方法
• steer
  • エージェントを停止させるのではなく、予算内に収まるように実行方法そのものを変更する

　コウル氏によると、steerは、予算超過時にエージェントを停止するのではなく、検索件数や出力量などを実行途中で調整し、トークン消費を抑えながら処理完了を目指す仕組みだ。

　例えば、RAG（検索拡張生成）の検索処理が毎回20件のチャンクを取得しているものの、実際には上位5件しかLLMが利用していないケースを考える。

　この場合、取得するチャンク数を5件に減らせば、エージェントを停止することなくトークン消費を削減できる。

　コウル氏によると、制御側から「取得件数を減らす」といった指示をエージェント側へ送り、開発者があらかじめ許可した範囲内で実行時の動作を変更する仕組みにしているという。

「このままでは予算を使い切る」と予測して指示を変える

　チャウラ氏とコウル氏は、steerのもう1つの例として、予算を使い切る前にエージェントの動きを調整する仕組みを紹介する。

　TokenOpsは、これまでに使った予算だけでなく、トークンを消費する速さも監視する。現在のペースのままでは、処理を終える前に予算を使い切ると判断すると、エージェントへの指示を変更する。

　例えば、LLMに対して「予算が残り少ないため、回答をより簡潔にする」といった指示を追加し、以降の出力量を抑える。

　コウル氏によると、既に消費した予算とトークンの消費速度を基に予算切れを予測し、「LLMの出力をより簡潔にしたり、要約したりするよう指示できる」という。

　予算を超えた時点でエージェントを強制終了するのではなく、予算を超えそうな段階で処理を軽量化し、できるだけ仕事を最後まで完了させるのがsteerの考え方だ。

平均支出を78％削減、完了率は67％から約96％に

　TokenOpsの効果を確かめるため、チャウラ氏らはオープンソースのAIエージェント環境を使ってベンチマークを実施した。複数のシナリオやストレステストで検証した結果、TokenOpsの一連のポリシーを有効にすると、平均支出を約78％削減できたという。

　さらに、予算を超えたエージェントを単純に停止する「スロットリング方式」と比べると、処理を最後まで完了できる割合にも違いが出たという。スロットリング方式では、設定した上限に達した時点でエージェントの実行を止めるため、コスト超過は防げても処理そのものが未完了になる場合がある。

　これに対しTokenOpsは、予算超過が近づいた段階でエージェントをすぐに停止するのではなく、出力量を抑えるなど処理内容を調整し、予算内で完了できるよう制御する。

　コウル氏は「平均支出を減らしながら、完了率を67％から約96％まで引き上げられました」と述べる。

　こうした制御に使うポリシーとして、両氏はコンテキストの圧縮、ツールから返す情報量の削減、ループ検知、処理の進捗検知などを紹介する。

AIエージェントのFinOpsは「請求を見る」だけでは足りない

　従来のクラウドFinOpsでは、利用量を可視化し、予算を設定して、必要に応じてリソースを削減するといった手法が使われてきた。

　AIエージェントでは、それだけでなく「なぜそのトークンが使われたのか」まで追跡する必要があるというのが、チャウラ氏とコウル氏の主張だ。

　どのユーザー、どのエージェント、どの実行がコストを生んだのかを記録する。その上で、コンテキストが増え過ぎているのか、検索結果を取得し過ぎているのか、ループを繰り返しているのかを判断し、エージェントを止める前に動作そのものを調整する。

　AIエージェントのコスト管理では、「何ドル使ったか」だけを見るのでは不十分になる。どの処理がコストを生み、その支出がどのような成果につながったのか。チャウラ氏が冒頭で示した、「token maxingからvalue maxingへ」という考え方は、AIエージェント時代のFinOpsを考える1つの基準になりそうだ。

本稿は、Shippioが2026年8月22日に公開したFinOps for AI Agents：Who Spent All the Tokens?－Tisha Chawla＆Susheem Koul, Microsoftを基に作成しました。