Bedrock の Claude が「リージョンから出ない推論」をソウルとシンガポールで開始 — 日本は対象外、代わりに東京・大阪の地理内ルート

要約

AWS は 2026-09-29、Amazon Bedrock で Claude の「単一リージョン推論（in-region inference）」をソウルとシンガポールで提供開始したと発表しました。

対象は次のとおりです。

• ソウル（ap-northeast-2）: Claude Opus 5、Claude Sonnet 5
• シンガポール（ap-southeast-1）: Claude Sonnet 5

同日、インド向けの展開も発表されました。 こちらは単一リージョンではなく 地理内クロスリージョン推論で、ムンバイとハイデラバードの間で Claude Opus 5 / Claude Sonnet 5 / Claude Haiku 4.5 が使えます。

この発表の価値は、新しいモデルが増えたことではありません。「どこで処理されるか」を言い切れるようになったことです。

Bedrock で Claude を使うとき、これまで一般的だったのはクロスリージョン推論プロファイルでした。これは需要に応じて複数リージョンへリクエストを振り分ける仕組みで、スループットは稼げますが、個々のリクエストがどのリージョンで処理されたかを事前に確定できません。

今回の単一リージョン推論について、AWS は明確な言葉を使っています。「リクエストは指定した単一の AWS リージョン内で完全に処理され、そのリージョンから出ない」。そして「ルーティング層が存在しない」。

この2文が、データ所在地の要件に対する回答になります。 「たぶん国内で処理されます」ではなく、「仕組みとして出ません」と言える状態です。

そして、AWS は交換条件も同じ文章の中に書いています。 「その代わり、スループットはそのリージョンの容量に縛られる」「リクエストはリージョン単位のサービスクォータの対象になる」。

これは重要な注記です。 ルーティング層を取り除くということは、混雑時に他のリージョンへ逃がす仕組みも無いという意味です。課金は呼び出したリージョンのオンデマンド価格、クォータ消費・CloudWatch メトリクス・CloudTrail ログもすべて同じリージョンにスコープされます。

公式が想定利用者として挙げているのは、金融サービス・ヘルスケア・公共部門です。 データを特定の地理内で処理する要件があり、かつスケールさせたい組織、という位置づけです。

日本リージョン（ap-northeast-1）は、この発表に含まれていません。

AWS のドキュメント上、日本向けの主経路は JP（東京・大阪）の地理内クロスリージョン推論と global ルートです。つまり、韓国で「ソウルから出ない」と言えるようになった一方、日本では「東京か大阪のどちらかで処理される」という説明になります。

どちらも「国内に留まる」ですが、保証の粒度が違います。 国内に複数リージョンを持つ国では地理内クロスリージョン、単一リージョンの国では単一リージョン推論——という整理に見えます。モデルごとの可否は AWS のリージョン互換性の公式表で確認が必要です。

何が変わったか

• ソウル（ap-northeast-2）で Claude Opus 5 / Claude Sonnet 5 の単一リージョン推論が利用可能
• シンガポール（ap-southeast-1）で Claude Sonnet 5 の単一リージョン推論が利用可能
• インド（ムンバイ・ハイデラバード）で Claude Opus 5 / Sonnet 5 / Haiku 4.5 の地理内クロスリージョン推論が利用可能
• 単一リージョン推論にはルーティング層が無く、リクエストは指定リージョン内で完結する
• その代わり、スループットはそのリージョンの容量に縛られ、リージョン単位のサービスクォータの対象になる
• 課金は呼び出したリージョンのオンデマンド価格
• クォータ消費・CloudWatch メトリクス・CloudTrail ログが同一リージョンにスコープされる
• 公式が挙げる想定利用者は金融サービス・ヘルスケア・公共部門
• 日本リージョンはこの発表の対象外。日本向けは JP（東京・大阪）の地理内クロスリージョンと global ルート

業務インパクト（一般企業向け）

最初に効くのは、提案書とセキュリティチェックシートの書き方です。

データ所在地の要件がある案件では、「データはどこで処理されるか」という設問がほぼ必ず出ます。 これまでクロスリージョン推論を使っていた場合、正直に書くなら「複数リージョンへ振り分けられる可能性がある」になります。この一文が通らずに案件が止まる、という経験をした人は少なくないはずです。

韓国・シンガポール・インドに関わる案件では、ここが書き換えられます。 「指定リージョン内で完結し、ルーティング層は存在しない」と公式が明記しているため、根拠として公式ドキュメントを引けます。 自社の設定の説明ではなく、ベンダーの仕様として示せる点が重要です。

日本案件では、書き方を変える必要があります。

「東京リージョンから出ません」と書けるかどうかは、モデルによって違います。 新しい Claude 世代では、日本向けの経路は JP（東京・大阪）の地理内クロスリージョンです。この場合の正確な記述は「日本国内（東京または大阪）で処理される」です。

ここを曖昧にしたまま「国内で処理されます」と書くと、後で問題になります。 監査や再委託先の確認で「どのリージョンか」を聞かれたとき、答えが「東京または大阪」であることを先に共有していないと、説明の修正に見えます。 最初から「国内2リージョンのいずれか」と書いておく方が安全です。

