プロジェクトの自動管理

SAML ベースのシングルサインオン（SSO）でサインインした瞬間に、IdP（Identity Provider）が送信する属性に基づいて、ユーザーを特定のプロジェクトに正しいプロジェクトロール付きで自動追加します。

このガイドはプロジェクトの割り当てのみを扱います。プロジェクトルールはチームの割り当てから完全に独立しています：ユーザーは、どのチームルールにも一致しない場合でも、属性ルールによって特定のプロジェクトに追加できます。

情報

チームベースの自動割り当ては別のドキュメントで説明しています。対になるガイドは自動チームおよびプロジェクト割り当てをご覧ください。

このドキュメントは、Enterprise Knowledge（EK）の Super Admin ダッシュボードから機能を構成する管理者向けに書かれています。

プロジェクト割り当ての機能

ユーザーが SAML SSO で認証すると、IdP は SAML レスポンスに一連の属性を含めます — 例：department、role、memberOf、group、country。EK はそれらの属性を構成済みのプロジェクト割り当てルールと比較し、一致した場合：

• ルールの対象プロジェクトの各々にユーザーを追加（既に所属しているものはスキップ）。
• 各プロジェクトにプロジェクトロールを適用 — デフォルトのロール、または条件付き上書きが一致した場合は別のロール。

ルールは毎回の SSO サインインで評価されるため、IdP 属性が変わってもアクセスは最新に保たれます。

情報

設計上追加のみ： プロジェクトルールはアクセスを追加するだけです。ユーザーがプロジェクトから削除されることはなく、以前一致した属性が一致しなくなっても、既存のプロジェクトロールが格下げされることはありません。プロジェクトアクセスの削除は引き続き手動/管理のアクションです。

情報

チームから独立： プロジェクトルールはチームの所属、ホーム / 請求チーム、チームロールに触れません。チーム全体のアクセスが欲しい場合は、代わりに（または追加で）チームの割り当てルールを使用してください。

前提条件

プロジェクトの自動割り当てを使う前に：

1. テナントに SAML SSO が構成されていること、そして IdP が一致させたい属性を送信していること。SAML レスポンスに属性が存在しない場合、それを参照するルールは一致できません。
2. EK へのスーパー管理者アクセスが必要です。一部のスーパーアドミンロールは閲覧専用です — そのモードではルールは表示されますが、作成/編集/削除コントロールは非表示になります。
3. 対象プロジェクトが既に存在していること。 ルールは既存のプロジェクトを参照します；作成はできません。

ヒント

まず属性名を把握してください。 正確な属性の名前と値（例：http://schemas.xmlsoap.org/.../group 対 group）は IdP によって決まります。IdP 管理者に確認するか、サンプルの SAML アサーションで確認してください — ルール内の属性名は IdP の属性名と完全に一致しなければなりません。

設定場所

エントリポイントは2つあり、どちらも Super Admin 配下です：

Automated Management タブ（すべてのプロジェクトルール）

Super Admin → Projects タブ → Automated Management サブタブ。

システム内のすべてのプロジェクト割り当てルールを一覧表示し、作成、編集、削除できます。各ルールは1つまたは多数の対象プロジェクトを持てます。

プロジェクト別ショートカット（1プロジェクトのルール）

Super Admin → Projects タブ → Project Management。 プロジェクトを探し、Actions 列のシールドアイコン（「SAML Project Rules」）をクリックします。そのプロジェクトを対象とするすべてのルールを表示するモーダルが開き、ルールの追加、編集、削除ができます。

• このモーダルでは、現在のプロジェクトが対象としてロックされ、削除できません。
• ここでのルール編集は、単一のルールが多数のプロジェクトを一度に対象としうるため、その他の対象プロジェクトにも影響する場合があります。

プロジェクトルールの解剖

フィールド	目的
SAML Attribute Name	検査する属性（例：department）。IdP が送信するものと完全一致。
Attribute Value(s)	必須とされる1つ以上の値。UI では値を入力し、カンマ/Enter でチップ/タグにします。
IdP packs multi-values into one string	ユーザー側 CSV トグル — 属性マッチングの仕組みをご覧ください。
Wildcard (substring) match	部分一致トグル — 属性マッチングの仕組みをご覧ください。
Default Project Role	上書きが一致しない限りすべての対象プロジェクトに適用されるロール：Viewer、Editor、Admin。
Target Projects	1つ以上のプロジェクト（id / 名前 / チーム / オーナーで検索可能）。少なくとも1つ必要。
Conditional Role Overrides	追加の属性が一致したときに別のプロジェクトロールを割り当てる任意のネストルール — 条件付きロール上書きをご覧ください。

