7月22日、Raman Bansalが「Building Token-Efficient Agentic Systems」と題した記事を公開した。この記事では、LLMエージェントシステムのトークンコストを構造的に削減しながらスループットを維持するアーキテクチャ設計手法について詳しく紹介されている。以下に、その内容を紹介する。
「トークンウォール」という構造的問題
エージェントシステムのPoC（概念実証）は安く動く。リクエスト数が少なく、1ターンのやり取りが中心だからだ。しかし本番スケールに移行した途端、コストが指数的に膨れ上がる。Raman Bansalはこの現象を「トークンウォール（The Token Wall）」と呼ぶ。
原因は4つある：
- マルチターンのコンテキスト蓄積：ReActループで全メッセージ履歴とツール実行結果を毎回プロンプトに追記する
- 静的なツール定義の肥大化：95%の場面で不要なJSON APIスキーマをすべてのリクエストに含める
- 無圧縮RAGコンテキスト：ベクトルDBから生のPDF/HTMLテキスト数千行をそのまま注入する
- モデル選択の画一化：JSON整形や意図分類のような単純タスクに数百億パラメータのフロンティアモデルを使う
放置すれば、認知推論のCOGS（売上原価）が顧客LTVや業務効率化の利益を超え、エージェント事業そのものが財務的に成立しなくなる。これが記事の出発点だ。
設計哲学：「LLM-as-a-CPU」
記事の核心にある概念が LLM-as-a-CPU だ。LLMを「人間の思考に近い何か」として扱うのをやめ、CPUやメモリ制約のあるシリコンの計算ユニットとして設計に組み込む、という思想転換を求める。
OSの概念をGenAIアーキテクチャにマッピングすると次のようになる：
| OS概念 | GenAI対応 |
|---|---|
| RAM | コンテキストウィンドウ |
| メモリリーク | 未圧縮のチャット履歴・静的ツール定義 |
| 仮想メモリ | Dynamic Context Paging |
| プロセスの優先度 | モデルカスケーディング |
このフレームワークに沿って、記事は3つのアーキテクチャパターンを提示する。
3本柱：実装レベルの解説
Pillar I：Dynamic Context Paging（動的コンテキストページング）
モノリシックなシステムプロンプトに全ツール定義を詰め込む代わりに、現在のサブタスクに必要なスキル定義だけをオンデマンドでロードし、完了後に破棄する設計だ。
実装上の具体的なステップは：
- SOPをYAMLメタデータ付きのMarkdownファイル（
SKILL.md）に分割し、バージョン管理する - Model Context Protocol（MCP）サーバー経由でツールスキーマをLazy Loadし、必要なドメインのみプロンプトに注入する
- 中間実行結果を永続ステートに追記する前に要約し、トークンの指数的増加を防ぐ
Pillar II：セマンティックゲートウェイ
クライアントアプリとモデルの間にプロキシとして介在するAPI Gatewayを置く。主な機能は3つ：
セマンティックベクトルキャッシュ：受信プロンプトをベクトル埋め込みに変換し、過去クエリとのコサイン類似度が閾値（0.92〜0.96）を超えたら0トークンコストでキャッシュ済み回答を返す。記事によれば、反復的なエンタープライズワークフローの**25〜40%**がこれで処理できるという。
Google Cloud Vertex AIのコンテキストキャッシュ：コードベースのAST、法的コンプライアンスガイドライン、エンタープライズスキーマなど高頻度参照データを明示的キャッシュとしてアップロードし、以降はキャッシュIDを参照するだけにする。入力トークンコストを75〜90%削減できるとしている。Geminiモデルでは暗黙的キャッシュも自動で有効になり、コード変更なしで頻出プレフィックスパターンのKVアテンション再計算が省略される。
プログラマティックなプロンプト圧縮：会話のフィラー、冗長なメタデータ、定型フォーマットを剥ぎ取り、入力トークン量を30〜50%削減する。
Pillar III：モデルカスケーディング（認知ティアリング）
「全リクエストをフロンティアモデルに送る」構成から脱却し、タスクに必要な最小能力のモデルにルーティングする3層構造を採用する：
- Tier 1（決定論的処理）：静的・情報提供系のリクエストをルールエンジンまたはキャッシュで処理
- Tier 2（軽量SLM）：非構造化テキストのJSON変換、パラメータ抽出、短文要約などをGemma 2やGemini 2.0 Flashで処理
- Tier 3（フロンティアモデル）：Tier 2の信頼スコアが0.85を下回るか、複雑なマルチステップ推論が必要な場合のみGeminiなどの大規模モデルにエスカレート
記事が示す目標値は「70/30ルール」：成熟したエンタープライズアプリでは、全推論リクエストの70%以上をTier 1とTier 2で解決し、Tier 3は30%以下に抑えるべきだ、というものだ。
ガバナンス：Prompt GitOpsとCIへのトークン予算組み込み
コードと同様、プロンプトもGitで管理し、CIパイプラインでコスト回帰テストを実施することを記事は強く推奨する。
具体的には、PRマージ時に以下を自動チェックする：
- トークンデルタ分析：PRがベースラインの平均トークン消費量を一定閾値（例：5%）以上増加させた場合、対応する精度向上がなければマージをブロック
- LLM-as-a-Judge回帰テスト：新しいプロンプトがベンチマーク精度をトークン予算内で維持しているか自動検証
「プロンプトをWebコンソールから直接変更してデプロイする」行為は、インフラのIaCを無視した手動サーバー操作と同列に位置づけている。
90日実行ロードマップ
記事は移行のフェーズを具体的に区切っている：
- Days 1–30：既存LLM連携に計測を入れ、「トークンリーク」エンドポイント（1万トークン超の静的プロンプト、無圧縮RAGなど）を特定する
- Days 31–60：AIゲートウェイを全社LLMトラフィックの前段に配置し、セマンティックキャッシュとVertex AIコンテキストキャッシュを有効化する
- Days 61–90：モノリシックプロンプトをSKILL.mdに分割、3層カスケードを実装、CIにトークン予算チェックを組み込む
記事全体を通じて強調されているのは、「モデル精度を最優先」から「認知コンピュートのユニットエコノミクス」への組織的な思考転換だ。マイクロサービスアーキテクチャがCPU・メモリのフットプリントに厳しいガイドラインを設けたように、GenAIシステムにも同様の工学的規律が必要だという主張は、スケールに直面したエンジニアリングチームには刺さる視点だろう。
詳細はBuilding Token-Efficient Agentic Systemsを参照していただきたい。
