長い会話で前提が抜けるのはなぜか：コンテキスト（作業中のメモ）と長期記憶の違いと、情報の置き場所の決め方

先に答え：容量が大きくても、前提は抜けることがある

1つのチャットで半日かけて提案書を作っていたとします。最初に伝えた「税込表記」や「A社のロゴ色は紺」が、途中から守られなくなりました。容量の大きいモデルを使っていても、これは起こりえます。理由はおもに3つです。会話が長くなるほど、AIが一度に見る情報の中で大事な条件が埋もれやすくなります。製品によっては、古いやりとりが押し出されたり、自動で要約されたりします。さらに、貼り付けた資料やAIの出力も、同じ枠を使っています。

新しい会話を始めるか、記憶機能に覚えさせるか。その答えは、情報の種類によって変わります。その作業の間だけ使う条件なら、短いまとめを作って新しい会話の冒頭に渡すのが基本です。どの作業でも守ってほしいルールなら、毎回冒頭に入る指示に置きます。量が多い資料や、ときどきしか使わない情報は、外のメモや資料に置いて必要なときに読ませます。以下では、なぜそう分けるのかを順に説明します。

毎回のやりとりで、過去の会話は丸ごと送り直されている

AIとの会話は、AIが話の流れを覚え続けているように見えます。しかし仕組みとしては、そうではありません。OpenAIの開発者向け文書では、文章を生成する1回1回の依頼は互いに独立していて、状態を持たないと説明されています。複数回のやりとりを続けるには、それまでのユーザーの発言とAIの返答を並べて、新しい依頼と一緒に渡します。

Anthropicの文書の図も同じ考え方です。2回目の依頼には1回目のやりとりが、3回目の依頼には1回目と2回目のやりとりが含まれます。そうして入力がどんどん積み上がっていきます。AIの返答も、次の回では入力の一部になります。

つまりAIは、毎回「これまでの会話の全文＋今回の質問」を最初から読み直して答えています。会話が長くなるほど、毎回読む量が増えます。なお、会話の保存を開発者の代わりに受け持つAPI（OpenAIのConversations APIなど）もあります。ただしその場合でも、会話の記録をどこに置くかが変わるだけです。モデルがその内容を読んで答えるという点は同じです。

指示・資料・ツールの結果・出力まで、すべてが同じ枠を使う

AIが答えを作るときに参照できる文章の範囲を「コンテキストウィンドウ」と呼びます。Anthropicの文書では、これを学習に使われた大量のデータとは別物と位置づけています。そのうえで、モデルにとっての作業用の記憶（working memory）にあたると説明しています。Googleの文書も、人の短期記憶にたとえています。どちらも、入れられる量に上限がある一時的な作業台だという点は共通です。

見落としやすいのは、この枠を使うのが会話の文章だけではないことです。Anthropicの文書では、次のものすべてが枠の中に数えられるとしています。システムプロンプト、メッセージ（ツールの結果、画像、文書を含む）、ツールの定義、そしてAIがその回に生成する出力です。出力には拡張思考も含まれます。プロンプトキャッシュを使っても、枠を占める量は減りません。変わるのは料金の扱いだけです。Googleの文書でも、Gemini 4では入力・思考・出力の3つが同じ1つの枠を分け合うと説明されています。

「100万トークン入るモデルだから大丈夫」と容量の数字だけを見て安心するのは危険です。PDFを何本も貼り、構成案を何十回も直してもらえば、その資料と出力がすべて毎回の入力に積み上がっていきます。

枠を使い切る前でも、量が増えると精度が下がる

枠が残っていれば問題ない、というわけでもありません。Anthropicの文書では、トークン数が増えるにつれて正確さや思い出す力が落ちると明記しています。この現象は「コンテキスト・ロット」（context rot）と呼ばれています。同じ文書では、空き容量の大きさと同じくらい、枠に何を入れるかを選ぶことが大切だとしています。

Googleの文書にも、同じ方向の説明があります。大量の文章から1つの情報を探すだけなら、高い精度が出やすいとしています。一方で、探したい情報が複数あると、同じ精度は出ないと書かれています。また、渡す必要のないトークンは渡さないほうがよい、ともしています。質問は長い資料のあとの末尾に置いたほうが性能が上がりやすい、という助言もあります。

提案書づくりに当てはめると、こうなります。「税込表記」「ロゴ色」「商品名の表記」は、AIが毎回同時に守るべき複数の条件です。それが大量の資料と修正のやりとりの中に散らばっている状態は、まさに精度が落ちやすい形です。

チャット画面では、古いやりとりが押し出されたり要約されたりする

開発者がAPIを直接使う場合、Anthropicの標準の動作では、過去のやりとりはそのまま全部残ります。ただし文書の注記では、claude.aiのようなチャット画面は事情が違うとしています。こうした画面では、古いものから順に押し出す（first in, first out）方式で枠を管理することがあると書かれています。もし押し出されれば、会話の序盤に伝えた条件そのものが、AIの読む範囲から消えます。

もう1つが自動要約です。Anthropicの文書では、会話が枠の上限に近づいたときの方法として「コンパクション」を紹介しています。これはサーバー側で会話の前半を自動で要約し、上限を超えて会話を続けられるようにする仕組みです（対象モデルでベータ提供）。要約はとても便利です。ただし、細かい表記ルールのような情報が要約の中でどう残るかは、利用者からは見えにくくなります。

