🧠 技術調査 - OpenAI Dreaming に学ぶAIエージェント記憶設計の6区分

検証日: 2026-06-06 / 一次ソース: OpenAI 公式ブログ「Dreaming」(2026-06-04) + Memory FAQ。本記事は OpenAI の ChatGPT メモリ再設計「Dreaming」を 1 事例として、業務 AI エージェントの記憶設計を 保存・参照・失効・訂正・評価・ガバナンス の 6 区分で整理し、Mem0 / Zep(Graphiti) / Letta(MemGPT) / Claude memory tool と対比します。数値は一次（OpenAI 公式ブログ・Memory FAQ）/ 二次 / 自己申告の区別を明示しています。

■概要

Dreaming とは何か

2026-06-04、OpenAI は ChatGPT のメモリアーキテクチャを再設計した「Dreaming（V3）」のロールアウトを開始しました（一次: 公式ブログ冒頭 "June 4, 2026"）。公式ブログの冒頭リードは課題を次のように定義します（一次・原文引用）。

Today we're beginning to roll out a more capable and scalable system for synthesizing memory, developed to tackle the staleness, correctness, and scalability challenges that we observe when memory is applied to the hundreds of millions of users and multi-year time horizons in ChatGPT.

• Staleness（陳腐化）: 記憶が時間の経過とともに古くなり、誤情報・無関係情報になります。
• Correctness（正しさ）: 複数の記憶が互いに矛盾しえます（例: "マラソン練習中" と "足首を捻挫した"、FAQ）。
• Scalability（スケーラビリティ）: 数億ユーザー・複数年スパンに対応できる設計が必要です。

この 3 課題に対処するために導入されたのが「dreaming」と呼ぶバックグラウンドプロセスです（一次）。

In contrast to saved memories, dreaming leverages a background process that allows ChatGPT to learn from many conversations and synthesize ChatGPT's memory state in order to always provide the freshest, most relevant context to your conversations.

dreaming は明示的な「覚えて」コマンドに依存せず、会話に自然に現れた文脈を自動で取り込みます。更新された memory state は memory summary として可視化・編集でき、会話への注入文脈として常に最新状態を供給します（一次: FAQ "a continually updated synthesis of context from your past chats"）。

saved memories からの進化（2024 → 2025 → 2026）

（一次: 公式ブログ「How memory has evolved」「How we evaluate memory」各セクション）

なぜ業務記憶設計の素材になるか

Dreaming は「保存と参照」だけだった旧来のメモリ設計に、失効・訂正・時間対応 という軸を加えた点で業務 AI エージェント設計への示唆が大きいです。

1. 課題の普遍性: staleness / correctness / scalability は、業務エージェントが長期ユーザーデータを扱う際にも共通して発生します。
2. 3 軸フレームの実用性: freshness / continuity / relevance という整理は、自社メモリ設計の評価基準を構造化する出発点になります。
3. 限界の両面性: Dreaming は課題を「解決済み」とは述べておらず、自己申告ベンチマークの透明性や削除の難しさといった限界も文書化されています。業務設計で「何を自前で埋めるか」の判断材料になります。

■特徴

1. 明示保存から自動合成へ

旧 saved memories の問題は、強い手がかりがないと書かれない点でした（一次: "relied on strong cues"）。Dreaming はこの制約を取り除き、会話の流れに自然に現れた情報を バックグラウンドで自動合成 します。合成された記憶は memory summary として可読・編集可能なサマリに集約され、ユーザーはテキスト編集・ハイライト訂正・"Don't mention this again"（参照抑制、削除ではない）でコントロールできます（一次: FAQ）。

2. 3 軸による評価・最適化

公式ブログのサブタイトルは最適化の 3 軸を明示します（一次: "optimize for freshness, continuity and relevance"）。本文「How we evaluate memory」では 3 軸を評価目的として展開します。

時間対応の具体例（一次）: "You're going to Singapore in July" → やがて "You went to Singapore in July 2026" へと書き換わります。

