こんにちは、株式会社TIMEWELLの濱本です。
「Claude Codeを全社で展開したい。ただし社外にコードもプロンプトも出したくない」。この相談を、ここ半年で20件以上受けました。最初に確認するのは決まって同じ質問です。「AWSとGoogle Cloud、どちらに寄せていますか」。
なぜか。Claude CodeはAnthropic直契約のほかに、Amazon BedrockとGoogle Vertex AI経由で動かす経路が公式に用意されているからです。既存のIAM・KMS・PrivateLink・CloudTrailをそのまま流用できる経路を選べば、追加のセキュリティ審査をほぼ通さずに本番投入できます。一方、経路選定を間違えると、せっかくの統制が効かなくなり、データ主権要件にも引っかかる。今回は、その分岐点を踏まえたうえで、Bedrock経由・Vertex AI経由の実装設定、ゲートウェイ層（LiteLLM、Helicone、Kong AI Gateway）の使い分け、東京リージョンでのデータ保管要件までを一気通貫で整理します。コード例は3種類用意しました。コピー＆ペーストで動く粒度です。
このシリーズはClaude Code法人活用の第6弾です。オンボーディング、SOC2やISO27001、コスト最適化と来て、今回はインフラ層に踏み込みます。
なぜBedrock経由・Vertex AI経由なのか、データ主権・監査・既存統制という3軸
まず素朴な疑問から。Anthropic直契約でもSOC 2 Type IIは取得済みで、ZDR（Zero Data Retention）契約も結べます。それでも法人がBedrockやVertex AIを選ぶ理由は、突き詰めると3つです。データ主権、監査統制、既存契約の流用です。
データ主権の話から始めます。Amazon Bedrockの地理限定クロスリージョン推論プロファイル（CRIS）を使うと、リクエストとレスポンスを特定の地理圏に閉じ込められます。日本向けには「jp.」プレフィックスのプロファイル（jp.anthropic.claude-sonnet-4-5-20250929-v1:0など）が2025年10月から提供されており、東京（ap-northeast-1）と大阪（ap-northeast-3）の間だけで推論が完結します。AWS Global Networkを経由するため、通信がパブリックインターネットに出ることもありません。金融庁のFISC安全対策基準やAPPI（個人情報保護法）の越境移転制限を意識する組織にとって、この設計は強力な切り札になります。
次に監査統制。BedrockはInvokeModel、InvokeModelWithResponseStream、Converse、ConverseStreamといった推論APIをCloudTrailの管理イベントとして自動的に記録します。Vertex AI側もService名aiplatform.googleapis.comの監査ログがCloud Loggingに流れます。つまり、誰がいつどのモデルを呼んだかが、既存のSIEM（Splunk、Datadog、Sumo Logicなど）の取り込み先を変えるだけで把握できる。新しい監査基盤を立てる必要がない、というのが効きます。Anthropic自身もBedrock経由のログを少なくとも30日間は保持することを推奨しています。
3つ目が既存契約・統制の流用です。AWSとEnterprise Discount Programを結んでいる企業なら、Claude Codeの利用料はAWSの請求にそのまま乗ります。新規ベンダー登録、与信、契約レビュー、法務、情報セキュリティ部門のすべてをスキップできる。これが現場の体感としていちばん大きい。「Anthropicと直接契約するのに半年かかる。Bedrockなら来週使える」という相談が、今のエンタープライズ現場の典型例です。
逆に直接契約のほうが向いているのは、最新モデルをリリース当日に試したい開発組織や、AWSやGCPと同居していないオンプレ中心の組織です。判断軸は明確で、「自社の既存統制をどこに置いているか」。そこにClaude Codeを寄せるのが、いちばん波風が立ちません。
AWS Bedrock経由のClaude Code実装、IAMとPrivateLinkとCloudTrailの三点セット
Bedrock経由のClaude Codeは、環境変数2つで切り替わります。CLAUDE_CODE_USE_BEDROCK=1とAWS_REGION、これだけです。Claude Codeは.aws/configを読まないため、リージョンは明示する必要があります。Anthropicは2026年4月のv2.1.92でBedrockのインタラクティブな初期設定ウィザードもリリースしましたが、CI／CDのパイプラインや全社配布の用途では、環境変数でガッチリ固定したほうが運用は楽です。
実際の設定例を示します。エンタープライズではIAMロールとSSO（AWS IAM Identity Center）を組み合わせるのが定番で、開発者ごとに静的なアクセスキーを配ることはしません。
# ~/.claude/settings.json または環境変数で固定
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
export AWS_PROFILE=claude-code-tokyo
export ANTHROPIC_DEFAULT_SONNET_MODEL=jp.anthropic.claude-sonnet-4-5-20250929-v1:0
export ANTHROPIC_DEFAULT_HAIKU_MODEL=jp.anthropic.claude-haiku-4-5-20251001-v1:0
# SSOセッション切れを自動更新
export AWS_SDK_LOAD_CONFIG=1
# Claude Code側のリフレッシュコマンド
# settings.json の awsAuthRefresh に "aws sso login --profile claude-code-tokyo" を設定
ポイントは2つ。jp.プレフィックスの推論プロファイルを明示することと、awsAuthRefreshでSSOの再ログインをClaude Codeが自動で叩く設定にしておくことです。これを怠ると、開発者が朝イチで「401エラーで動きません」と問い合わせを送ってきます。
IAMポリシーは最小権限で組みます。Bedrock側で必要になるのは推論3種類とリスト系で、ザクッと書くと以下のTerraformになります。
resource "aws_iam_policy" "claude_code_bedrock" {
name = "ClaudeCodeBedrockInvoke"
description = "Claude Code経由でBedrock Anthropic Claudeを呼ぶための最小権限"
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "InvokeAnthropicClaude"
Effect = "Allow"
Action = [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:ListFoundationModels",
"bedrock:ListInferenceProfiles"
]
Resource = [
"arn:aws:bedrock:ap-northeast-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0",
"arn:aws:bedrock:ap-northeast-1:*:inference-profile/jp.anthropic.claude-sonnet-4-5-20250929-v1:0",
"arn:aws:bedrock:ap-northeast-3::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0"
]
},
{
Sid = "MarketplaceForBedrockOnly"
Effect = "Allow"
Action = "aws-marketplace:Subscribe"
Resource = "*"
Condition = {
StringEquals = {
"aws-marketplace:ProductId" = "anthropic-claude-bedrock"
}
}
}
]
})
}
Resourceに推論プロファイルARNを明示するのは、SCP（Service Control Policy）でリージョンを制限している組織で特に効きます。Claude Codeは内部でファウンデーションモデルIDをクロスリージョン推論プロファイルに変換することがあり、SCPでus-east-1を禁止していると403で落ちる現象が報告されています（GitHub Issue #20594）。日本リージョンに閉じ込めたいなら、推論プロファイル側のARNで明示的に許可するのが確実です。
通信経路はPrivateLink（VPCインターフェイスエンドポイント）で固めます。com.amazonaws.ap-northeast-1.bedrock-runtimeとcom.amazonaws.ap-northeast-1.bedrockの2つを作るのが基本です。これでClaude Codeから出るリクエストはVPC内に閉じ、NATゲートウェイすら経由しません。社内開発環境がプロキシ経由でしかインターネットに出られない構成でも、PrivateLinkがあれば直接Bedrockに到達できます。料金は1エンドポイントあたり時間0.014ドル前後と微々たるもので、セキュリティ統制と引き換えにする価値は十分にあります。
監査ログはCloudTrailとCloudWatchの併用が定石です。CloudTrailはAPIコールのメタデータ（誰が、いつ、どのIAMロールで、どのモデルを呼んだか）、CloudWatch Logsはモデル呼び出しの本体（プロンプトと出力、トークン数）を記録します。CloudWatch Logsを有効化するには、Bedrockコンソールの「Settings → Model invocation logging」で出力先のロググループを指定するだけで済みます。Anthropicは最低30日のローリング保持を推奨していますが、SOC 2やISO 27001を取りに行くなら90日〜1年保持にしておくほうが安全です。KMSのCustomer-Managed Keys（CMK）で暗号化したロググループを使えば、ログ自体の鍵管理も顧客側に持ち込めます。
Google Vertex AI経由のClaude Code実装、Service AccountとVPC Service ControlsとCloud Loggingの構成
Vertex AI経由は、Bedrockと考え方は似ていますが、認可モデルが大きく違います。AWSがIAMロール中心なのに対し、Google CloudはService Accountと組織レベルの境界（VPC Service Controls）を組み合わせます。Claude CodeのVertex AI接続もv2.1.98以降でインタラクティブウィザードが入りましたが、エンタープライズではgcloud CLIとADC（Application Default Credentials）を使った非対話設定が中心になります。
最低限の環境変数は3つです。CLAUDE_CODE_USE_VERTEX=1、CLOUD_ML_REGION（リージョンまたはglobal）、ANTHROPIC_VERTEX_PROJECT_ID。設定例を見せると次のようになります。
# settings.json の env ブロックに書き込む例
env:
CLAUDE_CODE_USE_VERTEX: "1"
CLOUD_ML_REGION: "asia-northeast1"
ANTHROPIC_VERTEX_PROJECT_ID: "timewell-claude-code-prod"
GOOGLE_APPLICATION_CREDENTIALS: "/etc/secrets/claude-code-sa.json"
ANTHROPIC_DEFAULT_SONNET_MODEL: "claude-sonnet-4-5@20250929"
ANTHROPIC_DEFAULT_HAIKU_MODEL: "claude-haiku-4-5@20251001"
Service Accountに付与するロールは、原則としてroles/aiplatform.user一本です。このロールにはaiplatform.endpoints.predict（モデル呼び出し）とaiplatform.endpoints.computeTokens（トークンカウント）が含まれており、Claude Codeが必要とする権限はこれで足りる。逆にroles/aiplatform.adminを渡すのは過剰で、監査の観点でも避けるべきです。
Vertex AI側の本気のセキュアアーキテクチャは、VPC Service Controls（VPC SC）の境界（Perimeter）にClaude Code用プロジェクトを入れることで完成します。VPC SCの境界を設定すると、aiplatform.googleapis.comへのリクエストは境界内からしか通らなくなり、不正なプロジェクトや個人アカウントからの呼び出しを物理的に遮断できます。注意点として、Claude Sonnet 4のWeb検索機能はVPC SC境界の中では動かない仕様です（境界内からはインターネット側のWebに出られないため）。コード生成とリポジトリ操作だけが目的の用途であれば実害はありませんが、ドキュメント検索を伴うエージェント用途では、境界外プロジェクトを別途用意する設計が必要になります。
監査ログはCloud Audit Logsの「Data Access Logs」をaiplatform.googleapis.com向けに有効化します。デフォルトでは「Admin Activity Logs」しか取られないため、エンタープライズ用途ではData Access Logsの有効化が必須です。さらにVertex AIには「Request-Response Logging」というオプションがあり、有効化するとプロンプトと出力本体を最大30日間保管できます。これはBedrockのCloudWatch Logs相当の機能で、悪用検知や品質監査の用途に効きます。
ひとつ留意点があります。Vertex AIの監査ログは粗い粒度です。「どのService Accountがいつエンドポイントを叩いたか」までは追えますが、「リクエスト単位の入力トークン数」や「ユーザー単位のコスト按分」までは取れません。1人あたりの利用量を厳格に管理したい場合は、後述するLiteLLMやHeliconeのようなゲートウェイ層を間に挟む構成が現実的です。
通信経路は「Private Service Connect for Vertex AI」を使います。PSCを設定すると、asia-northeast1-aiplatform.googleapis.comのエンドポイントがVPC内のプライベートIPに解決され、リクエストがGCPのバックボーンに閉じます。AWSのPrivateLinkと考え方は同じで、社内VPNからしかPSCエンドポイントに到達できない設定にすれば、開発者の自宅Wi-Fiから直接Vertex AIを叩く事故も防げます。
ゲートウェイ層をどう挟むか、LiteLLM・Helicone・Kong AI Gatewayの使い分け
BedrockやVertex AIに直接つなぐ構成で十分な組織もあれば、その間にゲートウェイを挟みたい組織もあります。判断軸を整理します。
ゲートウェイを挟む理由は実務的に3つです。第1に、複数モデル・複数プロバイダの統合管理（OpenAI、Bedrock経由Claude、Vertex AI経由Claude、Geminiを1本のAPIで扱いたい）。第2に、ユーザー単位のコスト按分とレート制限（部署別の予算管理、開発者ごとの利用上限）。第3に、PII検出やプロンプトインジェクション対策などのガードレール（GDPR・APPI対応の入力検査）。これらを既存のセキュリティ機構だけでカバーしきれないとき、ゲートウェイの出番になります。
主要な選択肢は3つに絞られてきました。LiteLLM、Helicone、Kong AI Gatewayです。
LiteLLMは、自社で運用したいエンタープライズの第一候補です。Pythonベースの自己ホスト型プロキシで、140以上のプロバイダをOpenAI互換APIに揃え、Virtual API Key・Budget・SSO（Okta、Azure AD）・RBAC・監査ログまで揃っています。GitHubスター約4万、コミュニティ規模は最大級。負荷面では、毎秒2,000リクエストを超えると不安定になるという報告もあるため、本気の本番運用ではKubernetes上で水平スケールさせるのが前提です。Bedrock・Vertex AIの両方を裏に置いて、開発者にはOpenAI互換のシンプルなエンドポイントだけ見せる、という典型構成が一番きれいに当てはまります。
# litellm config.yaml の抜粋（Bedrock + Vertex AIの両方を束ねる例）
model_list:
- model_name: claude-sonnet-jp-bedrock
litellm_params:
model: bedrock/jp.anthropic.claude-sonnet-4-5-20250929-v1:0
aws_region_name: ap-northeast-1
aws_role_name: arn:aws:iam::123456789012:role/litellm-bedrock
- model_name: claude-sonnet-asia-vertex
litellm_params:
model: vertex_ai/claude-sonnet-4-5@20250929
vertex_project: timewell-claude-code-prod
vertex_location: asia-northeast1
router_settings:
routing_strategy: usage-based-routing-v2
fallbacks:
- claude-sonnet-jp-bedrock: ["claude-sonnet-asia-vertex"]
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
database_url: os.environ/DATABASE_URL
enable_jwt_auth: true
Heliconeは、観測性（Observability）を重視する組織に向いています。Rust製で追加レイテンシは50ms前後、自己ホストも可能で、Anthropic公式のClaude Code連携ドキュメントも整備されています。LiteLLMより監視ダッシュボードが洗練されており、リクエスト単位のコスト・レイテンシ・エラー率を即座に可視化できる。「コスト管理よりも、何が起きているか可視化したい」フェーズにフィットします。
Kong AI Gatewayは、すでにAPI管理基盤としてKongを使っている組織のための選択肢です。Bedrock向けのai-proxyプラグインがあり、既存のKong Gatewayにそのまま乗せれば、認証・レート制限・WAFまで一括で適用できます。ただし、KongをLLM専用に新規導入するのは過剰投資。既存のKongユーザー以外には積極的におすすめしません。
正直なところ、社員数50人以下のスタートアップなら、ゲートウェイは不要です。Bedrock・Vertex AIに直接つなぎ、CloudTrail・Cloud Auditで十分です。ゲートウェイが必要になるのは、複数事業部・複数モデルプロバイダ・厳格なPII検査が必要になる、いわゆる「中堅以上のエンタープライズ」からです。最初はシンプルに始めて、痛みが出てから入れる。その順番がいちばん事故が少ないと感じています。
データ主権と東京リージョン保管要件、APPIとFISCの観点で何を選ぶか
最後に、いちばん相談が多いテーマです。「データを日本国内に置きたい。Claude Codeで本当に置けますか」。
結論から言います。AWS Bedrockなら東京・大阪に閉じる構成が組めます。Vertex AIならasia-northeast1（東京）に閉じる構成が組めます。Anthropic直契約は、現時点ではこの保証ができません。
Bedrockの「jp.」プレフィックス推論プロファイル（jp.anthropic.claude-sonnet-4-5-20250929-v1:0）は、リクエストとレスポンスを東京（ap-northeast-1）と大阪（ap-northeast-3）の2リージョン内に閉じます。この2リージョン間の通信もAWS Global Networkに乗るので、パブリックインターネットを経由しません。FISC安全対策基準の「重要情報の暗号化保管」「越境データ移転の制限」を意識する金融機関にとって、これは決定的に重要なポイントです。Anthropicも明言しています。Bedrock経由で投入されたプロンプトと出力は、Anthropicのモデル学習に使われない、と。
Vertex AI側のasia-northeast1は単一リージョンに閉じる構成が組めます。CLOUD_ML_REGIONにasia-northeast1を指定し、VPC SC境界をかぶせれば、Claude Sonnet 4.5のリクエストは東京から出ません。VPC SC境界はGCPプロジェクトの組織レベルで管理されるため、開発者が誤って別リージョンを指定しても境界の外には出られない、という安全装置として機能します。
APPI（個人情報保護法）の「越境移転」条項に関しては、両者ともAWSとGoogle Cloudが日本国内のリージョンに閉じ込めることで、原則として越境移転に該当しないと整理できます。ただし、第三者提供の同意取得や安全管理措置の文書化は別途必要で、この部分はゲートウェイ層やZEROCKのような国内データ主権基盤で補完するのが現実的です。
個人的には、この領域で「Anthropic直契約 vs Bedrock vs Vertex AI」を悩んでいる時間がもったいない、とさえ感じます。組織の主インフラがAWSならBedrock、GCPならVertex AI、両方混在なら主要な開発組織が乗っているほうに寄せる。それで答えは出ます。あとはCloudTrailやCloud Auditのログ取得設定、KMSやCloud KMSのCMK利用、PrivateLinkやPSCの徹底という、3点セットを丁寧に組むだけです。逆にこの3点を入れない構成は、いくら「Bedrockだから安心」と言っても、監査の現場では通用しません。
現場でClaude Codeをエンタープライズ展開しようとすると、最終的にはコード生成のスピードよりも、「事故が起きたときにログから何が再現できるか」が問われます。CloudTrailのInvokeModelイベント、CloudWatch Logsのプロンプト全文、Cloud Audit LogsのData Access Logs、Vertex AIのRequest-Response Logging。この4種類が揃っていれば、よほどのことがない限りインシデント対応は回ります。
まとめ：Claude Codeの本番展開は「インフラに寄せる」のが正解
ここまでBedrock経由・Vertex AI経由のClaude Code実装、ゲートウェイ層、データ主権までを駆け足で見てきました。要点を最後に整理します。
- AWS主体ならBedrock経由：CLAUDE_CODE_USE_BEDROCK=1、jp.プレフィックス推論プロファイル、PrivateLink、CloudTrail、CMK暗号化ロググループ、SSO + IAMロールの組み合わせが標準形
- GCP主体ならVertex AI経由：CLAUDE_CODE_USE_VERTEX=1、asia-northeast1、Service Account（roles/aiplatform.user）、VPC Service Controls境界、Data Access Logs有効化、PSCの組み合わせが標準形
- ゲートウェイ層は中堅以上から：LiteLLM（コスト・RBAC重視）、Helicone（観測性重視）、Kong AI Gateway（既存Kong統合）の3択
- データ主権：Bedrockの「jp.」プレフィックスとVertex AIのasia-northeast1がある以上、東京リージョンに閉じる選択肢は揃っている
- 最初の3点セット：CloudTrailやCloud Auditのログ、KMSやCloud KMSのCMK、PrivateLinkやPSCの私設経路。この3点が揃っていない構成は監査で必ず指摘される
TIMEWELLでは、ZEROCKというエンタープライズAI基盤を提供しています。AWS国内サーバーで動作し、GraphRAGによるナレッジコントロール、組織内のプロンプトライブラリ管理、Claude CodeをはじめとするエージェントAIとの統合を一気通貫で扱える設計です。Claude Codeの法人展開で「自社で全部組むのは現実的じゃない」「とにかく早く本番投入したい」という相談には、ZEROCK側で監査・ナレッジ・ゲートウェイ層をパッケージで提供する選択肢があります。AIコンサルティングのWARPでは、Bedrock移行やVertex AI移行の現場アセスメントから運用設計までを、月次で伴走する形で支援しています。
Claude Codeは便利な道具ですが、エンタープライズで使うなら、道具より先に「どのインフラに寄せるか」を決める必要があります。インフラを決めれば、IAMもログも暗号化も、すべて既存の延長線上で済む。ここを押さえないまま「とりあえず使ってみる」と、必ず半年後にリビルドする羽目になります。先に設計しましょう。
関連記事としてClaude Code法人活用の全体像はこちら、エージェント並列開発の実装パターンはこちら、ナレッジコントロールの観点からの整理はこちらも合わせてご覧ください。
参考文献
[^1]: Anthropic, "Claude Code on Amazon Bedrock", https://code.claude.com/docs/en/amazon-bedrock [^2]: Anthropic, "Claude Code on Google Vertex AI", https://code.claude.com/docs/en/google-vertex-ai [^3]: AWS, "Introducing Amazon Bedrock cross-Region inference for Claude Sonnet 4.5 and Haiku 4.5 in Japan and Australia", https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-cross-region-inference-for-claude-sonnet-4-5-and-haiku-4-5-in-japan-and-australia/ [^4]: AWS, "Monitor Amazon Bedrock API calls using CloudTrail", https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html [^5]: Google Cloud, "Vertex AI audit logging information", https://docs.cloud.google.com/vertex-ai/docs/general/audit-logging [^6]: AWS Solutions Library, "Guidance for Claude Code with Amazon Bedrock", https://github.com/aws-solutions-library-samples/guidance-for-claude-code-with-amazon-bedrock [^7]: BerriAI, "LiteLLM: Python SDK, Proxy Server (LLM Gateway)", https://github.com/BerriAI/litellm [^8]: Helicone, "Claude Code with Helicone", https://docs.helicone.ai/integrations/anthropic/claude-code