東京・大阪リージョンから Amazon Bedrock の OpenAI GPT-5.6 を使う：グローバルクロスリージョン推論の仕組みと考慮点

Amazon Bedrock で OpenAI GPT-5.6 モデルが 25 を超える AWS リージョンから利用可能になり、クロスリージョン推論 (CRIS) に対応しました。クロスリージョン推論に対応する GPT-5.6 のモデルは Sol、Terra、Luna の 3 つで、それぞれ性能とコストのバランスが異なります。

この対応で日本拠点のお客様にとって特に重要なのは、東京リージョン (ap-northeast-1) と大阪リージョン (ap-northeast-3) が、グローバル推論プロファイルの呼び出し元 (ソース) リージョンに含まれていることです。すでに東京リージョンで Amazon Bedrock をお使いのお客様は、アプリケーションの接続先リージョンを変更することなく、いま使っている環境のまま GPT-5.6 を呼び出せます。

本記事では、GPT-5.6 モデルの概要、地理的 (Geographic) 推論プロファイルとグローバル推論プロファイルの違い、そしてそれが日本拠点のお客様にとって具体的に何を意味するのかを整理します。あわせて、導入を判断する前に必ず把握しておくべきデータの所在とレイテンシの論点を扱い、最後に Amazon Bedrock コンソールで試す手順を紹介します。

コード例、IAM ポリシー、SCP、クォータ管理といった実装の詳細は、関連記事「東京リージョンから Amazon Bedrock の OpenAI GPT-5.6 を呼び出す実装ガイド」で解説しています。

Amazon Bedrock の GPT-5.6

Amazon Bedrock の GPT-5.6 ファミリーには、汎用のモデルと、サイバーセキュリティに特化したモデルがあります。本記事で扱うのは、クロスリージョン推論に対応する 3 つの汎用モデル (Sol、Terra、Luna) です。

3 つのモデルに共通する仕様は次のとおりです。

入力はテキストと画像、出力はテキスト
コンテキストウィンドウは 100 万トークン
推論 (reasoning) モード、サーバーサイドツール呼び出し、プロンプトキャッシュに対応
OpenAI Responses API、OpenAI Chat Completions API、Amazon Bedrock Converse API から呼び出し可能
ストリーミングは Responses API と Chat Completions API の stream=True、および ConverseStream に対応

モデル間の主な違いは、位置づけと対応リージョンです。対応リージョンは呼び出し方 (In-Region / Geo / Global) ごとに異なるため、次の表ではその区分で整理しています。最新の提供状況は、後述のドキュメントリンクからご確認ください。

	GPT-5.6 Sol	GPT-5.6 Terra	GPT-5.6 Luna
位置づけ	最も高性能。エージェント用途・コーディング向け	バランス型。日常的な本番ワークロード向け	高速・低コスト。大量処理向け
In-Region (リージョン内) 対応	`us-east-1`、`us-east-2`	`us-east-1`、`us-east-2`、`us-west-2`	`us-east-1`、`us-east-2`、`us-west-2`
Geo (`us.`) 対応	`us-east-1`、`us-east-2`、`us-west-1`、`us-west-2`	同左	同左
Global (`global.`) 対応	東京・大阪を含む商用リージョン全体	同左	同左

料金はモデルごとに異なります。最新の単価は Amazon Bedrock の料金ページをご確認ください。各モデルの提供リージョンの正式な一覧は、Amazon Bedrock のリージョン別モデルサポートページをご参照ください。

GPT-5.6 におけるクロスリージョン推論の仕組み

クロスリージョン推論自体は Amazon Bedrock でかねてより提供されているもので、新機能ではありません。推論プロファイル (inference profile) を通じて動作します。推論プロファイルは、モデルと、Amazon Bedrock がリクエストをルーティングできる AWS リージョンの組み合わせを定義した論理的な識別子で、生のモデル ID の代わりに指定します。

お客様はソースリージョンからプロファイルを呼び出し、Amazon Bedrock がそのリクエストを宛先リージョンにルーティングして、そのリージョンの計算リソースで処理します。

