Claude Codeのトークン節約ガイド：100万コンテキストの使用に注意、新セッションの開始方法を適切に選択

最近コミュニティでは不満の声が上がっています：クォータがすぐに使い切れてしまいます。Max ユーザーの週間の利用枠を、ある人はわずか 2 日で使い果たしてしまいました。AWS Bedrock で計算したところ、1 つのセッションにおける実際のコストは 134 ドルを超えましたが、Pro Max の 5 倍サブスクリプションでは月額 100 ドルです。Anthropic のサブスクリプション自体が赤字で販売されています。

多くの人の第一反応は、頻繁に「/clear」コマンドを実行するか、ステップごとに新しいセッションを開始することです。「軽装して進むことでコストを節約できる」と考えているのです。しかし、Claude Code 背後のキャッシュ（注：計算結果の保存機能）メカニズムを理解すれば、この操作がしばしば逆効果になることがわかります。あなたはまさに全額支払いでのコンテキスト再構築をトリガーし、継続して会話をするよりも多くのお金を費やしていることになります。

なぜクォータがこれほど速く消費されるのか理解するには、まず大規模言語モデル（LLM）が入力を処理する仕組みを知る必要があります。それは人間の「続きから読む」という行為とは全く異なります。

気候変動に関する論文を書いていると想像してください。図書館に行くたびに同じことをしなければなりません：500 ページの『世界気候報告書』を見つけ、必要な章に飛び込み、重要なデータを写し取ることです。初めては 40 分かかりました。2 回目は異なる質問をしましたが、同じ本なのでまた 40 分かかりました。3 回目、4 回目も、同じく 40 分かかります。

大規模言語モデルが行っているのはまさにこれです。「記憶」を持っていません。直前に読んだからといってスキップすることはありません。あなたのメッセージを受け取るたびに、完全な入力内容を最初から「読み直す」必要があります。読む時間は入力内容の長さに比例します。

Claude Code における入力内容は通常、以下の 3 つの部分で構成されます：

固定部分：システム指示、ツール定義、CLAUDE.md に記載されたプロジェクトルール

前 2 つの部分は同じセッション内ではほとんど変化しませんが、モデルは毎回それらを再「読み」直す必要があります。20 ラウンド会話した後、新しいメッセージ 1 つあたりには 10 万トークンの「古い荷物」が付属することになり、処理が遅く、かつ高価になります。

500 ページの書を毎回最初からめくるのは、誰にとっても耐えられません。解決策は非常に直接的です：事前にノートを作成しておき、次回からはそのノートを参照するだけです。

モデルが入力を読み終えると、一連の中間計算結果を生成します。これは「読書ノート」に相当します。その後回答を生成する際、モデルはこのノートに基づいて動作し、原文に戻って確認することはありません。プロンプトキャッシュ（注：入力の一部が重複した場合に計算結果を再利用する機能）の仕組みは以下の通りです：最初にノートを計算して保存しておき、次回同じ入力プレフィックス（注：入力の先頭部分）に出会った場合、保存されたノートを使用して重複計算をスキップします。

キャッシュからの読み取りコストは、再計算のコストの約 10 分の 1 です。

大まかに計算すると：20 ラウンドのセッションで 10 万トークンのコンテキストがあり、キャッシュが常にヒット（注：保存されたデータが見つかること）する場合、入力コストは毎回全額処理するよりも 6 倍以上安くなります。

第一に、キャッシュは「プレフィックス」に対してのみ有効です。最初から始まり、文字通り一字一句正確に一致している必要があります。

例え話しましょう：作文用紙に文章を書いたとします。最初の 3 ページが一字も違わず同じで、4 枚目のページで 1 字だけ変更した場合。使えるのは最初の 3 ページのみで、4 枚目からは再計算が必要になります。もし 1 枚目で 1 字変更したら？キャッシュはすべて無効化され、最初から計算し直さなければなりません。

したがって、Claude Code の入力構造が非常に重要です：システム指示やツール定義など変化しない内容は最前面に配置し、会話履歴を中間に、新しいメッセージを最後に配置します。これにより、毎回末尾の一小部分のみが再計算され、前方の大部分はキャッシュヒットします。

同じアクティブなセッション内では、プレフィックスが本質的に一致しているため、各ラウンドは尾部に新コンテンツを追加するだけであり、キャッシュヒット率は非常に高くなります。しかし、新しいセッションを開始すると、プレフィックスはゼロから始まり、以前蓄積されたキャッシュは一切利用できません。

第二に、キャッシュには有効期限があります。Claude Code チームの説明によると、メインエージェントのキャッシュウィンドウ（注：キャッシュが保持される時間）は 1 時間、サブエージェントは 5 分です。API ユーザーの場合、デフォルトは 5 分ですが（有料で 1 時間に延長可能ですが、より高額になります）。キャッシュヒットするたびにタイマーがリセットされ、インタラクションの頻度を保っていれば、キャッシュは常に有効な状態を維持できます。