次に効くのは、容量計画です。

単一リージョン推論は、可用性を犠牲にして所在地を取る選択です。 ルーティング層が無いということは、そのリージョンが混雑したときの逃げ道も無いということです。公式が「スループットはそのリージョンの容量に縛られる」と書いているのは、注意書きではなく仕様の説明です。

だから、単一リージョン推論を選ぶときは、2つを先に決めておく必要があります。

1つめは、クォータの事前申請です。 リージョン単位のサービスクォータが上限になるため、想定ピークを計算してクォータ引き上げを申請しておく必要があります。本番投入の直前に気づくと、申請の処理時間がそのまま遅延になります。

2つめは、クォータに当たったときの挙動です。 選択肢は実質3つで、待たせる（キューイング）、落とす（明示的なエラー返却）、所在地要件の無い処理だけ別経路へ逃がす。最後の選択肢は設計次第で可能ですが、「どの処理が所在地要件の対象か」を分類しておかないと実装できません。 この分類は、今のうちにやっておく価値があります。

監査ログの扱いも変わります。

CloudWatch メトリクスと CloudTrail ログが呼び出しリージョンにスコープされるという点は、運用設計に直接響きます。複数リージョンにまたがって運用している場合、ログの集約先と、集約先がどのリージョンにあるかを確認する必要があります。 推論は国内で完結しているのに、ログを国外のリージョンに集約していたという構成は起こりえます。所在地要件の文脈では、これも説明対象です。

最後に、投資判断として見るときの注意です。

この発表は「使える国が増えた」という話に見えますが、裏返すと「国ごとに保証の形が違う」という話です。 アジア太平洋に複数拠点を持つ企業では、韓国は単一リージョン、日本は国内2リージョン、インドは国内2リージョン、シンガポールは単一リージョンという状態になります。

共通の社内規定を1つ作って全拠点に適用する、という進め方は無理が出ます。 規定には「各リージョンで利用可能な最も狭い経路を使う」のような原則を書き、拠点ごとの具体値は別表で管理する方が維持できます。モデルの世代交代ごとに対応リージョンは変わるため、別表は更新される前提で作ってください。

副業・個人活用視点

個人開発や小規模な受託では、この発表そのものを使う機会は少ないはずです。 単一リージョン推論を必要とするのは、データ所在地要件を持つ組織です。個人案件でこの要件が出ることは稀です。

それでも、ここから取れるものが2つあります。

1つめは、「所在地の説明ができる」という差別化です。

小規模な受託で AI 機能を入れるとき、ほぼ必ず聞かれる質問があります。「このデータはどこに行くんですか」。この質問に、具体的に答えられる人は多くありません。 「API に送っています」で終わらせるか、曖昧に「クラウド上で処理されます」と言うかになりがちです。

ここで、経路を具体的に言えると信用が違います。 「Bedrock 経由で、東京または大阪のリージョン内で処理されます。ログは○○に残ります」。この一文を言えるかどうかは、技術力の差ではなく、調べたかどうかの差です。 そして調べるコストは一度きりで、以降の案件で使い回せます。

2つめは、所在地要件を持つ案件へ入る足がかりです。

金融・医療・公共——公式が想定利用者として挙げている領域は、個人や小規模事業者が入りにくい領域です。 理由の1つは、セキュリティ要件への回答がそもそも書けないことです。要件定義の前のチェックシートで落ちます。

この壁は、実は知識で越えられる部分があります。 単一リージョン推論とクロスリージョン推論の違い、クォータのスコープ、ログの保存先——これらは公式ドキュメントに書いてあることで、実装経験が無くても説明できます。 案件に入る前に説明できる状態を作っておくと、チェックシートの段階で落ちなくなります。

具体的な準備として、自分用の表を1つ作ることを勧めます。 「使うモデル × 使うリージョン × 経路（単一 / 地理内クロス / global）× ログの保存先」の4列です。自分が実際に使う組み合わせだけで構いません。 案件ごとに作り直すのではなく、1枚を更新していく形にしてください。

注意点を1つ。この表はモデルの世代交代で古くなります。

今回の発表自体が、その実例です。 Claude Opus 5 と Sonnet 5 がソウルで単一リージョン対応になった一方、日本では新しい世代は地理内クロスリージョンが主経路という状態になっています。「前の案件で調べたから大丈夫」と考えて使い回すと、間違った説明をします。

だから、表には「いつ確認したか」の列を足してください。 日付が3か月以上前なら、公式表を見直す。この1列があるだけで、古い情報を自信を持って説明してしまうという最も危険な失敗を避けられます。

最後に、学びとして残す価値がある点を1つ。

AWS が「ルーティング層が無い」と書き、同じ文章で「その代わりスループットが縛られる」と書いたこと自体が、設計の説明として誠実です。 機能の説明に交換条件を併記している。自分が提案書や設計書を書くときの手本として使えます。

「できること」だけを書いた提案書は、読む側が制約を探す読み方になります。 制約を先に書いてある提案書は、書いた人が構造を理解していることの証明になります。 今回の AWS の書き方は、そのまま真似できる形です。