2026-08-22 発行（読了 6 分）
実プロダクトのアーキテクチャ・使用例から AI 開発の現在地を週 3 回・1 号 1 テーマで深掘り
プロンプトキャッシュは長らく「地味なコスト削減の設定項目」として扱われてきたが、エージェントが1タスクで数十回の LLM 呼び出しを重ねる今、話は変わった。Anthropic は キャッシュ読み込みを通常入力の10分の1、DeepSeek は128Kトークンのプロンプトで初回応答を13秒から500msに短縮できると公言する。差が大きすぎて「キャッシュを効かせられる設計かどうか」がエージェントのレイテンシとコストの上限を決める構造的制約になった。プレフィックス完全一致というキャッシュの仕組み上、この制約はプロンプト文面だけでなくツール順序や履歴の圧縮方法にまで及ぶ。
プロンプトキャッシュは、同一のトークン列（プレフィックス）を再送すると、その部分の推論をモデル側が再利用し、料金と待ち時間を大きく下げる仕組みだ。Anthropic はキャッシュ読み込みを通常入力の10分の1の価格に設定し、DeepSeek は自動ディスクキャッシュにより 128K トークン規模のプロンプトで初回トークンまでの時間を13秒から500ミリ秒へ短縮できるとしている。エージェントは1タスクで同じシステムプロンプトとツール定義を何十回も再送するため、この差はプロダクト全体のレイテンシとコスト構造を決めてしまう。
ただしキャッシュは「トークン列が0文字目から完全一致した範囲」にしか効かない。途中で1トークンでも変わればそこから後ろは全て再計算になる。Manus はこの性質を踏まえ、入力対出力のトークン比が平均100対1というエージェント特有の負荷構造の中で、キャッシュ命中率を「本番段階のAIエージェントにおいて最も重要な単一指標」と位置づけている。ツールの利用可否をコンテキストに追加・削除で表現せず、logit masking（デコード時に特定トークンを選択不可にする処理）で切り替えるのも、コンテキスト本文を変えずにプレフィックスを保つための工夫だ。
キャッシュはプレフィックスの先頭から効くため、システムプロンプトの冒頭付近に1バイトでも変動する値（現在時刻、ユーザーごとの状態など）を置くと、後続の全トークンでキャッシュが不成立になる。セキュリティ診断エージェント Neo を運用する ProjectDiscovery は、稼働中のタスク状態やスキルコンテキストといった動的情報をシステムプロンプトの先頭から、会話の末尾に付け足す1本のユーザーメッセージ（<system-reminder> タグで囲む）に移設した。
加えて、静的なツール定義をアルファベット順に固定してキャッシュチェーンを揃える、実際の値の代わりに [provided in Runtime Context] のようなプレースホルダをテンプレートに描画する、日時を秒単位でなく日付単位に丸めるといった細かい積み上げで、システムプロンプト自体をユーザー間・タスク間で「バイト単位で同一」に保っている。1つの構造変更だけで命中率が跳ね上がった事実は、キャッシュ最適化がプロンプトの言い回しではなく配置順の問題であることを示している。
MCP（Model Context Protocol）の仕様はツール一覧の返却順を保証しないため、ページネーションやサーバー実装の違いでターンごとに順序が変わると、そのたびにツール定義ブロックからキャッシュが壊れる。387kスター超のオープンソースAIアシスタント基盤 OpenClaw では、これを防ぐために MCP ツール一覧をターンをまたいで名前順にソートしてから API リクエストへ渡す修正が取り込まれた。
履歴圧縮（compaction）の実装でも同じ制約が効く。直感的には古い会話から削るのが自然だが、それでは会話の先頭付近（プレフィックス）が変わってしまい、そこから後ろのキャッシュが総崩れになる。OpenClaw は逆に「直近のツール実行結果から先に圧縮する」方式へ変更し、画像など大きなコンテンツの履歴からの削除も可能な限り遅延させることで、プレフィックスを長く保つ実装にしている。