Claude Enterpriseでコネクタを制限し社外アカウントの接続を防ぐ設定
Claude Enterpriseの検証済みドメイン設定は、社外のClaudeアカウントへ業務用Gmail・Slackなどを接続させません。手順と制限が及ばない範囲をまとめます。
検証済みドメインのコネクタ制限(Restrict verified-domain connectors)とは
Restrict verified-domain connectors to your enterpriseは、組織が検証したメールドメインを使うコネクタ接続を、Enterprise組織内のClaudeアカウントだけに限定する設定です。オンにすると、社員が個人のClaudeアカウントに会社のGmailやSlackを接続しようとしても、その接続だけが失敗します。
想定する事故はよくある形です。社員が私用のClaudeアカウントと、会社のメールアドレスを使う業務アカウントの2つを持っている場合を考えます。
会社のGmailを私用アカウントから接続すると
設定がオフ
私用アカウントにログインした状態でも会社のGmailを接続できます。業務データが組織の管理外に移ります。
設定がオン
私用アカウントからの接続は失敗します。業務アカウントからなら、同じGmailを今までどおり接続できます。
対象はコネクタ経由の接続のうち、後述する16サービスに限られます。コネクタの仕組み自体はClaude Connectorsとはで説明しています。SlackやMicrosoft 365を組織の横断検索に使う設定は、ClaudeのAsk Your Orgにあります。端末管理の接続例はClaudeとAutomoxの連携です。
前提条件 — 設定できる人と組織の条件
この設定を変更できるのは、Owner・Primary Owner、またはIdentity & Access権限をManageに設定したカスタムロールのメンバーです。カスタムロールでの権限付与はClaude Enterpriseでカスタムロールを作成する手順で扱っている仕組みと同じです。Identity & Accessの権限だけを個別に渡すこともできます。
組織側の前提はもう1つあります。Enterprise組織が検証済みドメインを最低1つ持っていることです。ドメインを検証していない組織では、この設定自体が使えません。
設定は親組織の単位で管理し、子組織すべてに一括で適用されます。事業部ごとに別々の子組織を持つ構成でも、親組織で1回オンにすれば全体に効きます。
制限のオン・オフを切り替える手順
管理コンソールでの操作
- 1
設定画面を開く
「Organization settings」→「Organization and access」に移動します。
- 2
該当項目を探す
画面を「Connector domain restriction」までスクロールします。
- 3
トグルをオンにする
「Restrict verified-domain connectors to your enterprise」のトグルをオンにします。
オンにした設定はいつでもオフに戻せます。この可逆性が、次に説明するドメインキャプチャとの一番大きな違いです。会社ネットワークの出口で使えるアカウントを絞る方法はClaudeのテナント制限にあります。
対象になる16のコネクタ
制限が及ぶのは、次の16サービスへの接続だけです。
| 対象コネクタ |
|---|
| Airtable / Asana / Atlassian / Canva |
| Figma / Gmail / Google Calendar / Google Drive |
| HubSpot / Linear / Microsoft 365 / Miro |
| Notion / Slack / Smartsheet / Tableau |
現在の対象リストは、管理コンソールの「Organization settings」→「Organization and access」でも確認できます。表に無いサービスを対象へ追加したい場合は、サポートチームへ依頼する窓口が用意されています。
判定は、接続先サービスがアカウントの身元情報(メールドメイン)を接続時にClaudeへ共有するかどうかに依存します。共有されればドメインを照合して制限を適用し、共有されなければチェックができず接続はそのまま通ります。一部のCanva Education(.edu)アカウントがその例です。判定できないときは、遮断ではなく許可に倒れる仕組みです。
制限をかけても変わらないこと
この設定には、名前から連想しやすい誤解が4つあります。
まず、制限は一方向にしか効きません。設定をオンにしても、Enterprise組織のメンバーが私用サービスを自分の業務アカウントへ接続すること自体は止まりません。個人のGmailを業務アカウントに接続する使い方は、オンのままでも変わらず可能です。
次に、この設定はDLP(データ損失防止)の代替にはなりません。想定しているのは、間違ったアカウントへうっかり接続してしまう事故の防止で、悪意を持ってデータを持ち出す行為への統制ではありません。
3つ目は、既存の接続には遡って効かないことです。制限は新規の接続試行だけに適用され、設定をオンにする前から接続済みのサービスは、そのままつながり続けます。
最後に、管理者への通知はありません。ブロックされたとき、その事実を知るのは操作した本人だけです。社内の運用として「ブロックされたら情報システム部門へ連絡する」といった窓口を別に決めておく選択肢があります。
自社の状況に当てはめると、止まる接続と止まらない接続は次のように分かれます。
| 接続の状況 | 制限の効き方 |
|---|---|
| 検証済みドメインのメールで、私用Claudeアカウントから16サービスに接続 | 制限の効き方止まる |
| 同じ接続を、組織内の業務アカウントから行う | 制限の効き方止まらない |
| 16サービス以外への接続 | 制限の効き方対象外で止まらない |
| 身元情報を共有しないサービス(一部のCanva Educationなど) | 制限の効き方判定できず止まらない |
| 設定をオンにする前から接続済みのサービス | 制限の効き方切断されない |
| 私用メールのGmailを業務アカウントへ接続 | 制限の効き方止まらない |
接続がブロックされたときの表示と確認方法
制限に触れた接続は、サインインの時点で失敗します。画面には次のメッセージが表示されます。
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アカウントから会社のメールアドレスでGmailなど対象のコネクタを接続してみると、効いているかを試せます。同じ接続を業務アカウントから行えば、通常どおり通ります。
対象外のはずのサービスで止まったという問い合わせは、16サービスの一覧と、管理画面の「Organization and access」にある現在のリストを照らして切り分けます。過去に接続した記憶があるのに止まったという相談は、止まったのが新規の接続試行だったと考えれば説明がつきます。
ドメインキャプチャ・一括認証との違い
似た名前の管理者設定が並ぶため、対象を混同しやすい領域です。次の早見表で役割を分けます。
| 設定名 | 制御する対象 | 元に戻せるか |
|---|---|---|
| 検証済みドメインのコネクタ制限(本記事) | 制御する対象社外アカウントからの新規コネクタ接続 | 元に戻せるか可能 |
| ドメインキャプチャ | 制御する対象ドメイン上の個人アカウントそのものの所属 | 元に戻せるか不可 |
| Enterprise-managed auth(ベータ) | 制御する対象コネクタの認証作業そのものの一括化 | 元に戻せるか―(本記事の対象外) |
ドメインキャプチャは、Claudeのドメインキャプチャ一括移行を管理者が設定する手順で扱っているとおり、検証済みドメイン上の個人のClaudeアカウントをEnterprise組織へ移す機能です。アカウントの所属そのものが変わり、有効にすると元に戻せません。対して本記事の設定は、アカウントの所属には一切触れず、新しいコネクタ接続だけを制限します。
Enterprise-managed authは軸がさらに異なります。Claude Enterpriseでコネクタを一括認証する設定手順で扱っているのは、MCPコネクタを組織として1回認可し、メンバーが初回ログインで利用権限を引き継ぐ仕組みです。接続を制限する機能ではなく、認証の手間を減らす機能にあたります。
組織のコネクタ管理で設定が分かれる3か所
コネクタまわりの管理設定は、画面も効く場面も別々に用意されています。「社外アカウントの接続を止めたい」のか「Claudeの操作範囲を絞りたい」のかで、触る場所が変わります。
| 目的 | 設定の場所 | 効く場面 |
|---|---|---|
| 使えるコネクタを組織に出す | 設定の場所「Organization settings」→「Connectors」→「Browse connectors」→「Add to your team」 | 効く場面有効化しても、各メンバーが個別に認証するまで使えない |
| 社外アカウントからの接続を止める | 設定の場所「Organization settings」→「Organization and access」 | 効く場面検証済みドメインのメールで行う、16サービスへの新規接続 |
| コネクタの操作範囲を絞る | 設定の場所「Customize」→「Connectors」→「Tool permissions」 | 効く場面接続した後の読み取り・書き込み・削除 |
有効化の画面は、OwnerまたはPrimary Ownerが操作します。3つを重ねると、使えるコネクタ、接続できるアカウント、接続後にできる操作を別々の層で決められます。
アクション制限には、接続先サービス側の権限との関係にも決まりがあります。Claudeで書き込みを許可しても、接続先で書き込む権限を持たない人は変更できません。Claude側の制限は接続先の権限を広げず、狭めるだけです。たとえばGoogle Driveで「読むだけ」に絞りたいときは、Tool permissionsで書き込み・削除系を「Blocked」にします。メール送信だけを止めて検索と要約は残す、といった分け方も同じ画面でできます。
コネクタ接続にもともと備わっている制御
検証済みドメイン制限は、コネクタが持つ既存のセキュリティ設計に重ねる追加の層です。コネクタはユーザーごとに接続先サービスの権限を引き継ぐ仕組みで、あるファイルやチャンネルを元のサービスで閲覧できない人は、Claude経由でも閲覧できません。
Team・Enterpriseプランでは、管理者がコネクタを組織に対して有効化しても、各メンバーは自分のアカウントで接続先サービスに個別認証するまで使えません。共有の認証情報を使うコネクタは例外で、その認証情報が届く範囲すべてに触れられます。加えて、コネクタは非公開のプロジェクト内でしか使えず、同期した内容を含むチャットは共有できません。検証済みドメイン制限は、これらの外側で「そもそもどのアカウントに接続してよいか」を組織側から縛る設定にあたります。
もう1点、混同しやすいのがデータの所在地です。接続先サービスは自社のインフラ・自社の規約のもとでデータを処理しており、その場所はアメリカ国外になることもあります。EnterpriseプランのUS-only inference設定のように、Claude自体の推論をどこで実行するかを決める設定を入れていても、接続先サービス側の処理場所までは変わりません。検証済みドメイン制限が絞るのは接続元アカウントで、接続先サービスのデータ所在地は変わりません。
まとめ
私用アカウント経由の誤接続を塞ぐ設定として、Owner、またはIdentity & AccessをManageにしたカスタムロールがオンにできます。ただし接続済みのサービスと身元情報を共有しないサービスは対象外のため、既存の接続の棚卸しや情報の持ち出し対策は別の手段で組む前提になります。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。