Claude CodeをIdPのグループ単位でアクセス制御する方法を実際に試してみた

はじめに

こんにちは。DXソリューション営業本部の松浦です。

Claude Code / Claude Desktop（Cowork）を組織に展開する際、「全社員に無条件で使わせるのではなく、一部の人だけに利用を絞りたい」というシーンがあるかと思います。利用資格を個別のアカウント登録や招待制で管理するのは運用負荷が大きいため、既存のSSO基盤が持つグループ情報だけで機械的に振り分けられると、管理はかなり楽になります。

Claude Apps Gatewayには、SSO認証で得られるグループ情報をもとに、ユーザーごとの利用可否・利用可能モデルを振り分ける「managed policies」という仕組みがあります。本記事では、この仕組みを使って、許可グループに含まれないユーザーが実際にClaude Desktop（Cowork）を使おうとした際にどうなるのかを実機で確認した結果をご紹介します！

こんな方におすすめの内容です。

• 社内の特定グループ・部署だけにClaude Code / Claude Desktopの利用を限定したい方
• 「許可した一部の人だけに使わせる」といった利用資格の運用を、SSOのグループ管理だけで実現できるか知りたい方
• Claude Apps Gatewayのポリシー機能で、非許可ユーザーの操作をどの段階で止められるのか知りたい方

まずは、この仕組みの全体像から見ていきましょう。

Claude Apps Gatewayのグループ別アクセス制御とは

Claude Apps Gatewayは、クライアント（Claude Code CLI・Claude Desktop）からのリクエストを受け付ける際、SSO認証で発行されたIDトークンに含まれる「groups」クレーム（IdP側のグループ情報）を読み取り、gateway.yamlのmanaged.policiesに定義したポリシーと突き合わせて、そのユーザーに配信する設定を決定します。

ポリシーは配列として複数定義でき、上から順に評価されて最初に一致したものが適用される仕組みです。特定グループ向けのポリシーを先に、どのグループにも一致しなかった場合に適用される既定ポリシー（match: {}）を最後に置く構成が基本になります。全体の流れを図にすると、次のようになります。

設定の流れ

グループ別のアクセス制御は、IdP側とGateway側でそれぞれ次のように役割が分かれます。

Gateway側は最初に設定ファイルを書けば、その後はほぼ触る必要がありません。日々の利用者の増減や異動に追従するのは、もっぱらIdP側のグループ管理という役割分担になります。今回の検証環境ではIdPとしてAmazon Cognitoを使用していますが、OIDCに対応したIdPであれば同様の構成で運用できます。

前提として準備しておくもの

本記事は、Claude Apps GatewayとSSO IdPとの基本的な連携（クライアントID・シークレットの登録、redirect URIの設定など、OIDCによるサインインそのものの設定）がすでに完了していることを前提とします。
Gateway・Claude Desktop側の詳しい設定内容（bootstrapUrlの登録など）は以下の記事で紹介していますので、あわせてご参照ください。

Claude DesktopをSSO化！Apps Gateway + Bedrock連携を試してみた
Claude Desktop（Cowork）は、自社構築のClaude Apps Gatewayを経由させることでSSO認証を挟んだ状態のままAmazon Bedrockに接続して利用できます。Gateway・Desktopの設定の流れと、実機で確認できた動作結果を紹介します。
 

本記事では、グループ別のアクセス制御に必要な「IdP側でのグループ作成」と「IDトークンへのgroupsクレームの付与」といった、サインインの設定とは別に必要になる部分を中心に取り上げます。
次の項目で、実際に使用したCognitoの設定内容を紹介します。

Cognitoグループとポリシー設定の対応

グループ別のアクセス制御を行うには、まずSSO IdP側にグループを用意しておく必要があります。今回の検証環境ではAmazon CognitoをIdPとして使用し、ユーザープールに「claude-approved」と「claude-denied」の2グループを作成しました。

「claude-approved」が、このあと紹介するmanaged.policiesで許可グループ側のポリシーに指定するグループ、「claude-denied」がどちらのグループにも一致せず既定ポリシー（match: {}）が適用される側の動作を確認するために用意したグループです。それぞれのグループには、検証用のテストユーザーを1名ずつ所属させています。

つまり、Claude側の設定を個別に触ることなく、「どちらのIdPグループに所属させるか」だけで、そのユーザーがClaude Desktop（Cowork）を使えるかどうかが決まる状態になっています。次に、この2つのグループ名を実際に指定したmanaged.policiesの設定内容を見ていきます。

managed.policiesでのグループ指定

グループ別のアクセス制御は、gateway.yamlのmanaged.policiesに、グループを指定したポリシーを追加するだけで設定できます。公式ドキュメント（Claude apps gateway configuration）の記載と、上記のCognitoグループ構成をもとに、今回の検証環境で実際に使用した設定は次のとおりです（グループ名は各環境のIdPで作成した任意の名称に置き換えられる、環境固有の値です）。

