何が発表されたのか
米Microsoftは同社の配信番組「The Azure Essentials Show」において、AI開発プラットフォーム「Microsoft Foundry」（編集部注：旧Azure AI Foundryの発展的ブランド）におけるAIエージェントの運用コスト最適化ソリューションを発表しました。同番組にはMicrosoft CoreAIのディレクター・オブ・エンジニアリングを務めるSindhura Bandhakavi氏が登壇し、ホストのTakuto Higuchi氏とともに、AI業界で急速に関心が高まっている「トークノミクス（Token Economics / Tokenomics）」の概念と、それを実現する「Model Router」および「Agent Optimizer」の2機能を実演解説しました。
これらの機能は、単に安い大規模言語モデル（LLM）を採用するだけでなく、リクエストの内容に応じてリアルタイムに適切なモデルへルーティングする仕組みと、本番環境の利用データに基づいてエージェントの構成を継続的に自己改善する仕組みを提供します。研究段階ではなく、Microsoft Foundry上で即座に利用可能なプレビューおよび一般提供（GA）機能として組み込まれています。
発表された機能・アップデートの全容
AIエージェントにおけるコスト発生機序と非決定性の課題
Sindhura Bandhakavi氏は、生成AIのコスト構造が従来のソフトウェア開発と根本的に異なる点を強調しました。従来型ソフトウェアでは、インフラ代やストレージ代、事前定義されたロジックの計算量が主なコストであり、テスト環境で正常に動けば本番環境でもほぼ予測通りのコストで推移します。
しかし、AIアプリケーション、特に自律的な推論とツール呼び出しを行うAIエージェントでは状況が一変します。AIモデルの呼び出しは「ステートレス」であるため、対話が継続するたびに過去の会話履歴、システムプロンプト、ツール実行結果、RAG（検索拡張生成）で取得したコンテキストのすべてを毎回再送しなければなりません。さらにエージェントは目的を達成するために複数回の内部ループ（意図分類、計画立案、ツール呼び出し）を回すため、1回のリクエストに対してLLM呼び出しが多重化し、全体のトークン消費量が爆発的に増大します。AIが持つ「非決定性（Non-deterministic）」ゆえに、本番環境の複雑なデータと接触した際、事前テストでは予期せぬ推論ルーティングが発生し、コスト急増の主因となります。
トークン数削減だけに依存しない最適化戦略の重要性
多くの開発者が陥る誤りとして、Bandhakavi氏は「単に送受信するトークン数を削ればコストが下がる」という短見的な考え方を指摘しました。プロンプトを無理に短縮したり情報を削りすぎたりすると、AIエージェントの推論精度が低下します。その結果、ゴールに到達するまでにエージェントが何度もやり直し（ツール再呼び出しや再質問）を行い、最終的なトータル呼び出し回数が増えてかえって総コストが悪化する事例が頻発しています。
真の最適化とは、単一リクエストあたりのトークン削減のみを目指すのではなく、タスクの難易度に応じて価格の異なるモデルを使い分けることや、適切なプロンプト構造によって一発で正確な回答を出力させる「総コストと回答精度のバランス調整」にあります。
リアルタイムで最適モデルを選択する「Model Router」
動画内では、1つ目の目玉機能として「Model Router」のデモが実演されました。Model Router自体が特殊な判断用言語モデルとして機能し、ユーザーから送られてきたプロンプトの複雑さや処理要件をミリ秒単位で解析して、背後にある最適なLLMへ処理を振り分けます。
設定画面では、まずデプロイメントタイプとして「Global Standard」と特定のリージョンに制限する「DataZone Standard」を選択します。続いてルーティングモードとして以下の3つを設定します。
- Quality: 回答精度を最優先し、高スペックモデルを中心に選択
- Cost: 費用削減を最優先し、軽量小型モデルを中心に選択
- Balanced: タスクの難易度とコストの損益分岐点を判断してバランス良くルーティング
さらに、エンタープライズのコンプライアンス要件に応じ、使用を許可するモデルのサブセット（例：GPT-4o、GPT-4o mini等）を指定可能です。 デモでは、住所のフォーマット変換という単純なリクエストに対しては自動的に低価格な「GPT-4o mini」が選択され処理されました。一方で、月間4万件のカスタマーサポートデータの計算と移行プラン立案という複雑な多段階推論を要するリクエストに対しては、思考力に長けた大型モデルが自動選択され、精度を落とすことなく適切なモデル割り当てが行われる様子が示されました。
本番トレースから継続改善を自動化する「Agent Optimizer」
2つ目の主要機能が「Agent Optimizer」です。エージェントを一度本番環境にデプロイした後に、どのように精度向上とコスト低減を両立させるかを自動化する仕組みです。
通常、エージェントの評価用データセット（テスト集）を手動で作るのは膨大な労力がかかります。Agent Optimizerは、Microsoft Foundry内に自動蓄積された本番ログ（Traces）から代表的なデータを自動抽出して評価データセットを生成します。その上で、LLM自身がオプティマイザーとして機能し、元の設定（Baseline）に対して複数のプロンプト案やシステム構成案（Candidates）を自動生成し、並列テストを実行します。
画面上の実演では、1回の最適化プロセスにかかる推定コスト（「約1.09ドル〜3.64ドル」など）が事前に提示され、開発者は納得した上で最適化ジョブを発注できます。生成されたCandidate 1とCandidate 2の比較結果画面では、Candidate 1が精度スコアを0.753から0.832に大きく向上させ、Candidate 2は逆にスコアを低下させたデータが明確に可視化されました。オプティマイザーが追加したシステムプロンプトの差分（Diff表示）を確認した上で、開発者はボタン一発で成果の良いCandidate 1を新たな本番バージョンへ昇格（Promote）させることができます。
精度向上と費用低減を両立するフライホイール構造
Model Routerが「推論実行時（Runtime）の動的振分」を担うのに対し、Agent Optimizerは「中長期的な構成最適化（Periodic Optimization）」を担います。この2つが組み合わさることで、本番データが溜まるほどエージェントが賢くなり、不要な高額モデル呼び出しが削減され、精度が高まりながら平均単価が下がっていく「フライホイール（弾み車）効果」が生まれると説明されました。これは一度きりのチューニングではなく、自動化されたHill-climbing（山登り法）マシンとして働き続けます。
