AIエージェントの運用コストが制御できない本当の理由 — 単価ではなく設計の問題

運用コストを下げたいという相談の多くは、どのモデルが安いかという比較から始まります。しかしモデル単価の比較だけではコストは制御できません。理由は単純で、同じモデルであっても、何にどれだけのトークンを使わせるかという設計次第で消費量が大きく変わるからです。

先に触れた課金体系の変更のように、ベンダー側の価格体系そのものが変わることもあります。単価に依存した設計は、規約変更のたびに再計算が必要になり、長期的には脆くなります。relmeaが運用で重視しているのは、単価が変わっても崩れない設計、つまりどの工程にどのモデルを配置し、どのデータをどう再利用するかという構造の側です。

「安いモデルに変える」だけでは解決しない理由

モデルを一律で安価なものに切り替えると、精度が落ちて出力のやり直しが増え、結果的にトークン消費が増えることがあります。運用コストの問題は、単価そのものよりも、どの工程にどの精度のモデルが必要かという設計判断に帰着します。

LLMコストの3層構造 — 入力・出力・キャッシュ読み出しで単価が違う

多くのLLMベンダーの料金体系に共通しているのは、トークンの種類によって単価が分かれているという構造です。大きく分けると次の3層があります。

  • 入力トークン（プロンプトとして渡す文章・コード・データ）
  • 出力トークン（モデルが生成する応答）
  • キャッシュ読み出しトークン（一度キャッシュした入力を再利用する際の読み出し分）

業界で一般に言われている傾向として、出力トークンの単価が最も高く、キャッシュ読み出しの単価が最も低く設定されています。実際の単価や倍率は各社・各モデルで変動が大きいためここでは扱いませんが、この3層構造そのものは複数の主要ベンダーに共通しており、設計の前提として押さえておく価値があります。

この構造から導かれる設計原則

出力トークンが最も高いということは、モデルに長く喋らせる設計はコストに直結するということです。逆に、繰り返し使う大きな入力をキャッシュとして扱えれば、同じ情報を毎回読み込ませるコストを大きく圧縮できます。単価を比較する前に、この3層のどこにコストが偏っているかを可視化するほうが、実務上の効果は大きくなります。

定石化している削減の3点セット — トークン削減・モデルルーティング・キャッシュ

トークン削減

渡すコンテキストの量そのものを減らす取り組みです。冗長なログ・不要な過去のやり取り・重複した説明を渡さないようにするだけで、入力トークンは目に見えて減ります。地味ですが、最も着手しやすく副作用も少ない打ち手です。

モデルルーティング

すべての工程を同じモデルで処理するのではなく、工程ごとに必要な精度を見極めてモデルを使い分ける設計です。分類・抽出・要約のような前段の処理は精度要求が比較的低いため下位モデルに任せ、最終的な判断や生成が必要な工程だけを上位モデルに担わせる配置が定石になっています。すべてを最上位モデルで処理する設計は、精度面では安全に見えても、コストの観点では過剰投資になりやすい構造です。

プロンプトキャッシュ

システムプロンプト・参照ドキュメント・コードベースの一部といった繰り返し使う大きな入力をキャッシュとして扱い、再利用時はキャッシュ読み出しの単価で済ませる設計です。3層のうち最も単価が低いのがキャッシュ読み出しであるため、キャッシュを効かせられる箇所を見極めることは削減効果が大きくなりやすい打ち手です。

エージェントが特にトークンを食う3つの理由

コマンド出力の冗長性

エージェントがコマンドやツールを実行すると、その実行結果（ログ、エラースタック、ファイル一覧など）がそのままコンテキストに戻ってくることがあります。実行結果を要約せずに丸ごと文脈へ積み上げていくと、セッションが進むほどコンテキストが膨らみ、以降のやり取りすべての入力トークンを底上げしてしまいます。

コードベース全体の読み込み

コードや設定ファイルを扱うエージェントは、必要な範囲だけでなく関連しそうなファイルまで広く読み込む傾向があります。リポジトリが大きくなるほど1回のタスクで読み込む範囲も比例して広がりやすく、意図せず入力トークンが積み上がる原因になります。

セッション間のコンテキスト再構築

新しいセッションを開始するたびに、エージェントはこれまでの経緯・ルール・前提を再度読み込む必要があります。長期運用する自動化ほど、この再構築コストが毎回発生する固定費のようにのしかかってきます。

relmeaの設計 — 多段オーケストレーターで親には終端サマリーだけを返す

relmeaでは、91体のサブエージェントとオーケストレーターコマンド42本という構成で日々の業務を自動化しています。これだけの数を運用するうえでコストを制御する軸にしているのが、親エージェントのコンテキストを太らせないという設計です。

一部の業務は、親となるオーケストレーターが複数の子エージェントを起動し、それぞれに調査・実装・検証などの工程を担わせる多段構成にしています。このとき、子エージェントが読み込んだコードベースの全文や実行したコマンドの詳細なログは子の作業領域にとどめ、親には何を行い結果がどうだったかという終端サマリーだけを返す設計にしています。

この設計の狙いは、精度を落とさずに親側のコンテキスト肥大を防ぐことです。親のコンテキストが長くなるほど以降のやり取りすべての入力トークンが底上げされていくため、子の詳細を親に持ち込まない設計は、そのままコストの抑制にもつながります。

モデルの配置も工程ごとに分ける

多段構成の中でも、調査や情報整理のような前段の工程と、最終的な意思決定や成果物の生成のような工程では、必要なモデルの精度が異なります。relmeaでは、この工程ごとの精度要求の違いに応じてモデルを配置する設計を、単発のプロンプト設計だけでなくエージェントの階層構造そのものに組み込んでいます。

コスト最適化そのものの手間は、元が取れるか

モデルルーティングやプロンプトキャッシュは、効果自体は広く語られている手法ですが、それを設計・実装・運用し続けるための手間はゼロではありません。工程を分割してルーティングを組む設計、キャッシュが有効に働くよう入力の構成を固定する作業、削減効果を継続的に測定する仕組みづくりには、それぞれ着手コストがかかります。

relmeaが実際の運用で先に確認しているのは、この最適化にかける手間が、削減できるコストを上回らないかという点です。呼び出し頻度が低い、あるいは扱うコンテキストがもともと小さいエージェントに複雑なルーティングやキャッシュ設計を持ち込んでも、削減額より設計と保守の手間のほうが大きくなることがあります。

コスト最適化はやったほうがよいことではなく、どの業務でやると割に合うかを先に見極める判断の対象として扱う。規約変更ひとつでコスト構造が変わりうる以上、単価に依存しない設計を先に持っておくこと、そしてその設計にかける手間自体が見合うかを問うこと。この2点が、運用コストを一時的にではなく継続的に制御するための土台になります。

モデル使い分け・コンテキスト設計・キャッシュ活用を実際にどう組み合わせて運用しているかはBrain Vol.1（運用編）で、多段オーケストレーターの実装や自動化パイプラインの組み方はBrain Vol.3（自動化実装編）で扱っています。設計と運用そのものを任せたい場合はRelmea AI Ops（AIチーム構築代行）でも対応しています。