数値について（重要）: 各軸の改善を示すベンチマーク（Fact recall 82.8% / Preference 71.3% / Time-sensitive 75.1%、2024年比較値 41.5% / 31.4% / 52.2% 等）は、公式ブログのグラフ画像内に埋め込まれており本文テキストとして取得できませんでした。これらは OpenAI 自己申告・図中値・独立検証なし の値です（二次情報: allthings.how / techtimes、techtimes は "not independently verified" と明記）。

3. コンピュート効率と展開計画

• ロールアウト開始: 2026-06-04、まず US の Plus / Pro。以降 coming weeks で Free / Go と追加国へ（一次）。
• Free 向けの serving compute を約 5x（approximately 5x）削減 したことが Free 展開を可能にしました（一次・"approximately 5x" 明記）。
• Plus / Pro のメモリ容量も増加（"increase memory capacity" と一次に明記。具体倍率「2x」は二次: techtimes のみ）。
• US 以外の具体国名は一次・二次とも確認できず（"additional / more countries" 止まり）。

4. ユーザーコントロール（一次: Memory FAQ）

5. 他システムとの比較

業務 AI エージェントの記憶設計を検討する際に参照しやすいよう、Dreaming を代表的な OSS・商用メモリシステムと並べます。GitHub star 数は 2026-06-06 時点の概数です。

横断インサイト: 本稿で比較した範囲では、「失効を構造で持つ」のは Zep/Graphiti の双時間モデルだけです。Dreaming と Mem0 は「上書き・書き換え」で陳腐化に対処しますが、これは "latest truth wins" ゆえに 一度の誤書き込みがストアを汚す（one bad write pollutes the store） リスクと表裏です。Claude memory tool / Letta / Dreaming（完全削除経路）は失効を実装者・モデルの運用に委ねるため、業務利用では運用方針の事前定義が必要です。

■構造

業務 AI エージェントの「記憶サブシステム」を論理構造として C4 model に読み替えて図解します（Pattern B）。

●システムコンテキスト図

主要アクターと記憶サブシステム、外部システムの関係を示します。具体的な製品名・実装名は含めません。

アクター

外部システム

●コンテナ図

記憶サブシステムの内部を「記憶設計 6 区分」で分解します。Dreaming のバックグラウンド合成プロセスも独立したコンテナとして配置します。

subgraph: 入力層・合成プロセス

subgraph: 保存 store・参照 retrieve

subgraph: 失効 expire・訂正 correct・評価 eval・ガバナンス governance

●コンポーネント図

保存・失効・訂正の内部をドリルダウンし、各実装パターンがどの製品・研究に対応するかを示します。

保存コンポーネント（store）の内部

失効コンポーネント（expire）の内部

訂正コンポーネント（correct）の内部

■データ

●概念モデル

記憶設計に登場するエンティティとその所有・利用関係を示します。所有関係は subgraph でグループ化し、利用関係は矢印で表現します。

●情報モデル

概念モデルのエンティティと対応させた classDiagram です。属性は Dreaming/Zep の一次記述に整合する主要なものを記載し、一次記述に無い属性は「(推測/補完)」と注記します。

■構築方法

ChatGPT 側で Dreaming を使う・制御する設定

Dreaming を有効化・調整する操作は ChatGPT の UI と FAQ が一次根拠です。

完全削除の手順（抑制と混同しないこと）: "Don't mention this again" は参照抑制であり削除ではありません。GDPR「忘れられる権利」の行使や個人情報の完全除去には次の全ソース削除が必要です。

1. memory summary から個別メモリを削除する。
2. 過去チャット・アーカイブを削除する。
3. アップロード済みファイルを削除する。
4. 連携アプリを切断する。
5. 削除後も安全・デバッグ目的で最大 30 日ログが保持される点に注意する。

自前エージェントに記憶を組み込む際の前提

「メモリを入れる」と一括りにせず、保存・参照・失効・訂正 を別々の設計判断として扱うことが前提です。ガバナンス要件はストア選定より 先に 決定します。

選定前に固める確認事項:

