「200Kトークンあるから大きなドキュメントをすべて突っ込もう」——この判断が本番で品質劣化を引き起こすケースは珍しくありません。コンテキストウィンドウは「作業記憶」であり、量を増やせば精度が比例して上がるわけではありません。長文脈モデルを設計に活かすには、モデルの実効的な能力限界と、RAGや他のアーキテクチャとのトレードオフを理解した上で使い分ける必要があります。
コンテキストウィンドウとは何か——Context Rotとはなぜ起きるか
コンテキストウィンドウはモデルの作業記憶であり、量を増やしても精度は比例せず「Context Rot」（文脈腐敗）が発生します。
コンテキストウィンドウは、モデルが応答生成時に参照できるすべてのトークン（会話履歴・ツール定義・システムプロンプト・ドキュメント）の合計です。これはモデルが学習したコーパスとは別概念で、1回のリクエストにおける「作業記憶」に相当します。
Anthropicの公式ドキュメントは、Context Rot（文脈腐敗）という現象を明示しています。「コンテキストが長くなるほど、精度とリコールが劣化する」——つまり文脈量が増えるほど、モデルが特定の情報を正確に参照できる確率は下がります。コンテキストウィンドウが大きいことは「詰め込める上限」であり、「詰め込んでよい量」ではありません。
Context Rotへの対処: Anthropicの「Effective context engineering」では、コンテキストに「何を入れるか」の設計がウィンドウサイズと同等以上に重要とされます。不要な履歴・重複・ノイズを除去するコンテキストキュレーションが品質を左右します。
200K vs 1Mトークン——モデル別の使い分けは何か
Opus 4.6以降は1Mトークンに対応しますが、通常業務は200Kで設計し、大規模文書横断推論の場合のみ1Mに切り替えます。
Claude APIのコンテキストウィンドウはモデルによって異なります。
| モデル | コンテキストウィンドウ |
|---|---|
| Claude Opus 4.8 / 4.7 / 4.6 | 1Mトークン |
| Claude Sonnet 4.6 | 1Mトークン |
| Claude Fable 5 / Mythos 5 | 1Mトークン |
| Claude Sonnet 4.5、Haiku 4.5 等 | 200Kトークン |
ただし1Mを使う場合は注意が必要です。200Kを超えるリクエストにはプレミアム料金（入力2倍・出力1.5倍）が適用されます。また、長文脈での精度は「MRCR（Multi-turn Retrieval Coherence Rate）」ベンチマークで確認できます。Claude Opus 4.6はMRCR v2で76%のスコアを記録し——前世代の18.5%から大幅向上——Anthropicが「定性的な転換点」と表現するほどの実効的長文脈能力を持ちます。
設計指針:
- 通常のチャット・エージェントセッション: 200Kで設計し、セッション管理でウィンドウを制御する
- 大規模文書全体への推論（法的文書・コードベース・研究論文群）: 1Mが有効な候補
- 動的データへのアクセス: 長文脈よりRAGを検討する
長文脈とRAGはどう使い分けるか
長文脈は静的な単一大規模文書に有利で、動的・多様なデータセットではRAGがコストと精度で優位に立ちます。
長文脈とRAGは競合ではなく、タスクの性質によって使い分けるアーキテクチャ選択です。
長文脈が有利な場面
- 静的で変化しない大規模文書: 契約書全体・コードリポジトリ全体・財務諸表セットを一括して推論させたい場合。文書間の依存関係・構造的なパターンを把握した上での推論が求められる
- 完全な文脈が必要なタスク: 「文書全体のすべての矛盾点を列挙する」のような、部分的な検索では答えられない問い
RAGが有利な場面
- 動的・更新頻度の高いデータ: 製品カタログ・社内ナレッジ・法令データベースなど、毎日更新が発生するデータソース
- 多様な情報源からの精密な事実検索: ソース帰属が必要な質疑応答。RAGはレスポンスの根拠となった文書を明示できる
- コスト感応型のユースケース: 検索スタイルのクエリでは、RAGのほうが大幅に低コストで運用できる
ハイブリッドアプローチ: 本番システムでは「RAGで候補文書を絞り込み、選ばれた文書をコンテキストに展開して推論させる」Agentic RAGが増えています。長文脈能力とRAGの検索効率を組み合わせたパターンです。
Context Awarenessとコンパクション——長時間エージェント設計は何か
Context Awarenessを持つモデルはトークン残量を自己認識し、コンパクションで200K/1M制限を超えた長時間セッションを継続できます。
Context Awareness（Sonnet 4.6 / 4.5 / Haiku 4.5）
Claude Sonnet 4.6・4.5・Haiku 4.5はContext Awarenessを搭載しています。セッション開始時にモデルはトークン予算を受け取り、ツール呼び出しのたびに残量を更新します。
```xml
```
これにより「残り何トークンあるか分からない状態での曖昧な判断」がなくなり、エージェントが最後まで集中してタスクを継続できます。エージェントハーネス設計と組み合わせることで、長時間セッションの品質が向上します。
サーバーサイドコンパクション
コンテキストウィンドウ制限に近づいた場合、サーバーサイドコンパクションが推奨の管理戦略です。これは会話履歴の古い部分をAPIが自動的に要約・圧縮することで、200K/1Mを超えた長時間会話を継続可能にします（Claude Fable 5、Mythos 5、Opus 4.8/4.7/4.6、Sonnet 4.6でベータ提供）。
手動での文脈管理（ツール結果のクリア・思考ブロックのクリア）は、コンパクションで対応できない特殊なケース向けのオプションです。
なお、Extended ThinkingとContext Windowの関係：思考ブロック（
規模別の留意点（SMB / エンタープライズ）
SMBの場合: コスト管理の観点から、まず200Kモデルで設計し、「長文脈が絶対に必要」と判断できる具体的なユースケースが特定されてから1Mモデルへ移行するアプローチが現実的です。Kuuのai-opsサービスでは適切なモデル選定と設計支援を提供しています。
エンタープライズの場合: 複数チームが異なるモデルを使う環境では、1Mトークンのコストプレミアムが組織横断で積み上がります。AI FinOpsの観点でモデルごとのコンテキスト利用を計装し、1Mモードの適用範囲をガバナンスで管理することが重要です。大規模エンタープライズでの長文脈設計はKuuのrdeサービスを参照してください。
参考
- Context windows — Claude API Documentation | Anthropic
- RAG vs Large Context Window: Real Trade-offs for AI Apps | Redis
- Effective Context Engineering for AI Agents | Anthropic Engineering Blog
まとめ
長文脈モデルのコンテキストウィンドウは「詰め込める上限」であり、Context Rotにより精度は文脈量が増えるほど劣化します。200Kは通常業務の設計基準として、1Mは静的大規模文書への全体推論など特定のユースケースに限定して使い分けます。動的データや事実検索にはRAGが依然として有利で、ハイブリッドのAgentic RAGが本番での主流になっています。Context AwarenessとサーバーサイドコンパクションはLLMの制限を超えた長時間エージェントセッションを支える設計基盤です。
長文脈設計を含むAIエージェントの実装相談は、Kuu株式会社のai-opsサービスまでお問い合わせください。