Claude LLM Gateway｜3大クラウド連携設計【2026】

結論: Claude LLM Gatewayは、AWS Bedrock・Google Vertex AI・Microsoft Foundryの3クラウドすべてでClaudeを統合運用できる仕組みで、日本企業のデータ主権確保・コスト最適化・ガバナンス強化に直結します。

この記事の要点:

• Claude Codeは唯一、Bedrock/Vertex/Foundryの3大クラウド全てにLLM Gatewayで接続できる
• データをAnthropicに送らないBedrock/Vertex経由なら、GDPR・APPI対応のデータ主権を確保できる
• LiteLLMなどのゲートウェイ経由で、チーム横断の利用追跡・コスト上限・監査ログを一元管理できる

対象読者: AI活用を本格化させたい中小〜中堅企業のITセキュリティ担当・DX推進責任者

読了後にできること: 自社のクラウド環境に合ったClaude LLM Gateway設定パターンを選択し、環境変数を設定して今日から運用を開始できる

「ChatGPTを導入したいけど、データがどこに飛ぶか分からない」

企業向けAI研修で、最もよく聞かれる質問の一つです。先日、従業員700名規模の製造業クライアントから相談を受けました。社内の法務部門から「生成AIへの入力データが学習に使われないか確認してほしい」と言われて止まっているというのです。

これ、実は解決策がちゃんとあります。Anthropicが提供する「Claude LLM Gateway（LLMゲートウェイ）」の仕組みを使えば、AWS・Google Cloud・Azureといった既存の自社クラウド環境の中でClaudeを動かせる。つまり、データはAmazonやGoogleのデータセンターに留まり、Anthropicには一切送られない設計が可能です。

この記事では、2026年4月時点の最新ドキュメントをもとに、Claude Code LLM Gatewayの仕組みから具体的な設定手順まで、実務担当者が今日から使えるレベルで解説します。

Claude LLM Gatewayとは何か — マルチクラウド統合の全体像

まず全体像を整理します。Claude Code（AnthropicのAIコーディングアシスタント）は、モデルAPIへのアクセス方法として現在4つのルートをサポートしています。

「LLMゲートウェイ」とは、Claude Codeとクラウドプロバイダーの間に挟まるプロキシ層のことです。組織によっては、さらにこのゲートウェイを経由してBedrockやVertexに接続するケースがあります。

実務的に言うと、LLMゲートウェイは以下のような課題を持つ組織に刺さります：

• 複数チームのAPI利用を一元追跡したい
• チームごとに予算上限を設定したい
• 全リクエストの監査ログを取りたい
• 認証を中央管理したい
• プロバイダーをコードなしで切り替えたい

3大クラウド連携の設定手順 — BedrockからFoundryまで

AIエージェント導入を支援している中で感じるのは、「環境変数一つ変えるだけでOK」という点に驚かれるケースが多いことです。実際、Claude Codeのマルチクラウドはほぼシェルのexportだけで切り替えられます。

AWS Bedrockとの連携

2026年4月現在、Claude Opus 4.7がAmazon Bedrockに正式対応しました。東京リージョン（ap-northeast-1）でも利用可能で、日本企業にとって最も身近な選択肢です。

直接接続する場合の設定:

# BedrockでClaudeを有効化
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1   # 東京リージョン

# AWSクレデンシャル（IAMロールが推奨）
export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key

# 不足情報があれば最初に質問してから設定を進めてください

LLMゲートウェイ経由でBedrockを使う場合:

# BedrockトラフィックをLLMゲートウェイに向ける
export CLAUDE_CODE_USE_BEDROCK=1
export ANTHROPIC_BEDROCK_BASE_URL='https://your-llm-gateway.com/bedrock'
export CLAUDE_CODE_SKIP_BEDROCK_AUTH=1   # ゲートウェイがAWS認証を肩代わりする場合

# 設定確認コマンド
# Claude Code内で /status を実行

Bedrockの利点はAWS IAMによるきめ細かなアクセス制御とCloudTrailによる監査ログです。ISO 27001認証取得済み環境でClaudeを動かせるのは大きなメリットです。

Google Vertex AIとの連携

Vertex AIはEU・米国・アジアの各リージョンでPrivate Service Connectによる閉域接続をサポートしています。データがインターネットに一切出ないVPCルーティングが可能な点が特徴です。

# Vertex AIでClaudeを有効化
export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=asia-northeast1   # 東京リージョン
export ANTHROPIC_VERTEX_PROJECT_ID=your-gcp-project-id

# GCPクレデンシャル（サービスアカウント推奨）
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json

LLMゲートウェイ経由の場合:

