Claude Enterpriseでコネクタを制限し社外アカウントの接続を防ぐ設定

検証済みドメインのコネクタ制限(Restrict verified-domain connectors)とは

Restrict verified-domain connectors to your enterpriseは、組織が検証したメールドメインを使うコネクタ接続を、Enterprise組織内のClaudeアカウントだけに限定する設定です。オンにすると、社員が個人のClaudeアカウントに会社のGmailやSlackを接続しようとしても、その接続だけが失敗します。

想定する事故はよくある形です。ある社員が私用のClaudeアカウントと、会社のメールアドレスを使う業務アカウントの2つを持っているとします。設定がオフのままだと、私用アカウントにログインした状態でも会社のGmailを接続でき、業務データが組織の管理外に流出します。設定をオンにすれば、この接続は業務用のClaudeアカウントからしかできなくなります。

対象はコネクタ経由の接続のうち、後述する16サービスに限られます。コネクタの仕組み自体はClaude Connectorsとはで説明しています。

前提条件 — 設定できる人と組織の条件

この設定を変更できるのは、Owner・Primary Owner、またはIdentity & Access権限をManageに設定したカスタムロールのメンバーです。カスタムロールでの権限付与はClaude Enterpriseでカスタムロールを作成する手順で扱っている仕組みと同じです。Identity & Accessの権限だけを個別に渡すこともできます。

組織側の前提はもう1つあります。Enterprise組織が検証済みドメインを最低1つ持っていることです。ドメインを検証していない組織では、この設定自体が使えません。

設定は親組織の単位で管理し、子組織すべてに一括で適用されます。事業部ごとに別々の子組織を持つ構成でも、親組織で1回オンにすれば全体に効きます。

制限のオン・オフを切り替える手順

管理コンソールでの操作は3ステップです。

1. 設定画面を開く: 「Organization settings」→「Organization and access」に移動します
2. 該当項目を探す: 画面を「Connector domain restriction」までスクロールします
3. トグルをオンにする: 「Restrict verified-domain connectors to your enterprise」のトグルをオンにします

オンにした設定はいつでもオフに戻せます。この可逆性が、次に説明するドメインキャプチャとの一番大きな違いです。

対象になる16のコネクタ

制限が及ぶのは、次の16サービスへの接続だけです。

現在の対象リストは、管理コンソールの「Organization settings」→「Organization and access」でも確認できます。表に無いサービスを対象へ追加したい場合は、サポートチームへ依頼する窓口が用意されています。

この判定は仕組み上、対象サービス側がアカウントの身元情報(メールドメイン)を接続時にClaudeへ共有しているかどうかに依存します。共有される場合はドメインを照合して制限を適用し、共有されない場合はチェックそのものができず、接続はそのまま通ります。一部のCanva Education(.edu)アカウントのように、身元情報を渡さないケースがあることも公式に明記されています。判定できないときは、遮断ではなく許可に倒れる仕組みです。

制限をかけても変わらないこと

この設定には、名前から連想しやすい誤解が4つあります。

まず、制限は一方向にしか効きません。設定をオンにしても、Enterprise組織のメンバーが私用サービスを自分の業務アカウントへ接続すること自体は止まりません。個人のGmailを業務アカウントに接続する使い方は、オンのままでも変わらず可能です。

次に、この設定はDLP(データ損失防止)の代替にはなりません。想定しているのは、間違ったアカウントへうっかり接続してしまう事故の防止で、悪意を持ってデータを持ち出す行為への統制ではありません。

3つ目は、既存の接続には遡って効かないことです。制限は新規の接続試行だけに適用され、設定をオンにする前から接続済みのサービスは、そのままつながり続けます。

最後に、管理者への通知はありません。接続がブロックされたとき、その事実を知るのは操作した本人だけです。管理者側のログや通知でこの遮断を後から追跡する仕組みは無いため、社内での運用ルールとして「ブロックされたら情報システム部門へ連絡する」といった手順を別に決めておく必要があります。

接続がブロックされたときに何が起きるか

制限に触れた接続は、サインインの時点で失敗します。画面には次のメッセージが表示されます。

This corporate identity belongs to an Enterprise that manages access through their own Claude account. Sign in to your organization's Claude account to use this connection.

対処はメッセージのとおりで、組織のClaudeアカウントにサインインし直してから同じ接続をやり直します。組織のClaudeアカウントを持っていない場合は、自分の管理者にアカウント発行を依頼します。

ドメインキャプチャ・一括認証との違い

似た名前の管理者設定が並ぶため、対象を混同しやすい領域です。次の早見表で役割を分けます。

ドメインキャプチャは、Claudeのドメインキャプチャ一括移行を管理者が設定する手順で扱っているとおり、検証済みドメイン上に残っている個人のClaudeアカウントをEnterprise組織へ強制的に統合する機能です。アカウントの所属そのものが変わり、一度実行すると元に戻せません。対して本記事の設定は、アカウントの所属には一切触れず、新しいコネクタ接続だけを制限します。この違いは公式のFAQでも明示されています。

Enterprise-managed authは軸がさらに異なります。Claude Enterpriseでコネクタを一括認証する設定手順で扱っているのは、メンバー1人ずつの手動認証をIDプロバイダー経由で省略する仕組みです。接続を制限する機能ではなく、認証の手間を減らす機能にあたります。両者は制御する対象が異なります。

コネクタ接続にもともと備わっている制御

検証済みドメイン制限は、コネクタが持つ既存のセキュリティ設計に重ねる追加の層です。コネクタはユーザーごとに接続先サービスの権限を引き継ぐ仕組みで、あるファイルやチャンネルを元のサービスで閲覧できない人は、Claude経由でも閲覧できません。

Team・Enterpriseプランでは、この権限継承がユーザー単位でさらに強制されます。管理者がコネクタを組織に対して有効化しても、各メンバーは自分のアカウントで接続先サービスに個別認証するまで使えるようにはなりません。加えて、コネクタは非公開のプロジェクト内でしか使えず、同期した内容を含むチャットは共有もできません。検証済みドメイン制限は、この個人単位の権限継承の外側で「そもそもどのアカウントに接続してよいか」を組織側から縛る設定にあたります。

もう1点、混同しやすいのがデータの所在地です。接続先サービスは自社のインフラ・自社の規約のもとでデータを処理しており、その場所はアメリカ国外になることもあります。EnterpriseプランのUS-only inference設定のように、Claude自体の推論をどこで実行するかを決める設定を入れていても、接続先サービス側の処理場所までは変わりません。検証済みドメイン制限は接続元アカウントを絞る設定であって、接続先サービスのデータ所在地を統制する設定ではない点は分けて理解しておく必要があります。

まとめ

Restrict verified-domain connectorsは、社外のClaudeアカウントが会社のメールドメインでコネクタに接続することを防ぐ設定です。オンにできるのはOwner・Primary Owner、またはIdentity & AccessをManageにしたカスタムロールで、検証済みドメインを持つEnterprise組織が対象になります。

対象は16の主要SaaSコネクタへの新規接続に限られ、既存の接続や、社員が私用サービスを業務アカウントへ接続する逆方向の操作までは制限しません。悪意ある持ち出しを防ぐDLPでもない点を踏まえたうえで、社外への接続経路を1つ塞ぐ設定として導入を検討する価値があります。