起動オーバーヘッドが固定的でほとんど削れないなら、プロンプトキャッシングは実際どんな実質的なメリットがあるのですか？
メリットは請求面に集中しており、コンテキスト領域ではない。プロンプトキャッシングは、毎ターン内容が変わらず繰り返し送信される部分（システムプロンプト、CLAUDE.md、ツール定義）を対象とし、それらをキャッシュ可能としてマークすることで、後続のリクエストがキャッシュにヒットした際、その部分の請求で約90%の割引が得られる。ターン数が多く、毎ターン同じ固定内容を再送信する長い対話では、この割引の積み重ねはかなりの規模になる。
しかしここでのバランス感覚が重要だ。キャッシングが下げるのは「これらのトークンにいくら費用がかかるか」であり、「これらのトークンがコンテキストウィンドウのどれだけの空間を占めるか」ではない。200Kのウィンドウ上限は、実際に占有しているトークン数を見ており、請求後の割引価格ではない。だからキャッシュにヒットして請求額が減っても、ウィンドウ内で占めるべき空間は変わらず占め続け、長い対話は依然として圧縮や要約に向かっていく。
接続済みだが今回の対話で実際には使われていないMCPサーバーも、起動オーバーヘッドを引き下げる要因になりますか？
なる。公式ドキュメントとコミュニティの分析はいずれも、接続済みのMCPサーバーはそのセッションで実際に呼び出されなくても、そのツールスキーマがシステムプロンプトに読み込まれ続けることを指摘している——これはClaudeに「このツールは存在し、必要なときに使える」と知らせるためであり、Claudeが適切なタイミングでそのツールを使うべきか判断できるようにするためだ。しかしその代償として、接続済みのサーバー一つひとつが、毎メッセージに小さいが確実に存在する固定オーバーヘッドをもたらす。
実務上の推奨は、自分が搭載しているMCPリストを定期的に見直すことだ。あるサーバーが1週間以上実際に呼び出されていなければ、一旦切断し、必要になったときに再接続する。これは10秒でできる操作でありながら、長期的には継続的な節約効果をもたらす。「将来使うかもしれない」という理由だけで、常時オーバーヘッドを負担させ続ける必要はない。
/context、/memory、/usageの他に、請求が来てから気づくのではなく、もっと早く使用量の異常を発見する方法はありますか？
ある。しかもセッションが終わるまで待つ必要はない。この3つの組み込みコマンドでリアルタイムに確認する以外にも、コミュニティは独立した計測ツールも開発している。例えばcontext-budgetのようなCLIツールは、実際にファイルを対話に読み込む前にワークスペースをスキャンし、各ファイルの個別のトークンコストをリストアップできる。これにより、「このファイルを読み込む」という操作を実行する前に、その代償を先に確認でき、読み込んだ後になってウィンドウの大部分が消費されていたと気づくことを避けられる。
もう一つの実用的な習慣は、段階的にチェックすることだ。セッション開始直後に/contextを一度実行して起動時のベースライン値を記録し、明らかに大量のファイルを取り込んだり大量のコマンドを実行したりする操作を一区切り終えた後、もう一度実行して差分を比較する。こうすることで「先ほどのその操作が実際にどれだけかかったか」を具体的に把握でき、セッション終了時になって初めて総量が高いことに気づき、どのステップが原因だったのか遡って特定するのが難しくなる事態を避けられる。
私はヘビーユーザーではなく、たまにClaudeCodeで小さなタスクをこなすだけですが、この内容は自分に意味がありますか？
意味はあるが、その意味合いは少し異なる。あなたの利用パターンが「たまにセッションを開き、いくつか質問して終わる」というものなら、固定起動オーバーヘッドが総使用量に占める割合はむしろ大きくなる——その先払いのコストを薄めるための後続の対話ターンが十分にないためだ。この場合、本当に注意を払うべきは、そもそもこれほど多くの独立した短いセッションを開く必要があるかどうかであり、いくつかの小さなタスクを一つのセッションにまとめて処理すれば、その固定コストをより有利に分散できる。
もしあなたのタスク自体が単純で、大量のファイル読み込みや繰り返しのコマンド実行をあまり伴わないなら、複利的に増加する部分（フィルタリングされていない出力、累積した読み込みファイル）があなたに与える影響はもともと限られている。この記事で最も関連性が高いのは、起動オーバーヘッドそのものへの理解だ——あの2万から3万トークンが何であるかを知っておけば、使用量の数字を見たときに、システム自体に問題があると誤解するのではなく、まずそれが正常な固定コストなのかどうかを確認できるようになる。
GitHub上には具体的なバグ報告（issue #52979）が記録されている：完全に空のフォルダで新しいセッションを開き、ファイルもツールもCLAUDE.mdもない状態で「hi」とだけ入力したところ、報告されたトークン使用量は約3万に達した。これは一人のユーザーの異常な事例ではない。firecrawl.devがまとめたトークン最適化ガイドも、「文字を一つも入力する前に2万から3万トークンが消える」というパターンを「バグではなく、ClaudeCodeの初期化の固定オーバーヘッドだ」と明確に位置づけている。この記事が分解するのは、そのコストが実際どこに使われているのか、そしてどの部分が本当に削れて、どの部分が削れないのかだ。
最初の一言を打つ前から、ClaudeCodeはすでにいくつかのものをコンテキストに読み込んでいる：システムプロンプト自体、組み込みツールの定義（公式ドキュメントによれば、ツール定義は個別にカウントされるのではなく、集計目的でシステムプロンプトに折り込まれる）、プロジェクトおよびグローバルレベルのCLAUDE.md、メモリファイル、接続済みMCPサーバーのツールスキーマ、そしてインストール済みSkillの名前と説明。これらすべてがメッセージごとに再送信される——APIは本質的にステートレスであり、「記憶する」という概念が存在しないため、毎ターン、スタック全体がゼロから展開し直される。
これが、「CLAUDE.mdから一段落削除して、何か節約できたはず」という直感的な最適化が、しばしば曖昧な結果しか生まない理由でもある。実際に目に見えるのは、自分で追加した部分だけだ。システムプロンプトやツールスキーマといった固定コストは、自分で書いた内容を削ったからといって消えるわけではない。
公式ドキュメントと複数の技術的分析はいずれも同じ重要な区別を指摘している：プロンプトキャッシングは、これらの固定的に繰り返し送信される内容をキャッシュでき、実際の請求で約90%の割引が得られるが、キャッシングが節約するのはお金であり、コンテキスト領域ではない。これらのトークンは依然として200Kのコンテキストウィンドウを完全に占有し、レート制限にもカウントされ続ける。そして内容が増えれば、ウィンドウが50〜70%埋まった時点から出力品質が低下し始めることも変わらない——これはまさにコンテキスト腐敗が扱う問題だ。安いことは無料であることを意味せず、ましてや重さがないことを意味しない。
起動時の2万から3万トークンを固定コストとして受け入れることは、一般的に現実的な判断だ——ほぼ全員がこのコストを支払っている。本当に時間をかけて調査する価値があるのは、セッションが長くなるにつれて積み重なり、複利的に増加していく部分だ。コミュニティが集めた実測データからの具体例：出力フィルタリングを行っていないテストコマンドは1回の実行で約2,131トークンを消費し、1時間に3〜4回実行すれば、その積み重ねは一晩かけて丁寧に削ったCLAUDE.mdをはるかに超える。同じコマンドを失敗項目のみ出力するように変更すると、1回あたりのコストは約363トークンまで下がった——この整理では「リストの中で最もレバレッジが高いが、ほとんど誰もやらない変更」と記されている。
もう一つ見落とされがちな複利の源は、既に読み込まれたファイルだ。ClaudeCodeがファイルを読むたびに、その内容は対話履歴に永続的に残り、以降のすべてのメッセージで再処理される。1回のPRレビューで20個のファイルをコンテキストに取り込むということは、そのセッションの残りのすべてのターンで、その20個のファイルの内容が繰り返し再送信されることを意味する——これは一度きりのコストではなく、セッションの長さとともに蓄積していくコストだ。
「この変更で何か節約できたはず」と直感的に推測するのではなく、ClaudeCode自体が実際の数字を見せてくれるツールをいくつか提供している：/contextは現在のコンテキストウィンドウ内の各要素が占めるトークン数をリアルタイムで内訳表示し、総使用量が一目でわかる。/memoryはこのセッションの起動時に実際にどのCLAUDE.mdとメモリファイルが読み込まれたかを示す。/usage（Opus 4.8以降で利用可能）は、現在の使用量がどの要素に集中しているかを具体的に指し示す。何かを削除してから「速くなった気がする」と漠然と観察するより、まず/contextを実行して実際に何にお金が使われているかをはっきり見てから、行動するかどうかを決める方がよい。
次に「このセッションの使用量がなぜこんなに急増しているのか」と感じたら、まず問題がどちらのカテゴリに属するかを見分けよう。すべてのセッションが一度だけ支払う固定起動オーバーヘッド（システムプロンプト、CLAUDE.md、接続済みのMCPとSkill）なのか、それとも対話ターン数とともに複利的に増加する可変コスト（フィルタリングされていないコマンド出力、繰り返しの読み込みで蓄積したファイル）なのか。前者はそれが本質的なコストであると受け入れ、せいぜい軽微な調整にとどめる。後者こそが本当に時間をかけて調査する価値があり、一度修正すればセッションの残り全体にわたって効果が続く部分だ。