エージェント最適化の経済学第2弾、コスト削減4手法を公開

本ブログ記事は、「エージェント最適化の経済学」と題された全 4 部構成シリーズの第 2 弾です。Microsoft Foundry で AI を管理投資システムとして運用し、エージェントのコストを最適化するための戦略、機能、実証事例を紹介します。

前編では、このシステムの基盤となる 3 つの意思決定について解説しました。それは「ランタイム時の各リクエストの最適化」「時間経過に伴うワークフロー全体の最適化」、そして「支出の継続的なガバナンス」です。本稿ではその最初の項目、「AI に費やす全費用に直結する最適化手法」を取り上げます。

エージェントとは、モデルをループ状に組み合わせたものです。計画を立て、ツールを呼び出し、結果を読み取り、再度推論を行うため、一つの完了した成果物を得るまでに、モデルへのリクエストが十数回発生することさえあります。そのため、ビジネスが重視すべきはトークン単価ではなく、「成功した成果物あたりのコスト」です。

このループ内の各ターンは依然として 1 つのモデルリクエストであり、それぞれのリクエストには「どのモデルを使うか」「どのオファーで実行するか」「何を再利用するか」「モデルに何と指示するか」といった重要な判断が伴います。これらの判断を適切に行えれば、その節約効果はすべてのターンで積み重なっていきます。だからこそ、エージェント最適化はこの地点から始まるのです。

Microsoft Foundry がどのように時間とコストの削減をサポートするか、詳しく見ていきましょう。

生産環境における AI で最も高価な習慣とは？

多くの AI アプリケーションは、同じような方法で構築されています。プロトタイプ段階では、利用可能な最も強力なモデルを選び、モデルが必要とする可能性のあるすべての情報をプロンプトに盛り込み、アイデアが機能することを確認します。これはプロトタイプにとっては正しい直感ですが、問題はその後です。

プロトタイプのデフォルト設定が、知らず知らずのうちに本番環境のアーキテクチャとして定着してしまいます。「これが動くか？」という問いに応えるために設計されたパターンが、「これを経済的にスケールできるか」という問いに答える責任を背負うことになります。

その時点で二つの問題が発生します。第一に、AI のワークロードは均一ではありません。一つのアプリケーションには、意図の分類、情報抽出、フォーマット変換、要約、そして本格的な多段階推論が混在しており、AI ワークロードの複雑さは非常にばらついています。これらをすべて最先端モデルへルーティングすると、その能力を必要としないリクエストの大半に対して過剰なコストを支払うことになります。

第二に、一つの成果物を得るために多数のリクエストが発生します。プロトタイプでは一度の呼び出しに対して支払えばよいですが、エージェントはループ全体に対して支払う必要があります。そのため、無駄な処理があるとそれが倍増してしまいます。トークン数についても同様ですが、ミスについてはさらに深刻です。間違った方向に進んだエージェントは、誤ったツールを呼び出して回復のためのループに入り、本来発生すべきではないステップでトークンを浪費し、結果としてより弱い回答にたどり着いてしまいます。

一つの成果物あたりのコストは、各ステップで使用されるトークンの量だけでなく、回避できたステップの数によっても大きく決まります。

本番環境における目標は、トークン数を最小化することではありません。重要なのは、品質・安全性・レイテンシを維持したまま、成功する結果を得るためのコストを下げることです。すべてのランタイム決定では、これらの要素をバランスよく考慮する必要があります。そのため、リクエストの経済性を左右するのは、以下の 4 つの意思決定に集約されます。

ランタイムで制御できる 4 つのレバー

Microsoft Foundry では、プロトタイプがたまたま選んだ妥協点を受け入れるのではなく、意図的にトレードオフを調整するための 4 つのレバーを提供します。各レバーは単独で導入でき、自社の品質基準に照らして測定可能です。もしその妥協点が成立しない場合は、いつでも元に戻すこともできます。

• レバー：Foundry の機能
• モデルとオファー：モデルルーター、デプロイメントタイプ、プロビジョニング済みスループット、バッチ処理、ファインチューニング
• キャッシング：プロンプトキャッシュ、Azure API Management の AI Gateway を介したセマンティックキャッシュ
• プロンプトおよびエージェントの最適化：指示・スキル・ツール説明・モデル選択にわたるプロンプトオプティマイザー、エージェントオプティマイザー
• 観測性と評価：Foundry の観測性と評価、エージェントトレース、Azure バジェット、アラート、コストタグ付け

1. リクエストを適切なモデルへ送信する

基本原則はシンプルです。タスクの複雑さに応じて結果を最適化することです。単純なリクエストに対しては、最先端モデルの経済性を支払う必要はありません。逆に、複雑なリクエストにおいて、トークン数を節約するために品質を犠牲にしてはいけません。

