ChatGPTとクロードの記憶システムについての考察：オンデマンド会話検索を可能にするために必要なこと

高品質のAIエージェントシステムにおいて、メモリ設計は見た目よりもはるかに複雑である。その核となるのは、3つの基本的な質問に答えることである：会話の履歴はどのように保存すべきか？いつ過去の文脈を取り出すべきか？そして、具体的に何を取り出すべきか？

これらの選択は、エージェントの応答待ち時間、リソースの使用量、そして最終的には能力の上限を直接形成します。

ChatGPTやClaudeのようなモデルは、使えば使うほど "メモリを意識している "ように感じます。嗜好を記憶し、長期的な目標に適応し、セッション間の連続性を維持する。その意味では、すでにミニAIエージェントとして機能している。しかしその表面下では、彼らの記憶システムはまったく異なるアーキテクチャを前提として構築されている。

ChatGPTと クロードの記憶メカニズムに関する最近のリバースエンジニアリング解析によって、明確なコントラストが明らかになった。ChatGPTは、軽量で予測可能な継続性を実現するために、事前に計算されたコンテキスト・インジェクションとレイヤード・キャッシングに依存している。対照的にClaudeは、メモリの深さと効率のバランスをとるために、動的なメモリ更新を伴うRAGスタイルのオンデマンド検索を採用している。

これら2つのアプローチは、単なる設計上の好みではなく、インフラストラクチャーの能力によって形作られている。Milvus2.6は、オンデマンドの会話型メモリが必要とする、密と疎のハイブリッド検索、効率的なスカラーフィルタリング、階層型ストレージの組み合わせを導入し、選択的検索を実世界のシステムで展開するのに十分な速さと経済性を実現している。

この投稿では、ChatGPTとClaudeのメモリシステムが実際にどのように動作するのか、なぜアーキテクチャ的に分岐したのか、そしてMilvusのようなシステムの最近の進歩がどのようにオンデマンド会話検索を大規模で実用的なものにしているのかを説明します。

ChatGPTの記憶システム

ChatGPTはベクターデータベースを照会したり、推論時に過去の会話を動的に取得する代わりに、コンテキストコンポーネントの固定セットを組み立て、すべてのプロンプトに直接注入することで「メモリ」を構築します。各コンポーネントは前もって用意され、プロンプト内の既知の位置を占めます。

この設計により、パーソナライゼーションと会話の連続性はそのままに、待ち時間、トークンの使用量、システムの動作をより予測しやすくしている。言い換えれば、メモリはモデルがその場で検索するものではなく、システムがパッケージ化し、応答を生成するたびにモデルに渡すものなのです。

高いレベルでは、ChatGPTプロンプトは以下のレイヤーで構成されています：

[0] システム指示

[1] 開発者の指示

[2] セッションメタデータ (エフェメラル)

[3] ユーザーメモリ (長期的な事実)

[4] Recent Conversations Summary (最近の会話の要約) (過去のチャット、タイトル、スニペット)

[5] 現在のセッションメッセージ（このチャット）

[6] 最新のメッセージ

これらのうち、[2]から[5]までのコンポーネントがシステムの有効な記憶を形成し、それぞれが明確な役割を果たします。

セッションメタデータ

セッションメタデータは、会話の最初に一度注入され、セッションが終了すると破棄される、短命で永続的でない情報を表す。その役割は、長期的に行動をパーソナライズすることよりも、モデルが現在の使用状況に適応するのを助けることである。

このレイヤーは、ユーザーの直近の環境と最近の使用パターンに関するシグナルを取得する。典型的なシグナルには以下が含まれる：

• デバイス情報- 例えば、ユーザーがモバイルかデスクトップか。

• アカウント属性- サブスクリプション・ティア（例：ChatGPT Go）、アカウント年齢、全体的な利用頻度など。

• 行動メトリクス- 過去1日、7日、30日間のアクティブ日数、平均会話時間、モデル使用分布（たとえば、リクエストの49%をGPT-5で処理）など。

ユーザー・メモリー

ユーザーメモリは、会話全体のパーソナライゼーションを可能にする、永続的で編集可能なメモリ層です。ユーザーの名前、役割やキャリア目標、進行中のプロジェクト、過去の成果、学習嗜好など、比較的安定した情報が保存され、新しい会話ごとに注入されることで、時間の経過に伴う連続性が維持されます。

このメモリは2つの方法で更新できる：

• 明示的な更新は、ユーザーが "これを覚えておけ "とか "これを記憶から削除しろ "といった指示で直接記憶を管理するときに行われる。

• 暗黙的な更新は、システムがOpenAIの保存基準を満たす情報（確認された名前や役職など）を識別し、ユーザーのデフォルトの同意とメモリ設定に従って自動的に保存するときに発生します。

最近の会話の要約

