コンテキストとプロンプトキャッシュ

Claude Code のコンテキストウィンドウには、あなたの指示、Claude が読んだファイル、Claude の応答、そして端末には出ない内容までが入ります。このページでは、何がいつ入るか、圧縮（compaction）で何が残るか、プロンプトキャッシュ（prompt caching）がどの操作で無効になるかを説明します。

• 起動直後、最初のプロンプトを打つ前から、CLAUDE.md・自動メモリ・MCP ツール名・スキルの説明などが入っている
• ファイルを1つ読むたびにコンテキストは増える。調査はサブエージェントに任せると、読んだ中身が自分の側に入らない
• 圧縮後に残るもの・読み直されるもの・消えるものは、読み込み方で決まる
• キャッシュは先頭からの完全一致で効く。モデルの切り替えや MCP ツール定義の変更は、次のターンが遅く高くなる
• 手元の状況は /context で見られる

起動時に入るもの#

最初のプロンプトの前に、次のものが自動で入ります（トークン数は公式の説明図では例示値で、実際は CLAUDE.md の大きさや MCP サーバーによって変わります）。

• MCP のスキーマの読み込み方は ENABLE_TOOL_SEARCH で変えられる。auto はコンテキストの 10% に収まるときに先に読み込み、false はすべて読み込む
• AGENTS.md も、単独または CLAUDE.md と一緒に読み込まれることがある
• 出力スタイルや --append-system-prompt のテキストも、ここに加わる

作業中に増えるもの#

• ファイルの読み取りがコンテキストの大半を占める。「auth.ts のバグを直して」のように範囲を絞ると、読むファイルが減る
• paths: を持つルールは、一致するファイルを Claude が読んだときに自動で入る。端末には「Loaded …」の1行しか出ず、ルールの中身は出ない
• PostToolUse フックの出力は、hookSpecificOutput.additionalContext で返した分だけ Claude に届く。終了コード 0 の標準出力はデバッグログにだけ書かれる。終了コード 2 は stderr をエラーとして Claude に見せるが、ツールは実行済みなので止められない。出力が 10,000 文字を超えると、ファイルに保存されてプレビューとパスだけが渡される。詳しくはフックのリファレンス
• !git status のようにシェルコマンドを ! 付きで実行すると、コマンドと出力があなたのメッセージの一部として入る
• disable-model-invocation: true のスキルは、/名前 で呼ぶまでコンテキストを使わない。コミットやデプロイなど副作用のあるスキルに向く
• サブエージェントは別のコンテキストウィンドウで動く。CLAUDE.md と同じ MCP・スキルを読むが、会話履歴と親の自動メモリは引き継がない。親に返るのは最終の応答と、トークン数・所要時間の小さな付記だけ。組み込みの Explore と Plan は CLAUDE.md を読まず、小さいコンテキストで動く。詳しくはサブエージェント

圧縮で何が残るか#

長いセッションが圧縮されると、会話履歴が要約に置き換わります。v2.1.198 以降、要約の依頼はセッションの拡張思考（extended thinking）の設定を引き継ぎます。思考が有効なら思考ありで要約し、無効なら無しです。セッションの設定自体は変わりません。

• 読み直すファイルが 5,000 トークンを超える場合は、中身なしのパス参照として戻り、Read ではなく Referenced file と表示される
• paths: 付きのルールとネストした CLAUDE.md は、会話履歴の中に読み込まれるので、圧縮で要約に消える。圧縮をまたいで効かせたいルールは、paths: を外すか、ルート直下の CLAUDE.md へ移す
• 大きなスキルは上限で切られ、先頭が残る。大事な指示は SKILL.md の上のほうに置く
• スキルの説明一覧は圧縮後には再注入されない。呼び出したスキルだけが残る

コンテキストがいっぱいになったら#

上限が近づくと自動で圧縮されるので、満杯でセッションが終わることはありません。先に自分で手を打つ方法は次のとおりです。

