前提条件

各決定の担当者と関係者を指名しました。実際に最初の決定を行う前に、順番に3つの基盤領域を確認します。

1. 作業する場所: Claude Enterpriseを管理する3つの場所。
2. 誰が何をできるか: 組織設定内のすべての操作を制御するロール。
3. 前提条件の確認: グループ構造を選択する前に確認すべき6項目、続いてドメインクレーム（元に戻せない設定）。

ID管理チームは、他のシステムについてはすでにこれらの多くを整備している場合があります。ここでのあなたの役割は、まだ整備が必要なものは何か、そしてそれを実現する責任者は誰かを把握することです。

作業する場所

Claude Enterpriseは3つの場所から管理します。どこに何があるかを知っておくことで、設定を無駄に探し回らずに済みます。4つ目の場所であるClaude Codeのマネージド設定は、プラットフォームリードの担当です（レッスン6）。

• 組織設定: このコース内のほとんどの制御項目 — グループとロール、コネクタ、ガバナンス、支出、可視性。グループに許可する操作を変更する際はここを使用します。
• IDプロバイダー（IdP）（Okta、Microsoft Entra ID、またはそれに相当するもの）: グループの定義とメンバーシップ。これはClaudeがIDシンクを通じて読み取ります。グループのメンバーを変更する際はここを使用します。
• Claude Console: APIキーと開発者アクセス。独自の管理モデルを持つ別組織として運用されます。上記の設定では管理できないAPIアクセスを管理する際はここを使用します。

よくある混同は最初の2つの間で起こります。グループが同期されている場合、メンバーシップはIDプロバイダーで変更し、権限は組織設定で変更します。

誰が何をできるか

すべてのメンバーは、4つの組み込みロール（Primary Owner、Owner、Admin、User）のいずれか、または定義したカスタムロールのいずれかを保持しており、組織設定内のすべての操作はこれらのロールによって制御されます。各組み込みロールが持つ正確な権限は、製品の進化に伴って変化します。現在の権限マトリックスについては、ロールと権限の記事を参照してください。レッスン5では、グループ設計の一環として、User、Admin、カスタムロールの全体像を扱います。管理者側が今重要なのは、このコースで扱う決定を実際に実行できるのが誰かを決めるからです。

前提条件の確認

最初に行う決定は「構造とID」です。これは後から変更するのに最も手間がかかる決定であるため、十分な準備を整えておく必要があります。グループ構造を選択する前に整えておくべき前提条件が6つあります。そのうち4つは必須です。3つはグループのセットアップを完全にブロックするものであり、1つは自分自身をロックアウトしないための保険です。残りの2つは並行して進めることができます。

ロックアウト対策の保険とドメインクレームを詳しく見る

ロックアウト対策の保険は、表に記載した以上に詳しく見る価値があります。また、前提条件の後に来る設定であるドメインクレームについても同様です。

ロックアウト対策の保険については、少なくとも2名のメンバーにOwnerロールを付与する必要があります。IdPロールマッピングを使用しない場合は、名前を指定して直接割り当てることで、グループ同期のエラーによって管理者アクセスが失われないようにします。IdPロールマッピングを使用する場合は、マッピングを保存する前に、同じメンバーをOwnerにマッピングされたグループに含めておきます。マッピングが有効になった後は、直接割り当てだけではアクセスを復元できません。復元できるのは、自動的に削除されることのないPrimary Ownerだけです。

Primary Ownerは、他のどのロールも実行できない操作を保持しているため、特に注意が必要です。そのうちのいくつかは、このコースの後半で再び取り上げます。各管理者には、その職務をカバーできる最も権限の小さいロールを与え、Primary Ownerは日常的な管理業務から外しておきましょう。Primary Ownerがあなた自身でない場合は、誰がこのロールを保持すべきかを今のうちに確認してください。

次にドメインクレームです。会社の従業員は、組織がClaudeに存在する前に、仕事用メールアドレスで登録した非Enterpriseアカウントで、すでにClaudeを使用している場合があります。ドメインをクレームするまで、それらのアカウントは組織の外にあり、メンバーがそこで行うすべての作業も同様です。ドメインの検証は、そのドメインを所有していることを証明するものです。クレームは別のステップであり、すでにそのドメイン上にある個人アカウントを組織に移動させ、後からそのドメインで登録する人を、シングルサインオンを通じて直接組織に送り込みます。クレームの30日間のウィンドウが終了すると、そのドメイン上に個人アカウントは残りません。ヘルプセンターのドメインクレームおよびアカウント移行の記事に、正確な手順が記載されています。

ドメインクレームは任意であり、前提条件の後に来るのには理由があります。有効にするには、まず以下が整っている必要があります。これにより、アカウントが移動した後も、そのドメイン上の全員がサインインする手段を持てるようにします。

