Claude.ai Enterprise の情シス管理設計：SSO・SCIM・データ保護の判断軸

Anthropic が提供する Claude.ai の企業向けプランには Teams と Enterprise の 2 種類があり、それぞれ SSO 連携・ユーザープロビジョニング・データ保護の設計が異なる。この記事では、100 名規模の組織で Claude.ai の展開を担当する情シス担当者が、管理設計を進めるための判断軸を整理する。

この記事を読んだほうが良い人

• Claude.ai の Teams または Enterprise プランを契約済みで、管理設計が追いついていない情シス担当者
• 生成 AI ツールの SSO 統合とユーザープロビジョニングをこれから設計する担当者
• Claude.ai に入力したデータがモデル学習に使われるかどうか、法務・上長から確認を求められている担当者
• Google Workspace (GWS) 環境で Claude.ai の SSO を設定したい担当者

Claude.ai Enterprise 情シス管理の全体像

Claude.ai の企業向けプランは大きく 2 つに分かれる。シート数上限 150 席の Teams プランと、大規模組織向けの Enterprise プランだ。

情シスとして最初に押さえるべき差異は次の表で確認できる。

機能	Teams	Enterprise
SSO（SAML 2.0）	✅	✅
JIT プロビジョニング	✅	✅
SCIM プロビジョニング	❌	✅
カスタムロール	❌	✅
カスタムデータ保持期間	❌	✅
監査ログ（Audit logs）	❌	✅
顧客管理暗号鍵（CMK）	❌	✅

SCIM (System for Cross-domain Identity Management) によるユーザーの自動プロビジョニング・廃棄、カスタムロールによる細粒度の権限制御、監査ログの取得は、いずれも Enterprise 専用だ。内部統制や法務要件で「誰がいつ Claude を使ったか記録したい」というニーズがある場合は、Teams プランでは対応できない。

なお Enterprise はプラットフォーム利用料とトークン消費が別請求の従量課金になる。Teams は定額制なので、利用規模とコスト構造を合わせて判断する必要がある。月あたりのアクティブユーザー数と一人あたりの利用頻度を概算してから、どちらのコスト構造が合うかを検討したい。

SSO 設計：Google Workspace を IdP にする場合

Claude.ai の SSO は SAML 2.0 に対応しており、WorkOS がミドルウェア層として機能する。対応 IdP は Okta・Entra ID（旧 Azure AD）・Google SAML・OneLogin・JumpCloud・Duo の 6 種で、GWS 環境であれば Google を IdP として利用できる。

設計上で注意が必要な点が 2 つある。

1 点目：親組織に接続できる IdP は 1 つだけ

Claude.ai の管理構造は「親組織（Parent Organization）」が頂点に立つ階層になっている。この親組織に接続できる IdP は 1 つのみだ。Okta と GWS を混在させることはできない。既に Okta で全社 SSO を運用している環境で「Claude.ai だけ Google SAML にしたい」という構成は取れないため、IdP の選択は最初に確定させる。

全社 SSO を Google Workspace で統一している組織は特に迷いがない。一方、Okta を全社 IdP としている場合は Okta 側で Google Workspace のアカウントをフェデレーションしているケースも多く、その場合は Okta を Claude.ai の IdP に選ぶほうが管理上シンプルになる。

2 点目：既存の個人アカウントへの影響

SSO 強制（Require SSO for Claude）を有効にすると、SSO アプリに追加されていないユーザーは会社ドメインのアカウントへアクセスできなくなる。SSO アプリに追加済みのユーザーは、組織アカウントと従来の個人アカウントをトグル切り替えで引き続き利用できる。展開前に会話履歴のエクスポート方法を社内に案内し、SSO アプリへの追加漏れがないよう確認しながら移行猶予期間を設けることが必要だ。

移行スケジュールの目安として、告知から猶予期間終了まで最低 2 週間は設けることを推奨する。実際には「Claude.ai を個人で使っていた」ことを申告していないユーザーが一定数いるため、展開日に突然アクセスできなくなるとヘルプデスクへの問い合わせが集中する。告知→移行期間→SSO 強制有効化という 3 段階で進めると混乱が少ない。

JIT vs SCIM の使い分け

JIT プロビジョニング（Teams・Enterprise 共通）

Just-in-Time（JIT）は、ユーザーが初めて SSO でログインした瞬間にアカウントが自動生成される方式だ。設定負荷が低く、Teams プランでも利用できる。

