2026年10月2日時点の結論。Claude CodeをAmazon Bedrockで使う入口は2つある。個人や小さなチームなら、Bedrockコンソールでユースケースを申請したあと claude を起動し、ログイン画面で「3rd-party platform」→「Amazon Bedrock」を選ぶ(ログイン済みなら /setup-bedrock)。CIや全社展開なら、CLAUDE_CODE_USE_BEDROCK=1 などの環境変数で設定し、モデルIDを固定してから配る。固定しないと、Bedrockでは別名 opus がOpus 5.5、sonnet がSonnet 4.5に解決され、主モデルはOpus 5.5になる。公式ドキュメントは、OpusはSonnetより1トークンあたりの単価が高いと明記している(Claude Code on Amazon Bedrock)。
「claude code bedrock」で調べる人の困りごとは、だいたい3つに分かれる。どう繋ぐのか、繋いだあと sonnet が思っていたモデルにならないのはなぜか、そして料金はどこに付くのか。この記事では、Anthropic公式のClaude Codeドキュメントと、AWSのBedrockドキュメントに書かれている内容だけで、この3つを手順の順に整理する。
この記事の要点
接続と権限
- 入口は2つ:対話で済ませるならウィザード(ログイン画面の「Amazon Bedrock」または
/setup-bedrock)。CIや全社展開なら環境変数で手動設定。 - AWS側の前提:Bedrockコンソールの「Model catalog」でAnthropicのモデルを選び、ユースケースのフォームを1回出す。提出するとすぐにアクセスが付与される。
- IAM:
bedrock:InvokeModel・bedrock:InvokeModelWithResponseStream・bedrock:ListInferenceProfiles・bedrock:GetInferenceProfileと、Marketplaceの購読2つ。
モデルと料金
- モデル:未固定だと
opusはOpus 5.5、sonnetはSonnet 4.5。チームに配る前にANTHROPIC_DEFAULT_OPUS_MODELなどで固定する。 - 料金:Bedrock経由の推論はAWSアカウント側のAmazon Bedrockの料金で計上される。公式は、コスト追跡とアクセス管理のためにClaude Code専用のAWSアカウントを作ることを勧めている。
- 使えないもの:Bedrock接続では
/logoutとWebSearchツールが使えない。
読んでほしい人と今日やること
- 対象読者:AWSを使う開発チーム、開発環境をそろえるプラットフォーム担当、情報システム部門。
- 今日やること:Claude Codeで
/statusを開き、接続先とリージョンがどう解決されているかを確かめる。
手順1|AWS側でAnthropicのモデルを使えるようにする
用意するもの
公式ドキュメントが挙げる前提は4つだ。Amazon Bedrockが有効なAWSアカウント、使いたいClaudeモデルへのアクセス、適切なIAM権限、そしてAWS CLI(ほかの方法で認証情報を得られない場合だけ必要)。AWS CLIは必須ではない点を先に押さえておくと、配布用の手順書が短く書ける。
ユースケースの申請は1アカウントにつき1回
Anthropicのモデルを初めて呼ぶ前に、ユースケースの詳細を提出する。手順はBedrockコンソールを開き、「Model catalog」からAnthropicのモデルを選び、ユースケースのフォームを埋めるだけだ。公式ドキュメントには「提出後すぐにアクセスが付与される」と書かれている(Claude Code on Amazon Bedrock)。
AWS Organizationsを使っている場合は、管理アカウントから PutUseCaseForModelAccess APIで1回提出すれば、承認が子アカウントにも自動で広がる。この呼び出しには bedrock:PutUseCaseForModelAccess のIAM権限が要る。部署ごとにAWSアカウントを分けている組織では、各アカウントで個別にフォームを出すより、この経路で一度に済ませたほうが漏れが出ない。
手順2|/setup-bedrockのウィザードで接続する
ログイン画面から入る
AWSの認証情報がすでに手元にあるなら、ウィザードがClaude Code側の設定を引き受ける。claude を起動し、ログイン画面で「3rd-party platform」、続けて「Amazon Bedrock」を選ぶ。すでにサインイン済みでチャット画面が出る場合は、/setup-bedrock を入力してウィザードを開く。