属性マッチングの仕組み

このセクションは、ルールが期待どおりに機能するかを支配します。マッチャーのメンタルモデルは：**「1つの本当にあいまいな場合を除き、すべては多値セットとして扱われる」**です。

属性マッチングは SAML Access Controls と同じエンジンを使用します。一般的なリファレンスはあのガイドのマッチング挙動マトリックスをご覧ください；下記のプロジェクト固有のマトリックスはワイルドカードの挙動を含みます。

ルール側（あなたが入力するもの）

Attribute Value(s) に入力するものは常にカンマ区切りのトークンセットとして扱われます。各トークンが必須の値です。

• 単一値（Finance）のルールは、ユーザーの属性に Finance を含むときに一致します。
• 複数値（Finance, US）のルールは、ユーザーの属性がそれらをすべて含むときにのみ一致 — **部分集合（⊆）**マッチ：ルールの必須セットはユーザーのセットに含まれていなければなりません。

情報

ルール内のカンマは常にトークン区切りであるため、カンマを含むリテラル値（例：Smith, John）に一致するルールは書けません。実際、アクセス制御属性（グループ、ロール、部署）にリテラルのカンマが含まれることはほとんどなく、この制限は稀です。

マッチングは大文字小文字を区別せず、周囲の空白は切り詰められます。

ユーザー側（IdP が送信するもの）

ユーザーの受信値の解釈は、そのワイヤ形状とルールごとのトグルに依存します：

IdP が送る…	解釈	トグルが必要？
複数の <AttributeValue> 要素（ネイティブ多値）	セット — 常に	いいえ — 自動
単一の <AttributeValue> でプレーンな値（Finance）	単一の値	いいえ
単一の <AttributeValue> に複数値をカンマ区切り文字列で詰めたもの（Finance,US,Admin）	CSV トグルがオフなら単一のリテラル値	はい — 下記参照

トグル：「IdP packs multi-values into one string」

一部の IdP は、複数の値を単一の属性値にカンマ区切り文字列として詰めます（例：Accounting,Admin,US）。デフォルトでは EK は単一の属性値を1つのリテラルトークンとして扱うため、Accounting,Admin,US は Accounting というルール値に一致しません。

• オフ（デフォルト）： ユーザーの単一文字列は1つのリテラル値；埋め込まれたカンマは保持されます。属性が本当に単一値のときに使用。
• オン： ユーザーの単一文字列は、マッチング前にカンマで分割されてセットになります。IdP が複数値を1文字列に詰めるときに使用。

このトグルはユーザーの単一文字列値の解釈にのみ影響します。ルール値の読み方（ルールのカンマは常に区切り）を変えることは決してなく、IdP が既にネイティブ多値属性を送信する場合は無視されます（それらは常にセット）。

挙動マトリックス

ユーザーの受信値	トグル	あなたのルール値	一致？
ネイティブ ["A","B","C"]	オフ	A	✓
ネイティブ ["A","B","C"]	オフ	A, B	✓
ネイティブ ["A","B","C"]	オン	A, B	✓
文字列 "A,B,C"	オフ	A	✗
文字列 "A,B,C"	オフ	A, B	✗
文字列 "A,B,C"	オン	A	✓
文字列 "A,B,C"	オン	A, B	✓
文字列 "A"	オフ	A	✓
文字列 "A"	オン	A	✓

トグル：「Wildcard (substring) match」

• オフ（デフォルト）： 各ルールトークンはユーザートークンと完全一致する必要があります（大文字小文字を区別しない切り詰めの後）。
• オン： 各ルールトークンは、ユーザーのトークンのどこかの中に現れれば一致（大文字小文字を区別しない部分一致）。例：ルール値 val2 は受信値 val1val2val3 に一致します。多トークルールでは、すべてのルールトークンが何らかのユーザートークンに含まれる必要があります。

ワイルドカードは CSV トグルとは独立です：CSV はユーザーの文字列がどのようにトークンに分割されるかを制御し、ワイルドカードは各トークンがどのように比較されるかを制御します。

警告

注意： ワイルドカードマッチングは広く、意図したより多くのユーザーに一致する可能性があります（例：ルール admin は nonadmin に一致）。部分一致の挙動が特別に必要な場合を除き、完全一致を推奨します。

条件付きロール上書き

ルールの Default Project Role は、ルールに一致するすべての人に適用されます。Conditional Role Overrides を使って、追加の属性に基づいて、一致したユーザーの部分集合に異なるプロジェクトロールを付与します。

各上書きは独自の以下を持ちます：