ただし JIT 単体では退職者への対応が手動になる点に注意が必要だ。IdP 側でユーザーが無効化されれば SSO ログインは止まるが、Claude.ai 側のシートは残り続ける。退職者がシートを占有したまま新規ユーザーに割り当てられない状況や、シート料金の無駄が発生するリスクがある。退職処理のフロー（HR システム連携や IT 担当者への通知）が整備されていない組織では特に注意が必要だ。

SCIM プロビジョニング（Enterprise 専用）

SCIM は IdP との双方向同期だ。IdP でユーザーにアプリを割り当てれば自動でシートが発行され、IdP から削除すれば即座にアクセスが失効する。グループマッピングを組み合わせれば、役割（ロール）の変更も IdP 側の操作だけで伝播する。

退職者が発生した場合の処理フローを比べると、JIT 環境では「IdP 無効化 → Claude.ai に手動ログインしてシート削除」という 2 ステップが必要なのに対し、SCIM では「IdP 無効化」だけでアクセス失効とシート解放が自動完了する。入退社が毎月複数件発生する組織では、この自動化の差が蓄積すると運用負荷として差が出てくる。

GWS を IdP とする場合、Google Workspace 側の SCIM 実装と Claude.ai を WorkOS 経由で接続する構成になる。SCIM は SSO 設定が完了していることが前提条件だ。

判断の目安

• 入退社が月 3 件以上、または退職後アクセス制御を確実に自動化したい → SCIM（Enterprise 必須）
• 入退社が少なく IT リソースも限られている → JIT（Teams でも対応可）
• 将来 SCIM に移行する可能性があるなら、最初から Enterprise で SSO + JIT を構築し、SCIM を後から追加する計画を立てておく

データ保護の設計判断

「Claude.ai に入力した情報がモデルの学習に使われるか」は、社内セキュリティ審査で必ず確認される項目だ。

Anthropic の公式情報では、Teams・Enterprise のいずれも、デフォルトでプロンプトおよび応答がモデル学習に使用されないとされている。個人向けの Free/Pro プランとは扱いが異なる点を、社内の利用ポリシー文書に明記しておくと後の説明コストが下がる。

Enterprise では追加のデータ保護オプションがある。

• カスタムデータ保持期間: データを何日間保持するかを組織で設定できる
• 顧客管理暗号鍵（CMK）: 自社クラウドで暗号鍵を管理できる
• Zero Data Retention（ZDR）: 会話データを一切ディスクに書き込まない構成（別途アドオン契約）

ZDR が必要かどうかの判断基準は、「会話内容そのものを Anthropic のインフラに一時的にでも保存させたくない」要件があるかどうかだ。医療・法務・金融など、規制業種や個人情報を含む業務での利用が見込まれる場合は ZDR を検討する。一方、CMK は「データは保存されても構わないが、暗号化キーの管理権を自社で持ちたい」ニーズに対応する。セキュリティポリシーや監査基準によって要件が異なるため、法務・情報セキュリティ部門と要件を揃えたうえで選択したい。

なお Anthropic は SOC 2 Type II 監査を完了しており、ISO 27001:2022 および ISO/IEC 42001:2023 の認証を取得している。社内のセキュリティ審査で第三者認証の確認を求められる場面では、Anthropic の Trust Center を参照するよう社内文書に記載しておく。

ロール設計の判断軸

Teams プランは Owner・Admin・User の 3 種類の組み込みロールのみだ。Enterprise ではこれに加えてカスタムロールを作成できる。

カスタムロールでコントロールできる範囲は以下の通りだ。

• 機能制限: Chat・Claude Code・web 検索・プロジェクト・コード実行など機能ごとに ON/OFF
• 管理権限: ID 管理・課金・分析・プライバシー・ユーザー管理・ライブラリを「閲覧不可 / 閲覧のみ / 管理」で制御
• コネクター権限: Google Drive・Microsoft 365・GitHub などの外部ツール連携を操作ごとに制限

ロールは「グループ」に割り当て、ユーザーはグループ経由で権限を受け取る構造だ。複数グループに属するユーザーの権限の合成挙動については、Anthropic 公式ドキュメントで事前に確認したうえで設計すること。

100 名規模の組織でありがちなロール設計例を挙げると、次のような 3 層構成が実務上の出発点になりやすい。

ロール（名称例）	対象	与える主な権限
一般ユーザー	全社員	Chat・Web 検索のみ
開発・エンジニア	開発部門	上記 + Claude Code・コード実行・GitHub コネクター
IT 管理者	情シス	上記 + ユーザー管理・監査ログ閲覧・課金確認