クロスリージョン推論は、第一義的にはキャパシティのための仕組みです。 1 つのリージョンで利用可能なキャパシティに縛られるのではなく、より広い計算リソースのプールを利用できるようにすることで、スループットを高め、負荷がかかった状況でも安定した性能を維持しやすくします。

GPT-5.6 のローンチでは、2 種類のクロスリージョン推論プロファイルが導入されました。この 2 つは、データがどこで処理されうるかが異なり、その違いがコンプライアンス上の主要な判断ポイントになります。

Geo (地理的) 推論プロファイル：us. のように地理コードが接頭辞として付きます (例: us.openai.gpt-5.6-terra)。推論処理をあらかじめ定義された地理的範囲内のリージョンに限定します。リクエストはソースリージョンから入り、その地理的範囲内の宛先リージョンにのみルーティングされます。データレジデンシー要件のあるワークロードでも、境界の内側で複数リージョンにスケールできます。
グローバル推論プロファイル：global. が接頭辞として付きます (例: global.openai.gpt-5.6-terra)。そのモデルが展開されている、サポート対象のすべての AWS 商用リージョンに対して、リアルタイムのキャパシティ状況に基づいてリクエストをルーティングできます。最も広いキャパシティプールを利用でき、地理的な処理要件がないワークロードに適した選択肢です。

どちらのプロファイルでも、リクエストはすでに Amazon Bedrock を呼び出しているリージョンからプロファイル ID を指定して送信し、どのバックエンドリージョンが処理するかは Amazon Bedrock が決定します。レスポンスは同じ呼び出しの中で返ります。アプリケーションのコード側で、どの宛先リージョンが処理したかを追跡する必要はありません。

補足として、次の点を押さえておいてください。

請求とクォータの消費は、どのバックエンドリージョンが処理したかに関係なく、お客様のアカウントに対して記録されます。 そのため、支出とスループットは引き続き 1 つのビューで把握できます。
グローバル CRIS を経由するデータは、そのモデルの対象リージョン群をまたいで処理される可能性があります。 処理を特定の地理的範囲に限定するデータレジデンシー要件がある場合は、該当する地理の Geo プロファイル (例: us.openai.gpt-5.6-terra) を使うか、単一リージョンへの直接呼び出しを使ってください。

クロスリージョン推論の仕組みそのものについては、Amazon Bedrock のクロスリージョン推論のドキュメントで解説されています。GPT-5.6 の各リージョンがどの呼び出し方 (In-Region / Geo / Global) に対応しているかは、リージョン別モデルサポートページのリージョン別の対応表をご確認ください。

ソースリージョンと宛先リージョン

まず押さえておきたいのは、us. プロファイルのソースリージョンは米国とカナダのリージョンに限られており、東京リージョンと大阪リージョンは含まれていない点です。つまり、東京リージョンから us.openai.gpt-5.6-terra を呼び出すことはできません。これは仕組み上の制約ではなく、提供状況によるものです。 ご自身の環境で呼び出せるプロファイルは、次のコマンドで確認できます。

aws bedrock list-inference-profiles --region ap-northeast-1 \
  --query "inferenceProfileSummaries[?contains(inferenceProfileId, 'gpt-5.6')].[inferenceProfileId,status]" \
  --output table

一方で、東京リージョンと大阪リージョンは、グローバル推論プロファイルのソースリージョンに含まれています。 以下の表は、グローバル推論プロファイル (global.openai.gpt-5.6-sol / -terra / -luna) を呼び出せるソースリージョンと、リクエストが処理されうる宛先リージョンの一覧です。ルーティングの内容は Sol、Terra、Luna の 3 モデルで共通です。

ソースリージョン宛先リージョン

