【2026年最新】長文脈とAIの記憶×論文4選|「長い資料ほど見落とす」「前に伝えたことを忘れる」を解く

【2026年最新】長文脈とAIの記憶×論文4選|「長い資料ほど見落とす」「前に伝えたことを忘れる」を解く AIニュース

LLMのコンテキストウィンドウ(1回の処理でモデルに渡せる文章量の上限)は大きく伸び、分厚い資料や大量のログをまるごと渡せるようになりました。過去の会話の内容を覚えておく「メモリ機能」を備えたチャットサービスやエージェントも増えています。

ところが現場では、「上限には収まっているのに、長い資料を渡すと大事な箇所を見落とす」「前回の会話で伝えたはずの情報が反映されない」といった声がよく聞かれます。上限の数字だけを見て設計すると、こうした見えにくい劣化に気づけません。

この記事では、各社の公式ドキュメントをもとにコンテキストウィンドウとメモリ機能の仕組みを整理し、「長い入力を実際にどこまで使いこなせるのか」「記憶をどう評価すべきか」を扱った論文4本を紹介します。結論を先に言うと、上限ではなく「実際に読める量」を自分の資料で測り、長い資料は置き方と渡し方を工夫し、記憶機能は事実ごとに点検するのが基本です!

コンテキストウィンドウとは何か:AIの「作業机」の広さ

会話の履歴も出力も、すべて含めて数える

Anthropic のドキュメントは、コンテキストウィンドウを「モデルが応答を作るときに参照できるテキストのすべて(応答そのものを含む)」と説明し、学習に使われた大量のデータとは別の「作業用の記憶」にあたるとしています。Google も、短期記憶にたとえて説明しています(Anthropic「Context windows」、Google「Long context」)。

注意したいのは、数えられるのが質問文だけではない点です。Anthropic の説明では、システムプロンプト、それまでの会話のすべて、ツールの実行結果や画像・文書、ツールの定義、さらにモデルが生成する出力や思考の部分まで、すべてが上限に数えられます。OpenAI も、上限には入力・出力・推論のトークンが含まれ、超えた分は切り捨てられうると書いています(OpenAI「Conversation state」)。会話が長引くほど、資料を置ける余白は減っていきます。

2026年10月時点で、Anthropic は最新世代を中心とする多くのモデルの上限を100万トークン、それ以外のモデルを20万トークンとしています。Google も、多くの Gemini モデルが100万トークン以上を扱えるとしています。

上限に収まっても、長いほど精度は落ちる

大事なのは、各社とも「入れられること」と「使いこなせること」を分けて説明している点です。Anthropic は、トークン数が増えるほど正確さや思い出す力が落ちる現象を「コンテキストの劣化(context rot)」と呼び、何を入れるかを選ぶことは、空きの大きさと同じくらい重要だとしています。Google も、1つの情報を探す試験では高い精度が出る一方で、探す情報が複数になると同じ精度は出ず、内容によって大きく変わると明記しています。

会話をまたぐ「記憶」の仕組み

APIは本来「前の会話を覚えていない」

OpenAI のドキュメントは、文章生成のリクエストは1回ごとに独立していて状態を持たない、と説明しています。複数回のやりとりは、それまでの会話をリクエストに含めて送ることで成り立っています。つまり、AIが「覚えている」ように見えるのは、過去のやりとりがコンテキストウィンドウに入っている間だけです。

チャットサービスのメモリ機能

会話をまたいで覚えておくのがメモリ機能です。Anthropic のヘルプによると、Claude のメモリは会話の終了後に要約するのではなく、会話中に話題ごとに保存し、利用者が確認・編集できます。プロジェクトごとに記憶は分かれ、1つのチャットだけメモリを使わない設定もあります。健康や信条などの個人的な話題は既定では保存せず、Team・Enterprise プランでは管理者が利用の可否を決めます(Anthropic「Use Claude’s chat search and memory to build on previous context」)。Google の Gemini アプリの過去のチャットに基づく個人化は、個人の Google アカウントで使う機能で、仕事用や学校用のアカウントでは使えないと案内されています(Google「Get personalization in Gemini Apps」)。

開発者が作る記憶:メモリツール

自社のエージェントに記憶を持たせる場合は、仕組みを自分で用意します。Anthropic のメモリツールは、モデルが記憶用のファイルの作成・読み出し・更新・削除を要求し、実際の保存はアプリ側が行う方式です。同じドキュメントは、機密情報を書き込む前に取り除く検証、ファイルの大きさの上限、長く使われていない記憶の定期的な削除、そして記憶用の保存場所の外にあるファイルに触れられないよう、操作のたびに指定先を検証することを、アプリ側の責任として挙げています(Anthropic「Memory tool」)。

