Claude1Mコンテキストの上限と体感性能劣化の真実！実用的な限界は256K？

「1Mトークンで大丈夫！」と思ってセッションを続けたら、途中からClaudeが指示を無視し始めた……そんな経験をしたことはありませんか？2026年3月にAnthropicがClaude Opus 4.6とSonnet 4.6の1Mコンテキストウィンドウを正式リリースしましたが、実際に使い込んだエンジニアたちの体感レポートは、公式発表とは少し違う現実を伝えています。この記事では、公式ベンチマークデータと世界中のユーザーが報告したリアルな体感情報を組み合わせ、「本当の意味で使えるコンテキストの上限」について徹底的に解説します。

Claude1Mコンテキストは何が変わったのか？

2026年3月13日、AnthropicはClaude Opus 4.6とClaude Sonnet 4.6において、1Mトークンのコンテキストウィンドウを一般提供（GA）することを発表しました。Max・Team・Enterpriseプランのユーザーは設定変更なしに、追加料金なしでOpus 4.6の1Mコンテキストを利用できるようになっています。Proプランのユーザーは/extra-usageコマンドでオプトインすることで利用可能です。

以前は200Kトークンを超えるリクエストに対して入力コスト2倍・出力コスト1.5倍という長コンテキストプレミアムが課されていましたが、このGA化と同時にその割増料金も廃止されました。つまり、900Kトークンのセッションも9Kトークンのセッションも、トークン単価はまったく同じです。

Anthropic CPOのJon Bell氏によると、1Mコンテキストのリリース以降、オートコンパクション（自動圧縮）の発生件数が15%減少したと述べています。これはベンチマークではなく、実際のClaude Codeの利用データから計測された数値です。それほど多くのユーザーが、以前はコンテキスト不足に苦しんでいたということを物語っています。

では、1Mトークンになったことで何が具体的に変わったのかというと、Claude Codeで約83.5%のコンテキスト使用率に達したときに自動圧縮がかかる仕組みは変わっていません。ただ、分母が5倍になったことで、約33Kトークンのバッファを除いた実質的な利用可能空間は約830Kトークンに拡大されました。これは数千のソースファイル、モノリポジトリ全体、コードとそのドキュメントを同時に保持できるレベルです。

体感性能が落ちる本当の理由「コンテキストロット」とは何か？

「コンテキストロット（Context Rot）」という言葉を聞いたことはありますか？これはAnthropicが自ら名付けた現象で、コンテキストが長くなるにつれてLLMの情報検索精度が劣化していく問題のことです。

Chroma Researchが2025年7月に発表した研究では、18のモデルを対象に194,480回のLLM呼び出しを通じて、この現象を体系的に解明しました。その結果は直感に反するものでした。「同じ質問をしているのに、周りのテキストが多いだけで間違える」のです。短い入力では95%以上だった精度が、長いコンテキストでは60〜70%にまで落ちるケースが観測されています。

特に問題になるのが、検索対象と意味的に似た「妨害テキスト」がコンテキスト内にある場合です。コードベースには、似たような名前の関数や似たロジックのクラスが大量に存在します。たとえばgetUserByIdを探そうとしたとき、getUserByNameやfindUserByIdがコンテキスト内にあると、モデルが混乱しやすくなります。これはコーディング作業においては特に深刻な問題です。

さらに驚くべき発見として、ランダムにシャッフルされたテキストのほうが、論理的に構造化されたドキュメントよりも検索性能が高いという結果も出ています。Attentionメカニズムが、テキストの構造パターンに予想外の影響を受けている可能性が示唆されており、「きれいに整理されたコードベース」を丸ごとコンテキストに入れても、その構造がかえって検索を妨げる可能性があるということです。

公式ベンチマークが示すClaude1Mの実質的な精度上限

AnthropicはOpus 4.6のリリース時に、MRCR v2（Multi-needle Retrieval and Contextual Reasoning）というベンチマーク結果を公表しています。1Mトークンのテキストの中に8つの「針」（特定の事実）を隠し、モデルがすべてを見つけられるかをテストするものです。