Claude Code チームの原文：

「Claude Code はキャッシュ利用率が最も高いフレームワークです。」

しかし、キャッシュミス（注：保存されたデータが見つからないこと）のコストは、コンテキスト長が増大するにつれて急激に増加します。200K のキャッシュミスと 1M のキャッシュミスでは、コストの規模が全く異なります。

このキャッシュの仕組みを理解した上で、いくつかの「常識」を覆す必要があります。

キャッシュがまだ有効な状態（ホット）であれば、新しいセッションを開くよりも継続して会話をする方が安価です。

Claude Code は毎回新しいセッションを開始するたびに、システムプロンプト、ツール定義、CLAUDE.md、プロジェクト設定といった「インフラストラクチャ」を再読み込みする必要があります。これらのおよそ 5 万トークンは、頻繁に /clear コマンドを実行すると、不変な内容に対して毎回全額分の書き込みコストを支払うことと同じです。

一方、アクティブなセッション内ではこれらの内容は常にキャッシュされており、そのたびにコストは約十分の一で済みます。

Anthropic の社員である Lydia Hallie 氏が「1 時間ほどアイドル状態になった大型のセッションは、再開を推奨する」と述べた際のキーワードは「アイドル状態」です。作業中のアクティブなセッションではキャッシュが常にホット（有効）な状態を保っており、継続して対話を行うのが最もコストを抑える方法です。

複雑なタスクを一度で正しく完了させる方が、何度も修正を繰り返すよりもトークン消費が少ない

拡張思考機能をオフにすると、単一のリクエスト内でのトークン節約にはなります。しかし、複雑なリファクタリングタスクにおいて、拡張思考をオンにして一度で完了させるのと、オフにした後に 3 回やり直すのでは、後者の方がコストが高くなる可能性が非常に高いです。なぜなら、対話のラウンドが増えるたびにコンテキスト全体が再送信される必要があり、3 ラウンドにわたる累積トークン数は、1 回の深い思考にかかる追加コストを遥かに上回るからです。

単純なタスクの場合は逆です。/effort コマンドで設定を下げるか、/config で思考モードをオフにすると、効果は即座に現れます。思考用のトークンは出力価格で課金されるため、デフォルトの予算設定では単純なタスクに対して明らかに無駄が生じます。

出力長を制御するよりも重要なのは、入力品質を制御することです。10,000 行のログをコピー＆ペーストして Claude に自分でエラーを探させるのではなく、ログファイルのパスを直接渡してください。Claude Code は grep などのツールを使って必要な情報を検索し、関連する内容のみをコンテキストに読み込みます。最も安価なトークンとは、そもそもコンテキストに含まれていないトークンのことです。

継続対話か新セッションかの判断：意思決定表

これは Claude Code でトークンを節約するための最も重要な判断基準となるかもしれません。多くの人のデフォルトの習慣は「完了したらクリアする」ですが、実際には最もコストを抑えるためのデフォルト習慣はその逆、「続けられるなら続けること」、そして新セッションは条件付きでトリガーされる操作であるべきです。

以下のいずれかの条件に当てはまる場合は、現在のセッションを継続してください：

• タスクが変更されていない。同じバグの修正中、同じモジュールの作成中、あるいは同一グループのファイルに関する作業中であること。
• 最後のメッセージから 1 時間以内であること。キャッシュはまだ有効であり、これまでに蓄積されたコンテキストはほぼ無料です。
• コンテキスト内の内容が現在の作業に依然として有用であること。以前読み込んだファイルや議論された解決策など、モデルがまだ活用している情報がある場合です。

もし思考中で一時的に入力がない場合は、短いメッセージを送ってキャッシュを活性状態に保ちましょう。あるユーザーは、キャッシュの自動維持のために「ハートビート拡張機能」まで作成しており、キャッシュを更新するコストは、キャッシュミス（未ヒット）時の全量再構築コストの約十分の一です。

タスクが変更された場合。認証モジュールの作成が終わった直後に支払い機能の実装に移るなど、2 つのタスクではコンテキストが全く異なります。古いセッションに蓄積されたコードファイルやデバッグ記録は新任務には無用であり、各リクエストでこれらの無関係な内容に対して課金されています。

アイドル状態が 1 時間を超えた場合。キャッシュはおそらく期限切れとなっており、継続対話を行うことは全量再構築をトリガーするのと同じです。むしろクリーンな状態から始める方がマシです。

コンテキストが無関係なコンテンツで埋め尽くされている場合。十数種類の試行や大量の無関係なファイルの読み込みが行われ、それらがまだスペースを占有しています。キャッシュがヒットしていても、モデルはノイズの中から信号を検出する必要があり、出力品質が低下します。また、圧縮後に重要な情報が失われる可能性もあります。