ここで1つ詰まりやすい点がある。CLAUDE_CODE_USE_BEDROCK=1 が設定されるまで、/setup-bedrock はコマンドメニューに表示されない。候補に出てこなくても、コマンドを最後まで入力すれば開ける。
ウィザードが聞くこと
ウィザードは次の順で進む。
- 認証方法:
~/.awsから検出したAWSプロファイル、Amazon BedrockのAPIキー、アクセスキーとシークレット、環境にすでにある認証情報、の4つから選ぶ。 - リージョン:Bedrockを呼ぶリージョンを指定する。
- モデルの確認と固定:そのアカウントで呼べるClaudeモデルを確かめ、固定(ピン留め)できる。
結果はユーザー設定ファイル ~/.claude/settings.json の env ブロックに保存される(CLAUDE_CONFIG_DIR を設定している場合は $CLAUDE_CONFIG_DIR/settings.json)。自分で環境変数を export する必要はない。認証情報・リージョン・モデルの固定を後から変えたいときは、もう一度 /setup-bedrock を開けばよい。モデル固定の画面は、いま固定しているモデルから始まる。
接続後に変わること
Bedrock接続では、認証をAWSの認証情報で扱うため /logout が使えない。また、WebSearchツールはAmazon Bedrockでは利用できない。調べものをClaude Codeに頼る運用をしているチームは、ここで作業の流れが変わる点を先に共有しておきたい。
手順3|環境変数で手動設定する(CI・全社展開向け)
認証情報の渡し方は5つ
Claude CodeはAWS SDKの既定の認証情報チェーンを使う。公式ドキュメントが示す渡し方は次の5つだ。

# A: AWS CLIの設定
aws configure
# B: アクセスキーを環境変数で渡す
export AWS_ACCESS_KEY_ID=your-access-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-access-key
export AWS_SESSION_TOKEN=your-session-token
# C: SSOプロファイル
aws sso login --profile=your-profile-name
export AWS_PROFILE=your-profile-name
# D: AWSマネジメントコンソールの認証情報
aws login
# E: Amazon BedrockのAPIキー
export AWS_BEARER_TOKEN_BEDROCK=your-bedrock-api-key
BedrockのAPIキー(E)は、AWSの認証情報一式を用意せずに使える方法として案内されている。SSOプロファイル(C)の場合、Claude Codeはプロファイルの sso_region に書かれたIAM Identity Centerのリージョンへロールの認証情報を取りに行く。Bedrockを使うリージョンと一致している必要はない。
認証情報のキャッシュとタイムアウト
v2.1.207以降のClaude Codeは、解決した認証情報をメモリに持ち、有効期限の5分前まで(期限が無い場合は1時間)使い回す。APIから認証エラーが返るとキャッシュを捨てて取り直す。毎回解決させたい場合は CLAUDE_CODE_SKIP_AWS_CRED_CACHE=1 を設定する。なお、APIキー(E)はこのチェーンを通らないためキャッシュの対象外だ。
チェーンの解決は1回あたり60秒でタイムアウトする。MFA付きのブラウザSSOのように、正当に時間がかかる手順を挟む場合は、CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS でミリ秒単位の上限を引き上げる。
Bedrockを有効にする変数
# Bedrock連携を有効にする
export CLAUDE_CODE_USE_BEDROCK=1
# AWSプロファイルにリージョンが書かれていれば省略できる
export AWS_REGION=us-east-1
# 任意:カスタムのエンドポイントやゲートウェイを使う場合
# export ANTHROPIC_BEDROCK_BASE_URL=https://bedrock-runtime.us-east-1.amazonaws.com
AWS_PROFILE のように他のプロセスへ漏らしたくない値は、シェルではなく設定ファイルの env に書ける。設定ファイルの置き場所と優先順位は、Claude Codeのsettings.json設定ガイドにまとめている。
リージョンが決まる順番
AWS_REGION を書かなくても動くことが多いのは、Claude Codeが次の順でリージョンを探すからだ。
AWS_REGIONAWS_DEFAULT_REGION- プロファイルのregion(使用中のAWSプロファイルに書かれた値。共有認証情報ファイル、共有設定ファイルの順に読む)
us-east-1
使用中のプロファイルは、AWS_PROFILE があればそれ、無ければ default だ。どこかの値がリージョン名の形をしていない場合(スラッシュ・ドット・空白を含むなど)、その値は未設定とみなされ、次の候補に進む。解決されたリージョンは /status で確認でき、設定ファイルや既定値から来た場合はその出どころも表示される。「東京で動かしているつもりが us-east-1 だった」という取り違えは、/status を1回見れば防げる。
手順4|IAMポリシーを用意する
公式が示す最小構成
公式ドキュメントが示すIAMポリシーは、モデルと推論プロファイルへのアクセス、Marketplaceの購読の2つの文でできている。

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowModelAndInferenceProfileAccess",
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream",
"bedrock:ListInferenceProfiles",
"bedrock:GetInferenceProfile"
],
"Resource": [
"arn:aws:bedrock:*:*:inference-profile/*",
"arn:aws:bedrock:*:*:application-inference-profile/*",
"arn:aws:bedrock:*:*:foundation-model/*"
]
},
{
"Sid": "AllowMarketplaceSubscription",
"Effect": "Allow",
"Action": [
"aws-marketplace:ViewSubscriptions",
"aws-marketplace:Subscribe"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:CalledViaLast": "bedrock.amazonaws.com"
}
}
}
]
}
より絞りたい場合は、Resource を特定の推論プロファイルのARNに限定できる。
GetInferenceProfileを外すとどうなるか
bedrock:GetInferenceProfile は、アプリケーション推論プロファイルのARNから元のモデルを割り出し、そのモデルに合うリクエストの形を選ぶために使われる。この権限が無くても、Claude Codeは別の形で1回だけ再試行して成功させる。ただし新しいモデルごとに往復が1回増える。公式ドキュメントは、これが特に AWS_BEARER_TOKEN_BEDROCK(APIキー)で運用する場合に起きやすいと書いている。APIキーのポリシーはIAMロールより狭く作られがちだからだ。
Mantleエンドポイントは別の権限
BedrockにはMantleというエンドポイントもあり、ClaudeをAnthropic APIと同じ形で提供する。Mantleの権限は bedrock-mantle: という別の接頭辞で、上の bedrock: の権限ではカバーされない。推論には bedrock-mantle:CreateInference、トークン数の計算には bedrock-mantle:CountTokens を付ける。Mantleを使う場合は CLAUDE_CODE_USE_MANTLE=1 で有効にし、/status に「Amazon Bedrock (Mantle)」と表示されることを確かめる。
手順5|モデルを固定する(sonnetがSonnet 4.5になる理由)
接続先によって別名の行き先が違う
Bedrockで /model sonnet を選んで「新しいSonnetにならない」と感じたら、それは設定ミスではない。Claude Codeの別名は、接続先ごとに既定のモデルIDへ解決される。2026年10月2日時点の公式ドキュメント(Model configuration)では次のとおりだ。