Foundry Models の Model Router は、コストと性能のトレードオフを解消します。この機能は着信する各リクエストを評価し、単一のエンドポイントと単一のデプロイメント背後で、最も適した基盤モデルにリアルタイムでルーティングします。ルーティングモードでは、コスト優先、品質優先、またはそのバランスを重視して設定できます。また、Model サブセットは Azure Policy と整合するようになり、コンプライアンス境界が適用される領域では承認されたホワイトリスト内でのみルーティングが行われます。組み込まれたフェイルオーバー機能により、利用可能なモデルがない場合は自動的に次の最適なモデルへリクエストが転送されるため、堅牢性も確保されます。

同じリクエストでも、デプロイ方法によって経済性は大きく異なります。これは多くのチームが見落としがちな重要なポイントです。組織は以下の点を明確に決定する必要があります。

• データをどこで処理するか（グローバル、データゾーン、またはリージョン単位）
• スループットをどのように購入するか（トークン課金か、プロビジョニング済み容量か）
• どのワークロードがインタラクティブな応答を本当に必要とするか

Foundry は複数のデプロイオプションを提供しており、ビジネス要件に合わせて最適な選択が可能です。多くのワークロードは、柔軟性とコスト効率に優れた従量課金型の標準デプロイから開始できます。

より高速で安定した応答時間が求められるインタラクティブなアプリケーションには、優先処理が有効です。一方、需要が見込める大規模なワークロードでは、Provisioned Throughput Units (PTUs) を活用することで経済性を高め、あふれ出るトラフィックは従量課金型の容量で処理する構成が推奨されます。

文書処理や分類、評価実行など、即時応答を必要としない非同期の大規模ワークロードには、バッチデプロイが最も適しています。これにより、即時的なレスポンスが不要な作業において最大 50% のコスト削減を実現できます。

単一のアプリケーション内でも、異なる体験に対して最適なデプロイ戦略は異なります。多少のレイテンシ変動を許容できる開発者向けツールであれば、標準デプロイで効率的に運用可能です。

インタラクティブなチャット体験には優先処理が適しており、持続的なスループットが求められるエージェント型アプリケーションでは PTU を活用することで最大の価値を引き出せます。文書分析や知識抽出、大規模分類などのバックグラウンドタスクは、エンドユーザーの体験を損なうことなくバッチデプロイへ移行できます。ワークロードに合ったデプロイモデルを選択するだけで、コスト削減が実現します。

ファインチューニングは、このレバーをさらに高度に活用する手法です。ルーティングが既存のモデルの中から最適なものを選ぶのに対し、ファインチューニングは小規模なモデル自体の能力を変え、特定のタスクやトーン、フォーマットを学習させることで、大規模モデルと同等の性能を発揮できるようにします。そのメリットは、利用料金の低下とプロンプト長の短縮です。動作が安定しており、かつ処理量が投資対効果が見込めるほど十分に高い場合に採用すべき手法です。

1. 同じトークンに対して二重課金をやめよう

エージェントはキャッシュの恩恵を非常に受けやすい存在です。システム指示、ツールスキーマ、ポリシーテキストなどは、会話の各ターンで毎回再送信されるため、10 ターンかかるエージェントでは、このプレフィックス部分に対して 10 回分のコストが発生してしまいます。プロンプトキャッシングを使えば、一度処理済みのプレフィックスを再利用でき、再処理する必要がなくなります。標準的なデプロイメント環境ではキャッシュ読み取りは通常の入力価格より割引料金で課金され、プロビジョニング済みデプロイメントでは最大 100% の割引が適用されることもあります。コスト削減と並行して、レイテンシの短縮も期待できます。

この仕組みから価値を引き出す鍵は主にプロンプトアーキテクチャにあり、基本ルールはシンプルです。「安定したコンテンツを先頭に、変動するコンテンツを末尾に配置する」ことです。システム指示、ツール定義、Few-shot 例などを先頭に置き、ユーザー入力、取得したチャンク、会話履歴などを末尾に配置します。キャッシュが機能するにはプロンプトの先頭部分が完全に一致している必要があるため、タイムスタンプやユーザー名のようにリクエストごとに変わる要素は、その安定ブロックの下側に配置する必要があります。もし変動する要素を先頭に置けば、キャッシュは決してヒットしません。

プロンプトの上位層でもキャッシュは機能します。Foundry 推論 API の前にゲートウェイを配置する際は、AI Gateway（Azure API Management）のようなセマンティック・キャッシュ対応のゲートウェイを選ぶことが重要です。これにより、同じエンドポイントへのセッションアフィニティを維持でき、異なるセッションやユーザー間でもほぼ重複するリクエストをマッチングさせながら、キャッシュ効果を最大化できます。

また、決定論的なツールの結果は、データが更新される頻度に応じて TTL（Time-To-Live）を調整した独自のストレージにキャッシュすることも可能です。

1. プロンプトを最適化し、その後エージェントを最適化する

