1. はじめに：なぜAIエージェントの導入でLLM利用コストが増えるのか
近年、企業におけるLLM活用は、「一問一答型のチャットボット」から、LLMが自律的にツール呼び出し、情報取得、結果の確認、追加処理などを行う「AIエージェント」へと広がっています。
AIエージェントでは、1つのユーザーリクエストに対してLLMを1回呼び出して終了するとは限りません。
例えば、ユーザーから「社内の売上データを調べてレポートを作成して」と指示された場合、エージェントは内部で以下のような処理を順次実行することが考えられます。
- ユーザーの指示を理解する
- 必要なツールやAPIを選択する
- データを取得する
- 取得結果を確認する
- 必要に応じて追加の検索・処理を行う
- 最終結果を生成する
そのため、ユーザーから見たリクエスト数が増えていなくても、バックエンドではLLMモデルの呼び出し回数や、処理する入出力トークン数が急激に増加する場合があります。
実際に本番運用すると、「アクセス数はそれほど増えていないのに、LLM APIの利用料金が大きく跳ね上がった」という問題が発生しがちです。本記事では、従来のチャットとAIエージェント導入後の振る舞いの違い、およびインフラ側に与える影響と解決策について考察します。
2. 従来のチャットとAIエージェントのふるまいの違い
コスト急増の最大の要因は、「1回のユーザーリクエスト ＝ 1回のLLM呼び出し」ではなくなった点にあります。処理フローの違いの一例を以下に示します。
従来のLLM利用（一問一答型）
[ユーザー] ──(1リクエスト)──> [LLM] ──(1レスポンス)──> [完了]
AIエージェント導入後（ループ・マルチステップ型）
[ユーザー] ──(リクエスト)──> [AI Agent]
├─(Call 1)─> [LLM] → ツール/APIを呼び出す
├─(Call 2)─> [LLM] → ツールの結果を確認
├─(Call 3)─> [LLM] → 追加処理
└─(Call 4)─> [LLM] → 最終回答
このように、タスクの複雑度に応じて複数回のLLM呼び出しがバックグラウンドで自動的に発生します。
3. 【検証】通常チャット vs Deep Research（自律リサーチ）
AIエージェント的な振る舞いによる負荷の違いを体感するため、同一プロンプトに対する通常チャットとDeep Research（自律リサーチ機能）の挙動を2つのAIモデル（AI-A, AI-B）で比較検証しました。
検証プロンプト
「80歳の男性が、都庁から東京駅に行くまでの最適な移動手段を教えて」
検証結果
AI-Aの通常チャット
数秒で推奨経路を出力。
- タクシー
- 電車（丸の内線使用）
- 電車（中央線使用）
AI-Bの通常チャット
こちらも数秒で推奨経路を出力。
- 電車（丸の内線使用）
- タクシー
- バス
AI-AでDeep Researchを使用
約15分程で、6ページにわたる詳細内容を出力。通常チャットで出力された推奨経路以外にも、駅のエレベーターやバリアフリールートなどを細かく調査。
AI-BでDeep Researchを使用
約8分程で、5ページにわたる詳細内容を出力。推奨内容と順序は通常チャットと同様ですが、駅のエレベーターや東京駅のバリアフリールートなどを調査。
検証からの考察
AI-AでDeep Researchを1回実行した後、「現在の使用量上限に達しました」と表示されました。同じ1つの質問であっても、内部でエージェント的に自律処理を行わせると、消費されるリソース（トークン量）が劇的に変わることが分かります。
また、出力までに要する時間も大幅に増加しており、バックエンドのコンピュートリソース（GPU/メモリ）を継続的に占有していることが推測されます。AIエージェントが実行するワークロードによって、必要となるGPU基数やVRAM/システムメモリ容量の要求仕様が根本から変わると考えられます。
4. コンテキスト膨張とAPI料金・計算負荷
「思考・判断 ➔ アクション ➔ 結果の取得 ➔ 次の判断」というループ処理では、ステップが進むにつれて過去のやり取りやツール実行結果がコンテキストとして蓄積され、入力トークン数が膨張します。
主要なLLM APIの料金構造において、Prompt Caching（キャッシュ活用）が適用される場合と適用されない場合では、最大10倍近い価格差が生じることがあります。コンテキストが大きくなった状態でキャッシュが効かない処理が挟まると、APIコストは一気に急増します。
(※Prompt CachingやContext Compactionなどのテクニックで抑制を図るものの、基本的には「ステップ数 × コンテキストサイズ」に比例した処理負荷とコストが発生すると考えられます。)
5. AIエージェントの普及でGPU・メモリインフラに何が起こるのか
AIエージェントの処理量増加に伴い、単に「GPUの演算性能」を高めるだけでなく、巨大化したコンテキストやKVキャッシュを保持するためのメモリ容量・帯域も重要になります。
しかし、最大負荷（ピーク時）に合わせた固定的なハードウェア構成をサーバーごとに構築すると、以下のような問題が発生します。
- エージェント処理実行時：GPUやメモリが枯渇しボトルネックになる
- 通常処理・待機時：高価なGPUリソースが稼働せず、リソース利用効率（ROI）が著しく低下する
ワークロード（CPU中心の処理、単一GPU処理、複数GPU並列処理など）の動的な変化に応じて、ハードウェア構成を柔軟に変更・再割り当てできるインフラ設計が強く求められます。
なお、コンポーザブルインフラにおけるGPU効率化の観点から、以下の参考記事なども非常に興味深い知見を提供しています。
6. 解決策としてのコンポーザブルなインフラ
AIエージェント時代のインフラ課題を解決する技術として、CDI（Composable Disaggregated Infrastructure）によるコンポーザブルなGPUやCXLが大きな注目を集めています。
CDI（Composable Disaggregated Infrastructure）とは
CDIは、PCIe/CXLファブリックを介して、GPU・ストレージ・メモリなどの物理リソースをサーバー筐体の枠を超え、ソフトウェア制御で動的に構成（コンポーズ）し、ディスアグリゲート（分離）する技術です。
- ジョブA（AIエージェント実行時）：サーバー1台に対し、GPU 4枚と大容量CXLメモリを即座に割り当てて高速処理。
- ジョブB（データ前処理・CPU処理時）：処理終了後、不要になったGPUを解放し、別の分析ジョブへ動的再割り当て。
このような柔軟な構成変更により、固定的なハードウェア構成に伴うサイロ化や過剰投資を防ぎ、GPU/メモリの利用率を極限まで高めることができます。
7. まとめ：コンポーザブル技術がもたらすインフラの解決策
AIエージェントの台頭により、バックエンドで実行されるタスクはより複雑化し、リソースの要求スペックも流動的になりました。多様かつ不確実なAIワークロードのピークに合わせて物理サーバーを個別に増設し続ける対応は、コストおよび運用面で限界を迎えつつあります。
「必要なときに、必要な分だけGPUやメモリをサーバーへ即座に割り当て、処理が終われば解放する。」
CDI（Composable Disaggregated Infrastructure）によるコンポーザブルGPUとコンポーザブルメモリ（CXL）を組み合わせたコンポーザブル・インフラストラクチャは、AIエージェント時代におけるコスト最適化とリソース効率化の強力な解決策になると期待されます。