100万トークンのコンテキストウィンドウ。聞こえはいい。だが「全部渡せばいい」と思った瞬間、高い請求書と低い精度の組み合わせが待っている。
100万トークンとは何か
100万トークンとは、日本語で書かれた文庫本に換算すると約1,250冊分に相当する量だ。A4用紙で約2,000枚、中規模のWebアプリのコードベースなら丸ごと入る。
これを実現したのが、2026年2月5日に公開されたClaude Opus 4.6だ。Anthropicが1Mトークン対応として公開しているモデルは、Opus 4.6とSonnet 4.6、Sonnet 4.5、Sonnet 4の合計4モデル。いずれも現時点ではベータ扱いで、APIで使うにはanthropic-beta: context-1m-2025-08-07ヘッダーが必要になる。
# ✅ 1Mコンテキストウィンドウを有効にするAPIコール
import anthropic
client = anthropic.Anthropic()
response = client.beta.messages.create(
model="claude-opus-4-6",
max_tokens=8192,
messages=[{"role": "user", "content": "..."}],
betas=["context-1m-2025-08-07"], # 1Mコンテキストのベータフラグ
)
利用条件もある。公式ドキュメントによると、Usage Tier 4またはカスタムレート制限を持つ組織のみが対象だ。個人アカウントで突然使えるようになるわけではない。
Claude Codeでの対応状況
Claude Code単体で使っている人には朗報がある。Claude Code v2.1.50で1Mコンテキストウィンドウのサポートが正式に追加された。Opus 4.6のFast Modeでは1Mトークン全体を追加の長コンテキスト料金なしで使える。環境変数CLAUDE_CODE_DISABLE_1M_CONTEXTをセットすれば無効化も可能だ。
「渡せる」と「使える」は別の話
ここが重要な部分だ。1Mトークン渡せることと、渡した1Mトークンを正確に活用できることは、まったく別の問題だ。
Anthropicが公式発表で示したMRCR v2（8-needle、1Mトークン版）のベンチマークスコアを見てほしい。
| モデル | MRCR v2スコア（1Mトークン） |
|---|---|
| Opus 4.6 | 76% |
| Sonnet 4.5 | 18.5% |
76%という数字は現行モデルの中では最高水準だが、同じOpus 4.6でも256Kトークン時は93%に達する。100万トークン使えるからといって、256Kの精度は出ない。
MRCR（Multi-Range Citation Recall）は、長い文書の中に埋め込んだ複数の「針」を正確に取り出せるかを測るベンチマークだ。100万冊の本の中から特定のページを8箇所同時に見つけてこいという試験に近い。76%は8個中6個弱を正確に見つけられるということだ。
Anthropicの76%はAnthropicによる自社計測の数値であり、独立した第三者機関による検証はまだ公開されていない。一次ソースとして引用しつつも、独立検証を待つのが誠実な姿勢だ。
コンテキスト腐敗（Context Rot）という現実
「渡せる量が増えた」ことと「精度が維持される」ことは別の問題だ。これを研究したのがChromaのリサーチチームで、Context Rotと名づけた現象がある。
18のLLMを測定した結果、わかったことがある。モデルはコンテキストを均一に使用しない。入力が長くなるほど、パフォーマンスが不安定になる。特に問題になるのが「Lost in the Middle」効果だ。コンテキストの中間に埋まった情報は、先頭や末尾に比べて取り出しにくい。
鍋に全食材を放り込んだとき、本当に必要な食材の味が埋もれてしまうイメージに近い。材料が多いほど、必要なものが見つからなくなる。
Anthropicが公表しているのはEffective Context Engineeringという考え方だ。コンテキストの目標は「最大量ではなく最小の高シグナルトークンセット」だとAnthropicのエンジニアリングチームは明言している。「全部渡す」はアンチパターンだ。
実際に有効な3つのユースケース
大規模コンテキストが本当に威力を発揮する場面は限られている。
セキュリティ監査
認証ロジック、ミドルウェア、APIルート、データベーススキーマ——これらを別々に渡すと、コンポーネント間の依存関係や認可フローの抜けを見逃しやすい。一括で渡すことで、「ここで認証しているが、別のAPIエンドポイントを経由すると迂回できる」という横断的な脆弱性を検出できる。
大規模なコードベース移行
Next.js 14から16へのアップグレード、TypeScript 5の新機能への対応、Reactのレガシーパターンからモダン構成への移行。影響範囲を一度に把握して一貫した変更を生成するのに、大規模コンテキストは向いている。
レガシーコードの解読
ドキュメントが存在しない数年前のコードベースを理解するのに使える。関連ファイルを一度に渡して「このシステムがどう動いているか」を説明させるのは、1万行ずつ渡すより効果的だ。
RAGと大規模コンテキスト、どちらを使うか
1Mトークン対応が注目される中で、「じゃあRAGはもう要らない」と考える人もいる。現実はそう単純ではない。
RAG（Retrieval-Augmented Generation）は必要な情報だけを動的に取得してコンテキストに含める仕組みだ。一方、1Mコンテキストウィンドウは大きな情報をまるごと渡す。
Redisの調査によると、RAGの応答時間は50〜200ms程度（ベクトル検索含む）だが、1Mコンテキストの同等タスクでは30〜60秒かかる場合もある。Sitepointの分析では、典型的な企業の内部文書（Wiki、ポリシー、製品カタログ）は500K以下のことが多く、「そもそも大きなデータ問題ではない」と指摘している。
Meilisearchがまとめている使い分けは明快だ。大規模なドキュメントを一発で処理したいときや、複数ファイルにまたがる論理推論が必要なときは1Mコンテキストが有利。コストと速度が重要で、かつ情報が継続的に更新されるような場面はRAGが有利だ。
コスト計算の罠——200Kを超えた瞬間の話
1Mコンテキストを使うとき、最も見落としやすいコストの仕組みがある。Anthropicの料金ページに明記されているが、見過ごしやすい。
200Kトークンを超えたリクエストは、超えた分だけでなく全トークンが長コンテキスト料金で請求される。
| モデル | 標準（≤200K） | 長コンテキスト（>200K） |
|---|---|---|
| Opus 4.6 入力 | $5/MTok | $10/MTok |
| Opus 4.6 出力 | $25/MTok | $37.50/MTok |
| Sonnet 4.6 入力 | $3/MTok | $6/MTok |
| Sonnet 4.6 出力 | $15/MTok | $22.50/MTok |
たとえば199,999トークンのリクエストなら$0.9999（Opus 4.6入力）。200,001トークンになった瞬間、そのリクエスト全体が$2.0000になる。1トークン増えただけで2倍になる。
# ❌ 無策にコードベース全体を渡す（500Kトークン想定）
with open("entire_codebase.txt") as f:
context = f.read() # 500K tokens → $5.00/リクエスト（Opus 4.6入力）
response = client.beta.messages.create(
model="claude-opus-4-6",
messages=[{"role": "user", "content": f"{context}\n\nバグを修正して"}],
betas=["context-1m-2025-08-07"],
)
# ✅ 関連ファイルだけを渡す（10Kトークン想定）
relevant_files = ["src/auth/middleware.ts", "src/api/user.ts", "src/types/auth.ts"]
context = "\n".join(open(f).read() for f in relevant_files)
# 10K tokens → $0.05/リクエスト（Opus 4.6入力）
# 50倍安く、関連情報だけなので精度が上がる可能性が高い
response = client.messages.create( # ベータフラグ不要
model="claude-opus-4-6",
messages=[{"role": "user", "content": f"{context}\n\nバグを修正して"}],
)
コスト削減の選択肢は他にもある。Batch APIを使えば50%割引が適用される（長コンテキスト料金にも適用）。プロンプトキャッシュを活用すれば、キャッシュヒット時は入力料金の0.1倍（最大90%削減）になる。
実践的なアプローチ——CLAUDE.md + RAG + Compaction
Anthropicのエンジニアリングブログが推奨しているハイブリッド戦略は、3つの層に分けてコンテキストを管理することだ。
# 第1層: CLAUDE.md（常にコンテキストに含まれる軽量ガイド）
プロジェクト概要
主要ファイルの場所（src/auth/, src/api/, src/models/）
コーディング規約の要点
# 第2層: 実行時の動的ロード（grepやglobで必要なファイルだけ取得）
$ grep -r "handleLogin" src/ --include="*.ts" # 関連ファイルを特定
→ 特定された5〜10ファイルだけをコンテキストに含める
# 第3層: Compaction API（長いセッションのコンテキスト圧縮）
ベータヘッダー: compact-2026-01-12
しきい値（デフォルト100K）に達したら古いコンテキストを自動でサマリーに圧縮
2026年2月5日にCompaction APIがベータ公開された。サーバーサイドで古いコンテキストを自動要約してトークンを節約する仕組みだ。Claude Codeでは古いツール出力を先に削除し、その後に会話を要約する。
一点注意がある。CLAUDE.mdやルール定義を会話の早い段階に置いていると、Compaction時に失われる可能性がある。永続させたいルールはCLAUDE.mdに書き、常にコンテキストの最初に来るようにしておくことが重要だ。
整理すると
図書館に入って、全部の本を声に出して読んでから質問に答えるのは誰でも非効率だとわかる。それより司書に「○○の本ありますか」と聞いた方が速くて正確だ。1Mコンテキストウィンドウは全部の本を渡せるようになったが、司書に聞く方が速い場面は依然として多い。
1Mコンテキストが威力を発揮するのは、横断的な関係性を一度に把握しなければならないとき——セキュリティ監査、大規模移行、レガシー解読——に限られる。日常的なコード補完やバグ修正では、必要なファイルだけを渡す方が速くて安くて精度が高い。
200Kトークンの壁を越える前に、本当に越える必要があるかを考えてほしい。その判断が、請求書の額を大きく変える。