Claude Codeにおける100万トークンコンテキストウィンドウ

コンテキスト制限は、Claude Code登場以来ずっと頭を悩ませてきた問題だった。その悩みがようやく小さくなった。AnthropicがOpus 4.6とSonnet 4.6に100万トークンのウィンドウを有効化した。ベータフラグなし、追加料金なし、ウェイトリストなし。Max、Team、Enterpriseプランではすでに有効になっている。

これはバージョンアップというよりも、エージェントが持ち運ぶワーキングメモリが5倍になったと考えるべきだ。そのメモリにはコードベース、ツール呼び出しの履歴、長い実行にわたる推論の連鎖が入る。料金も変わらない。90万トークンのリクエストも9,000トークンのリクエストも、同じトークン単価だ。

このページでは、100万トークンのウィンドウがプロダクトとワークフローのレベルで何を変えたかを理解するために使おう。圧縮がいつ発火するか、予約バッファがどう振る舞うかが本当の疑問なら、Claude Codeコンテキストバッファ管理を読んでほしい。セッションを続けるか、コンパクトにするか、巻き戻すか、再起動するかが疑問なら、コンテキスト管理を読んでほしい。

200Kと1Mの比較

GA時に実際に変わったこと

大きなウィンドウは何ヶ月もベータ版だった。GAとはベータ版を二流に感じさせていた摩擦を取り除くことだ。

ウィンドウ全体での定額料金。 長いコンテキストにプレミアムはなくなった。Opus 4.6は$5/$25/百万トークン（入力/出力）。Sonnet 4.6は$3/$15。1万トークンのリクエストも95万トークンのリクエストも同じトークン単価で請求される。

全体でフルのレート制限。 長いリクエストはベータ期間中は強くスロットリングされていた。そのキャップはなくなった。100万トークンの呼び出しは短いものと同じスループットを引き出す。

1リクエストに600メディアアイテム。 画像とPDFページはかつて100で上限だった。新しい上限は6倍の600だ。デザインシステムの作業、ドキュメントのレビュー、契約書のスタックには実際の向上だ。

ヘッダーのトグルなし。 200K超のリクエストにはかつてanthropic-betaヘッダーが必要だった。既存のヘッダーはただ無視されるようになった。APIが処理する。

マルチクラウドで稼働中。 Claude Platform、Microsoft Azure Foundry、Google Cloud Vertex AIで1Mウィンドウが使える。

なぜClaude Codeは今違って感じるのか

APIユーザーはここで料金と利便性の向上を得る。Claude Codeユーザーは構造的なものを得る。

圧縮の発火が減った

実際の作業でClaude Codeを押し進めてきた人なら、圧縮コストを知っている。ファイルを読み込み、ツール呼び出しを連鎖させ、推論を積み上げると、自動圧縮が発火する。Claudeが会話を圧縮してスペースを確保する。ニュアンスが失われる。エッジケースが消える。マルチステップタスクが途中でスレッドを落とす。

AnthropicのCPO Jon Bellはその数値を公表した: 圧縮イベントが大きいウィンドウが出荷されてから15%減少した。 ラボのベンチマークではない。実際のClaude Codeトラフィックで測定されたものだ。エージェントはコンテキストを保持し、最初に読み込んだものを忘れずに何時間もの作業をこなす。

圧縮がいつ発火するかのメカニズムに興味があれば、コンテキストバッファ管理ガイドを参照してほしい。手短に言うと: Claude Codeは約3.3万トークンのバッファを確保し、使用量が約83.5%に達すると圧縮する。100万のシーリングはそのラインに達するまでに約5倍の余地があることを意味する。

コードベース全体を一度に

200Kでは、バッファが確保されてしまうとワーキングスペースが約15万トークンだった。小規模なリポジトリには十分だ。それ以上には苦痛で、常にどのファイルを選ぶかを決めていた。

それが100万になると使えるヘッドルームは約83万トークン。数千のソースファイル。モノレポ全体。そのコードが記述するドキュメントとコードが並んでいる。Claude はAPIレイヤーとそれを呼び出すフロントエンドを、マイグレーションとそれが変更するスキーマを、テストファイルとその対象コードを。すべて同時に保持できる。どのファイルを読み込むかを手作業で選ぶのをやめられる。