研究で見る「長い入力のどこで見落とすか」

📄 論文: 長さが同じでも「情報の詰まり具合」で見落とす

Dense Contexts Are Hard Contexts: Lexical Density Limits Effective Context in LLMs(Giovanni Dettori ほか、2026年6月、arXiv:2606.06203)は、査読前の論文(プレプリント)です。

対象は 9B〜685B パラメータの、重みが公開されたモデル8種で、小さめのモデルは研究用のGPUで、大きなモデルは商用APIで動かしています。長さをどれも約1万2千トークンにそろえた3種類の「探し物」課題を作り、各100問で、正解の位置を少しずつずらして測りました。3種類は、同じ定型文が並ぶ対応表から値を探すもの(疎)、場面に反するルールを一覧から探すもの(中)、文に含まれる禁止語を単語の一覧から探すもの(密)で、情報の詰まり具合が違います。課題の種類も違うため、各課題の中で同じ項目を繰り返して密度だけを下げる実験も加えています。

結果は、疎な対応表ではどの位置でもほぼ満点だった一方、密な2種類では正解が後ろにあるほど成績が下がり、8モデルの平均で、正解が1万2千トークン地点にあるときのスコアは2千トークン地点に比べて、満点を100として27ポイントと31ポイント低くなりました。約1万2千トークンは、長さだけなら劣化しないと考えられてきた短さです。密度だけを下げると成績はおおむね戻りましたが、単語の一覧では、中程度に間引くとかえって悪くなる場合もありました。

運営者にとっての意味は、表や一覧、設定ファイルのように新しい情報がぎっしり詰まった資料は、短くても見落としが起きやすいということです。

📄 論文: 上限の「半分手前」で崩れたモデルがある

Intelligence Degradation in Long-Context LLMs: Critical Threshold Determination via Natural Length Distribution Analysis(Weiwei Wang ほか、2026年1月、arXiv:2601.15300)は、査読前の論文(プレプリント)です。

対象は公開モデルの Qwen2.5-7B(上限12万8千トークン)1つで、読解問題1,000件を、資料を切り詰めたり水増ししたりせず元の長さのまま解かせ、答えの一致度(F1)を測りました。短い資料は SQuAD、長い資料は NarrativeQA という別のデータセットから500件ずつ取っています。

結果は、上限の40%(約5万1千トークン)まではF1が0.55〜0.58で安定していたのに、40〜50%の間で0.556から0.302へ45.5%落ち、その先も戻りませんでした。ただし1モデル・1種類の課題での結果で、著者ら自身も、ほかのモデルや課題に当てはまるかは今後の検証が必要だとしています。

運営者にとっての意味は、「上限に収まるか」だけでは安心できず、使うモデルと資料で落ち始める長さを確かめる必要があるということです。

長い資料を「読ませずに扱う」、記憶を「事実ごとに測る」

📄 論文: 長い資料はファイルとして置き、エージェントに探させる

Coding Agents are Effective Long-Context Processors(Weili Cao ほか、2026年3月、arXiv:2603.20432)は、査読前の論文(プレプリント)です。

長い資料をモデルに丸ごと読ませる代わりに、文書をファイルとしてフォルダに置き、既製のコーディングエージェントに検索コマンドやプログラムで探させる方法を試しました。対象は、長い文書の読解・集計や、最大3兆トークンの文書群からの質問応答など公開ベンチマーク5種で、それぞれ200問を無作為に選び、Codex(GPT-5)を中心に、2種では Claude Code(Sonnet 4.5)でも測っています。比較相手は、GPT-5 に資料を区切って読ませる方法、一般的な RAG、検索ツール付きのエージェントなどです。

結果は、5種のうち4種で公表済みの最高値を上回り、相対的な改善幅は平均17.3%でした。一方で、多様な長文読解を集めたベンチマークでは最高値に届かず、GPT-5 にそのまま読ませた場合とほぼ同じでした。また、検索ツールを追加するとかえって成績が下がる場合があり、1問あたりの費用は RAG より高くなっています。

運営者にとっての意味は、長い資料への対策として「上限の大きいモデルに入れる」「RAGで一部を渡す」に加えて、「ファイルとして探させる」も比べる価値があるということです。

📄 論文: 記憶は「正解率」でなく事実ごとの変化で測る

MemTrace: Probing What Final Accuracy Misses in Long-Term Memory(Xianxuan Long ほか、2026年6月、arXiv:2606.17328)は、査読前の論文(プレプリント)です。