ロール設計は後からやり直しが難しいため、「一般社員には最小権限から始め、申請ベースで拡張する」設計にしておくほうが後の管理が楽になる。ロールを細かく作りすぎると管理対象が増えてかえって煩雑になるため、用途の差が明確なグループ単位に留めるのが現実解だ。

「一般社員は業務補助チャットのみ、エンジニアは Claude Code も使用可、管理者はコネクターも制御可」という段階的な権限設計が Teams プランではできない。カスタムロールが必要になるタイミングが Enterprise への移行判断の一つの基準になる。

生成 AI SaaS ガバナンスとして整理すると

情シス担当者視点で整理すると、管理設計の骨格は「誰が使えるか（アクセス制御）」「何を使えるか（機能制限）」「ログをどう取るか（監査）」の 3 軸だ。

Claude.ai の機能を当てはめると次のようになる。

• アクセス制御: SSO + JIT/SCIM でライフサイクル管理。シート数上限・ロール制限でコスト管理
• 機能制限: カスタムロールで用途別に機能を絞る（Enterprise）
• 監査: Audit logs + Compliance API でユーザー操作・データアクセスを取得（Enterprise）

Audit logs は管理コンソールから参照できる操作履歴で、「誰がいつどのプロジェクトにアクセスしたか」といった行動記録の確認に使う。Compliance API は外部の SIEM（セキュリティ情報イベント管理）ツールへのデータ連携を想定した機能で、定期的なログエクスポートや自動アラートを組み込みたい場合に活用できる。内部統制や情報セキュリティ管理の要件によっては、SIEM との連携が必要になる場面もあるため、展開前に情報システムセキュリティ担当と要件を確認しておきたい。

Teams プランは「アクセス制御」と「コスト管理」はカバーできる。「監査が必要（法務・内部統制要件が発生した）」タイミングが Enterprise 移行の主なきっかけになる。最初の展開では Teams から始め、監査要件が顕在化した段階で Enterprise に切り替えるという段階的アプローチも現実解の一つだ。ただし移行時には SSO・ロール設計の再構成コストが発生するため、長期的に監査要件が見込まれるなら最初から Enterprise を選ぶほうが合理的だ。

展開前に確認すべきポイント

展開開始前に情シスとして確認しておくべき項目を整理する。

• シート数が将来的に 150 を超える見込みがあるか（Enterprise 要件の判断）
• SCIM による自動プロビジョニング・廃棄が必要か（Enterprise 専用）
• IdP として何を使うか（Google SAML / Okta / Entra ID 等から 1 つ選択）
• SSO 強制前に既存アカウントユーザーへの告知と移行猶予期間（最低 2 週間）を設けているか
• 個人情報・機密情報を含む用途があるか（ZDR・CMK の要否判断）
• 監査ログや Compliance API が内部統制・法務要件に必要か（Enterprise 判断）
• 請求形態を理解しているか（Teams は定額、Enterprise はトークン従量課金も別途発生）
• 利用ポリシー（どの情報を入力してよいか・してはいけないか）を情報セキュリティポリシーの補足文書として整備済みか

特に最後の利用ポリシー整備は見落とされやすい。技術的な SSO 設定が完了しても「何を入力してよいか」のルールがないと、社員が判断に困って活用が進まなかったり、機密情報を入力するリスクが生じたりする。展開と並行して 1 ページ程度のガイドラインを用意しておくことで、ヘルプデスクへの問い合わせも減らせる。

これらを展開前に整理しておくと、「まず Teams で始めたが Enterprise の機能が必要になり移行が発生した」という二度手間を避けやすくなる。

まとめ

Claude.ai の情シス管理設計は、Teams と Enterprise のどちらを選ぶかによって構成がほぼ決まる。SCIM・カスタムロール・監査ログのいずれかが必要ならば Enterprise 一択だ。

Google Workspace 環境であれば Google SAML を IdP として利用できるため、既存の ID 管理基盤をそのまま活用できる点は導入しやすい要素の一つだ。

展開を急ぐあまり SSO なしで始めると、後から強制 SSO に切り替える際に既存アカウントの移行コストが発生する。最初の設計でアクセス制御の基本方針（SSO 必須か否か、JIT か SCIM か）を確定させておくことが、後の運用負荷を最も下げる判断になる。利用ポリシーの整備も技術設定と同時進行で進めることで、展開後の混乱を最小限に抑えられる。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。