I Reverse Engineered ChatGPT's Memory System, and Here's What I Found! - Manthan Gupta
https://manthanguptaa.in/posts/chatgpt_memory/
ChatGPT Memory Architecture: Four-Layer Context System Prioritizes Speed Over RAG and Vector Databases
https://blockchain.news/ainews/chatgpt-memory-architecture-four-layer-context-system-prioritizes-speed-over-rag-and-vector-databases
Hacker Newsで500ポイント以上を獲得し、AI開発者界隈で話題になっているのが、Manthan Guptasさんによる「ChatGPTの記憶システム」のリバースエンジニアリング調査です。
調査で明らかになったのは、ChatGPTがベクトルデータベースもRAG(Retrieval-Augmented Generation)も使っていない という驚きの事実。多くのAIエンジニアが「当然RAGを使っているだろう」と考えていた仮定を覆す内容になっています。
OpenAIは複雑な検索システムではなく、すべての記憶を毎回コンテキストに詰め込む というシンプルな設計を選択しています。一見非効率に思えるこのアプローチですが、実際には速度と効率性で大きなアドバンテージを生んでいるようです。
Manthan Guptasさんの調査によると、ChatGPTのメモリシステムは以下の4層構造で構成されています。
1. エフェメラル(一時的)セッションメタデータ
デバイスタイプ、ブラウザ、タイムゾーン、ユーザー設定などのセッション情報。これらは永続的に保存されず、セッションごとに注入されます。例えば、モバイルユーザーには簡潔なフォーマットで応答し、深夜2時のユーザーには軽めの説明を提供するなど、リアルタイム適応に使用されています。
2. 明示的な長期記憶(33個の事実)
ユーザーが「これを覚えておいて」と明示的に指示したり、ChatGPTが検出してユーザーが承認した情報のみを保存。Manthan Guptasさんのアカウントでは33個の事実が保存されていたとのこと。名前、目標、プリファレンスなど、本当に重要な情報だけに絞られています。
3. 最近の会話サマリー(軽量ダイジェスト)
約15件の最近の会話をタイトル・タイムスタンプ・スニペット形式で保存。完全なトランスクリプトではなく、軽量なダイジェストとして保持することで、計算コストを削減しています。
4. 現在のセッションメッセージ(スライディングウィンドウ)
現在の会話におけるメッセージ群。メッセージ数ではなくトークン数 で優先順位付けされ、コンテキストウィンドウに収まるよう調整されています。
このシンプルな4層構造により、ChatGPTは複雑な検索処理なしに高速な応答を実現しています。
多くのAI開発者が疑問に思うのは「なぜRAGを使わないのか?」という点です。
通常、RAGシステムは類似度検索で関連する記憶を選択的に取り出す仕組みですが、これには以下のような課題があります。
OpenAIはこれらのトレードオフを避け、すべての記憶を常に注入する 方式を選択しました。コンテキストウィンドウの拡大に伴う計算コストの低下を前提とした、「The Bitter Lesson」的なアプローチと言えます。
この設計は、モデルの性能向上と計算コスト低下が続く限り有効です。実際、現在のコンテキストウィンドウは128Kトークン(GPT-4o)に達しており、ユーザーメモリ全体を入れても余裕がある状態です。
Shlok Khemani氏の分析によれば、OpenAIの哲学は「強力なモデルに大量のコンテキストを渡せば、モデルが勝手に必要な情報をフィルタリングする」 というもの。精密な検索エンジニアリングではなく、モデルのスケーリングに賭ける戦略です。
「RAGを使わない」という技術的な話、正直ピンとこない人もいるかと思います。でも、これは毎日ChatGPTを使う時の体験に直結 しています。
ChatGPTが過去の会話を覚えているのに、質問への回答が速いのはなぜでしょう?
多くのAIシステムは「類似した記憶を探す→見つける→取り出す→考える→答える」というステップを踏みます。一方、ChatGPTは「全部持ってる→考える→答える」 というシンプルな流れ。
検索のステップがないから速い。でも全部持ってるからトークンは増える。OpenAIは「速さ」を選んだわけです。
「覚えておいて」と言える事実が33個まで。少ない気もしますが、これには理由があります。
無制限に記憶を許すと、毎回の会話でコンテキストが膨大になり、応答が遅くなります。速度とのトレードオフ です。
実際、日常的な使い方で「本当に毎回思い出してほしい情報」って、意外と少なくないですか? 名前、職業、好み、プロジェクトの基本情報...33個あれば足りるケースが多い、というのがOpenAIの判断です。
「去年Pythonを勉強中って言ったけど、もう仕事で使ってる」—— こういう変化、ChatGPTは自動で気づいてくれません。
あなたが明示的に「あの記憶、更新して」と言わない限り、古い情報が残り続けます。これは現状の課題です。
定期的にメモリ管理画面をチェックして、古くなった記憶を削除・更新する習慣が必要になります。
他の主要AIもメモリ機能を実装していますが、アプローチは大きく異なります。
ChatGPTが最も成熟したメモリシステムを持っています。無料プランでも自動記憶が機能 し、会話を跨いで持続します。
Claudeのメモリは「プロジェクト単位」で分離されているため、日常会話での記憶継続性はChatGPTより低い。ただし、200K+トークンのコンテキストウィンドウ(ChatGPTの128Kより広い)により、単一会話内では圧倒的な情報保持力を発揮します。
Geminiは記憶機能が有料プラン限定で、自動検出も未実装。英語以外での使用にも制限があり、日常的な記憶体験ではChatGPTに劣ります。一方、Gemini 2.0では2M(200万)トークンのコンテキストウィンドウを持ち、単一会話での情報処理能力は突出 しています。
要するに:
拡張機能は不要で、すべて標準機能として利用可能。どのAIも一時的チャットモード(メモリ無効)を提供し、プライバシーに配慮した設計です。
2024年5月、セキュリティ研究者のJohann Rehberger氏が「SpAIware」と名付けた攻撃手法を発見しました。
悪意あるウェブサイトや文書をChatGPTに読み込ませると、その中に隠された指示が「あなたの記憶」として永続的に保存されてしまう脆弱性です。
具体的なシナリオ:
一度注入された悪意ある記憶は、セッションを閉じても消えません。次回ログイン時も、その次も、ずっと機能し続けます。
Rehberger氏は「カフェで数時間調査しただけで見つけた」と述べています。当初OpenAIは「安全性の問題であり、セキュリティの問題ではない」として深刻に受け止めませんでしたが、実証デモを見せた後、部分的な修正が行われました。
すべての記憶はOpenAIのサーバーに保存され、モデル改善のために使用される可能性があります。OpenAIは「健康情報など機密性の高いデータは自動的に記憶しないよう訓練している」としていますが、完全な保証はありません。
対策: 本当に機密性の高い情報は、一時的なチャットモード(メモリ無効)で会話する習慣をつけることが推奨されます。
ChatGPTのアプローチは「The Bitter Lesson」の実践例です。精密なエンジニアリングではなく、モデルのスケーリングに賭ける戦略。
では、RAGと比べて実際どうなのか?
Google DeepMindとミシガン大学の研究によれば、文献理解のベンチマークテストでロングコンテキストICL(全部渡す方式)がRAGを12ポイント上回った との結果が出ています。
「全部渡してモデルに任せる」方が、精度が高くなるケースがある。これはOpenAIの判断を裏付けています。
実行時のコスト:
RAGの方が有利です。数十万件の文書があっても、関連度の高い10〜20件だけをLLMに渡せば済むため、トークン消費が少ない。
ChatGPTのように「全部渡す」方式は、トークン消費が多くなります。ただし、ChatGPTの場合はユーザーメモリが33個に制限されているため、実質的なコスト増は限定的です。
構築・運用コスト:
RAGシステムの構築・運用には数百万円以上かかるケースが多い。ベクトルデータベースの維持、検索精度のチューニング、定期的な更新作業...エンジニアリングコストが膨大です。
ChatGPTのシンプルな方式は、構築コストがほぼゼロ。OpenAIにとっては「モデルを強化すればいい」だけです。
結局、RAGとシンプルコンテキスト注入の使い分けはタスクの性質 で決まります。
OpenAIの選択は「一般ユーザーの会話」には最適化されていますが、高度なエージェントタスクには別のアプローチが必要になる可能性があります。実際、プロダクションシステムの多くはハイブリッドアプローチ を採用し始めています。
興味深いのは、一部のAIメモリシステムがベクトルデータベースではなくSQLベースのメモリエンジン を採用し始めている点です。
GibsonAIの「Memori」は構造化エンティティ抽出とSQLベースの検索を使用し、ベクトルデータベースと比較して80-90%のコスト削減 と2-4倍の速度向上 を実現しているとのこと。
これは「ベクトル類似度検索が唯一の解ではない」ことを示しています。ChatGPTのシンプルな全文注入、ベクトル検索、SQL検索 - それぞれに最適なユースケースがあるのでしょう。
ChatGPTのメモリシステムが示したのは、「精密な検索エンジニアリングより、強力なモデルに全部渡す方が速い」という現実です。
エンジニアとしては「もっと賢い設計があるのでは?」と思いたくなります。でも、シンプルな設計には見過ごせない利点があります。
バグが少ない。 複雑なシステムほど、予期しない動作が増えます。
メンテナンスが楽。 ベクトルデータベースの運用、検索精度のチューニング、定期的なインデックス更新...RAGシステムには継続的な手間がかかります。
モデルの進化に乗れる。 「モデルが賢くなれば、勝手に良くなる」。複雑なエンジニアリングに依存しないからこそ、GPT-5、GPT-6と進化するたびに自動的に性能が向上します。
Shlok Khemani氏は「The Bitter Lesson strikes again(また同じ教訓だ)」と指摘しています。人類は何度も「賢い設計」で問題を解こうとして、結局「計算資源とモデルのスケーリング」に負けてきました。
ただし、これがすべてのAIシステムで最適 かは別問題です。タスクの複雑さ、求められる精度、コスト制約によって、最適なメモリアーキテクチャは変わります。
ChatGPTのアプローチは、一般ユーザーの会話という特定のユースケースに最適化された結果です。あなたが普段感じている「ChatGPTの速さと便利さ」は、この割り切った設計思想の賜物と言えるでしょう。
参考
自己紹介サイトtenormusica2024.github.io/portfolio/index.htmlAI業務活用支援、RAG構築、Webアプリ開発、AI創作など、AIなんでも屋エンジニアです。