Claude Platform on AWSでClaude Codeを使う — Bedrockとの違い

Claude Platform on AWSは、AWS Marketplaceで契約しながら中身はAnthropicが直接運用するClaude APIを呼び出す提供形態です。Amazon Bedrockとは別物です。モデルカタログを介さずAnthropicのAPIへ直接リクエストが届くため、機能面では直接APIとほぼ同じ挙動になり、Bedrockで外れる一部機能もこちらでは使えます。認証はAWS認証情報、支払いはAWS Marketplace経由という、Bedrockと似た運用の型に、直接APIに近い機能セットを載せた構成です。

Claude Platform on AWSとは何か

Claude Platform on AWSは、AWSのIAMとMarketplace請求を使いながら、リクエスト自体はAnthropicのAPIサーバーへ直接届く提供形態です。Amazon Bedrockのようにモデルカタログを経由しません。同じモデル・同じAPI機能を、直接APIと同一のリリーススケジュールで受け取れます。認証はAWS認証情報かワークスペースAPIキー、支払いはAWS Marketplace経由です。

AWS Marketplaceでの契約は、既存のAnthropic組織とは別の新しい組織を作ります。すでにClaude Consoleのアカウントを持っていても、認証情報はそちらとは共有されません。AWS連携組織のワークスペースIDとAPIキーを使う必要があります。

Claude Codeが機能フラグサービス経由で有効にするクライアント側機能は既定でオフになり、Advisor機能も使えません。可用性の詳細は後述の比較表で確認します。

導入前に確認すること

設定を始める前に、次がすべて揃っているか確認します。

• 有効なClaude Platform on AWSのサブスクリプション(AWS Marketplace経由)
• AWS連携Anthropic組織内のワークスペースとそのワークスペースID
• Anthropicサービスを呼び出せるIAMプリンシパル、またはワークスペースにスコープされたAPIキー
• 環境変数・~/.aws/credentials・アタッチされたIAMロールのいずれかにあるAWS認証情報(SigV4認証を使う場合)。AWS CLIが必要なのはSSOログインのフローだけです

認証方式を選ぶ

Claude Codeは2つの認証方式に対応します。チームの認証情報管理の方針に合わせて選びます。

方式A: AWS認証情報とSigV4

環境変数・~/.aws/credentialsの共有認証情報・IAMロール・AWS SSOセッションなど、AWS SDKが対応する標準の認証情報チェーンを使ってSigV4署名でリクエストします。ローカル利用ではClaude Code起動前にAWS CLIでログインします。

aws sso login --profile my-profile
export AWS_PROFILE=my-profile

CIや自動化では、Anthropicサービスを呼び出せる権限を持つIAMロールをランナーに付与し、AWS_REGIONを設定します。認証情報チェーンが自動的にロールを拾います。

SSO認証情報がセッション途中で失効する場合は、awsAuthRefreshを設定しておくとClaude Codeがログインコマンドを再実行してリトライします。自動リフレッシュにはClaude Code v2.1.198以降が必要です。それより前のバージョンでは/loginを促すプロンプトで止まり、これはAWS認証情報をリフレッシュできません。

{
  "awsAuthRefresh": "aws sso login --profile my-profile"
}

設定後は/loginから「3rd-party platform」→「Claude Platform on AWS · refresh credentials」を選ぶと、再起動なしで認証情報を読み直せます(v2.1.186以降が必要)。

方式B: ワークスペースAPIキー

フェデレーションされたAWS認証情報を管理したくない場合の長期的なシークレットです。AWSコンソールの「Claude Platform on AWS → API keys」で発行し、ANTHROPIC_AWS_API_KEYに設定します。

export ANTHROPIC_AWS_API_KEY=sk-ant-xxxxx

このキーはx-api-keyとして送られ、SigV4より優先されます。環境にAWS認証情報があっても無視される点に注意します。別のClaude Consoleの組織で発行したAPIキーはここでは使えません。本番用の認証情報として扱い、ユーザー設定ファイルのenvブロックでマシン単位にスコープするのが手軽です。

/login・/logoutコマンドはClaude Platform on AWSに対してはClaude.aiサブスクリプションへのサインインを行いません。認証は常にAWS認証情報かワークスペースAPIキー経由です。

Claude Codeを設定する

Claude Codeの向き先をClaude Platform on AWSに切り替える環境変数を設定します。

export CLAUDE_CODE_USE_ANTHROPIC_AWS=1
export ANTHROPIC_AWS_WORKSPACE_ID=wrkspc_01ABCDEFGHIJKLMN
export AWS_REGION=us-east-1

ANTHROPIC_AWS_WORKSPACE_IDは必須です。すべてのリクエストでanthropic-workspace-idヘッダーとして送られます。例のIDは自分のセットアップで取得したワークスペースIDに置き換えます。

