前置きを壊さない（キャッシュ）（Keeping the Prefix Stable）

変わらないものを前に、変わるものを後ろに置く。キャッシュは接頭辞にしか効かないため、失うものの大きさは変更の大きさではなく変更の位置で決まる。

問題

長い会話を続けているのに、前置きがターンごとに作り直される。原因は会話の中身ではなく、前置きを毎ターン触っていることである。ツールを1個足した、命令ファイルを1行直した、モデルを切り替えた — どれも小さな操作だが、位置が前でありさえすれば、その後ろにある長い会話がまるごとキャッシュミスになる。中身は前回と一字も違わないのに再利用は効かず、実効費用だけが上がる（公式、具体例節）。しかも手を入れた本人に、いつ何を壊したのかが見えない。

コンテキスト

適用する条件:

会話が長く、前置きが大きい — システム命令・ツール定義・常駐する命令ファイルが毎リクエストの先頭を占める
同じ前置きで何ターンも回る — 再利用する相手があってはじめてキャッシュは効く
費用が気になる規模である

適用しないケース:

一発で終わる依頼。再利用する相手がいない
前置きが本当に変わるべきとき。誤った命令を、キャッシュを守るために使い続けるのは本末転倒である
何を使うか決まらないまま始める探索的な作業。後述のとおり、公式の第一の推奨（設定を先に固定する）がそもそも守れない

隣接パターンとの境界:

セッション境界の設計 — 正面から緊張する。同パターンは「切らないと壊れる」、本パターンは「切ると作り直しになる」。ただし公式は両方を同時に推奨している（具体例節）
読み捨ての隔離 — 揮発物を別のコンテキストへ追い出すのが同パターン。公式は本パターンの推奨として同パターンを挙げている（具体例節）
常駐物の棚卸し — 前置きの中身を減らすのが同パターン、動かさないのが本パターン。減らす操作それ自体が、一度は前置きを壊す
思考深度をタスクに合わせる — 深度の切り替えは前置きを壊す操作である（具体例節）

解決

なぜ効くのか。キャッシュが接頭辞一致でしか効かないことが全てである。照合されるのは集合ではなく列である — 問われるのは「同じものが入っているか」ではなく「同じ順で、同じ位置にあるか」である。先頭から一致をたどり、最初に食い違ったところで一致は終わる。そこから後ろは、中身が前回と一字も違わなくても、もう再利用されない（公式、具体例節）。

ここから、直感に反する2つが従う。

第一に、小さな変更ほど高くつきうる。命令を1行直す操作それ自体は小さい。しかしその1行が前にあれば、後ろにある長い会話を巻き添えにする。損失は変更の大きさではなく、変更の位置で決まる。 同じ1行でも、末尾で直せばほとんど何も失わない。「小さな変更だから影響も小さいはずだ」という見積もりが、ここでは逆を向く。

第二に、並べ替えは無害ではない。中身が同じでも順が違えば別の列である。何も足さず、何も消していなくても、位置を入れ替えればそこが分岐点になる（公式は「a reordered tool definition」を、キャッシュを壊すものの例として名指ししている。具体例節）。

したがって作法は「変えない」ではない。それは無理である — 命令は直るし、ファイルは添付されるし、ターミナルは出力を吐く。作法は「変わるものを後ろに寄せる」である。変化を止めることはできないが、変化の位置は設計できる。 入力を変化の頻度で並べ替え、動かないものを先頭に、動くものを末尾に置けば、分岐点は必然的に後ろへ下がる。

もう一つ、名前に関わる点がある。前置きが安定しているかどうかは、機構ではなく、こちらの操作の履歴で決まる。 機構は勝手に効く — 効かせるために何かを唱える必要はない。壊すのはこちらである。だから本パターンで言えることは「効かせろ」ではなく「壊すな」であり、壊さないためには、何が壊すのかを知っている必要がある。

トレードオフ

利点

同じ前置きを使い回すぶん、実効費用が下がる。 公式は「Prompt caching lowers the effective cost of a request by reusing tokens from a previous one」と書いている（公式、具体例節）。下がるのは再利用できたトークンのぶんであって、会話の中身ではない — 前置きが大きく、会話が長いほど、安定から得るものが大きい。
前置きが動かないこと自体が、他のパターンの前提になる。 何が効いているかを追うとき、毎ターン前置きが変わっていると、変わったのは命令か、モデルか、ツールかを切り分けられない。安定は、観測の下地でもある。