米国: us-east-1、us-east-2、us-west-2、us-west-1
カナダ: ca-central-1
欧州: eu-north-1、eu-west-3、eu-west-1、eu-central-1、eu-south-2、eu-south-1、eu-west-2、eu-central-2
アジアパシフィック: ap-southeast-4、ap-southeast-2、ap-northeast-1 (東京)、ap-northeast-3 (大阪)、ap-northeast-2、ap-south-1、ap-south-2、ap-southeast-1、ap-southeast-3、ap-southeast-7、ap-southeast-5、ap-east-2
中東: me-central-1、il-central-1
南米: sa-east-1 仕組み上はサポート対象の AWS 商用リージョン全体が対象。実際の処理先はモデルがデプロイされているリージョン (us-east-1、us-east-2、us-west-2)

ソースリージョン	宛先リージョン
米国: `us-east-1`、`us-east-2`、`us-west-2`、`us-west-1` カナダ: `ca-central-1` 欧州: `eu-north-1`、`eu-west-3`、`eu-west-1`、`eu-central-1`、`eu-south-2`、`eu-south-1`、`eu-west-2`、`eu-central-2` アジアパシフィック: `ap-southeast-4`、`ap-southeast-2`、`ap-northeast-1` (東京)、`ap-northeast-3` (大阪)、`ap-northeast-2`、`ap-south-1`、`ap-south-2`、`ap-southeast-1`、`ap-southeast-3`、`ap-southeast-7`、`ap-southeast-5`、`ap-east-2` 中東: `me-central-1`、`il-central-1` 南米: `sa-east-1`	仕組み上はサポート対象の AWS 商用リージョン全体が対象。実際の処理先はモデルがデプロイされているリージョン (`us-east-1`、`us-east-2`、`us-west-2`)

各プロファイルのルーティング対象リージョンの正式な一覧は、リージョン別モデルサポートページの GPT-5.6 の対応表をご確認ください。クロスリージョン推論プロファイル全般の仕様 (オプトインリージョンの扱いや、ソースリージョンによって宛先が変わる場合があることなど) は、推論プロファイルのサポート対象リージョンとモデルページに記載されています。

日本拠点のお客様にとって、これが何を意味するか

具体的なメリットは次の 3 点です。

1. 既存の Amazon Bedrock 利用環境をそのまま使える

すでに東京リージョンで Amazon Bedrock をお使いであれば、エンドポイントもリージョン設定も、VPC エンドポイントも、CloudTrail の集約先も、いま使っているものがそのまま使えます。アプリケーションコードで変えるのは modelId (または model) パラメータに渡す文字列だけです。

- model_id = "anthropic.claude-...."
+ model_id = "global.openai.gpt-5.6-terra"

米国リージョン側にスタックやエンドポイントを追加で用意する必要はありません。

ただし、コード以外に必要な準備が 2 つあります。 ひとつは IAM ポリシーで、グローバル推論プロファイルの呼び出しには 3 つのステートメントが必要です。もうひとつは、利用可能リージョンを制限する SCP を使っている場合の除外設定です。いずれも実装ガイドの記事で解説しています。

2. 単一リージョンより広いキャパシティプールを使える

グローバル推論プロファイルは、リアルタイムのキャパシティ状況に基づいてルーティングします。特定リージョンの需要が高まっている時間帯でも、単一リージョンに固定した呼び出しに比べてスロットリングの影響を受けにくく、負荷時のスループットが安定しやすくなります。新しいモデルの提供開始直後は需要が集中しやすいため、この効果は特に大きくなります。

3. 運用の可観測性は東京リージョンに残る

リクエストがどのリージョンで処理されても、CloudTrail のイベント、モデル呼び出しログ、CloudWatch メトリクス、Service Quotas はすべてソースリージョンである東京に記録されます。監視・課金・クォータ管理のダッシュボードを日本国外に分散させる必要はありません。

日本拠点のお客様が事前に理解しておくべきこと

グローバル CRIS の利点と引き換えに、必ず理解しておくべき論点が 2 つあります。導入判断の前に、社内のセキュリティ・コンプライアンス担当と共有してください。

推論処理は日本国外のリージョンで行われる

これが最も重要な点です。東京リージョンからグローバル推論プロファイルを呼び出した場合、推論処理はモデルがデプロイされているリージョンで実行されます。 プロンプトと生成結果は、処理のために日本国外に送信されます。