• ドメインが検証済みである
• 「組織作成を制限する」が有効になっている
• シングルサインオンが強制されている（設定されているだけでなく）
• プロビジョニングが稼働している

「組織作成を制限する」は、ドメインをクレームしない場合でも有効にする価値があります。これはドメインが検証されると利用可能になり、Claude Console組織を含め、誰もそのドメイン上で新しい個人アカウントや組織を作成できないようにします。

クレームを有効にする前に注意すべき点がいくつかあります。

• ドメイン上にいるがIDプロバイダーに登録されていない人は、クレームが開始されるとロックアウトされ、30日間のウィンドウが終了すると個人アカウントが無効化されます。そのため、クレームを開始する前にIDプロバイダーに追加しておいてください。
• この操作は元に戻せません。
• すでにそのドメイン上に個人アカウントを持っているメンバーには、クレームを開始した時点から30日間の移行ウィンドウが与えられます。
• 各メンバーは、既存の会話やプロジェクトを組織に持ち込むか、新規に始めるかを選択します。組織でHIPAA対応またはカスタマー管理の暗号鍵が有効になっている場合、新規に始めることのみが選択肢となり、個人アカウントからは何も移行されません。いずれの場合も、カスタムSkillsは個人アカウントの移行では引き継がれないため、保持したいものは移行前にエクスポートしておく必要があります。接続済みアプリの認可は取り消されるため、各アプリは各自の組織アカウントから再接続し、カスタムコネクタも組織のポリシーに従ってそこで再度追加する必要があります。その他の点については、ヘルプセンターの移行される内容の一覧を参照してください。ウィンドウが終了するまでに選択しなかった人は、デフォルトで新規に始めることになります。
• 元の個人アカウントは、いずれの場合も無効化されます。

ここでのあなたの役割は、この移行をできるだけスムーズに進めることです。クレームを開始する前に該当メンバーに事前通知し、古いアカウントがなくなった後になって初めて変更に気づく人がいないようにしましょう。以下の内容を共有することを検討してください。

HIPAA対応またはカスタマー管理の暗号鍵が有効になっている組織では、「選択すべきこと」を次のように置き換えてください。「個人アカウントからは何も移行されないため、必要なものは先に保存してください。」

Plutoの前提条件

前提条件が整った上で、Plutoはドメインクレームを有効にすることを選択しました。これが展開チームにとって唯一の本当のハードルでした。主にエンジニアからなる約40名のメンバーが、すでにPlutoのメールドメインでClaudeを使用していたためです（ITリードは、クレームを開始する2週間前に上記の通知を送付しました）。そして、30日間のウィンドウが終了するまでに、全員がPlutoの組織に移行しました。ID管理チームは最初の週にドメインを検証し、シングルサインオンを接続しました。管理者ロールはITリードが保持し、Primary Ownerロールは意図的に日常業務から外してCIOが保持しています。ID管理チームはプロビジョニングアプリも構築しました。直接割り当てられた2名のOwnerとグループの命名規則はITリードが担当し、請求責任者はCFOの代理人です。

セットアップ用リソース

以下の記事では、上記の基盤作業（SSO、プロビジョニング、ロールマトリックス、ドメインクレーム）を扱っており、個人アカウントを持つメンバーに表示される内容も含まれています。

• ドメイン上のアカウントをクレームして移行する: ドメインをクレームするための要件と手順。
• Claudeアカウントに対するEnterpriseドメインクレームへの対応: 個人アカウントを持つメンバーに表示される内容。事前通知の参考にしてください。
• 個人のClaudeアカウントをTeamまたはEnterprise組織に移行する: メンバーが移行する際に、Skills、接続済みアプリ、履歴がどうなるか。
• ロールと権限: 各組み込みロールの現在の権限マトリックス。
• シングルサインオン（SSO）を設定する: ドメインの検証とSSOの設定。ドメインをクレームする前に、設定するだけでなく強制する必要があります。
• JITまたはSCIMプロビジョニングを設定する: ドメイン上の全員がサインインできるように稼働させておく必要があるプロビジョニング。

レッスンの演習

以下のインタラクティブウィジェットでは、6つの前提条件を追跡できます。それぞれについて「整っている」か「まだ」かをマークし、結果をコンパニオンにコピーしてください。

6つの前提条件を順に確認し、それぞれについて2つの質問に答えてください。現在のステータスはどうなっているか、そして会社の誰がその完了を担当しているか。整っていないハードブロックや、担当者が決まっていない前提条件は、設定の決定を始める前に解決しておく必要があります。

→ これをワークアロング・コンパニオンのレッスン3セクションに記録してください。

次のステップ

次のモジュールでは、運用するClaude Enterprise組織の数を決定し、グループを設計します。