Claude Platform on AWSへ移行する — Bedrockからの差分と落とし穴

Amazon BedrockでClaudeを呼んでいるコードをClaude Platform on AWSへ移すと、リクエスト本文はほぼそのままで、宛先・署名・モデルID・ヘッダーが変わります。認証の仕組み自体はAWS IAMのSigV4のままです。落とし穴は、コードの外にある設定と契約に集中しています。

先に結論を並べます。

• 初めて使うAWSアカウントでは、outbound web identity federationを有効にしないと全リクエストが失敗します
• ZDR(ゼロデータ保持)は自動では付かず、Anthropicの担当者への申請になります
• Bedrockの割引・プライベートオファーは自動では引き継がれません
• 新しいAnthropic organizationが作られ、既存のAPIキーやworkspaceは持ち越せません

何が変わるのか — 現行のBedrock統合との差分表

移行元が「現行のBedrock統合」(bedrock-mantleのMessages API)か、「従来のInvokeModel/Converse」かで書き換え量が違います。ドキュメントの対比表から、コードに効く行を抜き出します。

現行のBedrock統合を使っているなら、リクエスト本文はすでにMessages APIの形です。変更点はベースURL、SigV4のサービス名、モデルID、anthropic-workspace-idヘッダーの4つに絞れます。従来のInvokeModelやConverseから来る場合は、これに加えてリクエストとレスポンスの形をMessages APIへ書き直します。

SDKのパッケージも入れ替えます。PythonならBedrock側のanthropic[bedrock]からanthropic[aws]へ、TypeScriptなら@anthropic-ai/bedrock-sdkから@anthropic-ai/aws-sdkへ変わります。クライアントクラスはBedrock側がAnthropicBedrockMantle、移行先がAnthropicAWS(TypeScriptではAnthropicAws)です。なおドキュメントによると、この移行先のSDKクライアントはbeta扱いです。

書き換え例 — cURLとPython

現行のBedrockをcURLで呼ぶ例と、移行後の例を並べます。差が出るのは宛先、--aws-sigv4の最後の要素、モデルID、ヘッダーの4か所です。例のリージョンは、移行前がus-east-1、移行後がus-west-2です。

# Bedrock(現行)
curl https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages \
  --aws-sigv4 "aws:amz:us-east-1:bedrock-mantle" \
  --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
  -H "x-amz-security-token: $AWS_SESSION_TOKEN" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "anthropic.claude-opus-5-5", "max_tokens": 1024,
       "messages": [{"role": "user", "content": "Hello, Claude"}]}'

# Claude Platform on AWS
curl "https://aws-external-anthropic.us-west-2.api.aws/v1/messages" \
  --aws-sigv4 "aws:amz:us-west-2:aws-external-anthropic" \
  --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
  -H "x-amz-security-token: $AWS_SESSION_TOKEN" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-workspace-id: $ANTHROPIC_AWS_WORKSPACE_ID" \
  -d '{"model": "claude-sonnet-5-5", "max_tokens": 1024,
       "messages": [{"role": "user", "content": "Hello!"}]}'

SDKを使っているなら、書き換えはクライアントの生成部分だけで済みます。

# Before: Bedrock
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
 
# After: Claude Platform on AWS
from anthropic import AnthropicAWS
client = AnthropicAWS()  # ANTHROPIC_AWS_WORKSPACE_ID と AWS_REGION を環境変数から読む

AnthropicAWSは、SigV4署名、リージョンに応じたベースURLの組み立て、anthropic-workspace-idヘッダーの付与を引き受けます。リージョンは必須で、未設定だとクライアントがエラーを出します。AWS_REGION(またはAWS_DEFAULT_REGION)を設定するか、クライアント生成時に渡します。

モデルIDはClaude APIと同じ文字列です。Bedrock形式のARNやanthropic.プレフィックスはありません。コードにモデルIDをべた書きしている箇所があれば、この置換が漏れやすい場所になります。

先にやること — outbound web identity federationの有効化