モデル・コンテキスト長	MRCR v2精度（8針）
Claude Opus 4.6（256K）	93%
Claude Opus 4.6（1M）	76%
Gemini 3 Pro（1M）	26.3%
Claude Sonnet 4.5（1M）	18.5%

競合他社と比べると、Opus 4.6の1Mでの76%という数値は圧倒的です。GeminiやSonnet 4.5と比較すれば、まさに別次元の性能です。しかし問題の本質は競合比較ではなく、Opus 4.6自身の256K時（93%）と比べたときの17ポイントの低下です。1Mトークンのコンテキストでは、8つの事実のうち約2つを見落とす計算になります。

重要な注意点として、AnthropicはこのMRCR v2において128Kや512Kの中間データを公開していません。256Kを超えた直後に急激に劣化するのか、それとも緩やかに進行するのかは、公式データからは判断できません。多くのエンジニアコミュニティでは「コンテキストウィンドウの50〜60%を超えると顕著な劣化が始まる」という経験則が共有されています。

Sonnet 4.6についても、Anthropicはまだ1MでのMRCR v2スコアを公開していません。実測テストでは、Sonnetは400Kを超えると信頼性が急低下し、600Kではほぼ推測レベルになるという報告があります。1Mコンテキストを本格的に活用したいなら、現時点ではOpus 4.6一択と考えるのが無難です。

リアルユーザーが体感した「見えない壁」の正体

公式ベンチマークはあくまで理想化された合成テストです。実際のClaude Codeのセッションではどうだったのか、GitHubのIssueやコミュニティに寄せられたリアルな声を整理してみます。

まず、2026年3月にGitHub Issue #34685として報告されたケースが衝撃的です。Claude Opus 4.6の1Mコンテキストを使ったセッションで、コンテキスト使用率が約20%の時点から性能劣化の兆候が現れ始め、40%でオートコンパクション発動、そして48%で「私は今、このコンテキストに深く入りすぎていて効果的に機能していません。新しいセッションを始めることをお勧めします」とClaude自身が告白したというのです。1Mトークンの48%といえば約480Kトークン。広告されている半分にも届いていません。

Medium上に投稿されたある開発者の体験談では、以前のバージョンではコンテキストウィンドウの65〜70%あたりから明確にハルシネーションが増え始めたと述べています。システムプロンプトだけで20〜25Kトークン消費していたため、実質的に使えるコンテキストは100〜110K程度しかなかったと語っています。オートコンパクトは状況を改善するどころか出力品質を予測困難な形で低下させるため、結局/clearで最初から始め直すのが最善策だったとのことです。

GitHub Issue #24437では別の問題も報告されています。Opus 4.6がセッション中盤以降で「指示を無視する」「自分勝手に判断する」「指示をすぐに忘れる」という挙動が確認されています。コンテキストにシステムプロンプト、ユーザーの指示、大量のコードが積み上がるにつれて、初期の指示の「重み」が相対的に薄まっていくためだと考えられています。

さらにGitHub Issue #24991では、同じモデルID（claude-opus-4-6）を使っているにもかかわらず、バックエンドの設定変更と思われる原因で、複雑なタスクのスコアが92点から38点へ58%もの壊滅的な低下を示したケースも報告されています。コンテキスト長の問題だけではなく、実行環境の違いでも大幅に性能が変わりうるという教訓も含んでいます。

これらの体験談に共通するパターンをまとめると、以下のような段階的な劣化プロセスが見えてきます。

Claude1Mコンテキストを最大限活用するための実践戦略

CLAUDE.mdで「揮発しない記憶」を作る

コンテキストウィンドウをRAMに例えるなら、解決策は「重要な情報を不揮発ストレージに逃がすこと」です。その役割を担うのがCLAUDE.mdです。プロジェクトルートに置くこのMarkdownファイルは、セッション開始時に必ずコンテキストへ注入され、オートコンパクションが発動した後の次のターンでも再読み込みされます。

記載すべき内容は「絶対に毎回必要な情報」に絞り込むことが重要です。アーキテクチャ方針、コーディング規約、使用しているフレームワーク、絶対に避けるべきパターンなど、毎ターン参照が必要なものだけをCLAUDE.mdに書きます。詳細な実装ルールは.claude/rules/に分割し、CLAUDE.mdから参照する形にするとトークン消費を最小化できます。注入される分だけトークンを消費するため、書きすぎは逆効果になります。

