確認済みの同じメモリー記録を二つのエージェントに渡す

Anthropic の Managed Agents のメモリーストアは、セッションをまたいでテキストを保持できます。同じ確認済み事実を二つのエージェントに渡すアプリでは、永続化は最初の段階にすぎません。アプリは記録の所有者を判断し、原典の証拠を確認し、保存済みの改訂を一つ選び、どちらのエージェントに見せる前にも正確なバイト列を保持する必要があります。このガイドは Managed Agents ベータへの正規アクセスがあり、アプリの認証、ストア選択、エージェント設定を管理できる開発者向けです。根拠は、Anthropic の現行メモリードキュメントと2026年10月20日に確認した API リファレンスです。BIG CHANGE はアカウントやモデルのテストを行っていません。

大きな変化

• 変わったこと： 確認済みの型付き JSON メモリーを Managed Agents ストアに保持できます。アプリは原典と保存された正確なバイト列を確認し、非公開スナップショットを一つ固定して、メモリーストアを接続せずに、その同じ承認済みバイト列を二つの別々の許可済みセッションへ送ります。
• 重要な理由： 後でストアが編集されても、既にセッション用に構成した入力は変わりません。
• 注意点： 原典の正確さ、ユーザーの権限、回答の品質は引き続き別々に確認する必要があります。

始める前に

実際の事実、好み、プロジェクト規則を一つ用意します。利用許可のある原典、安定した原典 ID と改訂、保存と両エージェント役割への開示を承認する所有者が必要です。確認前に、その記録に適したレビューの有効期限を決めます。Managed Agents ベータへのアクセス、非公開 API キー、許可されたワークスペース、設定済みの二つのエージェント ID、環境、アカウントで使えるモデルを確認します。この手順の四つの限定された利用側セッションを許可する前に、現在の使用量と料金を調べてください。キーはメッセージや実施記録に含めません。

アプリには認証済み主体とスコープの対応付けが必要です。信頼するアプリ状態で、その主体を承認済みの ownerScopeId、ワークスペース ID、ストア ID、許可された二つのエージェント ID に結び付けます。アクセス規則が異なる非公開ユーザーやプロジェクトは、ストアを分けます。ワークスペースの API キーはエンドユーザーを認証せず、パスはテナント境界ではなく、プロンプトでツールや認証情報を取り除くこともできません。両方の利用側設定に、ストア接続も、変更可能なストアへ通じるコネクター、環境の認証情報、ツール経路もないことを確認します。この境界を確立できなければ、記録を送る前に止めてください。

1. 原典と照合して記録を承認する

この構造テンプレートを使い、山括弧内の値をすべて実際の承認済み証拠に置き換えます。これは事実の例や実施結果の主張ではありません。承認前に、完成したオブジェクトを一つの正確な UTF-8 JSON テキストに直列化します。バリデーターはこのフィールドと型だけを受け入れ、不明なフィールドを拒否し、空白だけでない文字列と有効な UTC タイムスタンプを要求し、kindを fact、preference、または project_rule に制限し、statusを active、disputed、または superseded に制限します。注入できるのは active 状態の記録だけです。承認する主張は、発効日と適用範囲を含め、引用した原典と一致しなければなりません。

{
  "schemaVersion": "memory-record/v1",
  "recordId": "<opaque stable record ID>",
  "ownerScopeId": "<trusted mapped scope ID>",
  "kind": "<fact | preference | project_rule>",
  "claim": "<precise source-supported claim>",
  "sourceId": "<private original-source ID>",
  "sourceRevision": "<original revision or exact source hash>",
  "sourceQuoteOrPointer": "<minimal permitted quote or stable pointer>",
  "validFrom": "<UTC timestamp>",
  "checkedAt": "<UTC timestamp>",
  "status": "active",
  "reviewerId": "<approved human reviewer ID>",
  "reviewedAt": "<UTC timestamp>"
}

