株式会社デジライズで AI 導入支援を担当している茶圓です。グループ企業や複数部門を抱える組織が Claude Code を展開する際、「各テナントのデータを完全に分離しながら、運用効率とコストも最適化したい」という要求に直面します。私自身、金融グループや製造業の持株会社で、子会社ごとに異なる機密レベルを要求されながら、統一プラットフォーム上で運用する設計を何度も経験してきました。テナント分離は単なるアカウント分割ではなく、IAM・データレイク・監査ログ・課金の全層で一貫した設計判断が求められる領域です。本記事では、Claude Code を用いたマルチテナント環境において、物理・論理・アプリケーション層それぞれの分離レベルの選択基準と、実運用で機能する具体的な設計パターンを示します。
本記事の結論: テナント分離は「リスク許容度」「運用体制の成熟度」「コスト制約」の3軸で分離レベルを決定し、IAM ポリシー・データレイク・監査ログ・課金配賦の全層で一貫性を保つ設計が必須
Claude Code におけるテナント分離の3層モデル
Claude Code のマルチテナント環境では、分離レベルを物理層・論理層・アプリケーション層の3段階で定義し、各テナントのセキュリティ要件に応じて組み合わせます。
物理分離は、AWS アカウントや Organization を完全に分けるアプローチです。金融子会社・ヘルスケア部門など、規制要件が厳格でデータの混在が許されない場合に選択します。各テナントが独立した Anthropic API キー・IAM ロール・VPC を持ち、ネットワーク層でも他テナントのトラフィックと交わりません。運用負荷は高くなりますが、クロステナントの侵害リスクはゼロに近づきます。
論理分離は、単一の AWS アカウント内で IAM ポリシーとリソースタグによってテナントを区別します。全社統一の Claude Code インフラを運用しつつ、部門ごとに異なる権限を付与したい場合に有効です。タグベースの条件分岐（aws:ResourceTag/TenantID）で S3 バケット・CloudWatch Logs・IAM ロールへのアクセスを制御し、一つのインフラ内で複数テナントを管理します。運用コストは抑えられますが、IAM ポリシーの設計ミスがクロステナントアクセスにつながるリスクがあります。
アプリケーション層分離は、アプリケーションコード内でテナント ID を検証し、API リクエスト・データベースクエリ・ログ出力の全てに埋め込む方式です。SaaS 型の内製ツールで Claude Code を提供する場合や、単一コードベースで多拠点展開する場合に採用します。この層では、リクエストヘッダーに含まれるテナント ID と、データベースのテナント ID カラムを突合し、不一致があれば即座に拒否します。実装の柔軟性は高い反面、開発チームの設計ミスやバグが直接セキュリティホールになりやすく、継続的なコードレビューと自動テストが不可欠です。
設計判断の落とし穴: 「とりあえず IAM で分ければ安全」という思考は危険。各層の分離レベルが一貫していないと、データレイクで論理分離しているのに監査ログは共有バケット、といった設計の不整合が生じ、インシデント時に責任境界が曖昧になる
IAM ポリシー設計によるテナント境界の実装
論理分離を採用する場合、IAM ポリシーがテナント境界の最前線になります。以下の設計原則を守ることで、設定ミスによるクロステナントアクセスを防ぎます。
タグベースの条件分岐を全リソースに適用します。S3 バケット・Lambda 関数・CloudWatch Logs ロググループに TenantID タグを付与し、IAM ポリシーで "Condition": {"StringEquals": {"aws:ResourceTag/TenantID": "${aws:PrincipalTag/TenantID}"}} を記述します。これにより、ユーザーが自身のテナント ID と一致するリソースにしかアクセスできなくなります。
SCP（Service Control Policy）による上位制約を Organization レベルで設定します。特定の子会社アカウントから、他の子会社が管理する S3 バケットへのアクセスを明示的に拒否するポリシーを適用することで、IAM ロールの権限昇格攻撃を防ぎます。たとえば、テナント A のアカウントから arn:aws:s3:::tenant-b-* への s3:GetObject を拒否するルールを記述します。
セッションタグの強制により、一時認証情報にもテナント ID を埋め込みます。AssumeRole 時に "sts:RequestTag/TenantID" を必須化し、セッション中のすべてのリクエストが正しいテナント ID を持つことを保証します。これにより、開発者が誤って別テナントのロールを取得したとしても、リソースレベルのポリシーで弾かれます。
1. リソースタグの標準化 — S3・Lambda・Logs・DynamoDB 等の全リソースに TenantID Environment DataClassification の3タグを必須化し、Terraform や CDK のモジュールで自動付与
2. IAM ポリシーテンプレートの作成 — 各テナント用の IAM ロールを生成する際、タグ条件分岐を含むポリシーテンプレートから自動生成。手動編集は禁止
3. SCPによる上位制約の適用 — Organization のルートアカウントで、クロステナントリソースへの s3:* logs:* を明示的に拒否する SCP を設定
4. 定期的な Access Analyzer 監査 — AWS IAM Access Analyzer でクロステナントアクセスの可能性がある設定を週次検出し、誤設定を即座に修正
デジライズ が支援した製造業グループでは、8つの子会社それぞれに独立した Claude Code 環境を論理分離で構築しましたが、IAM ポリシーの条件分岐を一元管理するテンプレートリポジトリを用意し、全社共通の Terraform モジュールから生成する仕組みにしたことで、設定ミスをゼロに抑えました。
データレイクにおけるテナント分離設計
Claude Code の対話履歴・生成コード・ユーザーフィードバックを蓄積するデータレイクでは、ストレージ・テーブル設計・クエリエンジンの各層でテナント分離を実装します。
S3 バケット設計では、テナントごとに独立したバケットを作成する「バケット分離型」と、単一バケット内でプレフィックスを分ける「プレフィックス分離型」があります。バケット分離型は IAM ポリシーがシンプルになり、バケットポリシーでテナント単位のアクセス制御を完結できますが、バケット数が増えると AWS の制限（デフォルト100個）に達する可能性があります。プレフィックス分離型は s3://data-lake/tenant-a/conversations/ のように階層化し、IAM ポリシーで "Resource": "arn:aws:s3:::data-lake/tenant-${aws:PrincipalTag/TenantID}/*" と記述することで、単一バケット内でテナント境界を維持します。20テナント以上の大規模環境では、プレフィックス分離型が運用上現実的です。
テーブル設計では、DynamoDB や Athena のテーブルに tenant_id をパーティションキーまたはソートキーに含めます。クエリ時に必ず WHERE tenant_id = ? を強制することで、アプリケーション層のバグによる全テナントスキャンを防ぎます。Athena の場合、S3 のプレフィックスをパーティションとして認識させ、MSCK REPAIR TABLE でパーティション情報を更新する運用を自動化します。
クエリエンジンの分離は、Athena ワークグループをテナントごとに作成し、各ワークグループが参照できる S3 パスを制限します。これにより、SQL インジェクションや誤ったクエリで他テナントのデータが混入するリスクを排除します。さらに、Athena のクエリ結果バケットもテナント別に分け、結果データの漏洩を防ぎます。
運用上の注意点: データレイクの設計は初期構築だけでなく、テナント追加時の自動プロビジョニング、テナント削除時のデータ完全消去（S3 Object Lock や Glacier Deep Archive からの削除）までを含めた運用フローを事前に定義する必要がある
Claude Code のマルチテナント環境構築の詳細は Claude Code マルチテナンシー設計 で解説しています。
クロステナントリクエストの検知・防止メカニズム
設計上の分離に加えて、実行時にクロステナントアクセスを検知・遮断する防御層を設けます。
API Gateway レベルの検証では、Lambda オーソライザーでリクエストヘッダーの X-Tenant-ID と、JWT トークンに埋め込まれたテナント ID を突合します。不一致があれば 403 Forbidden を即座に返し、リクエストをバックエンドに到達させません。この検証ロジックは全エンドポイントで共通化し、個別の Lambda 関数内での重複実装を避けます。
CloudTrail によるリアルタイム監視では、EventBridge ルールで s3:GetObject dynamodb:Query 等のイベントを監視し、リクエスト元の IAM ロールのタグとリソースのタグを比較します。不一致があれば SNS 経由で即座にアラートを発火し、セキュリティチームが調査を開始します。デジライズ が構築した環境では、この仕組みで誤設定による他テナントへのアクセス試行を検知し、設定変更から3分以内に是正した実績があります。
GuardDuty と Security Hub の統合により、異常な API コールパターンを機械学習で検出します。特定の IAM ロールが短時間に複数テナントのリソースへアクセスを試みるような挙動は、GuardDuty が自動検知し、Security Hub の「重要度：高」所見として集約されます。この所見をトリガーに自動でロールを無効化する Lambda を接続し、インシデント拡大を防ぎます。
監査ログの分離保管とアクセス制御
監査ログ自体も機密情報であり、テナント間で分離して保管・アクセス制御する必要があります。
CloudWatch Logs のロググループ分離では、各テナント専用のロググループを作成し、/aws/lambda/tenant-a/code-executor のような命名規則で管理します。IAM ポリシーで logs:FilterLogEvents の Resource を arn:aws:logs:*:*:log-group:/aws/lambda/tenant-${aws:PrincipalTag/TenantID}/* に制限し、他テナントのログを参照できないようにします。
S3 への長期保管では、CloudWatch Logs のエクスポート機能で、30日経過したログを S3 に自動転送します。転送先のバケットもテナント別プレフィックスで分離し、S3 Object Lock を有効化して改ざん防止を実装します。金融業界など規制要件が厳しい場合、7年間の保管義務に対応するため Glacier Deep Archive への自動移行ルールを設定します。
アクセス制御の階層化では、監査ログへのアクセス権限を「通常運用者」「セキュリティ監査者」「外部監査人」の3層に分けます。通常運用者は自テナントのログのみ参照可能、セキュリティ監査者は全テナントのログを参照可能だが編集不可、外部監査人は特定期間・特定テナントのログを一時的に参照可能、という権限設計を IAM ポリシーで実装します。外部監査人用のロールは、監査期間中のみ有効化し、期間終了後は自動で無効化する Lambda を定期実行します。
コンプライアンス上の注意: 監査ログに含まれるユーザー識別子・IP アドレス・生成コードの断片が個人情報や機密情報に該当する場合、GDPR や個人情報保護法の観点から保管期間・アクセス権限・削除手順を法務部門と確認する必要がある
Claude Code のセキュリティ実装全般については Claude Code セキュリティベストプラクティス もあわせて参照してください。
課金配賦の仕組みとテナント別コスト可視化
マルチテナント環境では、AWS コストを各テナントに正確に配賦し、部門別・子会社別の予算管理を実現する必要があります。
コストアロケーションタグの活用では、全リソースに TenantID CostCenter Project のタグを付与し、AWS Cost Explorer で「タグでグループ化」を選択することでテナント別のコスト内訳を可視化します。Lambda の実行時間・S3 のストレージ使用量・API Gateway のリクエスト数が、どのテナントに起因するかを日次で把握できます。
Anthropic API 利用料の配賦は、Claude Code が発行する API リクエストに含まれるテナント ID をロギングし、CloudWatch Logs Insights で集計します。具体的には、fields @timestamp, tenant_id, token_count | stats sum(token_count) by tenant_id のようなクエリで、テナントごとのトークン消費量を算出し、月末に CSV エクスポートして財務システムに連携します。API キーが共有されている場合でも、アプリケーション層でテナント ID をメタデータとして記録していれば、正確な配賦が可能です。
予算アラートの設定では、AWS Budgets で各テナントの月間予算を設定し、80%・100%・120%の閾値で段階的にアラートを発火します。通知先はテナント管理者の Slack チャンネルとし、予算超過時には自動でリソースのスケールダウンや API コール制限を実行する Lambda をトリガーします。この仕組みにより、特定テナントの使いすぎが他テナントのコストに波及するのを防ぎます。
RI（Reserved Instance）・Savings Plans の配賦は複雑ですが、全社共通の割引を各テナントの実使用量に応じて按分する方式が一般的です。Cost and Usage Report を S3 にエクスポートし、Athena でテナント別の割引額を計算するクエリを定期実行し、配賦結果を BI ツールで可視化します。
| 配賦項目 | データソース | 集計方法 | 更新頻度 |
|---|---|---|---|
| Lambda 実行時間 | CloudWatch Logs | タグベース集計 | 日次 |
| S3 ストレージ | AWS Cost Explorer | タグベース集計 | 日次 |
| Anthropic API トークン | アプリログ | tenant_id で GROUP BY | 時間ごと |
| データ転送量 | VPC Flow Logs | 送信元タグで集計 | 日次 |
デジライズ が支援した小売グループでは、10店舗それぞれに独立した Claude Code 環境を提供し、Cost Explorer と連携した BI ダッシュボードで店舗ごとの AI コストを可視化しました。これにより、利用量の多い店舗に対して事前にリソース最適化の提案を行い、全社のコスト効率を改善できました。
まとめ
Claude Code のマルチテナント環境におけるテナント分離は、以下の設計判断と実装の積み重ねで実現します。
分離レベルの選択は、リスク許容度・運用体制の成熟度・コスト制約の3軸で判断します。金融・ヘルスケアなど規制が厳格な業界は物理分離、一般事業会社の部門分離は論理分離、SaaS 型の内製ツールはアプリケーション層分離が基本の選択肢です。重要なのは、選択した分離レベルを IAM・データレイク・監査ログ・課金の全層で一貫させることです。
IAM ポリシーの設計では、タグベースの条件分岐・SCP による上位制約・セッションタグの強制を組み合わせ、設定ミスによるクロステナントアクセスを排除します。ポリシーは手動編集ではなく、Terraform 等の IaC ツールでテンプレート化し、全テナントで統一した設定を保ちます。
データレイクとログの分離では、S3 バケット・テーブル設計・クエリエンジンの各層で境界を実装し、実行時の検証・監視・アラートで多層防御を構築します。監査ログ自体も機密情報として扱い、アクセス権限を階層化して管理します。
課金配賦の可視化により、各テナントの AI コストを正確に把握し、予算管理と最適化提案を実施します。Cost Explorer・CloudWatch Logs Insights・BI ツールを連携させ、日次でコスト内訳を更新する仕組みを構築します。
組織構造に応じた設計パターンは Claude Code 組織構造設計 で詳しく解説しています。
デジライズ の Claude Code 法人導入支援
株式会社デジライズでは、Claude Code のマルチテナント環境構築を「研修」と「コンサルティング」の2本柱で支援しています。
研修プログラムでは、貴社のセキュリティアーキテクト・インフラエンジニア向けに、IAM ポリシー設計・データレイク構築・監査ログ管理・課金配賦の実践ワークショップを提供します。座学だけでなく、実際の AWS 環境でテナント分離を実装し、クロステナントアクセスの検知・防止を体験いただくハンズオン形式です。
コンサルティングでは、貴社の組織構造・規制要件・既存インフラを分析し、最適な分離レベルの選定から、IaC による自動プロビジョニング、運用フローの標準化まで一気通貫で設計します。導入後も、定期的な Access Analyzer 監査・コスト最適化提案・新規テナント追加時の設計レビューを継続支援します。
無料相談では、貴社のテナント数・セキュリティ要件・運用体制をヒアリングし、物理・論理・アプリケーション層それぞれの実装案と想定工数をご提示します。マルチテナント環境の設計判断でお悩みの方は、ぜひお気軽にお問い合わせください。
無料相談のお申し込みは こちら
関連記事
デジライズの実績は社内集計値です。特に明記のない数値付き事例は、匿名加工された実例をもとにしたモデルケースです。導入効果は企業や業務によって異なります。各サービスの料金・機能・提供条件は記事の公開・更新時点の情報であり、変更されるため、最新情報はAnthropic公式サイトなどの一次情報をご確認ください。
Claude Codeの法人導入・研修・業務活用を支援しています。
法人導入支援サービスを見る
