企業全体で Claude Code を本格導入する際、「部門ごとに試用が先行してしまい、後から統合すると権限管理が煩雑化した」「セキュリティポリシーをテナントごとに統一できず、監査対応に時間を取られる」といった課題が起こりやすいのが実情です。私自身、デジライズ で複数の企業の Claude Code 導入支援を担当してきましたが、初期のアーキテクチャ設計が不十分なまま進めると、後からのガバナンス整備に数倍のコストがかかるケースを何度も目にしてきました。本記事では、Claude Code を全社基盤として構築する際のアーキテクチャ設計について、SSO 連携・RBAC 設計・監査要件対応を中心に、実務で検証済みのパターンを解説します。読者の皆様が自社のセキュリティポリシーと照らし合わせながら、適切な設計判断を下せるよう具体的な選択肢と判断基準を提示します。

i

本記事の結論: Claude Code の全社展開では、SSO 統合・テナント分離方針・RBAC 粒度・監査ログ設計の4要素を初期段階で定義し、ゼロトラスト原則に基づく認証フローを構築することで、後からのガバナンス整備コストを抑えられる

全社アーキテクチャ設計の前提となる4要素

Claude Code を企業基盤として構築する際、以下の4要素を初期段階で明確にする必要があります。これらは相互に依存するため、順序立てて検討することが重要です。

1. 認証基盤との統合方針 — 既存の IdP（Okta・Azure AD・Google Workspace 等）との SSO 連携をどのプロトコルで実現するか。Claude Code は SAML 2.0 および OIDC に対応しているため、自社の IdP が対応するプロトコルを確認したうえで選択します。

2. テナント分離戦略 — 部門・プロジェクト・セキュリティレベルのいずれを境界とするか。詳細は Claude Code マルチテナント設計 で解説していますが、データ主権・コンプライアンス要件・予算管理の観点から判断します。

3. RBAC 粒度の決定 — 組織階層・職務・データ分類のどのレベルまで権限を細分化するか。粒度が細かすぎると運用負荷が高まり、粗すぎると過剰権限のリスクが残ります。

4. 監査ログ要件の定義 — SOC 2・ISO 27001・GDPR 等の規格に応じて、どの操作をどの粒度で記録するか。Claude Code の監査ログは API 経由で SIEM と連携できるため、既存の監査基盤との統合方針も含めて検討します。

SSO 連携の実装パターンと認証フロー設計

Claude Code の SSO 連携では、IdP 側で発行されたトークンを Claude 側で検証し、組織内のロールにマッピングする流れが基本です。実装時に検討すべき主要な選択肢を以下に整理します。

プロトコル選択と IdP 側設定

Claude Code は SAML 2.0 と OIDC の両方に対応しています。既存の IdP が両方をサポートしている場合、以下の判断基準で選択します。

項目 SAML 2.0 OIDC
属性マッピング assertion 内のカスタム属性を柔軟に設定可能 ID トークンの claims に組織情報を含められる
セッション管理 IdP 側でセッションタイムアウトを制御 リフレッシュトークンで更新可能
既存システムとの統合 レガシー SSO 基盤との親和性が高い モダンな OAuth 2.0 ベースのシステムと統合しやすい

デジライズ の支援実績では、Azure AD を利用している企業の多くが SAML 2.0 を選択し、Google Workspace 環境では OIDC を採用するケースが比較的多い傾向にあります。

属性マッピングと動的ロール割り当て

SSO 認証時に IdP から渡される属性（部署名・役職・プロジェクトコード等）を Claude Code 側のロールにマッピングする設計が重要です。静的な手動割り当てではなく、IdP 側のグループメンバーシップに基づいて動的にロールを付与する設計を推奨します。

i

実装例: Azure AD のセキュリティグループ「Claude_Developers」に所属するユーザーには、ログイン時に自動的に「Developer」ロールを付与し、API 利用・コード実行権限を有効化する。グループから外れた時点で権限も自動的に剥奪される。

ゼロトラスト原則に基づく認証フロー

Claude Code を全社基盤として運用する場合、ゼロトラスト原則に基づき、「認証済みであっても常に検証する」フローを設計します。

