AIモデルのコンテキストウィンドウとは
コンテキストウィンドウは、言語モデルが1回のリクエストで「見る」テキスト量です。プロンプト、チャット履歴、アップロードしたドキュメント、モデルの返答が含まれます。コードベース全体、長い契約書、短いチャットだけが1回のAPI呼び出しに収まるかはウィンドウサイズ次第です。以下では、コンテキストウィンドウの意味、トークンでの測り方、モデル選定における重要パラメータである理由を説明します。
わかりやすい定義
コンテキストウィンドウ（context window）は、1リクエストでモデルが処理できる最大トークン数です。トークンは単語でも文字でもなく、トークン化後のテキスト断片です。ロシア語・英語では1トークンはおおよそ3-4文字または語の一部に相当し、「programming」は2-3トークンになることがあります。
モデルは過去のセッションを自動では「覚えません」。回答時点で知っているのは、現在のリクエストでウィンドウ内に渡した内容だけです。対話やドキュメントが上限を超えると、古い部分が切り捨てられるか、別手法（RAG、要約、チャンク分割）で圧縮が必要になります。
実務でのウィンドウの中身
典型的なAPIリクエストのコンテキストには次が含まれます：
- System prompt - モデルへの指示（役割、回答形式、制約）。
- メッセージ履歴 - チャット内の過去の user / assistant ターン。
- 添付 - PDFテキスト、リポジトリのコード、ナレッジベースの断片。
- モデル出力 - 多くのモデルでは返答も1回の呼び出しの総上限にカウントされます。
式は単純です：input + output ≤ コンテキストウィンドウサイズ（input と output を別上限にするモデルもありますが、1回あたり上限がある点は同じです）。
128Kウィンドウの例：
| 構成要素 | おおよその量 |
|---|---|
| System prompt | 500-2,000 トークン |
| チャット履歴（20メッセージ） | 5,000-15,000 |
| アップロード文書 | 80,000 |
| モデル返答 | 最大 8,000-16,000 |
合計が上限を超えると、APIはエラーを返すか、クライアント次第で履歴の先頭が自動トリムされます。
入力コンテキストと出力コンテキスト
開発者が混同しがちな2つの概念：
- Input context - モデルが受け取るトークン数（プロンプト + 履歴 + ファイル）。
- Max output tokens - 1回の呼び出しでの返答長の上限（
max_tokensなど別APIパラメータ）。
1Mウィンドウのモデルでも input はほぼ100万トークンまで受け付けますが、返答は例えば8K-64Kトークンに制限されることがあります。長いレポートには連続リクエストやストリーミング継続が必要な場合があります。
一部の料金体系では、long-context リクエスト（閾値超え、例：200K input）は高単価 - 推論負荷が大きいためです。
大きなコンテキストウィンドウが重要な理由
1リクエストで関連情報を大量に保持する必要があるとき、大コンテキストが有効です：
- ドキュメント分析 - 契約書、レポート、数十ページの調査を事前圧縮なしで。
- コード作業 - 複数ファイル、スタックトレース、変更履歴を1プロンプトに。
- 長い対話 - サポート・相談で直近10件ではなく会話全体が重要な場合。
- Agenticシナリオ - エージェントが1セッションで観察、ツール呼び出し、中間結果を蓄積。
小ウィンドウ（4K-32K）で足りる短タスク：分類、フォーム項目抽出、段落翻訳、シンプルなチャットボット。ドキュメントとコードを扱うエンタープライズ用途では通常128K以上を検討します。
2026年時点の典型的サイズ
2026年半ば、市場は次の段階に分かれます：
| 段階 | ウィンドウサイズ | 例モデル | 典型タスク |
|---|---|---|---|
| コンパクト | 8K-32K | 軽量ローカルモデル、旧API | チャット、分類 |
| 標準 | 128K-200K | GPT-5.5、Claude Sonnet 5、Gemini 3.1 Pro | コード、文書、エージェント |
| 拡張 | 1M-2M | GPT-5.6、Claude Fable 5、Gemini 3.5 Flash | 大規模リポ、コーパス |
コンテキストは「有用な」長さより速く伸びます。技術的に100万トークンを受け付けても、最長域では品質が落ちることがあります（「lost in the middle」- 長コンテキスト中央の情報をモデルが弱く使う）。大ウィンドウは設計の代替ではなく、能力の拡張です。
制限と回避策
2Mウィンドウでもすべてを1プロンプトに入れる必要はありません：
- コスト - input はトークン課金。1リクエスト100万トークンは本番コストを急増させます。
- レイテンシ - 長コンテキストはGPU処理が長くなります。
- 品質 - 関連事実は500ページの中央に「埋める」より明示的に渡す方がよい。
ウィンドウ不足時や節約の実用パターン：
- RAG（Retrieval-Augmented Generation）- ベクトルDBで関連断片を検索し、それだけをプロンプトに注入。
- 要約 - 古いメッセージや章を別モデル呼び出しで圧縮。
- チャンク分割 - テキストを分割し結果を集約。
- スライディングウィンドウ - 履歴には直近Nメッセージと過去の短い要約のみ。
本番では組み合わせが一般的：ナレッジベースはRAG + 適度なチャット履歴 + 「重い」リクエスト用に128K-1Mモデル。
タスクに応じたウィンドウサイズの選び方
| タスク | 推奨下限 | コメント |
|---|---|---|
| FAQボット、意図分類 | 8K-16K | 履歴短、文書はRAG |
| 1リポジトリ向けCopilot | 128K-1M | コードベースサイズ次第 |
| 法務 / コンプライアンスレビュー | 200K+ | 長PDF、相互参照 |
| マルチモーダル文書 | 1M+ | テキスト + 画像はトークン消費大 |
モデル選定前に 実際の input 量を見積もる：典型リクエストのトークン数（tiktoken、APIトークナイザ、プロバイダの count_tokens）を数え、返答と履歴増分の20-30%余裕を確保。
まとめ
コンテキストウィンドウは、1リクエストにおける言語モデルの「作業記憶」です。トークンで測り、プロンプト、履歴、添付、多くの場合返答用スペースを含みます。大ウィンドウ（128K-2M）は長文書・コードベースを常に切らず分析できますが、RAG、要約、コスト管理の代替にはなりません。選定時はスペックの数字だけでなく、長コンテキスト品質、long-context料金、典型リクエストの実サイズも見てください。
よくある質問
トークンと単語の違いは？
トークンはモデルがトークン化した後のテキスト単位です。1語が1つまたは複数トークンになることもあり、句読点・空白もカウントされます。ロシア語・英語の目安：1000トークン ≈ 750-900語 または 3000-4000文字（言語・モデル依存）。見積もりはWordの語数ではなく、各プロバイダのトークナイザを使ってください。
テキストがコンテキストウィンドウより長いとどうなる？
プラットフォーム依存：APIは「context length exceeded」を返す、履歴の 先頭 を切る（古いメッセージから失われる）、圧縮を提案する、など。モデルはウィンドウ外を「読み進めません」- 上限外の情報は存在しません。対策：RAG、要約、チャンク分割、より大きいウィンドウのモデル。
コンテキストが大きいほど常に良い回答？
いいえ。大ウィンドウはより多く渡す 能力 を与えるだけで、すべてを同等にうまく使う保証はありません。非常に長い入力では中央の事実精度が下がり、コスト・レイテンシが上がりがちです。コーパス全体を「念のため」渡すより、検索や構造化プロンプトで関連コンテキストを渡す方がよいです。
ドキュメントのトークン数はどう数える？
公式ツールを使用：tiktoken（OpenAI互換）、Anthropic tokenizer、Geminiは Google AI Studio、またはプロバイダSDKの count_tokens。概算：テキスト1ページ（約500語）で 650-800トークン 程度。コードや表は特殊記号で文字あたりトークンが増えることがあります。
普通のチャットボットに1Mトークンモデルは必要？
短い返答とFAQの典型チャットボットなら - 不要、32K-128K + ナレッジベースRAGで十分です。1M+は大PDF分析、リポジトリ全体、長いagenticセッション、一貫性を失わず事前分割できないデータ向け。まず本番の実リクエストサイズを測る - 適切な設計なら128Kで足りることも多いです。