• 属性名と値
• プロジェクトロール（Viewer / Editor / Admin）
• CSV トグル（「IdP packs multi-values into one string」）
• ワイルドカードトグル

上書きは、それらを所有するルールの内部で評価され、既にそのルールの主条件に一致するユーザーにのみ適用されます。

どの上書きが優先されるか

複数の上書きが一致した場合、EK は最も特定度の高いもの — 必要な値のセットが最大と定義 — を選びます。2つの上書きの特定度が並んだ場合、最早作成のものが選ばれ（警告がログに記録されます）、タイブレークに頼らずに曖昧な重複を取り除くよう上書きを再構成してください。

どの上書きも一致しない場合、ルールの Default Project Role が使用されます。

和集合のセマンティクスとロールの優先順位

和集合のセマンティクス

プロジェクトルールは純粋な和集合のセマンティクスを使用します — 「ユーザーごとに1プロジェクト」という制約はありません：

• 条件が一致するすべてのプロジェクトルールがその対象プロジェクトを寄与します。
• ユーザーは、一致したすべてのプロジェクトの和集合に追加されます（既に所属しているものはスキップ）。

ロールの優先順位

• プロジェクトロールのランク： Viewer < Editor < Admin。
• 単一のルール内では、ロールは最も特定度の高い一致上書きから解決され、なければルールのデフォルト。
• 同じプロジェクトが複数の一致ルールから対象とされ、異なるロールに解決される場合、最も特権の高いロールが勝ちます — したがって、一致するどのルールに対してもユーザーが過少供給されることは決してありません。
• 既存のプロジェクトロールは決して格下げされません。 ユーザーが既に対象プロジェクトのメンバーの場合、現在のロールは保持されます。

ステップごとの設定

プロジェクト割り当てルールの作成

1. Automated Management を開く

   Super Admin ダッシュボードを開き、Projects タブ → Automated Management サブタブに移動します。

2. 新しいルールを作成

   New Rule をクリックします。

3. SAML の一致条件を入力

   SAML Attribute Name（例：memberOf）を入力し、Attribute Value(s) を1つ以上追加 — 値を入力してカンマ/Enter でチップを作成します。

4. トグルを設定

   • IdP が単一のカンマ区切り文字列で複数値を送信する場合、IdP packs multi-values into one string を有効化。
   • 部分一致が必要な場合のみ Wildcard (substring) match を有効化。

5. デフォルトのプロジェクトロールを選択

   Default Project Role（Viewer / Editor / Admin）を選択します。

6. 対象プロジェクトを追加

   Target Projects で検索（id / 名前 / チーム / オーナー）し、ルールがアクセスを付与すべき各プロジェクトを追加します。少なくとも1つ必要です。

7. 条件付き上書きを追加（任意）

   別のロールを受けるべき部分集合のために Conditional Role Overrides を追加します。

8. 保存

   Create Rule をクリックします。

ルールの編集と削除

• Automated Management 一覧でルール行の編集と削除アイコンを使うか、プロジェクト別シールドアイコンのモーダルを開きます。
• ルールの削除は対象リストとロール上書きを削除しますが、ユーザーが既に持つプロジェクトの所属は変更しません。

単一プロジェクトのルールを管理する

1. Project Management を開く

   Projects → Project Management で、そのプロジェクトを探します。

2. SAML Project Rules を開く

   Actions 列のシールドアイコン（「SAML Project Rules」）をクリックします。

3. ルールを管理

   このプロジェクトを対象とするルールの追加 / 編集 / 削除。現在のプロジェクトは対象としてロックされたままです。

具体例

例1 — グループを Editor としてプロジェクトに

目標： memberOf に KB-Editors を含むユーザーに「Knowledge Base」プロジェクトへの editor アクセスを付与。

• 属性 memberOf = KB-Editors
• Default Project Role Editor
• Target Projects：Knowledge Base

例2 — IdP が単一の詰め込みグループ文字列を送る

目標： 上記と同じが、IdP が memberOf を KB-Editors,All-Staff,VPN-Users のような単一文字列で送信。

• 属性 memberOf = KB-Editors
• IdP packs multi-values into one string = オン
• Default Project Role Editor
• Target Projects：Knowledge Base

CSV トグルがオンのため、詰め込み文字列が分割され、KB-Editors の1つのトークンとして一致します。

例3 — 2つの属性を同時に要求

目標： US と Engineering の両方に属するユーザーのみが「US Engineering Docs」プロジェクトへのアクセスを得る。

• 属性 groups = US, Engineering（2つのチップ）
• Target Projects：US Engineering Docs

ルールは、ユーザーの groups セットが両方の値を含むときにのみ一致します。

例4 — ベースロールと昇格上書き