• 1M トークンのウィンドウは、Fable 系・Sonnet 5 以降・Opus 4.6 以降・Sonnet 4.6 が対応する。Sonnet 5.5 と Sonnet 5 は最初から 1M で動き、選べる [1m] 版はない。圧縮の仕組みは大きい上限でも同じ
• 自動圧縮が走る位置はモデルと設定で変わる。モデルごとの境界、ゲートウェイや独自モデル ID でウィンドウの想定が違うときの補正はモデル・effort・fast modeを参照

自分のセッションの実際の使用量は /context で見られます。カテゴリ別の内訳と最適化の提案が出て、どの CLAUDE.md と自動メモリが読み込まれたかも分かります。それらを開いて編集するには /memory を使います。

プロンプトキャッシュの仕組み#

Claude Code はメッセージを送るたびに新しい API リクエストを作り、システムプロンプト・プロジェクトのコンテキスト・過去の全メッセージとツール結果・新しいメッセージをまとめて再送します。API は、リクエストの先頭（プレフィックス）が最近処理した内容と一致する部分をキャッシュから読み、変わった部分だけを処理します。一致は完全一致で、プレフィックスのどこかが変わると、それ以降はすべて再計算されます。ファイル単位・区間単位のキャッシュはありません。

変わりにくいものほど前に並べてあります。

会話の層の変化はシステムプロンプトとプロジェクトのコンテキストのキャッシュを壊しません。システムプロンプトが変わると全体が無効になります。表に出ない設定として次の2つも影響します。

• モデル：モデルごとにキャッシュが別。切り替えると中身が同じでも全体を再計算する
• effort：多くのモデルでは effort の段階ごとにキャッシュが別。ただし Opus 5.5・Sonnet 5.5・Fable 5.1 を API キーか Claude サブスクリプションで使う場合は、既定でキャッシュが残る

キャッシュの置き場所#

キャッシュはモデルを動かしているサーバー側にあります。

• API キー・Claude サブスクリプション・Claude Platform on AWS：Anthropic の基盤
• Amazon Bedrock と Google Cloud の Agent Platform：クラウドプロバイダーの基盤
• Microsoft Foundry：デプロイのホスティング方式による（Azure 上なら Azure、Anthropic 上なら Anthropic の基盤）
• 独自の ANTHROPIC_BASE_URL や LLM ゲートウェイ：転送先にある。キャッシュが効くかはゲートウェイ次第

ゲートウェイや独自の ANTHROPIC_BASE_URL を経由するとき、cache_control マーカーの扱いで結果が変わります。

• そのまま転送する：プロバイダーの直接のエンドポイントと同じようにキャッシュされる
• マーカーを名指しした 400 エラーで拒否する：Claude Code はマーカーをシステムの該当ブロックから外し、最後の会話メッセージに付け替えて再送し、その会話の間そのままにする。そのブロックは未キャッシュの入力として課金され、会話はキャッシュされる
• マーカーを消して成功を返す：会話履歴の全体が毎ターン未キャッシュの入力として課金される。ブロック形式のシステム内容を文字列に変換するゲートウェイも、同じ形でマーカーを落とす

ファイル変更の通知など、会話の途中で足すシステムコンテキストのブロックは、CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS を設定しない限り、どのプロバイダー・接続でもキャッシュ対象に印が付きます。設定すると、このブロックは未キャッシュで送られます。

キャッシュを無効にする操作#

次の操作では、次のリクエストでキャッシュの一部または全部が外れます。遅くて高いターンが1回出て、その後は新しいプレフィックスがキャッシュされます。

モデルの切り替え#

/model で切り替えると、次のリクエストは会話履歴の全体をキャッシュなしで読みます。

