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

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

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

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

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

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

管理者が「Linearの書き込み系操作をAlways allowにしたのに更新できない」と困る場面があります。原因は多くの場合、Claude側の設定ではなく元サービス側の権限です。接続した本人がそのプロジェクトへの書き込み権限をLinear側で持っていなければ、Claude側でどれだけ許可を広げても操作は失敗します。

対策はシンプルです。Claude側で操作が失敗したら、先に元サービス側の権限を確認します。Action restrictionはあくまで「Claudeに許す範囲を狭める」機能であり、「元サービスにできないことをさせる」機能ではありません。

同じ構図はGoogle Driveでも起きます。「ファイルを編集できない」という報告の原因が、Claude側の設定ではなく、そもそも本人がそのファイルへの編集権限を持っていなかった、という例は珍しくありません。切り分けの順序は共通です。先にClaudeの外で同じ操作を試し、元サービス側で成功するかどうかを確かめてから、Claude側の設定を疑います。

失敗2: 組織の権限制限を個人がChatで上書きできると誤解する

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

逆方向の失敗もあります。個人が「この接続先は毎回確認したい」と思って慎重に運用しているつもりでも、組織側でその操作カテゴリーがAlways allowに設定されていれば、確認なしで実行されます。個人の体感と実際の挙動がずれるのは、組織設定が優先されるからです。設定を確認する際は、自分のチャット画面の表示だけでなく、組織設定側の値を照合する必要があります。

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

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

Enterprise-managed authを使えば、この個別認証を省略できます。Okta等のIDプロバイダー経由で組織として一度だけ認可し、対象ロールのメンバーは初回ログイン時に自動でアクセス権を引き継ぎます。設定の具体的な手順はClaude Enterpriseでコネクタを一括認証する設定手順にまとめています。ただし対象ロールを絞ってパイロット導入することもでき、その場合はロール未対象のメンバーには適用されません。ロール未対象のメンバーは、Managed authorizationが失敗したときと同じ経路でブラウザー個別サインインを求められます。パイロット中の組織で「一部の人だけ求められる個別ログインが直った/直っていない」という報告が食い違う場合、対象ロールの設定範囲を先に確認します。

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

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アカウントにサインインし直してから同じ接続をやり直すことです。組織にアカウントが無い場合は管理者に相談します。この制限は失敗した本人にだけ表示され、管理者への通知は飛びません。事前に社内へ周知しておかないと、原因不明のエラーとして個別に問い合わせが積み上がります。

制限は新規の接続試行にだけ働き、設定をオンにする前にできていた接続は遡って切断されません。逆方向(組織アカウントで個人用のGmailを接続する)も制限しないため、データ持ち出しの完全な防止策ではなく、誤接続を防ぐ安全策と位置づけるのが実態に近い理解です。

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

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

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

よくある質問

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

いいえ。アクション制限(読み取り専用/書き込み・削除のカテゴリー別制御)はTeam・Enterpriseプランの機能で、個人アカウントには相当する設定がありません。個人利用では、接続先ごとにChatから有効・無効を切り替えるか、Customizeから接続そのものを解除する形になります。

書き込み系ツールをBlockedにすると、読み取り系にも影響しますか

影響しません。読み取り専用と書き込み・削除は別カテゴリーとして管理されており、片方をBlockedにしてももう片方の設定は独立して維持されます。

検証済みドメイン制限は既存の接続にも遡って適用されますか

されません。設定をオンにした時点より後の新規接続試行だけが対象で、それ以前に成立していた接続は維持されます。

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

対象ロールに含まれるメンバーであれば基本的に出ません。ただしBrowser sign-inとManaged authorizationは併用可能な設定で、Managed authorization側が失敗した場合はメンバーに個別サインインを求めるフォールバックが働きます。IDプロバイダー側の障害時にロックアウトしないための設計です。

まとめ

Connectorsの権限設定でつまずく多くは、「接続先での本人権限」と「組織のアクション制限」という独立した2層を1つの設定だと思い込むことに起因します。Claude側の許可は元サービスの権限を超えて広げることはできず、組織の制限は個人設定より優先されます。組織で有効化した接続先も、メンバー個別の認証が済むまでは使えません。配布前にこの3点を確認しておくだけで、問い合わせの多くは未然に防げます。Connectorsの基本的な追加手順や種類はClaude Connectorsとは、Coworkでの承認モードや組織設定はClaude CoworkのConnectors一覧にまとめています。接続そのものがうまくいかないときの切り分けはMCPサーバーに接続できないときの切り分け手順にまとめています。