最初の落とし穴です。Claude Platform on AWSのゲートウェイは、AnthropicへJWTを渡すためにサーバー側でsts:GetWebIdentityTokenを呼びます。このSTSの機能は、どのAWSアカウントでも初期状態で無効です。Bedrockでは不要だった手順なので、移行の段取りから抜け落ちやすいところです。

有効化はアカウントごとに1回だけです。

aws iam enable-outbound-web-identity-federation
 
# 有効かどうかとissuer URLの確認
aws iam get-outbound-web-identity-federation-info

未設定のまま呼ぶと、全リクエストがOutbound web identity federation is disabled for your accountというエラーになります。ドキュメントはこれを最も多いセットアップエラーとしています。すでに有効なアカウントでコマンドを実行するとFeatureEnabled ... already enabledが返るので、その場合は何もせず次へ進めます。

サインアップ画面でFailed to enable OutboundWebIdentityFederationというバナーが出た場合は、もう一度Continueを選びます。IAM側の有効化が反映されるまで少し時間がかかるためです。

新しいorganizationとworkspace IDを用意する

AWSコンソールからサインアップすると、AWSアカウントに紐づいた新しいAnthropic organizationが作られます。既存のorganizationは変換できません。ファーストパーティのAPIキー、workspace、Claude Consoleの設定は持ち越せないので、新しい側で作り直します。

組織が分かれる利点もあります。新旧のorganizationは独立しているため、両方で同時にトラフィックを受けられます。ドキュメントも、一括で切り替えずに段階的に寄せる進め方を示しています。

リクエストに必要なanthropic-workspace-idは、AWSコンソールのサービスページか、Claude ConsoleのWorkspacesで確認します。形式はwrkspc_で始まる文字列です。workspaceは単一のAWSリージョンに紐づくため、複数リージョンで運用するときはリージョンごとにIDを用意します。

export ANTHROPIC_AWS_WORKSPACE_ID='wrkspc_01AbCdEf23GhIj'
export AWS_REGION='us-west-2'  # workspaceのリージョン

IAMポリシー側も見直します。推論にはaws-external-anthropic:CreateInferenceをworkspaceに対して許可し、APIキー認証を使う場合はaws-external-anthropic:CallWithBearerTokenも必要です。アクションの一覧と最小権限の書き方はClaude Platform on AWSのIAMアクション一覧にまとめています。Claude Codeを載せ替える場合の設定はClaude Platform on AWSでClaude Codeを使う方法が扱っています。

契約まわりの落とし穴 — ZDR・割引・規約

ZDRは申請制になる

BedrockではAWSがデータ処理者で、Anthropicは推論の入力と出力を保持しません。AnthropicのZDRプログラムはBedrockには適用されない、という整理です。

Claude Platform on AWSでは、Anthropicが独立したデータ処理者として推論データを扱います。ZDRはファーストパーティのClaude APIと同じ方式で、Anthropicの担当者に依頼して有効にします。データ保持の保証に依存する本番ワークロードは、ZDRの登録を確認してから移すことが求められています。

割引とプライベートオファーは移らない

Bedrockで交渉した割引や、AWS Marketplaceのプライベートオファーは、Claude Platform on AWSへ自動では引き継がれません。新しい条件はAnthropicの担当者と詰めます。

既存のBedrockプライベートオファーがある場合は、サインアップの前に担当者へ連絡するよう案内されています。割引はオファーの受諾時点から適用され、受諾前に発生した利用にさかのぼっては適用されないためです。

規約と請求の違い

Anthropicの商用規約と利用ポリシーへの同意が必要です。Bedrockだけを使ってきた組織は、アカウント設定の途中で同意を求められます。請求はAWSのネイティブサービスからAWS Marketplace経由に変わります。利用量はClaude Consumption Unit(CCU)で計測され、時間単位で集計して翌月に請求書へ載ります。前払いのクレジットではなく、残高やコミットメントはありません。一方で、AWS上で請求書が発行される点と、AWSのコミットメント消化の扱いは変わりません。

