クイック比較
| モード | 暗号文の保存場所 | 復号できる主体 | 適した用途 |
|---|---|---|---|
Cloud 管理モード cloud | XMemo 管理データプレーンに保存され、アクセス制御、アプリケーション層のスコープ認可、監査で保護されます。データベース RLS の有効性はデプロイごとの検証が必要です。 | XMemo サーバーは、リコール、検索、ランキング、サポート可能なエクスポートのためにメモリ内容を処理できます。 | 最短のセットアップ、完全なホスト型リコール、デバイスやリカバリーキー管理を避けたい場合。 |
Keyguard モード keyguard | XMemo 管理 Postgres に保存されますが、エンベロープキーはテナントの KMS / HSM に結び付きます。 | KMS grant が unwrap 操作を許可している場合に限り、サーバーが復号できます。 | ホスト型リコールと顧客管理キーの両方が必要なエンタープライズチーム。 |
Vault モード vault | XMemo 管理 Postgres には不透明な暗号文と envelope metadata だけが保存されます。 | 登録済みデバイスまたはリカバリーキットだけが復号できます。XMemo は平文を復元できません。 | ゼロ知識の保管。全デバイスとリカバリー素材を失うと恒久的に失われます。 |
XMemo が保存するもの
- メモリー記録：メモリー本文または暗号文、メタデータ、所有者、タイムスタンプ、リコールに必要なベクトル検索データ。
- アカウント設定状態：選択したセキュリティモード、セットアップ完了状態、モード変更回数、KMS binding id や vault recovery marker などの preflight 証跡。
- アクセスと監査記録：セッション、ハッシュ化または scoped credential、ID リンク、setup_state_transition などの監査イベント。
XMemo の公開ページが API key の貼り付けを求めることはありません。Agent と MCP の設定は環境変数または公式クライアントの設定画面を参照してください。
Cloud 管理モード
メモリーデータは XMemo 管理データプレーンに保存されます。サーバーはリコール、検索、ランキング、エクスポートのためにメモリ内容を処理できます。
- XMemo サーバーはサーバー側セマンティックリコール、ランキング、エクスポートのためにメモリ内容を処理できます。
- 最も便利なモードですが、ゼロ知識モードではありません。
- 削除時はメモリー行と関連メタデータを削除します。DSAR エクスポートには平文を含められます。
Keyguard モード
Keyguard は XMemo のホスト型リコール体験を維持しつつ、エンベロープ操作を Azure Key Vault、AWS KMS、GCP KMS、KMIP など組織管理の provider に結び付けます。
- ウィザードは KMS binding を保存し、personal_default_mode = keyguard をコミットします。
- リコールには KMS grant が有効であることが必要です。grant を取り消すと以後の decrypt/unwrap はブロックされます。
- XMemo は自身の暗号文とメタデータを削除します。KMS key のローテーションや破棄はテナント側の責任です。
Vault モード
Vault はゼロ知識オプションです。ブラウザーまたはデバイスがデータ送信前に暗号化し、サーバーは暗号文、ルーティング情報、envelope metadata だけを保存します。
- XMemo は vault memory を復号できず、vault key をリセットできず、全デバイスとリカバリーキット喪失後の復元もできません。
- Vault データの DSAR エクスポートは暗号文と envelope metadata です。ローカルでデバイスまたはリカバリーキットを使って復号します。
- 機能がクライアント提供またはプライバシー保護表現で動作できない限り、ホスト型セマンティック機能は制限される場合があります。
本番データ境界
XMemo 本番アーキテクチャは operator-managed Postgres、TLS 検証、アプリケーション層のスコープ認可を境界として設計されています。データベース RLS/runtime context の有効性はデプロイごとの検証が必要です。Supabase は開発および互換バックエンドのみであり、これらの保管境界の本番基盤ではありません。
- Managed Postgres：アカウント、メモリー、ベクトル、設定、監査記録の本番ストレージ境界。
- データベース RLS/runtime context：デプロイ固有の制御です。対象環境で runtime role、migration ledger、runtime-context flag、owner/team CRUD matrix を検証する必要があります。
- Supabase compatibility：ローカルや OSS 利用には有用ですが、service-role の挙動は本番の強化境界と同等ではありません。
現在のモードを確認する方法
- Memory Console -> Settings -> Security mode を開き、表示されているモードを確認します。
- GET /api/v1/me/setup/state を呼び出します。完了済みアカウントでは setup_state = setup_completed と期待する selected_mode が返ります。
- GET /api/v1/me/security-mode を呼び出します。posture には verified_effective_mode、new_write_mode、pending_write_mode、legacy_read_mode、migration_status が含まれます。
- Keyguard では表示された key binding id を KMS 監査ログと照合します。Vault では送信書き込みに不透明な暗号文だけがあり、識別可能な平文がないことを確認します。