ChatGPTが前の発言を忘れる理由
ウィンドウには境界があり、それは目に見えない
すべてのモデルには最大コンテキストが存在します。長い会話は最終的にそれを超えてしまい、その時点で何かを捨てる必要があります。最近のやり取りを収めるために、初期のやり取りが削除されるか圧縮されます。
インターフェースはこれを示してくれません。スレッドの中に、モデルの視野がどこから始まっているかを示す線はありません。そのため、ユーザー側からはメッセージが目に見える形で存在し、無視されているように見えますが、モデル側からはそこには存在しないのです。この不一致こそがこの問題の本質であり、何度も強く言い直すことが常に解決策のように見えてしまう理由です。
ウィンドウの内部であっても、位置が重要になる
これは多くの人が知らない部分であり、スレッドが明らかに収まっているケースにおけるより適切な説明となります。
この知見は、Lost in the Middle: How Language Models Use Long Contexts (Liu et al., TACL 2023) から得られたものです。彼らは、関連情報の位置を移動させながら、複数文書の質問回答やキー・バリューの検索をテストし、「関連情報が入力コンテキストの最初または最後にある場合にパフォーマンスが最も高くなることが多く、モデルが長いコンテキストの中央にある関連情報にアクセスしなければならない場合、明示的に長いコンテキストに対応したモデルであっても、パフォーマンスが著しく低下する」と報告しています。
これをチャットに当てはめてみましょう。最初の設定指示は冒頭にあります。これは良い位置です。最新のメッセージは最後にあります。これも良い位置です。しかし、90メッセージ中30メッセージ目で追加した制約は中央にあり、入力の中で最も弱い位置になります。指示が不明確だったわけではありません。時間の経過によって、単に配置が悪くなってしまったのです。
実効容量は公表されている数値よりも小さい
2つ目の効果は、公表されているコンテキストサイズは上限であり、実際に機能する容量ではないということです。
RULER: What's the Real Context Size of Your Long-Context Language Models? (Hsieh et al., 2024) では、単純な「針を探す（needle-in-a-haystack）」検索を超えて、マルチホップの追跡や集約を含む合成ベンチマークを構築し、17のロングコンテキストモデルを評価しました。彼らの結論は、標準的な検索テストでほぼ完璧なスコアを獲得したにもかかわらず、「ほぼすべてのモデルが、コンテキスト長が増加するにつれて大幅なパフォーマンス低下を示す」というものでした。また、すべてのモデルが32Kトークン以上を謳っていましたが、「32Kの長さで満足のいくパフォーマンスを維持できたのは半数のみ」でした。
この評価は2024年のものであり、特定のモデルはその後置き換えられているため、現在のリーダーボードとしてではなく、問題の傾向を示すものとして捉えてください。この傾向は今も変わっていません。スペックシートの数値は「収まる量」を示しているのであって、モデルが「うまく活用できる量」を示しているわけではありません。そして、散らばった情報を横断して推論する必要があるタスクは、単一の事実を検索するだけのタスクよりも早く劣化します。
何が削除されたかは知らされない
問題をさらに悪化させる要因は、沈黙です。初期のやり取りがトリミングまたは圧縮されても、通知は届きません。長時間のエージェントセッションについて執筆している実務家も、ツール側から同じ現象を報告しています。セッション初期の指示が無視されているのではなく、モデルがもはやそこに確実にアクセスできなくなっているのです。
そのため、「制約に従わなかった」のか「制約がもはや視野に入っていない」のかを区別することができません。これらは相反する対応を必要とします。前者はより明確な指示を求めます。後者は会話の再構築を求めます。そして、どれだけ強調して言い直しても、後者を解決することはできません。
人々が試みる対策
指示を繰り返す。 即効性がありますが、なぜそうなったのかの理由は分かりません。また、スレッドが肥大化するため、次の破綻がより早く訪れます。これが、多くの人が陥っているトレッドミルです。
重要なことをすべて最初のメッセージに含める。 実に賢明な方法です。冒頭は強い位置だからです。これはスレッドが長くなって冒頭がトリミングされるまでは有効ですが、40メッセージ目で気づいた制約には対処できません。
新しいチャットを始める。 最も信頼できる単一のアクションであり、経験豊富なユーザーが頻繁に行う理由でもあります。代償として、有用な情報もすべて捨てることになるため、劣化したスレッドを空のスレッドと交換することになります。
続ける前に要約を求める。 実用的なテクニックです。制約を再確認させ、コンテキストの末尾に近いその要約に基づいて作業を進めます。効果的ですが、情報の損失を伴います。圧縮を行うことになり、何を捨てるかはモデルが決定します。
固定部分にカスタム指示（Custom Instructions）を使用する。 過小評価されがちですが、これらは履歴に残るのではなく、リクエストごとに再提供されるため有効です。容量が小さいため、このタスクの具体的な内容ではなく、いくつかの基本ルールを保持するのに適しています。適切に活用する価値はありますが、設定したのに効果が出ない指示とは異なります（これは別の問題です）。
ドキュメントを再アップロードする。 よく行われますが、同じ問題に直面します。スレッドの途中でアップロードしたファイルがコンテキストから外れてしまうのは、ファイル側から見たこれと同じメカニズムです。
すべての回避策に共通している点に注目してください。これらはすべて、ストレージとして使用されている履歴を管理するための方法に過ぎません。
解決策：会話をストレージとして使うのをやめる
構造的な間違いは、スレッドを記録として扱うことです。会話は作業スペースであり、思考には適していますが、保持には適しておらず、長くなると明確に悪影響を及ぼします。要件がメッセージとしてしか存在しなくなると、位置の影響、トリミング、圧縮の対象となり、そのどれもユーザーには見えません。
したがって、要件を外に切り出しましょう。制約、仕様、スキーマ、決定事項はアシスタントが読み取れるストアに保管し、個々の会話は短く使い捨てにできるようにします。短いスレッドには、迷子になるような「中央」が存在しません。
これが本質的なメカニズムであり、何ができて何ができないかを正確に理解することが重要です。メモリレイヤーは、コンテキストウィンドウを拡張したり、長い入力内での注意力を改善したりするものではありません。 それを行う技術は存在しません。変化するのは、永続的な情報が再提示されるのではなく検索されるようになるため、スレッドを長く保つ必要がなくなる点です。これにより、モデルが信頼できない領域を管理するのではなく、モデルが信頼できる領域で作業を進めることができるようになります。
MemoryLake はそのためのメモリレイヤーです。ドキュメント、制約、決定事項を1つのストアにまとめ、APIを介してChatGPTから、またMCP対応ツールを介してClaudeやCodexから直接読み取ることができます。新しいチャットでも同じ知識を共有でき、90メッセージのスレッドは不要になります。
ステップ 1: APIキーを作成する
キーを生成すれば、約30秒で最初のリクエストを送信できます。キーはチャットウィンドウに貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。
ステップ 2: 最初のメモリをアップロードする
仕様書、制約、スタイルガイド、スキーマ、決定事項など、現在何度も説明し直しているドキュメント、画像、ファイルをドラッグ＆ドロップします。可能な限り、要約ではなくソース自体をアップロードしてください。すべてが何かの圧縮版になってしまうワークフローから脱却することが目的です。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPI経由でメモリへのアクセス権を付与します。ChatGPTにはMCPクライアントがないため、API経由で必要な情報を取得し、プロンプト、カスタムGPTの指示、またはモデルを呼び出すワークフローに注入します。MCPに対応しているツールは、同じストアを直接読み取ることができます。
実践において何が変わるか
最初の違いは、スレッドが短くなることであり、これこそが最大のメリットです。それぞれが同じ検索されたコンテキストから始まる10個の短い会話は、途中で劣化する1つの90メッセージのスレッドよりも優れています。それは整理されているからではなく、短い入力こそがモデルが本来のパフォーマンスを発揮できる場所だからです。
2つ目は、「忘れたのか、それとも従わなかったのか」という疑問に答えを出せるようになることです。制約が30メッセージ前にあるのではなく、リクエストと同時に提供されていれば、従わなかった場合は純粋な指示違反であり、実際に起きていることに応じた適切な対応を取ることができます。
3つ目は、新しくやり直すことのコストがゼロになる点です。現状では、新しいチャットを始めることは説明し直すことを意味します。だからこそ、人々は信頼性の限界をはるかに超えてスレッドを使い続けてしまうのです。知識が検索されるようになれば、新しいチャットは無料になり、何度もコンテキストを説明し直すことがクリーンなコンテキストを得るための代償ではなくなります。
そして、これは組み込みのメモリ機能と競合するのではなく、補完し合います。保存されたメモリは本来の得意分野に特化させることができます。つまり、それをファイルキャビネットのように使うのをやめることで、容量がいっぱいになることなく、1〜2ページの固定された好みを保持できるようになります。
長い会話のためのベストプラクティス
スレッドの長さを消費するリソースとして扱う
作業スレッドを大体どのくらいの長さにするかを事前に決めておき、それを超えたら新しいスレッドを開始します。多くの人は、説明し直す手間を避けるために、信頼性の限界をはるかに超えて使い続けてしまいます。説明し直す問題を解決すれば、これは簡単なことになります。
重要な制約は冒頭だけでなく、最後にも置く
位置はあなたに不利に働くこともあれば、有利に働くこともあります。次の回答で必ず守るべきルールがある場合は、送信するメッセージの中でそれを再確認してください。入力の末尾は強い位置です。これが「繰り返す」ことが有効である理由であり、重要な2〜3のことに対して意図的に行うことは、すべてに対して受動的に行うよりも効果的です。
自分で決めた境界で、意図的に要約する
スレッドが長くなったら、要件を明示的に再確認させ、それを確認・修正した上で、それをオープナー（最初のメッセージ）として新しいチャットを開始します。目に見えないトリミングに任せるのではなく、自分で確認しながら圧縮を行うのです。
決定事項を履歴の中だけに存在させない
来週になっても有効である事柄は、メッセージの40番目ではなく、ドキュメントやストアに保管すべきです。この1つの習慣が、この種の問題全体を防ぎ、スレッドを安心して破棄できるようにします。
モデルを疑う前に位置を疑う
指示に従わなくなったときは、書き直す前に、それが会話のどこに位置しているかを確認してください。長いスレッドの初期に設定された内容は、入力の中で最も弱い位置にあります。正しい対応は、表現の変更ではなく、構造の再構築です。
結論
ChatGPTが同じ会話の中で前の発言を忘れてしまうのは、長い入力が不均等に処理されるためです。長いコンテキストの中央にある情報は、最初や最後にある情報よりも信頼性が低くなります。これが Lost in the Middle の発見であり、ロングコンテキスト向けに明示的に構築されたモデルでも同様でした。そして、実際に使用可能な容量は公表されている数値を大きく下回ります。これは、32K以上を謳うモデルの半数が32Kで持ちこたえられなかったという RULER の実証結果が示している通りです。あなたの制約は無視されたのではなく、90メッセージ目になる頃には、モデルが適切に処理できる長さを超えた入力の最悪の位置に置かれていたのです。
つまり、解決策はプロンプトのテクニックではありません。履歴を記録として使うのをやめましょう。永続的な情報はアシスタントが読み取れるストアに保管し、会話は短く保ち、自由に新しい会話を開始してください。そうすれば、モデルが信頼できない領域を管理するのに苦労するのではなく、モデルが信頼できる範囲で作業を進めることができるようになります。