コンテキストウィンドウとは?長文を扱うAIの基本

コンテキストウィンドウとは?長文を扱うAIの基本について、用途ごとの考え方と選び方のポイントを整理します。

AIものさし編集部

コンテキストウィンドウとは、モデルが一度の処理で扱えるtokenの範囲です。入力の文字数だけでは決まらず、指示、会話履歴、取得資料、tool結果、画像などの情報と、生成する出力の制限が関係します。上限はモデルやサービスによって異なります。長い文章が入ることと、必要な箇所を正確に理解できることは別です。

文字数ではなくtokenで考える

文章はtokenと呼ばれる単位へ分割されて処理されます。日本語でも、文字数とtoken数は一定の比率になりません。単語、記号、表記、言語、画像などによって変わるため、「日本語なら何文字まで」と固定値で換算するのは危険です。正確な上限を知りたい場合は、利用するmodelやAPIの現行仕様、tokenizerや計測機能を確認します。

コンテキストは質問本文だけではありません。system instruction、過去のやり取り、添付資料から抽出した内容、検索で取得したchunk、toolの結果もモデルへ渡されれば枠を使います。さらに出力のための余地が必要です。入力を上限ぎりぎりにすると、長い回答が途中で止まったり、履歴や重要な条件が省かれたりする場合があります。各サービスで数え方や制限の扱いが同じとは限りません。

何が枠を使うかを整理する

表は横にスクロールできます

要素例長文作業で起きること
固定指示役割、禁止事項、出力形式毎回使うため入力余地を減らす
会話履歴前の質問や回答古い前提も残り、必要情報を押し出す
今回の入力質問、コード、文書大きいほど出力や追加資料の余裕が減る
検索・tool結果Webページ、API response、RAG資料関連性が低い結果が混ざるとnoiseになる
生成する回答要約、表、コード出力tokenの上限や全体枠に影響する

画像や音声などは、画面上のファイルサイズや表示文字数だけでtoken消費を判断できない場合があります。利用サービスの対応形式と計測方法を確認し、添付できることを「全文を同じ条件でモデルが読める」と解釈しないでください。会話サービスでは長くなった履歴を要約・切り詰める挙動があるため、過去の全発言が常に残っていると仮定するのも避けます。

上限に近づくときの症状と対処

表は横にスクロールできます

症状あり得る原因まず行うこと
途中から古い条件を忘れる履歴の一部が省略・要約された現在の目的と必須条件を短く再掲する
文書の後半を見ない入力枠または処理方式の制約対象範囲を分割し、同じ質問で各範囲を確認する
回答が途中で切れる出力枠が小さい、または全体枠を使い切った出力を短くするか、段階ごとに生成する
重要な箇所を取り違える長いcontextに埋もれた、検索結果が不適切根拠箇所を指定して回答と照合する
検索資料が増えるほど答えが散る不要なchunkや重複資料が混在必要な資料・段落だけへ絞る

表は症状から原因を断定する診断表ではありません。製品のエラー表示、request log、token usageなど確認できる情報を先に見て、context上限、検索漏れ、指示の競合を切り分けてください。単にmodelを大きくする、資料をさらに投入する、といった対処は原因を悪化させることがあります。

長文を扱う実務手順

  1. 目的と出力を先に決める:全文要約なのか、契約期間の抽出なのか、比較表なのかを分ける。

  2. 文書の構造を残す:章見出し、表の列、脚注、日付、文書名を保持する。分割だけして位置情報を捨てない。

  3. 質問に関係する範囲を選ぶ:検索を使う場合は、必要な章と条件が同時に取得できるかを確認する。

  4. 出力余地を残す:長い質問や資料を渡すときは、期待する回答の長さと必要情報の優先順位を指定する。

  5. 根拠へ戻る:抽出結果を原文のページ・段落と照合し、数字、否定、例外、適用期間を確認する。

  6. 範囲を変えて再確認する:分割した各部分で同じ質問を行い、最後に矛盾や抜けを統合する。

  7. 不明を残す:資料にない内容を推測で補わず、確認が必要な点として分ける。

例えば100ページの規程から「2026年度に適用される経費上限」を知りたいなら、まず対象年度、部門、費目を特定します。文書全体を一度に渡すより、目次や該当しそうな章を検索し、上限額と適用条件が同じ根拠に含まれるか確認します。回答には金額だけでなく対象期間・例外・参照箇所を残します。ここでの手順は一般的な検証例であり、特定サービスを実際に試した結果ではありません。

context windowと長文理解は別

大きなウィンドウは、一度により多くの入力を扱える可能性を示します。しかし長い資料の全箇所へ均等に注意を向ける、矛盾を必ず検出する、細かな条件を落とさない、と保証する指標ではありません。資料の品質、検索や分割、質問の具体性、出力形式によって結果は変わります。

