Amazon BedrockでClaudeを呼ぶ方法は、1本ではなくなりました。Opus 4.7以降のモデルにはAnthropic APIと同じ形で呼べるMessages APIの入口が加わり、従来のInvokeModel・Converseと並んで3つの経路があります。経路ごとに異なるのは、モデルIDの書き方、IAM権限、使える機能の3点です。この記事では2026年9月時点の公式ドキュメントをもとに、3経路の違い、東京リージョンの設定、PythonとClaude Codeの設定例、Anthropic APIとの機能差を整理し、Bedrockを選ぶ案件と見送る案件を線引きします。
まとめ:Bedrock ClaudeはモデルIDの世代と必要な機能で呼び方を決める
新しくアプリを作るなら、Anthropic SDKからMessages APIの形で呼ぶ経路を選びます。Anthropic APIのコードをほぼそのまま移せて、Claude Opus 5.5やSonnet 5のような新しいモデルをanthropic.claude-sonnet-5のような短いIDで指定できます。
既にboto3のinvoke_modelやConverseで動いている資産は、急いで書き換えなくてかまいません。新しいモデルもInvokeModelから呼べます。ただし構造化出力やGuardrailsを使うならbedrock-runtime側に残す必要があり、bedrock-mantle側へ寄せると動かなくなります。
Claude CodeをBedrockで使うなら、CLAUDE_CODE_USE_BEDROCK=1に加えてモデルIDを固定します。モデルIDを固定しない場合に使われる既定のモデルは、Opus 5.5です。国内に処理を閉じる案件は接頭辞をjp.にそろえ、地域指定の10%上乗せを予算に入れます。
Bedrock上のClaudeを呼ぶ3つのAPI経路とモデルIDの世代差の整理
最初に、3つの経路がどこに向けて、何を送るのかをそろえます。混乱の多くは、経路ごとにモデルIDの形が違うことから起きます。
Messages API・InvokeModel・Converseを8項目で比べた違い
AWSのBedrockのエンドポイント比較ページによると、Bedrockの推論エンドポイントはbedrock-runtimeとbedrock-mantleの2つです。Anthropic形式のMessages APIは両方にあり、InvokeModelとConverseはbedrock-runtimeだけにあります。
| 項目 | Messages(mantle) | Messages(runtime) | InvokeModel | Converse |
|---|---|---|---|---|
| 送り先 | bedrock-mantle | runtimeの/anthropic | bedrock-runtime | bedrock-runtime |
| 本文の形 | Anthropic API同形 | Anthropic API同形 | Anthropic形式+版指定 | Bedrock共通形式 |
| 接頭辞 | anthropic.のみ | global.やjp.を付ける | 旧世代のIDは必須 | InvokeModelと同じ |
| IAMの名前空間 | bedrock-mantle: | bedrock: | bedrock: | bedrock: |
| 推論プロファイル | 非対応 | 対応 | 対応 | 対応 |
| 構造化出力 | 非対応 | 記載なし | 対応 | 対応 |
| Guardrails | 非対応 | 記載なし | 対応 | 対応 |
| 他社モデルへの切替 | Claudeのみ | Claudeのみ | 本文をモデルごとに書く | 同じ本文で切替可 |
Converseは、ClaudeとNova・Llamaなどを同じ本文で呼び分けたいときの経路です。実装はAmazon Bedrock Converse APIの使い方にまとめています。
Opus 4.7以降の短いIDと従来のバージョン付きIDを見分ける基準
AnthropicのClaude in Amazon Bedrockのページは、Opus 4.7以降のモデルIDをanthropic.claude-opus-5-5のような「接頭辞+モデル名」だけの形で載せています。対象はFable 5.1・Fable 5・Opus 5.5・Opus 5・Opus 4.8・Opus 4.7・Sonnet 5・Haiku 4.5です。
一方、Opus 4.6以前のモデルは従来型連携のページに載っており、anthropic.claude-sonnet-4-5-20250929-v1:0のように日付とv1:0が付いたIDが中心です。この世代のIDはbedrock-mantleでは通りません。ただしSonnet 4.6はanthropic.claude-sonnet-4-6、Opus 4.6はanthropic.claude-opus-4-6-v1で、日付が付かないのに従来型です。IDの見た目で判断せず、どちらのページの表に載っているかで世代を決めます。
Haiku 4.5は両方の表に載り、従来型は日付付き、Messages API側はanthropic.claude-haiku-4-5です。取り違えると400エラーになるため、経路とIDの組は1か所で管理します。
東京リージョンからBedrock Claudeを呼ぶ前のモデルアクセスとIAM設定
コードを書く前に、AWSアカウント側で済ませる作業が2つあります。モデルの利用申請と、経路に合わせたIAM権限です。
ユースケース申請と東京の推論プロファイルを確かめるCLI手順
Anthropicのモデルを初めて呼ぶ前に、Bedrockコンソールのモデルカタログからユースケースを1回申請します。Claude CodeのBedrock設定ページによると、送信するとすぐに使えるようになり、AWS Organizationsなら管理アカウントのPutUseCaseForModelAccessで子アカウントにも広がります。
申請が済んだら、東京で使える推論プロファイルをCLIで確かめます。
# 認証情報が通っているかを確認
aws sts get-caller-identity
# 東京(ap-northeast-1)から呼べるClaudeの推論プロファイルIDを一覧にする
aws bedrock list-inference-profiles \
--region ap-northeast-1 \
--query "inferenceProfileSummaries[?contains(inferenceProfileId, 'anthropic')].inferenceProfileId" \
--output table
# 基盤モデルIDの一覧(従来型のバージョン付きIDを確かめるとき)
aws bedrock list-foundation-models \
--region ap-northeast-1 \
--by-provider anthropic \
--query "modelSummaries[*].modelId"
一覧にjp.で始まるIDがあれば、東京と大阪の中だけで処理する経路が使えます。global.は全商用リージョンへ振り分ける経路です。推論プロファイルの対応ページは正確なIDをモデルカードで確かめるよう案内しているため、一覧とモデルカードの両方を見てからIDを確定します。
runtimeとmantleの呼び出し経路別IAM権限とアクションの違い
IAMは経路でアクションの名前空間が分かれます。bedrock-runtimeはbedrock:、bedrock-mantleはbedrock-mantle:で、片方だけ許可するともう片方は403で止まります。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeViaBedrockRuntime",
"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": "InvokeViaBedrockMantle",
"Effect": "Allow",
"Action": [
"bedrock-mantle:CreateInference",
"bedrock-mantle:CountTokens"
],
"Resource": "*"
}
]
}
前半はClaude CodeのBedrock設定ページの権限、後半は同ページのMantleの節で追加が必要とされる2つのアクションです。本番ではResourceを使うモデルのARNに絞ります。振り分け先のリージョンがSCPで拒否されているとリクエスト全体が失敗するため、jp.なら東京と大阪の両方を許可します。
Anthropic SDKとboto3の経路別Python実装例
以下は公式ドキュメントのサンプルを東京リージョン向けに書き換えたPythonのコード例です。
AnthropicBedrockMantleでMessages APIを東京から呼ぶ実装
新しく書くなら、Anthropic SDKのBedrock用クライアントを使います。Claude in Amazon Bedrockのページでは、pip install -U "anthropic[bedrock]"で入るAnthropicBedrockMantleが、SigV4の署名を自動で付けます。
# pip install -U "anthropic[bedrock]"
from anthropic import AnthropicBedrockMantle
# 認証情報は AWS_ACCESS_KEY_ID など環境変数 → ~/.aws の設定 → IAMロールの順に解決される
client = AnthropicBedrockMantle(aws_region="ap-northeast-1")
message = client.messages.create(
model="anthropic.claude-sonnet-5", # 短い形式のID(日付やv1:0は付けない)
max_tokens=1024,
system="あなたは社内の経理規程に沿って回答するアシスタントです。",
messages=[{"role": "user", "content": "出張旅費の精算期限を教えてください"}],
)
# 応答は content の配列で返る。思考ブロックが混ざる場合もあるため type で選ぶ
print(next(block.text for block in message.content if block.type == "text"))
print(message.usage) # 入出力トークン数。コスト監視のログに残す
送り先はhttps://bedrock-mantle.ap-northeast-1.api.aws/anthropic/v1/messagesです。AWSのMessages APIのページによると、bedrock-mantleの対応リージョンには東京が含まれます。ストリーミングもAnthropic APIと同じSSE形式です。
同じページには、bedrock-runtimeの/anthropicに向けてAnthropic SDKを使う書き方もあります。こちらはglobal.anthropic.claude-sonnet-5のように接頭辞を付けたIDを指定し、認証には短期のBedrockトークンを使います。Anthropic形式のままjp.で国内に閉じたい案件はこの経路です。構造化出力やGuardrailsが要件なら、AWSの資料で対応が明記されている次の節のInvokeModelを選びます。
boto3のinvoke_modelで本文に版を指定する既存資産向け実装
既存のシステムがboto3で組まれているなら、InvokeModelのまま新しいモデルへ切り替えられます。本文にAnthropic形式のメッセージとanthropic_versionを入れる書き方です。
import json
import boto3
client = boto3.client("bedrock-runtime", region_name="ap-northeast-1")
body = {
"anthropic_version": "bedrock-2023-05-31", # InvokeModelでは本文に必須
"max_tokens": 1024,
"messages": [{"role": "user", "content": "出張旅費の精算期限を教えてください"}],
}
response = client.invoke_model(
# 推論プロファイルID。list-inference-profiles の結果で実在を確かめてから書く
modelId="jp.anthropic.claude-sonnet-4-5-20250929-v1:0",
body=json.dumps(body),
)
result = json.loads(response["body"].read())
print(result["content"][0]["text"])
従来型連携のページでは、Sonnet 4.5のjp接頭辞が「対応」です。同じページの注記によると、Sonnet 5やOpus 5.5もInvokeModelから呼べ、処理はMessages APIと同じ基盤で行われます。boto3を直接書きたくなければ、Anthropic SDKのAnthropicBedrockクライアントで同じ経路を使えます。
従来型モデルの400エラーを推論プロファイルIDへの変更で直す手順
従来型のIDで最も多い失敗は、基盤モデルIDをそのままmodelIdに入れて400が返るケースです。エラー文は「Invocation of model ID … with on-demand throughput isn’t supported」で始まります。
原因は、新しめの従来型モデルがリージョン単独のオンデマンド呼び出しではなく、推論プロファイル経由で提供されていることです。公式のエラー例はSonnet 4.5で、jp.やglobal.を付けたIDへ置き換えれば通ります。付ける接頭辞の候補は、list-inference-profilesで東京から見えたものだけです。存在しない接頭辞でも400になります。
Claude CodeをBedrock経由で動かす環境変数とモデル固定の設定手順
Claude Code自体の機能はClaude Codeとは?できること・使い方・料金で扱い、ここではBedrock接続の設定に絞ります。
CLAUDE_CODE_USE_BEDROCKとAWS_REGIONで始める最小構成
一番早いのは、claudeのログイン画面で「3rd-party platform」から「Amazon Bedrock」を選ぶ方法です。ウィザードが認証・リージョン・使えるモデルを確認し、結果を設定ファイルのenvに書き込みます。後から変えるときは/setup-bedrockで開き直します。
CIや社内配布では、ウィザードを使わず環境変数で固定します。
# Bedrock経由に切り替える
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
# 認証はいずれか1つ(SSOプロファイルの例)
aws sso login --profile=dev-bedrock
export AWS_PROFILE=dev-bedrock
# 東京でも jp. の推論プロファイルを優先させる(既定では ap-* は apac. になる)
export ANTHROPIC_BEDROCK_REGION_PREFIX=jp
# モデルを固定する(IDは list-inference-profiles で確かめた値に置き換える)
# 主モデルを指定すると、セッション名の生成などの背景処理も同じモデルで動く
export ANTHROPIC_MODEL='jp.anthropic.claude-sonnet-4-6'
export ANTHROPIC_DEFAULT_SONNET_MODEL='jp.anthropic.claude-sonnet-4-6'
claude
# 起動後に /status でリージョンと接続先(Amazon Bedrock)を確認する
見落としやすいのは接頭辞です。Claude Codeはap-*のリージョンで、アジア太平洋へ広く振り分けるapac.を優先します。処理を国内に閉じるために必要な指定は、ANTHROPIC_BEDROCK_REGION_PREFIX=jpです。この変数はClaude Code v2.1.224以降で使え、値はus・eu・apac・jp・au・globalから選びます。
従来型連携のページの表では、Haiku 4.5にjp.がありません。背景処理用にglobal.のHaikuを指定すると国外で処理され得るため、国内に閉じる案件では上の例のようにHaikuを指定しません。
モデルを固定しないとOpus 5.5の単価で請求される落とし穴
Claude CodeのBedrock設定ページによると、固定しない場合の既定はv2.1.280以降で主モデルがOpus 5.5です。v2.1.207より前はSonnet 4.5だったため、古い手順で導入した環境は、更新しただけでOpusの単価へ切り替わります。
対策はANTHROPIC_MODELかANTHROPIC_DEFAULT_*_MODELでの明示です。Opusを使わせる場合も版を固定しておけば、移行の時期を管理者が決められます。部署ごとに費用を分けるなら、アプリケーション推論プロファイルのARNをモデルIDとして渡します。
Bedrock経由のClaude CodeではWeb検索ツールと/logoutが使えません。社内のLLMゲートウェイを挟む構成や、Claude DesktopまでAWSの認証でそろえる構成はClaude apps gateway for AWSの構成要件で整理しています。
Anthropic APIとの機能差と地域指定の料金で詰まる落とし穴と対処
BedrockのClaudeはAnthropic APIと同じではありません。設計の途中で差に気づくと手戻りが大きいため、先に洗い出します。
構造化出力・Web検索・Batches・Files APIが使えない範囲
Claude in Amazon Bedrockのページが「非対応」としている主な機能は次のとおりです。
- 構造化出力(mantle経路のみ非対応)
- サーバー側ツール(コード実行・Web検索・Web取得)
- Agent Skills・MCPコネクタ・プログラムからのツール呼び出し
- Message Batches・Files API・画像やPDFのURL指定
- サーバー側のフォールバック(
fallbacksパラメータ)
実務でまず効いてくるのは構造化出力です。AWSのエンドポイント比較ページは、output_config.formatを含むリクエストはbedrock-mantleで400になると明記しています。JSONスキーマで出力を縛る設計で選ぶ呼び出し先は、InvokeModelかConverseです。従来型の経路ではプロンプトキャッシュの自動指定(最上位のcache_control)も使えないため、キャッシュの区切りを明示的に書きます。書き方はAmazon Bedrockのプロンプトキャッシュの実装が参考になります。
逆に、Bedrockにしかない機能もあります。入出力の検査を掛けるGuardrailsはbedrock-runtime側だけで使え、日本語での効かせ方はAmazon Bedrock Guardrailsの設定と実装にまとめています。
地域指定に10%上乗せされるglobalとjpの国内処理要件での選び分け
Anthropicの2つのBedrockページは、Sonnet 4.5以降のモデルで、地域に処理を閉じるエンドポイントに10%の上乗せがあると書いています。global.は上乗せなし、jp.やus.は上乗せありです。
判断の基準はデータの置き場所の要件です。個人情報や契約上の制約で国内処理が条件ならjp.を選び、10%を見積もりに入れます。その条件が無い社内ツールや検証環境はglobal.で十分です。AWSのエンドポイント比較ページでは、推論プロファイルによる振り分けに対応するのはbedrock-runtimeだけなので、使い分けたい案件はそちらで組みます。トークン単価そのものはAmazon Bedrockの料金ページに載っており、モデル別の月額試算はAWS Bedrockの料金と月額試算で扱っています。
BedrockとClaude Platform on AWS・直契約の採用条件
ここまでの仕様を踏まえて、どの入口でClaudeを使うかを言い切ります。候補はBedrock、AnthropicがAWS上で運営するClaude Platform on AWS、Anthropic APIの直契約の3つです。
データとIAMをAWS内で閉じる案件はBedrockを第一候補にする
業務データがAWSにあり、認可をIAMとSSOで管理し、支払いをAWSの請求にまとめたい案件は、Bedrockを選びます。Claude in Amazon Bedrockのページは、推論基盤にAnthropicの担当者がアクセスできない設計を挙げ、ログはCloudWatchとCloudTrailに出ます。この構成なら、監査への説明をAWSの既存の統制に乗せることが可能です。RAGやエージェントまでAWS内で組むなら、なおさらです。エージェントの本番基盤はAmazon Bedrock AgentCore APIの使い方で解説しています。
新機能を即日使いたい案件やAgent Skills前提の案件は見送る
Bedrockを見送るのは、コード実行・Agent Skills・Files API・Batchesを前提にした設計です。AnthropicのClaude Platform on AWSのページによると、こちらはAnthropicが運営し、AWSは認証・IAM・Marketplace経由の請求を担います。Agent Skillsやベータ機能まで使えるため、AWSの請求にまとめつつ機能をそろえたいならこちらが合います。
ただし推論の処理者はAnthropicです。2026年9月18日より前に作ったワークスペースはAWS外で処理される場合があると明記されており、データの所在が条件ならinference_geoの指定と契約条件の確認が先です。AWSを使っていない会社は、Anthropic APIの直契約が最も手数が少なく済みます。
入口を決めきれない段階や、既存システムへClaudeを組み込む実装まで任せたい場合は、生成AI開発・AI受託開発の相談窓口で要件の整理から対応しています。モデルそのものの選び分けはAWS Bedrockのモデル選定と切替判断で比べています。
Bedrock Claudeの設定・モデルID・Claude Code連携でよくある質問
BedrockでClaudeを使い始める段階で出やすい質問に、2026年9月時点の公式ドキュメントで答えます。
BedrockのClaudeは東京リージョンで使えますか?
使えます。Anthropicの対応表では、東京はグローバル・JP・東京単独の3種類、大阪で対応しているのはグローバルとJPの2種類です。ただしFable 5.1の地域指定エンドポイントは執筆時点でバージニア北部だけで、モデルごとに差があります。IDは東京でのlist-inference-profilesで確かめます。
Anthropic APIのコードはそのままBedrockで動きますか?
Messages APIの経路なら、クライアントの作り方とモデルIDの2点を変えるだけで動きます。Anthropic()をAnthropicBedrockMantleに、claude-sonnet-5をanthropic.claude-sonnet-5に替えるのが、具体的な変更内容です。Web検索ツール・Files API・Batchesを使うコードは動かないため、その部分は設計から見直します。
Bedrockで最新のClaudeモデルが一覧に出ないのはなぜですか?
多くは、見ている資料とIDの世代が合っていないことが原因です。Anthropicの従来型ページは、Fable 5.1やOpus 5.5などバージョン付きIDを持たないモデルを、そのページの表から省いていると注記しています。新しいモデルはClaude in Amazon Bedrockのページの表でIDを確認します。もう1つの原因は利用条件です。Opus 5.5とOpus 5は全員に開放されたモデルの一覧に含まれていないため、コンソールのモデルアクセスで自分のアカウントの条件を確かめます。
Claude CodeをBedrockで使う料金はどう決まりますか?
Claudeの定額プランではなく、Bedrockのトークン従量課金です。AWSのエンドポイント比較ページによると、同じモデルならbedrock-runtimeとbedrock-mantleのどちらを選んでも単価は変わりません。見積もりを外す原因は、既定のOpus 5.5で動かすことと、jp.の10%上乗せの見落としの2つです。
InvokeModelとConverseはどちらを使えばよいですか?
思考ブロックやキャッシュの区切りなどClaude固有の指定を細かく書くならInvokeModel、ClaudeとNovaやLlamaを同じコードで切り替えたいならConverseです。Claude CodeのBedrock接続はInvokeModelの経路(Mantle有効時はMessages API)を使い、Converseには対応していません。IAMポリシーをClaude Codeと共用するなら、アプリもInvokeModelにそろえます。
関連記事
- Amazon Bedrockの使い方|料金・モデル・APIの始め方を4ステップで解説:Bedrock全体の始め方とコンソール操作
- Amazon Bedrock Converse APIの使い方|boto3実装・ConverseStream・Tool Use・IAM権限:Converse経路の実装詳細
- AWS Bedrockのモデル選定|Claude・Nova・OpenAI・Gemmaの選び分けと切替判断:Claude以外のモデルとの比較
- AWS Bedrockの料金はいくら?課金方式4種と月額試算・費用を下げる順番:トークン料金の試算と費用の下げ方
- Claude apps gateway for AWSとは?Bedrock接続の構成要件と導入判断:Claude DesktopやClaude CodeをAWS認証でまとめる構成