/compactコマンドで要約の品質をコントロールする

オートコンパクションに任せっぱなしにするのではなく、区切りのよいタイミングで手動の/compactを実行するのが賢明です。手動で実行すると、何が重要かを明示した観点指定付きの要約ができるからです。

/compactのタイミングとして特に推奨されるのは、機能の実装が一段落してコミット前のタイミング、大きなリファクタリングフェーズから実装フェーズに移行するタイミング、そしてコンテキスト使用率が40〜50%に達したタイミングです。コミット前に/compactを実行する習慣をつけると、翌日のセッション開始時のコンテキスト品質が格段に上がります。

観点指定は英語で書くと要約品質が安定します。例えば「Summarize focusing on: current architecture decisions, completed features, and next immediate steps」のように、何を優先して要約してほしいかを明記することで、情報損失を最小限に抑えられます。

コンテキスト使用率に応じた適切なモード選択

Claude Codeのモデル選択画面には「Opus」と「Opus（1M context）」が並んでいますが、どちらを選ぶかはタスクの性質によって判断します。個別ファイルの編集、バグ修正、機能追加、テスト作成など対象が比較的限定されたタスクであれば、標準の200Kモードで十分です。256K以内では93%という高精度を維持できます。

一方、大規模コードベースの全体分析、アーキテクチャレベルのリファクタリング計画、セキュリティ監査など複数ファイルを横断的に参照する必要がある場合に1Mモードの真価が発揮されます。ただし、500Kを超えたあたりから精度が低下し始める可能性を意識し、可能な限り投入するコンテキスト量を絞り込む「コンテキストエンジニアリング」の発想が重要です。

「1Mの容量があるから1M分詰め込もう」という発想は避けるべきです。大は小を兼ねません。必要な情報だけを厳選して投入することが、最終的な出力品質を高める近道です。

また見落とされがちな選択肢として、opusplanエイリアスがあります。計画フェーズではOpusの高い推論能力を使い、実装フェーズではSonnetの効率性を活かすハイブリッドアプローチで、コストと性能のバランスを自動最適化してくれます。

CLAUDE_AUTOCOMPACT_PCT_OVERRIDEの正しい理解

環境変数のCLAUDE_AUTOCOMPACT_PCT_OVERRIDEを設定することで、オートコンパクションの発動タイミングを早めることができます。デフォルトは約83%ですが、たとえば65と設定すると65%の時点で早期発動し、要約に使えるトークンが多く残るため要約品質が向上します。

重要な制約として、この変数は閾値を早める方向にしか機能しません。内部実装でMath.min（指定値、デフォルト閾値）というクランプが適用されているため、83%より高い値（90や95など）を設定してもデフォルトの約83%で発動します。「遅らせたい」場合は効果がないことに注意してください。

Auto Memory機能とMCP Memory Serverを組み合わせる

Claude Code v2.1.59以降、Auto Memory機能がデフォルトで有効になっています。これはClaudeがビルドコマンドやデバッグの知見、アーキテクチャメモなどを~/.claude/projects/プロジェクト名/memory/に自動的に書き込む機能です。CLAUDE.mdと組み合わせることで、セッションをまたいだ記憶の継続性が大幅に改善します。

さらに本格的なセッション間記憶共有を実現したい場合は、MCP Memory Serverの導入が有効です。コンテキストウィンドウが圧縮・消滅してもデータは外部ストレージに残ります。シンプルに始めるならJSONベースの公式実装（@modelcontextprotocol/server-memory）で十分です。「過去の意思決定を横断検索したい」「複数のClaude Codeセッション間でコンテキストを共有したい」といったニーズが出てきたら、SQLiteやベクトルDBベースの実装への移行を検討してください。

「コンテキストロット」が起きているサインを見逃すな！現場で体験する劣化の症状チェック

問題は突然やってきません。コンテキストが劣化するとき、Claudeは「エラーを返す」のではなく「静かにドリフトしていく」のです。これがやっかいな理由で、出力がそれっぽく見えるのに中身がどんどん空洞化していくため、気づいたときにはすでに大量の作業が台無しになっています。

