1つのエージェントにチーム全体を担当させる — ユーザー間で属性付きメモリを保持し、プライバシーガードレールと完全な開示監査を備え、エージェントが話したすべてのユーザーで複利的に蓄積されるデフォルトオンの非属性ウィズダム層も付属。

デフォルトのエージェントメモリモデルはユーザーごと — すべての会話は1つの (agent, user) ペアにスコープされた事実プロファイルを構築します。これはコンパニオン製品や1対1のアシスタントには正しいモデルです。しかしチームは逆を必要とします：1つのエージェントがグループ全体を担当する場合、ユーザー間で何が起こっているかを知る必要があります。

共有メモリは、単一のエージェントをチームのブレインに変える機能です — ユーザーBと話して得たコンテキストでユーザーAに応答し、属性付き、サーバー強制のプライバシーフロア、完全な開示監査を備えます。デフォルトオンの wisdom 層（非属性のクロスユーザー一般化）と組み合わせることで、クロスユーザー知識の2つの補完的な層が得られます。

位置づけ

共有メモリは標準のユーザーごとメモリの上に重ねられます。ユーザーごとの事実は引き続き存在します；共有メモリはユーザー境界を越えるべき事実のためのエージェント全体パーティションを追加します。両者は共存します — 共有メモリをオンにしてもユーザーごとメモリは何も変わりません。

2つの層、1つの機能サーフェス

	動作	デフォルト	使用するタイミング
`wisdom`	非属性のクロスユーザー一般化。日次の昇格ジョブがユーザーごとの事実履歴からパターンを抽出し、k-匿名化し、エージェント全体の知識として書き直します。個別のユーザーは識別不可能。	新しいエージェントすべてでオン	複数のユーザーと話すすべてのエージェント — 無料の一般化層です。厳密な単一ユーザー製品の場合のみ無効化を検討。
`sharedMemory`	属性付きのクロスユーザーコンテキスト。エージェントが記録した個人／エンティティ属性付きの事実（役割、専門性、ビジネスコンテキスト、関係）を、エージェントを共有する他のユーザーに公開。名前と身元は表示される。	オフ。オプトイン。	グループ、チーム、パーティ、または共有ビジネスコンテキスト製品で、ユーザーが誰が何をしているかを見ることを明示的に期待する場合。

両方を同じエージェントで同時に実行できます。wisdom は安全な層（常にk-匿名化の背後）；sharedMemory は強力な層（属性が保持される）で、慎重なオプトインが必要です。

共有メモリをオンにするタイミング

有効にするケース：

チームコーディネーター。 「アリスは移行担当、ボブはインシデント対応」 — エージェントに参加するすべてのチームメイトが現在のオーナーシップ状況を見られる。
グループ／パーティの計画。 「キャロルはデザート、デイブはセットアップ」 — 計画の途中で参加した人が状態を再質問せずに把握。
共有ビジネスワークスペース。 アカウントレベルのエージェント — アカウント上のすべてのユーザーが他者から得たコンテキストの恩恵を受ける。
マルチステークホルダーサポート。 カスタマーサクセスエージェント — 1人のステークホルダーから得た更新コンテキストが次のステークホルダーとの会話に活かされる。

オフのままにすべきケース：

単一ユーザーのコンパニオン製品（プライベートな1対1関係）
ユーザーがエージェントが自分について他のユーザーに話すことに驚くようなユースケース
クロスユーザーの開示が法的に許可されないコンプライアンスセンシティブなコンテキスト

共有メモリを有効化する

wisdom は前提条件です（デフォルトオンなので通常は明示的に設定する必要なし）。sharedMemory: true を反転してエージェントをオプトイン。

// ウィズダムは新しいエージェントではデフォルトオン — デフォルトを
// オーバーライドする場合のみ明示的に設定する。
await client.agents.updateCapabilities("agent_abc", {
wisdom:       true,
sharedMemory: true,
});

エージェント作成時に設定することもできます：

const agent = await client.agents.create({
name:       "Team Coordinator",
project_id: "proj_abc",
tool_capabilities: {
  wisdom:        true,
  shared_memory: true,
},
});

共有メモリを無効化する

sharedMemory: false を渡します。既存の属性付き事実はストレージに残り（後で再有効化できます）、エージェントはそれらをコンテキストに表示しなくなり、書き込みツールも取得しなくなります。

await client.agents.updateCapabilities("agent_abc", { sharedMemory: false });

wisdom を無効化する（稀 — 通常は厳密な単一ユーザー製品のみ）：

await client.agents.updateCapabilities("agent_abc", { wisdom: false });

オンにすると何が変わるか

sharedMemory: true が反映された瞬間に、3つのことが同時に切り替わります：

1. ツール — エージェントが属性付きウィズダムCRUDを取得

LLMが4つの新しいツールを取得します：