1. 初回認証 — IdP 経由で多要素認証（MFA）を必須化し、デバイス証明書や条件付きアクセスポリシー（IP 制限・デバイス登録状態）と組み合わせる。

2. セッション検証 — Claude Code へのアクセス時、セッショントークンの有効期限だけでなく、IdP 側のセッション状態もリアルタイムで確認する設計が理想。SAML の場合は IdP initiated SSO、OIDC の場合は token introspection endpoint を活用します。

3. 操作時の再認証 — 機微なデータへのアクセスや API キー発行などの重要操作では、セッション継続中でも再度 MFA を要求する step-up 認証を検討します。Claude Code 側の設定で特定の操作に re-authentication を求めることができます。

デジライズ で支援した金融機関の事例では、本番データを扱う workspace へのアクセス時に毎回 MFA を要求し、開発環境では初回のみとする段階的な設計を採用しました。

RBAC 設計とロール粒度の最適化

Claude Code の RBAC は、組織レベル・workspace レベル・project レベルの3階層で権限を制御できます。全社展開では、この階層構造を自社の組織図と照らし合わせて設計する必要があります。

標準ロールのカスタマイズ方針

Claude Code が提供する標準ロール（Admin・Member・Viewer 等）をそのまま使うか、カスタムロールを定義するかは、組織の規模と業務特性に応じて判断します。

!

注意点: カスタムロールを多数定義すると、権限の組み合わせが複雑化し、監査時に「なぜこのユーザーがこの操作を実行できたのか」の追跡が困難になります。初期段階では標準ロールをベースに、必要最小限のカスタムロールを追加する方針を推奨します。

職務分離（SoD）の実装

特に金融・医療・公共分野では、職務分離の原則に基づき、「開発者が本番環境に直接デプロイできない」「監査ログの閲覧権限と削除権限を分離する」といった制約が求められます。Claude Code では以下の設計パターンで対応できます。

要件 実装パターン
開発者の本番環境アクセス制限 本番 workspace を別テナントに分離し、開発者ロールには参照権限のみ付与。デプロイは CI/CD パイプライン経由に限定
監査ログの改ざん防止 ログ閲覧ロールと管理者ロールを分離。ログ出力先を外部 SIEM に転送し、Claude Code 上では削除不可に設定
API キー発行の承認フロー API キー発行権限を特定のロールに限定し、発行時に Slack 等への通知と承認ワークフローを組み込む

最小権限の原則と定期レビュー

RBAC 設計では、初期付与する権限は業務遂行に必要な最小限に留め、追加権限は申請ベースで付与する運用を推奨します。また、四半期ごとに権限レビューを実施し、不要になった権限を剥奪するプロセスを組み込みます。

デジライズ の支援先では、IdP 側のグループメンバーシップと Claude Code 側のロール割り当てを定期的に突合するスクリプトを用意し、差分があれば管理者に通知する仕組みを導入している企業が複数あります。

監査要件とログ設計

Claude Code の監査ログは、API 経由で外部システムに転送できるため、既存の SIEM（Splunk・Azure Sentinel・Google Chronicle 等）と統合することで、他のシステムと横断的な監査基盤を構築できます。

記録すべき監査イベントの選定

すべての操作を記録するとログ量が膨大になり、かえって重要イベントを見逃すリスクがあります。以下の粒度で記録対象を分類し、保存期間とアラート設定を使い分けます。

1. 認証・認可イベント — ログイン成功・失敗、MFA 検証、権限変更、API キー発行。保存期間は最低1年、異常なアクセスパターンは即座にアラート。

2. データアクセスイベント — workspace・project へのアクセス、ファイルの閲覧・編集・削除。個人情報や機密データを含む workspace では特に詳細に記録。

3. 設定変更イベント — テナント設定・RBAC ポリシー・SSO 連携設定の変更。変更前後の差分も含めて記録し、意図しない設定変更を検知できるようにする。

4. API 利用イベント — API キーによるリクエスト、レート制限の到達、エラー発生。外部システムとの連携が多い場合は API ログを重点的に監視。

SIEM との連携パターン

Claude Code の監査ログを SIEM に転送する際、以下の方式を選択できます。

