50ページの契約書をAIに読み込ませて要約させたところ、後半にある重要な条項がまるごと抜け落ちていた。
上司に指摘されて確認すると、たしかにAIの回答には前半の内容しか反映されていなかった。
こうした経験に心当たりがないでしょうか。
この現象の背景には、AIが一度に読める範囲を定める『コンテキストウィンドウ』という仕組みがあります。
近年のAIはコンテキストウィンドウを急速に広げてきましたが、範囲が広がったからといって、渡した文章のすべてを均等に読んでいるとは限りません。
この記事では、業務自動化の構築設計で長文資料を扱う際に使っている判断基準をもとに、コンテキストウィンドウとは何かという基本の定義と、上限に達していないのに内容が抜け落ちる理由を整理しています。
あわせて、主要なAIごとの上限の違いと、長文を扱う業務での分割と要約の判断基準もまとめています。
コンテキストウィンドウとは何か？AIが一度に読める範囲の意味
コンテキストウィンドウとは、AIが1回のやり取りで参照できるテキストの範囲のことです。
質問文、渡した資料、それまでの会話履歴、AIが生成する回答まで、すべてがこの範囲の中に収まっている必要があります。
AIは文章を『トークン』という単位に分割して処理します。
トークンは単語というよりも、単語の一部や記号を含む処理上の最小単位です。
日本語の場合は1文字が1～2トークン程度に相当することが多く、英語の場合は1単語がおおよそ1トークンになります。
コンテキストウィンドウの上限は、このトークン数の合計で決まります。
トークンの数え方や課金との関係は、以下で詳しく整理しています。
たとえば上限が10万トークンのAIであれば、質問文と資料と会話履歴と回答を合わせて10万トークンを超えると、それ以上の情報は範囲の外に出ます。
範囲の外に出た部分は、AIにとって存在しないのと同じ扱いになります。
冒頭で挙げた契約書の例では、資料そのものは上限に収まっていたにもかかわらず、後半の条項が抜け落ちていました。
次の見出しでは、上限を超えていないのに起きるこの現象の理由を整理します。
コンテキストウィンドウの上限内でも情報が抜け落ちるのはなぜか？
コンテキストウィンドウの上限内に収まっていても、AIは渡された文章のすべてを同じ重みで扱っているわけではありません。
文章の中での位置によって、AIが参照する精度に差が出ることが分かっています。
この差が生まれる背景には、上限を超えた場合の単純な切り捨てと、上限内で起きる精度の偏りという、2つの異なる現象があります。
前者は範囲外の情報が物理的に消えるのに対し、後者は範囲内にあるのに扱いが薄くなる現象です。
契約書の後半が抜け落ちた原因は、資料の分量そのものよりも後者に近い可能性があります。
以下でそれぞれの中身を分けて見ていきます。
上限に達すると何が起こるか
上限に達すると、AIは古い情報から順に範囲の外へ押し出すか、そもそも入力を受け付けずにエラーを返します。
チャット形式のAIで長時間やり取りを続けた際に、最初のほうで伝えた前提を急に忘れたように見えるのは、この切り捨てが原因であることが多くあります。
たとえば会議の議事録を1時間分ずつ追記しながらAIに要約させ続けると、上限に近づいた時点で冒頭の発言内容が範囲外に押し出され、それ以降の回答には反映されなくなります。
この場合は資料を分割して都度要約を取るか、新しい会話に切り替えて要点だけを引き継ぐといった対応が必要です。
上限を大きく超えるほど分量が多い資料を1回で読ませようとする使い方は、この切り捨てが最も起きやすい条件です。
上限の内側でも起こるLost-in-the-Middle
コンテキストウィンドウの上限内であっても、文章の中央付近に置かれた情報は、冒頭や末尾に置かれた情報より見落とされやすい傾向が報告されています。
この現象は『Lost-in-the-Middle』と呼ばれています。
原因は、AIの内部で使われている注意機構（文章のどの部分を重視するかを決める仕組み）が、すべての位置を均等に評価するわけではない点にあります。
冒頭の指示や末尾の直近の文脈には注意が向きやすい一方、大量の文章の途中に埋もれた1段落は相対的に軽視されがちです。
冒頭で挙げた契約書の例で言えば、後半の条項が文章全体の中央付近に位置していた場合、上限に余裕があっても見落としが起きた可能性があります。
実際に数十ページの資料を一括で要約させる運用では、中盤の条件や例外事項が回答から抜け落ちるケースがしばしば見られます。
この現象を避けるには、資料を意味のまとまりで分割し、重要な箇所を冒頭か末尾に近い位置で再確認させる工夫が有効です。
【よくある誤解】容量に余裕があれば見落としは起きない
以前は、コンテキストウィンドウが小さいAIほど見落としが起きやすいという理解が一般的でした。
実際、数千トークンしか扱えなかった世代のAIでは、上限による切り捨てが見落としの主な原因でした。
しかし現在は数十万から百万トークン規模のAIが増え、上限による切り捨ては起きにくくなっています。
一方で、Lost-in-the-Middleによる見落としは上限の大小にかかわらず起こり得ることが分かっています。
容量が大きいAIであっても、資料を渡すだけで見落としがなくなるとは限りません。
数十ページ規模の資料を1回で処理させる場合は、容量に余裕があっても中盤の内容を意識的に確認する運用が必要です。
コンテキストウィンドウの上限は主要AIでどれくらい違うか？
コンテキストウィンドウの上限は、AIの種類や世代によって大きく異なります。
数千トークンしか扱えなかった初期の世代から、現在は百万トークンを超えるAIも登場しています。
| AI | コンテキストウィンドウの上限（目安） |
|---|---|
| 初期のGPT系モデル | 約2,000トークン |
| Claudeの主要モデル | 約20万トークン |
| Google Geminiの一部モデル | 約100万～200万トークン |
出典：各社公式ドキュメント（Anthropic、Google、OpenAI各社の技術資料に基づく2026年7月時点の目安）。上限値は各社のアップデートで随時変更されるため、実際の業務で使う際は利用中のAIの公式ドキュメントで最新値を確認してください。
日本語の文書で考えると、上限が20万トークンのAIであれば、日本語で10万～20万文字程度の文章が目安になります。
ただし、この目安は文章の種類によって前後します。
専門用語や英数字が多い資料はトークンの消費効率が異なるため、同じ文字数でも消費されるトークン数が増減することがあります。
上限の数字だけを見て『大きいAIなら何でも渡せる』と判断するのは早計です。
前の見出しで見た通り、上限内でも見落としは起こります。
次の見出しでは、実際の業務でこの制約とどう付き合うかを整理します。
長文をコンテキストウィンドウの上限内でどう扱うか？
長文を扱う業務でコンテキストウィンドウの制約と付き合う方法は、大きく3つに分かれます。
文章を分割する、要約を段階化する、そして必要な部分だけを都度取り出すRAG（Retrieval-Augmented Generation：検索拡張生成）という仕組みを使う、の3つです。
資料の性質と業務の目的によって、適した方法は異なります。
分割は最も手軽ですが、粒度を誤ると文脈が途切れます。
段階的な要約は精度を保ちやすい一方で手間が増えます。
RAGは大量の資料を継続的に扱う業務に向きますが、環境構築の負担があります。
以下でそれぞれの判断基準を見ていきます。
分割の粒度をどう決めるか
資料を分割する際は、ページ数や文字数で機械的に区切るのではなく、章や条項といった意味のまとまりで区切ることが基本です。
意味の途中で分割すると、前後の文脈が失われて誤読の原因になります。
たとえば50ページの契約書であれば、条項ごとに区切って1条項ずつ要約させ、その後で条項間の関係を確認する使い方が有効です。
一方、数ページ程度の短い資料であれば分割の必要はなく、Lost-in-the-Middleの影響も出にくいため、そのまま一括で読ませて問題ありません。
分割が向かないのは、条項同士が相互に参照し合っていて分割すると意味が通じなくなる資料です。
この場合は分割よりも次に挙げる段階的な要約のほうが適しています。
意味のまとまりで区切る分割の考え方は、チャンキングとして次の記事で詳しく整理しています。
要約を段階化する
段階的な要約とは、資料をいくつかのまとまりに分けてそれぞれを要約し、その要約同士をさらにまとめて全体の要約を作る方法です。
一度に全体を要約させるより手間はかかりますが、中盤の内容が抜け落ちるリスクを抑えられます。
具体的には、まず章ごとに200～300字程度の要約を作らせ、その章別要約をすべて1つの入力にまとめてから、全体の要約を作らせる2段階の手順を踏みます。
各段階の入力が短くなるため、中盤の内容が薄く扱われる条件そのものを避けられるのがこの方法の利点です。
ただし、章ごとの要約の質が低いと、その誤りが全体の要約にそのまま引き継がれます。
章別要約の段階で内容を確認する工程を省略しないことが前提になります。
RAGとの使い分け
RAGは、資料全体をAIに渡すのではなく、質問に関連する部分だけを検索して渡す仕組みです。
契約書1件を単発で処理するような業務では、分割と段階的な要約で十分に対応できます。
RAGが向くのは、社内規程やマニュアルのように継続的に参照する資料が大量にあり、毎回同じ資料群から必要な箇所だけを探したい業務です。
逆に、資料が1件限りで使い捨てに近い場合や、資料同士の全体的なつながりを把握する必要がある場合は、RAGよりも段階的な要約のほうが向いています。
RAGの構築には検索の仕組みを用意する手間がかかるため、月に数件程度しか長文を扱わない業務でRAGから導入するのは負担が見合わないことがあります。
まずは分割と段階的な要約で運用を固め、扱う資料量が増えてから検討する順番が現実的です。
RAGの仕組みそのものについては、以下で詳しく整理しています。
自社の業務でどの方法が向いているか判断に迷う場合は、 個別相談 で資料の量と頻度を整理することもできます。
コンテキストウィンドウの制約が向かない業務・注意が必要な条件
ここまでの分割・段階的な要約・RAGはいずれも有効な対応ですが、業務によっては手間に見合わない場合があります。
向き不向きを判断する基準を整理します。
分割や段階的な要約が向かないのは、資料の分量がそもそも少なく、上限にもLost-in-the-Middleにも余裕がある業務です。
数ページ程度の資料であれば、追加の工程を挟むよりそのまま読ませたほうが速く、見落としのリスクも小さくなります。
逆に、資料の分量が数十ページを超え、かつ資料の中盤に見落としたくない条件や例外事項が集中している業務では、分割と段階的な要約の効果が大きくなります。
RAGの導入を急ぐ必要がないのは、扱う資料が月に数件程度で、資料同士のつながりを都度人が把握できる規模の業務です。
資料の種類や件数が増え、同じ資料群を繰り返し参照する業務が増えてきた段階で、RAGの検討に切り替える進め方が無理のない対応になります。
長文資料のAI活用について相談してみませんか？
「AIに要約を任せたら重要な条項が抜けていた」「上限内のはずなのに内容が偏る理由を説明できない」「社内に長文を扱う運用ルールを設計できる人材がいない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、AI業務自動化に関するお悩みをお伺いする 無料の個別相談 を実施しています。
よくある質問
Q. コンテキストウィンドウの上限はどこで確認できますか？
利用しているAIの提供元が公開している公式ドキュメントで確認できます。
上限値はアップデートのたびに変わることがあるため、契約中のプランやモデル名を確認したうえで、都度最新の情報を見る必要があります。
Q. 上限に近い分量の資料を渡すと処理が遅くなったり失敗したりしますか？
上限に近づくほど処理にかかる時間が長くなる傾向があります。
また、上限をわずかでも超えるとエラーになるか、超えた部分が自動的に切り捨てられる場合があります。
余裕を持たせて上限の7～8割程度に収める使い方が安全です。
Q. 要約を段階化すると、一括で要約させるより時間がかかりますか？
章ごとに要約を作る分、一括要約よりも手順は増えます。
ただし1回あたりの処理時間は短くなるため、資料の分量や重要度に応じて、精度を優先するか速さを優先するかを選ぶ判断になります。
Q. RAGを導入するには専門的な知識が必要ですか？
検索の仕組みを構築する部分は技術的な設定が必要になるため、社内に開発体制がない場合は外部の支援を受けて構築するのが一般的です。
まずは分割と段階的な要約で運用しながら、資料量が増えた段階で導入を検討する進め方が現実的です。