執筆時点では、GPT-5.6 がデプロイされているのは米国の 3 リージョン (us-east-1、us-east-2、us-west-2) です。 グローバル推論プロファイルという名称は「全世界のリージョンにルーティングしうる仕組み」を指しますが、実際にリクエストが到達できるのはモデルが配置されているリージョンに限られます。したがって東京から呼び出した GPT-5.6 のリクエストは、米国内で処理されます。

ただし、この前提は将来にわたって保証されるものではありません。 グローバル推論プロファイルの宛先はモデルの展開状況に追随するため、対応リージョンが増えれば処理先も変わりえます。加えて、どのリージョンが処理するかはリアルタイムのキャパシティ状況に基づいて Amazon Bedrock が自動的に選択し、お客様が処理先リージョンを指定することはできません。 そのため、データレジデンシーの観点では「現時点で米国内に収まっている」ことを設計の前提に置くのではなく、地理的範囲を限定しない仕組みであるという理解でご検討ください。処理範囲を確実に限定する必要がある場合は、グローバル推論プロファイルではなくジオ推論プロファイルが適切な選択肢です。

特定のリージョンで処理する必要がある場合、一般には「そのリージョンのモデルを直接呼び出す」という選択肢があります。ただし東京・大阪リージョンから GPT-5.6 を直接呼び出す方法は提供されていません。 bedrock-runtime エンドポイントは推論プロファイルの指定を求め、生のモデル ID を受け付ける別のエンドポイント (実装ガイドの記事で解説) は東京・大阪では GPT-5.6 を利用できません。そのため、処理リージョンを日本国内に固定する必要があるワークロードでは、別のモデルを検討してください。

あわせて、不正利用検知の目的で入力プロンプトと出力結果が保存される場合がある点を、社内のコンプライアンス担当と共有してください。GPT-5.6 を含む一部のモデルでは、自動不正利用検知の分類器がフラグを立てたトラフィックが最大 30 日間保持されます (詳細は後述の「セキュリティとコンプライアンス」を参照)。

ここで、リージョンをまたぐデータと、ソースリージョンに留まるデータを区別しておくことが重要です。

データ	保存先	出典
モデル呼び出しログ (リクエスト・レスポンスの全文を含む)	ソースリージョン (東京)	モデル呼び出しのモニタリング
CloudTrail イベント、CloudWatch メトリクス	ソースリージョン (東京)	グローバルクロスリージョン推論
不正利用検知でフラグが立った入力・出力 (最大 30 日間)	宛先リージョン (推論処理が行われたリージョン)	不正使用の検出

モデル呼び出しログについては、配信先として指定できるのが同一アカウント・同一リージョンの Amazon S3 または CloudWatch Logs のみである点がドキュメントに明記されています。そのため、プロンプトとレスポンスの全文を保管したい場合でも、その保管先は東京リージョン内に収まります。

一方で、不正利用検知のために保持されるコンテンツは、処理が行われた宛先リージョン側に保存されます。 不正使用の検出のドキュメントには次のように記載されています。

If cross-region inference is enabled for these models, retained inputs and outputs are stored in destination regions (i.e., the region where your inference request is processed).

この点はデータレジデンシーの検討で見落としやすいため、コンプライアンス担当と共有しておくことを推奨します。なお、リージョンをまたいで転送されるリクエストは AWS のネットワーク内を暗号化されて流れ、パブリックインターネットを経由しません。

判断のための整理は次のとおりです。

ワークロードの要件	推奨される選択
データ処理を日本国内に限定する必要がある	執筆時点では GPT-5.6 で要件を満たせません。日本ジオ (`jp.`) の推論プロファイルが提供されている他のモデル、または東京リージョンで In-Region 呼び出しに対応した他のモデルを検討してください
データ処理を特定の地理的範囲に限定したい	Geo プロファイルが該当します。ただし GPT-5.6 に提供されるのは `us.` (米国) のみで、東京からは呼び出せません。米国リージョンをソースとして呼び出す構成が必要です
処理リージョンを 1 つに固定したい	東京・大阪をソースとする GPT-5.6 では実現できません。クロスリージョン推論では処理先を指定できず (仕様上の挙動であり設定で変更できません)、日本リージョンから GPT-5.6 を直接呼び出す方法も提供されていません。別のモデルをご検討ください
地理的な処理要件はない	グローバル CRIS が最適です。最も広いキャパシティプールを利用できます