アプリの非公開承認記録には、実際の承認者、所有者の許可、原典と改訂、スコープと許可エージェント、鮮度規則、そしてこの正確な UTF-8 JSON バイト列の SHA-256 を示します。実際の主張に対する人の判断を記録するものです。記録内の reviewerId 文字列は認証ではありません。矛盾や許可不足が未解決の記録は保存しないでください。Anthropic はテキストを保存しますが、このスキーマを検証したり、主張が真実だと証明したりはしません。

2. 保存して読み戻す

許可されたワークスペースで限定的なメモリーストアを作成または選択し、実際の memstore_... ID を記録します。例えば /records/{opaque-record-id}.json のような機密性のないパスを使います。リクエスト前に、実行者、UTC 時刻、原典の改訂、承認バイト列のハッシュ、ストアとパス、pending 状態を記録します。メモリーストアを直接呼び出すときは agent-memory-2026-07-22、セッション呼び出しでは managed-agents-2026-04-01 を使います。Anthropic によると、ストアリクエストに両方のベータヘッダーを併用すると HTTP 400 が返ります。作成リファレンスとメモリーマニュアルには次の SDK 形式があります。インストール済み SDK を現在のリファレンスと照合してください。

mem = client.beta.memory_stores.memories.create(
    store.id,
    path="/records/<opaque-record-id>.json",
    content=approved_json_text,
)

作成では既存パスを上書きしません。返された mem_... ID を保存し、限定したストア内の /records/ を一覧取得し、各 next_page を次の page としてページを進めます。標準の基本一覧には内容が含まれません。選択したメモリーを取得し、ID を指定して全文を読みます。ストア ID、メモリー ID、パス、内容、content_sha256 を承認済みバイト列と照合します。応答と直接の読み戻しをログと登録簿に残します。作成応答だけでは完了確認になりません。応答が不明なら、正確なパスと直接の記録を調べてから結果を判断します。検索で見つからないだけでは作成を繰り返せません。

3. 選択した改訂を固定する

以後の各実行では、呼び出し元を認証し、信頼できる登録簿からスコープ、ストア、選択記録 ID を解決します。探索が必要なら限定プレフィックスの全ページを一覧取得してから、選択した mem_... を直接取得します。返された内容を UTF-8 で符号化して SHA-256 を計算し、提供元の content_sha256 と人が承認した正確なバイトハッシュを照合して、JSON を再検証します。記録 ID、所有者スコープ、原典の改訂、active 状態、原典の現行性、事前に決めた鮮度期限を確認します。一つでも失敗したら何も送りません。

取得した正確なバイト列を、そのハッシュで参照する非公開ストレージへ一度だけ書き込みます。Python の open(path, "xb") のような排他的作成を使います。書き込み直後と、毎回の送信前にファイルを読み直してハッシュを確認します。既存スナップショットは上書きしません。不完全なファイルや同じアドレスの異なるバイト列は、保留して整合性を確認する必要があります。元の承認、ストア ID、メモリー ID、提供元ハッシュ、スナップショットハッシュ、スコープ判断を非公開の取得記録に残します。この一度だけ書くスナップショットはアプリ設計であり、Anthropic が提供する版固定マウントではありません。

4. 同じバイト列を二つの新しいセッションへ渡す

実際に許可されたエージェントと環境の ID でエージェント A の新規セッションを作り、次のフィールドにはメモリーストア項目を入れません：resources。返されたセッションのリソースと、エージェントの実際のツール・認証情報に、ストアへ至る別経路がないことを確認します。Anthropic のセッションガイドは、作成と user.message の送信を別々に説明しています。

session = client.beta.sessions.create(
    agent=approved_agent_id,
    environment_id=approved_environment_id,
)
client.beta.sessions.events.send(
    session.id,
    events=[{"type": "user.message", "content": [{"type": "text", "text": message_text}]}],
)

