結論：1Mトークンでも、全部入れる設計にしない

先に答えると、Claudeのコンテキストウィンドウは「読み込める資料の最大容量」ではなく、応答を作る間に参照する作業領域です。2026年8月3日のAnthropic公式文書では、Claude Opus 5、Fable 5、Sonnet 5などは1Mトークンに対応します。ただし、容量内へ収まれば精度が一定になるわけではありません。公式文書も、文脈が増えるほど正確性や想起が低下するcontext rotに注意し、何を残すかの設計が重要だと説明しています。

読者の具体的な困りごとは、長い会話と資料を足し続け、根拠の取り違え、古い指示の混入、費用増、上限エラーの原因を説明できないことです。読了後は、入力を目的・根拠・履歴・ツール結果へ分け、残す、要約する、別セッションへ移す判断ができます。次の行動は、実際の一業務について「最終判断に必要な資料」を五件以内で書き出すことです。

何がコンテキストへ入るのか

Claude APIでは、system prompt、messages内の過去の会話、現在の依頼、画像やPDF、ツール定義、ツール実行結果が入力として数えられます。今回生成する回答やthinkingも上限へ影響します。Prompt Cachingを使っても、支払う単価は変えられますが、キャッシュ部分がコンテキストから消えるわけではありません。料金削減と容量管理を同じものとして扱わないことが重要です。

1Mトークン対応モデルは、単一リクエストで最大128kの出力を生成できますが、入力と出力が同じ作業領域を使います。大量の画像やPDFでは、トークン上限より先にリクエストサイズ制限へ当たる場合もあります。入力だけが上限を超えると400のinvalid_request_errorとなり、新しいモデルでは生成中に上限へ達するとmodel_context_window_exceededで停止する場合があります。

会話画面とAPIでも挙動は同一とは限りません。claude.aiは古い会話をローリング管理することがあり、APIでは送った履歴がそのまま入力になります。画面上で続いて見えることと、必要な根拠が確実に残っていることを分けて確認します。

長文で精度を落とす三つの原因

  1. 目的が複数ある：調査、比較、草案、承認を一度に頼み、評価基準が競合します。
  2. 根拠の優先順位がない：最新版と旧版、一次情報とメモ、確定事項と仮説が同じ重さで入ります。
  3. 履歴が成果物になっていない：会話は長いのに、決定、未決、次の作業を再利用できる形で残していません。

長い入力で起きる問題は、単純な「忘却」だけではありません。重要な一文が中ほどへ埋もれる、似た名称を取り違える、古い指示を優先する、ツール結果のノイズへ引っ張られる、といった形で現れます。そのため評価は、回答が生成できたかではなく、指定した根拠を引用したか、最新版を選んだか、禁止事項を守ったかで行います。

長い資料を扱う7手順

  1. 一回の依頼で答える質問を一つにし、完了条件を一文で書きます。
  2. 資料を正本、参考、履歴、未確認へ分類し、正本を先に置きます。
  3. Token Countingで、指示、会話、資料、ツール定義を含む入力を見積もります。
  4. 全文が不要な資料は、見出し、対象期間、必要箇所を指定して絞ります。
  5. 途中成果を「決定／根拠／未決／次の作業」の四項目で保存します。
  6. 古いツール結果や完了済みの探索は消し、必要ならcompactionやcontext editingを使います。
  7. 新しいセッションで成果物を読み戻し、元の質問へ同じ答えが出るか確認します。

分割は文字数だけで行いません。契約書なら条項と判断論点、会議記録なら決定と宿題、コードなら機能境界とテスト、調査なら主張と一次情報で区切ります。区切りごとに出典、日付、版を残すと、次のセッションで復元しやすくなります。

中間成果には、元資料の要約だけでなく「採用しなかった情報」と理由も残します。たとえば旧料金表を除外した、担当者の推測は根拠に使わなかった、未確認の数値は空欄にした、と記録します。次の会話が短くても判断の境界を再現でき、同じ探索を繰り返す費用も減らせます。再開テストでは、成果物だけを新しい会話へ渡し、重要な制約が一つでも抜けるなら要約形式を改善します。

compaction、context editing、キャッシュの使い分け

長時間の会話やエージェント業務では、公式文書はserver-side compactionを主要な管理策として案内しています。過去部分を要約しながら会話を継続する仕組みですが、要約後も重要な数値や禁止事項が残っているかを評価します。Claude 4.6以降などでベータ提供されるため、対象モデルとAPI条件を実装前に再確認します。

context editingは、古いツール結果やthinking blockなど特定要素を整理する選択肢です。一方Prompt Cachingは、同じ前置きを繰り返す費用と遅延を減らす機能で、容量そのものを空けません。目的が「上限回避」「精度維持」「料金削減」のどれかを先に決め、機能名だけで選ばないようにします。

公開・本番前チェックリスト

質問は一つか／正本と旧版を区別したか／日付と版があるか／必要箇所だけを入れたか／入力と最大出力を見積もったか／ツール結果を無制限に残していないか／決定と未決を成果物化したか／再開時に読み戻せるか／長文の代表例で引用と禁止事項を評価したか、を確認します。

1Mという上限は、整理を不要にする数字ではありません。むしろ長い業務ほど、正本、優先順位、中間成果、停止条件を明示した方が再現性を上げられます。費用の分解はClaude API料金の削減手順、モデル差はClaude API最新モデル比較、入力情報の分類はClaudeに入力してはいけない情報も参照してください。

よくある質問

1Mトークンは何文字ですか？

言語や内容で変わるため固定の文字数へ換算しません。公式モデル表は目安を示しますが、実装ではToken Countingで実データを測ります。

Prompt Cachingで上限を回避できますか？

できません。キャッシュ済み入力もコンテキストへ数えられます。キャッシュは主に費用と遅延の改善です。

長い会話はいつ切り替えるべきですか？

質問や正本が変わる時、古いツール結果が増えた時、決定事項を成果物化できた時が区切りです。新しい会話へ要点と根拠を渡します。

公式情報と次の一歩

仕様はAnthropic公式Context windows、モデル別の上限は公式Models overview、圧縮設計は公式Compactionで公開直前に確認してください。

Miraigentの無料診断では、長文業務の質問、正本、入力範囲、中間成果、再開条件を一枚にし、詰め込みに頼らないClaude運用へ整理します。