実際の開発現場でよく体験される劣化サインを整理すると、次のようなパターンが繰り返し報告されています。まず「Actually…Actually…」パターンです。Claudeが同じ問題を何度も再検討し、前に進まない堂々巡りの思考が始まります。「実は別のアプローチのほうがいいかもしれません」→実装→「やはり最初のアプローチが正しかった気がします」という無限ループは、コンテキストが飽和し始めているサインです。

次に命名規則のドリフトがあります。セッション序盤にgetUserData()で統一していた関数名が、セッション中盤以降にfetchUser()やretrieveUserInfo()に変わっていても気づかないまま実装が進む、というケースです。Claudeが初期の決定を「忘れた」わけではなく、初期の決定が大量のコンテキストの中に埋もれて参照頻度が下がった結果、整合性が崩れていきます。

もう一つの典型は「以前読んだファイルをもう一度読み直す」という行動です。30分前にすでに読み込んだはずのファイルに対して、再度Readツールを呼び出す様子が見られたら、コンパクション後の要約にそのファイルの内容が十分に保存されなかった可能性が高いです。これが頻発し始めたら、セッションのリフレッシュを検討するタイミングです。

MindStudioのコンテキスト管理ガイドでは、こうした症状が2つ以上同じセッション内で見られたら「今すぐ対処すべきサイン」だと述べています。問題は検知が難しいことではなく、検知のための判断基準を持っていないことです。上記の症状リストをあらかじめ頭に入れておくだけで、無駄なセッション時間を大幅に節約できます。

コンテキストを「汚染する」行動と「保全する」行動の違い

コンテキスト管理を突き詰めると、「何をコンテキストに入れるか」と同じくらい「何をコンテキストに入れないか」が重要です。日常的なClaude Code利用で無自覚にコンテキストを汚染している行動は意外と多く、改めて整理することで体感品質が劇的に変わります。

コンテキストを無駄に消費する行動の代表格は、コードをチャットにペーストすることです。200行の関数をチャットに貼り付けてから「この関数を修正して」と依頼すると、そのファイルのコンテキスト消費量が実質2倍になります。「このファイルのgetUserById関数を修正して」と指定するだけで十分で、Claudeが自分でファイルを読みに行きます。この差は長いセッションで積み重なると驚くほど大きくなります。

テスト実行結果の全ログをそのまま貼り付けることも同様に問題です。100行のテストログをペーストするより、「テスト#42が失敗している。エラーメッセージは〇〇」と要約して伝えるほうが、情報の密度が高く、コンテキスト消費量は桁違いに小さくなります。

逆にコンテキストを保全する効果的な行動として、公式ドキュメントが明示的に推奨しているのが「Claudeに自分でコンテキストを取りに行かせる」アプローチです。bashコマンド、MCPツール、ファイル読み込みなど、Claude自身が必要な情報を取得する手段を与え、人間がコンテキストに詰め込む前に一歩引くことで、ノイズの少ないクリーンなコンテキストを維持できます。

また、1日に複数回同じようなタスクをClaude Codeに依頼しているなら、それはスラッシュコマンド化するべきサインです。.claude/commands/に繰り返しタスクをコマンドとして定義しておくと、毎回同じ文脈説明をコンテキストに書かなくて済み、かつ実行の一貫性も高まります。

現実でよく困るコンテキスト問題と体験ベースの解決策

「途中でClaude Codeがフリーズしたように見える」問題

長いセッションで突然Claudeが無反応になったり、ツール呼び出しが止まったりする経験をしたことはないでしょうか。これは多くの場合、コンテキストが上限に近づいたときに起きるオートコンパクションの失敗や、圧縮パイプライン側の制限に引っかかっているケースです。GitHub Issue #23751では、200Kモードでコンテキスト使用量が48%（約78Kトークン）の時点でこの問題が発生したことが報告されています。

体験ベースの解決策として有効なのが、セッションのJSONLファイルをバックアップしてから再開する方法です。Claude Codeはセッション履歴を~/.claude/projects/[プロジェクトハッシュ]/[セッションID].jsonlとして保存しています。長時間の重要なセッションでは、定期的にこのファイルをバックアップしておくと、コンパクションでコンテキストが失われた際にclaude –resume [セッションID]で復元できます。

