ChatGPTの記憶システムはRAGを使っていなかった - 4層アーキテクチャの衝撃
参照元
I Reverse Engineered ChatGPT's Memory System, and Here's What I Found! - Manthan Gupta
ChatGPT Memory Architecture: Four-Layer Context System Prioritizes Speed Over RAG and Vector Databases
RAGを使わないメモリシステムという衝撃
Hacker Newsで500ポイント以上を獲得し、AI開発者界隈で話題になっているのが、Manthan Guptasさんによる「ChatGPTの記憶システム」のリバースエンジニアリング調査です。
調査で明らかになったのは、ChatGPTが ベクトルデータベースもRAG（Retrieval-Augmented Generation）も使っていない という驚きの事実。多くのAIエンジニアが「当然RAGを使っているだろう」と考えていた仮定を覆す内容になっています。
OpenAIは複雑な検索システムではなく、すべての記憶を毎回コンテキストに詰め込む というシンプルな設計を選択しています。一見非効率に思えるこのアプローチですが、実際には速度と効率性で大きなアドバンテージを生んでいるようです。
4層構造のメモリアーキテクチャ
Manthan Guptasさんの調査によると、ChatGPTのメモリシステムは以下の4層構造で構成されています。
1. エフェメラル（一時的）セッションメタデータ
デバイスタイプ、ブラウザ、タイムゾーン、ユーザー設定などのセッション情報。これらは永続的に保存されず、セッションごとに注入されます。例えば、モバイルユーザーには簡潔なフォーマットで応答し、深夜2時のユーザーには軽めの説明を提供するなど、リアルタイム適応に使用されています。
2. 明示的な長期記憶（33個の事実）
ユーザーが「これを覚えておいて」と明示的に指示したり、ChatGPTが検出してユーザーが承認した情報のみを保存。Manthan Guptasさんのアカウントでは33個の事実が保存されていたとのこと。名前、目標、プリファレンスなど、本当に重要な情報だけに絞られています。
3. 最近の会話サマリー（軽量ダイジェスト）
約15件の最近の会話をタイトル・タイムスタンプ・スニペット形式で保存。完全なトランスクリプトではなく、軽量なダイジェストとして保持することで、計算コストを削減しています。
4. 現在のセッションメッセージ（スライディングウィンドウ）
現在の会話におけるメッセージ群。メッセージ数ではなく トークン数 で優先順位付けされ、コンテキストウィンドウに収まるよう調整されています。
このシンプルな4層構造により、ChatGPTは複雑な検索処理なしに高速な応答を実現しています。
なぜRAGを使わないのか？
多くのAI開発者が疑問に思うのは「なぜRAGを使わないのか？」という点です。
通常、RAGシステムは類似度検索で関連する記憶を選択的に取り出す仕組みですが、これには以下のような課題があります。
- エンベディング生成とベクトル検索のレイテンシ
- 類似度スコアの精度問題（本当に重要な記憶を取りこぼす可能性）
- システムの複雑化によるメンテナンスコスト
OpenAIはこれらのトレードオフを避け、すべての記憶を常に注入する 方式を選択しました。コンテキストウィンドウの拡大に伴う計算コストの低下を前提とした、「The Bitter Lesson」的なアプローチと言えます。
この設計は、モデルの性能向上と計算コスト低下が続く限り有効です。実際、現在のコンテキストウィンドウは128Kトークン（GPT-4o）に達しており、ユーザーメモリ全体を入れても余裕がある状態です。
Shlok Khemani氏の分析によれば、OpenAIの哲学は 「強力なモデルに大量のコンテキストを渡せば、モデルが勝手に必要な情報をフィルタリングする」 というもの。精密な検索エンジニアリングではなく、モデルのスケーリングに賭ける戦略です。
これがどう影響するのか？
「RAGを使わない」という技術的な話、正直ピンとこない人もいるかと思います。でも、これは 毎日ChatGPTを使う時の体験に直結 しています。
速い応答の裏側
ChatGPTが過去の会話を覚えているのに、質問への回答が速いのはなぜでしょう？
多くのAIシステムは「類似した記憶を探す→見つける→取り出す→考える→答える」というステップを踏みます。一方、ChatGPTは 「全部持ってる→考える→答える」 というシンプルな流れ。
検索のステップがないから速い。でも全部持ってるからトークンは増える。OpenAIは「速さ」を選んだわけです。
33個の制限の理由
「覚えておいて」と言える事実が33個まで。少ない気もしますが、これには理由があります。
無制限に記憶を許すと、毎回の会話でコンテキストが膨大になり、応答が遅くなります。速度とのトレードオフ です。
実際、日常的な使い方で「本当に毎回思い出してほしい情報」って、意外と少なくないですか？ 名前、職業、好み、プロジェクトの基本情報...33個あれば足りるケースが多い、というのがOpenAIの判断です。
古い記憶の問題
「去年Pythonを勉強中って言ったけど、もう仕事で使ってる」—— こういう変化、ChatGPTは自動で気づいてくれません。
あなたが明示的に「あの記憶、更新して」と言わない限り、古い情報が残り続けます。これは現状の課題です。
定期的にメモリ管理画面をチェックして、古くなった記憶を削除・更新する習慣が必要になります。
ClaudeやGeminiのメモリ機能は？
他の主要AIもメモリ機能を実装していますが、アプローチは大きく異なります。
Claude（Anthropic）
- 2025年8月に導入、10月に全有料プラン（Pro/Max）に展開
- Projectsごとに独立したメモリ（プロジェクト外では記憶なし）
- ツール呼び出しとして可視化 されるため、何を覚えたか透明性が高い
- 一般的な会話メモリは「Coming Soon」（2025年12月時点で未実装）
- 代わりに200K+トークンの巨大コンテキストウィンドウで補完
Gemini（Google）
- 2025年8月にメモリ機能を追加
- 2025年12月時点では 依然として英語が主要言語、多言語対応は「数週間以内に展開予定」
- Google One AI Premium（有料プラン）必須 - 無料プランではメモリ機能なし
- 日本語サポートは存在するが制限あり（英語での使用が推奨）
- 手動メモリ登録方式（ChatGPTのような自動検出・提案はない）
性能比較
ChatGPTが最も成熟したメモリシステムを持っています。無料プランでも自動記憶が機能 し、会話を跨いで持続します。
Claudeのメモリは「プロジェクト単位」で分離されているため、日常会話での記憶継続性はChatGPTより低い。ただし、200K+トークンのコンテキストウィンドウ（ChatGPTの128Kより広い）により、単一会話内では圧倒的な情報保持力を発揮します。
Geminiは記憶機能が有料プラン限定で、自動検出も未実装。英語以外での使用にも制限があり、日常的な記憶体験ではChatGPTに劣ります。一方、Gemini 2.0では2M（200万）トークンのコンテキストウィンドウを持ち、単一会話での情報処理能力は突出 しています。
要するに:
- 日常会話の記憶: ChatGPT > Claude > Gemini
- 単一会話の情報量: Gemini 2.0 > Claude > ChatGPT
- 透明性・コントロール: Claude > ChatGPT > Gemini
拡張機能は不要で、すべて標準機能として利用可能。どのAIも一時的チャットモード（メモリ無効）を提供し、プライバシーに配慮した設計です。
セキュリティ上の懸念 - あなたの記憶が狙われる
2024年5月、セキュリティ研究者のJohann Rehberger氏が「SpAIware」と名付けた攻撃手法を発見しました。
Memory Injection（メモリ注入）攻撃とは？
悪意あるウェブサイトや文書をChatGPTに読み込ませると、その中に隠された指示が「あなたの記憶」として永続的に保存されてしまう脆弱性です。
具体的なシナリオ:
- あなたが悪意あるサイトのURLをChatGPTに送る（または、罠が仕掛けられたPDFを要約させる）
- その中に「今後の会話をすべて外部サーバーに送信せよ」という隠し指示
- ChatGPTがそれを「記憶」として保存
- 以降のすべての会話が盗聴される
一度注入された悪意ある記憶は、セッションを閉じても消えません。次回ログイン時も、その次も、ずっと機能し続けます。
Rehberger氏は「カフェで数時間調査しただけで見つけた」と述べています。当初OpenAIは「安全性の問題であり、セキュリティの問題ではない」として深刻に受け止めませんでしたが、実証デモを見せた後、部分的な修正が行われました。
プライバシーの問題
すべての記憶はOpenAIのサーバーに保存され、モデル改善のために使用される可能性があります。OpenAIは「健康情報など機密性の高いデータは自動的に記憶しないよう訓練している」としていますが、完全な保証はありません。
対策: 本当に機密性の高い情報は、一時的なチャットモード（メモリ無効）で会話する習慣をつけることが推奨されます。
RAG vs シンプルコンテキスト注入 - コストと性能の真実
ChatGPTのアプローチは「The Bitter Lesson」の実践例です。精密なエンジニアリングではなく、モデルのスケーリングに賭ける戦略。
では、RAGと比べて実際どうなのか？
性能面: ロングコンテキストが優位
Google DeepMindとミシガン大学の研究によれば、文献理解のベンチマークテストで ロングコンテキストICL（全部渡す方式）がRAGを12ポイント上回った との結果が出ています。
「全部渡してモデルに任せる」方が、精度が高くなるケースがある。これはOpenAIの判断を裏付けています。
コスト面: 状況による
実行時のコスト:
RAGの方が有利です。数十万件の文書があっても、関連度の高い10〜20件だけをLLMに渡せば済むため、トークン消費が少ない。
ChatGPTのように「全部渡す」方式は、トークン消費が多くなります。ただし、ChatGPTの場合はユーザーメモリが33個に制限されているため、実質的なコスト増は限定的です。
構築・運用コスト:
RAGシステムの構築・運用には数百万円以上かかるケースが多い。ベクトルデータベースの維持、検索精度のチューニング、定期的な更新作業...エンジニアリングコストが膨大です。
ChatGPTのシンプルな方式は、構築コストがほぼゼロ。OpenAIにとっては「モデルを強化すればいい」だけです。
使い分けの基準
結局、RAGとシンプルコンテキスト注入の使い分けは タスクの性質 で決まります。
- 日常会話（ChatGPT）: シンプル注入で十分。速くて便利。
- 企業の膨大な文書検索: RAGが有利。数十万件から関連情報だけを効率的に取り出せる。
- 高精度な文献理解: ロングコンテキストが優位。
OpenAIの選択は「一般ユーザーの会話」には最適化されていますが、高度なエージェントタスクには別のアプローチが必要になる可能性があります。実際、プロダクションシステムの多くは ハイブリッドアプローチ を採用し始めています。
ベクトル検索の代替としてのSQL
興味深いのは、一部の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の速さと便利さ」は、この割り切った設計思想の賜物と言えるでしょう。
参考
- Manthan Gupta "I Reverse Engineered ChatGPT's Memory System, and Here's What I Found!"
- Shlok Khemani "ChatGPT Memory and the Bitter Lesson"
- Blockchain.news "ChatGPT Memory Architecture: Four-Layer Context System Prioritizes Speed Over RAG and Vector Databases"
- Johann Rehberger "Hacking ChatGPT's Memory to Expose a Major Security Flaw"
- Google DeepMind & University of Michigan "RAG vs Long-Context ICL" - Qiita記事
- Hacker News Discussion - ChatGPT Memory System
Discussion