> ## Documentation Index > Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt > Use this file to discover all available pages before exploring further. # 自動管理 > SSO ユーザーを SAML メタデータ属性に基づいて正しいチームとプロジェクトに自動的に割り当てます。 ユーザーが SAML SSO を通じてサインインすると、Enterprise Knowledge はメタデータ属性を評価し、ユーザーをチームに、オプションでそのチーム内のすべてのプロジェクトに（適切なロールで）自動的に割り当てることができます。 自動管理とアクセスコントロールは独立した機能ですが、通常は一緒に使用されます。詳細については、[SAML アクセスコントロール](/super-admin/sa-access-controls.mdx)を参照してください。 ## 前提条件 自動管理を有効にする前に： * SAML SSO が設定済みで、ログイン時にメタデータ属性が送信されていること * SAML アサーションに照合対象となる安定した属性が含まれていること * 対象チームが EK に既に存在していること。チームの作成方法については、[チーム管理](/super-admin/sa-teams)を参照してください。 自動化を有効にする前に、いくつかの成功した SSO ログインから属性名と値を検証してください。スーパーアドミンのユーザービューには、各 SSO ユーザーの保存された SAML メタデータが表示されます。ルールを作成する際の信頼できる情報源としてご活用ください。 ## ルール構造 **スーパーアドミン → ユーザーとワークスペース → チーム → 自動管理**に移動してルールを設定します。各ルールには以下が含まれます： | フィールド | 必須 | 説明 | | ------------------ | ----- | ------------------------------------------------------ | | SAML 属性名 | はい | SAML アサーションの属性キー | | 属性値 | はい | 1つ以上のカンマ区切りトークン — リストされたすべてのトークンが一致する必要があります（AND ロジック） | | 対象チーム | はい | ユーザーを割り当てるチーム | | デフォルトチームメンバーシップロール | オプション | `Member`（デフォルト）または `Admin` | | チームプロジェクトに自動追加 | オプション | チーム内のすべての非デフォルトプロジェクトにユーザーを追加 | | デフォルトプロジェクトロール | オプション | `Admin`、`Editor`、または `Viewer` | | 強制的な継続チーム再割り当て | オプション | 初回ログインだけでなく、毎回のサインイン時にユーザーを移動 | ルールには以下も含めることができます： * **条件付きチームロールオーバーライド** — 追加の SAML 属性に基づいてチームメンバーシップロールを変更 * **条件付きプロジェクトロールオーバーライド** — 追加の SAML 属性に基づいてプロジェクトロールを変更（自動追加が有効な場合にのみ適用） ## ルールマッチングの仕組み 属性マッチングはアクセスコントロールと同じエンジンを使用します。ルールとユーザー属性の両方が**トークンのセット**として扱われ、サブセットセマンティクスで比較されます — ルールは必要なトークンがユーザーのトークンの**サブセット**である場合に一致します。 * **属性値のカンマ**はトークン区切り文字です。`Accounting, US` はユーザーが**両方**のトークンを持っていることを要求します（1ルール内の AND ロジック）。 * **特異性**はルールが要求するトークンの数に等しいです。複数のルールが一致する場合、**最も特異な**（トークン数の多い）ルールが優先されます。 同等の特異性を持つルール間のタイブレークはありません。2つのルールが同点の場合、EK は最初に作成されたルールを選び、タイしたルール ID を含む `WARNING` ログを出力します。これを設定エラーとして扱い、重複を排除するためにルールを再構成してください。 ### 異なる SAML ワイヤフォーマットの処理 SAML 属性は2つのフォーマットで到着する可能性があり、各ルールにはそれらを処理するトグルが用意されています： **ネイティブマルチ値** — IdP が複数の `` 要素を送信します。EK はこれを自動的にセットとして扱います。 **CSV 対応の単一値** — IdP が値をカンマ区切りの文字列にパックします。ルールごとのトグルを使用します： | トグル：「IdP がマルチ値を1つの文字列にパック」 | 動作 | | -------------------------- | --------------------------------- | | **オフ**（デフォルト） | ユーザーの文字列は1つのリテラルトークンとして処理されます | | **オン** | ユーザーの文字列はカンマで分割され、セットとしてマッチングされます | 完全なリファレンス表については、[SAML アクセスコントロール — マッチング動作マトリクス](/super-admin/sa-access-controls#matching-behavior-matrix)を参照してください。 ## チーム割り当て動作 毎回の SSO サインイン時に、EK は設定済みルールをユーザーの SAML メタデータに対して評価し、最も特異な一致ルールを選びます。 | ユーザーステート | 結果 | | ---------------- | ---------------------------- | | チームに未所属 | 対象チームに割り当て | | 対象チームに既に所属 | 変更なし | | 異なるチームに所属 | **強制的な継続チーム再割り当て**が有効な場合のみ移動 | | メンバー複数のチームのオーナー | 強制的に移動されない（オーナーシップの孤立を防止） | | チームの唯一のメンバー/オーナー | 移動；空になったチームは削除 | 初回の SSO オンボーディングでは、正しい配置を確立するために再割り当ては常に強制されます。 ## チームメンバーシップロール ユーザーがチームに追加されるロールは、以下の順序で解決されます： 1. **条件付きチームロールオーバーライド** — ユーザーのトークンにサブセット一致する最も特異なオーバーライド 2. **デフォルトチームメンバーシップロール** — ルールで設定された `Member` または `Admin`（レガシーデフォルト：`Member`） チームロールは**追加時のみ**適用されます。ユーザーが既に対象チームにいる場合、既存のロールは保持されます — 以降のサインインでは変更されません。既存のメンバーの昇格や降格には、管理者の明示的な操作が必要です。 ### 条件付きチームロールオーバーライド 各オーバーライドには**属性名**、**属性値**、オプションの `is_csv_value` トグル、および**チームロール**（`Member` または `Admin`）を指定します。最も特異な一致オーバーライドが優先されます；同点の場合は警告がログに記録されます。 ## プロジェクトへの自動追加 ルールで**チームプロジェクトに自動追加**が有効な場合、EK は対象チームの非デフォルトプロジェクトにユーザーを追加します。ユーザーは既にメンバーではないプロジェクトにのみ追加されます。 ロール割り当ての優先順位： 1. 一致する**条件付きプロジェクトロールオーバーライド**（最も特異な一致） 2. チームルールで定義された**デフォルトプロジェクトロール** プロジェクト割り当ては非同期で実行されます。チームメンバーシップはすべてのプロジェクトメンバーシップの完了前に表示される場合があります。 プロジェクトロールは**追加時のみ**適用されます。既存のプロジェクトメンバーシップは、以降のサインインで再評価や変更が行われることはありません。 ## 条件付きプロジェクトロールオーバーライド ロールオーバーライドにより、追加の SAML 属性に基づいて異なるプロジェクトロールを割り当てることができます。 **例：** * チームルール：`department = engineering`、デフォルトロール → `Viewer` * ロールオーバーライド：`level = manager` → `Admin` **結果：** * すべての `engineering` ユーザーがチームに追加 * `level = manager` も持つユーザーは自動追加プロジェクトで `Admin` を受け取る * マネージャーでないユーザーは `Viewer` を維持 複数の条件付きロールオーバーライドが同じユーザーに一致する可能性がある場合、最も特異な（トークン数の多い）ものが優先されます。同点の場合は警告がログに記録され、最初に作成されたオーバーライドにフォールバックします — 同点を避けるためにオーバーライドを再構成してください。 ## チーム再割り当て制限 **スーパーアドミン → チーム → 自動管理 → チーム再割り当て制限**にあるこれらの設定は、ユーザーがチーム間を移動した場合のプロジェクトメンバーシップへの影響を制御します。3つすべてのデフォルトは**オフ**（非破壊的）です。 チーム再割り当て制限 | 設定 | 説明 | | --------------------------------- | ----------------------------------------- | | **1. 旧チームのプロジェクトからユーザーを削除** | マスタースイッチ。再割り当て時に旧プロジェクトメンバーシップを削除します。 | | **2. ユーザーが所有するプロジェクトはフォローする** | 設定1に依存。所有プロジェクトは新しいチームに移動します。 | | **3. フォローされたプロジェクトから旧チームメンバーを削除** | 設定1と2に依存。移動されたプロジェクトの旧チームアクセスをクリーンアップします。 | 実際には： * **設定1のみ** — ユーザーは旧チームのプロジェクトから削除されます；所有プロジェクトは旧チームに残り、所有権は旧チームのオーナーに移譲されます * **設定1 + 2** — ユーザーが所有するプロジェクトは新しいチームに移動します；既存のメンバーはそのまま残ります * **設定1 + 2 + 3** — オーナーと一緒に移動したプロジェクトから旧チームメンバーも削除されます 再割り当て時に所有権を安全に移譲できない場合、EK は破損した所有権状態を防ぐためのセーフガードを適用します。 ## 自動管理ルールの設定 **スーパーアドミン → ユーザーとワークスペース → チーム → 自動管理**に移動し、**ルールを追加**をクリックします。 **SAML 属性名**、**属性値**、**対象チーム**を指定します。 マルチトークンルールの場合、各トークンを入力してカンマを押してチップを作成します（例：`accounting` + `us` で両方を要求）。必要に応じて **IdP がマルチ値を1つの文字列にパック** をトグルします。 新しいチーム割り当てルール **デフォルトチームメンバーシップロール**（`Member` または `Admin`）を選択し、必要に応じて追加の属性に基づいて異なるチームロールを必要とするユーザー向けの**条件付きチームロールオーバーライド**を追加します。 **チームプロジェクトに自動追加**および/または**強制的な継続チーム再割り当て**を有効にするかどうかを決定します。 **デフォルトプロジェクトロール**を選択し、必要に応じて**条件付きプロジェクトロールオーバーライド**を追加します。 ルールを保存し、必要に応じて**チーム再割り当て制限**を設定して、ユーザーがチームを変更した場合の動作を定義します。 本番環境で有効にする前に、各期待されるメタデータパターンを表す実際の SSO ユーザーでテストします。 ## ルール設計のベストプラクティス * **安定したアイデンティティプロバイダー属性**を使用する — 変動しやすい値や頻繁に変更される値を避ける * 属性名を正確な SAML クレーム名と一致させる（一部の IdP ではクレームレベルで大文字・小文字を区別） * IdP がサポートしている場合は、**ネイティブマルチ値** SAML 属性を推奨 — 曖昧さがなく `is_csv_value` トグルが不要 * **同等の特異性で重複するルールを避ける** — 「Ambiguous match」警告が表示される場合は、ルールにトークンを追加して厳密により特異にする * **最小権限**（`Member` チームロール、`Viewer` プロジェクトロール）から開始し、条件付きオーバーライドで必要な場合のみ昇格 * ルールの所有権を文書化し、定期的なレビューをスケジュールする ## テストチェックリスト 設定後、各シナリオを確認します： * 許可されたユーザーが正しいチームロールで正しいチームに配置されること * 条件付きチームロールオーバーライドが正しいユーザーに適用されること * プロジェクト自動追加が正しいロールで完了すること（非同期処理に数秒かかる場合があります） * 条件付きプロジェクトロールオーバーライドが正しいユーザーに適用されること * 強制再割り当てが期待通りに動作すること（有効な場合） * チーム移動時に再割り当て制限設定が正しく動作すること ## トラブルシューティング * 一致するチーム割り当てルールが存在することを確認 * 対象チームがまだ存在することを確認 * ルールの属性/値トークンがユーザーの実際の SAML メタデータのサブセットであることを確認（スーパーアドミンのユーザービューを確認） * ユーザーが別のチームに既に所属しており移動が必要な場合は**強制的な継続チーム再割り当て**を有効にする * ユーザーがメンバー複数のチームのオーナーの場合、自動的に移動されません — これは意図的な動作です * ログに `Ambiguous match` 警告が含まれている場合、2つのルールが同等の特異性で同点です。重複を排除するために再構成する * **条件付きチームロールオーバーライド**が存在し、ユーザーに一致するかどうかを確認 * チームロールは追加時のみ適用されます — オーバーライドが追加される前にユーザーが既にチームにいた場合、既存のロールは保持されます。手動で昇格または降格してください * オーバーライド間の同点の場合、ログを確認し、意図したオーバーライドにトークンを追加して厳密により特異にする * 一致したルールで**チームプロジェクトに自動追加**が有効であることを確認 * チームに非デフォルトプロジェクトが存在することを確認 * 有効なプロジェクトロール（`Admin`、`Editor`、または `Viewer`）が設定されていることを確認 * 非同期バックグラウンド処理に短い遅延を許容する * ロールオーバーライドが正しいチーム割り当てルールにアタッチされていることを確認 * 追加の属性/値がユーザーの SAML メタデータに実際に存在することを確認 * デフォルトロールが適用されている場合、条件付きオーバーライドが一致しなかったことを意味します * 属性が CSV 対応の単一文字列として到着する場合、オーバーライドで **IdP がマルチ値を1つの文字列にパック** が有効であることを確認 同等の特異性を持つ2つ以上のルール（またはオーバーライド）が同じユーザーに一致しました。EK はDeterministicに最初に作成されたルールを選びましたが、設定は脆弱です。 ログ行には同点のルール ID がリストされます。1つを編集して追加のトークンを追加し、厳密により特異にするか、重複を完全に削除してください。 ## 運用ガイド * 割り当てルールを**セキュリティ上重要な設定**として扱う * 本番環境への更新には変更管理プロセスを使用する * IdP のクレーム変更後（例：CSV 対応からネイティブマルチ値への切り替え、クレームの名前変更）は再テストする * 定期的にルールをレビューし、古いマッピングを削除する * 新しいルールを作成する前に、スーパーアドミンのユーザービューで保存された SAML メタデータを確認する