目標： department=Support の全員が「Support Runbooks」プロジェクトへの Viewer アクセスを得る；チームリードは Editor。

• 属性 department = Support、Default Project Role Viewer
• 上書き：属性 title = Lead → Editor

department=Support, title=Lead のユーザーは Editor；素の department=Support のユーザーは Viewer。

例5 — 2つのルールから同じプロジェクト

• ルール A：role=analyst → プロジェクト X を Viewer として。
• ルール B：role=lead → プロジェクト X を Editor として。

両方に一致するユーザーはプロジェクト X に Editor として（最も特権の高いものが勝つ）。

挙動、エッジケース、重要な注意

• 追加のみ。 ルールはユーザーをプロジェクトから決して削除せず、既存のロールを決して格下げしません。デプロビジョニングは別の手動アクションです。
• チームから独立。 プロジェクトルールはチームの所属、チームロール、ユーザーのホーム / 請求チームに影響しません。
• 毎回のサインインで評価。 ユーザーの IdP 属性の変更は、次に SSO でサインインしたときに有効になります。新しいルールの作成は、現在サインインしていないユーザーに遡及適用されません。
• バックグラウンドで適用。 サインイン後、プロジェクトの追加は非同期タスクで処理されるため、非常に大きい対象セットは完全に適用されるまで少し時間がかかる場合があります。
• 既にメンバーのプロジェクトはスキップ。 ユーザーは既に所属していないプロジェクトにのみ追加され；既存のロールは保持されます。
• 欠落するロールはスキップ。 解決されたロールが特定のプロジェクトに存在しない場合、ログイン全体を失敗させる代わりにそのプロジェクトはスキップされます。
• 削除済みの対象プロジェクトは無視されます（安全に、そしてログ付き）。
• 空のルール値は拒否。 トリムと空のカンマスロット除去の後に何も残らない値は、何も一致しないため受け付けられません。
• 値は保存のために正規化。 各値周囲の空白は切り詰められ、空のスロットは削除；元の大文字小文字は表示のために保持されますが、マッチングは大文字小文字を区別しません。
• 監査。 プロジェクトルールとそのロール上書きの作成、更新、削除はスーパーアドミン監査ログに記録されます。

トラブルシューティング

ルールは正しく見えるのにユーザーが追加されない

• 属性名が IdP が送信するものと完全一致することを確認（名前は完全修飾 URI であることが多い）。
• 値の大文字小文字とスペルを確認 — マッチングは大文字小文字を区別しませんが、それ以外はトークンと一致する必要があります。
• IdP が単一のカンマ区切り文字列で複数値を送信する場合、**「IdP packs multi-values into one string」**を有効化。
• マッチングは部分集合であることを想起 — 多値ルールはユーザーがすべての列挙値を持つことを要求します。
• ルールに少なくとも1つの対象プロジェクトがあることを確認。
• ルールが適用されるには、作成後にユーザーが再度サインインする必要があります。

ユーザーは一致したが誤ったロールを得た

• 条件付き上書きを確認 — より特定度の高い上書きが勝っている可能性。
• ルール間で最も特権の高いものが勝ち、既存のロールは決して格下げされないことを想起。

部分一致が多すぎるユーザーを捕まえる

• Wildcard をオフにして完全一致を使うか、値をより具体的に。

ルールの編集が予期しないプロジェクトのアクセスを変更した

• ルールは複数のプロジェクトを対象としうる。編集（プロジェクト別シールドアイコンのモーダルからのものを含む）はその対象プロジェクトすべてに影響します。

クイックリファレンス

概念	挙動
スコープ	プロジェクトのみ — チームやホームチームに決して触れない。
ルール値のカンマ	常にトークン区切り（部分集合マッチ）。
ネイティブ多値 SAML	常にセットとしてマッチ。
単一の詰め込み文字列	CSV トグルがオンのときのみセットに分割。
ワイルドカードトグル	完全一致の代わりに部分一致。
マッチの方向	ルールの必須セット ⊆ ユーザーのセット。
特定度	必須セットが大きい = より特定度が高い（上書きに使用）。
プロジェクトロール	Viewer < Editor < Admin。
評価	和集合 — 一致するすべてのルールがそのプロジェクトを寄与。
同じプロジェクト、複数ロール	最も特権の高いものが勝つ。
既存の所属/ロール	決して格下げも削除もされない。
評価の頻度	すべての SSO サインイン。
対象プロジェクト	ルールごとに少なくとも1つ必要。
場所（すべてのルール）	Super Admin → Projects → Automated Management。
場所（1プロジェクト）	Super Admin → Projects → Project Management → シールドアイコン。