「コンパクション後にClaudeが別人になる」問題

これはおそらく最もフラストレーションを感じる体験です。30分かけて決めたアーキテクチャ方針がコンパクション後にすっかり消え去り、「なぜかさっきと全然違う提案をしてくる」という現象です。

根本的な解決策は、コンパクション発動前の「重要な決定」をCLAUDE.mdに都度書き込んでいく習慣をつけることです。セッション中に重要な決定が出るたびに「CLAUDE.mdに追記して」と依頼するだけで、次のコンパクション後も自動的に再注入されます。手間に感じるかもしれませんが、「コンパクション後に一から説明し直す時間」と比べれば、明らかに効率的です。

さらに有効なのが/handoffコマンドを使ったコンテキスト引き継ぎ手法です。2026年2月に登場したclaude-code-handoffというアプローチでは、/handoffスラッシュコマンドでコンテキストファイルを生成し、次のセッション開始時にSessionStartフックで自動注入します。エージェントが「強い状態」（コンテキスト60%以下）のうちにhandoffを実行すると、劣化した状態で書いた要約よりもはるかに精度の高いコンテキスト引き継ぎができます。

「Claudeが勝手にファイルを書き換えてしまう」問題

指示していないファイルをClaudeが変更した、あるいは明示的に却下した選択肢に戻ってしまった、という体験は長いセッションで頻発します。これはコンテキスト内で「指示の重み」が薄まっていくコンテキストロットの典型症状です。

実践的な対処法として、Esc Escキー（または/rewindコマンド）を使って問題が起きる前の状態にロールバックするのが最も確実です。「修正しようとして余計に状況を悪化させる」という二次的な汚染をコンテキストに加えないためにも、問題に気づいた瞬間に/rewindで戻ることをクセにしてください。同じコンテキスト内で修正を試み続けると、失敗した試行がすべてコンテキストに積み上がり、さらなるドリフトを引き起こします。

Claude1Mコンテキストをフル活用するための実践プロンプト集

以下のプロンプトはClaude1Mコンテキストの体感性能に直結する場面で使えるものを厳選しました。コピペして即使えるように設計しています。

プロンプト1コンパクション後の文脈復元プロンプト（セッション再開時）

「このセッションでこれまでに決定した主要な事項を箇条書きでまとめてください。特に以下の観点を含めてください採用したアーキテクチャの判断とその理由、却下した選択肢とその理由、現在の実装状況と次のステップ、変更してはいけないファイルやルール。これをCLAUDE.mdに追記する形式で出力してください。」

このプロンプトはコンパクション後や長いセッションの区切りで使うと、Claudeの現在の理解度を確認しながら、同時にCLAUDE.mdを更新できる一石二鳥の効果があります。

プロンプト2コンテキスト使用率の健全チェックプロンプト

「現在のコンテキスト使用率を確認してください。もし40%を超えているなら、この会話の中で最も重要な決定事項と現在の実装状態を3〜5行でサマリーしてください。その後、コンテキストの効率的な利用のために削除してもよい冗長な部分があれば教えてください。」

定期的にこのプロンプトを使うことで、/contextコマンドの情報とClaudeの自己認識を組み合わせた判断ができます。

プロンプト3コードレビュー時のコンテキスト最小化プロンプト

「以下のファイルパスにある関数を確認して[ファイルパス]の[関数名]。この関数だけを読んで、以下の点を評価してください[評価観点]。他のファイルを読む必要があれば、必要最小限にとどめてください。」

「必要最小限にとどめてください」という一文を加えるだけで、Claudeが不必要なファイル読み込みを自制し、コンテキスト消費を抑えてくれます。

プロンプト4大規模リファクタリング前の計画専用プロンプト（プランモード活用）

「まだコードを書かないでください。[機能名]のリファクタリングを計画するため、以下の質問に答えてください影響を受けるファイルの一覧、変更順序の推奨とその理由、リスクの高い箇所、ロールバック手順。計画が完成したらSPEC.mdとして保存してください。コードの実装は新しいセッションで別途依頼します。」