• 端末で /model を実行すると、キャッシュがまだ温かく、新しいモデルが直前の応答を出したモデルではないときだけ、確認が入る。キャッシュが温かいのは、このセッションで最後にリクエストを送った時点か Claude が最後に応答した時点から、キャッシュの TTL 1回分の間。過ぎていれば確認なしで切り替わる。v2.1.238 より前は TTL を見ず、期限切れでも確認が入った
• PreModelSwitch フックで、確認を必須にしたり省いたりできる。詳しくはフックのリファレンス
• opusplan はプランモードで Opus、実行中は Sonnet になるので、プランモードの切り替えのたびにモデルが替わり、キャッシュが作り直される
• Fable 系・Opus 5.5・Sonnet 5.5・Opus 5 の自動モデルフォールバックもモデルの切り替え。安全性の分類器が、フォールバック先のあるカテゴリで要求にフラグを立てると、そのモデルでやり直し、セッションもそこで続く
• スキルやコマンドの frontmatter の model が現在のモデルと違うと、そのターンはモデルの切り替えになる。セッションのモデルは次のプロンプトで戻る。context: fork のスキルは、分岐したサブエージェントのモデルを設定する

effort の変更#

多くのモデルでは、セッション中に effort を変えると、次のリクエストが会話履歴の全体をキャッシュなしで読みます。キャッシュが温かいうちは、変更の前に確認が入ります。

Opus 5.5・Sonnet 5.5・Fable 5.1 を API キーか Claude サブスクリプションで使う場合は、キャッシュが残り、確認なしで新しい段階に切り替わります。次の場合は当てはまりません。

• Amazon Bedrock・Google Cloud の Agent Platform・Claude apps gateway
• CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS を設定している
• 組織に HIPAA の構成がある

v2.1.260 より前は、Fable 5.1 を API キーか Claude サブスクリプションで使う場合も、effort の変更でキャッシュが無効になっていました。段階の一覧はモデル・effort・fast modeにあります。

fast mode をオンにする#

fast mode をオンにすると、キャッシュキーに含まれるリクエストヘッダーが付くので、オン後の最初のリクエストはキャッシュなしで履歴の全体を読みます。

• ヘッダーはターンの開始時に1度設定され、そのターンの間保たれる。Claude の作業中にオンにすると、キャッシュミスは次のターンの最初のリクエストで起きる
• そのぶんの未キャッシュ入力は fast mode の料金で課金される。セッションの始めにオンにするほうが、長いセッションの深いところでオンにするより安い
• 今のモデルが fast mode 非対応だと、オンにするとモデルも切り替わり、それ自体で次のリクエストからキャッシュが作り直される
• コストは会話ごとに1回だけ。最初の fast mode のターンの後は、Claude Code はヘッダーを送り続け、キャッシュキーに入らない速度の設定だけを変える。オフにする・レート制限で標準速度へ自動で戻る・後でオンに戻す、のどれでもキャッシュは残る。使用クレジットが切れて標準速度で再試行する場合も同じ
• /clear と /compact はこれをリセットする（その時点でキャッシュを作り直すため）

fast mode の詳細はモデル・effort・fast modeを参照してください。

MCP サーバーの接続と削除#

ツール定義はシステムプロンプトの層にあるので、リクエスト内のツール定義の集合がターン間で変わるとキャッシュが無効になります。/advisor の切り替えは例外で、その定義はキャッシュの区切りより後ろにあり、キャッシュされたプレフィックスは保たれます。MCP サーバーの変更がどうなるかは、tool search がセッションの MCP ツールを遅延させるかで決まります（対応モデルでの既定）。

• ツールが遅延されている：会話の最初のリクエストのツール一覧を会話の間ずっと保つので、サーバーの接続や切断は、すでにキャッシュされた部分に影響しない。最初のリクエストの後に接続を終えたサーバーのツールは、遅延の定義として届き、Claude が必要なときに読み込む
• ツールを先に読み込んでいる：定義が増えるとキャッシュが無効になり、意図して削除したときも同じ。tool search が auto のしきい値未満・無効・使えないときに当てはまる。たとえば Google Cloud の Agent Platform で Claude 4.5 世代より前のモデル、独自の ANTHROPIC_BASE_URL のゲートウェイ、Azure 上のデプロイで tool search を拒否されたと Claude Code が判断した Microsoft Foundry など

