> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # テナント管理（組織とメンバー） > AgentEye テナント管理（組織とメンバー）のドキュメント。 単一の AgentEye デプロイメントで、複数の完全に分離された**組織**（テナント）を提供します。これにより、1つのインスタンスで異なるチーム、事業部門、または顧客をホストしながら、あるテナントのデータが別のテナントに公開されることを防ぎます。すべてのデータ行（イベント、評価、セッション、ダッシュボード、保存済みクエリ、アラート、APIキー、メンバー）は、必ず1つの組織に属します。主要な分離はアプリケーションコードで強制されます。すべてのリクエストは、明示的な `org_id` 述語によって対象の組織にスコープされます。大量のイベントと評価が格納される ClickHouse では、これはエンジンレベルの強力な強制によって裏付けられています。各組織は専用の読み取り専用 ClickHouse ユーザーと組織ごとの行ポリシーを持つため、信頼されていない分析 SQL でも別テナントの行を読み取ることはできません。PostgreSQL では、行レベルセキュリティが読み取り専用クエリパス（`/queries/run`）に多層防御を追加し、アプリケーションレベルのフィルターが欠落していた場合でも、そのパスが参照できるデータを制限します。サーバー自身の書き込みコネクションはテーブルオーナーとして実行されるため、アプリケーションレベルの `org_id` スコープを通じて動作します。 テナントのライフサイクルはオペレーターが管理し、メンバーが日常的に行うすべての操作はダッシュボードでセルフサービスとして利用できます。組織とそのメンバーシップは **`agenteye-orgctl`** CLIを使用して作成・管理します。このCLIはサーバーイメージに同梱されており、**既存のサーバーポッド内で実行します**。テナントの作成と削除は意図的にダッシュボードとHTTP APIから除外されています。テナントのライフサイクルには**HTTPエンドポイントもダッシュボードのボタンも存在しません**。そのため、アプリケーションの表面からではなく、クラスター/ポッドのシェルアクセスによってのみ操作できます。 組織内では、メンバーはダッシュボードとAPIだけで作業します。サインイン、所属する組織の切り替え、自分のAPIキーの管理、ダッシュボードや保存済みクエリの構築、および組織のアラート設定などが行えます。役割分担は明確です。オペレーターはCLIを通じてテナントとメンバーのプロビジョニング・廃止を行い、メンバーはUIを通じてテナント内のすべてを操作します。 > **シングルテナント構成ではこの手順は不要です。** シングルテナントのインストールは、オペレーターの操作なしに動作します。すべてのデータ、ユーザー、キーは、自動的にプロビジョニングされる組み込みの `default` 組織に格納されます。このガイドが必要になるのは、2つ目の組織を追加する場合のみです。 *** ## 前提条件 **2つ目**の組織を作成する前に（組み込みの `default` 組織には何も必要ありません）: * **PostgreSQL 15以降。** 組織メンバーシップのスキーマは、PostgreSQL 15以降が必要な列リスト形式の `ON DELETE SET NULL` 外部キーを使用します。2つ目の組織をプロビジョニングする前に PostgreSQL をアップグレードしてください。 * **強力で安定した `ORG_CH_SECRET`。** 各組織の ClickHouse パスワードは `HMAC(ORG_CH_SECRET, org_id)` として導出されます。そのため、公知の組み込み開発用デフォルト値を使用すると、組織ごとの認証情報が外部から推測可能になります。`agenteye-orgctl org create` は **`ORG_CH_SECRET` が未設定または組み込みの開発用デフォルト値のままの場合、実行を拒否します**。事前に独自の値を設定してください（[デプロイメント → 環境変数](/ja/agenteye/deployment) および Kubernetes の場合は [Kubernetes ガイドのセクション 2.6](/ja/agenteye/kubernetes-deployment#26-multi-tenant-org-isolation-key-optional) を参照してください）。すべてのサーバーレプリカで同一の値を使用し、気軽にローテーションしないでください。ローテーションすると、次回の起動で再プロビジョニングされるまで、すべての組織の ClickHouse ユーザーが孤立状態になります。 *** ## CLIの実行方法 `agenteye-orgctl` は **サーバーと同じイメージ**（`agenteye-server` の隣）に同梱されています。専用のポッド、Job、Deployment はデプロイ**しません**。既に実行中のサーバーポッド内で exec して使用するため、サーバーが使用している `DATABASE_URL`、`CLICKHOUSE_URL`、`ORG_CH_SECRET` と同じ値が読み込まれます。 **Kubernetes:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- agenteye-orgctl ``` **Docker Compose:** ```bash theme={null} docker compose exec server agenteye-orgctl ``` 以下の例では簡潔さのために `agenteye-orgctl ` のみ記載しています。実際には、デプロイメント環境に応じて上記いずれかの行を先頭に付けてください。 *** ## コマンドリファレンス ### 組織 | コマンド | 内容 | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `org create --slug --name ` | 新しい組織を作成します。`ORG_CH_SECRET` が未設定または組み込みの開発用デフォルト値のままの場合は実行を拒否します（前提条件を参照して事前に独自の値を設定してください）。組織の読み取り専用 ClickHouse ユーザーと行ポリシーをプロビジョニングします。 | | `org list` | すべての組織（スラッグ、名前、ライフサイクル状態）を一覧表示します。 | | `org rename --slug --name ` | 組織の表示名を変更します。スラッグ（URLとキーで使用）は変更されません。 | | `org delete --slug ` | 組織を**ソフトデリート**し、その ClickHouse ユーザーを削除します。データは**保持されます**。アクセスを無効化し、組織ごとの ClickHouse 認証情報を解放しますが、イベントは削除しません。オペレーターによって元に戻すことができ、パージ前の安全な最初のステップです。 | | `org purge --slug ` | **不可逆的なデータ削除。** 組織は事前に `delete` されている必要があります。組み込みの `default` 組織には絶対に実行できません。テナントのデータを確実に破棄する場合にのみ使用してください。 | ### メンバー | コマンド | 内容 | | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `member add --org --email [--set ] [--add perm1,perm2] [--remove perm3] [--protected]` | 組織にメンバーを追加します。オプションで組み込みの権限セットをベースにして、個別の権限を追加/削除できます。`--protected` を指定すると、ダッシュボードからメンバーを削除またはデモートできなくなります（後述）。新しいメンバーは、最初のダッシュボードログイン時にOTPを受け取ります。 | | `member list --org ` | 組織のメンバーを一覧表示します。出力列は `EMAIL`、`SET`（メンバーが使用した組み込みセット、または `-`）、`PROT`（メンバーが保護されているかどうか）、`PERMISSIONS`（有効な権限）です。末尾に `*` が付いたメールアドレスはインスタンス管理者を示し、すべての組織にアクセスできます。 | | `member update --org --email [--set ...] [--add ...] [--remove ...] [--protected \| --unprotect]` | メンバーの権限や保護フラグを変更します。`--set` は組み込みセットで置き換え、`--add` / `--remove` は個別の権限を調整し、`--protected` / `--unprotect` は保護を切り替えます。付与フラグなしで `--protected`/`--unprotect` のみを指定した場合、保護のみが変更され、既存の権限はそのまま維持されます。 | | `member remove --org --email ` | 組織からメンバーを削除します。メンバーが保護されている場合は拒否されます。先に `--unprotect` してください。（1人が複数の組織のメンバーになれますが、これは指定した組織のみに影響します。） | 1人が複数の組織のメンバーになることができ、それぞれで**異なる**権限を持てます。例えば、ある組織では管理者、別の組織では読み取り専用といった設定が可能です。各メンバーシップは組織ごとに独立して管理されます。ある組織でのメンバーの権限変更は、他の組織でのメンバーシップには影響しません。 ### 保護メンバー（削除不可能な組織管理者） 保護機能により、組織が誤ってセルフ管理から締め出されることを防ぎます。デフォルトでは、組織内の管理者はダッシュボードのセルフサービスのユーザーページから互いを追加・削除できるため、最後の管理者を削除して組織を管理できない状態にしてしまう可能性があります。 ユーザーページ：ダッシュボードユーザーごとにカードが表示され、メールアドレス、付与された権限、編集/無効化コントロールが含まれます これを防ぐために、1人のメンバーを**保護**としてマークします: ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member add --org acme --email owner@acme.example --set admin --protected ``` 保護されたメンバーは**ダッシュボードから削除またはデモートできません**。そのような操作はエラーになります。変更できるのはオペレーターのみで、このCLIからのみ操作可能です。まず `member update --org acme --email owner@acme.example --unprotect` を実行してから、削除またはデモートしてください。これにより、すべての組織が少なくとも1人の管理者を維持し、組織のメンバー自身がその管理者を締め出せないようになります。また、テナントの管理権限はオペレーターのみに維持されます。保護は**組織ごと**に設定されます。ある組織で誰かを保護しても、別の組織でのメンバーシップには影響しません。 ### 組み込み権限セット `--set` は、組織ごとに適用される3つの組み込みセットのいずれかを受け付けます: | セット | 対象 | | ----------- | ---------------------------------------- | | `admin` | 組織内でのフルアクセス。組織のAPIキーとユーザーの管理を含みます。 | | `standard` | 日常的な使用：クエリの読み取りと実行、ダッシュボードの構築、インシデントの承認。 | | `read-only` | 組織のデータとダッシュボードへの閲覧のみのアクセス。 | `--set` でセットを指定した後、[APIキー](/ja/agenteye/api-keys) に記載されている個別の権限トークンを使用して `--add` / `--remove` で細かく調整できます。権限トークン自体はAPIキーに使用されるものと同一です。 *** ## 実践例 新しい `acme` テナントをプロビジョニングし、最初の管理者を追加して、キーを作成させた後、組織を廃止します。 **1. 組織を作成する**（`ORG_CH_SECRET` は事前に強力で安定した値に設定されている必要があります。未設定または組み込みの開発用デフォルト値のままにしないでください）: ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org create --slug acme --name "Acme Corp" ``` **2. 最初のメンバーを組織管理者として追加する:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member add --org acme --email alice@acme.example --set admin ``` Alice はダッシュボードに初めてサインインするときにOTPを受け取ります。それ以降は、組織のURLプレフィックス（例: `/acme/sessions`）のもとで、UIでのみ作業します。 **3. 組織ごとのAPIキーを作成する（ダッシュボードにて）:** オペレーターはCLIから組織ごとのデータキーを**作成しません**。Alice（または `keys:create` 権限を持つ組織メンバー）が、ダッシュボードの**キー**ページから `acme` 組織のコレクター/ダッシュボードキーを作成します。作成されたすべてのキーは自動的に組織と紐付けられ、`acme` のデータの読み書きのみが可能です。[APIキー](/ja/agenteye/api-keys) を参照してください。 **4. 後でメンバーを変更する:** ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member update --org acme --email alice@acme.example --add alerts:write kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl member list --org acme ``` **5. 組織をソフトデリートする**（アクセスを無効化し ClickHouse ユーザーを削除；データは保持）: ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org delete --slug acme ``` **6. 組織をパージする**（不可逆；ソフトデリート後のみ；`default` 組織は不可）: ```bash theme={null} kubectl -n agenteye exec deploy/server -- \ agenteye-orgctl org purge --slug acme ``` Docker Compose の場合は、各コマンドの `kubectl -n agenteye exec deploy/server --` プレフィックスを `docker compose exec server` に置き換えてください。 *** ## 責任の分担 組織メンバーが日常的に必要とするすべての操作は、ダッシュボードとAPIでセルフサービスとして利用でき、現在の組織に自動的にスコープされます: * **組織ごとのAPIキー**は、ダッシュボード（または `keys:create` を持つキーを使用したキーAPIを通じて）で組織メンバーが作成・管理します。CLIはデータキーを**作成しません**。[APIキー](/ja/agenteye/api-keys) を参照してください。 * **組織の切り替え**はダッシュボードに組み込まれており、メンバーは組織スイッチャーから所属する組織を切り替えることができます。組織スコープのページは `//…` 以下に存在します。 * **ダッシュボード、保存済みクエリ、アラート、およびすべてのデータ利用**は、UIとAPIで完結し、メンバーの現在の組織にスコープされます。 オペレーターは `agenteye-orgctl` を使用して、組織とメンバーの**ライフサイクル**のみを管理します。つまり、組織の作成/名前変更/削除/パージ、およびメンバーの追加/一覧表示/更新/削除です。 *** ## 関連情報 * [デプロイメント](/ja/agenteye/deployment): `ORG_CH_SECRET` とその他のサーバー環境変数。 * [Kubernetes デプロイメント](/ja/agenteye/kubernetes-deployment): セクション 2.6 では、最初のマルチテナント組織の前に `agenteye-org-ch-secret` シークレットを作成します。 * [APIキー](/ja/agenteye/api-keys): 組織ごとのキーモデルと、`--add` / `--remove` で使用される権限トークン。 * [トラブルシューティング](/ja/agenteye/troubleshooting): マルチテナントのプロビジョニングと ClickHouse 分離に関する問題。