料金の水準そのものはBedrockの価格と別の話です。比較はBedrockのClaude料金の解説で扱っています。

使える機能と使えない機能が入れ替わる

移行先は、Claude APIのエンドポイントをそのまま使う構成です。Bedrock側で使えなかった機能の多くが使えるようになります。

移行で得られるものは、新しいモデルと機能への同日対応、Agent Skills、Anthropic管理のサンドボックスでのコード実行、anthropic-betaヘッダー経由のベータ機能、Claude Consoleでの利用量の確認、Anthropicによる直接サポート、SigV4の代わりに使えるAPIキー認証です。

逆に、移行先で消える・使えない側に注意が必要です。

• コンプライアンス: HIPAA-readyは使えません。FedRAMP High、IL4、IL5、HIPAA-readyが要件の組織や、AWSを唯一のデータ処理者にしたい組織には、ドキュメントがBedrockを選ぶよう案内しています
• Admin API: workspaceと外部キーのエンドポイントだけが使えます。組織メンバー、招待、APIキー、使用量・コスト・レート制限のレポートは使えず、利用量はClaude Consoleで見ます。メンバー管理はAWS IAMに移ります
• ツール: computer_toolset_20260801とbrowser_toolset_20260801は使えません。ベータ版のコンピューター操作ツールは、一部のモデルで引き続き使えます
• MCP tunnels: 公開インターネット上のMCPサーバーだけが対象です
• 認証: OAuthは使えず、SigV4かAPIキーのどちらかになります

Bedrock側との機能差を一覧で見たい場合は、BedrockとGoogle Cloudの機能対応の比較も参照できます。

切り替え後に効くレート制限と支出上限

新しいorganizationはStart tierから始まります。レート制限はAWSのクォータ体系ではなくAnthropicが管理します。Bedrockで得ていた上限が、そのまま移るわけではありません。

Console上の「Request tier increase」は使えず、引き上げは担当者かAnthropic supportへの依頼になります。依頼には次の情報を添えるよう求められています。

• 引き上げたいモデル
• モデルごとの、ピーク時の入力・出力トークン毎分(日次の合計ではない)
• 入力のうち、キャッシュまたは繰り返しのコンテキストが占めるおおよその割合

もう1つ見落としやすいのが、各tierに付く月間の支出上限です。月の利用額が上限に達すると、翌月1日の00:00 UTCまでAPIリクエストが失敗します。再試行しても通りません。支出の集計には2時間ほどかかるため、上限を超えた分が請求されることもあります。

自分で設定する組織・workspaceの支出上限は、Billingページに通知先メールを1件以上登録したあとで設定できます。上限に達したときの通知は、登録した宛先に届きます。「管理者全員」のようなロール指定の宛先は使えません。

移行の手順 — 順番がある

移行しないほうがよい場合

移行の動機が機能面(Agent Skills、コード実行、新モデルへの同日対応)にあるなら、Claude Platform on AWSは筋が通ります。逆に、AWSを唯一のデータ処理者にしたい、FedRAMPやHIPAA-readyが要件にある、という場合は、ドキュメント自身がBedrockを選ぶ条件として挙げています。

両方の併用も想定された構成です。Claude Platform on AWSはファーストパーティのClaude APIやBedrockとは別のキャパシティプールを持つため、複数のプラットフォームで動かして障害時に切り替えることもできます。Bedrock側の使い方はAmazon BedrockでClaudeを使う方法にあります。

よくある質問

既存のBedrock用IAMポリシーはそのまま使えますか

移行先で許可するのはaws-external-anthropic:CreateInferenceなどのaws-external-anthropic:アクションで、対象はworkspaceです。IAM自体は引き続き使いますが、ポリシーは移行先のアクションで書き直します。

移行中、Bedrockの請求はどうなりますか

新旧は独立して動き、既存側は従来どおり請求されます。Claude Platform on AWS側の利用はAWS Marketplace経由で別に請求されます。