tool search が効かない場合、セッション中のサーバーの変化とキャッシュの関係は次のとおりです。

• ツールがプレフィックスに入る会話を再開するとき、最初のリクエストの時点で MCP サーバーがまだ接続中のことがある。記録にそのサーバーのツール定義があれば、記録どおりに含めるので、同じツールで接続が終わってもリクエストは変わらない
• MCP の設定ファイルを編集しただけではキャッシュは変わらない。新しい設定は再起動で効き、そのときサーバーが接続・切断される

プラグインの有効化・無効化#

プラグインを有効・無効にしたときのコストは、プラグインが提供するコンポーネントの種類で決まります。

• スキル・コマンド・エージェント・フック・モニター・テーマ：キャッシュを無効にしない。内容は既存の会話の後ろに足され、次のリクエストはその内容のぶんだけを払い、手前はキャッシュから読む
• MCP サーバーを提供するプラグイン：上の MCP サーバーの接続と削除と同じ規則に従う
• コードインテリジェンスのプラグイン：有効にすると Claude が LSP ツールを使えるようになる

/plugin メニューでの変更は、メニューを閉じるときに Claude Code が実行する /reload-plugins を通ります。変更が適用された最初のターンで、追記の告知か全体の読み直しのコストを払います。Claude Code が自分で適用する場合もあります。

• command ソースのプラグインは、Claude Code が自分で再読み込みできる
• /plugin のインターフェースからインストールすると、インストール中に有効化できることがある。結果はインストール後の要約に出る
• /cd でセッションを移すと（v2.1.246 以降）、新しいディレクトリの設定が有効にするプラグインが移動の一部として適用される。/reload-plugins を止める全体読み直しの警告は出ない
• --plugin-dir で渡したプラグインのフォルダの追加・削除は、対話セッションなら即座に適用される（v2.1.265 以降）。全体の読み直しになる場合は、適用を保留して /reload-plugins を促す通知を出す

/reload-plugins の結果が全体の読み直しになるときは、警告を出して適用しません。それでも適用するなら /reload-plugins --force を実行します。対話端末のないセッション（デスクトップアプリ・Agent SDK・-p の非対話モード）でも、セッションに直接入力すれば /reload-plugins が走ります（v2.1.260 以降）。そこでは MCP サーバー以外が適用され、MCP サーバーの変更は次のセッションで効くので、途中で全体の読み直しは起きません。

セッション中に有効にしたプラグインを同じセッションで無効に戻すと、以前のリクエストの形に戻ります。そのプレフィックスがまだキャッシュの有効期間内なら、次のリクエストは古いキャッシュを読み、作り直しません。

ツール全体を拒否する#

Bash や WebFetch のようなツール名だけの拒否ルールを足すと、次のリクエストから Claude はそのツールを呼べません。/permissions で足しても、設定ファイルを直接編集しても同じで、ターンの途中に /permissions で足した場合も含みます。

• tool search が有効（対応モデルの既定）なら、リクエストのツール定義は変わらず、キャッシュも残る
• tool search が使えない・無効なら、次のリクエストから定義が外れてキャッシュが無効になり、後でルールを外したときも同じ
• この形でツールを塞ぐのは、ツール名の位置で一致する拒否ルールだけ。ツール名だけ・同等の Bash(*)・"*" のようなツール名のグロブがそれにあたり、MCP ツールだけに一致する "mcp__*" も同様。Bash(rm *) のような範囲を絞った拒否や、許可・確認のルールは Claude に見えるツールを変えない。呼び出しの試行時に検査されるので、プレフィックスは保たれる

ルールの書き方は権限ルールを参照してください。