ベースURLはhttps://aws-external-anthropic.{region}.api.awsの形でAWSリージョンから自動的に組み立てられ、リージョンの解決順序はAmazon Bedrockと同じです。直接上書きしたい場合はANTHROPIC_AWS_BASE_URLを設定します。

AWS認証情報が環境にあってもClaude Platform on AWSはオプトインです。Amazon BedrockとMicrosoft Foundryはプロバイダールーティングで優先されるため、CLAUDE_CODE_USE_BEDROCKとCLAUDE_CODE_USE_FOUNDRYが設定されていれば解除しておきます。

モデルバージョンを固定する

Claude Platform on AWSは直接APIと同じモデルIDを使います。既定のエイリアスfable・opus・sonnet・haikuはClaude Code組み込みの既定モデルに解決され、最新リリースより遅れることがあります。ANTHROPIC_DEFAULT_OPUS_MODELを設定しなければ、opusはOpus 5に解決されます(v2.1.219より前はOpus 4.8、v2.1.207より前はOpus 4.7でした)。

チームに展開する場合は、新しいリリースで全員が一斉に切り替わらないよう明示的にピン留めします。

export ANTHROPIC_DEFAULT_FABLE_MODEL=claude-fable-5
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-8
export ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5

プロンプトキャッシュは自動的に有効になります。既定の5分ではなく1時間のTTLを使いたい場合はENABLE_PROMPT_CACHING_1H=1を設定します(1時間キャッシュの書き込みはより高い単価で課金されます)。

起動して確認する

Claude Codeを起動し、ルーティングを確認します。

claude

起動時のバナーにClaude Platform on AWSと表示されればプロバイダーが有効になっています。/statusを実行すると、API provider行がClaude Platform on AWSになっているか、ワークスペースID・AWSリージョン・(設定していれば)ベースURLの上書きが確認できます。

Agent SDKから使う

Agent SDKはCLIと同じ環境変数を読むため、Claude Codeのサブプロセスを起動するプログラムはどれも同じ変数をエクスポートするだけでClaude Platform on AWSを使えます。

import { query } from "@anthropic-ai/claude-agent-sdk";
 
process.env.CLAUDE_CODE_USE_ANTHROPIC_AWS = "1";
process.env.ANTHROPIC_AWS_WORKSPACE_ID = "wrkspc_01ABCDEFGHIJKLMN";
process.env.AWS_REGION = "us-east-1";
 
for await (const msg of query({ prompt: "What's in this repo?" })) {
  console.log(msg);
}

この例はSigV4署名を環境にあるAWS認証情報チェーンに任せています。ワークスペースAPIキーで認証したい場合も同じ要領でANTHROPIC_AWS_API_KEYを設定します。

企業プロキシ経由でルーティングする

トラフィックをプロキシやLLMゲートウェイ経由にするには、ANTHROPIC_AWS_BASE_URLをプロキシのアドレスに設定します。同じワークスペース・認証ヘッダーが転送先に届くため、それらをそのまま中継するゲートウェイならどれでも動作します。

ゲートウェイ側でリクエストに自分で署名する場合は、CLAUDE_CODE_SKIP_ANTHROPIC_AWS_AUTH=1を設定するとClaude Codeは未署名のリクエストを送り、ゲートウェイがSigV4ヘッダーを付けてAWSへ転送する構成になります。ゲートウェイ自体に独自のトークンが必要な場合はANTHROPIC_AUTH_TOKENに設定します。

Amazon Bedrock・他プロバイダーとの機能差

Claude Platform on AWSはAWS経由という点でAmazon Bedrockと似ていますが、リクエストがAnthropicへ直接届く分、機能セットは直接APIに近くなります。両者の違いを機能単位で並べると、認証方式の共通点だけでは見えない差が出ます。

Web検索がBedrockでは使えずClaude Platform on AWSでは使える点、逆にクラウドセッションの代替としてBedrockはGitHub ActionsとGitLab CI/CDの両方が使えるのにClaude Platform on AWSはGitLab CI/CDしか使えない点が、認証方式の類似性からは想像しにくい実務上の分かれ目です。GitHub Actionsでワークフロー化するなら、Bedrockか直接APIが選択肢になります。Web検索を使うエージェントを動かすなら、Claude Platform on AWSに分があります。

/design-syncとclaude importサブコマンド(/import)は、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・Claude Platform on AWSのいずれでも利用できません。ChannelsやRoutines・Remote Control・Code Reviewなど、Claude.aiサブスクリプションを必要とする機能全般もどのサードパーティプロバイダーでも使えない点は共通です。加えて、analytics dashboardとserver-managed settingsはこれらとは別枠で、Claude Platform on AWSを含むいずれのサードパーティプロバイダーでも利用できません。特にserver-managed settingsが使えない点は、組織全体の設定をサーバー側で一括管理したいエンタープライズ導入の判断材料になります。