export CLAUDE_CODE_USE_VERTEX=1
export ANTHROPIC_VERTEX_BASE_URL='https://your-llm-gateway.com/vertex_ai/v1'
export ANTHROPIC_VERTEX_PROJECT_ID=your-gcp-project-id
export CLAUDE_CODE_SKIP_VERTEX_AUTH=1   # ゲートウェイがGCP認証を処理する場合
export CLOUD_ML_REGION=us-east5

GDPRが気になる欧州展開の企業は、Vertex AI＋EU推論プロファイルの組み合わせが最有力です。

Microsoft Azure Foundryとの連携

Azure Foundryは2026年初頭からClaudeの正式提供が始まっており、Microsoft Entra ID（旧Azure AD）による統合認証が利用できます。Azureをメインクラウドとする日本企業（特に金融・製造大手）にとって自然な選択です。

# Azure FoundryでClaudeを有効化
export CLAUDE_CODE_USE_FOUNDRY=1
export ANTHROPIC_FOUNDRY_RESOURCE=your-azure-resource
export ANTHROPIC_FOUNDRY_API_KEY=your-foundry-api-key
# Entra ID認証の場合はAPIキーを省略可

LLMゲートウェイ経由の場合:

export CLAUDE_CODE_USE_FOUNDRY=1
export ANTHROPIC_FOUNDRY_BASE_URL='https://your-llm-gateway.com'
export CLAUDE_CODE_SKIP_FOUNDRY_AUTH=1   # ゲートウェイがAzure認証を処理する場合

なお、AI導入戦略の全体像については別記事で体系的に解説していますので、あわせてご確認ください。

LiteLLMゲートウェイの実践設定

現場でよく採用されているOSSゲートウェイが「LiteLLM」です。Anthropicが公式ドキュメントで言及しており、BedrockとVertex AIのパススルーエンドポイントをサポートしています。ただし、重要な注意点があります。

重要なセキュリティ警告: LiteLLM PyPI バージョン1.82.7および1.82.8は、認証情報を窃取するマルウェアが混入していたことが確認されています。これらのバージョンをインストールした場合は即座にパッケージを削除し、全クレデンシャルをローテーションしてください（参照: BerriAI/litellm#24518）。

安全なバージョンのLiteLLMを使う場合の基本設定です。

統合エンドポイント方式（推奨）:

# LiteLLMの統合Anthropicフォーマットエンドポイントを使用
export ANTHROPIC_BASE_URL=https://litellm-server:4000

# ロードバランシング・フォールバック・コスト追跡が自動で有効になる

静的APIキー認証の設定:

export ANTHROPIC_AUTH_TOKEN=sk-litellm-static-key
# このキーがAuthorizationヘッダーとして送信される

動的APIキー（Vault連携）の場合:

#!/bin/bash
# ~/bin/get-llm-key.sh — 起動時に認証情報をVaultから取得

vault kv get -field=api_key secret/llm/claude-code

# JWT方式の場合
jwt encode 
  --secret="${JWT_SECRET}" 
  --exp="+1h" 
  '{"user":"'${USER}'","team":"dev"}'

# settings.jsonでAPIキーヘルパーを設定
{
  "apiKeyHelper": "~/bin/get-llm-key.sh",
  "env": {
    "CLAUDE_CODE_API_KEY_HELPER_TTL_MS": "3600000"
  }
}

データ主権とコンプライアンスの設計

研修先の法務担当から一番よく聞かれるのが「このデータ、Anthropicで学習に使われますか？」という質問です。答えは利用方法によって異なります。

BedrockとVertex AIは「オペレータアクセスゼロ」設計で、プロンプトや出力がAnthropicにもAWS/GCPオペレーターにも見えない仕組みが保証されています。日本の個人情報保護法（APPI）対応が必要な場合、東京リージョン指定で国内完結が可能です。

Claude Opus 4.7のBedrock提供は2026年4月21日から開始されており、東京リージョン（ap-northeast-1）でもIn-Region推論が使えます。データを日本国内に留めながら最新Claudeモデルを使いたい企業にとって、タイムリーな選択肢です。

モデルバージョンのピン留め — クラウド経由でのバージョン管理

エンタープライズ導入で見落とされがちなのがモデルバージョン管理です。クラウドプロバイダー経由の場合、エイリアス（「claude-3-opus」等）が最新バージョンに自動解決されます。Anthropicが新モデルをリリースした時点でプロバイダーが対応していなければ、エラーになる可能性があります。

# モデルを特定バージョンにピン留め（推奨）
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-7-20260401
export ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-4-6-20251001
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-3-5-20241022

# ピン留めすることで、プロバイダー側の対応タイミングを自分でコントロールできる

本番環境では必ずピン留めを設定し、新バージョン移行は検証後に明示的に更新する運用をお勧めします。

