Bedrock の Claude in-region 推論がロンドンへ拡大 — 「国内で処理される」の中身が国ごとに違う

要約

AWS は 2026-09-30、Amazon Bedrock の Claude モデルについて、英国（ロンドン、eu-west-2）での in-region 推論対応を拡大したと告知しました。対象は Claude Opus 5.5 と Claude Sonnet 5 の2モデルです。

公式の説明は明快です。「Amazon Bedrock は呼び出したリージョン内で推論リクエストとデータを処理し、処理がそのリージョンから出ることはない」。想定利用者として挙げられているのは金融サービス、ヘルスケア、公共部門で、英国内でのデータ処理要件を持つ組織向けの対応という位置づけです。

単体で見れば「対応リージョンが1つ増えた」という話にしか見えません。 実際、これは数日前のアジア太平洋向け告知（ソウルとシンガポールの in-region、インドの地理内クロスリージョン）に続く同一プログラムのリージョン拡大です。

それでも取り上げる価値があるのは、日本との非対称がここで輪郭を持つからです。

英国は in-region で現行世代の Claude を使えます。 一方、日本で「国内処理」を実現する主経路は in-region ではありません。 jp. プレフィックスの**地理内クロスリージョン推論（GEO CRIS）**で、東京（ap-northeast-1）と大阪の間を AWS のグローバルネットワーク経由で自動ルーティングする方式です。新しい世代の Claude は、東京リージョン単体の in-region 推論に対応していません（世代を遡れば対応するモデルもありますが、それは現行世代を諦めるという選択になります）。

つまり「Claude は日本国内で処理できますか」という問いに対する正確な答えは、「できます。ただし単一リージョン内ではなく、日本国内の2リージョン間でルーティングされます」になります。 英国の顧客に対する答えとは、技術的な中身が違います。

この差は、監査や調達の文脈で効いてきます。 「データが国外へ出ない」で足りる要件なら、どちらも満たします。しかし「データが単一のリージョンから出ない」「リージョン間の転送が発生しない」という粒度で書かれた要件があると、日本は条件を満たせません。

何が変わったか

• ロンドン（eu-west-2）で Claude Opus 5.5 / Claude Sonnet 5 の in-region 推論が利用可能になった（2026-09-30 告知）
• 呼び出しはロンドンリージョンの bedrock-runtime エンドポイント
• 公式の保証は「推論リクエストとデータは呼び出したリージョン内で処理され、リージョンから出ない」
• 想定利用者は 金融サービス / ヘルスケア / 公共部門
• モデルごとの対応状況の正本は Bedrock ユーザーガイドのリージョン対応表（告知本文ではなくドキュメント側を見る）
• 数日前のアジア太平洋向け告知（ソウル / シンガポールは in-region、インドはムンバイ・ハイデラバードの地理内クロスリージョン）と同一プログラムの続き
• 日本は in-region ではなく jp. の地理内クロスリージョン（東京・大阪間）が主経路。現行世代の Claude は東京の in-region 対応を持たない

業務インパクト

最初に確認すべきは、自社の要件が「国」の粒度なのか「リージョン」の粒度なのかです。

データ所在地の要件は、文書上ではだいたい「国内で処理すること」と書かれます。この一文を Bedrock の構成へ翻訳する作業で、国ごとに答えが変わるようになりました。 英国は in-region で満たせる。日本は地理内クロスリージョンで満たす。インドも地理内クロスリージョンです。どれも「国外へ出ない」は満たしますが、「単一リージョンから出ない」は英国だけが満たします。

グローバル展開している組織では、ここが設計の分岐点になります。 英国法人向けにはロンドンの in-region、日本法人向けには jp. のクロスリージョンと、同じモデルを使いながら呼び出し方（推論プロファイル）が国ごとに変わる構成になります。アプリケーション側でリージョンとプロファイルを設定として外に出していないと、国を追加するたびにコード変更が必要になります。

モデル選定にも影響します。 「東京の in-region で現行世代の Claude を使う」という構成は、現時点では選べません。この前提で稟議や設計書を書いていると、実装段階で詰まります。 取れる選択は3つで、(1) 地理内クロスリージョンを受け入れる、(2) 世代を落として東京 in-region に対応するモデルを使う、(3) 要件そのものを「国内処理」の粒度へ緩める交渉をする。(2) は性能と価格の両方で不利になるため、実務では (1) か (3) になります。

セキュリティレビューへの説明資料は、AWS の告知文をそのまま引くのが安全です。 「処理がそのリージョンから出ることはない」という表現は公式の文言で、意訳すると保証の範囲が変わってしまいます。日本については、地理内クロスリージョンの仕組み（東京・大阪間、AWS グローバルネットワーク経由、jp. プレフィックスの推論プロファイル）まで書いた資料を用意しておくと、レビューで止まりにくくなります。

なお、対応状況は告知ではなくドキュメントを見てください。 公式告知も「モデルの対応状況はリージョン対応表を参照」と誘導しています。リージョン対応はモデル単位で増減するため、告知の日付時点の情報を設計の根拠に固定しない方がよいという意味です。

副業・個人活用視点

個人開発やフリーランス案件の規模では、in-region かどうかが直接問題になることはほとんどありません。 個人の判断でリージョンを選ぶなら、レイテンシと価格で決めて差し支えありません。

効いてくるのは、受託案件の要件定義に同席する場面です。

「データは国内で処理されますか」という質問は、AI 導入の相談でほぼ必ず出ます。 ここで「Bedrock なら国内で処理できます」と即答できる人は多いのですが、「単一リージョン内ですか、それとも国内の複数リージョン間ですか」まで分解して答えられる人は少ないのが実情です。この粒度で答えられると、技術者としての信頼の付き方が変わります。

もう1つは、海外拠点を持つ顧客の案件です。 「英国法人と日本法人で同じ AI 基盤を使いたい」という要望に対して、構成が国ごとに変わる理由を説明できると、設計の工数を見積もりに乗せやすくなります。 「同じモデルだから同じ構成でいけます」と言ってしまうと、後から差分の対応を無償で飲むことになりがちです。

学習の素材としても使えます。 AWS のこの手の告知は、機能の説明と制約の説明が同じ分量で書かれているのが特徴です。「できること」だけでなく「どこまでを保証するか」を短い文で言い切る書き方は、提案書や仕様書を書くときの手本になります。今回なら「処理がそのリージョンから出ることはない」という一文が、保証の範囲をちょうど必要なだけ限定しています。

関連リンク

• Amazon Bedrock expands Claude models in-region support in the UK (London)（AWS 公式告知）
• Regional availability by models（Amazon Bedrock ユーザーガイド）
• Introducing Amazon Bedrock cross-Region inference for Claude in Japan and Australia（日本の地理内クロスリージョン）