一言でまとめると：キャッシュがホットでタスクが変わっていないなら継続対話。キャッシュが期限切れ、タスクが切り替わった、あるいはコンテキスト内のノイズが多すぎる場合は、迷わず新セッションを開始してください。

コミュニティからは、「1 つのセッションで 1 つのことだけを行う」という働き方では、ほぼクォータ（利用枠）の問題に直面しないという報告もあります。

2026 年 3 月より、Max、Team、Enterprise プランではデフォルトで Opus 4.6 の 1M トークンコンテキストウィンドウが使用されます。Anthropic は長文コンテキストに対する 2 倍の価格プレミアムを撤廃し、1M ウィンドウと 200K ウィンドウは同額となりました。

しかし、1M コンテキストは多くのユーザーにおいてクォータ不足の主要な原因となっています。

問題はキャッシュが失効した際の代償にあります。1M トークンコンテキストを使って長いセッションを積み重ねた後、1 時間以上離席して戻り、継続対話を行うと、1M トークンのキャッシュはすべて期限切れとなり、1 メッセージ送るだけで全量再構築がトリガーされます。チームはこの問題を確認しており、デフォルトのコンテキストサイズを 1M から 400K に引き下げることを検討しています。

また、多くの日常会話では 80-120K のコンテキスト（文脈）の時点で圧縮がトリガーされ、200K も使えず、ましてや 1M を使う必要もありません。コミュニティで得られた経験則データも同じ結論を指し示しています：コンテキストが 200K を超えるとモデルのパフォーマンスは顕著に低下し、350K を超えればほぼ運頼みです。

1M のコンテキストが適しているシナリオは確かに存在します：大規模なコードベースを一度に読み込んでグローバルリファクタリングを行う場合や、長時間の多輪対話で圧縮によって中断されたくない場合などです。しかし、日常のコーディングやバグ修正には使いません。

私の提案：1M のウィンドウは維持しつつ、保守的な自動圧縮閾値を設定し、柔軟性と効率性の両方を兼顾することです。

もし 1M コンテキストを無効化したい場合は、~/.claude/settings.json に以下を追加してください。

{

"env": {

"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"

}

}

自動圧縮の閾値を設定したい場合は：

{

"env": {

"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "200000"

}

}

コンテキストが約 20 万トークンに近づくと自動的に要約・圧縮され、文脈の連続性を保ちつつコストの暴走を防ぎます。

一、日常業務には Sonnet を使う

Opus の入力コストは Sonnet の約 1.7 倍ですが、より重要なのは Opus がトークンを消費する速度が Sonnet の約 2 倍である点です。多くのチームが Opus のトークン使用量を減らす方法に時間を費やしていますが、まずは「このタスクに本当に Opus が必要か？」と自問すべきです。ほとんどのコーディングタスクには Sonnet で十分であり、Opus は複雑なアーキテクチャの意思決定や多段階推論のために取っておくべきです。

Claude Code では /model コマンドを入力すると、モデルを切り替えることができますが、プロンプトキャッシュはモデルごとに隔離されています。Opus で 10 万トークンのキャッシュを蓄積した後、Sonnet に簡単な質問をすると、Sonnet はゼロから独自のキャッシュを構築する必要があります。この場合、より「安価」な Sonnet に切り替えるよりも、Opus が直接回答する方がコストは少なくなります。軽量モデルが必要なシナリオでは、主モデルを切り替えるのではなくサブエージェントを使用してください。

三、CLAUDE.md を簡素化し、スキルの数を制御する

CLAUDE.md の内容はすべてのリクエストに注入されます。公式の推奨事項として 200 行以内に抑え、本当に長期的に有効なルールのみを残すべきです。コードレビューのプロセスやデータベースマイグレーションの手順など、特定のタイミングでのみ必要な長い説明は「スキル」に移管してください。スキルはデフォルトで呼び出し時にのみロードされ、事前にコンテキストを占有しません。

ただし、スキルも多ければ多いほど良いわけではありません。読み込みすぎたスキルとエージェントは、クォータ消費の隠れた要因となります。チームはこの消費量をより可視化できるようインターフェースの改善を進めています。スキルはプロジェクトディレクトリ（.claude/skills/）に配置します。

ちょっとしたコツ：CLAUDE.md 内で HTML コメントを使ってメンテナ向けの注釈を書くと、Claude がコンテキストを注入する前にコメントが削除されるため、トークンを消費しません。

五、まず少しのトークンを使って計画を立てる

複雑なタスクでは、まず計画モードに入り、Claude にコードの探索と方案の提案を行ってもらってから実施フェーズに入ることで、総コストは往々にして低くなります。本当に高価なのは、方向を誤った後にコードを再スキャンし、実装を書き直し、テストを再実行することです。