組み込みのExploreサブエージェントは、Claude APIではOpusに上限を固定しますが、Claude Platform on AWSを含む他プロバイダーではメインの会話と同じモデルをそのまま継承します。細かな挙動差ですが、コスト設計に影響します。

このほかにも面ごとの可用性差があります。定期実行を組む/scheduleはClaude Platform on AWSでは使えず、代わりに/loopを使います。セッション間でメッセージをやり取りするCross-session messagingは、他の多くの機能が「利用不可」か「利用可能」で割り切れるのに対して唯一の部分対応で、同一マシン内のセッション間に限られます。エラーレポートとテレメトリの送信は、Claude Platform on AWS・Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryの4プロバイダーいずれでも既定でオフになっています。

トラブルシューティング

/statusを実行すると、解決されたプロバイダーと明示設定したワークスペースID・リージョン・ベースURLの上書き・認証スキップ設定が確認できます。まずここでClaude CodeがClaude Platform on AWSを向いているかどうかを見ます。

すべてのリクエストで403 ForbiddenやAccessDeniedが出る場合、解決されたIAMプリンシパルにワークスペース内でAnthropicサービスを呼び出す権限が無い可能性があります。AWSプロファイルやランナーに付いたロールを確認し、aws-external-anthropicで始まるIAMアクションが付与されているかを見ます。ANTHROPIC_AWS_API_KEYを設定している場合、そのキーはSigV4より優先されるため、キーが古くなっていても同じエラーになります。AWSコンソールでキーを再発行するか、変数を解除してAWS認証情報にフォールバックさせます。

ANTHROPIC_AWS_WORKSPACE_IDが未設定か空だと、ワークスペース不足のエラーで失敗します。すべてのリクエストにワークスペースIDが必須で、AWS認証情報からは推測されません。

CLAUDE_CODE_USE_ANTHROPIC_AWSが未設定か、真として解釈される値になっていないと、リクエストがapi.anthropic.comに向かってしまいます。1を設定して/statusで確認します。CLAUDE_CODE_USE_BEDROCKやCLAUDE_CODE_USE_FOUNDRYも設定されている場合は、そちらがClaude Platform on AWSより優先されます。

まとめ

Claude Platform on AWSは、AWS認証・IAM・AWS Marketplace請求という運用の型をAmazon Bedrockと共有しながら、リクエストの中身はAnthropicのAPIに直接届くという提供形態です。SigV4認証かワークスペースAPIキーのどちらかで接続し、CLAUDE_CODE_USE_ANTHROPIC_AWS・ANTHROPIC_AWS_WORKSPACE_ID・AWS_REGIONの3つを設定すれば最小構成が動きます。

Bedrockとの実務上の分かれ目は機能セットです。Web検索が使える一方でGitHub Actions連携の代替が使えない、という非対称な差があるため、既にBedrockを使っているチームが乗り換える前には、上の比較表で自分たちが依存している機能を確認しておく価値があります。Amazon Bedrock経由の料金体系はAWS BedrockのClaude料金は直接APIとどう違うか、Bedrock側の対話セットアップはClaude Code Bedrockセットアップ、VS Code拡張でのサードパーティプロバイダー設定はVS Code拡張でサードパーティプロバイダーを使う設定にまとめています。

よくある質問

Claude Platform on AWSとAmazon Bedrockはどちらが安いですか

Claude Platform on AWSの料金はAWS Marketplaceの契約条件で決まります。比較する場合は契約前にAWS Marketplace側の見積もりを取得してください。

既存のClaude Consoleアカウントの認証情報を流用できますか

できません。AWS Marketplaceでのサブスクリプションは、AWSアカウントに紐づいた新しいAnthropic組織を作ります。既存の組織とは別物で、認証情報は共有されません。AWS連携組織のワークスペースIDとAPIキーを使う必要があります。

/loginでClaude.aiにサインインできますか

Claude Platform on AWSに対しては/login・/logoutコマンドはClaude.aiサブスクリプションへのサインインを行いません。認証は常にAWS認証情報かワークスペースAPIキー経由です。/loginから選べる「refresh credentials」はAWS認証情報の再読み込みであり、Claude.aiへのサインインとは別の操作です。

Amazon Bedrockと同時に設定してしまった場合どうなりますか

Amazon BedrockとMicrosoft Foundryは、プロバイダールーティングでClaude Platform on AWSより優先されます。CLAUDE_CODE_USE_BEDROCKやCLAUDE_CODE_USE_FOUNDRYが設定されたままだと、CLAUDE_CODE_USE_ANTHROPIC_AWS=1を設定してもリクエストはBedrockやFoundryへ向かいます。切り替えたい場合はそれらの変数を解除してください。