方式 概要 適用場面
Webhook 転送 Claude Code から SIEM の webhook endpoint にリアルタイムで送信 リアルタイムアラートが必要な場合
API ポーリング SIEM 側から定期的に Claude Code API を呼び出してログを取得 バッチ処理で十分な場合
ログストリーミング Claude Code から S3 等のストレージに出力し、SIEM がストリームで取り込む 大量ログを効率的に処理したい場合

デジライズ の検証環境では、webhook 転送を採用した場合、ログ遅延が平均 2〜5秒程度に収まる結果が得られていますが、ネットワーク環境や SIEM 側の処理能力により変動するため、本番運用前に負荷テストを実施することを推奨します。

i

検証環境での参考値: 1,000ユーザー規模の想定環境で、1日あたり約50,000件の監査イベントが発生しました。これを webhook でリアルタイム転送した場合、SIEM 側のストレージ増加は月間約15GB程度でした。ただし、実際の利用パターンや記録粒度により大きく変動します。

コンプライアンス規格との対応

SOC 2 Type II や ISO 27001 の認証取得を目指す場合、監査ログの完全性・改ざん防止・アクセス制御が要求されます。Claude Code のログを外部ストレージに転送後、以下の対策を講じます。

  • 改ざん防止: S3 の Object Lock や Azure Blob の immutable storage を利用し、一度書き込んだログを変更不可に設定
  • アクセス制御: ログストレージへのアクセスを監査担当者のみに制限し、開発者や運用担当者は参照不可に設定
  • 長期保管: 規制に応じて3〜7年間の保管が求められる場合、コールドストレージへの移行ポリシーを設定

GDPR 対応が必要な場合は、個人データの削除要求に対応するため、ログ内の個人識別情報をどのように管理するかも設計段階で決定しておく必要があります。

ネットワーク設計とテナント分離

Claude Code の全社展開では、ネットワークレベルでのテナント分離とアクセス制御も重要な設計要素です。Claude Code テナント分離戦略 で詳細を解説していますが、ここでは全社アーキテクチャにおける選択肢を整理します。

IP ホワイトリストと VPN 統合

Claude Code は IP ベースのアクセス制限をサポートしており、特定の IP アドレス帯からのみアクセスを許可する設定が可能です。リモートワーク環境では VPN 経由のアクセスを必須化し、VPN の出口 IP をホワイトリストに登録する運用が一般的です。

!

検討ポイント: IP ホワイトリスト方式は、モバイル端末や外部パートナーとのコラボレーションでは柔軟性に欠けます。ゼロトラストアーキテクチャを採用する場合は、IP 制限に依存せず、デバイス証明書や条件付きアクセスポリシーを優先する設計を検討してください。

Private Link / PrivateLink 相当の接続

AWS PrivateLink や Azure Private Link に相当する、インターネットを経由しないプライベート接続が将来的に提供される可能性がありますが、本記事執筆時点では公式アナウンスがないため、この点は Anthropic の公式情報を定期的に確認してください。現状では、VPN + IP ホワイトリストの組み合わせが最も確実な閉域接続の方法です。

テナント間のデータ分離保証

複数テナントを運用する場合、あるテナントのデータが別テナントから参照できないことを技術的に保証する必要があります。Claude Code のマルチテナント機能では、テナント ID に基づくデータ分離が実装されていますが、アーキテクト視点では以下の点を確認することを推奨します。

  • テナント作成時に専用の暗号化キーが発行されるか（データベースレベルでの分離）
  • API アクセス時に他テナントのリソース ID を指定してもエラーが返されるか（認可レベルでの分離）
  • 監査ログでテナント横断のアクセス試行が記録されるか（監視レベルでの検証）

デジライズ の支援では、導入前にこれらの分離が技術的に保証されていることを検証テストで確認し、結果を経営層に報告する工程を含めています。

スケーラビリティと性能設計

全社展開では、数百〜数千ユーザーが同時にアクセスする状況を想定し、性能面の設計も考慮する必要があります。

API レート制限への対応