最近の会話の要約は、完全なチャット履歴を再生または取得することなく、連続性を維持する軽量で、クロスセッションコンテキストレイヤーです。従来のRAGベースのアプローチのように動的な検索に頼る代わりに、この要約は事前に計算され、すべての新しい会話に直接注入される。

このレイヤーはアシスタントの返信を除いて、ユーザーメッセージのみを要約する。それは意図的にサイズが制限されており、通常15エントリ程度であり、詳細な内容ではなく、最近の関心についての高レベルの信号のみを保持する。埋め込みや類似検索に依存しないため、待ち時間とトークンの消費を低く抑えることができる。

現在のセッションメッセージ

現在のセッションメッセージは、進行中の会話の完全なメッセージ履歴を含み、首尾一貫した、ターンバイターンの応答に必要な短期的なコンテキストを提供する。このレイヤーは、ユーザーの入力とアシスタントの返答の両方を含みますが、セッションがアクティブな間だけです。

このモデルは固定トークンの制限内で動作するため、この履歴は無制限に増やすことはできません。制限に達すると、システムは古いメッセージを削除し、新しいメッセージのためのスペースを確保します。この切り捨ては現在のセッションだけに影響し、長期的なユーザーの記憶と最近の会話の要約はそのまま残ります。

クロードのメモリシステム

Claudeはメモリ管理に異なるアプローチをとっている。ChatGPTのようにすべてのプロンプトに固定された大きなメモリコンポーネントを注入するのではなく、クロードは永続的なユーザメモリとオンデマンドツールと選択的な検索を組み合わせます。過去の文脈は、モデルが関連性があると判断したときにのみ取得され、システムは文脈の深さと計算コストをトレードオフすることができる。

クロードのプロンプトコンテキストは以下のような構造になっている：

[0] システムプロンプト（静的命令）

[1] ユーザーの記憶

[2] 会話履歴

[3] 現在のメッセージ

ClaudeとChatGPTの主な違いは、会話履歴の取得方法と ユーザーメモリの更新・維持方法にあります。

ユーザメモリ

Claudeでは、ユーザ・メモリはChatGPTのユーザ・メモリと同様の目的で長期的なコンテキスト・レイヤーを形成しますが、自動的なバックグラウンド主導の更新に重点を置いています。これらのメモリは（XMLスタイルのタグでラップされた）構造化された形式で保存され、最小限のユーザの介入で時間の経過とともに徐々に進化するように設計されています。

クロードは2つの更新経路をサポートしている：

• 暗黙的な更新- システムは定期的に会話の内容を分析し、バックグラウンドでメモリを更新する。これらのアップデートはリアルタイムでは適用されず、削除された会話に関連するメモリは継続的な最適化の一環として徐々に削除されます。

• 明示的な更新- ユーザーは、専用のmemory_user_edits ツールを介して実行される "これを記憶する "や "これを削除する "などのコマンドを通じて、メモリを直接管理することができます。

ChatGPTと比較して、Claudeは長期記憶を洗練、更新、刈り込みする責任をシステム自身に負わせます。そのため、ユーザーが保存されているものを積極的に管理する必要性が低くなっている。

会話履歴

会話履歴については、クロードはすべてのプロンプトに注入される固定要約に依存しません。その代わりに、3つの異なるメカニズムを使用して、モデルが必要と判断した場合にのみ、過去の文脈を検索する。これにより、無関係な履歴を持ち越さないようにし、トークンの使用量を抑えている。

コンポーネント	目的	使用方法
ローリングウィンドウ（現在の会話）	ChatGPTのセッションコンテキストと同様に、現在の会話の完全なメッセージ履歴を保存します。	自動的に注入されます。トークンのリミットは~190K; リミットに達すると古いメッセージは削除される
conversation_search ツール	トピックまたはキーワードで過去の会話を検索し、会話のリンク、タイトル、ユーザー/アシスタントメッセージの抜粋を返す	モデルが過去の詳細が必要だと判断したときにトリガーされる。パラメータにはquery (検索語) とmax_results (1-10) が含まれます。
recent_chats ツール	指定された時間範囲内（例えば「過去3日間」）の最近の会話を検索します。conversation_search	最近の、時間にスコープされたコンテキストが関連する場合にトリガーされる。パラメータには、n （結果数）、sort_order 、および時間範囲が含まれる。

これらのコンポーネントの中で、conversation_search は特に注目に値する。緩い言い回しや多言語のクエリであっても、関連する結果を表示することができ、単純なキーワードのマッチングに頼るのではなく、意味的なレベルで動作していることを示している。これは、埋め込みベースの検索、あるいは、まずクエリを正規形に翻訳または正規化し、次にキーワード検索またはハイブリッド検索を適用するハイブリッドなアプローチを含んでいる可能性が高い。

全体として、Claudeのオンデマンド検索アプローチには、いくつかの特筆すべき強みがある：