本当に完了するエージェントトレース

エージェントチームと複雑なオーケストレーション実行にとっての報われる部分だ。ツール呼び出しのたびに、推論ステップのたびに、ファイルの読み込みのたびにコンテキストに積み重なる。200Kでは、実際の作業でのマルチエージェントセッションが20〜30分で予算を使い切った。

RampのソフトウェアエンジニアAnton Biryukovはかつてのパターンをこう表現した: 「Claude CodeはDatadog、Braintrust、データベース、ソースコードを検索して100K以上のトークンを消費できる。そして圧縮が始まる。」1Mでは、検索して、また検索して、エッジケースを集めて、修正を出荷できる。1つのセッションの中で。何も途中で落とさない。

モデルは本当に100万トークンを使いこなせるか？

巨大なコンテキストは、モデルが実際にその中の内容を想起して推論できなければ意味がない。Anthropicは1Mのマークでまさにそれをテストするために構築された2つのベンチマークを実行した。

Opus 4.6は1MトークンでのスコアがMRCR v2で78.3%。 MRCR（Multi-Round Coreference Resolution）は、巨大なプロンプト全体にわたってモデルがエンティティとそれらの間のつながりを追跡できるかをチェックする。100万トークンで80%近い精度は、モデルが単に言葉を保存しているだけでないことを意味する。離れた場所にある部分がどうつながるかをまだ知っている。

Sonnet 4.6は1MトークンでのGraphWalks BFSスコアが68.4%。 このテストは、長い入力の深い部分に埋め込まれたグラフ構造をモデルがどれだけ歩けるかを測定する。数十万トークンにわたって参照の連鎖を追跡できるか？両スコアは当該コンテキスト長でのフロンティアモデルのトップとして記録されている。

実際には、Claudeが50万トークン前に定義したヘルパー関数を見つけ出して、今編集しているコンポーネントとのフックを確認できることを意味する。

ワークフローでの使い方

やることを変える

ファイルの手動管理をやめる。 200Kでは@fileの呼び出しのたびにトレードオフがあった。1Mでは必要なものを読み込んで先に進むだけ。実装とテストファイルを一緒に読み込む。コンポーネントと型を一緒に読み込む。Claudeに全体像を与える。

セッションを長く続ける。 30分ごとに再起動する習慣は好みではなく生存のためのものだった。シーリングが5倍になり、セッションは難しいタスクに何時間も取り組める。バッファが気になるからではなく、本当にフォーカスが切り替わるときに再起動しよう。いつコンパクトにしていつ続けるかのルールについては、コンテキスト管理ガイドを参照。

マルチステップのエージェントを活用する。 本当の報酬は素早い編集ではない。Claude が多くのファイルにわたって調査・計画・実装・確認する必要がある種類の作業だ。その連鎖はかつてタスクの途中で圧縮が発火すると切れた。今は1つのウィンドウに収まり、ドラマなしに完結する。

コンテキストエンジニアリングのプレイブックを再考する。 読み込みと保存の戦略は引き続き重要だ。ただより多くの余裕がある。コンテキスト管理ガイドの基本は引き続き有効だ。プレッシャーは「200K以下で生き残る」から「1Mをうまく使う」に移った。

1Mウィンドウが結果を変えるところ

1Mコンテキストの最も良い考え方は「Claudeはより多くを読める」ではない。「タスクの全クラスが脆く感じなくなる」だ。

1. クロスレイヤーのバグハント

200Kでの以前のパターン:

• フロントエンドを読み込む
• 問題がAPIにあるかもしれないと気づく
• いくつかのファイルをアンロード
• APIを読み込む
• バグはスキーマかマイグレーションにも依存していると気づく
• 途中で圧縮が起き、最初の手がかりを失う

1Mでは、ページコンポーネント、APIハンドラ、スキーマ、マイグレーション、失敗しているテストをすべて1つのセッションに保持することが多くの場合できる。これは単に便利なだけでない。根本原因の品質を変える。

2. 実際のシステム境界にわたるセキュリティレビュー