| 接続先 | opus の行き先 |
sonnet の行き先 |
|---|---|---|
| Anthropic API | Opus 5.5 | Sonnet 5.5 |
| Amazon Bedrock | Opus 5.5 | Sonnet 4.5 |
何も固定していないBedrockの既定は、主モデルがOpus 5.5(us-* リージョンなら例として us.anthropic.claude-opus-5-5)、小さく速いモデルがSonnet 4.5(例:us.anthropic.claude-sonnet-4-5-20250929-v1:0)だ。セッション名の生成のような裏の処理は、通常はHaiku級のモデルが受け持つが、BedrockではHaikuがすべてのアカウントやリージョンで有効とは限らないため、既定のSonnetを使う。Haikuを使わせたい場合は、ANTHROPIC_DEFAULT_HAIKU_MODEL にアカウントで使えるモデルIDを入れる。
固定する変数
複数の人に配るなら、別名に任せず固定する。公式の例は次のとおりだ。
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-8'
export ANTHROPIC_DEFAULT_SONNET_MODEL='us.anthropic.claude-sonnet-4-6'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='us.anthropic.claude-haiku-4-5-20251001-v1:0'
未固定のときは別名がClaude Code側の既定に任され、固定後は別名が指定したIDに解決される。新しい版へ移る時期を自分たちで決められるのが、固定のいちばんの利点だ。最新のOpusに固定したい場合は、既定モデル表に載っている us.anthropic.claude-opus-5-5 を使える。Sonnet 5.5のBedrock上のIDは、2026年10月2日時点のClaude Codeドキュメントのこのページには載っていない。Anthropicの「Models overview」とアカウントの推論プロファイル一覧で確かめてから固定する。
100万トークンのコンテキストを使う場合は、モデルIDの末尾に [1m] を付ける。BedrockではClaude Sonnet 5、Opus 4.6以降、Sonnet 4.6が100万トークンに対応し、Sonnet 5は付けなくても常に100万トークンで動く。
起動時のモデル確認
Bedrockに繋いだClaude Codeは、起動時に使う予定のモデルが自分のアカウントで呼べるかを確かめる。固定したモデルが既定より古く、新しい版が呼べる場合は、固定を更新するか聞いてくる。固定していないのに既定のモデルが使えない場合は、そのセッションだけ古い版(Opusが無ければ既定のSonnet)に切り替えて通知を出す。この切り替えは保存されない。
呼べなかったモデルは、そのマシンで最大1日記憶され、その間の起動ではBedrockに問い合わせずに飛ばされる。既定モデルの拒否は、前回の確認から10分たてば起動時に確認し直す。記憶を使わせたくない場合は CLAUDE_CODE_SKIP_MODEL_ACCESS_MEMORY=1 を設定する。
リージョンの接頭辞とデータの行き先
Bedrockの推論プロファイルIDには、リージョンに応じた接頭辞が付く。Claude Codeが優先する接頭辞は次のとおりだ。
| 解決されたAWSリージョン | 接頭辞 |
|---|---|
us-gov-*(AWS GovCloud) |
us-gov. |
us-* |
us. |
eu-* |
eu. |
ap-* |
apac. |
| それ以外 | global. |
東京(ap-northeast-1)のような ap-* リージョンなら、Claude Codeは apac. を先に試す。別の接頭辞を優先したいときは ANTHROPIC_BEDROCK_REGION_PREFIX を設定する。指定できる値は us・eu・apac・jp・au・global で、v2.1.224以降が必要だ。プロファイルの一覧を取得できない環境で、アカウントに無い接頭辞を指定すると、リクエストは400エラーで失敗する。
AWSのドキュメントによると、Global(全世界)のクロスリージョン推論プロファイルの宛先には商用リージョンがすべて含まれ、AWSがリージョンを足すと変わりうる。一方、US・EU・APACのような地域に紐づくプロファイルは、宛先リージョンの一覧が変わらない(Supported Regions and models for inference profiles)。処理するリージョンを社内規程で決めている組織は、global を選ぶ前にこの違いを確認しておきたい。アカウントでどのプロファイルが使えるかは aws bedrock list-inference-profiles --region <リージョン> で確かめられる。
手順6|料金と使用量を管理する
料金はAWS側で決まる
Bedrock経由の推論は、使ったAWSアカウントのAmazon Bedrockの利用料として計上される。単価はAWSのAmazon Bedrock pricingで確認する。この記事では金額を転記しない。料金表は改定されるので、見積もりの前に毎回ページを開いて確かめるほうが安全だ。
固定しないとOpusの単価になる
料金で最初に効くのはモデルの固定だ。公式ドキュメントは、OpusはSonnetより1トークンあたりの単価が高く、主モデルを固定していない構成はv2.1.207以降に更新した時点でOpusの単価で課金されると警告している。Sonnet 4.5を主モデルに保ちたい場合は、ANTHROPIC_MODEL にそのフルIDを入れる。ANTHROPIC_DEFAULT_SONNET_MODEL でSonnetを指定し、ANTHROPIC_DEFAULT_OPUS_MODEL を設定していない構成は、指定したSonnetが既定のまま残る。
アカウントとプロファイルで分ける
公式ドキュメントは、コスト追跡とアクセス管理を楽にするため、Claude Code専用のAWSアカウントを作ることを勧めている。組織でアプリケーション推論プロファイルを用意している場合は、ANTHROPIC_MODEL にそのARNを入れるか、設定ファイルの modelOverrides でモデルの版ごとにARNを割り当てる。modelOverrides を使うと、利用者が /model で版を切り替えても、組織のプロファイルを迂回しない。AWSのドキュメントでは、アプリケーション推論プロファイルを作れるリージョンに ap-northeast-1 も含まれている。
開発者ごとの支出上限をゲートウェイで設ける方法はClaude Codeの支出上限をgatewayで開発者別に設定する記事、全社でのコストの見える化はClaude Code全社導入のコスト可視化・上限設計ガイドで扱っている。
キャッシュとサービス階層
プロンプトキャッシュは既定で使われる。止める場合は DISABLE_PROMPT_CACHING=1、5分の既定より長い1時間のキャッシュを使う場合は ENABLE_PROMPT_CACHING_1H=1 を設定する。1時間のキャッシュは5分の既定より高い単価で課金される。キャッシュのトークン数がずっと0のままなら、そのリージョンでプロンプトキャッシュが使えるかをAWSのドキュメントで確かめる。
Bedrockのサービス階層は、ANTHROPIC_BEDROCK_SERVICE_TIER に default・flex・priority のいずれかを入れて選ぶ。費用と応答の速さのどちらを取るかの選択で、Claude Codeはこの値を X-Amzn-Bedrock-Service-Tier ヘッダーとして毎回送る。使える階層はモデルとリージョンで異なる。
手順7|SSO・社内プロキシの環境で止まらないようにする
awsAuthRefreshとawsCredentialExportの違い
SSOや社内のIDプロバイダーを使う組織では、認証情報の更新を設定ファイルに任せられる。似た名前の設定が2つあり、動くタイミングが違う。

