Claude 1M コンテキストとは｜小説 10 冊分を一括処理する仕組み

Claude の 1M コンテキストウィンドウとは

「コンテキストウィンドウ」とは、Claude が 1 回のリクエストで参照できるテキストの総量のことだ。会話履歴・システムプロンプト・添付ドキュメント・ツール定義・Claude 自身の出力をすべて合算した値がこの上限内に収まる必要がある。

Claude の標準コンテキストウィンドウはかつて 200k トークンだった。1M（100 万）トークンコンテキストウィンドウは、この上限を 5 倍に拡張した機能だ。Anthropic 公式ドキュメントによると、2026 年 3 月にリリースノートで「Claude Opus 4.6 と Sonnet 4.6 において標準料金で一般公開(GA)」が宣言され、ベータヘッダーなしで利用できるようになった。

GA 以前は context-1m-2025-08-07 というベータヘッダーを付けてリクエストを送る必要があり、長文脈専用のレートリミットも存在した。GA 後は通常のリクエストと同じ手順で 1M コンテキストが使えるため、実装の敷居が大幅に下がっている。

1M トークンはどれくらいの量か——実感値で把握する

トークンは文字数とは異なるが、おおよその目安として次の変換が使える。

英語テキストでは 1 トークン ≈ 0.75 語が目安で、1M トークン ≈ 75 万語となる。一般的な英語の長編小説が 7〜10 万語のため、1M トークン ≈ 小説 8〜10 冊分に相当する。

日本語は漢字・かな交じりのため 1 文字あたり 1〜2 トークンを消費する。実験的な目安として、1M トークン ≈ 50〜100 万日本語文字ほどになる。文庫本 1 冊が約 10〜15 万文字のため、1M トークン ≈ 日本語文庫本 5〜10 冊分と見ておくと感覚がつかみやすい。

コードの場合はさらに効率が良い。一般的なソースファイルを集約すると、数万行規模のコードベース全体を 1M トークンの中に収められることが多い。大規模な Python や TypeScript プロジェクトでも、依存ファイルを除いたアプリ本体なら多くのケースで収まる計算になる。

PDF や画像も混在できる。公式ドキュメントによると、1M コンテキストモデルでは 1 リクエストあたり最大 600 画像または 600 PDF ページを含められる（200k モデルは 100 枚・ページまで）。

対応モデルと上限サイズ一覧

Anthropic の公式ドキュメントによると、2026 年 7 月時点で 1M トークンコンテキストウィンドウに対応しているモデルは以下のとおりだ。

Sonnet 4.5 以前・Haiku 系のモデルは 200k が上限で、1M コンテキストには対応していない。1M を使いたい場合は Sonnet 4.6 以降または Opus 系モデルを選択する。

料金——長文脈サーチャージは不要になった

GA 以前のベータ期間中、1M コンテキストを利用するには「200k トークンを超えた分に追加の長文脈料金がかかる」という仕組みがあった。GA 後はこの追加料金が廃止され、標準の入出力トークン料金のみで利用できる。

たとえば Sonnet 4.6（$3 / $15 per MTok）を使って 900k トークンのリクエストを送っても、9k トークンのリクエストと同一の単価が適用される。コンテキストが増えたからといって割増にはならない。

コスト最適化にはプロンプトキャッシュの活用が有効だ。変更の少いシステムプロンプトや参照ドキュメントをキャッシュすれば、繰り返しリクエストでの入力コストを大幅に削減できる。公式プロンプトキャッシュドキュメントに詳しい設定方法が記載されている。

なお、claude.ai の有料プランでは、ウェブ UI 上のコンテキスト上限がモデルやプランによって異なる場合がある。API 経由と比べて上限が異なることがあるため、大量の文脈を扱う場合は API 経由での利用を推奨する。

主要ユースケース——1M コンテキストで実現できること

1M トークンが GA になったことで、以前は「理論的にはできるがリスクがあった」操作が本番品質で使えるようになった。代表的なユースケースを挙げる。

大規模コードベースの一括レビュー: 数万行規模のプロジェクト全体をそのままコンテキストに流し込み、依存関係の問題・セキュリティ上の懸念・設計上の矛盾を一括で検出できる。チャンク分割や RAG の前処理が不要なため、実装コストが大きく下がる。

長大ドキュメントへのクロス検索: 数百ページの仕様書・法的文書・論文群を一括で投入し、特定条件に該当する箇所を横断検索できる。従来はチャンク単位で処理する必要があったが、1M コンテキストがあれば文書全体の文脈を保ったまま回答が得られる。

複数ファイルにまたがるリファクタリング支援: 関数・クラス・設定ファイルが複数モジュールに分散しているプロジェクトでも、すべてのファイル内容を一つのコンテキストに詰め込んで整合性のある変更指示を出せる。

長時間エージェントの文脈保持: Anthropic の Jon Bell CPO は GA 後のデータとして「コンパクションイベント（文脈を圧縮して切り捨てる処理）が 15% 減少した」と報告している。1M コンテキストにより、エージェントが長時間タスクを実行する際に情報を保ち続けやすくなった。

書類・研究論文の精読支援: 複数の論文や書類を束にして渡し「この主張はどの文献に根拠があるか」「矛盾する記述はどれか」といった横断的な質問ができる。

「コンテキストロット」——長文脈の品質に注意する

1M コンテキストが使えることは「大きいほど良い」を意味しない。公式ドキュメントは明示的に次のように警告している。

コンテキストが増えるにつれて、精度と再現性が低下する（"context rot" と呼ばれる現象）。コンテキストウィンドウにどれだけの空き容量があるかと同様に、何をコンテキストに入れるかをキュレーションすることが重要である。

「Lost in the middle」と呼ばれる現象も知られており、コンテキストの中央付近に配置した情報は、先頭・末尾に比べてモデルに参照されにくくなる傾向がある。

実用上は次の点に注意すると品質を維持しやすい。

1. 直接関係する情報だけをコンテキストに入れ、無関係なファイルは除外する
2. 重要な情報はコンテキストの先頭または末尾に配置する
3. 大量の情報を流し込む前に、まず小さいサブセットで期待通りの回答が得られるか確認する
4. 出力の品質が低下してきたら、コンテキストを整理して新しいセッションを始める

API での利用方法

GA 以降、1M コンテキストの利用に特別な設定は不要だ。対応モデルを指定してリクエストを送れば、自動的に 1M コンテキストが有効になる。

import anthropic

client = anthropic.Anthropic()

with open("large_codebase.txt", "r") as f:
    code_content = f.read()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=8192,
    messages=[
        {
            "role": "user",
            "content": f"以下のコードベースを審査し、セキュリティ上の懸念点を列挙してください:\n\n{code_content}"
        }
    ]
)

print(response.content)

かつて必要だった anthropic-beta: context-1m-2025-08-07 ヘッダーは不要になった（付けても無視される）。また、コンテキストが何トークンになるかを事前に確認したい場合はトークンカウント APIを使うと送信前に推定できる。

長大なリクエストが context window を超えて止まった場合、stop_reason: "model_context_window_exceeded" が返る（Claude 4.5 以降のモデル）。この挙動については公式ドキュメントの overflow behavior のセクションを参照されたい。

出典

• Context windows — Claude Platform Docs
• Claude Platform Release Notes
• Claude Context Window Size 2026: What 1 Million Tokens Actually Means — Tygart Media