Claude Codeの開発者Boris Cherny氏が実際に使っているアプローチです。「まだコードを書かないでください」という一文がいわゆるプランモードの核心で、この一文があるだけでClaudeが計画と実行を分離し、計画フェーズのコンテキストを無駄に消費しません。

プロンプト5コンテキスト意識を持たせるシステムプロンプト（CLAUDE.mdへの追記用）

「あなたのコンテキストウィンドウは自動的に圧縮されるため、中断することなく作業を続けられます。コンテキスト残量が少なくなっても、自分から作業を早期終了しないでください。タスクが完了するまで粘り強く自律的に作業を続けてください。コンテキストの上限が近づいたら、現在の進捗状況と次のステップをmemoryに保存してから、コンテキストの更新に備えてください。」

Anthropicの公式ドキュメントにも紹介されているプロンプトパターンです。これをCLAUDE.mdに書いておくだけで、Claudeが自分からセッションを打ち切ることが大幅に減ります。

1Mコンテキストと料金の「本当の計算」を知らないと損する

GAによって長コンテキストプレミアムは廃止されましたが、コスト管理の重要性が消えたわけではありません。むしろ1Mを気軽に使えるようになった分、無意識のうちにコストが膨らみやすくなっています。

Opus 4.6の料金体系は入力100万トークンあたり$5、出力100万トークンあたり$25です。900Kトークンのセッションを1回こなすと、それだけで入力側だけで$4.50かかります。これが1日に数回のループ処理で走るような環境では、月間コストが想定外の水準に達することがあります。

エンジニアコミュニティで注目されている興味深い逆説があります。「Sonnetはトークン単価が安いが、Opusのほうが実は安くつく」という考え方です。Claude Codeの開発者自身が語っているように、Sonnetが同じ結果を出すために3回の反復を要するとすると、Opusが1回で済む場合よりも総トークン消費量で上回ることがあります。安さで選んで補正ループを繰り返すよりも、最初から精度の高いモデルを選んで一発で仕上げるほうが、トータルコストが低くなるケースが多いのです。

また、Claude Codeでは/usageコマンドで現在のプランの使用状況を確認でき、/contextコマンドで現在のコンテキスト使用率をビジュアルなカラーグリッドで確認できます。この2つのコマンドを定期的に見る習慣だけで、「気づいたら使いすぎていた」という事態を防げます。

2026年3月時点では、Claude Codeの平均的な1日あたりの利用コストは約$6と報告されていますが、大規模コードベースを1Mモードで扱うセッションをこなすと、これが大幅に跳ね上がります。セッション開始前に「このタスクに本当に1Mコンテキストが必要か？」を一度問いかけるクセをつけることが、長期的なコスト管理の要です。

ぶっちゃけこうした方がいい！

ここまでの内容を踏まえて、個人的な本音をお伝えします。

1Mコンテキストという数字に踊らされているうちは、Claude Codeを本当に使いこなしているとは言えません。「大きければ大きいほどいい」という発想で使うと、かえって品質が落ちてコストが上がるという逆転現象が起きます。

ぶっちゃけ、個人的に一番楽で効率的だと感じているのは「プランは新しいセッションで、実装は別のセッションで」という分離戦略です。プランモード（「まだコードを書かないでください」の一文）でSPEC.mdを作ってから、クリーンな新しいセッションでSPEC.mdを読み込ませて実装する。この2ステップを習慣にするだけで、60ターンかけても終わらなかったタスクが2〜4ターンで片がつくことがあります。

コンテキストが長くなるほど、Claudeは「今何をすべきか」の焦点を失います。逆に言うと、コンテキストが短くて目的が明確なほど、Claudeは最高のパフォーマンスを発揮します。1Mコンテキストの本当の使い方は「長くなっても使い続けられる保険」であって、「1Mまでギリギリ使い切る競技」ではありません。

適切なタイミングで/compactやセッション分割を行い、CLAUDE.mdを「生きたドキュメント」として更新し続け、必要な情報だけをピンポイントで投入する。この地味な管理習慣が、派手な1Mという数字よりも、日々の生産性に圧倒的な差をもたらします。

1Mコンテキストはツールであって、ゴールではありません。賢く使う人だけが、その恩恵を本当の意味で受け取れます。

