{
  "issue": "2026-08-25",
  "generated_at": "2026-08-25T07:00:00+09:00",
  "theme": {
    "title": "エージェントのメモリ設計 — 生ログでも単一要約でもなく、書き換え可能な単位に分解する",
    "category": "agent-memory",
    "lede": "2026年に入り、OpenAI と Anthropic はほぼ同時期に、消費者向けチャットとエージェント製品の双方でメモリ機構を刷新した。共通しているのは「会話をそのまま貯める」「1本の要約文にまとめる」のどちらでもなく、書き換え可能な小さい単位に分解して保存する設計への転換だ。だが記憶をいつ作り直すか、どこに保存するかという次の設計判断は各社で割れており、この2軸が実装の分かれ目になっている。",
    "tldr": [
      "Claude は2026年7月、記憶を単一のローリング要約から個別の書き換え可能なエントリへ移行。ChatGPT は非同期の「Dreaming」処理で古い事実を時制ごと書き換える。",
      "Claude Managed Agents はセッション中のリアルタイム書き込みと、セッション間で横断整理するバッチ処理（Dreaming）を明確に分けて提供する。",
      "Claude API の memory tool はモデルがファイル操作を要求するだけで保存先を開発者側に残す設計で、mem0 のような専業ベンダーに記憶レイヤーごと預ける選択肢と対比できる。"
    ],
    "sections": [
      {
        "heading": "会話ログでも単一の要約でもなく、書き換え可能な個別エントリへ",
        "body_html": "<p>従来の2方式にはそれぞれ弱点があった。生の会話履歴をそのまま保持する方式はコンテキストコストが際限なく膨らみ、1件の誤りを消すために関係ない発言まで巻き込む。1本の要約文に凝縮する方式は逆に、1つの事実を訂正するには要約全体を書き直す必要があり、その過程で無関係な情報が欠落するリスクがある。</p><p>今の主流は、記憶を「1つの検証可能な事実」を単位にした個別レコードへ分解し、それぞれを独立に読み書き・削除できるようにすることだ。単位を細かくするほど、間違いの訂正や失効判定を他の記憶に影響させずに局所化できる。</p>",
        "examples": [
          {
            "product": "Claude（Anthropic、コンシューマー向けメモリ）",
            "approach": "単一のローリング要約から、カテゴリ分けされた個別エントリへ移行",
            "detail": "2026年7月10日、Anthropic は Claude の記憶を「毎日更新される1本の要約文」から「会話中に読み書きされるカテゴリ別の個別エントリ」に置き換えた。ユーザーは1件だけを確認・修正・削除でき、他の記憶を巻き込まない。",
            "source_url": "https://support.claude.com/en/articles/12138966-release-notes"
          },
          {
            "product": "ChatGPT（OpenAI、Dreaming）",
            "approach": "対話とは別のバックグラウンド処理が記憶を継続的に再統合し、古い事実を書き換える",
            "detail": "2026年6月に展開された新アーキテクチャでは、複数の会話から学習する専用プロセスが「7月にシンガポールに行く予定」を「7月にシンガポールに行った」のように時制ごと更新する。ユーザーが読める要約ページとして提示され、項目単位の追加・修正に対応する。",
            "source_url": "https://openai.com/index/chatgpt-memory-dreaming/"
          }
        ],
        "takeaway": "メモリを実装するなら保存の最小単位を「会話」や「1つの人物像」ではなく「検証可能な1事実」に置く。単位が細かいほど訂正と失効判定のコストが下がる。"
      },
      {
        "heading": "記憶を作り直すタイミング — セッション中のリアルタイム書き込みか、セッション間のバッチ処理か",
        "body_html": "<p>もう一つの分かれ目は更新のタイミングだ。作業しながらその場でファイルに書き込む同期方式は即時性が高い一方、1セッションの視野に閉じるため冗長な記憶が溜まりやすい。対して、複数セッションが終わった後にまとめて見直す非同期方式は、単体のセッションでは見えないパターン（繰り返し起きるミスや複数エージェント間の共通知見）を検出できる。</p><p>企業向けのエージェント製品が後者を別立てで用意するのは、記憶を横断的にマージ・重複排除できるだけでなく、自動推論された記憶が人のレビューを経ずに将来の挙動を静かに変えてしまうリスクを、承認ゲートで止められるからだ。</p>",
        "examples": [
          {
            "product": "Claude Managed Agents（Anthropic、Memory）",
            "approach": "作業中にその場でファイルへ書き込む",
            "detail": "エージェントの記憶はファイルシステムにマウントされたファイル群として実装され、Claude は既存の bash・コード実行ツールでそのまま読み書きする。セッションの終了を待たず、作業しながら学習する設計。",
            "source_url": "https://claude.com/blog/claude-managed-agents-memory"
          },
          {
            "product": "Claude Managed Agents（Anthropic、Dreaming）",
            "approach": "セッション間で動く別プロセスが記憶を横断的に整理し直す",
            "detail": "Dreaming はスケジュール実行されるプロセスで、複数エージェントのセッションと記憶ストアを見直し、繰り返し起きるミスやチーム共通の知見を抽出して記憶を再構成する。変更を自動反映するか、人のレビュー待ちにするかを開発者が選べる。",
            "source_url": "https://claude.com/blog/new-in-claude-managed-agents"
          }
        ],
        "takeaway": "1エージェント・1セッションで完結する記憶はリアルタイム書き込みで足りる。複数エージェントや複数日にまたがる知見を集約したいなら、別立てのバッチ整理プロセスと、誤った記憶が自動適用される前に人が止められる仕組みをセットで用意する。"
      },
      {
        "heading": "誰が保存先を持つか — マネージドな記憶か、自前インフラに預ける記憶か",
        "body_html": "<p>3つ目の軸は保存先の所有権だ。モデルは <code>view</code> や <code>create</code> といったファイル操作を要求するだけで、実際の保存先とアクセス制御は呼び出し側のアプリケーションが持つクライアントサイド方式がある一方、保存から取り出しまで丸ごとベンダーやサードパーティに委ねるマネージド方式もある。</p><p>マネージド方式は導入が速いが、記憶の保存場所と保持ポリシーがベンダーのインフラに縛られる。クライアントサイド方式は、パストラバーサル対策やファイルサイズ上限の実装といった手間と引き換えに、データ所在地の制御やゼロデータリテンション対応など、企業導入で求められる要件を自分で満たせる。</p>",
        "examples": [
          {
            "product": "Claude API（Anthropic、memory tool）",
            "approach": "Claude はファイル操作を要求するだけで、保存先は開発者のアプリ側が持つ",
            "detail": "memory tool はクライアントサイド実装で、Claude が /memories 配下への view・create・str_replace・delete を要求し、実際の保存先（ディスク・DB・暗号化ストレージなど）とパストラバーサル対策は呼び出し側が実装する。ゼロデータリテンション要件に対応できるのはこの分離ゆえ。",
            "source_url": "https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool"
          },
          {
            "product": "mem0",
            "approach": "記憶レイヤー自体を専業ベンダーに委譲する",
            "detail": "2026年4月公開の新アルゴリズムは単一パスの階層抽出と複数シグナルの検索を組み合わせ、時系列が絡む質問で旧アルゴリズム比+29.6ポイントの精度改善を報告している。自前実装をせず記憶レイヤーごと外部に預ける選択肢の代表例。",
            "source_url": "https://mem0.ai/blog/state-of-ai-agent-memory-2026"
          }
        ],
        "takeaway": "データ所在地やコンプライアンス要件が強いならクライアントサイドのツールで自前インフラに保存し、そうでなければマネージドな記憶機能かサードパーティの記憶レイヤーで実装コストを削る、という順で検討する。"
      }
    ]
  },
  "editorial": "OpenAI と Anthropic は同じ2026年に、示し合わせたかのように「生ログを貯めない」設計へ収束した。だが同期か非同期か、マネージドか自前インフラかという次の階層の選択は割れたままで、この組み合わせの違いが今後1年のメモリ機構の実質的な差別化ポイントになりそうだ。",
  "quick_picks": [
    {
      "title": "Redis: Long-Term Memory Architectures for AI Agents",
      "summary": "pgvector や Redis を使い、記憶をエントリ単位で自前実装する際の具体的なデータモデルを示す。マネージドな記憶機能を使わない選択をした場合の設計の出発点になる。",
      "url": "https://redis.io/blog/long-term-memory-architectures-ai-agents/"
    },
    {
      "title": "Anthropic: Effective context engineering for AI agents",
      "summary": "Claude の memory tool ドキュメントが「広いパターン」として直接参照する記事で、記憶をコンテキストウィンドウにどう出し入れするかの設計原則をまとめている。本文で扱った「いつ記憶を作るか」の一段上にある「いつ思い出すか」の設計に相当する。",
      "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents"
    },
    {
      "title": "OpenAI: Memory and new controls for ChatGPT",
      "summary": "2024年当時の「明示的に保存を頼むメモリ」の発表で、本文で扱った Dreaming の前段にあたる旧世代アーキテクチャを示す。比較すると今回の非同期化がどこを変えたかが分かる。",
      "url": "https://openai.com/index/memory-and-new-controls-for-chatgpt/"
    }
  ]
}
