# ガバナンスと保持

保持、削除、エクスポート、データ境界、監査証拠について、現在のガバナンス方針を確認します。

- Canonical: https://docs.xmemo.dev/ja/docs/concepts/governance-retention
- Locale: ja-JP
- Content-Locale: ja-JP
- Canonical-Content-Digest: 64872f32f2fa2549e9b806845665721e6289a5b6fe5d9e8dc96165599625c17b
- Edition-Digest: 3d4675f3fc43358e7abe913f721e566cb57ca1a80b518c25b56862f6c8189f48
- Source-Revision: sha256:47f2eb881bc452bf2c7284e56f7b3ce65901de5335e31c6b20f6047355dc4f40

## 現在、保持はサービスによって管理されます

現在のMeGovernanceResponseはretention.status=operator_managed、retention.available=falseを報告します。アカウントごとの自動保持ルールは設定できません。archive、forget、clearの操作には明示的なアカウント操作が必要です。このページは実装済みの方針を説明するもので、自動保持スケジュールを約束するものではありません。

```json
{
  "retention": {
    "status": "operator_managed",
    "available": false
  },
  "delete": {
    "status": "self_service",
    "available": true
  }
}
```

## 削除とエクスポートには別々の方針があります

個別メモリの削除はself-serviceで行えます。アカウントを閉鎖するとアクセスを取り消し、Personal purge workflowをキューに入れます。response contractでは、teamで共有されたデータはTeamに残ると定めています。エクスポートは、runtime configurationに応じてself-service downloadまたはrequest-onlyとなり、準備済みartifactは自動的に期限切れになります。

- delete — 個別メモリのself-service削除が利用できます。
- export — runtimeが有効にした場合だけstatusはself_service_downloadとなり、それ以外はrequest_onlyです。
- data_boundary — アカウント単位です。アカウントをまたぐアクセスは許可されません。

## ガバナンス操作は監査証拠を残す

ガバナンスresponseはaudit.status=enabledを報告し、アカウント操作がaudit eventを発生させると説明します。audit-logへのアクセスとself-service audit exportは、引き続きサービスチームが管理します。メモリ削除も、忘れられたcontentを公開結果に残さず、mode、reasonの有無、target referenceをmemory audit outboxに記録します。

```json
{
  "data_boundary": {
    "status": "account_scoped",
    "available": true
  },
  "audit": {
    "status": "enabled",
    "available": true
  }
}
```

## modeを選ぶ前に有効な方針を確認する

Security modeとガバナンス方針は別の制御です。Cloud modeではserver-side processingが可能です。Keyguardは監査付きの一時復号とcustomer key wrappingを使います。Vaultはメモリ本体をclient-encryptedで保ち、通常はlocal recallを必要とします。保持、削除、security handlingは、3つすべてを1つの設定が制御すると仮定せず、現在のresponse contractに基づいて選択してください。

```text
retention  = operator_managed
delete     = self_service
audit      = enabled
security   = resolve the effective Cloud, Keyguard, or Vault mode
```

## ChatGPT ユーザー

bearer token をチャットに貼り付けずに、ChatGPT が XMemo の設定、プロジェクト事実、意思決定、TODO に永続的にアクセスできるようにします。

ChatGPT/OpenAI app の OAuth フローで hosted XMemo MCP server に接続し、XMemo アカウントに memory:read と memory:write の許可を承認します。

合成の設定またはプロジェクトメモを保存し、新しいチャットを開始してから、作業を続ける前に ChatGPT に XMemo 経由でそれを呼び出させます。

OAuth が失敗する、またはツールが表示されない場合は、direct token を作成する前に、ホストアプリで MCP server からサインアウトし、XMemo server URL を再接続して再試行します。

## Copilot / Codex 開発者

リポジトリの判断、コーディング規約、バグ修正メモ、タスク履歴を IDE と CLI エージェント間で持ち運べます。

利用可能な場合は、VS Code / GitHub Copilot および Gemini CLI に OAuth を使用してください。Copilot CLI、Codex、Cursor、またはその他の直接 MCP クライアントの場合は、XMEMO_KEY をローカル環境またはシークレットストアに保持し、安定した XMEMO_AGENT_INSTANCE_ID を設定してください。

コードベースの判断またはバグ修正を記録し、次の IDE または CLI エージェントに、編集前に関連する XMemo コンテキストを呼び出させます。

呼び出し結果が空の場合は、選択した MCP 設定パス、direct client 用の XMEMO_KEY 環境変数、ホストアプリ内の古い OAuth 認証情報を確認します。

## チーム / エンタープライズ pilot owner

アカウント制御、ソース attribution、エクスポート/削除ワークフロー、レビュー担当者向けに安全な設定証跡で共有メモリを評価します。

保護された XMemo workspace を作成または開き、承認済みユーザーを招待してから、readiness badges に従って OAuth またはスコープ付き direct credential で各クライアントを接続します。

pilot メンバーに合成のチームメモリを保存してもらい、XMemo でソース attribution を確認し、削除/エクスポートとサポート経路をレビューします。

メンバーが接続できない場合は、新しい token を発行する前に、ロール権限、OAuth 承認、クライアント readiness 状態、サポートガイダンスを確認します。

## 自律エージェント operator

headless またはスケジュール済みエージェントが進捗を記録し、過去の判断を取得し、安定した非秘密のインスタンス ID を保持できるようにします。

/api/v1/mcp/config/autonomous-agent を取得します。runner が OAuth + custom headers をサポートする場合は auth_modes.oauth を優先し、完全 headless runner の場合のみ secret store の XMEMO_KEY で auth_modes.xmemo_key を使います。

XMemo に進捗を書き込む合成タスクを 1 つ実行し、runner を再起動して、同じ XMEMO_AGENT_INSTANCE_ID でその進捗を呼び出せることを確認します。

attribution が変わる、または呼び出し結果がインスタンス間で分かれる場合は、XMEMO_AGENT_INSTANCE_ID を git の外に永続化し、runner が起動ごとに再生成していないことを確認します。