Bedrock東京リージョンのClaudeモデル一覧 — Global・JP・In-region別
Bedrockの東京リージョン(ap-northeast-1)で使えるClaudeモデルを、Global・JP・In-regionの3種類のエンドポイント別に表で示します。
Amazon Bedrockの東京リージョン(ap-northeast-1)は、Global・JP・In-regionという3種類のエンドポイントに対応しています。ただし、どのモデルでも3種類が使えるわけではありません。最新のClaude Fable 5.1は、リージョナルエンドポイントがus-east-1だけです。日本国内にデータを留めたい案件では、モデル選びの段階で制約に当たります。
国内保存ならJPで5モデル、東京固定のIn-regionで3モデルが使えます。Globalなら、下の表のモデルのうちMythos Preview以外を東京から呼べます。
Anthropic側のページは「例外の列挙」になっていて、東京で何が使えるかを読み取りにくくなっています。この記事ではAWSの各モデルカードと突き合わせた対応表と、日本国内保存が要件のときの切り分け、Claude Codeから東京のJPプロファイルを使う設定までを扱います。
東京リージョンで選べる3種類のエンドポイント
Amazon Bedrockは、Claudeへのアクセス経路として「Global」と「Regional」という2つのエンドポイント方式を用意しています。東京はこのうち、Globalと、リージョナルの2通り(JP・In-region)を選べるリージョンです。
東京で選べる3種類
Global
可用性の高いAWSリージョンへ動的にルーティングします。実行先は東京とは限らず、日本国内に固定する仕組みでもありません。
JP
地理別推論プロファイルで、東京と大阪をまたいで振り分けます。リクエストは日本国内に留まりますが、実行先が東京とは限りません。
In-region
東京リージョン単独に固定します。他リージョンへのフェイルオーバーが無い代わりに、実行先が常に東京になります。モデルカードでは、Mantleエンドポイントの表にだけ○が付きます。
Anthropicのドキュメントでは、JPとIn-regionはどちらもリージョナル扱いで、Globalに対して10%の料金加算が掛かります。単価の比較はAWS BedrockのClaude料金は直接APIとどう違うかに、東京を単独指定するかJPプロファイルを使うかの基本はAmazon BedrockでClaudeを使うガイドにあります。
モデル別の対応表
Anthropicのページにあるのは「Globalエンドポイントの対象モデルの一覧」と「リージョナルの例外」だけで、東京の可否を行列にはしていません。行列で示しているのはAWSの各モデルカードです。モデルカードにはbedrock-runtimeの表とbedrock-mantleの表があります。東京(ap-northeast-1)の行を読むと、GlobalとJPはbedrock-runtimeの表にだけ、In-regionはbedrock-mantleの表(Messages API形式のMantleエンドポイント)にだけ○が付きます。bedrock-runtimeでは、東京のIn-regionはどのモデルも×です。
| モデル | モデルID | Global | JP(地理別) | In-region(東京・Mantle経由のみ) |
|---|---|---|---|---|
| Claude Fable 5.1 | モデルIDanthropic.claude-fable-5-1 | Global○ | JP(地理別)× | In-region(東京・Mantle経由のみ)× |
| Claude Fable 5 | モデルIDanthropic.claude-fable-5 | Global○ | JP(地理別)× | In-region(東京・Mantle経由のみ)× |
| Claude Opus 5.5 | モデルIDanthropic.claude-opus-5-5 | Global○ | JP(地理別)○ | In-region(東京・Mantle経由のみ)× |
| Claude Opus 5 | モデルIDanthropic.claude-opus-5 | Global○ | JP(地理別)× | In-region(東京・Mantle経由のみ)× |
| Claude Opus 4.8 | モデルIDanthropic.claude-opus-4-8 | Global○ | JP(地理別)○ | In-region(東京・Mantle経由のみ)○ |
| Claude Opus 4.7 | モデルIDanthropic.claude-opus-4-7 | Global○ | JP(地理別)○ | In-region(東京・Mantle経由のみ)○ |
| Claude Sonnet 5.5 | モデルIDanthropic.claude-sonnet-5-5 | Global○ | JP(地理別)× | In-region(東京・Mantle経由のみ)× |
| Claude Sonnet 5 | モデルIDanthropic.claude-sonnet-5 | Global○ | JP(地理別)× | In-region(東京・Mantle経由のみ)× |
| Claude Haiku 5.5 | モデルIDanthropic.claude-haiku-5-5 | Global○ | JP(地理別)○ | In-region(東京・Mantle経由のみ)× |
| Claude Haiku 4.5 | モデルIDanthropic.claude-haiku-4-5 | Global○ | JP(地理別)○ | In-region(東京・Mantle経由のみ)○ |
| Claude Mythos Preview | モデルIDanthropic.claude-mythos-preview | Global×(リージョナル専用) | JP(地理別)× | In-region(東京・Mantle経由のみ)×(us-east-1のみ) |
国内保存に使えるのは、JPならOpus 5.5・Opus 4.8・Opus 4.7・Haiku 5.5・Haiku 4.5の5つ、東京単独のIn-regionならOpus 4.8・Opus 4.7・Haiku 4.5の3つです。ただしIn-regionはMantleエンドポイント経由に限られ、Invoke API側(bedrock-runtime)では選べません。Fable 5.1・Fable 5・Opus 5・Sonnet 5.5・Sonnet 5は東京ではGlobalしか選べません。Opus 5.5はJPプロファイルがある一方、東京の単独指定はありません。
Mythos 5.1とMythos 5も招待制で、モデルIDはanthropic.claude-mythos-5-1とanthropic.claude-mythos-5です。Mythos 5.1は東京からGlobalで呼べますが、JPとIn-regionはありません。Mythos 5のIn-regionはus-east-1だけです。Anthropicのページではどちらもリージョナルの提供先が示されておらず、Globalの対象リストにも入っていないので、AWS側の記載との差に注意が要ります。
Fable 5.1とFable 5を使うには、データ保持モードをaws_reviewに設定してAWSのレビューにオプトインする必要があります(AWSのモデルカード)。Data Retention APIで設定します。
アクセス条件もモデルごとに別々です。Anthropicのページで全ユーザーに開放と明記されているのは、Fable 5.1・Fable 5・Opus 4.8・Sonnet 5・Opus 4.7・Haiku 4.5の6つです。Opus 5.5・Opus 5・Sonnet 5.5・Haiku 5.5は開放の一覧に無く、AWSコンソールのモデルアクセス画面で許可状況を見ることになります。
Claude Codeのバージョン要件もモデルで違います。Fable 5.1は2.1.257以降(AnthropicのBedrock解説ページは2.1.255以降と記載)、Opus 5.5は2.1.280以降です。
モデルIDにはリージョンやエンドポイント種別が含まれません。どのエンドポイントを使うかは、呼び出し先のURLか推論プロファイルの指定で決まります。
Fable 5.1は東京のJP・In-regionでは使えない
Anthropicのページでは、Fable 5.1のリージョナルエンドポイントはus-east-1だけです。AWSのモデルカードでも、Fable 5.1の地理別プロファイルはus.だけで、東京のJPもIn-regionもありません。
日本国内保存を要件にしたまま最新のFable 5.1を使う、という組み合わせは成立しません。Globalなら追加料金なしで呼べますが、実行先は動的に決まります。要件と使いたいモデルの組み合わせは、次の順で切り分けられます。
東京でモデルを選ぶ切り分け
- 1
日本国内保存は必須か
必須でなければ、Globalが追加料金なしで使えます。Fable 5.1もこの範囲です。
- 2
必須なら、使いたいモデルはFable 5.1か
Fable 5.1は東京のJP・In-regionに出せません。Fable 5とSonnet 5も東京ではGlobalだけなので、切り替え先は、表でJP列かIn-region列が○のモデルです。
- 3
国内保存の中で、可用性と固定のどちらを取るか
複数拠点への振り分けならJP、実行リージョンの固定ならIn-region(Mantleエンドポイント経由)です。
Mythos Previewは東京では呼べない
Mythos Previewは招待制で、しかもリージョナル専用です。対応リージョンはus-east-1だけなので、Globalエンドポイント経由でも東京からは呼べません。Project Glasswingの招待を受けたアカウントでも同じです。加えて、Mythos Previewには専用のAWSアカウントをBedrock Marketplaceチームがallowlistに登録する手続きも要ります。
大阪はJPでしか使えない
東京と大阪の違いは、In-regionが選べるかどうかです。公式のリージョン表では、東京(ap-northeast-1)がGlobal・JP・In-region only、大阪(ap-northeast-3)がGlobal・JPです。
大阪を単独で指定する手段は無く、大阪での実行はJPプロファイルの振り分け結果としてのみ起こります。東京は、日本国内で唯一、単独指定(Mantleエンドポイント経由)と複数リージョン振り分けの両方を選べます。
料金面では、Anthropicは「リージョナルエンドポイントはGlobalより10%高い」とし、複数リージョンにまたがる場合は地理別の推論プロファイル(US・EU・JP・AU)を使うと書いています。AWSのクロスリージョン推論の比較表でも、地理別(JPを含む)は標準料金、Globalは約10%安いと示されています。
Claude CodeでJP系統のプロファイルを明示指定する
Claude CodeがBedrockで使う推論プロファイルのプレフィックスは、実行リージョンから決まります。公式の対応表は次のとおりです。
| 解決されたAWSリージョン | 既定のプレフィックス |
|---|---|
us-gov-* | 既定のプレフィックスus-gov. |
us-* | 既定のプレフィックスus. |
eu-* | 既定のプレフィックスeu. |
ap-* | 既定のプレフィックスapac. |
| 上記以外 | 既定のプレフィックスglobal. |
東京(ap-northeast-1)はap-*なので、既定はjp.ではなくapac.になります。AWSのモデルカードを見ると、現行のモデルにapac.のプロファイル自体がありません。日本国内限定を意図しているなら、ANTHROPIC_BEDROCK_REGION_PREFIXでJP系統を指定します。
export AWS_REGION=ap-northeast-1
export ANTHROPIC_BEDROCK_REGION_PREFIX=jp指定できる値はus、eu、apac、jp、au、globalの6つで、Claude Code 2.1.224以降で有効です。この変数は「最初に試すプレフィックス」を選ぶもので、実際にどう適用されるかは、アカウントのプロファイルを一覧できるかで変わります。
プレフィックスの適用順(プロファイルを一覧できる場合)
- 1
指定したプレフィックスのプロファイル
アカウントにあれば、まずこれが使われます。
- 2
プレフィックスが違っても一致するプロファイル
指定のプロファイルが無いモデルには、他のプレフィックスの一致するプロファイルが使われます。
- 3
組み込みのモデルIDに指定のプレフィックスを付ける
一致するプロファイルがまったく無いモデルでは、可用性を確認せずにこの形で送ります。
プロファイルの一覧を取れない場合(bedrock:ListInferenceProfilesの権限が無いなど)は、可用性を確認せずにプレフィックスを付けて送ります。該当するプロファイルがアカウントで有効になっていないと、リクエストは400エラーで失敗します。上の6つ以外の値を入れたときは、リージョン由来の既定にフォールバックします。GovCloudでは指定に関わらずus-gov.だけが使われます。
既定のapac.のままだと、プロファイルを一覧できる場合は他のプレフィックスの一致するプロファイルへ、一覧できない場合は400エラーになります。
jpを指定しても国内に留まるとは限りません。プレフィックスは「優先」で保証ではなく、jp.のプロファイルがあるのは、表でJP列が○の5モデルだけです。それ以外のモデルは別のプレフィックスのプロファイルに解決されうるので、国内限定ならANTHROPIC_DEFAULT_*_MODELでjp.のIDを固定します。
解決されたリージョンは/statusで確認できます。bedrock:GetInferenceProfileは別の役割で、アプリケーション推論プロファイルのARNから元のモデルを引き、リクエストの形を選ぶために使われます。欠けていても自動で1回リトライされるだけで、そのぶん新しいモデルごとに往復が1回増えます。IAM権限の全体像と解決順序の実例はClaude Code Bedrock IAM設定とクロスリージョン推論プロファイルの組み方にあります。
既定モデルの選択にも注意点があります。既定のOpusが組み込みでOpus 5.5に解決される構成では、アカウントでOpus 5.5が使えないと、起動時にClaude Codeが古いバージョンへフォールバックし、通知を出します。Opusがどれも使えない場合はSonnetになります。このフォールバックはセッション限りで、設定には保存されません。
なお、新しいMessages API形式のMantleエンドポイント(CLAUDE_CODE_USE_MANTLE=1)は別系統です。MantleはAWS_REGIONからエンドポイントURLを組み立て、モデルIDにanthropic.を付けたバージョン接尾辞なしの形を使うため、推論プレフィックスの仕組みとは切り離して考えます。東京のIn-regionをClaude Codeで使う経路は、CLAUDE_CODE_USE_MANTLE=1とAWS_REGION=ap-northeast-1の組み合わせです。Mantleにはbedrock-mantle:名前空間のIAM権限(CreateInferenceなど)が別に要ります。JSON出力の入口別の書き方はBedrockのClaudeで構造化出力を使うにあります。
Bedrock経由と直接契約、Vertex AI、Foundryの違いはClaudeを日本から使う提供経路で比較しています。
よくあるつまずき
- Fable 5.1をJP・In-regionで指定する: リージョナルエンドポイントが
us-east-1のみなので、東京では使えません。国内保存が必須なら、表でJP列かIn-region列が○のモデルへ切り替えます(In-regionはMantleエンドポイント経由のみ) apac.を日本限定と思い込む:ap-*での既定はapac.で、東京固有のjp.とは別のプレフィックスです。国内限定にしたいときはANTHROPIC_BEDROCK_REGION_PREFIX=jpに加え、jp.のプロファイルがあるモデルを選びます- Opus 5.5・Opus 5・Sonnet 5.5・Haiku 5.5のアクセス未許可: 開放済みの一覧に載っていないため、コンソールのモデルアクセス画面で許可状況を確認します
- Mythos Previewを東京で試す: 招待を受けていても、対応は
us-east-1だけです
まとめ
東京のBedrockで国内保存が要件になると、Fable 5.1・Sonnet 5.5のようにGlobalしか選べないモデルがあります。JPで使えるのはOpus 5.5・Haiku 5.5などの5モデルです。東京単独のIn-regionはOpus 4.8・Opus 4.7・Haiku 4.5に限られ、Mantleエンドポイント経由になります。設計の前にAWSのモデルカードで、使いたいモデルの東京の行を確かめる手があります。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。