Claude Code マルチテナント設計｜グループ企業向けアーキテクチャ

グループ企業全体で Claude Code を導入する際、「各社のデータをどう分離するか」「誰が全体のアクセス権限を管理するのか」「コスト配賦の基準はどうするか」といった構造的な問いに直面します。私自身、ホールディングス傘下の複数法人を持つお客様から「子会社ごとに契約するとライセンス管理が煩雑だが、統合すると情報漏洩リスクが心配」という相談を何度も受けてきました。本記事では、Claude Code をマルチテナント設計で運用するためのアーキテクチャ要素—テナント分離設計、データ配置方針、アクセス制御モデル、課金配分の実装—を、国内グループ企業の実態に即して整理します。

本記事の結論: マルチテナント設計は「組織単位でデータを論理分離」「API Gateway で属性を検証」「利用量を自動集計」の3層で構成し、グループ全体のガバナンスと子会社の自律性を両立する

マルチテナントが必要になる組織構造

グループ企業では、持株会社（ホールディングス）と複数の事業子会社、さらに孫会社が階層的に存在する形態が一般的です。Claude Code を導入する際、次のいずれかの運用方針が考えられます。

方針	メリット	デメリット
子会社ごとに個別契約	データ完全分離	ライセンス管理コスト増、ボリュームディスカウント不可
持株会社で一括契約	コスト最適化、統一ポリシー	テナント分離設計が必須、初期設計コスト
事業部単位で分離	中間粒度の管理	組織変更時の再設計リスク

一般的な事例では、100名規模の子会社が3〜5社あるグループの場合、一括契約により年間コストを20〜30%削減できる可能性がある一方、テナント設計の初期投資として1〜2か月の設計期間が必要になります。この判断は、グループ全体の IT ガバナンス方針（集権型か分権型か）と密接に関係します。

⚠

注意: Claude の公式 API には「テナント ID を指定するパラメータ」が標準提供されているわけではありません。マルチテナント設計は、利用者側が API Gateway や Proxy レイヤーで実装する必要があります。

テナント分離設計の3つのレベル

マルチテナントアーキテクチャでは、データ分離の粒度を「物理分離」「論理分離」「アプリケーション層分離」の3段階で選択します。

物理分離（Dedicated Instance）

子会社ごとに別の Claude API Key を発行し、完全に独立した契約として運用する方式です。データベースも別スキーマまたは別インスタンスとし、他社のデータに物理的にアクセスできない構造を作ります。

1. 子会社ごとに API Key を発行 — Anthropic Console で Organization を子会社ごとに作成（または持株会社 Organization 内で Project を分離）

2. Gateway で API Key をルーティング — リクエスト元の社員が所属する子会社を識別し、対応する API Key を選択してプロキシ

3. ログを子会社別に記録 — CloudWatch Logs や BigQuery のテーブルを子会社ごとに分割し、監査ログの閲覧権限を分離

この方式は金融・製薬など規制業界でデータ隔離の証明が必要な場合に有効ですが、API Key の管理コストと契約交渉の手間が子会社数に比例して増加します。

論理分離（Shared Instance with Tenant ID）

単一の Claude API Key を使い、リクエストのメタデータに「テナント ID」（子会社識別子）を埋め込んで分離する方式です。データベースは共有スキーマとし、WHERE tenant_id = 'subsidiary_a' のようなクエリで分離します。

# API Gateway（FastAPI 例）でテナント ID を検証
@app.post("/v1/chat")
async def proxy_chat(request: Request, user: User = Depends(get_current_user)):
    tenant_id = user.subsidiary_code  # JWT から取得した子会社コード
    headers = {
        "x-api-key": SHARED_CLAUDE_API_KEY,
        "anthropic-version": "2023-06-01",
        "x-tenant-id": tenant_id  # カスタムヘッダー（ログ記録用）
    }
    # 会話履歴を tenant_id でフィルタして取得
    history = await db.get_history(user_id=user.id, tenant_id=tenant_id)
    # Claude API へプロキシ

この方式は運用コストを抑えつつ、アプリケーション層でのアクセス制御を実装できます。ただし、コード上の実装ミス（WHERE 句の漏れ等）により他社データが漏洩するリスクがあるため、セキュリティベストプラクティスで述べた「最小権限の原則」を厳格に適用する必要があります。

