LLMエージェントのコストは線形じゃない
AIエージェントを使い始めて「思ったより請求額が高い」と感じたことはありませんか。実はこれには構造的な理由があります。LLMベースのエージェントは、タスクが複雑になるほどコストが「二次関数的（quadratic）」に増大する性質を持っているんですね。
Hacker Newsでも「Expensively Quadratic: The LLM Agent Cost Curve」というタイトルの記事が話題になり、多くの開発者が共感のコメントを寄せていました。
なぜコストが二次関数的に増えるのか
最大の原因は「コンテキストウィンドウの蓄積」です。LLMエージェントは、ステップを踏むたびに過去のやり取りをコンテキストとして保持します。ステップ1では少量のトークンですが、ステップ10になると過去9ステップ分のトークンが全部入力に含まれるわけです。
つまり、各ステップの入力トークン数は「1 + 2 + 3 + … + n」のように累積していきます。これはn²/2に比例するため、ステップ数が2倍になるとコストは約4倍に膨らむという計算になります。
さらに、エージェントがツール呼び出しの結果を受け取ると、そのレスポンスもコンテキストに追加されます。外部APIの返り値が長い場合、一気にトークン数が跳ね上がることもあるので要注意です。
LLMエージェント コストの具体的なイメージ
たとえば、10ステップのエージェントタスクで各ステップの出力が500トークンだとしましょう。最初のステップの入力は500トークンですが、10ステップ目には約5,000トークンの入力になります。合計入力トークンは約27,500トークン。単純に10回独立して呼び出す場合の5,000トークンと比べると、5倍以上のコストです。
これが20ステップになると差はさらに開き、100ステップの複雑なタスクでは桁違いのコストになることもあります。OpenAIの料金表を見ると分かりますが、入力トークンにも課金されるモデルが多いため、この累積効果は無視できません。
コストを抑えるための実践的なアプローチ
では、どうすればこのコスト問題に対処できるのでしょうか。いくつかの方法を紹介します。
コンテキストの要約・圧縮
一定ステップごとに過去のやり取りを要約し、フルログの代わりに要約文だけをコンテキストに渡す方法です。精度は多少落ちますが、コストを大幅に削減できます。
ツール出力のトリミング
外部APIからの返り値が長い場合、必要な部分だけを抽出してコンテキストに渡すようにします。MCPサーバーを使う場合も、レスポンスのフィルタリングを組み込むと効果的です。
小型モデルとの使い分け
すべてのステップで最大サイズのモデルを使う必要はありません。判断が簡単なステップでは小型モデル、重要な判断には大型モデルという使い分けが、コスト効率を大きく改善してくれます。
プロンプトキャッシングは救世主になるか
プロンプトキャッシングは、同じプレフィックスを持つ入力のコストを削減する技術です。エージェントの場合、システムプロンプトやツール定義は毎回同じなので、この部分のキャッシュは効果があります。
ただし、各ステップで追加される会話履歴は毎回異なるため、キャッシュの恩恵を受けられるのは一部分にとどまります。根本的な解決にはなりませんが、組み合わせて使うことでコストを20〜40%程度は削減できるケースが多いようです。
まとめ
LLMエージェントのコストが二次関数的に膨らむのは、アーキテクチャ上の避けられない性質です。しかし、コンテキスト圧縮やモデルの使い分け、ツール出力のトリミングといった工夫で、実用的なレベルまでコストを抑えることは十分可能だと感じています。
エージェント設計に興味がある方は、AIエージェントハーネスの設計パターンも合わせて読んでみてください。コスト面も含めた設計の全体像が見えてくると思います。