• 何を覚えてはいけないか（PII/健康/信条/業務機密のカテゴリ定義）。
• 記憶の書き込み・参照を監査ログで追えるか。
• テナント分離（ユーザー間・組織間の記憶リーク防止）は必要か。
• GDPR 等の削除権に対応するため記憶を外部ストアに隔離できるか。

■利用方法

記憶設計 6 区分のうち 保存・参照・失効・訂正 の 4 区分を実装例で示します。コードはすべて 実装案/例 であり、実際の API キー・設定は公式ドキュメントで確認してください。

保存 — Mem0 で会話から事実を抽出して add する

# 実装案/例: Mem0 で会話から事実を自動抽出して保存する
# pip install mem0ai / 公式: https://docs.mem0.ai/core-concepts/memory-operations/add
from mem0 import Memory

config = {
    "vector_store": {
        "provider": "qdrant",
        "config": {"host": "localhost", "port": 6333},
    },
}
m = Memory.from_config(config)

messages = [
    {"role": "user", "content": "私はベジタリアンです。ランチにサンドイッチを食べました。"},
    {"role": "assistant", "content": "了解です。ベジタリアン向けのメニューをご提案しますね。"},
]

# user_id を必ず渡す。記憶はユーザー単位で分離される
result = m.add(messages=messages, user_id="user_alice")
print(result)
# 例: {'results': [{'id': '...', 'memory': 'アリスはベジタリアン', 'event': 'ADD'}]}

infer=False にすると矛盾解消・重複防止がスキップされ生データが保存されます。誤書き込みがストアを汚染する（"one bad write pollutes the store"）リスクが上がるため、意図的な場合のみ使用してください。

保存前の PII フィルタリング（実装案/例）:

# 実装案/例: 保存前に PII カテゴリを除外するフィルタ
import re

PII_PATTERNS = [
    r"\b\d{3}-\d{4}-\d{4}\b",         # 電話番号（日本形式）
    r"\b\d{4}-\d{4}-\d{4}-\d{4}\b",   # クレジットカード番号
]

def contains_pii(text: str) -> bool:
    return any(re.search(p, text) for p in PII_PATTERNS)

safe_messages = [msg for msg in messages if not contains_pii(msg["content"])]

参照 — ベクトル検索・グラフ検索・summary 注入の使い分け

# 実装案/例: Mem0 で直近の関連記憶をベクトル検索して取得する
# 公式: https://docs.mem0.ai/core-concepts/memory-operations/search
results = m.search(query="今日のランチで何がお勧めですか？", user_id="user_alice", limit=5)

memory_context = "\n".join(f"- {r['memory']}" for r in results["results"])
system_prompt = f"""あなたはユーザーをサポートするアシスタントです。
ユーザーについて知っていること:
{memory_context}
"""

# 実装案/例: Graphiti で時系列グラフをハイブリッド検索する
# pip install graphiti-core / 公式: https://github.com/getzep/graphiti
from graphiti_core import Graphiti

client = Graphiti(neo4j_uri="bolt://localhost:7687", neo4j_user="neo4j", neo4j_password="***")
results = await client.search(query="アリスの食事制限", num_results=5)
for fact in results:
    print(f"事実: {fact.fact} / 有効期間: {fact.valid_at} 〜 {fact.invalid_at}")

Zep/Graphiti はグラフ走査と BM25 を組み合わせて sub-second レイテンシを実現します（arXiv:2501.13956 の論文値。公式ドキュメント要確認）。

失効 — Zep の双時間モデルで「上書きせず invalidate」する

古い事実を削除するのではなく invalid_at をセットして無効化することで、「現在の真実」と「過去の任意時点での真実」の両方をクエリできます。

# 実装案/例: Graphiti に新エピソードを追加すると矛盾する旧エッジが自動 invalidate される
# 公式: https://github.com/getzep/graphiti
from datetime import datetime
from graphiti_core import Graphiti
from graphiti_core.nodes import EpisodeType