アプリケーション層分離（UI/UX Level）

単一インスタンスを複数子会社で共有し、UI のログイン画面やダッシュボードで子会社を選択させる方式です。データは論理分離と同様ですが、ユーザーは自社以外のデータを「見えない」形で設計します。

実装例: ログイン時に subsidiary_id をセッションに保持し、すべての API 呼び出しで WHERE subsidiary_id = session['subsidiary_id'] を自動付与する ORM フィルタを実装。

国内のグループ企業では、子会社間で人事異動が発生するケースが多いため、ユーザーの所属子会社を動的に変更できる設計が求められます。

データ配置とリージョン選択

Claude API は米国リージョン（us-east-1 等）でホストされているため、日本国内のデータレジデンシー要件を満たすには、プロンプト・応答の保存場所を慎重に設計する必要があります。

データ種別	推奨配置先	保持期間
プロンプト本文	国内 RDB（暗号化）	監査要件に応じて 1〜7年
Claude の応答	国内 Object Storage（S3 互換）	同上
利用量ログ	国内 DWH（BigQuery / Redshift）	課金配分のため最低 2年
セッション情報	Redis（国内リージョン）	24時間（短期）

グループ企業では、親会社が国内データセンターを保有し、子会社がクラウドを利用している混在環境が少なくありません。この場合、親会社の VPN 経由で Claude API にアクセスし、ログは親会社のオンプレミス DWH に送信する「ハイブリッド配置」が現実的です。

⚠

注意: Claude API の応答データは、Anthropic のサーバーに一時的に保持されます（トレーニングには使用しない設定が可能）。個人情報や機密情報を含むプロンプトを送信する場合は、事前にマスキング処理を行うか、契約時に DPA（Data Processing Agreement）を締結してください。

アクセス制御モデルの設計

マルチテナント環境では、「誰がどのテナントのデータにアクセスできるか」を階層的に定義します。一般的な RBAC（Role-Based Access Control）を拡張し、テナント属性を組み合わせた T-RBAC（Tenant-aware RBAC） を実装します。

ロール定義例

1. グループ管理者（Group Admin） — 全子会社のログ閲覧、API Key の発行・無効化、課金レポートの集計

2. 子会社管理者（Subsidiary Admin） — 自社のユーザー追加・削除、自社の利用量確認、自社のプロンプト履歴の監査

3. 一般ユーザー（End User） — 自社テナント内での Claude 利用、自分の会話履歴の閲覧のみ

JWT（JSON Web Token）のペイロードに tenant_id と role を埋め込み、API Gateway で検証する実装が標準的です。

{
  "sub": "user123",
  "tenant_id": "subsidiary_a",
  "role": "subsidiary_admin",
  "exp": 1735689600
}

横断アクセスの制御

グループ全体のナレッジベースを共有したい場合（例: 持株会社が作成した業界動向レポートを全子会社で参照）、テナント横断リソース として別テーブルで管理し、shared_resources テーブルに accessible_tenants カラムを持たせます。

CREATE TABLE shared_resources (
  resource_id UUID PRIMARY KEY,
  owner_tenant_id VARCHAR(50),
  accessible_tenants TEXT[],  -- ['subsidiary_a', 'subsidiary_b']
  content TEXT
);

この設計により、子会社 A が作成したプロンプトテンプレートを、子会社 B・C にも選択的に公開できます。

課金配分の自動化

グループ企業で一括契約した場合、API 利用量を子会社ごとに集計し、親会社から各社へコストを配賦する仕組みが必要です。Claude API のトークン消費量（Input / Output）を tenant_id 別に記録し、月次で集計します。

配賦ロジックの選択肢

方式	計算方法	適用場面
トークン実測配賦	子会社ごとの Input/Output トークン数で按分	利用量に差がある場合
ユーザー数割	契約ユーザー数で均等割	全社で利用頻度が均一な場合
固定比率	売上高・従業員数などの外部指標で配分	内部振替の簡素化を優先

一般的な事例では、トークン実測配賦を採用すると、利用していない子会社への過剰請求を防げる一方、集計システムの開発に 2〜4週間の工数を要します。

3つ

配賦方式の選択肢

月次

推奨集計頻度

2-4週

配賦システム開発期間

利用量ログのスキーマ例