質問も同様です。「このコードベースを最適化してほしい」といった曖昧なプロンプトは広範なスキャンを引き起こしますが、「auth.ts に対して認証ロジックの改善案を提示して」のように具体的な指示を出すことで、無駄な処理を防げます。

六、permissions.deny を使ってモデルの読み取り範囲を制限する

インデックス化されていないコードベースでは、モデルが文脈を見つけるためにファイル検索に頼らざるを得ず、効率が極めて低くなります。.claude/settings.json に以下のように設定してください。

{

"permissions": {

"deny": [

"Read(./.env)",

"Read(./.env.*)",

"Read(./secrets/**)",

"Read(./node_modules/**)",

"Read(./build)"

]

}

}

これにより、機密情報や不要なファイルへのアクセスを明示的に拒否し、トークン使用量とコストを抑制できます。

これらのパターンに一致するファイルは、ファイル発見および検索結果から除外され、読み取り操作も直接拒否されます。モデルは場合によっては 5 分以上にわたってコードベースの検索ループに陥ることがあり、ファイルパスを指定したとしても、背景で関連しないファイルを繰り返し読み続けることがあります。

permissions.deny

2 つの委譲アプローチにより、メインセッションのトークン消費を削減できます。

サブエージェント：Claude Code のサブエージェントは独立したコンテキストを持ち、完了後に短いサマリーのみをメインセッションに返します。サブエージェントのキャッシュウィンドウは 5 分（メインエージェントは 1 時間）と短く、各呼び出しにおけるキャッシュ利用率も低くなります。しかしその価値はコンテキストの隔離にあります：コードレビュー、テスト実行、ドキュメント検索といった作業の詳細な出力がメインセッションに残らないため、以降のメッセージでこれらの内容に対して課金される必要がありません。

エージェントチームはサブエージェントとは異なります。エージェントチーム内の各メンバーは独立した Claude インスタンスであり、それぞれが独自のコンテキストウィンドウを維持します。プランニングモードにおけるエージェントチームのトークン消費量は標準セッションの数倍（コミュニティでの推計では約 7 倍）に達し、アイドル状態のメンバーも継続してリソースを消費します。並列処理による加速にはコストがかかり、「マルチエージェント＝より安価」とは限りません。

Codex プラグイン：OpenAI のサブスクリプションをお持ちの場合は、コミュニティ内で openai/codex-plugin-cc が利用されています。

claude mcp add codex -- npx -y @openai/codex-plugin-cc

コミュニティではトークン消費に関する様々な噂が流れていますが、Claude Code チームは議論の中で公式に澄清を行いました。

最も広まっているのは「コンテキストが 256K を超えると消費速度が加速する」という説です。これに対する公式の回答は非常に明確です：これは事実ではありません。実際の原因として考えられるのは、長期間アイドル状態だったセッションをユーザーが再起動し、大規模なキャッシュミスが発生したことが、コンテキスト長のせいだと誤って帰属されたケースです。

また、「モデルがファイルを読み込むたびにマルウェアチェックを行っており、トークンを浪費している」という不満もあります。このセキュリティ検知の通知は Sonnet 3.7 から導入されており、各新モデルで評価が行われましたが、性能低下を引き起こすことはありませんでした。Opus 4.6 ではすでにこの通知が削除されています。「適応的思考による配额消費の異常」についてもチームは否定しています。チームは内部指標を盲目的に信じておらず、引き続き調査を進めています：

「私たちはこの件を真摯に受け止め、継続して調査を行っています。内部指標を盲目的に信頼しているわけではありません。」

トークンを節約する核心的な考え方は一言で表せます：キャッシュのヒット率を可能な限り高め、コンテキストには無関係な内容を極力含めないようにすることです。

新しいセッションを開くことは手段の一つですが、プロンプトキャッシュの仕組みを理解すれば、「アクティブなセッション内で作業を継続する」ことがデフォルト戦略であり、「新しいセッションを開く」のは特定の条件下での最適化操作であることがわかります。

コミュニティでは多くの人が Claude Code、Codex、Cursor のいずれがより寛容なクォータを提供しているかを比較しています。しかし、クォータの引き締めは業界全体の傾向かもしれません。「補助金付き計算資源時代の終焉」に直面していると語る人もおり、かつて Uber が 3 ドルで配車サービスを提供していた時期のような状況です。どの企業がより長く補助金を続けるか賭けるよりも、コスト構造を明確にし、予算を最も効果的な場所に投じるべきでしょう。

皆さんは普段、1 つのセッションがどれくらいの長さになることが多いですか？また、会話が続くのを恐れて頻繁に /clear コマンドを実行する習慣はありませんか？

Claude Code のトークン節約ガイド：1M コンテキストを不用意に使用せず、新しいセッションを開き続けるのも、常に同じセッションを使い続けるのも正解ではありません（続き 5/5）