async def update_memory_with_invalidation():
    client = Graphiti(neo4j_uri="bolt://localhost:7687", neo4j_user="neo4j", neo4j_password="***")
    # 旧事実: 7月にシンガポールへ行く予定
    await client.add_episode(
        name="trip_plan", episode_body="アリスは2026年7月にシンガポールへ行く予定です。",
        source=EpisodeType.text, reference_time=datetime(2026, 6, 1), source_description="会話ログ",
    )
    # 新事実: 旅行後の更新（Graphiti が自動で旧エッジを invalidate）
    await client.add_episode(
        name="trip_done", episode_body="アリスは2026年7月にシンガポールへ行きました。",
        source=EpisodeType.text, reference_time=datetime(2026, 8, 1), source_description="会話ログ",
    )
    # → 旧エッジは無効化され、内部的に invalid_at 相当（2026-08-01）が付与される想定

双時間モデルの時間軸（概念図）:

event time    |------[行く予定]----X  [行った]-------->
              valid_at=2026-06    invalid_at=2026-08  valid_at=2026-08
ingestion time  ↑書込              ↑失効記録          ↑新エッジ書込
                created_at=...     expired_at=...     created_at=...

削除せず invalidate することで「過去の任意時点で何が真だったか」を復元でき、監査要件のある業務環境で重要です。

訂正 — ユーザー編集・参照抑制・矛盾解消

# 実装案/例: Mem0 の矛盾解消（latest truth wins）
m.add(messages=[{"role": "user", "content": "私は東京に住んでいます。"}], user_id="user_alice")
# → ADD: {'memory': 'アリスは東京に住んでいる', 'event': 'ADD'}
m.add(messages=[{"role": "user", "content": "先月、大阪に引っ越しました。"}], user_id="user_alice")
# → UPDATE: {'memory': 'アリスは大阪に住んでいる', 'event': 'UPDATE'}（旧記憶は残らない）

# 手動 CRUD（GDPR 削除権・退職者対応の実装例）
m.update(memory_id="memory-id-xxx", data="アリスは大阪（梅田）に住んでいる")
m.delete(memory_id="memory-id-yyy")
m.delete_all(user_id="user_alice")

Mem0 の矛盾解消は latest truth wins で動き、旧記憶が残りません。「過去どこに住んでいたか」は別途 Recall ストアや Zep で管理します。

# 実装案/例: Letta で参照抑制ルールを core memory ブロックに追記する（"Don't mention" 相当）
# 公式: https://docs.letta.com/guides/ade/core-memory/
client.agents.blocks.update(
    agent_id="my-agent-id", block_label="persona",
    value="あなたは親切なアシスタントです。ユーザーの食事制限については言及しないでください。",
)

重要: 抑制は「参照しない」指示でありストアからの削除ではありません。完全削除は m.delete() / m.delete_all() を使い、UI・コードで「抑制」「論理削除」「物理削除」を明確に区別してください。

■運用

記憶の鮮度維持 — 時点書き換えと減衰の設計

Dreaming は「7月にシンガポールへ行く」→「2026年7月にシンガポールへ行った」と時間経過で自動書き換えします（一次）。便利な一方、書き換えのタイミングや根拠が不透明という運用リスクを持ちます。業務エージェントでは次の 3 点を明示的に持つことを推奨します。

• time_point（時点メタデータ）: 各記憶エントリに valid_from / valid_until を付与する。Zep/Graphiti の双時間モデル（arXiv:2501.13956）が代表例。
• 減衰スコア: Generative Agents（arXiv:2304.03442）の指数減衰（係数 0.995）を参考に「最終参照からの経過 × 参照頻度」でスコアを下げる。ACT-R ベースのモデル（HAI 2025, ACM DOI 10.1145/3765766.3765803）は冪減衰で「頻繁に参照された記憶は減衰が遅い」を実現する。
• 鮮度トリガ条件の明示: 「旅行終了後」「プロジェクト完了後」などの業務イベントをトリガとして明示定義する。自動推論に任せると誤タイミングで書き換えが起きる。

矛盾解消の運用

矛盾解消はベンチマークでも「最も未成熟な領域」とされます（arXiv:2603.07670・サーベイ・プレプリント、査読未確認）。