代償

前置きを固定する圧力が、直すべきものを直しにくくする。 命令の修正も、ツールの整理も、常駐物の棚卸しも、どれも前置きを壊す。キャッシュを守るために誤った命令を残すのは倒錯である。この圧力は本パターンが作り出したものであり、本パターン自身では解けない — 直すべきものは直し、壊れたキャッシュは作り直す、という判断が外から要る。
「設定を先に固定せよ」という要求は、探索的な作業と相性が悪い。 公式の第一の推奨は「Lock in settings before you start」である（公式、具体例節）。何を使うか分かってから始められる仕事なら守れるが、モデルもツールも決まらないまま探り始める仕事では守れない。守れないときに無理に守ると、間違った設定のまま最後まで走ることになる。

GitHub Copilot での具体例

この節の公式引用が語る範囲

以下の原文はすべて VS Code の面についての記述である。本カタログが原文で確認できたのはこの面だけであり、他の面（github.com / Copilot CLI / cloud agent）でのキャッシュの扱いについては確認しておらず、したがって何も主張しない。確認していないことは、無いことではない — ここで言えるのは「この面ではこう書かれている」までである。

機構 — キャッシュは接頭辞にしか効かない

出典: Cache Explorer（取得日: 2026-07-16）公式:

The cache only applies to the matching prefix of a request. As soon as the content of two consecutive requests diverges, everything after that point is a cache miss. Small changes early in the prompt, such as a reordered tool definition or a modified instruction, break the cache for the rest of the request.
〔訳〕キャッシュは、リクエストの一致する接頭辞にのみ適用される。連続する2つのリクエストの内容が食い違うとすぐに、それ以降のすべてがキャッシュミスになる。プロンプトの前のほうにある小さな変更 — 並べ替えられたツール定義や変更された命令など — は、リクエストの残り部分のキャッシュを壊す。

キャッシュが効くのはリクエストの一致する接頭辞（the matching prefix of a request）だけである。連続する2つのリクエストの内容が食い違った時点（diverges）で、それ以降は全部キャッシュミス（everything after that point is a cache miss）になる。そして壊すものとして名指しされているのは「プロンプトの前のほうの小さな変更」（Small changes early in the prompt）であり、例として挙がっているのがツール定義の並べ替え（a reordered tool definition）と命令の変更（a modified instruction）である。「解決」で述べた3点 — 列であること、位置が損失を決めること、並べ替えが無害でないこと — が、この一文にそのまま書かれている。

費用への効果

出典: VS Code — 言語モデル（取得日: 2026-07-16）公式:

Other factors also affect credit consumption, such as thinking effort (higher effort produces more thinking tokens), context window size, and tool usage. Prompt caching lowers the effective cost of a request by reusing tokens from a previous one.
〔訳〕クレジット消費には他の要因も影響する。thinking effort(effort が高いほど thinking tokens が増える)、コンテキストウィンドウのサイズ、ツール使用などである。Prompt caching は、直前のリクエストのトークンを再利用することで、リクエストの実効費用を下げる。

Prompt caching は、直前のリクエストのトークンを再利用することで、リクエストの実効費用を下げる（lowers the effective cost ... by reusing tokens from a previous one）。公式が費用について述べているのはここまでである。 本カタログは削減率も、応答速度への効果も主張しない — 確認できた根拠は、上の機構と、この一文までである。

公式の5つの推奨

Cache Explorer のページは、キャッシュを壊さないための推奨を5つ挙げている公式（出典・取得日は上記と同じ）:

Lock in settings before you start: Switching the model, reasoning effort, context size, or the enabled tools and MCP servers during a session rebuilds the cache. Choose them upfront, or use auto model selection, which switches models only at cache boundaries.
Keep instructions stable: Changing instructions files or custom agent definitions mid-session breaks the cache.
Add volatile context late: Place content that changes often, such as file attachments or terminal output, later in the conversation.
Isolate exploration in subagents: Run research in a subagent to keep the parent session prompt stable.
Start fresh after a break: Caches expire after inactivity. Start a new session or run /compact to rebuild from a short summary instead of the full history.
〔訳〕開始前に設定を固定する(セッション中のモデル・reasoning effort・コンテキストサイズ・有効なツールや MCP サーバーの切り替えはキャッシュを作り直すので、事前に選ぶか、キャッシュの境界でのみモデルを切り替える auto model selection を使う)/命令を安定させたままにする(セッション途中で instructions files やカスタムエージェント定義を変更するとキャッシュが壊れる)/揮発性のコンテキストは後で足す(ファイルの添付やターミナル出力など頻繁に変わる内容は会話の後ろのほうに置く)/探索はサブエージェントに隔離する(親セッションのプロンプトを安定させるため調査はサブエージェントで行う)/休止後は新しく始める(キャッシュは非アクティブが続くと失効するので、/compact を実行するか新規セッションを開始して、全履歴ではなく短い要約から作り直す)、の5点。