managed:
  policies:
    # 許可グループ向けのポリシーを先に定義する
    - match:
        groups: [claude-approved]           # IdP（今回はAmazon Cognito）側で作成したグループ名。環境ごとに任意の名称を指定可能
      cli:
        availableModels: [<利用可能にするモデルID>]
      desktop: {}                          # Claude Desktop（Cowork）へのポリシー配信を有効にするために必要

    # 既定（catch-all）ポリシーを最後に定義する
    - match: {}
      cli:
        availableModels: []                # 空リストを指定すると、利用可能なモデルが0件になる
      desktop: {}

ポイントは、既定ポリシー（match: {}）側のavailableModelsを空リストにしておくことです。許可グループに一致しなかったユーザーにはこの既定ポリシーが適用され、利用可能なモデルが1つもない状態で設定が配信されます。また、Claude Desktop（Cowork）に対してもポリシーを配信するには、各ポリシーにdesktopキー（内容は空でも構いません）を含めておく必要があります。

実機確認

非許可グループ：起動時点で完全ブロック

許可グループに含まれない「claude-denied」グループのアカウント(testuser2)でClaude Desktop（Cowork）を起動すると、画面上部に「Configuration can't be used（設定を利用できません）」という警告が表示され、詳細欄には「Gateway returned no usable models.（Gatewayから利用可能なモデルが返されませんでした）」という内容が表示されることが確認できます。

※ 画面左下のアカウント表示が「testuser2@qes.co.jp・Gateway」であり、claude-deniedグループ所属のtestuser2がGateway経由で接続していることが分かります

この画面では、メッセージの入力欄自体は表示されているものの、利用可能なモデルが0件のため、実際にメッセージを送信する前の時点ですでに操作がブロックされています。つまり非許可グループのユーザーは、「メッセージを送って初めて拒否される」のではなく、「Claude Desktop（Cowork）を起動した時点で利用できないことが分かる」形で制御されていることが実機で確認できました。

許可グループ：正常応答

一方、許可グループである「claude-approved」グループに所属するアカウント(testuser1)で同じClaude Desktop（Cowork）を起動した場合は、「Configuration can't be used」のような警告は表示されず、メッセージを送信すると通常どおり応答が返ってくることも実機で確認できました。

※ 画面左下のアカウント表示が「testuser1@qes.co.jp・Gateway」であり、claude-approvedグループ所属のtestuser1がGateway経由で接続していることが分かります
※ 画面上部に表示されている「Not enough disk space」は、検証端末のワークスペース領域のディスク容量に関する別件の通知であり、Gatewayが返すモデルの利用可否とは無関係です

ここでのポイントは、このアカウントからのメッセージに対してエラーなく応答が返っている点で、設定ファイル上の違いはグループの所属だけであり、それ以外のクライアント側の操作・見た目は変わりません。

活用イメージ

グループ単位で利用可否を切り替えられる仕組みは、ひとつのGateway構成のまま、次のような運用に活用できます。

• 研修・社内テスト合格者への段階的な利用開放：
  利用ルールの研修やテストに合格したユーザーだけをIdP側の許可グループに追加すれば、Claude側の設定を個別に変更することなく、そのユーザーの利用をすぐに開放できます
• 部署・チーム単位でのトライアル導入：
  全社展開の前に、特定の部署やチームだけを許可グループとして先行運用し、対象外のユーザーはモデル0件のまま待機させる、といった段階的なロールアウトにも応用できます
• 利用資格の一元管理：
  利用可否の判断をClaude側の個別設定ではなくIdPのグループ管理に一本化できるため、異動や退職があった場合もグループの所属を変更するだけで追従できます

まとめ

Claude Apps Gatewayのmanaged.policiesでグループ別のポリシーを設定すると、SSO IdPのグループ情報だけを根拠に、Claude Code / Claude Desktop（Cowork）の利用可否をユーザー単位で制御できます。今回の実機確認では、許可グループに含まれないユーザーが、メッセージを送信するより前の起動時点で「利用可能なモデル0件」の状態としてブロックされる一方、許可グループに含まれるユーザーは同じ構成のまま通常どおり応答を受け取れることが確認できました。

「特定の人だけに利用を絞る」といった社内統制を、個別のアカウント管理を増やすことなくSSOのグループ管理だけで実現する際の、実装パターンのひとつとして参考にしていただければ幸いです。

QESでは、ガバナンス整備・セキュアな利用環境構築・利活用コンサルティング・セキュリティレビューまで、Claude / Claude Code の組織導入を一貫して支援しています。AWS（Amazon Bedrock）経由での提供にも対応しています。支援内容は下記のサービスページ、および無料の「Claude 導入チェックリスト」をご覧いただくか、お問い合わせフォームよりお気軽にご相談ください。

Claude 導入支援サービス | QES
Anthropic のAIエージェント「Claude」の導入を、ガバナンス整備・利用環境構築（Enterprise / Amazon Bedrock）・利活用コンサルティング・セキュリティレビューまでQESが一貫して支援します。
 

※このブログで参照されている、Anthropic、Claude、Claude Code、Claude Cowork は、Anthropic, PBCの米国およびその他の国における商標または登録商標です。

※このブログで参照されている、Amazon Web Services、AWS、Amazon Bedrockは、Amazon.com, Inc.またはその関連会社の商標です。