文書全体の回答が必要なら、代表的な章だけでなく、例外・付属表・変更履歴も含めた評価セットを用意します。最初と最後の箇所に重要条件を置いたテスト、似た語の別制度を含むテスト、答えが資料にないケースを混ぜると、見落としを発見しやすくなります。結果は正答だけでなく、根拠箇所、条件の保持、不明時の停止で確認します。

model上限を調べる順序

具体的なcontext limitを調べる際は、モデル名だけでなく、利用するサービス、モデルsnapshot、APIまたは画面の種類を特定します。提供元の公式model pageやAPI referenceで、入力上限、出力上限、合算条件、画像・tool使用時の扱いを確認してください。上限は更新されることがあり、古い比較表や第三者記事の数値を現行仕様として使わないようにします。

運用では、上限いっぱいまで使うより、余裕を残した要求を設計します。要約を前段に置く場合でも、元資料への参照と未処理範囲を保持します。会話を短くするだけでなく、必要な指示を優先し、古い履歴や重複したtool結果を整理すると回答の焦点を保ちやすくなります。

AIものさしの判断

長文を渡せるかの判断では、最大token数だけでなく、必要条件を取りこぼさず、原文へ戻れるかを確かめます。頻繁に更新する資料は検索で必要部分を取る方法、長い一冊を扱う作業は章ごとの分割と根拠確認が候補です。どの方法でも、重要な数値・否定・例外を原文と照合する工程を残します。

モデルの具体上限は変わるため、利用時の公式仕様を確認してください。利用者の仕事が「一回で全部読む」ではなく「必要な結論を出す」なら、資料全体を毎回投入するより、対象範囲、出力、根拠の残し方を決める方が実務的です。上限に入ったことを、読解精度や正確さの証明として扱わないことが判断の要点です。

長文処理を設計するミニ例

契約書の期間と自動更新条件を調べる場合、最初に「契約開始日・終了日・更新条件・解約期限を、根拠箇所と一緒に抽出する」と出力を定義します。次に文書名、版、ページを保ったまま、契約期間や解約に関係する章を検索します。抽出した日付だけを返させず、適用される条項、例外、原文の位置を合わせて出させます。最後に担当者が原文と照合し、曖昧な条項を自動で結論にしないことを確認します。

文書を分割する場合、章タイトルだけでなく、その章がどの文書・ページに属するかを保持します。たとえば「例外条項」が別の章にあるなら、期限の段落だけを切り出すと条件を失うことがあります。検索された箇所に重要な条件が見当たらないときは、回答へ進まず追加検索するか、人へ確認します。これはモデルが長文を処理できるかではなく、業務上必要な情報を取りこぼさないための設計です。

利用前のチェックリスト

  • 利用する製品、model、model versionを特定した

  • 入力と出力それぞれの制限を公式仕様で確認した

  • 添付資料・画像・tool結果の扱いを確認した

  • 長い履歴で古い前提がどう扱われるか把握した

  • 数値、否定、適用期間、例外を原文へ戻って確認できる

  • 分割・検索を使う場合、文書IDと位置情報を保持する

  • 上限超過や根拠不足のときの応答を決めた

  • 要約を使う場合、元資料と未処理範囲へ戻れる

  • 機密情報を入力・ログ保存する条件を確認した

特に業務文書では、回答の滑らかさより、該当箇所を再確認できることが重要です。質問の対象期間や部門が不明なら、AIに埋めさせず入力者へ確認します。複数文書で記載が矛盾する場合は、文書の日付と優先規則を見て、解決しないものは未確定として残します。

文字数をtoken数へ換算する必要がある場合、一般的な目安は概算にとどめます。日本語文章、コード、表、画像を混ぜた入力は差が出るため、実際のmodelやAPIで利用量を計測します。特定モデルの上限が分かっていても、画面上のファイル容量上限やサービス側の添付制限とは別の制約です。

作業を中断・再開するとき

長い調査を複数回に分ける場合は、各回の終わりに「確認済みの事実」「未確認の範囲」「次に読む箇所」「原文の識別情報」を短く保存します。次回はその記録を原文と照合してから続けます。要約だけを唯一の根拠にすると、否定条件や更新日が落ちたまま作業が進むことがあります。契約や規程のように誤りの影響が大きい資料では、要約を引き継ぎメモとして使い、決定前に該当条文へ戻ってください。

また、処理を分割した結果をまとめるときは、同じ項目が異なる章に記載されていないか、日付や定義が一致しているかを確認します。複数部分から得た結論が食い違えば、AIに都合よく統合させず、どの版や記載を優先するか人が決めます。

引用・データ出典