lost in the middleとは？長文コンテキストで中盤の情報が無視される原因と3つの対策
この記事のポイント ・lost in the middleとは、長い文脈の中盤に置いた情報だけがAIの答えに反映されにくくなる現象です ・コンテキストウィンドウが100万トークン級になっても消えていません。失う中盤が広がっただけ ・対策は「端に置く」「量を絞る」「分けて読ませる」の3つ。最初にやるべきは配置の見直しで、費用は0円 ・全部投げる運用は精度も料金も損をします。入力トークン数によっては単価そのものが上がります
資料を10本まとめて貼って質問したら、5本目に書いてあったはずの数字が答えから消えていた。しかも同じ資料を1本だけ渡すと、AIはちゃんと答える。
犯人はAIの読解力ではなく、情報を置いた場所です。
長い文脈の真ん中は、先頭や末尾より弱く扱われます。この偏りに名前がついたものがlost in the middleです。仕組みを知れば、貼り方を変えるだけで拾われ方が変わります。
lost in the middleとは、長い文脈の真ん中が読み飛ばされる現象です
lost in the middleとは、AIに長い文章をまとめて読ませたとき、先頭と末尾の情報は正しく使われるのに、中盤に置いた情報だけが答えに反映されにくくなる現象です。日本語では「中盤の見落とし」と訳されます。
最初に報告されたのは2023年の研究でした。実験の作りはとても素朴です。
- 1つの質問を用意する
- 複数の文書をまとめて読ませる
- そのうち1本だけに答えが書いてある
- 答えの入った文書の位置だけを動かす
文書の中身は一切変えていません。動かすのは順番だけ。それなのに正答率が上下します。答えが先頭付近か末尾付近にあるときは高く、真ん中に沈めると落ちる。グラフにするときれいなU字を描きます。
ここが不気味なところ。AIは「読めていない」のではなく、「読んだのに使わない」のです。
つまり、精度が出ないときに疑うべきはモデルの賢さではなく、こちらの並べ方かもしれません。
なぜ中盤だけが読み飛ばされるのか？
原因は注意（アテンション）の配り方の偏りです。AIは入力された文字のかたまり（トークン）を均等には見ていません。
先頭が強い理由は単純です。学習してきた文章の多くは、冒頭に主題や指示が来る形をしています。「先頭は大事なことが書いてある場所」という癖が染みついている、と考えると納得しやすいはずです。
末尾が強い理由も別にあります。答えを書き始める直前にある情報なので、単純に近い。人間でも会議の最後の発言はよく覚えているものです。
では真ん中はどうか。主題としての強さも、直前にある近さも持っていない。 両側から挟まれて埋もれます。
さらに厄介なのが、量が増えるほど中盤が長くなること。10本の資料なら中盤は2、3本ですが、100本なら数十本が中盤に入ります。埋もれる範囲が広がるわけです。
この偏りは日本語でも英語でも起きます。言語の問題ではなく、位置の問題だからです。
コンテキストウィンドウが広がれば解決するのでは？
しません。ここが最大の誤解です。
最初の報告から3年、モデルは何世代も入れ替わりました。それでもU字の形は残っています。窓が広くなったことで変わったのは、失える中盤が広くなったという一点だけ。
長文専用に調整されたモデル変種でも、同じ位置的な弱さが観測されています。窓のサイズと、窓の中を均等に扱う力は別物です。
ベンチマーク側の事情も知っておくと判断が早くなります。
針1本テストの限界 よく見かける「100万トークンの中に1文だけ埋めて探させる」テストは、満点が出やすい作りです。1回の実行で探す対象が1つしかないから。実務の社内資料検索は、関連する断片を複数まとめて拾い、突き合わせて答えます。RULERの検証では、この複数拾い（multi-needle）が明確に難しくなると報告されています。
LongBench v2やHELMETのような複数文書型のベンチマークでも、関連情報が中央寄りになるほど性能が落ちる傾向が続いて観測されています。
満点のグラフを見て安心する前に、そのテストが針1本かどうかを見てください。
位置と拾われやすさをどう読むか
配置ごとの扱われ方を整理すると、資料の並べ方の指針がそのまま出てきます。下の表は、長い入力を4つの区画に分けたときの傾向です。
| 置き場所 | 拾われやすさ | 向いている中身 |
|---|---|---|
| 先頭（最初の1割） | 非常に高い | 役割指定・出力形式・守ってほしいルール |
| 前半（1〜3割） | 高い | 前提条件・用語定義・判断基準 |
| 中盤（3〜7割） | 明確に低い | 参考程度の補足資料・背景情報 |
| 末尾（最後の2割） | 非常に高い | 最重要の資料・具体的な質問文 |
つまり、答えに直結する材料を中盤に沈めた時点で勝負は半分ついています。
コード解析でも同じことが起きます。長いファイルを丸ごと貼って「この関数のバグを探して」と頼むより、対象の関数そのものをプロンプトの末尾近くに直接貼るほうが精度が上がります。全部渡して探させる運用は、AIに不利な条件を課しているのと同じです。
その不調は本当にlost in the middleか？
長文で答えがおかしくなる原因は1つではありません。対策を間違えると手間だけ増えるので、症状で切り分けます。
| 症状 | 疑う原因 | 最初に試すこと |
|---|---|---|
| 中盤の資料の内容だけ答えに出ない | lost in the middle | 該当資料を末尾へ移す |
| 似た資料が多く、別の会社の数字を混ぜる | 情報の取り違え | 資料を減らして出典名を明記させる |
| 古い版の記述を最新として答える | 古い情報の混入 | 旧版を入力から外す |
| 指示を途中から無視する | 指示同士の衝突 | 指示を先頭と末尾に分けて再掲 |
見分け方はシンプルです。問題の資料を1本だけ渡して同じ質問をする。 それで正しく答えるなら、読解力ではなく配置の問題。ほぼ確実に中盤の見落としです。
この切り分けを飛ばして「モデルを変えよう」と判断すると、費用だけ増えて症状は残ります。
対策1: 大事なものを「端」に置く
いちばん効いて、いちばん安い方法。プロンプトの並べ替えだけなので、実装も追加費用も要りません。
具体的な組み立て方はこうなります。
- 先頭に役割と出力形式を書く
- 参考資料を重要度の高い順ではなく、重要なものを末尾寄りに並べる
- 末尾に最重要資料を置く
- いちばん最後に質問文を置く
資料を時系列順に並べる癖は、いったん捨ててください。日付順は人間には読みやすいものの、AIにとっては「重要なものが真ん中に来る」危険な並びです。
指示の二度書きも効きます。冒頭で書いたルールを、質問の直前でもう一度短く繰り返す。「日本円で答える」「出典の資料名を必ず添える」といった条件は、末尾での再掲で守られ方が変わります。
長い指示文が言うことを聞かない問題は、画像生成でも同じ形で起きます。要素を詰め込んだ長文プロンプトの中盤の指定が落ちる感覚に覚えがあるなら、AIイラストツールの比較記事で扱っている指示の書き分けが、そのまま文章側にも応用できます。
無料でここまで改善できるのに、やっていない現場が多い。もったいない話です。
対策2: 入れる量を絞る
窓が広いと、つい全部入れたくなります。この誘惑が精度を殺します。
中盤の見落としは、中盤が長いほど深刻になる現象です。だとすれば、そもそも中盤を作らないのが正攻法。資料20本を10本に減らせば、埋もれる範囲は半分になります。
絞り込みの実務的な手順を挙げます。
- 検索して関連度の高い上位だけを渡す
- 似た内容の断片は1本に統合して重複を消す
- 各資料を先に要約させ、要約だけを本番の入力に使う
- 明らかに古い版・失効した規程は入力前に除外する
要約を挟む二段構えは地味ですが、効きます。1回目の呼び出しで各資料から「質問に関係する箇所だけ」を抜き出させ、2回目でその抜き出し結果を使って答えさせる。入力が短くなるぶん、位置の偏りに晒される情報自体が減ります。
社内文書を横断して答えさせる仕組みを検討しているなら、社内監査向けAIツールの整理記事が参考になります。検索の質が悪いまま量で殴る構成は、この現象と最悪の相性です。
引用元を提示しながら答える設計のツールも選択肢になります。Feloの使い方をまとめたFelo完全ガイドや、資料を限定して読ませるNotebookLMのような形は、入力の範囲を人間側で決められる点が強みです。RAG・検索系カテゴリには近い設計のツールが集まっています。
ここまでの整理 ・原因は読解力ではなく「置いた場所」 ・窓が広がっても解決しない。中盤が広がるだけ ・最初にやるのは並べ替え（0円）、次に量を減らす（工数中）
対策3: 一度に読ませず、分けて読ませる
量を減らせない場合の手段です。1回で全部読ませることをやめます。
分割して処理する型は3ステップで組めます。
- 資料をひとかたまりずつ分ける
- かたまりごとに「質問に関係する記述だけ」を抜き出させる
- 抜き出した結果をまとめて、最終回答を作らせる
各ステップの入力が短いので、どのかたまりも「先頭と末尾しかない」状態になります。中盤が生まれない構造にしてしまう発想です。
処理を段階に割って組み立てる考え方は、画像生成のワークフロー設計と似ています。ComfyUIとStable Diffusionを比べた記事で扱っているノード単位の分割は、文章処理側の分割設計を考えるときの下敷きになります。
もう1つの手は、AI自身に取りに行かせる形です。全部を先に渡さず、必要になった時点でAIが検索し、足りなければ検索し直す。手元に置く情報を最小に保てるので、埋もれる余地が構造的に小さくなります。AIエージェントの設計が注目される理由の1つがここにあります。
簡単に試せる裏技も1つ。「答える前に、根拠になる箇所を原文のまま引用してください」と指示を足すだけで、中盤の拾われ方が変わることがあります。引用を強制されると、全体を走査せざるを得なくなるからです。
3つの対策はどう使い分ける？
手間と効き目が違うので、上から順に試すのが正解です。下の表は導入判断の目安になります。
| 対策 | 手間 | 効き目 | 向いている場面 |
|---|---|---|---|
| 端に置く | ほぼゼロ | 中 | 手作業でチャットに貼っている全ての場面 |
| 量を絞る | 中（実装が必要） | 大 | 社内資料QA・大量文書の横断検索 |
| 分けて読ませる | 大（設計が必要） | 大 | 資料を減らせない要約・全件レビュー |
| モデルを変える | 小 | 小 | 他を試した後の最後の手段 |
つまり、モデルの乗り換えは最後です。位置の偏りはモデル固有のバグではなく、この仕組み全体が持つ性質だからです。乗り換えても症状は付いてきます。
現場での優先順位は明快。今日は並べ替え、今月は絞り込み、余力ができたら分割処理。この順番で費用対効果が最大になります。
業務のどこで効くか
抽象論に見えて、被害が出る場所ははっきりしています。
社内規程のQA 規程集をまとめて読ませ、「この経費は精算できるか」と聞く使い方。例外条項が中盤にあると、原則だけを答えて例外を落とします。危険度は高めです。
契約書レビュー 条項の数が多い契約ほど中盤が厚くなります。不利な条項が真ん中にある確率も、当然そこがいちばん高い。
議事録の要約 1時間の議事録なら、決定事項が話の中盤に来ることは珍しくありません。冒頭の雑談と末尾の締めが妙に濃く要約に残るなら、この現象を疑ってください。
コードレビュー 長いファイルの中央にある関数の扱いが雑になります。対象を切り出して渡すだけで結果が変わります。
長文のやり取りが続くチャット運用でも同じ影響が出ます。会話が伸びるほど、序盤に伝えた前提が中盤に押し流されていく。Meta AIの活用ガイドのような日常利用でも、長い会話では前提の再掲が効きます。
長文を投げるとコストはどうなる？
精度だけの話ではありません。財布にも来ます。
入力トークン数が一定を超えると単価そのものが変わる料金設計があります。GPT-5.5では、272Kトークンを超える入力に対して、標準・Batch・Flexの各セッションで入力単価が2倍、出力単価が1.5倍になる仕様が案内されています（2026年8月時点）。一方でClaude Opus系のように、100万トークンまで一律の料金で使えるモデルもあります。
料金体系はモデルごとにかなり違うので、長文前提の仕組みを組む前に必ず確認してください。
ここに、この記事の一番おいしい点があります。
| 判断 | 精度 | 料金 | 応答速度 |
|---|---|---|---|
| 資料を全部入れる | 中盤が落ちる | 高い | 遅い |
| 上位だけ絞って入れる | 上がる | 安い | 速い |
| 要約してから入れる | 上がる | かなり安い | 速い |
つまり、絞る判断は精度・料金・速度の3つを同時に改善します。トレードオフがない改善はめったにありません。ここは迷わず絞ってください。
「本当に長い入力が必要か」を1回考えるだけで、月額が下がることもあります。
AI PICKS編集部の判定
lost in the middleは、知っているかどうかで結果が変わる典型です。そして知っていれば、初手はタダで打てる。ここが結論です。
窓が100万トークンになったのだから全部入れればいい、という考え方は正直イマイチです。3年前に指摘された位置の偏りは、世代が変わっても消えていません。広くなったのは中盤であって、注意の配り方ではないからです。
現場で最初にやるべきは1つだけ。答えに直結する資料と質問文を、入力のいちばん最後に置く。 これだけで拾われ方が変わるケースが相当あります。実装も承認も要りません。今日から変えられます。
その次が絞り込み。精度・料金・速度が同時に良くなるので、投資先としては破格です。分割処理や自律検索の設計は、そのあとで十分。逆に、モデルの乗り換えを最初に検討するのは順序として微妙です。原因が置き場所なら、乗り換えても症状は付いてきます。
長文を投げる前に「これ、真ん中に大事なもの埋めてないか」と一度だけ確認する。この習慣が一番安い改善策です。
あわせて見たいツール・カテゴリ
長文の扱いを見直すときに、あわせて検討したい選択肢を挙げます。
- ChatGPT — 長文入力の癖を掴むなら、まず手元で位置を変えて比べるのが早いです
- Claude — 長いコンテキストを前提にした運用で候補に挙がります
- Gemini — 大量の資料をまとめて扱う場面での比較対象に
- NotebookLM — 読ませる資料を人間側で限定できる設計が、絞り込みの発想と噛み合います
- Dify — 分割処理や検索連携を自分で組みたいときの土台になります
- Glean — 社内文書の横断検索を業務に組み込む場合の選択肢
- RAG・検索カテゴリ — 絞り込みの仕組みを比べるならここから
- LLMカテゴリ — モデルの特性を並べて確認できます
- プロンプト関連カテゴリ — 配置と指示の書き方を詰めたい人向け
- AIリサーチツールランキング — 資料調査の入り口を整えたい場合に
- AI業務効率化ランキング — 日常業務への組み込みを検討するなら
よくある質問（FAQ）
Q. lost in the middleは日本語でも起きますか？
起きます。原因はトークンの位置に対する扱いの偏りで、言語には依存しません。日本語の社内規程や議事録でも、中盤の記述が落ちる形は同じように現れます。
Q. コンテキストウィンドウが大きいモデルを選べば回避できますか？
回避できません。窓の大きさと、窓の中を均等に扱う力は別の話です。長文向けに調整されたモデル変種でも同じ位置的な弱さが観測されています。窓が広がると、むしろ中盤が長くなります。
Q. 症状が出ているかどうか、どう確かめればいいですか？
答えに出てこなかった資料を1本だけ渡して、同じ質問をしてください。それで正しく答えるなら読解力の問題ではありません。位置の問題です。資料を末尾に移して再実行すると、はっきり違いが出ます。
Q. 資料を減らせない業務では、どうすればいいですか？
分けて読ませる形に切り替えます。資料をかたまりに分け、各かたまりから関連箇所だけ抜き出させ、その抜き出し結果で最終回答を作る。1回あたりの入力が短くなるので、中盤そのものが生まれません。
Q. 「針を探すテスト」で満点なら安心してよいですか？
安心できません。1回の実行で探す対象が1つだけのテストは、実務より易しい設定です。複数の関連情報をまとめて拾う場合は明確に難しくなると報告されています。社内検索の実態はこちらに近いはずです。
Q. 対策すると料金は上がりますか？
下がる方向に働きます。入力を絞れば送るトークン数が減るからです。モデルによっては一定のトークン数を超えると単価自体が上がる設計もあるため、絞る判断は料金面でも有利になります。
Q. 一番効く順番を教えてください。
配置の見直し、量の絞り込み、分割処理、この順です。最初の1つは費用ゼロで今日から実行できます。モデルの乗り換えは最後に検討してください。
社内の資料をAIに読ませる仕組みを本気で作るなら、次は社内監査向けAIツールの整理記事へ。検索の質を上げることが、この現象への一番効く投資だと分かります。
各ツールの公式サイト（一次情報）
料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。
- ChatGPT — 公式サイト（AI PICKSの詳細）
- Claude — 公式サイト（AI PICKSの詳細）
- Gemini — 公式サイト（AI PICKSの詳細）
- NotebookLM — 公式サイト（AI PICKSの詳細）
- Felo — 公式サイト（AI PICKSの詳細）