設定確認とトラブルシューティング

設定が正しく反映されているかは、Claude Code内で /status コマンドを実行することで確認できます。

# Claude Code内で実行
/status

# 出力例
# Route: bedrock (ap-northeast-1)
# Gateway: https://gateway.example.com/bedrock
# Model: claude-opus-4-7-20260401
# Auth: AWS credentials (IAM Role)

【要注意】よくある設定ミスと回避策

失敗1: ヘッダーが転送されないゲートウェイ

❌ ゲートウェイが anthropic-beta ヘッダーを転送しない

⭕ ゲートウェイの設定で anthropic-beta と anthropic-version を必ず転送するよう設定

なぜ重要か: これらのヘッダーがないとClaude Codeは機能を正しく判断できず、ストリーミングや特定機能が動作しなくなります。

失敗2: BedrockとVertex AIでAnthropicメッセージ形式を使う時

❌ LLMゲートウェイがAnthropicメッセージ形式でBedrockに転送する設定で、実験的ベータ機能が使えない

⭕ 環境変数 CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 を設定して実験的機能を無効化する

なぜ重要か: プロバイダーAPI形式の違いにより、ベータ機能の一部が非互換になることがあります。

失敗3: リージョン未指定によるデータ主権違反

❌ AWS_REGIONを指定せず、デフォルトリージョン（米国）でデータ処理される

⭕ AWS_REGION=ap-northeast-1（Bedrock）または CLOUD_ML_REGION=asia-northeast1（Vertex）を明示する

なぜ重要か: コンプライアンス要件で「データを日本国内に留める」が求められているのに、実際には米国で処理されていたというケースが現場でも起きています。

失敗4: LiteLLM汚染バージョンの利用

❌ PyPI 1.82.7/1.82.8 のLiteLLMをそのまま使い続ける

⭕ バージョン確認 pip show litellm | grep Version を実行し、該当する場合は即座に削除してクレデンシャルをローテーション

なぜ重要か: マルウェア混入が確認されており、AWSキーやGCPサービスアカウントが窃取される可能性があります。

日本企業のマルチクラウドAI設計 — 3つのパターン

100社以上のAI研修・導入支援の経験から、日本企業でよく見るパターンを3つ整理します。

パターン1: AWS一本化型（中小〜中堅製造業に多い）

既存のAWSインフラにBedrock経由でClaudeを追加。IAMで細かく権限制御し、CloudTrailで全操作をログ記録。東京リージョン指定でデータ主権を確保。追加インフラが最小限で済みます。

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
# IAMロールで認証（EC2やEKSの場合はインスタンスプロファイルで自動取得）

パターン2: マルチクラウドLLMゲートウェイ型（大手・金融系に多い）

社内でLiteLLMやPortkeyなどのゲートウェイを立て、部署ごとにBedrock・Vertex・Foundryを使い分ける。コスト追跡とレート制限を全社一元管理。クラウドベンダーロックインを最小化できます。

export ANTHROPIC_BASE_URL=https://internal-llm-gateway.company.co.jp
export ANTHROPIC_AUTH_TOKEN=sk-internal-team-token

パターン3: ハイブリッド型（研究開発+本番の分離）

開発・検証環境はClaude API直接接続で柔軟性を確保し、本番環境はBedrock経由でコンプライアンスを担保。環境ごとに設定ファイルを切り替える。

LLMゲートウェイが満たすべき要件チェックリスト

自社でゲートウェイを選定・評価する際のチェックリストです。

参考・出典

• Enterprise deployment overview – Claude Code Docs — Anthropic（参照日: 2026-04-24）
• LLM gateway configuration – Claude Code Docs — Anthropic（参照日: 2026-04-24）
• Claude Opus 4.7 is now available in Amazon Bedrock — AWS（参照日: 2026-04-24）
• AWS Weekly Roundup: Claude Opus 4.7 in Amazon Bedrock — Amazon Web Services（参照日: 2026-04-24）
• Claude Cowork now runs on Bedrock, Vertex and Foundry — Unfiltered Bits（参照日: 2026-04-24）

まとめ: 今日から始める3つのアクション

1. 今日やること: 自社の主力クラウド（AWS/GCP/Azure）を確認し、対応するClaude接続環境変数を1行設定してみる
2. 今週中: IT・法務・セキュリティ部門と「どのリージョンでデータを処理するか」をすり合わせ、コンプライアンス要件を整理する
3. 今月中: LLMゲートウェイの選定（LiteLLM/Portkey等）を評価し、チーム横断のコスト管理・監査ログ体制を構築する

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（旧Twitter）で活用法を発信（@SuguruKun_ai、フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。