セッションをまたぐ永続メモリ — ファイルシステム型実装・監査ログ・名前空間設計

セッション境界問題 — コンテキストは消え、仕事の文脈も消える

エージェントが持つ「記憶」は、大きく2層に分かれます。1つはコンテキストウィンドウ——今のセッションで起きたことをすべて覚えている作業記憶で、数十万トークンを保持できます。問題は、セッションが終わると全内容がリセットされることです。次のセッションでエージェントは「初対面」の状態から再開します。

これは単純な不便にとどまりません。長期にわたる業務自動化では、セッションをまたいで引き継ぐべき文脈が大量に生まれます。「先月承認された変数名ルール」「過去3回の試行で判明した制約」「顧客Aが優先するコミュニケーション形式」——これらはどのセッションでも参照できるべき知識ですが、コンテキストウィンドウだけでは次のセッションに渡せません。

エージェントが複数になると、この問題は深刻化します。異なるエージェントが互いの作業結果を知らないまま、同じ顧客情報を重複して収集する。矛盾する結論を出す。先のエージェントが判明した制約を後のエージェントが踏む——こうした非効率が生まれます。永続メモリ層は、エージェント間の「引き継ぎ」を体系的に解決するアーキテクチャ的回答です。

ファイルシステムとして見せる実装（Anthropic、2026-04-23）

Anthropicは2026年4月23日、「Memory for Managed Agents」として永続メモリの仕組みを公開しました。最も特徴的な設計判断は、メモリをファイルシステムとして提供する点です。エージェントは /mnt/memory/ 以下にファイルを作成・読み書きする通常のファイル操作でメモリを扱います。専用のメモリAPIを学ぶ必要はありません。

ファイルシステムとして見せることには設計上の利点があります。エージェントはすでにファイル操作ツール（read_file・write_file・list_directory）を習熟しています。メモリ管理を「特別な操作」として扱わず、既存のツールセットで自然に扱えます。エンジニア側も、メモリの内容を直接ファイルとして検査・修正できます。

（B）ファイル形式の選択はユースケースによって変わります。Markdown 形式は、エージェントが自然言語で読み書きする際の可読性が高く、構造化と散文のバランスが取れています。設定値・ルール・承認リストなどは YAML が扱いやすく、キーバリュー構造が明確です。どの形式を選ぶかは「誰が書き、誰が読むか」で決まります——人間が確認するなら Markdown、複数エージェントが参照するなら構造化形式が適しています。

読み取り時注入（read-time injection）と背景合成

永続メモリを「いつ、どのように」コンテキストに取り込むかは実装の核心です。現在の主流は読み取り時注入（read-time injection）パターン——セッション開始時（または推論開始直前）にメモリファイルを読み込み、内容をシステムプロンプトに埋め込む設計です。エージェントはメモリを「最初から知っていること」として扱えるため、タスク実行中に別途メモリ参照ツールを呼び出す必要がありません。

（B）背景合成（background synthesis）は補完的なアプローチとして注目されています。セッション終了後にバックグラウンドプロセスがセッション内容を分析し、重要な情報を抽出してメモリを更新する仕組みです。エージェント自身が「何を覚えるか」を判断するのではなく、専用の合成プロセスが要約・整理して書き込む分業構造になります。読み取り時注入と背景合成は競合するのではなく、前者が「読む効率」を、後者が「書く品質」を担保する補完的な役割を担います。

（B）注入量には上限があります。メモリが際限なく積み重なると、注入されたメモリがコンテキストウィンドウの大半を占め、実際のタスクのための余地が圧迫されます。よく使われる対策は2つです。重要度スコアによる選択的注入——すべてのメモリを注入するのではなく、現在のタスクとの関連度が高いものだけを選ぶ。そして古いメモリの段階的アーカイブ——更新が古く参照頻度が低いファイルを別ディレクトリへ移し、通常の注入対象から外します。

よくある質問

最終更新: 2026-06