既存の評価用データ(HaluMem)にある20人分の複数回の会話履歴から、利用者に関する835の事実を取り出し、事実ごとに「何回前の会話で出たか」「今の状態・以前の状態・変化の経緯のどれを聞くか」「根拠がある・ない・誤った前提を含むか」を変えて、1万5千問以上を作りました。長文脈モデル、RAG、外部記憶、エージェント型の計13構成を比べました。長文脈モデルは会話履歴を直接読んで自分で答え、ほかの構成は取り出した記憶を共通のモデル(gpt-4o-mini)に渡して答えさせています。

結果は、全体の正解率が近くても弱点がばらばらでした。長文脈モデルの Qwen3.5-35B は、新しい事実の「変化の経緯」には49.0%答えられたのに、会話が積み重なると6.7%に落ちました。話に出ていない事実についてはほぼ必ず回答を控えるのに、誤った前提はあまり正せないシステムもありました。1種類の簡単な検索器を使った300問の追試では、正しい会話に届いていたのに解けなかった例が、届かなかった例の約10倍ありました。この倍率は検索器によって変わりうると著者らは断っています。

運営者にとっての意味は、記憶の改善は「保存を増やす」より「取り出せた情報を正しく使わせる」ことが課題で、評価も事実の更新や誤った前提を含めて行う必要があるということです。

現場でやること

長い資料は「置き方」を整える

各社のガイドは、長い資料の渡し方について具体的な指針を示しています。

  • 長い資料はプロンプトの先頭に置き、質問は最後に書く(Anthropic は、質問を最後に置くと、特に複数の資料を含む複雑な入力で、回答の質が試験で最大30%上がったとしています)
  • 複数の資料は1つずつ区切り、出典や資料名を添える
  • 答える前に、関係する箇所を資料から引用させる

(Anthropic「Prompting best practices」、Google「Long context」)

自社の資料で「落ち始める長さ」を測る

上限の数字ではなく、実際に使う資料と質問で確かめます。資料の長さを変えたり、答えの書かれた箇所を前後に動かしたりして、同じ質問への正答がどこから崩れるかを見ます。表や一覧のように情報が詰まった資料は、短くても分割して渡すことを前提にしましょう。

長い資料は「探させる」構成も比べる

すべてを1回で読ませる方法、関連部分だけを渡す RAG(RAGの実務の記事)、ファイルとして置いてエージェントに探させる方法を、同じ質問で比べます。精度だけでなく、1件あたりの費用と待ち時間も合わせて判断します(推論コストの記事)。

記憶機能は「事実ごと」に点検する

  • 利用者の情報が変わったとき(担当者の交代、締め切りの変更など)に、新しい内容で答えられるか
  • 「以前はどうだったか」「どう変わったか」を聞いても正しく答えられるか
  • 話していない事実を聞かれたら「分からない」と言えるか、誤った前提を含む質問を正せるか
  • 業務で使うなら、保存される内容の確認方法、オフにする手順、古い記憶の削除の運用を決めておく

長文脈と記憶を使いこなす鍵は次の3点です

  1. 「上限に収まるか」ではなく「実際に読める量」で設計する
    自社の資料で長さや情報の詰まり具合を変えて精度を測り、どこから落ち始めるかを把握します。
  2. 長い資料は置き方と渡し方を工夫する
    資料を先頭・質問を末尾に置き、引用させてから答えさせます。読ませるだけでなく、ファイルとして探させる構成も比べます。
  3. 記憶機能は事実ごとと変化の追跡で評価する
    全体の正解率だけで判断せず、情報の更新や誤った前提を含む質問で正しく振る舞えるかを確かめます。

まとめ:長文脈と記憶は「どれだけ入るか」から「どれだけ使えるか」へ!

コンテキストウィンドウは会話の履歴や出力まで含めた「作業机」の広さで、各社とも長くなるほど精度が落ちうると説明しています。研究でも、情報の詰まり具合や長さによって上限よりずっと手前で見落としが起きる例や、記憶が「保存されていても使われない」例が示されました。

まずは、よく使う長い資料を1つ選び、答えの書かれた箇所を動かしながら同じ質問をしてみてください。自社の環境で「どこまで読めるか」が見えてきます!

参考文献

2026-10-01 更新: 構成を見直し、論文へのリンクと参考文献を追加し、情報密度の実験条件、上限の半分手前での性能低下を調べた対象モデル、コーディングエージェントの比較結果の記述の誤りを修正しました

タイトルとURLをコピーしました