Claudeの統括組織を管理コンソールに登録する手順 — 元に戻せない承認フロー

Claude Enterpriseの統括組織(parent organization)専用の管理コンソールは、admin.claude.comで使えます。登録の手順がヘルプセンターに載りました。ベータ提供で、対象はEnterpriseプランです。

最初に知っておきたいのは、登録を取り消せないことです。しかも、設定を始めた人がすべての配下組織を管理しているなら、その場で登録が完了します。

11月5日の発表でこのコンソールが加わったこと自体は、Claude Enterpriseのセキュリティセンター新設を扱った記事の1節にあります。ここでは、登録前に決めること、登録後に何が移るか、ベータ中にできないことを掘り下げます。

登録の前に確かめる3つのこと

事前準備

登録前に決めておく事柄

• 統括組織のOwnerを誰にするか

  提案した人のうち、登録完了時にまだ資格のある全員が統括組織のOwnerになります。登録が終わる前に提案する管理者を変えると、全配下組織の承認がやり直しになります。登録後は、OwnerがAdmin rolesページで管理者を追加できます。

• テナント制限の許可リスト

  ネットワークでテナント制限を使っている場合、開始前に統括組織のIDを許可リストへ足します。後回しにすると、その回線から統括組織のコンソールを管理できません。

• 登録できる構成か

  HIPAAを有効にした配下組織がある統括組織は登録できません。配下がTeamプランだけの統括組織も同様です。

統括組織と配下組織の関係

用語は2つです。統括組織(親組織とも呼ばれます)は会社そのものと、Anthropicとの契約関係を表す単位です。IDプロバイダー、ドメイン検証、該当する場合はBAAなど、会社全体の設定がここに置かれます。配下組織(child organization)は、その下にある個別のClaude組織です。Claude Enterprise、Teamプラン、Anthropicから直接購入したClaude Platformの組織が当たります。

登録しても、配下組織は統合されません。それぞれが独立した組織のまま、ユーザー、ロール、プロジェクトを持ち、データの境界も保たれます。変わるのは、SSOやドメインなどの管理画面が統括組織側に集まる点です。SSOとSCIMを設定する前の準備は、SSOとSCIMの前提条件の記事にあります。

統括組織の役割と配下組織の管理者の分担

役割は統括レベルの2つと、配下組織の管理者に分かれます。

統括組織の役割は、配下組織への参加やサインインの権限にはなりません。統括組織のOwnerが配下組織の中で作業するには、ほかのユーザーと同じようにその組織へ追加される必要があります。

登録は取り消せない — 承認フローを順に追う

登録を始められるのは、統括組織の下にある配下組織のOwnerです。画面はadmin.claude.comになります。

手順

登録が完了するまでの流れ

1. 1

   admin.claude.comで設定を始める

   自分が管理している配下組織が一覧に出ます。

2. 2

   統括組織の管理者を提案する

   名前、メールアドレス、組織名で人を検索して選びます。候補に挙げられるのは、自分が管理している組織の所属者です。

3. 3

   残りの配下組織の承認を待つ

   設定を始めた時点で、自分が管理する組織の承認は済んだ扱いです。ほかの組織の管理者は、自分の組織から管理者を推薦して承認します。未承認の組織には督促を送れます。

4. 4

   Doneを選ぶ

   最後の承認で登録が完了し、コンソールがOrganizationsページで開きます。

注意が必要な点は3つあります。

• 配下のすべての組織を自分が管理している場合は、承認を待たずにその場で登録が完了します。取り消せないという警告は、この場合に特に重く効きます
• 提案する管理者を変えると、すべての配下組織に再承認が求められます
• 最後の変更から7日経っても承認しない組織があるときは、統括組織の下にあるいずれかの配下組織のOwnerが、その組織に代わって承認できます

最後の点は、承認者が不在でも登録が進むということです。逆に言うと、7日間反応のない組織を放置すると、その組織の管理者の意思と関係なく人選が確定する余地があります。未承認の組織には督促を送れるので、提案前に管理者へ直接伝えておくと待ち時間が読めます。

テナント制限を使う組織が先にやること

ネットワークでテナント制限を使っている場合、許可する組織IDの一覧(anthropic-allowed-org-idsヘッダー)に統括組織のIDを加えてから、設定を始めます。既存のIDは残します。

統括組織のIDを入れ忘れると、その回線上の統括組織のOwnerとAdminは、コンソールを管理できなくなります。統括組織のIDは、ClaudeのOrganization settings > Organization、またはConsoleのSettings > Organizationからコピーできます。登録後は、コンソールのGeneralページにもIDが出ます。

許可リストに入れる値は、次の3種類が揃っているかで確認できます。

1. すでに許可しているIDすべて
2. 管理している配下組織のID
3. 統括組織のID

ヘッダーの設定そのものは、テナント制限の設定記事にあります。

管理がどこへ移るか

登録後は、これまで配下組織の管理設定にあった次の項目を、統括組織のコンソールで一度に管理します。