レイテンシに処理先までのネットワーク往復が加わる

処理が日本国外のリージョンで行われるため、東京から呼び出す場合、ネットワークの往復時間がリクエストごとに上乗せされます。処理先が米国リージョンであれば、太平洋を往復する分の時間が加わります。また、複数の処理先候補の中からリクエストごとに選択されるため、レイテンシは一定ではありません。

対話型 UI のように応答の速さが体験に直結するワークロードでは、次の対策が有効です。

ストリーミングを使う：stream=True または converse_stream を使うことで、最初のトークンが届いた時点から表示を開始できます。ネットワークの往復は最初の 1 回に集約されるため、体感の待ち時間を大きく削減できます。
プロンプトキャッシュを活用する：長い共通プレフィックス (システムプロンプトや few-shot 例) の再処理を省けるため、キャッシュ対象部分の処理時間を短縮できます。
実測する：一般的な目安ではなく、実際のプロンプトサイズと出力長で、本番と同じ経路で計測してください。処理先が変動する性質上、平均値だけでなく p90 / p99 も併せて確認することを推奨します。Converse API のレスポンスには metrics.latencyMs が含まれるため、まずは短いプロンプトで往復を確認し、その後に本番相当の負荷で計測するとよいでしょう。

ストリーミングとプロンプトキャッシュの具体的な実装方法は、実装ガイドの記事で解説しています。

重要なのは、これがトレードオフであって欠陥ではないという点です。 バッチ処理、非同期のドキュメント処理、エージェント的なワークフロー、社内ツールなど、数百 ms のレイテンシが問題にならないワークロードは多く、そうしたケースではグローバル CRIS のキャパシティ上の利点がそのまま享受できます。一方、ミリ秒単位の応答性が要件であれば、その要件を先に確認してから設計してください。

セキュリティとコンプライアンス

クロスリージョン推論は、同一リージョン内での直接呼び出しと同じ Amazon Bedrock のセキュリティモデルを使用します。リクエストは AWS Identity and Access Management (IAM) の認証情報で認証され、IAM ポリシーによってロールが呼び出せる推論プロファイルを制御できます。

Amazon Bedrock はチップレベルで実施されるゼロオペレーターアクセス (ZOA) セキュリティモデルを採用しており、AWS のオペレーターがお客様のプロンプトや生成結果にアクセスすることはできません。すべてのモデル呼び出しはお客様の IAM ポリシー配下で実行され、VPC エンドポイント経由で VPC からプライベートに到達でき、AWS CloudTrail に記録されます。データ境界ポリシーによって、アカウントやネットワークの境界をまたぐデータの流出を防ぐこともできます。

Amazon Bedrock は既定でゼロデータ保持 (ZDR) のモデルを採用しており、モデルへの入力と出力を保存しません。ただし GPT-5.6 を含む一部のモデルでは、自動不正利用検知の分類器がフラグを立てたトラフィックが、オフラインでの不正利用検知のために最大 30 日間保持されます。

クロスリージョン推論を使う場合、保持されるコンテンツは宛先リージョン (推論処理が行われたリージョン) に保存されます。 保持されたデータは AWS が保存・処理し、お客様が明示的に許可しない限りサードパーティのモデルプロバイダーと共有されることはありません。要件に応じて、完全な ZDR の適用を AWS のアカウントチームに相談できる場合があります。

対象となるモデルと仕組みの詳細は、Amazon Bedrock ユーザーガイドの不正使用の検出をご参照ください。

Amazon Bedrock コンソールで GPT-5.6 を試す

