はじめに
Anthropicが、Claude Opus 4.6とSonnet 4.6の1Mコンテキストウィンドウを正式に一般提供（GA）開始しました。200Kから5倍の拡張です。しかも追加料金なしの標準価格で利用できます。
この記事では、公式ブログの内容をベースに、1Mコンテキストウィンドウで何が変わるのか、具体的にどう活用できるのかを解説します。
何が変わったのか
料金据え置きで5倍のコンテキスト
最大のポイントは、料金体系が変わっていない点です。
| モデル | 入力 | 出力 | 長文プレミアム |
|---|---|---|---|
| Opus 4.6 | $5/Mトークン | $25/Mトークン | なし |
| Sonnet 4.6 | $3/Mトークン | $15/Mトークン | なし |
9Kトークンのリクエストでも900Kトークンのリクエストでも、トークン単価は同じです。
競合モデルとの比較として、Gemini 3 Pro Previewは200Kトークン以下の入力が$2、超過分は$4と倍額になります。GPT-5.4も272Kトークン以下の入力が$2.50、超過分は$5と倍額です。Claudeにはこのような段階的な値上げがありません。
API変更点
- 200Kトークン超のリクエストにベータヘッダーが不要になりました
- 既存のベータヘッダー付きコードはそのまま動作します
- フルレートリミットがすべてのコンテキスト長で適用されます
メディア拡張
1リクエストあたりの画像・PDFページ数の上限が100から600に増加しました。契約書や技術文書のPDFを丸ごと読み込む場合に効果的です。
ベンチマーク
Opus 4.6は長文コンテキスト検索ベンチマーク「MRCR v2」で78.3%を達成しています。フロンティアモデルの中で最高スコアであり、1Mトークン全体にわたって検索精度を維持できることを示しています。
Claude Codeでの恩恵
Claude CodeのMax、Team、Enterpriseプランでは、Opus 4.6で自動的に1Mウィンドウが有効になります。
Proプランの場合はClaude Codeで/extra-usageコマンドを実行してオプトインする必要があります。Freeプランでの1Mコンテキスト対応は公式に言及されていません。
コンパクション問題の軽減
Claude Codeを実プロジェクトで使ったことがあれば、コンパクション（会話の圧縮）に悩んだ経験があると思います。コンテキストが上限に達すると、エージェントが会話を圧縮し、作業中の重要な情報が失われます。
200Kトークンの場合、複雑なタスクでは比較的すぐにこの上限に到達しました。1Mトークンでは5倍の余裕が生まれるため、コンパクションの発生頻度が大幅に減ります。
以前は、要約や手動のコンテキストクリアなどのエンジニアリング工夫が必要でした。1Mウィンドウではコンパクションの発生頻度が大幅に下がり、より多くの会話履歴を保持できるようになります。公式ブログでは、あるユーザーがコンパクション発生率の15%減少を報告しています。
活用法1：大規模ファイルの直接読み込み
PRD（プロダクト要件定義書）の読み込み
200Kトークン時代には、大きなPRDをコンテキストに読み込むと、それだけでウィンドウのかなりの部分を消費していました。エージェントが「コンテキストウィンドウの長さを超えた」とエラーを返すこともありました。
対処法として、ファイルを小さなチャンクに分割し、各チャンクの要約を作成し、要約を結合するという手順を踏んでいました。この過程で重要な詳細が失われがちです。
1Mトークンでは、680行を超えるような詳細なアプリ仕様書でも、1Mトークンに対してごくわずかな割合しか消費しません。ファイル全体を直接読み込んで作業できます。
データ分析用ファイル
CSVやExcelスプレッドシートのデータ分析も同様です。以前はファイルサイズの制約で分割が必要でしたが、1Mトークンではより大きなデータセットを直接扱えます。
活用例
以下のようなケースで効果を発揮します。
- 数百ページの契約書PDFの一括レビュー（最大600ページ）
- コードベース全体の読み込みと分析
- 長時間稼働したエージェントの実行トレース（ツール呼び出し、観察結果、推論過程）の完全な保持
活用法2：Wave分割による実装計画
1Mコンテキストを活かした効率的な開発ワークフローを紹介します。すべてを1セッションに詰め込むのではなく、計画的に活用するアプローチです。
ステップ1：仕様書から実装プランを生成
アプリの仕様書（appspec）をClaude Codeに渡し、以下のように依頼します。
- 仕様をフィーチャー（機能）単位に分解してもらいます
- フィーチャー間の依存関係を分析してもらいます
- 依存関係に基づいてWave（実装の波）にグルーピングしてもらいます
# 実装プラン例
## Wave 0: 基盤セットアップ
- プロジェクト初期化
- DB設定
## Wave 1: コア機能
- 認証システム
- ユーザー管理
## Wave 2: ビジネスロジック
- データ処理パイプライン
- API実装
## Wave 3: UI/UX
- ダッシュボード
- 設定画面
- 通知システム
- レポート機能
- ユーザープロフィール
- 検索機能
## Wave 4: 統合テスト
## Wave 5: デプロイ準備
ステップ2：Waveごとに並列実装
各Waveは、同じファイルや機能領域に触れるフィーチャーがグルーピングされています。そのため、エージェントがWave内のフィーチャーを実装する際、関連ファイルがすでにコンテキストに読み込まれた状態で効率的に作業できます。
200Kトークン時代には、1つのWaveに3つ以上のフィーチャーがあると、コンパクションが発生するリスクがありました。1Mトークンでは5倍の余裕があるため、Wave 3のように6つ以上のフィーチャーを含むWaveでも安定して実装を進められます。
ステップ3：エージェントチームで並列処理
Claude Codeのエージェントチーム機能を使うと、各Waveを担当するエージェントを並列で稼働させることができます。
エージェントチームの構成例は以下の通りです。
- Wave担当エージェント（Wave 0〜5をそれぞれ担当）
- QAエージェント（品質チェック担当）
- Devil's Advocateエージェント（品質に疑問を投げかける役割）
各エージェントは個別のコンテキストウィンドウを持ちます。以前は各エージェントも200Kトークンの制約があったため、複雑なWaveでコンパクションが発生していました。1Mトークンでは各エージェントにも十分な余裕があります。
エージェント間はタスクリストを共有し、相互にコミュニケーションを取りながら実装を進めます。/btwコマンドを使えば、作業中のエージェントを中断せずに質問することも可能です。
活用法3：大規模マイグレーション
1Mコンテキストが最も効果を発揮するユースケースの1つが、大規模なコードベースのマイグレーション（技術スタック移行）です。
マイグレーションの課題
400以上のフィーチャーを持つアプリケーションを別の技術スタックに移行する場合を考えてみます。
200Kトークンでは以下のような問題が発生していました。
- プロジェクト全体を俯瞰できません（一部のコンポーネントだけでコンテキスト上限に到達します）
- すべてを極小チャンクに分割する必要がありました
- 会話のコンパクション時に重要な詳細が失われました
- 移行完了後も一部の機能が欠落するリスクがありました
1Mトークンでの改善
1Mトークンでは、以下の点が改善されます。
- コードベースのより広い範囲を一度に分析できます
- ファイル構成や依存関係の把握が正確になります
- specファイルの作成や実装計画の精度が向上します
- コンパクションによる情報ロスが大幅に減ります
1Mトークンでもすべての問題が解消されるわけではありません。非常に大規模なプロジェクトでは、Wave分割とエージェントチームを組み合わせたアプローチが依然として有効です。
対応プラットフォーム
| プラットフォーム | 対応状況 | 備考 |
|---|---|---|
| Claude Platform（API） | GA（Opus 4.6 / Sonnet 4.6） | 標準料金、ベータヘッダー不要 |
| Claude Code（Max/Team/Enterprise） | 自動有効化 | 設定変更不要 |
| Claude Code（Pro） | オプトイン |
/extra-usageで有効化 |
| Microsoft Foundry | GA | |
| Google Cloud Vertex AI | GA |
Sonnet 4.5やSonnet 4などの旧モデルで200Kトークンを超えるリクエストを行う場合は、引き続きcontext-1m-2025-08-07ベータヘッダーが必要です（Usage Tier 4以上）。
まとめ
Claude 1Mコンテキストウィンドウのポイントを整理します。
- 200Kから1Mへ、5倍の拡張が追加料金なしで利用できます
- 競合モデルのような長文プレミアム（倍額課金）がありません
- 画像・PDFは最大600ページまで対応しています
- MRCR v2ベンチマークで78.3%（フロンティアモデル最高）を達成しています
- Claude Codeではコンパクション問題が大幅に軽減されます
活用のポイントとしては、以下の3点を意識してみてください。
- 大規模ファイル（PRD、データセット、契約書PDF）を分割せずに直接読み込む
- 仕様書をWave分割し、依存関係を考慮した並列実装を行う
- エージェントチームで各Waveを並列処理し、開発速度を上げる
「コンテキストが足りない」という制約から解放されることで、AIエージェントの活用範囲が広がります。特にマイグレーションや大規模プロジェクトの計画・実装フェーズで、これまで諦めていたアプローチを試してみてください。