Claude Code の API には、テナント単位・ユーザー単位でレート制限が設定されています。具体的な制限値は契約プランやテナント設定により異なるため、公式ドキュメントで最新情報を確認してください。全社展開では、以下の対策を検討します。

  • バッチ処理の設計: 大量のデータを一括処理する場合は、リクエストを分散させるキューイング機構を導入
  • キャッシュ戦略: 頻繁にアクセスされるデータは CDN やアプリケーションキャッシュに保持し、API 呼び出し回数を削減
  • エラーハンドリング: レート制限に達した場合の Retry-After ヘッダーを尊重し、exponential backoff で再試行

同時接続数とセッション管理

ユーザー数が増えると、同時セッション数も増加します。デジライズ の検証環境では、500ユーザーが同時にログインした状態でも応答時間の大きな劣化は見られませんでしたが、これは検証環境の条件下での参考値であり、本番環境での性能は利用パターンに依存します。

以下のような設計で、セッション管理の負荷を軽減できます。

  • セッションタイムアウトの最適化: 長時間放置されたセッションを自動的に無効化し、リソースを解放
  • 非アクティブユーザーの検出: 一定期間ログインのないユーザーを特定し、ライセンス再割り当てを検討
  • ピーク時の負荷分散: 業務開始時刻にアクセスが集中する場合、時差出勤やログイン時間の分散を促す運用ルールを検討

災害復旧とバックアップ戦略

全社基盤として Claude Code を運用する場合、障害発生時の復旧手順とバックアップ戦略も設計に含めます。

データバックアップの責任分界

Claude Code のデータは Anthropic 側でバックアップされていますが、企業側でも定期的にエクスポートしてローカル保管することを推奨します。特に以下のデータは定期的にバックアップします。

  • 組織設定・RBAC ポリシー: テナント設定、ロール定義、ユーザー権限の一覧を JSON 等で定期出力
  • プロジェクトデータ: 重要なコードや設定ファイルは Git リポジトリにも同期
  • 監査ログ: SIEM に転送済みのログも、長期保管用に別途アーカイブ

障害時の切り戻し手順

Claude Code がメンテナンスや障害で利用できない場合の代替手段も事前に定義します。

1. 影響範囲の特定 — どの業務が Claude Code に依存しているかをマッピングし、停止時の影響度を評価

2. 代替手段の準備 — ローカル開発環境や他の AI アシスタントツールへの一時的な切り替え手順を文書化

3. 復旧後の検証 — サービス復旧後、認証・権限・データ整合性を確認してから全社に利用再開を通知

まとめ

Claude Code の全社アーキテクチャ設計では、以下の要点を押さえることで、後からのガバナンス整備コストを抑え、セキュアな運用基盤を構築できます。

4要素
初期設計の必須項目
3階層
RBAC の権限制御レベル
4種類
監査イベントの分類
  • SSO 統合: IdP との連携プロトコル（SAML / OIDC）を選択し、動的ロール割り当てとゼロトラスト認証フローを設計
  • RBAC 最適化: 標準ロールをベースに必要最小限のカスタムロールを追加し、職務分離と最小権限の原則を徹底
  • 監査ログ設計: 記録対象イベントを4分類し、SIEM と統合してリアルタイム監視と長期保管を両立
  • ネットワーク分離: IP ホワイトリスト・VPN 統合・テナント分離を組み合わせ、データ主権を技術的に保証
  • 性能・復旧計画: API レート制限対策とバックアップ戦略を初期段階で組み込む

これらの設計パターンは、企業の規模・業種・セキュリティポリシーにより調整が必要です。デジライズ では、お客様の既存システムと Claude Code の統合設計を支援するアーキテクチャ設計コンサルティングと、実装後の運用を担う社内チームを育成する技術研修プログラムの2本柱で、全社展開をサポートしています。SSO 連携の具体的な設定手順や、RBAC ポリシーのテンプレート提供も含め、初期構築から本番運用まで伴走します。まずは 無料相談 で、貴社の現状課題とアーキテクチャ要件をお聞かせください。技術的な疑問点や、他社事例との比較検討もお気軽にご相談いただけます。

関連記事

全社アーキテクチャ設計を深めるために、以下の関連記事もあわせてご覧ください。