Claude Connectorsの権限設定でよくある失敗と対策

Connectorsの権限はどの2層で決まるか

Connectorsの権限は、個人の権限と組織の権限という2つの層が独立して重なる設計です。この2層を分けて理解しないと、設定したはずの制限が効かない、あるいは許可したはずの操作が動かない、という食い違いに直面します。

1層目は接続先での本人権限です。Claudeは接続した本人がその外部サービスで持つ権限を継承するだけで、権限そのものを拡張しません。自分が閲覧できないファイルやチャンネルには、Claudeを介してもアクセスできません。

2層目は組織のアクション制限です。Team・EnterpriseプランのOwnerは、接続先ごとにClaudeが使えるツールを制限できます。ツールは「読み取り専用」と「書き込み・削除」のカテゴリーに分かれて表示されます。カテゴリーごと、あるいはツール単位で、「Always allow(常に許可)」「Needs approval(要承認)」「Blocked(禁止)」の3段階から選びます。設定は「Customize > Connectors」から対象の接続先を選び、「Tool permissions」で行います。

操作が通らないとき、どの順で疑うか

「Claudeから操作できない」という報告は、原因の層が違っても同じ見え方になります。次の順に確認すると、どの層の問題かを絞り込めます。

手順

操作が失敗したときの切り分け順

1. 1

   Claudeの外で同じ操作を試す

   元のサービスの画面で、同じ本人が同じ操作を試します。ここで失敗するなら、原因は1層目(本人権限)で、Claude側の設定をいくら触っても直りません。

2. 2

   その接続先を本人が認証済みか見る

   Team・Enterpriseでは、組織で有効化しただけでは誰もアクセスできません。個別認証が済んでいるか、Enterprise-managed authの対象ロールに入っているかを確認します。

3. 3

   組織のTool permissionsを確認する

   該当ツールのカテゴリーがBlockedやNeeds approvalになっていないかを、Customize > Connectorsで見ます。個人のチャット画面では上書きできません。

4. 4

   接続時のエラー文言を読む

   接続そのものが失敗するなら、権限ではなく検証済みドメインの制限が原因かもしれません。メッセージの文面は失敗5で扱います。

失敗1: Claude側の許可が元サービスの権限を上書きすると思い込む

管理者が「Linearの書き込み系操作をAlways allowにしたのに更新できない」と困る場面があります。原因は、接続した本人がそのプロジェクトへの書き込み権限をLinear側で持っていないことが典型です。Google Driveでも同じで、編集できない原因が本人のファイル権限にあるなら、Claude側の設定は無関係です。

Claudeの外で同じ操作が成功するかを先に確かめると、Claude側の設定を疑う前に原因の層を切り分けられます。

失敗2: 共有の認証情報を使うカスタムコネクターで、本人権限が効くと思い込む

「本人の権限を継承する」という説明には、公式ヘルプセンターに明記された例外があります。共有の認証情報を使うカスタムコネクターは、その認証情報がアクセスできる範囲すべてに届きます。

たとえばカスタムコネクターの設定(Request headers)にAPIキーを固定し、Claudeが毎回のリクエストで送る構成です。接続者全員が同じキーを使うこの構成では、誰が呼び出しても接続先から見えるのは同じ1つの認証情報なので、メンバーごとの権限差は接続先に伝わりません。メンバーごとに見えるものを変えたい用途では、この構成が前提を崩します。

ヘルプセンターは、Team・Enterpriseで個別認証が必要になる条件にも「共有認証情報を使うコネクターを除く」と書いています。個別認証の周知を考えるときも、接続先の認証方式を先に確認します。

Claude側のアクション制限は、この構成でも有効です。読み取りだけを許したいなら、Tool permissionsで書き込み・削除のカテゴリーをBlockedにして、共有認証情報の到達範囲を実際の操作の面から狭められます。

失敗3: 組織の権限制限を個人がチャットで上書きできると誤解する

Team・Enterpriseプランでは、Ownerが設定したアクション制限は組織全体に適用され、個人がチャット画面から上書きすることはできません。たとえばOwnerがLinearの「新規issue作成」をBlockedに設定していれば、メンバー個人がどれだけ許可を試みても、その操作はブロックされたままです。

個人が「この接続先は毎回確認したい」と慎重に運用しているつもりでも、実際の挙動は組織設定の値で決まります。

設定を確認するときは、自分のチャット画面の表示だけで判断しないでください。組織設定側の値と照らし合わせます。

失敗4: 組織で有効化しただけで全員が使えると思い込む

Team・Enterpriseプランでは、Connectorを組織に追加しても、それだけでは誰も使える状態になりません。Owner・Primary Ownerが有効化した後、メンバー1人ずつが個別に認証を済ませて初めて使えるようになります。管理者が「有効化したのに使えない」という問い合わせを受けたら、まず個別認証が済んでいるかを見ます。

有効化の画面は「Organization settings > Connectors」で、アクション制限を設定する「Customize > Connectors」とは別の場所です。有効化の入口とアクション制限の入口を取り違えると、設定したのに反映先が違う、という行き違いになります。

Enterprise-managed authで個別認証を省く場合

Enterprise-managed authを使えば、この個別認証を省略できます。IDプロバイダー経由で組織として一度だけ認可し、対象ロールのメンバーは初回ログイン時に自動でアクセス権を引き継ぎます。設定の具体的な手順はClaude Enterpriseでコネクタを一括認証する設定手順にまとめています。