会話の圧縮#

圧縮は会話履歴を要約に置き換えるので、設計上、会話の層が無効になります。次のリクエストの履歴は新しく短くなり、古い履歴とプレフィックスを共有しないためです。

• システムプロンプトの層は再利用される。ただし、変わっていたはずのシステムプロンプトを保ったまま再開した会話では、最初の圧縮で現在のプロンプトへ切り替わり、その層が1回作り直される
• プロジェクトのコンテキストはディスクから読み直す。CLAUDE.md とメモリがセッション開始時から変わっていなければ、キャッシュにヒットする
• 要約には、会話と同じシステムプロンプト・ツール・履歴に要約の指示を最後のユーザーメッセージとして足した別のリクエストを送る。キャッシュが温かいうちは、このリクエストがプレフィックスをキャッシュから読むので、途中の /compact はコンテキストの大きさから想像するよりずっと安く、時間の大半は要約の生成にかかる
• キャッシュの有効期間を超えて空いた後は、読めるキャッシュがなく、要約のリクエストが履歴の全体を未キャッシュで処理する。古いセッションを再開した直後の /compact が最も高い理由はこれ
• 圧縮の次のターンは、短い要約のぶんだけ会話のキャッシュを作るので、遅くない

画像の蓄積#

API は 1 リクエストに載せられる画像と PDF の数に上限があり、Claude Code は画像と PDF の合計サイズにも上限を設けています。大きなスクリーンショットは、小さいものより少ない枚数で上限に達します。

• 次のリクエストが上限を超えそうなとき、Claude Code は古い画像と PDF をまとめて取り除いて送る。取り除いたぶん、しばらく余裕ができる
• 取り除かれた画像は Claude にはもう見えない。必要なら共有し直す
• 画像を含んでいたメッセージが変わるので、その中で最も早いメッセージから先を再処理する。まとめて取り除くので、遅いターンはスクリーンショットごとではなく、1回のまとまりごとに1回出る

Claude Code のアップグレード#

新しいバージョンはたいていシステムプロンプトやツール定義を更新するので、アップグレード後に始める最初の会話は、先頭からキャッシュを作ります。自動更新は裏でダウンロードしますが、適用は次の起動で、セッションの途中では行いません。アップグレードを適用するタイミングを自分で決めるには DISABLE_AUTOUPDATER=1 を設定します。アップグレード前に始めた会話を再開するコストは、後の「セッションの再開」を参照してください。

キャッシュを保つ操作#

次の操作は会話の末尾への追記か、リクエストに触れないもので、キャッシュは残ります。

• サブディレクトリの CLAUDE.md と paths: 付きのルールは、一致するファイルを最初に読むときに読み込まれる。読み込み前の編集は効くが、読み込み後は会話履歴の一部になるので、途中の編集は過去に遡って効かない
• 権限モードは権限モード、出力スタイルは出力スタイル、スキルはスキルを参照

セッションの再開#

セッションを再開すると、Claude Code は会話の全体を再送し、プレフィックスのうち変わっておらず有効期間内の部分がキャッシュから読まれます。システムプロンプトは、Claude Code のアップグレード後や、再開時の --append-system-prompt のテキストが違うと変わりうるものです。既定では再開した会話は、始まったときのシステムプロンプトを保ち、履歴は同じプロンプトの後ろに残ります。変更は、会話を圧縮したとき、または新しい会話で効きます。リクエストごとにプロンプトを作り直す場合はCLI のコマンドとフラグの「システムプロンプトのフラグ」を見てください。

キャッシュの有効期間（TTL）#

キャッシュされたプレフィックスは、しばらく使われないと期限切れになります。キャッシュにヒットするリクエストのたびにタイマーが戻るので、作業を続けている間は温かいままです。長く空くと、次のリクエストは入力を全部計算し直してキャッシュを作り直します。席を外した後の最初のターンが遅いのはこのためです。