Claude1Mコンテキストの上限と体感に関する疑問解決

1Mコンテキストで本当に1Mトークン全部使えるの？

技術的には使えますが、高い品質を期待できる実質的な上限は公式データ上は約256Kトークン（精度93%）です。1Mまで使うと精度は76%に低下し、4つのうち1つの事実を見落とす計算になります。実際のユーザー報告では、複雑なリファクタリングや依存関係のある変更では250K〜500Kトークン前後から顕著な劣化が始まるという声が多く聞かれます。また、コンテキストの約83.5%に達するとオートコンパクションが発動するため、1Mモードでも実質利用可能なのは約830Kトークンです。

Sonnet 4.6でも1Mコンテキストを使えるの？

Sonnet 4.6も1Mコンテキストに対応していますが、性能の観点では注意が必要です。Sonnet 4.5は1Mでの精度がわずか18.5%という壊滅的なスコアを示しており、Sonnet 4.6の1Mスコアはまだ公式発表がありません。実測テストでは400Kを超えると信頼性が急低下するという報告があります。長大なコンテキストで高い品質を求めるなら、現時点ではOpus 4.6が唯一の現実的な選択肢です。

オートコンパクションはいつ発動する？コントロールできるの？

Claude Codeはコンテキスト使用率が約83.5%に達したときにオートコンパクションが発動します。残り約33Kトークンは要約処理のバッファとして確保されます。CLAUDE_AUTOCOMPACT_PCT_OVERRIDEという環境変数で発動タイミングを早めることができます（たとえば65と設定すると65%で発動）が、83%より遅くすることはできません。より確実な方法は、手動で/compactを実行し、重要な観点を指定して要約品質を高めることです。

1Mコンテキストは料金が高くなるの？

2026年3月13日のGA化により、長コンテキストプレミアム（200Kトークン超で入力2倍・出力1.5倍という割増料金）は廃止されました。900Kトークンのリクエストも9Kのリクエストも、トークン単価は同じです。ただし、Max・Team・Enterpriseプランでは追加設定なしで利用できますが、Proプランでは/extra-usageコマンドでのオプトインが必要です。フリープランでも2026年3月のボーナスキャンペーン期間中はアクセス可能でした。

1Mコンテキストで応答が遅くなることはある？

明確に遅くなります。実測データによると、コンテキストサイズと初回トークン生成時間（TTFT）の関係は以下の通りです。50Kトークン（キャッシュなし）で約2秒、100Kで約4秒、200Kで約9秒、300Kで約16秒、500Kで約35秒という傾向があります。インタラクティブな作業では体感的にはっきりわかる遅延です。バックグラウンドや自動化タスクでは許容範囲内ですが、素早いフィードバックが必要なインタラクティブなコーディングでは、大量のコンテキストを常に保持することのデメリットを意識する必要があります。

まとめ

Claude Opus 4.6の1Mコンテキストウィンドウは、間違いなく技術的なブレイクスルーです。競合モデルが1Mで20〜30%程度の精度しか出せない中、76%を達成している事実は驚異的です。AnthropicのCPOが語った「コンパクション発生15%減」というデータは、多くのエンジニアの日常的な不満を実際に解消していることを示しています。

しかし本記事で繰り返し強調してきたように、「1Mコンテキストウィンドウ＝1Mトークン全域で高品質な動作を保証」ではありません。公式データが示す信頼できる上限は約256Kトークン（精度93%）であり、それを超えると緩やかに劣化が始まります。GitHubのIssueで報告されているように、400〜480Kの時点でClaudeが自ら性能低下を認め、セッションのリスタートを勧めるケースまで存在します。

「1Mトークンの容量があるから1M分詰め込もう」という考え方は捨ててください。最も賢い使い方は、タスクに本当に必要な情報だけを厳選してコンテキストに投入する「コンテキストエンジニアリング」の発想です。CLAUDE.mdで揮発しない記憶を作り、/compactで要約品質をコントロールし、コンテキスト使用率40〜50%を一つの目安として適切にリフレッシュする習慣を持つことが、長期的には最も安定した成果をもたらします。1Mという数字に踊らされず、「使えるコンテキスト」を意識して運用することが、Claude Codeを本当に使いこなすための核心です。