次の呼び出し events.send の前に、非公開スナップショットを読み直してハッシュを確認します。message_text は、明示的な「確認済みデータ」ラベル、記録・原典・レビューの識別情報、変更しない JSON テキストと SHA-256、その原典で答えられる限定的な質問から、決定的に構成します。表示したフィールドはアプリのメッセージ形式であり、提供元の応答フィールドではありません。送信前に、メッセージ全体の UTF-8 バイト列とハッシュ、選択スナップショットのハッシュ、許可エージェント ID、セッション ID、送信状態を記録します。送信結果と実際の送信イベント ID、または取得可能ならイベント一覧の読み戻しを残します。結果不明時はイベントを読み戻し、むやみに再送しません。

別途承認されたエージェント ID で B の新規セッションを作り、同じくストアへアクセスできない設定にします。同じ一度だけ書くスナップショットを読み直し、バイトハッシュを確認し、B のメッセージ全体を構成・記録して送ります。質問や受信者メタデータは異なっても構いませんが、埋め込む JSON バイト列と承認済み記録ハッシュの一致を確認します。各回答とツールイベントを原典と照合します。もっともらしい回答や引用だけでは、モデル内部が注入テキストに依拠した証拠にはなりません。メッセージと提供元イベントの記録が証明するのは、アプリが何を渡したかです。どちらかにライブマウントや別のストア経路があれば、そのセッションには送りません。

5. 原典を再確認してから更新する

原典が変わったら現在のメモリーを直接取得し、所有者と新旧証拠を比較します。安定した記録 ID、訂正した主張または原典ポインター、新しい原典改訂と確認・レビュー時刻を含む正確な置換 JSON バイト列を、人が承認します。古い承認記録とハッシュは保持します。mem_... ID、現在直接読んだ content_sha256、予定する置換ハッシュ、実行者、承認、保留状態を記録します。文書にある条件付き更新は次のとおりです。

client.beta.memory_stores.memories.update(
    memory_id=memory_id,
    memory_store_id=store_id,
    content=approved_replacement_json_text,
    precondition={"type": "content_sha256", "content_sha256": fresh_old_hash},
)

提供元は正規化せず、正確な UTF-8 内容をハッシュ化します。不一致では HTTP 409 memory_precondition_failed_error が返ります。その応答や不明なネットワーク結果を受けたら、現在のメモリーを再取得し、必要に応じ版履歴を調べます。競合する原典改訂を比較し、所有者に統合、却下、または新たな正確な置換の承認を依頼します。古い書き込みを盲目的に再試行しません。成功時は、直接取得によってパス、置換全文、ハッシュ、メモリーバージョン ID を確認してから、ログを confirmed にします。

確認した改訂から、新しい承認済みスナップショットを固定します。ストアをマウントしない新規の許可済み A・B セッションを作り、二回の送信と原典確認を繰り返します。古いスナップショットを変えたり、送信済みメッセージが自動更新されると説明したりしないでください。前のスナップショットは以後の注入対象から外します。所有者が記録を撤回したら新規送信を止め、保持・削除方針に従います。現在のメモリーを削除しても保持版まで消えるとは限りません。ストア全体のアーカイブや削除は別途の判断です。

完了とみなす条件

非公開記録は、元の許可と原典改訂を正確な承認済み JSON ハッシュに結び付け、実際のワークスペース・ストア・パス・mem_... の識別と作成後の直接読み戻し、一つの不変スナップショット、異なる二つの許可済み・未マウントのセッション ID、送信メッセージハッシュと原典確認済み回答、承認済み条件付き更新と更新後の直接読み戻し・新規セッション確認までつなぐ必要があります。どれかが不明なら全体を未完了とし、正確な保留理由を残します。実行した場合は実際のセッション・ツール使用量とアカウント固有の費用を記録してください。この文書ベースのガイドは節約やモデル性能を測定していません。

関連しますが異なる作業として、後のセッションに向けて Dream 出力一件を確認するガイドは、生成されたストア提案を扱います。ここでの手順は所有者が承認した原典記録から始め、二つの利用側へ渡す内容を正確に固定します。