Pro か Max プランで大きなセッションを長い休みの後に再開するときは、Claude Code が要約からの再開を提案します。

API は 2 種類の TTL を用意しています。5 分と 1 時間です。1 時間は長い休みを越えて温かく保てますが、キャッシュの書き込みが高い料金になります。放置してから戻る使い方には効きますが、5 分以上空かない短い作業の連続では、高い書き込み料金だけがかかり、長い寿命が活きません。

どのリクエストにどの TTL が付くか#

Claude Code はリクエストごとに TTL を決め、リクエストは次の2つのバケットのどちらかに入ります。

• メインの会話：対話のターン・非対話の -p・Agent SDK のターン、それらと一緒に走る補助処理
• それ以外：サブエージェント・ワークフロー・プロセス内のチームメイト・fork・圧縮・セッションタイトルなど、会話の外のリクエスト

自分で TTL を選ばない限り、Claude Code が 1 時間を要求するのは、プランの含まれる利用枠の範囲内の Claude サブスクリプションだけです。そこではメインの会話と、Anthropic がサーバー側で制御する少数の補助リクエストに 1 時間を要求します。

プランの利用上限を超えて使用クレジットを使い始めると、その利用は課金されるので、メインの会話は安い 5 分に下がります。そこで 1 時間を保つには、自分で TTL を選びます。

TTL を自分で選ぶ#

どちらのバケットにも設定できます。値は 5m か 1h で、それ以外は無視されます。いずれの設定と環境変数も v2.1.242 以降が必要です。

API キーでサインインしている場合やクラウドプロバイダーを使う場合に、メインの会話を 1 時間にするには promptCacheTtl を 1h にします。会話の外のリクエストは、そのバケットの TTL を選ぶまで 5 分のままです。

複数の制御が当てはまるときは、次の順で最初に一致したものが使われます。

1. FORCE_PROMPT_CACHING_5M=1（両方のバケットを 5 分に強制する）
2. そのバケットの環境変数
3. そのバケットの設定キー
4. サブエージェントのリクエストについて、サブエージェントの experimental frontmatter フィールドの cacheTtl の値（v2.1.248 以降。Claude サブスクリプションが使用クレジットを使っている間は、1h が無視される）
5. ENABLE_PROMPT_CACHING_1H=1（両方のバケットで 1 時間を要求する）
6. リクエストのバケットの既定

FORCE_PROMPT_CACHING_5M=1 は、キャッシュの挙動のデバッグ、2 つの TTL の比較、管理設定で指定された長い TTL の上書きに使います。

メインの会話のキャッシュ書き込みがどの TTL だったかは、claude -p "hello" --output-format json を実行し、結果の usage.cache_creation で確認できます。1 時間の書き込みは ephemeral_1h_input_tokens、5 分の書き込みは ephemeral_5m_input_tokens に出ます。

キャッシュの範囲#

Claude Code のキャッシュは、実質的に 1 台のマシンと 1 つのディレクトリに閉じます。システムプロンプトに自動メモリのパスが入り、会話の冒頭には作業ディレクトリ・プラットフォーム・シェル・OS のバージョンの告知があるためです。別のディレクトリのセッションはプレフィックスが違うので、互いのキャッシュに当たりません。

• 同じディレクトリで並行して動かすセッションは、同じプレフィックスになり、互いのキャッシュを読む
• 順番に動かすセッションがプレフィックスを共有するのは、起動時の git status のスナップショットが一致するときだけ（各会話にそのスナップショットのブランチと最近のコミットが載るため）
• API 側のキャッシュは、もっと広い。組織間では分離され、プロバイダーによっては組織内のワークスペース間でも分離される。その境界の中では、同じモデルと同じプレフィックスのリクエストは同じキャッシュを読む。Agent SDK で自動処理の群れを動かす場合は、自動メモリの場所をシステムプロンプトの外へ移し、ユーザーやマシンをまたいでシステムプロンプトのキャッシュを共有する方法がある。詳しくはSDK のツール・権限・拡張を見てください