モデルの選択が速度を決めるなら、指示書が処理量を決めます。しかもこれはインフラに触れずに修正できる最も安価な手段です。トークン数を削減する手法は、回答品質を高める手法と共通しています。タスクを文脈の壁に埋め込むのではなく冒頭で明確にし、出力形式や長さを具体的に指定し、説明のための長い段落の代わりに精選した数例を示すのが効果的です。

さらに、会話が進むにつれて蓄積される情報を適切に管理することも重要です：

• 完全なトランスクリプトを再生するのではなく、完了した会話を要約する
• ツール定義は、そのタスクに関連するツールだけに絞り込む
• 作業状態は外部メモリに保存し、必要な時だけ呼び出す

Foundry では、これまで手動で行っていたチューニングを自動化しています。プロンプト最適化機能は、プロンプトエンジニアリングのベストプラクティスに基づいてエージェントのシステム指示書を書き換え、各変更に対する理由も提示します。これにより、ユーザーが方向性を示したり再実行したりした上で、ワンクリックで結果を適用することが可能になります。

Foundry Agent Service のエージェント最適化機能は、単なる分析に留まらず、改善のループを完結させます。実際のタスクデータセットに対してエージェントを実行し、候補となる設定を生成・採点・ランク付けすることで、最良の設定を選定して適用できます。プロンプト指示やスキル定義、ツール説明、使用するモデルの切り替えなど多様な要素を変更可能で、学習用データセットには自社のエージェント実行ログを活用することも可能です。

1. 可視化と評価による最適化の実現

見えないものを調整することはできず、測定していない節約を主張することもできません。Foundry の観測機能は、各リクエストごとの詳細な信号を提供し、他の 3 つの改善策を安全に実行できる基盤となります。具体的には、入力・出力トークン数、キャッシュヒット率、レイテンシ、実際にリクエストに応じたモデル、そして品質が維持されたかどうかを示す評価スコアなどが含まれます。

ここで重要なのは 2 つの数値です。「1 リクエストあたりのコスト」は、より安価な経路でも品質基準を満たしているかを確認するために必要です。一方、「完了した成果物あたりのコスト」こそが、ビジネスが実際に支払った金額を反映します。これは、達成までに要したすべてのターンやリトライを含んだ総額です。前者の値を下げて後者の値（必要なターン数）が増加する最適化は、実態としては悪化させていることになります。真の改善を見極めるには、後者「完了した成果物あたりのコスト」に注目する必要があります。

可視化された評価結果は、システム変更への許可証となります。コスト、レイテンシ、タスクの成功率を同時に測定し、すべての最適化手法がリリース前にクリアしなければならない恒久的な評価セットを用意してください。これらのトレーシングデータと評価セットこそが、エージェントオプティマイザーが消費する資源です。つまり、この作業は二重の効果を生みます。Azure 上で予算管理、アラート設定、コストタグ付けを組み合わせれば、回帰現象は月末の驚きではなく、即座に通知として届くようになります。

これがどのようにして「ヒルクライム」へと繋がるのか

これらの手段はいずれも一度きりの節約効果ではありません。それらが組み合わさることで、毎回のサイクルでより安価で高品質になるループが形成されます。マイクロソフト AI が「ヒルクライミングマシン」と呼ぶのは、まさにこの継続的な改善プロセスのことです。より良いデータと鋭い評価を通じて、サイクルを繰り返すごとにシステムを進化させます。

モデルとオファーの選択は各リクエストの実行場所を決定し、ファインチューニングは実証済みのタスクを恒久的に低コストな処理へと変換します。

キャッシングはすべてのサイクルのコストを引き下げ、これによりループを十分に頻繁に回すことが可能になります。

プロンプトとエージェントの最適化は次の候補を生成し、評価セットに対してその有効性を証明します。

観測性と評価は、現在の状況と直近の変更が効果を維持しているかどうかを明らかにします。

この「登り」には明確な開始点は存在しません。多くのチームは測定フェーズからこのサイクルに参加しますが、本質的には循環構造です。トレーシングデータが評価用データセットへと変換され、そのデータセットがオプティマイザーを駆動します。オプティマイザーの結果に基づき、安定したタスクを特定してファインチューニングの対象とします。ファインチューニングされたモデルはルーターの選択基準を変更し、新しいルーティングによって新たなトレーシングデータが生成されます。

本シリーズの最初の投稿「エージェント最適化の経済学：パイロットから測定可能な収益へ」を読み、AI パイロットから測定可能な ROI への移行について理解を深めましょう。

モデルルーターを導入し、現在のベースラインと比較検証してください。

Microsoft Mechanics のトークン経済に関するエピソードを視聴すれば、これらのレバーが実際にどのように機能するかを実践的に確認できます。

Microsoft Foundry でランタイム最適化の詳細を確認し、Foundry を活用した構築を始めましょう。

「エージェント最適化の経済学」シリーズで以下の投稿を見逃していませんか？

AI コスト管理：AI パイロットから測定可能な ROI へ