配下組織の管理者に残るのは、ユーザー、ロール、組織設定、そしてIP許可リストやセッション期間といった組織レベルのセキュリティ設定です。IP許可リストは配下組織の管理設定に残ります。セッション期間も、ベータの間は配下組織ごとの設定です。

統括組織の管理画面は、これらの設定を足すだけでなく、複数のIDプロバイダーを1つの統括組織につなげる機能も加えます。ドメインごとに1つ以上のプロバイダーへ振り分けられ、同じドメインを複数のプロバイダーに分けるsplit domainsもあります。IdP側のSAMLとSCIMの設定は、Ping IdentityのSSO設定のような各IdPの手順で行います。

ドメインの割り当ては保存した時点で反映される

Domainsページでは、ドメインを追加して検証したうえで、SSOサインインの列から使うIDプロバイダーを選びます。保存するとサインインに即座に反映されます。IDプロバイダーを割り当てていないドメインには、SSOでのサインインがありません。

また、検証済みドメインは1つの統括組織にしか所属できません。コネクターの制限を有効にすると、企業外のClaudeアカウントが自社ドメインのメールでGoogle Drive、Gmail、Microsoft 365、Slackなどのコネクターをつなぐことを防げます。

Require SSOは、ClaudeとConsoleで別々のスイッチがあり、どちらもドメイン単位です。IDプロバイダーのページでも、Domainsページでも変更できます。

ドメインの引き取りも統括組織から始める

サイドメニューのSecurityページは、各組織のHIPAAの状態を一覧します。ドメインの引き取り(claim)も、配下組織の設定ではなく、ここから始めます。

引き取り先の配下組織を1つ選ぶと、その時点で検証済みのドメイン上の、Free、Pro、Max、Ultraのアカウントが対象になります。ユーザーはデータを持ち越すか選べますが、その後にサインインするには引き取り先の組織の席が必要です。

APIキーとCompliance APIの扱い

APIキーのページは、統括レベルのキーだけを並べます。1つの配下組織に限ったキーは、その組織の管理設定に残ります。キーは統括組織に属するため、作った人が組織から外れても有効なままです。

ページ上部のCompliance APIスイッチは、統括組織の下にあるすべての組織でCompliance APIを入れたり切ったりします。切っている間は、既存のキーでもcomplianceスコープが使えません。

手順

統括レベルのキーを作る手順

1. 1

   前提を満たす

   統括組織の下に、Claude Enterprise組織が最低1つ必要です。

2. 2

   Create keyを選んで名前とスコープを決める

   read:compliance_activitiesなどのcomplianceスコープが見えないときは、先にCompliance APIスイッチを入れます。これで、すべての配下組織のコンプライアンスイベントのログ記録も有効になります。グループ用のスコープはread:rbac_groupsとwrite:rbac_groupsです。

3. 3

   作成して、キーを控える

   delete:compliance_user_dataを持つキーは、配下のどの組織のデータも完全に削除できるため、作成の前に確認が入ります。キーは作成時にしか表示されません。

配下組織の管理者が作ったキーとの境界も押さえておく価値があります。

• 配下組織の管理者は、自分の組織に限ったキーを作れます。全組織で動くキーは作れず、無効にされたキーを戻すこともできません
• Claude Enterpriseの配下組織のプライマリオーナーは、read:org_auditやグループのスコープを持つキーを自組織向けに作れます。ただしこうしたキーは、統括組織のすべてのグループにアクセスします
• 1つの組織に限ったキーでは、サインインやRequire SSOの変更のような統括レベルのイベントを読めません。読むには、全組織で動くキーを使います
• 配下組織で作られた全組織向けのキーは、コンソールで組織名に警告アイコンが付きます。そのまま動き続け、統括組織側で管理できます

Compliance APIのオンオフをAPIから切り替える方法は、Compliance Settings APIの解説にあります。

ベータ中にできないこと

ヘルプセンターは、ベータの間の制限を次のように示しています。

グループの件は見落としやすい点です。グループの可用性機能がまだないため、Enterpriseの配下組織の管理者は、統括組織のすべてのグループを見られます。部署ごとに配下組織を分けている会社でも、グループの一覧は組織の壁を越えて見えます。

既存のEnterprise組織を統括組織の下に入れるには、アカウントチームへの連絡が必要です。セルフサービスで招待できるのは、検証済みドメインに属するClaude Platform組織とTeamプランです。

HIPAA構成そのものの制約は、HIPAA構成の適用前に確認することで扱っています。

11月5日の発表で足りなかった点

11月5日の発表で示されたのは、管理コンソールの概要と、管理者の提案から承認を経て最後の承認で完了し、元に戻せないという流れでした。ヘルプセンターの記事で加わったのは、配下組織を全部管理していれば承認なしで完了すること、承認の7日ルール、テナント制限の事前設定です。HIPAAやTeamのみの構成が登録できないこと、マーケットプレイス経由の組織が参加できないことも、ここで初めて具体的に書かれました。

まとめ

承認フローには7日経つと代理で承認できる仕組みがあります。配下組織の管理者が多い会社ほど、開始前に人選を合意しておく効果が大きくなります。