• 検索は自動的には行われない：ツールの呼び出しは、モデル自身の判断によってトリガーされる。例えば、ユーザが「前回議論したプロジェクト」を参照したとき、Claudeは関連するコンテキストを検索するためにconversation_search 。

• 必要なときに、よりリッチなコンテキストを：ChatGPTの要約はユーザーのメッセージのみをキャプチャするのに対し、取得した結果にはアシスタントのレスポンスの抜粋を含めることができます。このため、Claudeはより深い、またはより正確な会話コンテキストを必要とするユースケースに適しています。

• デフォルトでより良い効率：履歴コンテキストは必要なとき以外は注入されないため、システムは大量の無関係な履歴を持ち越すことを避け、不必要なトークンの消費を抑えることができます。

トレードオフも同様に明確です。インデックスの構築と維持、クエリーの実行、結果のランク付け、場合によっては再ランク付けが必要となる。また、エンド・ツー・エンドの待ち時間は、事前に計算され、常にコンテキストが注入される場合よりも予測しにくくなる。さらに、モデルは、いつ検索が必要かを判断することを学習しなければならない。その判断に失敗すると、関連するコンテキストがまったく取得されない可能性がある。

クロード式オンデマンド検索の背後にある制約条件

オンデマンド検索モデルを採用することで、ベクトル・データベースはアーキテクチャの重要な一部となる。会話検索は、ストレージとクエリ実行の両方に異常に高い要求を課しており、システムは同時に4つの制約を満たさなければならない。

1.低レイテンシ耐性

会話システムでは、P99のレイテンシは通常～20ミリ秒以下に抑える必要があります。それ以上の遅延はすぐにユーザーに気づかれてしまいます。ベクトル検索、メタデータのフィルタリング、結果のランキングはすべて慎重に最適化されなければなりません。ベクトル検索、メタデータフィルタリング、結果ランキングはすべて慎重に最適化されなければならない。どのポイントでもボトルネックがあると、会話体験全体が低下する可能性がある。

2.ハイブリッド検索要件

ユーザーのクエリはしばしば複数の次元にまたがる。過去1週間のRAGに関するディスカッション」のようなリクエストは、意味的関連性と時間ベースのフィルタリングを組み合わせている。もしデータベースがベクトル検索しかサポートしていない場合、1,000の意味的に類似した結果を返すかもしれない。実用的であるためには、データベースはベクトルとスカラーを組み合わせたクエリーをネイティブにサポートする必要がある。

3.ストレージと計算の分離

会話履歴は、ホット-コールドの明確なアクセスパターンを示す。最近の会話は頻繁にクエリされるが、古い会話はほとんどクエリされない。もしすべてのベクターがメモリ上になければならないとすると、何千万もの会話を保存するために何百ギガバイトものRAMを消費することになる。実行可能であるためには、システムはストレージとコンピュートの分離をサポートし、ホットデータをメモリに、コールドデータをオブジェクトストレージに保持し、必要に応じてベクターをロードする必要がある。

4.多様なクエリーパターン

会話検索は単一のアクセス・パターンに従うものではない。クエリの中には、純粋に意味的なもの（例えば、"私たちが議論したパフォーマンス最適化"）もあれば、純粋に時間的なもの（"先週からのすべての会話"）もあり、また、複数の制約を組み合わせたもの（"過去3ヶ月間のFastAPIに言及したPython関連の議論"）も多くあります。データベース問い合わせプランナは、単一サイズの総当たり検索に頼るのではなく、異なる問い合わせタイプに実行戦略を適応させなければなりません。

これら4つの課題を合わせて、会話型検索の中核となる制約を定義する。Claudeスタイルのオンデマンド検索を実現しようとするシステムは、協調してこれら全てに対処しなければならない。

Milvus 2.6が会話型検索に適している理由

Milvus2.6の設計上の選択は、オンデマンド会話検索のコア要件と密接に一致している。以下は、主要な機能の内訳と、それらが実際の会話検索のニーズにどのように対応しているかを示している。

密なベクトルと疎なベクトルのハイブリッド検索

Milvus2.6では、密なベクトルと疎なベクトルを同じコレクション内に格納し、クエリ時にそれらの結果を自動的に融合することができます。密なベクトル（例えば、BGE-M3のようなモデルによって生成される768次元の埋め込み）は意味的類似性を捉え、一方、疎なベクトル（一般的にBM25によって生成される）は正確なキーワード信号を保持する。

Milvusは、"先週のRAGに関する議論 "のようなクエリに対して、意味検索とキーワード検索を並行して実行し、リランキングによって結果をマージする。どちらかのアプローチを単独で使用する場合と比較して、このハイブリッド戦略は実際の会話シナリオにおいて著しく高いリコールを実現する。

ストレージと計算の分離とクエリの最適化

