# 長文脈モデルの活用設計——200K/1Mトークンの使いどころ

> 長文脈モデルのコンテキストウィンドウ活用設計を解説。Context Rot現象、200K/1Mモデルの選択、RAGとのトレードオフ、Context Awareness、コンパクションを実装パターンで示します。

- Canonical: https://kuucorp.com/blog/long-context-window-design-patterns/
- Date: 2026-06-15
- Last modified: 2026-06-15
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
「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](/blog/rag-vs-tool-use-agent-design/)を検討する

## 長文脈と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
<!-- セッション開始時 -->
<budget:token_budget>1000000</budget:token_budget>

<!-- ツール呼び出し後の更新 -->
<system_warning>Token usage: 35000/1000000; 965000 remaining</system_warning>
```

これにより「残り何トークンあるか分からない状態での曖昧な判断」がなくなり、エージェントが最後まで集中してタスクを継続できます。[エージェントハーネス設計](/blog/agent-harness-state-management-retry-design/)と組み合わせることで、長時間セッションの品質が向上します。

### サーバーサイドコンパクション

コンテキストウィンドウ制限に近づいた場合、**サーバーサイドコンパクション**が推奨の管理戦略です。これは会話履歴の古い部分をAPIが自動的に要約・圧縮することで、200K/1Mを超えた長時間会話を継続可能にします（Claude Fable 5、Mythos 5、Opus 4.8/4.7/4.6、Sonnet 4.6でベータ提供）。

手動での文脈管理（ツール結果のクリア・思考ブロックのクリア）は、コンパクションで対応できない特殊なケース向けのオプションです。

なお、Extended ThinkingとContext Windowの関係：思考ブロック（`<thinking>`）は生成時にのみ課金され、後続ターンのコンテキストからは自動的に除外されます。トークン節約の観点から見て、Extended Thinking使用時に思考ブロックを手動で取り除く必要はありません。

### 規模別の留意点（SMB / エンタープライズ）

**SMBの場合**: コスト管理の観点から、まず200Kモデルで設計し、「長文脈が絶対に必要」と判断できる具体的なユースケースが特定されてから1Mモデルへ移行するアプローチが現実的です。[Kuuのai-opsサービス](/services/ai-ops/)では適切なモデル選定と設計支援を提供しています。

**エンタープライズの場合**: 複数チームが異なるモデルを使う環境では、1Mトークンのコストプレミアムが組織横断で積み上がります。[AI FinOps](/blog/ai-finops-token-cost-instrumentation/)の観点でモデルごとのコンテキスト利用を計装し、1Mモードの適用範囲をガバナンスで管理することが重要です。大規模エンタープライズでの長文脈設計は[Kuuのrdeサービス](/services/rde/)を参照してください。

## 参考

- [Context windows — Claude API Documentation | Anthropic](https://platform.claude.com/docs/en/build-with-claude/context-windows)
- [RAG vs Large Context Window: Real Trade-offs for AI Apps | Redis](https://redis.io/blog/rag-vs-large-context-window-ai-apps/)
- [Effective Context Engineering for AI Agents | Anthropic Engineering Blog](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

## まとめ

長文脈モデルのコンテキストウィンドウは「詰め込める上限」であり、Context Rotにより精度は文脈量が増えるほど劣化します。200Kは通常業務の設計基準として、1Mは静的大規模文書への全体推論など特定のユースケースに限定して使い分けます。動的データや事実検索にはRAGが依然として有利で、ハイブリッドのAgentic RAGが本番での主流になっています。Context AwarenessとサーバーサイドコンパクションはLLMの制限を超えた長時間エージェントセッションを支える設計基盤です。

長文脈設計を含むAIエージェントの実装相談は、[Kuu株式会社のai-opsサービス](/services/ai-ops/)までお問い合わせください。