セキュリティレビューはコンテキストを多く消費する。問題が1つのファイルにあることはめったにないからだ。

本格的なレビューには以下が必要かもしれない:

• 認証ミドルウェア
• セッション処理
• パスワードリセットフロー
• レート制限ロジック
• 監査ログ
• サーフェスを露出するルートハンドラ

200Kでは、どのレイヤーを省くかを選んでいた。1Mでは、フロー全体をレビューして、テイクオーバーリスク、リプレイリスク、権限境界のミスについてより良い質問ができる。

3. ファイルを手作業でキュレートせずにモノレポを変更する

200Kでは、大規模なリポジトリの作業がしばしばコンテキストの管理作業になった。セッションの半分をClaude が何を見ることを許可されるかを決めることに費やす。

1Mでは、以下にわたるマイグレーション:

• 共有型
• APIコントラクト
• フロントエンドの呼び出し元
• 統合テスト

がずっと自然に収まる。スコープの規律はまだ必要だ。ただ10分ごとのトークントリアージをやめられる。

4. 長いドキュメントとデザインのレビュー

コード以外でも大きなウィンドウは重要だ。プロダクト仕様、デザインドキュメント、アーキテクチャノート、PDF、スクリーンショット、関連する実装ファイルをすべて同じリクエストに保持できる。「仕様から実装へ」と「デザインからコードへ」の作業がずっと安定する。

1Mが実際に必要かどうかの判断

セッションが定期的に以下の1つ以上を含むなら、より大きなウィンドウの恩恵を受けられるだろう:

作業が主にすばやい編集、小さなリポジトリ、短い集中したセッションなら、1Mは良いが変革的ではない。コンテキストが主な制約だったより広いタスクで向上が現れる。

変わらないこと

コンテキストの衛生は引き続き重要だ。100万のシーリングは何でも詰め込んでClaude が仕分けしてくれると期待するキューではない。無関係なファイルはトークンを消費し、Claudeが集中するために使うシグナルを薄める。

CLAUDE.md、スキル優先の読み込み、クリーンなセッション管理は引き続きベストプラクティスだ。ただより余裕がある。使用最適化パターンをすでに実践しているなら、大きなウィンドウはさらに報われる。

1Mウィンドウを使えるのは誰か

Claude Code、Max、Team、EnterpriseプランではOpus 4.6で1Mウィンドウが自動的に使える。トグルする必要はない。長いコンテキストのリクエストにかつて必要だった追加の使用割り当てはなくなった。

APIユーザーは標準のトークン単価で使える。Opus 4.6は$5/$25/百万トークン。Sonnet 4.6は$3/$15。長いコンテキストにプレミアム階層はない。

200Kウィンドウは引き続き存在する。標準APIリクエストと下位プランのデフォルトとして。1Mオプションは特にOpus 4.6とSonnet 4.6に紐付いている。

これが示すもの

Anthropicは単にコンテキストウィンドウを大きくしているのではない。大きなウィンドウを使いにくくしていたトレードオフを取り除いている。定額料金は長いリクエストを別に予算計算する必要をなくす。フルのレート制限はスループットが下がらないことを意味する。ベータヘッダーを廃止することで既存のコードがそのまま動く。

方向性は明らかだ。コンテキスト管理はユーザーの仕事からインフラの仕事に移行しつつある。モデルは長いコンテキストの使いこなしが向上し続けている。料金が門を開き続ける。ツールは自然に整備される。

Claude Codeユーザーにとっての教訓はシンプルだ。エージェントはより長く考えてより多く覚える。その上にワークフローを構築すれば、かつて慎重なセッション管理と手作業でのコンテキストの選別が必要だったタスクが、ただ動くようになり始める。エンドツーエンド。1つのウィンドウの中で。

関連リソース

• コンテキストバッファ管理 -- 自動圧縮の仕組みと3.3万トークンバッファ
• コンテキストエンジニアリング -- コンテキストを戦略的に読み込むための6つの柱フレームワーク
• コンテキスト管理 -- セッションをまたいで重要なコンテキストを保持する戦略
• モデル選択ガイド -- タスクに応じてOpus 4.6とSonnet 4.6を選ぶ