{
  "issue": "2026-07-28",
  "generated_at": "2026-07-28T07:00:00+09:00",
  "theme": {
    "title": "エージェントのメモリ設計 — 保存容量ではなく「書き込みの境界線」を設計する",
    "category": "agent-memory",
    "lede": "エージェントが複数セッションにまたがって学習・継続動作するようになるにつれ、「何を覚えておくか」の設計が改めて焦点になっている。Anthropic は Claude Managed Agents にファイルベースの長期メモリと監査ログを追加し、Cursor はツール定義や過去の会話を常駐させず必要な時だけ取得させる構成でトークン消費を46.9%削減し、OpenAI は Agents SDK の実装例で短期メモリと長期メモリの境界を書き込み時のガードレールで引いている。3社の手法を並べると、メモリ設計が「保存容量を増やす」話ではなく「どこで区切り、何を書かせないか」を先に決める設計行為になっていることが見えてくる。",
    "tldr": [
      "Anthropic は Claude Managed Agents の記憶をファイルとして保存し、監査ログ・ロールバック・スコープ別パーミッションを標準機能として public beta で提供している",
      "Cursor はツール定義や過去の会話をデフォルトで常駐させず、grep/tail/セマンティック検索で必要な時だけ取得させる設計により、MCPツール呼び出し時のエージェント総トークン消費を46.9%削減したと報告している",
      "OpenAI の Agents SDK 実装例は、長期メモリへの書き込みを「恒常的に成り立つか」「実際に挙動を変えるか」の2条件でガードし、セッションメモがグローバルメモに優先する明示的な優先順位ルールで汚染を防いでいる"
    ],
    "sections": [
      {
        "heading": "ファイルベースの長期メモリと監査ログ",
        "body_html": "<p>Claude Managed Agents 向けに2026年4月23日に公開された Memory 機能は、記憶を構造化データベースではなく通常のファイルとして保存する設計を取る。エージェントは既存の bash・コード実行能力をそのまま使って記憶を読み書きし、org 全体で共有する読み取り専用ストアとユーザーごとの読み書き可能なストアを使い分けられる。どの変更がどのエージェント・どのセッションに由来するかを追う監査ログが標準で付き、過去バージョンへのロールバックや履歴からの redact も可能だ。</p><p>この設計が選ばれたのは、ベクトル DB や専用メモリストアを新たに構築せずに済むからだ。コーディングエージェントはすでにファイルシステム操作を前提に訓練・運用されており、「ファイルとして保存する」は既存の道具立てに乗るだけで実装できる。逆に監査ログとロールバックを標準機能にしたのは、エンタープライズ導入で「エージェントが何を学習し、なぜその判断に至ったか」を追跡できないと承認が下りないという実務上の制約が先にあったからだ。</p>",
        "examples": [
          {
            "product": "Claude Managed Agents Memory（Anthropic 公式ブログ）",
            "approach": "記憶をファイルとして保存し、監査ログ・ロールバック・スコープ別パーミッションを標準機能として提供",
            "detail": "Rakuten は初回パス誤り率97%減・コスト27%減・レイテンシ34%減、Wisedocs は書類検証の速度を30%改善したと公式に報告している",
            "source_url": "https://claude.com/blog/claude-managed-agents-memory"
          }
        ],
        "takeaway": "コーディングエージェント基盤の上に長期メモリを足すなら、専用DBより先にファイル＋監査ログの構成を検討する。エンタープライズ導入の障壁は記憶の性能より追跡可能性であることが多い。"
      },
      {
        "heading": "静的に持たせず、必要な分だけ取りに行かせる",
        "body_html": "<p>Cursor が公開した dynamic context discovery は、ツール定義や過去の会話、MCPサーバーのツール一覧をあらかじめすべてコンテキストに詰め込むのではなく、最小限の手がかりだけを常駐させ、必要になった時にエージェント自身が grep や <code>tail</code>、セマンティック検索で取りに行く設計だ。長い shell 出力や MCP の応答はファイルに書き出し、エージェントが <code>tail</code> で必要な分だけ読み進める。要約で失われた過去の会話も、検索可能なファイルとして残すことで後から引き出せるようにしている。</p><p>この方式が効くのは、MCPサーバーの数が増えるほど全ツール定義を毎回コンテキストに載せるコストが線形に膨らみ、しかも大半のターンでは使わないツールの説明が「使われない高コストな常駐者」になるからだ。Cursor は MCP ツールを呼び出したランに限定した計測で、この方式がエージェントの総トークン消費を46.9%削減したと公式に報告している。</p>",
        "examples": [
          {
            "product": "Cursor（公式エンジニアリングブログ）",
            "approach": "スキル定義・MCPツール一覧・過去の会話をデフォルトで最小化し、grep/tail/セマンティック検索でエージェントに必要な分だけ取得させる",
            "detail": "MCPツールを呼び出したランに限定した計測で、動的発見によりエージェントの総トークン消費を46.9%削減したと報告している",
            "source_url": "https://cursor.com/blog/dynamic-context-discovery"
          }
        ],
        "takeaway": "ツール定義やドキュメントを「念のため全部常駐させる」のをやめる。特に MCP サーバーが増えてきたら、ツール一覧はインデックスだけ持たせて詳細は呼び出し時に取得させる設計に切り替える。"
      },
      {
        "heading": "短期はセッション、長期はグローバル — 境界は「書く前のチェック」で引く",
        "body_html": "<p>OpenAI Agents SDK の実装例は、状態を Profile（構造化された既知情報）・Global Memory（セッションをまたぐ長期メモ）・Session Memory（今回限りの短期メモ）・Trip History に分けて管理する。長期メモへの書き込みは save_memory_note ツールを経由し、「複数回の利用を通じて成り立ちそうか（durable）」「実際にレコメンドや制約を変えるか（actionable）」の2条件を満たした場合のみ保存を許可する。セッション終了時には LLM 呼び出しでセッションメモをグローバルメモへ統合し、重複排除と競合解消（新しい情報を優先）を行う。会話履歴そのものの管理には、直近 N ターンだけを残す Trimming と、古いターンを要約に圧縮する Summarizing の2方式があり、前者は決定的でレイテンシ0、後者は長期文脈を保てる代わりに要約起因の情報汚染リスクを持つとされる。</p><p>この二層設計と書き込み時ガードレールが必要になるのは、「今回だけ窓側の席がいい」のような一回限りの要望と、「いつも通路側」のような恒常的な好みを同じ場所に書くと、次回以降のレコメンドが一回限りの要望に汚染されるからだ。OpenAI の実装は「セッションメモがグローバルメモに優先する」という明示的な優先順位ルールを持たせることで、この汚染を読み出し時ではなく書き込み・統合時に処理している。</p>",
        "examples": [
          {
            "product": "OpenAI Agents SDK（公式Cookbook, context personalization）",
            "approach": "Global/Session の二層メモリを save_memory_note の durable/actionable チェックと統合時の重複排除・競合解消で運用",
            "detail": "「SESSION memory overrides GLOBAL memory for this trip when they conflict」という明示的な優先順位ルールを実装コードごと公開している",
            "source_url": "https://developers.openai.com/cookbook/examples/agents_sdk/context_personalization"
          },
          {
            "product": "OpenAI Agents SDK（公式Cookbook, session memory）",
            "approach": "会話履歴の圧縮を Trimming（直近Nターン保持）と Summarizing（要約圧縮）の2方式で使い分ける実装を公開",
            "detail": "Trimming は決定的でレイテンシ0だが古い文脈を失うリスク、Summarizing は長期文脈を保てるが要約起因の「context poisoning」リスクがあるとトレードオフを明記している",
            "source_url": "https://developers.openai.com/cookbook/examples/agents_sdk/session_memory"
          }
        ],
        "takeaway": "長期メモを持たせるなら、書き込み時に「恒常的に成り立つか」「実際に挙動を変えるか」の2条件チェックを先に入れる。一回限りの要望と恒常的な好みを同じ場所に書かせると、次回以降の挙動が汚染される。"
      }
    ]
  },
  "editorial": "3社の実装が揃って示すのは、エージェントのメモリ設計がもはや「何を保存するか」ではなく「どこに書き込みの境界線を引くか」の設計行為になっているということだ。Anthropic はファイル＋監査ログで追跡可能性を、Cursor は常駐させないことでトークン効率を、OpenAI は書き込み時ガードレールで汚染防止を、それぞれ別の軸で解いている。どれも「メモリを増やす」のではなく「メモリの粒度と境界を制御する」方向の工夫である点に注目したい。",
  "quick_picks": [
    {
      "title": "Anthropic、長時間タスクでは CHANGELOG.md が「失敗した試み」を記録する携行型長期メモリになると報告",
      "summary": "科学計算エージェントの事例で、進捗ファイルに失敗したアプローチとその理由を記録することで、次のセッションが同じ行き止まりを再試行しなくなると説明する。本文で扱った「何を書くかより何を書かないかを決める」設計と同じ発想の実例。",
      "url": "https://www.anthropic.com/research/long-running-Claude"
    },
    {
      "title": "Anthropic、長文脈エージェントの実務指針として compaction・構造化ノート・サブエージェント分離の3手法を整理",
      "summary": "コンテキストウィンドウを使い切る前に要約して引き継ぐ compaction、NOTES.md 的な外部メモリへの構造化ノート、サブエージェントが1000〜2000トークンの要約だけを返す設計を公式に解説する。本文セクション1・2で扱った「メモリの粒度を絞る」設計判断の上位概念として読める。",
      "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents"
    }
  ]
}
