この記事で扱うこと
エージェントAI（Agentic AI）を本番運用すると、パイロット段階では見えなかったコストが急増する。本記事では、その原因を6つのコストドライバに分解し、品質を落とさずにコストを制御する5つの設計レバーを解説する。対象読者は、システム設計・API連携・ガバナンス・運用設計に携わるエンジニアとアーキテクト。
パイロットは嘘をつかないが、不完全である
ある企業の買掛金（AP）例外処理エージェント。パイロットでは1トランザクションあたりのコストが十分に低く見えた。しかし本番投入から6ヶ月後、クラウドコストは8倍に跳ね上がり、ユーザーからは応答の遅さに対する不満が殺到した。
なぜ起きたのか。エージェントワークフローは単一のモデル呼び出しではない。以下のような複数のステップが連鎖する。
- ケース受付
- ERPとナレッジベースからのコンテキスト取得（検索・ツール呼び出し）
- モデルによる分類
- 請求書と入庫ステータスの確認（ツール呼び出し）
- データ不備があればリトライ
- 推奨またはエスカレーションの生成
各ステップは単体では安価だが、成功アウトカム1件あたりの累積コストはパイロットの想定をはるかに超える。パイロットは低ボリューム・クリーンデータ・選別シナリオで動作するため、この現実が隠蔽される。
重要なのは「1プロンプトあたりのコスト」ではなく、「1成功アウトカムあたりのコスト」 である。
6つの隠れたコストドライバ
1. モデル選定のミスマッチ
多くのチームが、意図分類やフィールド抽出といった軽量タスクにも最高性能モデルを使っている。調達業務の初期カテゴリ分類であれば小規模モデルで十分であり、強力なモデルは曖昧なケースや高リスク判断に限定すべきである。
2. コンテキスト長の制御不能
ドキュメント、トランザクション履歴、メタデータを「念のため」すべてプロンプトに含めると、推論コストとレイテンシが急増する。コンテキスト長は静かなコストキラーであり、適切な検索設計なしにエージェントを運用すると、品質も低下する。
3. 過剰な推論ステップ
ITインシデントの基本エンリッチメントに長大な推論チェーンは不要である。すべてのタスクを複雑な問題とみなすと、コストとレイテンシが不釣り合いに増加する。
4. 検索・ツール呼び出しの連鎖
ベクトルストアへのクエリ、ERP/CRM/HRISへのAPI呼び出しは、AIレイヤのコストだけでなく、ミドルウェア負荷、イベント処理、ライセンス費用などの間接コストを伴う。エンタープライズ環境では、ツール呼び出しのコストがAI推論コストを上回ることも珍しくない。
5. 評価と可観測性のコスト
ログ保存、トレース処理、ダッシュボード運用、サンプリングレビュー、回帰テスト——これらはすべてコストである。ガバナンスを強化すればするほど制御コストは増える。可観測性を削るのではなく、初期コストモデルに組み込むことが正しい設計判断である。
6. マルチエージェント構成のオーバーヘッド
オーケストレータ＋複数のタスクエージェントという構成は、1リクエストあたりのコストを乗算する。モジュール性や品質に明確なメリットがある場合にのみ採用すべきであり、単純なユースケースではアーキテクチャ上の贅沢に過ぎない。
品質を犠牲にしない5つの最適化レバー
1. モデルルーティング
最も強力なレバー。軽量タスクには小規模モデル、複雑な推論や高リスク判断には強力モデルを割り当てる。財務クローズでは、構造化データからの差異抽出に軽量モデル、ポリシーとビジネスナラティブを統合したコメント作成に強力モデルを使う。ルーティングの導入はアーキテクチャと評価の複雑性を増すが、コスト抑制効果は大きい。
2. コンテキストの削減
以下の3つの手法が実践的である。
- 高精度な検索：不要なドキュメントをプロンプトに含めない
- 事前要約：メイン推論の前にコンテキストを要約する
- キャッシング：頻出コンテキストをキャッシュする
カスタマーオペレーションでは、全履歴を毎回送るのではなく、関連サマリ＋オンデマンド詳細取得で十分なケースが多い。ただし、要約によるニュアンス損失やキャッシュの陳腐化には注意が必要である。
3. リトライとループの制限
「成功するまで何度でも試す」エージェントはコスト爆発の原因となる。すべてのワークフローに以下を設定する。
- 明示的な停止条件
- リトライ上限（例：最大2回）
- ツール呼び出し上限（例：最大5回）
- 人間へのエスカレーション条件
4. 動作モードの段階的適用
すべてのユースケースに完全自律モードは不要である。以下の3モードを状況に応じて使い分ける。
- ドラフトモード：エージェントが下書きを生成し、人間が確認・修正
- レコメンドモード：エージェントが推奨を提示し、人間が承認
- 実行モード：エージェントが自律実行（リスクが低く、信頼性が確認できた場合のみ）
5. 可観測性の階層化
すべてのインタラクションにフルログを取るとコストがかさむ。以下の階層化が推奨される。
| リスクレベル | ログポリシー | 保存期間 |
|---|---|---|
| 高リスク（決済・個人情報） | フルログ | 長期（監査要件に準拠） |
| 中リスク | サンプリング＋サマリ | 中期 |
| 低リスク（内部Q&A等） | サマリのみ | 短期 |
レイテンシとキャパシティ：忘れられがちな次元
コストだけに注目すると、遅すぎて使われないエージェントが生まれる。レイテンシはユーザー採用率、プロセスSLA、チーム生産性、そしてエージェントへの信頼に直接影響する。
設計上の最重要判断は同期/非同期の区別である。
- 同期モード：内部Q&A、初期分類、短いドラフト、単純なレコメンド。コンテキストを限定し、ツール呼び出しを最小限に抑える。
- 非同期モード：複雑な例外分析、レポート生成、インシデント調査、複数ソースの突合。ユーザーは画面で待つ必要がなく、ステータス通知とレビュー可能な結果が重要。
キャパシティ計画はモデル推論だけでなく、検索、統合レイヤ、ワークフローエンジン、人間の承認キャパシティまで含める必要がある。月末の財務クローズやカスタマーオペレーションのピーク時には、事前にキャパシティを確保しなければ、レイテンシの悪化→リトライ増加→コスト上昇の負のスパイラルに陥る。
経済性のオーナーシップ
エージェントAIのFinOpsを技術ダッシュボードだけで完結させてはいけない。本番エージェントには以下が必要である。
- ビジネスオーナー：アウトカムと予算の責任者
- テクニカルオーナー：アーキテクチャと運用の責任者
- 支出上限とアラート：予算超過を事前に検知
- 利用分析とアウトカム目標：コスト対効果を継続測定
ポートフォリオレビューでは、利用ボリュームだけでなく、総コスト、成功アウトカムあたりのコスト、レイテンシ、修正率、エスカレーション率、ビジネス価値を比較する。人気のあるエージェントが必ずしも経済的とは限らない。
以下の兆候が見られた場合、エージェントはスケールに耐えられない。
- 成功アウトカムあたりのコストが高すぎる
- レイテンシが原因でユーザーが手動プロセスに戻っている
- リトライとループが過剰
- ツール呼び出しが異常に多い
- 承認キューがボトルネックになっている
- 運用・監視コストを正当化できるビジネス価値が証明されていない
この場合の正しい判断は「モデルを最適化する」だけではない。ワークフローの簡略化、自律性の低下、非同期UXへの切り替え、あるいはユースケースそのものの中止も選択肢に入れるべきである。
まとめ：スケールするエージェントAIのために
エージェントAIのFinOpsは、コストを極限まで下げることではない。経済性、ユーザー体験、運用制御のバランスを保ちながらスケールすることである。パイロットで印象的なデモを見せるだけでは不十分であり、本番で持続可能な設計が求められる。
参考
https://ariefwara.github.io/ai-for-business/ja/agentic-ai-finops