導入前に押さえておく条件が3つあります。

• 対応するIDプロバイダーは、専用ヘルプページの記載ではOktaです(ほかは対応予定の扱い)
• 対応コネクターは、Asana・Atlassian・Canva・Datadog・Figma・Granola・Linear・Notion・Slack・Supabaseの10種です
• ロールの選択は、組み込みロール(User・Admin・Owner・Primary owner)をまとめて1つの選択肢として扱い、カスタムロールは1つずつ選びます

特定のチームだけで試すなら、そのチームのカスタムロールだけを選び、組み込みロールのチェックは外したままにします。この場合、組み込みロールのメンバーは、チェックを入れ直すまでそのコネクターを自動では受け取りません。

パイロット中に「一部の人にだけコネクターが届かない」という報告が出たら、Applied rolesに誰が入っているかを先に見ます。

権限の面では、設定のScopesステップで、IDプロバイダー経由の接続時にClaudeが要求できる権限を選べます。この選択は、選んだすべてのロールに適用されます。特定のロールだけ権限を絞りたいときは、そのロールのConnectorsタブで調整します。

カスタムロールのConnectorsタブには「How members connect」の設定もあります。選択肢はIndividually、Managed authorization、コネクターごとの個別指定(Set per connector)です。個別サインインが出る理由を切り分けるときは、この設定も見ます。

なお、ヘルプセンターの総合ページはEnterprise-managed authを「ベータ」と書き、専用ページは「一般提供」と書いています。ページ同士で段階の表記が食い違っているので、導入判断の材料にするなら専用ページの記載と実際の画面の表示を合わせて見る必要があります。

失敗5: 検証済みドメインの制限で接続だけがブロックされる

Enterpriseプランには、検証済みドメインのメールアドレスを使った接続を自組織のClaudeアカウントに限定する設定があります。この設定がオンの状態で、個人のClaudeアカウントに会社の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アカウントから、対象コネクターを新規に接続しようとしたとき。

素通りする

働かない

設定をオンにする前から続く既存の接続、組織アカウントでの個人用Gmailの接続、接続先がアカウントの身元情報を返さない場合。

つまり、データ持ち出しを防ぐ仕組みではなく、誤接続を防ぐ安全策です。ヘルプセンター自身も、データ損失防止の代わりにはならないと書いています。

「働かない」側のうち、身元情報が共有されない場合の例として、ヘルプセンターは一部のCanva Education(.edu)アカウントを挙げています。制限を評価できない接続は、ブロックされずにそのまま許可されます。

そのほかの条件は次のとおりです。

• 設定できるのは、Owner、Primary Owner、そして「Identity & Access」権限をManageにしたカスタムロールです
• 組織には検証済みドメインが1つ以上必要です
• 設定は親組織で管理し、子組織すべてに適用されます
• 対象は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」の「Connector domain restriction」です
• いつでもオフにでき、元に戻せないドメイン取得(domain capture)とは別の設定です

対象外のコネクターに同じ制限をかけたい場合は、サポートへの追加依頼が必要です。

権限設定を配る前に確認すること

組織で権限設定を配布する前に、次の点を確認しておくと失敗を未然に防げます。

• 接続先の各ツールが「読み取り専用」と「書き込み・削除」のどちらに分類されているかを、実際に設定画面で確認する
• Always allowに設定する操作は、元サービス側でも本人が実行権限を持っているか確認する
• カスタムコネクターの認証方式が共有認証情報なら、到達範囲を認証情報の側で絞れているか確認する
• 組織で有効化した接続先について、個別認証が必要な旨をメンバーへ周知する
• Enterprise-managed authを段階導入する場合、Applied rolesの範囲を明示し、対象外のメンバーはそのコネクターを自動では受け取らない旨を伝える
• 検証済みドメイン制限をオンにする場合、失敗時のメッセージ内容とサインイン先の切り替え方を事前に共有する

補足: チームのプロジェクトとの関係

ヘルプセンターは、Team・Enterpriseの注意点として、コネクターは非公開のプロジェクトでだけ使えること、同期した内容を含むチャットは共有できないことも挙げています。権限の設定とは別の制約です。

よくある質問

個人アカウントでも組織と同じような権限制限をかけられますか

アクション制限の手順は、Team・EnterpriseのOwner向けに書かれています。個人利用でヘルプセンターに載っているのは、Customize > Connectorsで各サービスを切断することと、接続設定や権限・アクセスレベルを確認することです。削除系と送信系の割り当て例はClaudeとMailerLiteの連携で扱っています。

Enterprise-managed authを設定すれば、個別のサインイン画面は二度と出ませんか

対象ロールに含まれるメンバーなら、管理者がBrowser sign-inも同時にオンにしていない限り、フォールバックの個別サインインは出ません。両方がオンのときは、Managed authorizationが失敗するとメンバーに個別サインインが求められます。IDプロバイダー側の障害時にロックアウトしないための設計です。

まとめ

本人権限と組織のアクション制限は別々の設定で、片方をいじってももう片方は変わりません。Connectorsの基本的な追加手順や種類はClaude Connectorsとは、Coworkでの承認モードや組織設定はClaude CoworkのConnectors一覧にまとめています。接続そのものがうまくいかないときの切り分けはMCPサーバーに接続できないときの切り分け手順にまとめています。