GPT-5.6 を最も手軽に試せるのは、Amazon Bedrock コンソールのプレイグラウンドです。コードや SDK のセットアップは不要です。プロンプトを送信し、推論パラメータを調整し、モデルを切り替えながら、API 統合の前に各モデルの感触を確かめられます。

モデルセレクターには地理的推論プロファイルとグローバル推論プロファイルの両方が表示されるため、コードを書く前にどちらのクロスリージョン推論オプションも試せます。

東京リージョンから試す手順:

Amazon Bedrock コンソールを開き、リージョンセレクターでアジアパシフィック (東京) ap-northeast-1 を選択します。
ナビゲーションペインの Test の下から Playground を選択します。
ページ中央の Select model を選択します。
OpenAI GPT-5.6 Sol を検索し、Global OpenAI GPT-5.6 Sol を選択して Apply を選択します。
プロンプトを入力し、Run を選択して応答を生成します。

まとめ

この記事では、Amazon Bedrock の OpenAI GPT-5.6 におけるクロスリージョン推論の仕組みと、東京・大阪リージョンをソースとして使う場合に押さえるべき論点を整理しました。

GPT-5.6 には 3 つのモデルがあります。要求の厳しいエージェント用途とコーディングには Sol、日常的な本番ワークロードには Terra、大量処理とレイテンシに敏感なアプリケーションには Luna です。

日本拠点のお客様にとって、この対応の実際的な意味は次の 3 点に集約されます。

グローバルキャパシティへのアクセス：東京リージョンと大阪リージョンはグローバル推論プロファイルのソースリージョンに含まれます。アプリケーションの接続先リージョンを変更することなく、いま使っている環境から GPT-5.6 を呼び出せます。
スループットの改善：グローバル推論プロファイルはリアルタイムのキャパシティ状況に基づいてルーティングするため、単一リージョンに固定した呼び出しよりも広い計算リソースのプールを利用できます。需要が集中する時間帯でも性能が安定しやすくなります。
可観測性はソースリージョンに集約される：呼び出しログ、CloudTrail、CloudWatch メトリクス、Service Quotas はすべて東京リージョンに記録されます。監視基盤を日本国外に分散させる必要はありません。

一方で、グローバル CRIS を使うと推論処理は日本国外のリージョンで実行されます。 執筆時点で GPT-5.6 がデプロイされているのは米国の 3 リージョンのため、実際の処理は米国内で行われますが、グローバル推論プロファイルは地理的範囲を限定しない仕組みであり、処理先を指定することもできません。データレジデンシー要件があるワークロードには適さず、レイテンシには処理先までのネットワーク往復が加わります。導入前に、この点を社内のセキュリティ・コンプライアンス担当と共有してください。

なお、GPT-5.6 に日本ジオ (jp.) の推論プロファイルは提供されていません。 推論処理を日本国内に限定する必要がある場合は、jp. プロファイルが提供されている他のモデル、または東京リージョンで In-Region 呼び出しに対応した他のモデルをご検討ください。実際の導入時には、記事中の list-inference-profiles コマンドと AWS 公式ドキュメントで最新の対応状況をご確認ください。

次のステップ

Amazon Bedrock コンソールを東京リージョンで開き、Playground から Global OpenAI GPT-5.6 Sol にテストプロンプトを送ってみてください。
実装に進む場合は、関連記事「東京リージョンから Amazon Bedrock の OpenAI GPT-5.6 を呼び出す実装ガイド」で、3 種類の API のコード例、IAM ポリシー、SCP、クォータ管理を解説しています。
本番ワークロードのサイジング前に、Amazon Bedrock の料金ページで GPT-5.6 の最新単価を確認してください。
問題が発生した場合やコミュニティに質問したい場合は、AWS re:Post で検索または投稿するのが有効です。

著者について

本橋和貴 (Motohashi, Kazuki) は、AWS Japan の機械学習ソリューションアーキテクトです。AI/ML 領域には9年ほど携わっており、最近は主に自動車業界のお客様を対象にAWS の生成 AI/ML サービスのご利用をサポートしています。博士 (理学)。

Amazon Web Services ブログ