Milvus 2.6は2つの方法で階層型ストレージをサポートしている：

• メモリ上のホットデータ、オブジェクトストレージ上のコールドデータ

• インデックスをメモリに、生のベクトルデータをオブジェクトストレージに

この設計では、およそ2GBのメモリと8GBのオブジェクトストレージで100万件の会話エントリを格納することができる。適切なチューニングにより、ストレージとコンピートの分離を有効にしても、P99のレイテンシは20ミリ秒以下に抑えることができる。

JSONシュレッダーと高速スカラーフィルタリング

Milvus 2.6はデフォルトでJSON Shreddingを有効にし、ネストしたJSONフィールドをカラム型ストレージにフラット化します。これにより、公式ベンチマークによると、スカラーフィルタリングのパフォーマンスが3～5倍向上します（実際の向上はクエリパターンによって異なります）。

会話形式の検索では、ユーザーID、セッションID、時間範囲などのメタデータによるフィルタリングが必要になることがよくあります。JSON Shreddingを使用すると、「過去1週間のユーザーAからのすべての会話」のようなクエリは、完全なJSONブロブを繰り返し解析することなく、カラムナインデックス上で直接実行できます。

オープンソースの制御と運用の柔軟性

オープンソースシステムであるMilvusは、クローズドでブラックボックス化されたソリューションにはない、アーキテクチャと運用のコントロールが可能です。チームはインデックスパラメータを調整し、データ階層化戦略を適用し、ワークロードに合わせて分散デプロイメントをカスタマイズすることができます。

この柔軟性が参入障壁を下げます。中小規模のチームは、特大のインフラ予算に頼ることなく、100万から数千万規模の会話検索システムを構築することができます。

ChatGPTとクロードが異なる道を歩んだ理由

ChatGPTとClaudeの記憶システムの違いは、大まかに言えば、それぞれが忘却をどのように扱うかにあります。ChatGPTは積極的な忘却を好みます：メモリが一定の限界を超えると、古いコンテキストは削除されます。これは完全性をシンプルさと予測可能なシステム動作と引き換えにします。Claude は遅延忘却を好みます。理論的には、会話の履歴は、オンデマンドの検索システムに委任されたリコールで、無制限に成長することができます。

では、なぜ2つのシステムは異なる道を選んだのだろうか？上に述べた技術的制約を考慮すれば、その答えは明らかである。それぞれのアーキテクチャは、基盤となるインフラがそれをサポートできる場合にのみ実行可能だからである。

クロードのアプローチを2020年に試みても、おそらく実用的ではなかっただろう。当時、ベクターデータベースには数百ミリ秒のレイテンシーが発生することが多く、ハイブリッドクエリのサポートは不十分で、データの増大とともにリソースの使用量は法外にスケールしていった。このような状況下では、オンデマンド検索は過剰なエンジニアリングとして否定されていただろう。

2025年になると、状況は一変する。Milvus 2.6のようなシステムによるインフラストラクチャーの進歩により、ストレージとコンピュートの分離、クエリーの最適化、密と疎のハイブリッド検索、JSONシュレッディングが本番環境で実行可能になった。これらの進歩により、レイテンシが短縮され、コストが抑制され、選択的検索が実用的な規模になりました。その結果、オンデマンドツールと検索ベースのメモリは、実現可能になっただけでなく、特にエージェントスタイルのシステムの基盤として、ますます魅力的になっている。

最終的には、アーキテクチャの選択は、インフラストラクチャが可能にするものに従うことになる。

結論

実世界のシステムでは、メモリ設計は、事前に計算されたコンテキストかオンデマンド検索かの二者択一ではない。最も効果的なアーキテクチャは、両方のアプローチを組み合わせたハイブリッド型であることが一般的である。

一般的なパターンは、スライディングコンテキストウィンドウを通して最近の会話ターンを注入し、固定メモリとして安定したユーザー嗜好を保存し、ベクトル検索を介してオンデマンドで古い履歴を検索することである。製品が成熟するにつれて、このバランスは徐々に変化し、アーキテクチャを破壊的にリセットすることなく、主に事前計算されたコンテキストから、次第に検索主導に移行することができる。

事前計算アプローチから始める場合でも、移行を念頭に置いて設計することが重要である。メモリは、明確な識別子、タイムスタンプ、カテゴリー、ソース参照とともに保存されるべきである。検索が実行可能になれば、既存のメモリに対してエンベッディングを生成し、同じメタデータとともにベクターデータベースに追加することで、最小限の混乱で段階的に検索ロジックを導入することができる。

Milvusの最新機能についてのご質問やディープダイブをご希望ですか？私たちのDiscordチャンネルに参加するか、GitHubに課題を提出してください。また、Milvusオフィスアワーを通して、20分間の1対1のセッションを予約し、洞察、ガイダンス、質問への回答を得ることもできます。