CREATE TABLE usage_logs (
  log_id UUID PRIMARY KEY,
  tenant_id VARCHAR(50),
  user_id VARCHAR(100),
  timestamp TIMESTAMP,
  model VARCHAR(50),  -- 'claude-3-5-sonnet-20241022'
  input_tokens INT,
  output_tokens INT,
  total_cost_usd DECIMAL(10,4)
);

-- 月次集計ビュー
CREATE VIEW monthly_usage AS
SELECT 
  tenant_id,
  DATE_TRUNC('month', timestamp) AS month,
  SUM(input_tokens) AS total_input,
  SUM(output_tokens) AS total_output,
  SUM(total_cost_usd) AS total_cost
FROM usage_logs
GROUP BY tenant_id, month;

このビューを BI ツール（Looker / Tableau / Power BI）に接続すれば、グループ管理者と子会社管理者がそれぞれ必要な粒度でコストを可視化できます。

組織変更への対応設計

グループ企業では、M&A による子会社の追加・売却、事業の分社化・統合が頻繁に発生します。マルチテナント設計では、これらの変更に柔軟に対応できる拡張性を確保する必要があります。

1. テナント ID を外部マスタで管理 — ハードコードせず、tenants テーブルで tenant_id, company_name, status (active/inactive) を保持

2. ユーザーの所属を履歴化 — 人事異動時に user_tenant_history テーブルで過去の所属を記録し、監査ログの連続性を確保

3. データ移行スクリプトを用意 — 子会社統合時に tenant_id を一括変更する SQL を事前に準備

エンタープライズオンボーディングでは単一組織の段階的導入を扱いましたが、マルチテナント設計では「複数組織の同時並行導入」と「継続的な組織変更」の両方を考慮する必要があります。

API 統合パターンとの関係

マルチテナント環境で Claude を既存システムと連携させる場合、API 統合パターンで紹介した Gateway パターンを拡張し、テナント認証を組み込みます。

graph LR
    A[子会社Aユーザー] -->|JWT with tenant_a| B[API Gateway]
    C[子会社Bユーザー] -->|JWT with tenant_b| B
    B -->|tenant_id検証| D[Claude API Proxy]
    D -->|共通API Key| E[Claude API]
    D -->|ログ分離| F[DWH tenant_a]
    D -->|ログ分離| G[DWH tenant_b]

この構成では、Gateway が JWT の tenant_id を検証し、不正なクロステナントアクセスをブロックします。また、利用量ログを DWH の異なるパーティションに書き込むことで、課金配分を自動化します。

導入ロードマップ

1. 要件定義（2週間） — グループ内の法人数、データレジデンシー要件、課金配分方式を確定

2. アーキテクチャ設計（2-3週間） — テナント分離レベル、ロール定義、利用量ログスキーマを決定

3. PoC 実装（4週間） — 2〜3子会社で API Gateway + ログ集計の動作検証

4. 全社展開（3-6か月） — 残りの子会社へ順次ロールアウト、運用体制の確立

条件により異なりますが、グループ全体で 5〜10社の子会社がある場合、設計から全社展開まで 6〜9か月を見込むケースが一般的です。

まとめ

Claude Code のマルチテナント設計では、テナント分離設計（物理・論理・UI 層の選択）、データ配置（国内リージョンへのログ保存）、アクセス制御（T-RBAC の実装）、課金配分（トークン実測または固定比率）の4要素を統合的に設計する必要があります。グループ企業特有の組織変更リスクに対応するため、テナント ID を外部マスタで管理し、データ移行スクリプトを事前に準備することが運用の持続性を高めます。

4要素

設計の柱

6-9か月

想定導入期間（5-10社）

月次

推奨課金集計

株式会社デジライズでは、グループ企業向けの Claude Code マルチテナント設計支援を研修と コンサルティング の2本柱で提供しています。研修では、アーキテクト向けにテナント分離の実装パターンと利用量ログの設計手法を、コンサルティングでは、貴社のグループ構造に最適化した API Gateway の設計・PoC 実装・課金配分システムの構築を支援します。「どの分離レベルを選ぶべきか」「組織変更に強い設計とは何か」といった疑問に、実装レベルで回答します。まずは 無料相談 で、貴社グループの構成と要件をお聞かせください。