Claude Enterpriseでコネクタを一括認証する設定手順

Enterprise-managed authとは何か

Connectorsは通常、メンバー1人ずつが自分でOAuth認証して使い始めます。人数が多い組織では、この個別認証がそのまま導入の遅れになります。Enterprise-managed authは、この認証を管理者側で一度に済ませる仕組みです。組織のIDプロバイダーを通じてコネクタへのアクセスを中央管理し、メンバーは初回ログイン時に権限を自動で引き継ぎます。

管理者が制御できる項目は5つです。コネクタの有効・無効、ロールベースの権限付与、Claudeが要求できる権限スコープの選択、IDプロバイダー側からのアクセス取り消し、そしてIDプロバイダー経由の接続の強制です。個人が1件ずつ認証ボタンを押す運用から、管理者がロール単位で配布する運用に切り替わります。Connectorsの種類やプラットフォームごとの対応状況はClaude Connectorsとはで先に押さえておくと、本記事の手順がどこに位置づくかが分かりやすくなります。

対応コネクタと前提条件

Enterprise-managed authが対応するコネクタは8つです。

前提として、OktaでのSSO設定が済んでいる必要があります。SSOとSCIMプロビジョニングの基本的な組み方は、Claude CoworkのRBAC運用に近い設計思想なので、Claude CoworkのRBAC運用のSSO・SCIM節が参考になります。ここでの設定はコネクタの認証に限った話で、組織全体のロール権限そのものを再設計する話ではありません。

一括認証を設定する手順

管理コンソールでの設定は6ステップです。

1. 設定画面を開く: 「Organization settings」→「Connectors」で対象のコネクタを選び、「Configuration」タブの「Managed authorization」横にある「Set up」をクリックします
2. IDプロバイダー接続を確認する: 「Connect」ステップでIDプロバイダーとの接続状態を確認し、必要なら「Run test」で疎通を確認します
3. 対象ロールを選ぶ: 「Roles」ステップで、User・Admin・Owner・Primary Ownerといった組織の標準ロール、またはカスタムロールを個別に選びます
4. 権限スコープを決める: 「Scopes」ステップで、Claudeがそのコネクタに要求できる権限の範囲を選びます
5. 設定を保存する: 「Save & turn on」をクリックすると設定が有効になります
6. 反映を確認する: 「Configuration」タブに戻ると、適用済みのロール(Applied roles)と権限(Scopes)が表示されます

最初から全社員を対象ロールに含めると、設定ミスの影響範囲が広がります。パイロット導入では、Step 3で特定チームのカスタムロールだけを選び、標準ロール(User・Admin等)はチェックしない進め方が安全です。数週間動かして問題が無ければ、対象ロールを広げていく順序が現実的です。

カスタムロールごとに接続方法を分ける

一括認証を全社一律にする必要はありません。「Organization settings」→「Roles」のカスタムロールにある「Connectors」タブから、ロールごとに接続方法を選べます。

エンジニアリング部門はFigmaやSupabaseをManaged authorizationにして即座に使える状態にし、それ以外の部門はIndividuallyのまま必要な人だけ個別認証する、といった組み合わせができます。特定ロール向けに権限スコープを絞りたい場合は、そのロールのConnectorsタブから個別に設定します。

個人認証との共存とフォールバック

Enterprise-managed authを有効にしても、通常のブラウザーサインインによる個人認証(Browser sign-in)は無効になりません。2つの認証経路は同時に有効化でき、IDプロバイダー側で障害が起きた場合は個人サインインにフォールバックできます。業務を止めないための保険として、この共存は残しておく価値があります。

個人用に別のアカウントで使いたいコネクタは、Managed authorizationの対象とは別に、メンバー本人が追加で設定できます。トークンの有効期限やライフサイクルの管理は、接続先の認可サーバーとIDプロバイダー側が担い、Anthropic側でアクセス可否やデータの範囲を制御しているわけではありません。アクセス決定とデータスコープの最終的な制御は、あくまでIDプロバイダーと接続先サービスに委ねられています。

メンバーが離脱したときのアクセス取り消し

Managed authorizationの利点は、認証を一括で配れることだけではありません。取り消しも一括でできる点が、個人認証との大きな違いです。個人認証の場合、退職や異動のたびにClaude側でメンバーを削除しても、接続先サービス側のトークンが別途残っていないかを個別に確認する手間が発生しがちです。

Managed authorizationでは、アクセスの可否がIDプロバイダー側のグループ所属に紐づきます。退職者をOkta側のグループから外すだけで、そのメンバーが持っていたコネクタへのアクセスも合わせて失効します。情報システム部門がオフボーディングの手順を1本化できる点は、コネクタを多く配布している組織ほど効いてきます。

導入判断の早見表

どの範囲から始めるかは、組織の規模と対象コネクタの重要度で変わります。

よくあるつまずき

Managed authorizationの対象ロールにメンバーを追加し忘れると、そのメンバーだけが従来通り個人認証を求められます。ロール設計とEnterprise-managed authの対象範囲がずれていないか、導入後に代表メンバーで動作確認しておくと手戻りが減ります。

対応コネクタは8つに限られているため、業務で使いたいコネクタが対応していないケースもあります。その場合はIndividually(個人認証)のまま運用するか、対応拡大を待つことになります。対応コネクタの一覧は今後増える可能性があるため、導入前に最新の対応状況を確認しておくのが確実です。

よくある質問

Managed authorizationはCoworkにも適用されますか

Enterprise-managed authはConnectorsの認証方式を変える設定であり、本記事で扱う対象もConnectorsの認証範囲に限られます。Coworkでの接続先の扱いや承認モードについてはClaude CoworkのConnectors一覧で個別に扱っています。

Okta以外のIDプロバイダーは使えますか

立ち上げ時点で対応しているIDプロバイダーはOktaのみです。他のプロバイダーへの対応は今後の展開として案内されていますが、時期は明言されていません。

一度設定した対象ロールは後から変更できますか

「Configuration」タブから同じ設定フローを開き直すことで、対象ロールや権限スコープを変更できます。変更時も、まず一部のロールで動作確認してから範囲を広げる進め方が安全です。

Teamプランでも使えますか

Team・Enterpriseの両プランが対象です。ただしカスタムロールを使った細かい制御はEnterprise限定の機能であり、Teamプランでは標準ロール単位の設定が中心になります。TeamとEnterpriseの違い全般はClaude法人プランの契約ガイドにまとめています。

権限スコープはコネクタごとに違いますか

違います。「Scopes」ステップで選べる権限の粒度はコネクタの実装に依存し、細かく分かれているものもあれば、大まかな区分しか持たないものもあります。導入前に対象コネクタがどこまで細かくスコープを分けられるかを確認しておくと、想定していた絞り込みができないという手戻りを避けられます。

まとめ

Enterprise-managed authは、メンバー個別のOAuth認証を待たずにConnectorsを組織へ配布するOkta連携のベータ機能です。設定はOrganization settingsから6ステップで完了し、対象ロールと権限スコープを絞ってから展開範囲を広げるのが安全な進め方になります。対応コネクタは8つに限られ、対応外のコネクタは引き続き個人認証が前提です。カスタムロールのConnectorsタブを使えば、部門ごとにIndividually・Managed authorizationを使い分けられるため、全社一律にする必要はありません。退職・異動時のアクセス取り消しもIDプロバイダー側の操作1つで完結する点は、個人認証の運用にはない利点です。