1. 書き込み前の矛盾チェック: 新規エントリ追加前に既存ストアをセマンティック検索し矛盾を検出する。SSGM（arXiv:2603.11768・プレプリント、査読未確認）は consistency verification を統合前の必須ステップとする。
2. 無効化と削除を区別する: 上書きでなく旧エントリを invalid_at でマークして残す。削除すると「なぜ変わったか」の監査証跡が失われる。
3. 人手レビューの挿入ポイントを決める: 矛盾スコアが閾値超過時にフラグを立て、自動解消せずユーザー確認を挟む。完全自動の矛盾解消は semantic drift を静かに進行させる。

削除・忘却の扱い — 削除ログ 30 日・完全削除は全ソース

• 誤解: 「削除ボタンを押せば記憶は消える」
• 反証: FAQ（一次）で "Don't mention again" は参照抑制であり削除ではないと明記。完全削除は全ソース削除が必要で、削除ログは最大 30 日保持。学術調査（arXiv:2602.01450, ACM WWW'26）では ChatGPT の記憶の 96% がシステム側の一方的生成、ユーザー主導は 4% と報告（同論文の調査条件・サンプル・判定基準に依存する値）。
• 推奨: 「抑制」と「完全削除」を UI とデータ層の両方で区別する。完全削除は全会話ログから当該エントリを削除するパイプラインを用意する。削除ログ保持期間を明示定義する（30 日は OpenAI の設計だが GDPR 消去義務と照らして要検討）。実際に削除される範囲をユーザーに明示する。

容量管理 — recency × frequency

OpenAI は容量管理の優先度判定に recency × frequency を用います（FAQ・一次）。これは Generative Agents の検索スコア（arXiv:2304.03442）と発想が近いものです。

• 容量上限を決め超過時の優先度ルールを明示する（何も決めないと古い重要な記憶が押し出される）。
• recency だけに頼らず importance（重要度タグ）を別途持つ。
• cold storage への退避ルールを定義する（一定期間未参照の記憶を削除でなく cold tier へ）。MemGPT の仮想コンテキスト管理（arXiv:2310.08560）が参照実装。

評価の回し方 — 自前ドメインで 3 軸を測る

• 誤解: 「公表ベンチ（82.8% / 71.3% / 75.1%）が良ければ十分」
• 反証: これらは OpenAI 内部評価で評価セット非公開・独立検証なし・他社比較なし（implicator.ai・techtimes〔二次〕）。さらに LoCoMo でほぼ満点のシステムが MemoryArena（arXiv:2602.16313・プレプリント）のエージェント環境では大きく低下すると報告され（具体値 40〜60% は二次情報、MemoryArena 本文で一次未確認）、「静的 recall ベンチ ≠ 実運用記憶性能」。
• 推奨: LongMemEval（arXiv:2410.10813, ICLR 2025）と LoCoMo（arXiv:2402.17753）の課題設計を参考に、自前ドメインで以下を測定する。

■ベストプラクティス

記憶設計を 6 区分に分けて個別に決める

「メモリを入れる」と一括りにせず 保存・参照・失効・訂正・評価・ガバナンス を個別に設計します。この分解は arXiv:2603.07670（サーベイ・プレプリント、査読未確認）が write–manage–read として定式化しています。区分が混在すると、失効の設計不備を参照コストで補うなど非効率な補完が生じます。

失効を上書きだけに頼らない — 出所と時点を残す

• 誤解: 「latest-truth-wins で上書きすれば古い記憶は無害化できる」
• 反証: SSGM（arXiv:2603.11768・プレプリント、査読未確認）は write isolation を持たないアーキテクチャでは一度の誤書き込みが長期記憶を汚染する（"one bad write pollutes the store"）と指摘。Mem0（arXiv:2504.19413）も操作分離でこのリスクを緩和。
• 推奨: 各エントリに source_conversation_id と written_at を必ず付与する。上書きでなく「旧エントリを invalid_at でマーク + 新エントリ追加」で記録する。Zep/Graphiti の双時間モデル（arXiv:2501.13956）が OSS 実装の参照。

訂正をユーザーが触れる形に保つ