キャッシュの状態を確かめる#

API はすべての応答で 2 つのトークン数を返します。ライブで見るには、current_usage オブジェクトを読むステータスラインのスクリプトが最も直接的です。

読み取りが書き込みに比べて多ければ、うまく効いています。書き込みが毎ターン多いままなら、プレフィックスの何かが変わり続けています。上の「キャッシュを無効にする操作」が、よくある原因の一覧です。

• セッションごとの要約は /usage。メインの会話の最初の応答の後、Session ブロックに Prompt cache (main) の行が加わり、セッションのヒット率・ミスの回数・今キャッシュが温かいかを示す。ステータスラインのスクリプトは prompt_cache オブジェクトで同じ数字を読める。どちらも v2.1.251 以降が必要
• Prompt cache (main) の行は、特定できるときは直近のミスの原因も示す（例：likely cause: tool definitions changed）。この表示は v2.1.260 以降が必要
• 組織全体では、OpenTelemetry のエクスポーターがユーザーとセッションごとにキャッシュの読み取りと書き込みのトークンを報告する。詳しくは利用状況の計測

サブエージェントとキャッシュ#

サブエージェントは、親とは別のシステムプロンプトとツールの集合で、自分の会話を始めます。プレフィックスが親と違うので、最初のリクエストは親のキャッシュを読まず、自分のターンを通して自分のキャッシュを温めます。メインの会話のバケットの外なので、サブスクリプションでも 5 分で、長い TTL を選ぶまで変わりません。親のキャッシュには影響せず、親の側から見ればサブエージェントの呼び出しと結果が会話に追記されるだけで、プレフィックスは保たれます。

• fork は、親のシステムプロンプト・ツール・会話履歴をそのまま引き継ぐので、最初のリクエストが親のキャッシュを読む
• /fork で複製したセッション：隔離の指示が、複製した会話の末尾にメッセージとして加わるので、元の会話が作ったキャッシュは残る
• 圧縮：要約の呼び出しは、同じプレフィックスの共有の仕組みを使う
• 再開したサブエージェント：再開した実行の最初のリクエストが、元の実行が温めたキャッシュを読めることがある
• ワークフローの扇状の分岐（同じプレフィックスのエージェントを並べる）：最初の 1 つ以外を既定で最大 5 秒保留し、それらの最初のリクエストが最初のエージェントのキャッシュしたプレフィックスを読めるようにする

関連する機能はエージェントビューとワークフローを参照してください。

プロンプトキャッシュを無効にする#

キャッシュの挙動を特定のモデルやプロバイダーでデバッグするときなど、まれに無効にしたい場面があります。次の環境変数を 1 にします。

• DISABLE_PROMPT_CACHING_HAIKU は、haiku の別名が指す既定の Haiku モデルに効く。そのモデルが動く場所はどこでも無効になり、メインモデルであればメインの会話も含む。メインの会話を含めるには v2.1.283 以降が必要。非推奨の ANTHROPIC_SMALL_FAST_MODEL で指定したバックグラウンドモデルも、メインのモデルと違うときは対象になる
• 別の Haiku のバージョンをメインモデルに固定した場合はキャッシュが残る。無効にするには DISABLE_PROMPT_CACHING を使う
• DISABLE_PROMPT_CACHING_SONNET と DISABLE_PROMPT_CACHING_OPUS は、それぞれ sonnet・opus の別名が指すモデルに効く。ほかの Sonnet や Opus のモデル ID をメインモデルにした場合は、そのモデルはキャッシュが残る。たとえば sonnet が claude-sonnet-5-5 を指しているとき、claude-sonnet-5 のセッションはキャッシュが残る。そのモデルで無効にするには DISABLE_PROMPT_CACHING
• 組織全体の方針にするには、これらや TTL の変数を管理設定の env ブロックに置く