どの製品が押し出しや要約をどの時点で行うかは、製品ごとに違います。今回確認した文書の範囲では、各チャット製品の細かい動作までは分かりませんでした。使っている製品の公式説明で確かめる必要があります。

長期記憶はコンテキストの外にあり、必要なときに読み戻す

会話をまたいで情報を残す仕組みは、コンテキストとは別の場所にあります。例としてAnthropicのメモリツールを見てみます。公式文書によると、このツールを使うと、Claudeはメモ用のファイル置き場にファイルを作成・読み込み・更新・削除できます。そのファイルはセッションが終わっても残ります。ファイルの保存先は、Claude側ではなく利用者のアプリケーション側が管理します。

ここで大事なのは「最初に全部を読み込まない」という考え方です。文書では、学んだことをメモファイルに書いておき、必要になったときに読み戻すやり方だと説明しています。こうすると、今の作業に必要なものだけが枠に入るので、長い作業でも枠があふれにくくなります。また、メモリツールはコンパクションと組み合わせられるとしています。要約で失われては困る情報をメモ側に残しておく、という役割分担です。

逆に言えば、長期記憶に入れたものは会話を変えても読み戻されます。誤りや古い情報が入ると、それも残り続けます。Anthropicの文書でも、長くアクセスされていないメモファイルを定期的に削除することや、機密情報を書き込ませない対策を、利用者側の責任として挙げています。

判断の目安：症状を切り分けて、3つの置き場所に振り分ける

ここからは、公式文書の説明をもとにした編集部の整理です。まず症状を切り分けます。会話の序盤に伝えた条件だけが抜けるなら、原因の候補は3つです。コンテキストが長すぎて埋もれたか、押し出されたか、要約で削られたかです。この場合、記憶機能に頼る前に、会話を区切ることを考えます。一方、新しい会話を始めるたびに同じ前提を言い直しているなら、その情報は冒頭に置く指示か長期記憶の候補です。

次に、枠を使っているものを数えます。会話だけでなく、貼った資料、ファイル、ツールの結果、AIの出力も数に入れます。関係のなくなった古い資料ややりとりは、途中で外したほうがよいと考えます。量が多いほど良いわけではないからです。

長い作業は、区切りで新しい会話に移るのが有効です。区切りごとに「決まったこと・残っている作業」をAIに短くまとめさせます。そのまとめを新しい会話の冒頭に貼って続けます。ただし、まとめは必ず人が読んで確かめます。抜けや誤りがあれば、それが次の会話の前提になってしまうからです。

長期記憶に登録する前には、本当に繰り返し使う前提かどうかを考えます。その案件でしか使わない数字や、まだ変わりそうな方針は、長期記憶には向きません。

仮例：ナギサ企画の提案書づくり

以下は架空の例です。広告制作会社「ナギサ企画」のディレクターが、1つのチャットで飲料メーカー「コハク飲料」向けの提案書を作りました。冒頭で表記ルールを伝えました。内容は、税込表記、ロゴ色は紺、商品名は「コハク麦茶ZERO」の3つです。そのあと競合資料のPDFを3本貼り、構成案を20回ほど直しました。すると後半になって、税抜価格が混ざり、商品名も「コハク麦茶ゼロ」と書かれるようになりました。

振り返ると、資料と修正のやりとりで、枠の大部分が埋まっていました。冒頭の条件は大量の情報に埋もれて拾われにくくなったか、製品の仕組みで押し出されたり要約されたりした可能性があります。

ディレクターは3つの対応をしました。1つ目に、どの案件でも使う社内ルール（税込表記など）だけを、毎回冒頭に入る指示に移しました。2つ目に、案件ごとの条件（ロゴ色・商品名）は短いメモにまとめ、新しい会話の冒頭に貼るようにしました。3つ目に、競合資料は全文を貼るのをやめ、必要な章だけを渡すことにしました。

あわせて、チームのルールに一文を加えました。「構成案が固まったら、決定事項のまとめを作って新しい会話に移る」というものです。案件ごとの条件を長期記憶に登録しなかったのは、別の案件の会話にまで読み戻されると困るからです。

使っている製品で確かめておきたいこと

古いやりとりを押し出すか、自動で要約するか、それがいつ起きるか。これらは製品によって違います。チャット製品を使う場合は、公式ヘルプで会話の長さの扱いを確認してください。記憶機能があるなら、何がいつ保存され、どう消せるかも確認しておきます。

開発者がAPIで社内ツールを作る場合は、送る前に入力のトークン数を見積もれるかを確かめます。Anthropicはトークン数を数えるAPIを用意しており、各応答でも実際に使った量が返されます。また、入力だけで上限を超えるとエラーになることも文書に書かれています。上限に近づいたときにどうするかは、あらかじめ決めておきます。区切って要約するのか、古いツールの結果を消すのか、外のメモに移すのか、という設計です。

容量の数字は「どこまで入るか」を示すだけで、「どこまで正確に使えるか」を保証するものではありません。何を枠に入れ、何を外に置くか。その判断は、使う側に残っています。