awsAuthRefresh:認証情報が期限切れのときだけ動く。期限をローカルで判定した場合か、APIが認証エラーを返した場合に実行し、更新後にリクエストをやり直す。.awsディレクトリを更新するコマンド(aws sso loginなど)向けで、出力は画面に表示されるが、対話入力はできない。awsCredentialExport:セッション開始時と認証情報の再読み込みのたびに動く。.awsを書き換えられず、別アカウントの認証情報を直接返す必要がある場合だけ使う。出力は表示されず、決まったJSONの形で返す必要がある(v2.1.206以降)。
{
"awsAuthRefresh": "aws sso login --profile myprofile",
"env": {
"AWS_PROFILE": "myprofile"
}
}
awsAuthRefresh を動かす前に、Claude CodeはSTSの GetCallerIdentity で本当に期限切れかを確かめ、まだ使えるなら実行を飛ばす。この確認は HTTPS_PROXY と NO_PROXY に従ってプロキシを通る。v2.1.239より前は直接送っていたため、プロキシ経由でしか外に出られないネットワークでは起動時に止まっていた。
SSOのタブが何度も開くとき
AWS SSOでブラウザのタブが繰り返し開く場合、公式ドキュメントの対処は設定ファイルから awsAuthRefresh を外すことだ。社内VPNやTLS検査プロキシがSSOのブラウザの流れを中断すると、Claude Codeはそれを認証失敗とみなして awsAuthRefresh を実行し直し、終わらなくなる。ネットワークがブラウザのSSOに干渉する環境では、Claude Codeを起動する前に手で aws sso login を済ませる運用に切り替える。
証明書エラー
Claude Codeは、モデルの確認・トークン数の計算・認証情報を解決するSTSとSSOの呼び出し・ウィザードの確認に、OSの証明書ストアや NODE_EXTRA_CA_CERTS の設定を適用する。社内のルート証明書がこのどちらかに入っていれば、Bedrock用の追加設定は要らない。v2.1.261より前は、ウィザードの「環境にある認証情報を使う」を選んだ場合などに unable to get local issuer certificate が出たり、モデルが unreachable と表示されたりした。この症状なら更新で直る。
エラー別の直し方
表示と対処の一覧
公式ドキュメントのトラブルシューティングと各手順の記載から、表示と対処を対応づけた。版番号が書かれているものは、claude update で更新すれば解消する。
| 表示・症状 | 主な原因 | 対処 |
|---|---|---|
/setup-bedrock がメニューに出ない |
CLAUDE_CODE_USE_BEDROCK=1 が未設定の間は表示されない |
コマンドを最後まで入力する |
Session token not found or invalid |
v2.1.207でBedrockのリージョンが sso_region を上書きしていた |
更新する(現在は sso_region を使う) |
AWS default-chain credential resolve timed out |
認証情報チェーンのどこかが60秒以上止まった | credential_process などを見直すか、CLAUDE_CODE_AWS_CHAIN_RESOLVE_TIMEOUT_MS を上げる |
Timed out after 60s waiting for AWS |
ウィザードの認証確認が60秒を超えた | 上と同じ |
| SSOのタブが繰り返し開く | VPNやTLS検査プロキシがSSOを中断している | awsAuthRefresh を外し、事前に aws sso login |
unable to get local issuer certificate |
v2.1.261より前の版の証明書の扱い | 更新する |
on-demand throughput isn't supported |
モデルを推論プロファイルでない形で指定している | 推論プロファイルIDで指定する |
| リージョンに関するエラー | リージョンとモデルの組み合わせ | aws bedrock list-inference-profiles --region <リージョン> で確認し、対応するリージョンに切り替えるか推論プロファイルを使う |
Bedrock streaming response has content-type |
間のゲートウェイが Content-Type を書き換えた |
応答の本文とヘッダーをそのまま転送させる |
Switched to <fallback> because <model> is not available |
管理者がセッション中のモデルを無効にした | モデルを有効にするか固定する。切り替えずに失敗させるなら CLAUDE_CODE_DISABLE_MODEL_ACCESS_FALLBACK=1 |
/context のツール欄がすべて0 |
v2.1.196より前の版 | 更新する |
ゲートウェイ経由で止まるとき
ゲートウェイの件は少し補足が要る。Bedrockは InvokeModelWithResponseStream の応答を application/vnd.amazon.eventstream という形式で返す。ゲートウェイがこれをServer-Sent Eventsに変換している場合、そのゲートウェイはもうBedrockのAPIを提供していないことになる。Anthropic MessagesのAPIを受けられるゲートウェイなら、CLAUDE_CODE_USE_BEDROCK ではなく ANTHROPIC_BASE_URL でLLMゲートウェイとして繋ぐ。また、Claude CodeはBedrockのInvoke APIを使い、Converse APIには対応していない。
想定シナリオ|開発チームの設定をBedrock経由にそろえる
想定する状況
ここからは公開事例ではなく、構成例としての想定シナリオだ。本番基盤をAWSに置いている開発組織が、各自がばらばらに契約していたClaude Codeの接続を、会社のAWSアカウント経由のBedrockにそろえる場面を考える。目的は、利用料をAWSの請求にまとめることと、使えるモデルを組織で決めることだ。
配る設定の例
SSOで認証し、モデルを固定する場合のユーザー設定は、たとえば次の形になる。モデルIDは公式ドキュメントに載っている例をそのまま使っている。us-* 以外のリージョンでは接頭辞が変わるので、実際のIDは推論プロファイルの一覧で確かめてから入れる。
{
"awsAuthRefresh": "aws sso login --profile bedrock-dev",
"env": {
"CLAUDE_CODE_USE_BEDROCK": "1",
"AWS_PROFILE": "bedrock-dev",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "us.anthropic.claude-opus-5-5",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "us.anthropic.claude-sonnet-4-6"
}
}
アクセスキーをリポジトリや共有ドキュメントに書かない運用は、Bedrockでも同じだ。SSOプロファイルを使うと、キーそのものを配らずに済む。秘密情報の扱いはClaude Codeのシークレット管理の7原則にまとめている。
使えるモデルを組織で絞る
使えるモデルを制限する availableModels は、MDMや管理設定ファイルで配れば、Bedrockのようなサードパーティの接続先でも効く。一方、サーバーから配る管理設定はサードパーティの接続先には届かない(Model configuration)。また、us.anthropic. のような接続先の接頭辞は照合のときに取り除かれないので、特定のモデルだけを許可するなら接頭辞付きのフルIDで書く。全社での管理設定の配り方はClaude Code全社ガバナンスの記事で扱っている。
出力のフィルタを足す場合
Amazon Bedrock Guardrailsを使うと、Claude Codeに内容のフィルタをかけられる。Bedrockコンソールでガードレールを作って版を公開し、設定ファイルの env に ANTHROPIC_CUSTOM_HEADERS でガードレールのIDと版を渡す。クロスリージョン推論プロファイルを使っている場合は、ガードレール側でもクロスリージョン推論を有効にする。応答の途中でブロックされた場合は、それまでに出た文章は残り、ガードレールに設定したブロック時のメッセージで返答が終わる。
まとめ|最初に確認する3つ
/statusで接続先とリージョンを見る:Bedrock(またはMantle)に繋がっているか、リージョンがどこから来たかが分かる。- モデルを固定してから配る:未固定のBedrockでは主モデルがOpus 5.5、
sonnetがSonnet 4.5になる。単価と挙動の両方に効く。 - 料金の置き場を決める:Claude Code専用のAWSアカウントか、アプリケーション推論プロファイルのARNで、使った分を追える形にしておく。
よくある質問
Claude CodeはAmazon Bedrockで使えますか?
使えます。Bedrockコンソールの「Model catalog」でAnthropicのモデルのユースケースを申請したあと、claude を起動してログイン画面で「3rd-party platform」→「Amazon Bedrock」を選びます。CIなどでは CLAUDE_CODE_USE_BEDROCK=1 とAWSの認証情報を環境変数で渡します。
Bedrock経由で使うと料金はどうなりますか?
Bedrock経由の推論は、使ったAWSアカウントのAmazon Bedrockの利用料として計上されます。単価はAWSの料金ページで確認してください。公式ドキュメントは、OpusはSonnetより単価が高く、主モデルを固定していないとv2.1.207以降はOpusの単価で課金されると警告しています。コストを追いやすくするため、Claude Code専用のAWSアカウントを作ることも勧めています。
設定はどこに保存されますか?
ウィザード(/setup-bedrock)は、ユーザー設定ファイル ~/.claude/settings.json の env ブロックに保存します。CLAUDE_CONFIG_DIR を設定している場合は $CLAUDE_CONFIG_DIR/settings.json です。手動で設定する場合は、シェルの環境変数か、同じ設定ファイルの env に書きます。
/modelでsonnetを選ぶとSonnet 4.5になります。新しいSonnetを使うには?
Bedrockでは別名 sonnet がSonnet 4.5に解決されるためです(2026年10月2日時点の公式ドキュメント)。使いたいSonnetのBedrock上のモデルIDを、Anthropicの「Models overview」とアカウントの推論プロファイル一覧で確かめ、ANTHROPIC_DEFAULT_SONNET_MODEL に入れて固定してください。
東京リージョンで使えますか?
Claude Codeは ap-* のリージョンでは推論プロファイルの接頭辞 apac. を優先します。ANTHROPIC_BEDROCK_REGION_PREFIX の値として jp も指定できます。実際にどのモデルのプロファイルが使えるかはアカウントによって異なるため、aws bedrock list-inference-profiles --region ap-northeast-1 で確認してから固定してください。
WebSearchや/logoutが使えません。
どちらもBedrock接続では使えない仕様です。WebSearchツールはAmazon Bedrockでは利用できず、/logout は認証をAWSの認証情報で扱うため使えません。
あわせて読みたい
- Claude Code settings.json設定完全ガイド
- Claude Codeの支出上限|gatewayで開発者別に設定
- Claude Code全社導入のコスト可視化・上限設計ガイド
- Claude Codeのシークレット管理|秘密情報を守る7原則
- Claude Code全社ガバナンス|利用モデルとスキル統制
運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る(無料)
参考・出典
- Anthropic「Claude Code on Amazon Bedrock」(Claude Code Docs・2026年10月2日確認):前提条件、ログイン画面と
/setup-bedrockのウィザード、保存先、ユースケースの申請とPutUseCaseForModelAccess、認証情報の5つの渡し方とキャッシュ・タイムアウト、awsAuthRefresh/awsCredentialExport、有効化の変数とリージョンの解決順、/logoutとWebSearchの制限、モデルの固定と既定モデル、Opusの単価の警告、modelOverrides、起動時のモデル確認、接頭辞の対応表、IAMポリシー、専用AWSアカウントの推奨、100万トークン、サービス階層、Guardrails、Mantle、トラブルシューティング - Anthropic「Model configuration」(Claude Code Docs・2026年10月2日確認):接続先ごとの別名の行き先、サードパーティ接続でのモデル固定と
[1m]、availableModelsと管理設定の届き方、接頭辞を含むIDでの照合 - AWS「Supported Regions and models for inference profiles」(Amazon Bedrock User Guide・2026年10月2日確認):Globalのクロスリージョン推論プロファイルの宛先、地域に紐づくプロファイルの宛先が変わらないこと、アプリケーション推論プロファイルを作れるリージョン
- AWS「Amazon Bedrock pricing」:Bedrock経由の利用料の単価(本記事では金額を転記していない)