{
  "issue": "2026-08-22",
  "generated_at": "2026-08-22T07:00:00+09:00",
  "theme": {
    "title": "プロンプトキャッシュはコスト最適化ではない — 「プレフィックス固定」というアーキテクチャ制約",
    "category": "prompt-caching",
    "lede": "プロンプトキャッシュは長らく「地味なコスト削減の設定項目」として扱われてきたが、エージェントが1タスクで数十回の LLM 呼び出しを重ねる今、話は変わった。Anthropic は キャッシュ読み込みを通常入力の10分の1、DeepSeek は128Kトークンのプロンプトで初回応答を13秒から500msに短縮できると公言する。差が大きすぎて「キャッシュを効かせられる設計かどうか」がエージェントのレイテンシとコストの上限を決める構造的制約になった。プレフィックス完全一致というキャッシュの仕組み上、この制約はプロンプト文面だけでなくツール順序や履歴の圧縮方法にまで及ぶ。",
    "tldr": [
      "キャッシュ命中率はもはや副次指標ではなく、Manus はこれを「本番エージェントで最重要のメトリック」と明言している。",
      "ProjectDiscovery は動的な情報をシステムプロンプトの先頭から末尾のユーザーメッセージへ移すだけで命中率を7%から84%に引き上げ、LLM コストを最大70%削減した。",
      "キャッシュはトークン列の完全プレフィックス一致で決まるため、ツールの並び順や履歴圧縮の実装まで「キャッシュを壊さない設計」に揃える必要がある。"
    ],
    "sections": [
      {
        "heading": "キャッシュ命中率が最重要指標になった理由",
        "body_html": "<p>プロンプトキャッシュは、同一のトークン列（プレフィックス）を再送すると、その部分の推論をモデル側が再利用し、料金と待ち時間を大きく下げる仕組みだ。Anthropic はキャッシュ読み込みを通常入力の10分の1の価格に設定し、DeepSeek は自動ディスクキャッシュにより <code>128K</code> トークン規模のプロンプトで初回トークンまでの時間を13秒から500ミリ秒へ短縮できるとしている。エージェントは1タスクで同じシステムプロンプトとツール定義を何十回も再送するため、この差はプロダクト全体のレイテンシとコスト構造を決めてしまう。</p><p>ただしキャッシュは「トークン列が0文字目から完全一致した範囲」にしか効かない。途中で1トークンでも変わればそこから後ろは全て再計算になる。Manus はこの性質を踏まえ、入力対出力のトークン比が平均100対1というエージェント特有の負荷構造の中で、キャッシュ命中率を「本番段階のAIエージェントにおいて最も重要な単一指標」と位置づけている。ツールの利用可否をコンテキストに追加・削除で表現せず、<code>logit masking</code>（デコード時に特定トークンを選択不可にする処理）で切り替えるのも、コンテキスト本文を変えずにプレフィックスを保つための工夫だ。</p>",
        "examples": [
          {
            "product": "Manus（AIエージェントプラットフォーム、公式ブログ）",
            "approach": "ツールの利用可否をコンテキストへの追加・削除ではなく logit masking で制御し、KVキャッシュのプレフィックスを崩さない",
            "detail": "入力:出力トークン比が100:1という自社の負荷実測をもとに、キャッシュ命中率を本番エージェントの最重要指標と明言した一次情報",
            "source_url": "https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus"
          },
          {
            "product": "DeepSeek API（Context Caching on Disk）",
            "approach": "コード変更不要の自動ディスクキャッシュで、頻出プレフィックスを検出して再利用する",
            "detail": "128Kトークンのプロンプトで初回応答が13秒→500msに短縮、キャッシュ命中時の単価は10分の1という具体的な公式実測値を提示",
            "source_url": "https://api-docs.deepseek.com/news/news0802/"
          }
        ],
        "takeaway": "エージェントのレイテンシ改善はモデル選定より先に、まずキャッシュ命中率を測ることから始めるべき判断基準になる。"
      },
      {
        "heading": "動的な情報を「末尾」に逃がす設計",
        "body_html": "<p>キャッシュはプレフィックスの先頭から効くため、システムプロンプトの冒頭付近に1バイトでも変動する値（現在時刻、ユーザーごとの状態など）を置くと、後続の全トークンでキャッシュが不成立になる。セキュリティ診断エージェント Neo を運用する ProjectDiscovery は、稼働中のタスク状態やスキルコンテキストといった動的情報をシステムプロンプトの先頭から、会話の末尾に付け足す1本のユーザーメッセージ（<code>&lt;system-reminder&gt;</code> タグで囲む）に移設した。</p><p>加えて、静的なツール定義をアルファベット順に固定してキャッシュチェーンを揃える、実際の値の代わりに <code>[provided in Runtime Context]</code> のようなプレースホルダをテンプレートに描画する、日時を秒単位でなく日付単位に丸めるといった細かい積み上げで、システムプロンプト自体をユーザー間・タスク間で「バイト単位で同一」に保っている。1つの構造変更だけで命中率が跳ね上がった事実は、キャッシュ最適化がプロンプトの言い回しではなく配置順の問題であることを示している。</p>",
        "examples": [
          {
            "product": "ProjectDiscovery Neo（自律型セキュリティ診断エージェント、公式ブログ）",
            "approach": "動的なランタイム情報をシステムプロンプト先頭から会話末尾のユーザーメッセージへ移設し、3つのキャッシュブレークポイント（システムプロンプト・ツール定義・直近の会話ウィンドウ）を明示管理する",
            "detail": "この1点の変更だけでキャッシュ命中率が7%→74%に跳ね上がり、その後の周辺最適化で84%・LLMコスト最大70%削減まで到達したという公式の実測推移",
            "source_url": "https://projectdiscovery.io/blog/how-we-cut-llm-cost-with-prompt-caching"
          }
        ],
        "takeaway": "システムプロンプトを書くときは「毎回変わる値をどこに置くか」を最初に決める。先頭ではなく必ず末尾に寄せる。"
      },
      {
        "heading": "ツール順序と履歴圧縮も「キャッシュを壊さない実装」に揃える",
        "body_html": "<p>MCP（Model Context Protocol）の仕様はツール一覧の返却順を保証しないため、ページネーションやサーバー実装の違いでターンごとに順序が変わると、そのたびにツール定義ブロックからキャッシュが壊れる。387kスター超のオープンソースAIアシスタント基盤 OpenClaw では、これを防ぐために MCP ツール一覧をターンをまたいで名前順にソートしてから API リクエストへ渡す修正が取り込まれた。</p><p>履歴圧縮（compaction）の実装でも同じ制約が効く。直感的には古い会話から削るのが自然だが、それでは会話の先頭付近（プレフィックス）が変わってしまい、そこから後ろのキャッシュが総崩れになる。OpenClaw は逆に「直近のツール実行結果から先に圧縮する」方式へ変更し、画像など大きなコンテンツの履歴からの削除も可能な限り遅延させることで、プレフィックスを長く保つ実装にしている。</p>",
        "examples": [
          {
            "product": "OpenClaw（オープンソースAIアシスタント基盤、GitHub PR）",
            "approach": "MCPツール一覧をターン間で名前順に固定ソートし、キャッシュ対象のプレフィックスを安定させる",
            "detail": "MCP仕様がlistTools()の順序を保証しないことに起因するキャッシュ崩れを、実際のマージ済みPRとして修正した一次情報（bcherny によるPR #58037）",
            "source_url": "https://github.com/openclaw/openclaw/pull/58037"
          },
          {
            "product": "OpenClaw（履歴圧縮ロジックのPR）",
            "approach": "履歴圧縮を「古い会話から」ではなく「直近のツール実行結果から」削る順序に変更し、プレフィックスを保持する",
            "detail": "直感に反する削除順序の変更を、キャッシュ崩れ対策として明記したマージ済みPR（#58036）",
            "source_url": "https://github.com/openclaw/openclaw/pull/58036"
          }
        ],
        "takeaway": "履歴圧縮やツール一覧生成のロジックを書くときは、常に「プレフィックスの何文字目から変わるか」を先に確認する。末尾から削る・順序を固定するが基本形になる。"
      }
    ]
  },
  "editorial": "プロンプトキャッシュの話が面白いのは、最適化の主戦場がプロンプト文面そのものではなく「何をどこに置くか」という配置の問題に移っている点だ。モデルの賢さや文章の巧拙とは別の軸で、レイテンシとコストの上限が決まってしまう。エージェント基盤を選ぶ・作る際は、まずキャッシュ命中率をダッシュボードに出すところから始めるのが早道だろう。",
  "quick_picks": [
    {
      "title": "Prompt Caching as a First-Class Constraint in Harness Engineering",
      "summary": "プロンプトキャッシュをエージェント基盤（ハーネス）設計の必須制約として扱うべき理由を、複数社の実装差分から整理した論考。本稿で扱った「配置順の設計問題」という視点の元ネタの一つ。",
      "url": "https://yage.ai/share/prompt-caching-harness-constraint-en-20260404.html"
    },
    {
      "title": "Context Engineering: A Practical Guide for AI Agents",
      "summary": "大規模コードベース向けのコンテキスト設計を扱うSourcegraphの解説記事で、ベクトル検索だけでは足りない構造的コンテキストの必要性を論じる。キャッシュ設計とは別軸だが、同じ「エージェントに何を・どう見せるか」という設計問題を扱う関連テーマ。",
      "url": "https://sourcegraph.com/blog/context-engineering"
    },
    {
      "title": "DeepSeek API introduces Context Caching on Disk, cutting prices by an order of magnitude",
      "summary": "DeepSeekが自動ディスクキャッシュ機能を発表した公式アナウンス。本稿セクション1で扱った「13秒→500ms」「単価10分の1」という数値の一次ソース。",
      "url": "https://api-docs.deepseek.com/news/news0802/"
    }
  ]
}