概念機能Teams

Concept

Teams

協調エージェントチーム向けのテナント分離共有メモリ空間。空間管理者が管理プレーンでワークスペース境界を管理し、メモリアクセスはデータプレーンシートによってパーティション化されます。

チームメモリアーキテクチャと Preview 提供状況

Teams は Business プランの機能です。本番環境では、Business プランがローンチされるまでチーム作成はデフォルトで無効化されています。現在のランタイムは未認可のリクエストに対して拒否専用(deny-only)モードで動作します。空間管理者はワークスペース管理プレーンでワークスペースの境界とテナントプロビジョニングを管理し、エージェントのメモリアクセスはテナント分離された暗号空間バインディングを備えたデータプレーンシートによって制御されます。

  • Preview 提供状況: https://xmemo.dev/me#teams の Memory Console では、Team Management に Preview バッジが表示されています。
  • コンソールワークスペースのコンテキスト: Team Management のヘッダーには "One workspace for members and invitations." と表示され、管理者がアクティブなメンバーと保留中の招待を管理します。
  • 空間ナビゲーション: コラボレーターは明示的な空間パラメーター(https://xmemo.dev/me?space=<team_id>#memory)を使用してチーム空間に切り替えるか、共有ナレッジ(https://xmemo.dev/me?space=<team_id>#knowledge)やスキル(https://xmemo.dev/me?space=<team_id>#skills)を検査します。
  • 協調的な分離: チームワークスペースは、個別ユーザーのパーソナルメモリ空間(/me#memory)から分離されたマルチエージェント共有コンテキストを提供します。

チーム資格、作成要件、およびサブスクリプションの境界

チームの作成には、2 シート以上を購入した利用資格のある Business サブスクリプションが必要です。Business プランは現在購入を受け付けていないため、一般アカウントでのセルフサービスチーム作成はデフォルトで無効になっています。公開ドキュメントでシートの購入を利用可能なアクションとして提示することは一切ありません。

  • 作成の姿勢: Business プランがローンチされるまで、本番環境でのセルフサービスチーム作成はデフォルトで無効です。
  • 資格要件: コンソールはチーム作成を開く前に組織の利用資格を確認します。対象外の場合、インターフェースには「"A Business subscription with at least 2 purchased seats is required to create a team."」と表示されます。
  • Preview 制限の理由: アカウントが許可リストに登録されていない場合、コンソールには「"Team creation is currently limited to preview accounts."」と表示されます。
  • 一般的な未提供の理由: プロビジョニングされていないアカウントの場合、コンソールには「"Team creation is not available for this account yet."」と表示されます。
  • 商用ステータス: Business サブスクリプションは現在購入できません。セルフサービスでのシート追加やプランのアップグレードは無効化されています。
  • 作成モーダル: 許可リストに登録されたプレビューアカウントでチーム作成をクリックすると、「"Enter your company name. This will become the team name inside XMemo."」というモーダルが開き、入力フィールド「"Company name"」(プレースホルダー「"e.g. Acme Corp"」)が表示されます。

4段階のRBAC階層とクレデンシャル発行上限

チームメンバーシップの権限とクレデンシャル発行上限は、パーソナルコンソールサービスによって適用されます。owner、admin、または member ロールを持つアクティブメンバーは、ロール固有のスコープ上限内でチームに紐づくクレデンシャルを発行できますが、viewer は厳格に読み取り専用でありトークンの発行は拒否されます。以下のロールスキーマは例示的な概要です(API レスポンスではありません):

  • ロール階層: ワークスペースロールを権限レベルおよびトークン発行上限にマッピングする例示的な概要(API レスポンスではありません)。
  • owner(レベル 3): 請求アカウントに固定されたワークスペース作成者。Admin、Member、Viewer ロールを持つメンバーを招待でき、非所有者メンバーのロールを更新でき(Admin、Member、Viewer 間)、非所有者メンバーを削除して招待を取り消すことができます。データプレーンメモリ、台帳、ナレッジ、監査スコープ(memory:read、memory:write、memory:restore、read:memories、write:memories、delete:memories、ledger:read、ledger:write、knowledge:read、knowledge:write、および read:audit)を含む、任意のセルフサービススコープでチーム紐づきクレデンシャルを発行できます。
  • admin(レベル 2): ワークスペース管理者。Member または Viewer ロールを持つメンバーを招待でき(Admin は招待不可)、非所有者メンバーの削除や保留中の招待の取り消しができますが、メンバーロールを変更することはできません。データプレーンメモリ、台帳、ナレッジ、監査スコープ(memory:read、memory:write、memory:restore、read:memories、write:memories、delete:memories、ledger:read、ledger:write、knowledge:read、knowledge:write、および read:audit)を含む、任意のセルフサービススコープでチーム紐づきクレデンシャルを発行できます。
  • member(レベル 1): 標準的なワークスペースコラボレーター。共有チームメモリシート、チームナレッジ項目、チーム Cloud Skill への読み取り、書き込み、復元アクセス権を持ちます。チームメンバースコープに制限された個人用のチーム紐づきクレデンシャルを発行できます(memory:read、memory:write、memory:restore、read:memories、および write:memories)。上位の台帳やナレッジスコープを発行することはできず、ワークスペースメンバーや設定を管理することはできません。
  • viewer(レベル 0): コンソールでの読み取り専用メモリアクセス(memory:read)および共有ナレッジの閲覧。クレデンシャルの発行は一切許可されず、メモリへの書き込み、状態の更新、またはチームクレデンシャルの発行は禁止されています。
  • 単独所有者の制約: 単独所有者がチームを脱退しようとすると、「"Cannot leave team as the sole owner. Transfer ownership or delete the team first."」(ツールチップ:「"Sole owner must transfer ownership before leaving"」)という通知が表示されます。
{
  "roles": {
    "owner": {
      "level": 3,
      "token_issuance_cap": [
        "memory:read",
        "memory:write",
        "memory:restore",
        "read:memories",
        "write:memories",
        "delete:memories",
        "ledger:read",
        "ledger:write",
        "knowledge:read",
        "knowledge:write",
        "read:audit"
      ]
    },
    "admin": {
      "level": 2,
      "token_issuance_cap": [
        "memory:read",
        "memory:write",
        "memory:restore",
        "read:memories",
        "write:memories",
        "delete:memories",
        "ledger:read",
        "ledger:write",
        "knowledge:read",
        "knowledge:write",
        "read:audit"
      ]
    },
    "member": {
      "level": 1,
      "token_issuance_cap": [
        "memory:read",
        "memory:write",
        "memory:restore",
        "read:memories",
        "write:memories"
      ]
    },
    "viewer": {
      "level": 0,
      "token_issuance_cap": []
    }
  }
}

サーバー権威による空間バインディングと動的失効

マルチテナントの分離は、暗号化空間バインディングを通じてサーバー側で強制されます。すべてのチームスコープ付き API キーには、クライアントリクエストで変更または指定できない不変のクレーム(bound_team_id、membership_id_at_issue、space_binding_version)が含まれています。一致しないチームを対象とするリクエストは、HTTP 403 token_space_mismatch で直ちに fail closed となります。

  • 権威ある空間検証: 一致しないチームを対象とするリクエストは、HTTP 403 token_space_mismatch で直ちにフェイルクローズします。
  • スプーフィング防止保証: 偽造または競合するチームヘッダーを持つリクエストは、データベースプールにアクセスする前にエッジで拒否されます。
  • エポックベースの動的失効: メンバーシップ検証では、認証されたすべてのリクエストで有効な membership_id エポックをチェックするため、削除されたメンバーはトークンの有効期限を待たずにエポック更新時に即座にアクセス権を失います。

シート管理、招待ライフサイクル、およびライフサイクルの境界

ワークスペースのキャパシティは、アクティブなメンバーシップと保留中の招待にわたって定性的に追跡されます。運用境界によって、招待の発行、有効期限、およびコンソール機能が管理されます:

  • 定性的なシートカウント: 使用中のシートはアクティブなメンバーと有効期限内の保留中の招待で構成され、コンソールヘッダーに「"Seats {used} / {limit} used, {members} members, {pending} pending"」と表示されます。
  • 技術的な招待の有効期限: チームの招待は発行から 7 日後に期限切れになります(teams_service.py:1184-1188)。期限切れの招待は予約を解放し、使用中シートとしてカウントされなくなります。
  • シート容量制限: 利用可能なすべてのシートが使用中の場合、メンバー追加モーダルに「"Team seat limit reached. Upgrade or remove a member or pending invitation to send more invitations."」と警告が表示されます。
  • 招待ワークフローステータス: 招待を送信すると、安全な 7 日間有効なトークンリンクが生成されます。ただし、現在コンソールインターフェースには招待の受諾を処理する画面がありません。完全な招待受諾ワークフローはコンソールではまだ利用できません。
  • チーム削除や所有権移転の不在: コンソールには、チームワークスペースの削除やチーム所有権の移転のためのルートや UI コントロールは用意されていません。これらのアクションはセルフサービスでは利用できません。

共有リソース、エージェントアクセス、およびデータエクスポートの境界

Teams 機能によって Model Context Protocol (MCP) のインターフェースに変更が加わることは一切ありません。エージェントは、チーム紐づきトークンで認証するだけで、標準ツール(remember、recall、recall_context、search など)を使用して共有チームメモリに透過的にアクセスできます。

  • 共有チームメモリ: チーム紐づきトークンで認証された接続エージェントは、共有チームメモリ空間に対する読み取りと書き込みを行います。
  • 共有チームナレッジ: チーム空間(?space=<team_id>#knowledge)配下に公開されたドキュメントコレクションは、knowledge:read スコープを持つチームエージェントおよびチームメンバーが取得できます。
  • 共有チーム Cloud Skill: チーム空間(?space=<team_id>#skills)で作成された手順スキルは、チームロールによって管理されます。チーム空間で公開すると PROPOSED リビジョンが作成され、Admin または Owner の承認が必要になります。
  • 個人プロジェクトの境界: 現在のところ、プロジェクトワークスペースは厳格に個人専用のままです(services/personal_console.py:7222)。team_id を指定したプロジェクトワークスペースの作成はバックエンドによって拒否されます。
  • データエクスポートの境界: 個人データのエクスポート(/api/v1/export または /me#memory)は個人のメモリのみを正確にエクスポートし、共有チームメモリレコードは厳格に除外されます。
  • 固定されたツールインターフェース: チーム管理ツール(チーム作成や招待管理など)が MCP に追加されることはありません。
  • ユニバーサルなクライアント互換性: Claude Desktop、ChatGPT、Codex、Cursor、および Gemini CLI は、クライアント側の設定を変更することなくチームメモリとやり取りできます。
  • スコープ付き分離: チーム空間内でエージェントによって書き込まれたメモリには自動的にチーム属性が付与され、個人のユーザーメモリから分離されます。

明確な境界と未検証の機能

出荷されたコードに先行してドキュメントが乖離するのを防ぐため、以下の機能は明示的に利用不可とされており、現在のリリースの対象外です:

  • Business プランが必要: Teams 機能は Business プランに属しており、現在はまだ一般購入を受け付けていません。
  • 本番環境での作成無効: Business プランがローンチされるまで、本番環境での一般的なセルフサービスチーム作成は無効化されています。
  • 自動化された SCIM / SAML 同期の不在: エンタープライズ ID プロバイダーのディレクトリ同期はサポートされていません。
  • クロスクラウドまたはマルチリージョンデータレプリケーションの不在: チームデータは単一のリージョナルテナントパーティション内に保持されます。
  • MCP による変更ツールの不在: MCP ツール呼び出しを通じてチームを作成、変更、または削除することはできません。
  • 拒否専用ランタイムモード: Business プランがローンチされるまで、現在のランタイムは未認可のリクエストに対して拒否専用(deny-only)モードで動作します。
  • 根拠のないパフォーマンスメトリクスの不在: 失効およびクエリの処理時間は運用上の実行時特性であり、固定された数値保証ではありません。

ペルソナフロー

ChatGPT ユーザー

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

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

Copilot / Codex 開発者

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

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

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

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

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

出典: Enterprise & Teams