3番目の「Add volatile context late」が、本パターン固有の作法である。変わりやすいもの — 添付ファイル、ターミナル出力 — を会話の後ろに置け、と公式が言っている。「解決」の「変わるものを後ろに寄せる」が、そのまま推奨として現れている。

5つのうち4つは、公式が別のパターンを推している（あるいは牽制している）

残る4つは、本カタログが別々に立てているパターンと一対一で対応する。キャッシュという単一の関心から出発した公式の推奨が、本カタログの分類を外側からなぞっている箇所である。

公式の推奨（上記の逐語より）	対応するパターン	向き
Isolate exploration in subagents	読み捨ての隔離	同じ向き — 隔離は親セッションの前置きを安定させる
Start fresh after a break	セッション境界の設計	緊張が解ける — 間が空けば、守るべきキャッシュはもう無い
Lock in settings before you start	思考深度をタスクに合わせる	逆向き — reasoning effort の切り替えが前置きを作り直させる
Keep instructions stable	常駐物の棚卸し	逆向き — 棚卸しは常駐命令を動かす

「Isolate exploration in subagents」〔訳: 探索をサブエージェントに隔離する〕は、隔離とキャッシュの関係の向きを与えている。公式の書き方は「Run research in a subagent to keep the parent session prompt stable」であり、隔離の目的として親セッションの前置きを安定させることが挙がっている。探索を別のコンテキストへ追い出せば、その探索が生む揮発物は親の前置きを触らない。隔離はキャッシュに有利に働く — 両者は競合しない。

「Start fresh after a break」〔訳: 休止の後は新しく始める〕は、本パターンとセッション境界の設計の緊張が解ける箇所である。一見、両者は正面から衝突する — 同パターンは「長い会話は切れ」と言い、本パターンは「切れば前置きを作り直すことになる」と言う。ところが公式は両方を同時に推奨している。理由も原文にある: 「Caches expire after inactivity」。間が空いた時点で、守るべきキャッシュはもう無い。 失うものが無いのだから、そこで切るコストは小さい。さらに原文は /compact を挙げ、作り直すとしても「rebuild from a short summary instead of the full history」— 全履歴からではなく短い要約から、と述べている。

緊張は、条件を見れば解ける。 会話が続いている間はキャッシュを守る価値があり、間が空いた後には無い。「切るか、続けるか」を一般論として争う必要はなかった。

念のため — ここまでの引用は確認できた範囲ではすべて VS Code の面のものである（冒頭の注記のとおり）。他の面（github.com / Copilot CLI / cloud agent）でキャッシュがどう扱われるかは確認しておらず、確認していないことは無いことの証明ではない。ここで言えるのは「この面ではこう書かれている」までである。

別名

呼称	出典
Prompt caching	一次 — VS Code 公式が、直前のリクエストのトークンを再利用して実効費用を下げる機構に与えている名（出典は具体例節）
Prefix match / matching prefix	一次 — 同じく公式が、キャッシュの効く範囲を「リクエストの一致する接頭辞」と規定する。機構ではなく一致の判定方法を指す（出典は具体例節）
前置きを壊さない（キャッシュ）/ Keeping the Prefix Stable	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

公式の Prompt caching は提供側の機構の名である。本パターンはこちら側の作法であり、指しているものが違う。機構の名を実践の名に流用すると、「キャッシュは自動なのだから、こちらは何もしなくてよい」と読める。実際は逆で、何をしたかで壊れる。 名前を否定形にしたのはそのためである — 効かせる方法は無く、壊す方法だけが無数にあるからだ。

前置きを壊さない（キャッシュ）（Keeping the Prefix Stable） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

機構 — キャッシュは接頭辞にしか効かない ​

費用への効果 ​

公式の5つの推奨 ​

5つのうち4つは、公式が別のパターンを推している（あるいは牽制している） ​

別名 ​

関連 ​