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

Claude Platform on AWSとは、AWS Marketplaceで契約しながら、中身はAnthropicが直接運用するClaude APIを呼び出す提供形態です。Claude CodeではCLAUDE_CODE_USE_ANTHROPIC_AWS=1を設定し、ワークスペースIDを渡すと使えます。

Amazon Bedrockとは別物で、Bedrockでは外れるWeb検索がこちらでは使えます。逆にGitHub Actionsはこちらでは使えません。Claude Codeで乗り換えや新規導入を考えるなら、設定より先に「自分たちが依存している機能はどちらで動くか」を確認するのが近道です。

Claude Platform on AWSとは何か

AWSの認証情報・IAM・Marketplace請求を使いながら、AnthropicのAPIを直接呼ぶ仕組みです。AWSで契約と支払いが済む点はBedrockと似ていますが、呼び出し先が違います。

リクエストはAnthropicのAPIサーバーへ直接届きます。Amazon Bedrockのようにモデルカタログを経由しないため、同じモデルと同じAPI機能を直接APIと同じリリーススケジュールで受け取れます。認証はAWS認証情報かワークスペースAPIキー、支払いはAWS Marketplace経由です。

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

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

Bedrockと比べて何が使えて何が使えないか

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

Auto modeはBedrockと違い、Claude Platform on AWSの欄にモデル制限の注記がありません。一方Desktopは、Claude Platform on AWSでは使えません。Claude Desktop on 3PがCodeタブを動かせるのはBedrock・Google CloudのAgent Platform・Microsoft Foundry・自前のLLMゲートウェイで、Claude Platform on AWSは含まれないためです。Desktopで使う前提の導入は、この時点で選択肢から外れます。

依存機能から選ぶ場合の切り分けは次のとおりです。GitHub Actionsでワークフロー化するなら、Bedrockか直接APIが選択肢になります。Web検索を使うエージェントを動かすなら、Claude Platform on AWSに分があります。どちらも要らず、AWS請求にまとめたいだけなら、機能差は表の残りの行だけです。

/design-syncとclaude importサブコマンド(/import)は、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・Claude Platform on AWSのいずれでも利用できません。Routines・Remote Control・Code ReviewなどClaude.aiサブスクリプションを必要とする機能と、Channelsは、どのサードパーティプロバイダーでも使えない点は共通です。加えて、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の欄で唯一「部分対応」に分類されており、同一マシン内のセッション間に限られます。v2.1.248以降が必要です。エラーレポートとテレメトリの送信は、Claude Platform on AWS・Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryの4プロバイダーいずれでも既定でオフになっています。

導入前に確認すること

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

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

AWS上でClaude Codeを動かす環境としてCloud9を使う場合は、既定のインスタンスが小さいため、AWS Cloud9でのインスタンス要件も先に確認しておきます。

認証方式を選ぶ

Claude Codeは2つの認証方式に対応します。違いは「AWSの認証情報チェーンに乗るか、長期シークレットを1つ持つか」です。

方式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以降が必要)。awsAuthRefreshのコマンドは、既存の認証情報を検証できない起動時にも実行されます。ログインが終わるまで、コマンドの出力はAuthenticationパネルに表示されます。

方式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キー経由です。/loginから選べる「refresh credentials」はAWS認証情報の再読み込みで、Claude.aiへのサインインとは別の操作です。

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が指すモデルはClaude Codeのバージョンで変わってきました。

Claude Codeを更新すると、ピン留めしていないチームのメンバーは同じ操作のまま別のモデルへ移ります。

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

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の上書きが確認できます。

実機で確認できた範囲(v2.1.285)

手元のClaude Code v2.1.285でclaude --helpを確認したところ、--bare(フック・CLAUDE.mdの自動探索・キーチェーン読み取りなどを飛ばす最小モード)の説明は、認証について次のように書いています。

Anthropic auth is strictly ANTHROPIC_API_KEY or apiKeyHelper via --settings
(OAuth and keychain are never read). 3P providers (Bedrock/Vertex/Foundry)
use their own credentials.

サードパーティプロバイダーとして名前が挙がるのはBedrock・Vertex・Foundryの3つで、Claude Platform on AWSは含まれていません。--bareとClaude Platform on AWSを組み合わせたときにどの認証が使われるかは、helpにも公式ページにも書かれていません。

なお、環境変数リファレンスによると、バイト単位のストリーミング無応答ウォッチドッグ(CLAUDE_ENABLE_BYTE_WATCHDOG)は、未設定なら直接APIとClaude Platform on AWSの接続で既定で有効です。ANTHROPIC_AWS_BASE_URL経由のゲートウェイ接続でも、ストリーミング応答には効きます。v2.1.222より前は、このゲートウェイ接続では動いていませんでした。

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に設定します。

トラブルシューティング

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

まとめ

最小構成はCLAUDE_CODE_USE_ANTHROPIC_AWS・ANTHROPIC_AWS_WORKSPACE_ID・AWS_REGIONの3つで、認証はSigV4かワークスペースAPIキーのどちらかです。Bedrockから移るかどうかは、Web検索とGitHub Actionsのどちらに依存しているかでほぼ決まります。

Amazon Bedrock経由の料金体系はAWS BedrockのClaude料金は直接APIとどう違うか、Bedrock側の対話セットアップはClaude Code Bedrockセットアップ、VS Code拡張でのサードパーティプロバイダー設定はVS Code拡張でサードパーティプロバイダーを使う設定にまとめています。