Dreaming の memory summary（閲覧・編集・ハイライト訂正・出所表示）は良い設計の方向性を示します。ただし「Don't mention again = 削除」という誤解を UI で招いてはなりません（一次: FAQ）。

• 記憶エントリの一覧表示と個別編集の UI を用意する。
• 「抑制」「論理削除」「完全削除（全ソース）」を明確に区別しラベルで示す。
• 出所（どの会話のどの発言から書き込まれたか）を表示する。

評価を自前で持つ — 自己申告ベンチを鵜呑みにしない

ベンチマーク数値をそのまま意思決定の根拠にするのは危険です。自分のユースケース・ドメイン・言語・タスク依存性で評価を設計します（「運用」の評価の回し方を参照）。

ガバナンスを保存設計より先に固める

• 誤解: 「まず動くものを作ってからプライバシー対応は後で考える」
• 反証: arXiv:2602.01450（ACM WWW'26）によれば記憶の 28% に GDPR 定義の個人データ、52% に心理的推察が含まれる。自動学習型の記憶は気づかぬうちに PII・心理プロファイルを蓄積し、parametric 化した記憶は machine unlearning が未成熟で消去困難。
• 推奨:
  • 覚えてはいけない情報の定義: 健康・信条・給与・顧客機密・当事者が拒否した情報を書き込み抑制カテゴリとする。
  • 監査ログの設計: 「誰の発言から、いつ、何が書き込まれ、誰がいつ参照したか」を記録する。記憶を重みでなく外部ストアに置くと監査が容易。
  • GDPR 訂正権・削除権の動線: 訂正（Art.16）と削除（Art.17）それぞれに応答するパイプラインを事前設計する。
  • 退職者・テナント越境の対策: 組織離脱イベントをトリガに記憶の削除フックを設定する。

■トラブルシューティング

■まとめ

OpenAI の Dreaming は、ユーザーの明示保存に頼らずバックグラウンドで記憶を合成し、鮮度・継続性・関連性の 3 軸で最適化する記憶アーキテクチャです。一方で、自己申告ベンチ・削除の難しさ・記憶汚染という限界も残るため、業務エージェントに転用するなら 保存・参照・失効・訂正・評価・ガバナンス の 6 区分に分け、失効や評価やガバナンスは自前で設計する姿勢が重要になります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

■参考リンク

• 一次ソース（公式）
  • OpenAI - Dreaming: Better memory for a more helpful ChatGPT (2026-06-04)
  • OpenAI Help Center - Memory FAQ
• 関連メモリシステム（公式ドキュメント・リポジトリ）
  • Mem0 - Memory Operations docs
  • Mem0 - GitHub
  • Graphiti - GitHub
  • Zep - GitHub
  • Letta - Core Memory docs
  • Letta - GitHub
  • Anthropic - Claude memory tool docs
  • LangMem - docs
• 学術系譜（記憶設計の骨子）
  • Generative Agents (arXiv:2304.03442)
  • MemGPT (arXiv:2310.08560)
  • Reflexion (arXiv:2303.11366)
  • Mem0 (arXiv:2504.19413)
  • Zep / Graphiti (arXiv:2501.13956)
  • Memory for Autonomous LLM Agents (arXiv:2603.07670, プレプリント)
• 評価ベンチマーク
  • LongMemEval (arXiv:2410.10813, ICLR 2025)
  • LoCoMo (arXiv:2402.17753)
  • MemBench (arXiv:2506.21605, ACL 2025 Findings)
  • TempReason (arXiv:2306.08952)
  • MemoryArena (arXiv:2602.16313, プレプリント)
• 反証・限界
  • The Algorithmic Self-Portrait (arXiv:2602.01450, ACM WWW'26)
  • SSGM (arXiv:2603.11768, プレプリント・査読未確認)
  • TiMem (arXiv:2601.02845)
  • Center for Democracy and Technology - Dark Patterns in AI Chatbots
• 二次（数値・主張の出所、独立検証なし）
  • implicator.ai - OpenAI will expand ChatGPT memory after 5x compute cut
  • mem0.ai - State of AI Agent Memory 2026 (競合ベンダー・利益相反あり)