ツール	エージェントができること
`sonzai_wisdom_set`	属性付き事実を作成またはアップサート（entity_type、entity_id、category、value、confidence）
`sonzai_wisdom_update`	既存の事実の値を置換
`sonzai_wisdom_delete`	属性付き事実をソフト削除（トゥームストーン、可逆）
`sonzai_wisdom_relate`	エンティティ間の属性付き関係を作成（「アリスはボブを管理する」）

これらは遅延ツールです — LLMがインラインで呼び出し、プラットフォームがターン後に非同期で書き込みを処理するため、レイテンシはクリーンに保たれます。

2. コンテキスト — エージェントのプロンプトに「Shared facts」セクションが追加される

これ以降エージェントが実行するすべてのシステムプロンプトには、ファイル上の属性付き事実をリストする Shared facts about people and entities セクションと、LLMに開示の扱い方を指示する慎重さの条項（「慎重さを発揮する；透明性よりプライバシーを優先」）が含まれます。エージェントはすべてのユーザーにすべてをダンプするわけではありません — ターンごとに開示の判断を行います。

3. プライバシーフロア — すべての書き込みがサーバー側で検証される

属性付き事実が永続化される前に、プラットフォームは報酬・健康・政治などのプライバシーセンシティブなカテゴリの書き込みを拒否するセマンティックバリデーターを実行します。これはサーバー側で強制され、プロンプトではありません — ユーザーが明示的にエージェントに給与を記録するように頼んでも、書き込みはブロックされます。拒否された書き込みは開示監査に decision = "redacted" で表示されるため、何が試みられたかと理由を確認できます。

動作確認

ステージングまたは本番に対してエンドツーエンドで実行できる3つのチェック。$AGENT_ID、$API_KEY、プラットフォームURLを置き換えてください。

1. エージェント上の属性付き事実をリスト

curl 'https://api.sonz.ai/api/v1/agents/$AGENT_ID/wisdom/attributed?limit=20' \
  -H "Authorization: Bearer $API_KEY"

期待値：事実の配列（entity_type、entity_id、category、value、confidence）を含む 200。まだ何も書き込まれていない場合は空配列 — それでも健全な応答です。

2. APIから直接属性付き事実を書き込む

curl -X POST 'https://api.sonz.ai/api/v1/agents/$AGENT_ID/wisdom/attributed' \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "entity_type": "person",
    "entity_id": "alice",
    "entity_display_name": "Alice",
    "category": "role",
    "value": "Lead Engineer",
    "confidence": 0.92
  }'

次に上記のリストエンドポイントを再度実行します。アリスの役割が表示されるはずです。これでこのエージェントと話すユーザーは、エージェントのコンテキストでこの事実を見ることになります（慎重さの判断に従う）。

3. 開示監査を読む

curl 'https://api.sonz.ai/api/v1/agents/$AGENT_ID/wisdom/audit?limit=50' \
  -H "Authorization: Bearer $API_KEY"

ターンのコンテキストに事実がロードされるたびに、decision = "disclosed" と decision_why を持つ監査行が書き込まれます。プライバシーフロアが何かをブロックした場合、その行は decision = "redacted" を表示します。これがあなたのライブな観測可能性です — 共有メモリをオンにして本番トラフィックが流れている場合、ここにエントリが表示され、いつでも開示判断を遡って監査できます。

プライバシーと制御

共有メモリは設計上センシティブです。LLM呼び出しと永続化された開示の間に4つの制御層があります：

機能ゲート。 sharedMemory: false（デフォルト）は何も起こらないことを意味します — ツール登録なし、コンテキスト注入なし、監査行なし。
プライバシーフロア。 セマンティックバリデーターがストレージに到達する前に報酬・健康・政治などの設定済みセンシティブカテゴリの書き込みを拒否します。テナント単位で設定可能。
プロンプト内の慎重さの条項。 事実が存在していても、エージェントはすべてをダンプするのではなくターンごとに開示を判断するよう指示されます。
開示監査。 すべての開示判断が理由とともにログに記録されます。エージェントが共有したもの、保留したもの、その理由を監査エンドポイントを介していつでも確認できます。

ハード削除は管理者のみです。エージェントはソフト削除（トゥームストーン）のみ行うため、誤って属性付けされた事実は管理者が永久にクリアするまで可逆です。

他の機能との組み合わせ

ナレッジベースの自律編集と組み合わせる

knowledgeBaseWrite と sharedMemory は独立した機能です — 任意の組み合わせで反転できます：

KB書き込みのみ： エージェントはプロジェクトナレッジグラフに世界に関する事実（製品、ポリシー、価格、インシデント）を記録
共有メモリのみ： エージェントはこのチームの人々に関する事実（役割、専門性、オーナーシップ、関係）を記録
両方： 完全な閉じたループの組織記憶 + チームのブレイン

ナレッジベース — より広範なマルチプレイヤーメモリのストーリー
自己改善 — 共有メモリがペアごとのオンライン学習の上にどのように重なるか
組織ナレッジベース — プロジェクトの上に位置するテナント全体のナレッジ
Wisdom API — 完全なエンドポイントリファレンス

共有メモリ（Shared Memory）