「GPT-5.6はAmazon Bedrockから東京リージョンを起点に本番利用でき、どの推論プロファイルを選べばよいのでしょうか？」
2026年8月現在、GPT-5.6のSol・Terra・Lunaは東京（ap-northeast-1）を含む25超のAWSリージョンでGlobal cross-Region inferenceの呼び出し元として利用でき、地理制約がなければglobal.、処理地域を限定するならGeo、単一リージョン処理が必須なら対応するin-Region経路を選びます。
- 東京から使う基本形：
bedrock-runtime.ap-northeast-1.amazonaws.comへ接続し、global.openai.gpt-5.6-terraなどのGlobal推論プロファイルIDをモデルとして指定します。 - 2026年8月17日の変更：Responses、Chat Completions、Converseの3 APIが
bedrock-runtimeでGPT-5.6に対応し、GlobalとGeoのcross-Region inferenceが追加されました。 - 最重要の注意：東京を呼び出し元にできることと、推論処理が日本国内に留まることは同義ではありません。Globalは対応する商用AWSリージョンへ処理を振り分けます。
対象は、AWS上でOpenAIモデルを本番運用し、データ所在、SCP、IAM、キャッシュ、クォータを設計する開発者・クラウド基盤担当者です。
AWSは2026年8月17日のWhat’s NewでAPI拡張とcross-Region inferenceを発表し、8月20日のAWS Machine Learning Blogで東京を含むリージョン、推論プロファイル、IAM、SCP、キャッシュ、クォータまで具体化しました。ここでは、その2本を軸に「東京から呼べる」と「日本で処理される」を切り分けます。
扱う範囲はBedrock上のGPT-5.6配信基盤です。モデル内部のUltra modeやサブエージェント設計はGPT-5.6 Ultra modeとサブエージェント設計、エージェント実行基盤の刷新はBedrock Agents ClassicからAgentCoreへの移行ガイドが対象で、この記事とは論点が異なります。
GPT-5.6 Bedrockで何が変わったのか
最初に押さえたいのは、GPT-5.6がBedrockへ追加された日と、cross-Region inferenceが追加された日は別だという点です。Sol・Terra・Lunaの一般提供は2026年7月13日です。その後、8月17日にbedrock-runtime上で3 APIとGlobal・Geoの推論プロファイルが追加され、8月20日に実装・運用の詳細が公開されました。8月24日発表ではありません。
| 確認日 | AWSの発表内容 | 開発者への意味 |
|---|---|---|
| 2026年7月13日 | GPT-5.6 Sol・Terra・LunaがAmazon Bedrockで一般提供 | モデルファミリーをBedrockから利用可能になった |
| 2026年8月17日 | Responses、Chat Completions、Converseとcross-Region inferenceを追加 | bedrock-runtimeと推論プロファイルで既存AWS統制へ組み込みやすくなった |
| 2026年8月20日 | 25超のAWSリージョン、東京、IAM、SCP、キャッシュ、クォータの実装詳細を公開 | 本番設計に必要なルーティングと運用条件が明確になった |
3モデルはいずれもテキストと画像を入力し、テキストを出力します。AWSの8月20日記事では、1Mトークンのコンテキスト、reasoning mode、server-side tool calling、prompt cachingへの対応も明記されています。ResponsesとChat Completionsではストリーミング、AWS SDKではConverseStreamを利用できます。
ただし「1Mトークンまで入る」ことは、巨大な入力を毎回そのまま送る設計が最適だという意味ではありません。コンテキストの関連性、先頭応答までの時間、キャッシュヒット率、出力トークンのクォータ消費を別々に測る必要があります。
25超リージョンと推論プロファイルはどう読むのか
Cross-Region inference（CRIS）は、アプリケーションが各リージョンの容量を自前で監視して振り分ける仕組みではありません。モデルとルーティング可能なAWSリージョンの集合を定義した「推論プロファイル」をモデルIDの代わりに渡し、Bedrockが利用可能な計算資源へ処理を振り分けます。主目的は、単一リージョンの空き容量だけに縛られず、負荷時のスループットを確保しやすくすることです。
東京のアプリ（ap-northeast-1）
↓ bedrock-runtime
Global推論プロファイル（global.openai.gpt-5.6-terra）
↓ リアルタイムの容量に応じてルーティング
対応する商用AWSリージョンで推論処理
AWSの8月20日記事は、Globalプロファイルの呼び出し元として東京（ap-northeast-1）と大阪（ap-northeast-3）を含むリージョン群を掲載しています。ここでいう25超は、単一のモデルが常に25超リージョンへ同時に複製される、あるいは各リクエストが25超へ送信される、という意味ではありません。アプリケーションは1つのソースリージョンから1つの推論プロファイルを呼び、Bedrockがそのプロファイルの対象内から処理先を選びます。
Globalプロファイルの対象リージョン集合は、AWSが対応リージョンを追加すると変わる可能性があります。一方、地理にひも付くGeoプロファイルの処理先集合は固定されるとAWSドキュメントに記載されています。本番では記事中のリージョン一覧を設定ファイルへ転記して固定化せず、Supported Regions and models for inference profilesと各モデルカードをデプロイ前に再確認してください。
Global・Geo・in-Regionはどう選ぶべきか
選択基準は「速そうなもの」ではなく、処理地域の境界、必要な容量、API、価格条件です。2026年8月17日のAWS発表では、OpenAIモデルについてGlobal inferencingはin-RegionおよびGeo inferencingよりトークン単価が低いと説明されています。ここではモデル単価を固定値で転載しません。実際の見積もりはAmazon Bedrock料金ページで確認してください。
| 方式 | 代表的な指定 | 処理地域 | 向いている条件 | 確認すべき点 |
|---|---|---|---|---|
| Global CRIS | global.openai.gpt-5.6-terra |
モデルが展開された対応商用AWSリージョン | 地理的な処理制約がなく、広い容量プールを使いたい | データ所在、SCPのunspecified、変動する処理先集合 |
| Geo CRIS | us.openai.gpt-5.6-terra |
プロファイルで定義された地理内 | 対象地理の範囲内で容量を広げたい | ソースと全デスティネーションのIAM・SCP許可 |
| in-Region | openai.gpt-5.6-terra |
対応する単一リージョン | 処理を1リージョンへ固定する要件がある | bedrock-mantle側の対応リージョンとAPI機能 |
日本の開発チームにとって大事なのは、2026年8月20日のAWS記事がGPT-5.6のGeoとして具体的に示しているのはUS cross-Region inferenceだという点です。東京からGlobalは呼べますが、日本国内またはAPAC内だけで処理するGeoプロファイルが同記事に示されたわけではありません。日本国内処理が契約・社内規程の必須条件なら、Globalを選ぶ前に各モデルカードの現行リージョン表とAWS担当者への確認が必要です。
ログと処理場所も分けて考えます。CloudTrailイベントはソースリージョンに現れ、additionalEventData.inferenceRegionから実際の処理リージョンを確認できます。モデル呼び出しログを有効化した場合、ログは同じアカウントのソースリージョンにあるAmazon S3またはCloudWatch Logsへ配信できます。ログの保存場所が東京でも、推論処理そのものが東京とは限りません。
東京リージョンでSCPとデータ所在をどう設計するか
Global CRISではaws:RequestedRegionがunspecifiedになる
リージョン制限SCPを使っている組織では、Global CRISが最初の落とし穴です。AWSの8月20日記事によると、Global CRISがリージョン非依存のモデルARNを認可するとき、aws:RequestedRegionは特定のリージョン名ではなくunspecifiedになります。東京だけを許可するSCPでは、IAMが正しくても明示的Denyにより呼び出しが失敗し得ます。
AWSが推奨する考え方は、組織全体のリージョン許可リストを安易に広げるのではなく、bedrock:InferenceProfileArn条件で対象のCRISプロファイルを例外化することです。ソースリージョンである東京は従来どおり許可しつつ、Bedrockの推論プロファイル経由だけを通す設計にします。Geo CRISでは、プロファイルが含む全デスティネーションリージョンがSCP評価対象です。1リージョンでもブロックされると、他に許可済みの処理先があってもリクエストが失敗する点に注意してください。
IAMはプロファイルと処理先モデルの両方を許可する
OpenAI互換APIでBedrock APIキーを使う場合、少なくとも推論プロファイルとモデルへのbedrock:InvokeModel、デフォルトプロジェクト、Bearer認証用のbedrock:CallWithBearerTokenを確認します。ConverseStreamを使うなら、推論プロファイルと基盤モデルにbedrock:InvokeModelWithResponseStreamも必要です。AWS管理ポリシーで試せても、本番の最小権限ポリシーへ落とす際にデスティネーション側のモデルARNを抜かないようにしましょう。
通常データとabuse detection対象を混同しない
Amazon Bedrockは通常、zero operator accessとzero data retentionを基本とします。ただしAmazon Bedrock abuse detectionでは、GPT-5.6 Sol・Terra・Lunaについて、自動分類器がフラグした入出力をオフラインのabuse detection目的で最大30日保持すると明記されています。Cross-Region inferenceでフラグ対象になった入出力は、処理を担当したデスティネーションリージョンに保存されます。
これは「すべてのプロンプトが30日保存される」という意味でも、「GPT-5.6は無条件で完全なZDR」という意味でもありません。保持モード、モデルのallowed modes、契約要件を確認し、機密データを投入する前にデータ分類とDLPを設計してください。AWS文書上、保持されたデータは、利用者が明示的にオプトインしない限りモデルプロバイダーへ共有されません。厳格なZDRが必要な組織は、利用可能性をAWSアカウントチームへ確認します。
ClaudeをBedrockで利用する場合のZOAとデータ境界は、Claude Messages API on Bedrockとzero operator accessで別に整理しています。モデル提供者と保持条件が異なるため、Claudeの記事の結論をGPT-5.6へそのまま流用しないでください。
Sol・Terra・Lunaは何を基準に使い分けるか
Bedrockでは3モデルを同じAPI形状で呼べますが、最初からSolへ固定する必要はありません。高い推論能力が必要なタスク、日常的な本番タスク、高頻度で速度と効率を優先するタスクを分け、同一の評価セットで受入率、遅延、再試行、出力長を測ります。
使い分けの補助として、Kiroが2026年7月14日に公開したGPT-5.6公式案内が参考になります。KiroはIDE・CLI・Webで3モデルを提供し、Coding Agent Indexとクレジット乗数を公開しました。ただし、これらはKiro上の評価・消費条件であり、Bedrockのモデル単価や自社ワークロードの品質を示す数値ではありません。
| モデル | 最初に試すタスク | Kiro Coding Agent Index | Kiroクレジット乗数 |
|---|---|---|---|
| GPT-5.6 Sol | 複雑な実装、長いリファクタリング、高い失敗コストの推論 | 80 | 2.4倍 |
| GPT-5.6 Terra | 日常のコード生成、構造化抽出、汎用エージェント | 77.4 | 1.2倍 |
| GPT-5.6 Luna | 高頻度の分類、整形、短い反復タスク | 74.6 | 0.6倍 |
Kiroでは3モデルのコンテキストが272Kで、対象プランはPro、Pro+、Pro Max、Powerです。一方、Bedrockの8月20日記事は3モデルとも1Mトークンのコンテキストを示しています。数字が違うのは、Kiroというコーディング環境とBedrock APIという提供面が別だからです。対話的な開発作業をすぐ試すならKiro、IAM・SCP・VPC・ログ・コスト配賦まで含むアプリケーション基盤を構築するならBedrock、という役割分担が自然です。
AIエージェント全体のツール選定から見直す場合は、実在するピラー記事AIエージェントツール比較ガイドも参照してください。モデル、エージェントSDK、実行基盤、開発IDEを同じ評価軸で混ぜないことが選定の出発点です。
3つのAPIからどう呼び出すか
ここからは東京リージョンをソースにし、Global CRISのTerraを呼ぶ最小構成を示します。AWSの2026年8月20日公式例に沿った構文ですが、認証、モデルアクセス、SCP、クォータはアカウントごとに異なります。
OpenAI SDKを使う → 新規の応答・ツール中心ならResponses／既存資産を保つならChat Completions
AWS SDKでモデル共通化する → Converse／ストリーミングはConverseStream
動作前提：Python 3.11以上、openai、aws-bedrock-token-generator、またはboto3。API仕様確認日は2026年8月27日です。パッケージは隔離した検証環境へ導入し、採用するバージョンをロックファイルで固定してください。
Responses API：OpenAI SDKからGlobalプロファイルを呼ぶ
既存のOpenAI SDKベースのアプリケーションを移行する場合は、接続先を東京のbedrock-runtimeへ向け、モデル名をGlobal推論プロファイルIDへ置き換えます。短期Bedrock APIキーは既存のAWS認証情報から生成され、公式例では最長12時間有効です。
from aws_bedrock_token_generator import provide_token
from openai import OpenAI
region = "ap-northeast-1"
model_id = "global.openai.gpt-5.6-terra"
client = OpenAI(
base_url=f"https://bedrock-runtime.{region}.amazonaws.com/openai/v1",
api_key=provide_token(region=region),
)
response = client.responses.create(
model=model_id,
input="S3イベント駆動アーキテクチャの要点を3項目で整理してください。",
max_output_tokens=512,
)
print(response.output_text)
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。静的な長期キーをソースコードやコンテナイメージへ埋め込まないことがポイントです。実行ロールのAWS認証情報から短期キーを生成し、bedrock:CallWithBearerTokenと推論権限を最小化します。
Chat Completions API：reasoningと明示キャッシュを併用する
既存アプリがChat Completions形式を使っている場合は、client.chat.completions.createを維持できます。次の例は、1,024トークン以上の安定した社内ルールを明示キャッシュの対象にし、可変の質問を後ろへ置く形です。
from pathlib import Path
# 1,024トークン以上の安定した接頭辞を用意する
support_policy = Path("support_policy.txt").read_text(encoding="utf-8")
completion = client.chat.completions.create(
model="global.openai.gpt-5.6-terra",
messages=[
{
"role": "system",
"content": [
{
"type": "text",
"text": support_policy,
"prompt_cache_breakpoint": {"mode": "explicit"},
}
],
},
{
"role": "user",
"content": "破損した端末の返金受付で最初に確認する事項は？",
},
],
max_completion_tokens=512,
reasoning_effort="low",
prompt_cache_key="support-policy-v1",
)
print(completion.choices[0].message.content)
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。prompt_cache_keyは、同じ接頭辞を持つリクエストを同じキャッシュへ寄せるための補助キーです。キーを付けるだけでは不十分で、明示モードではprompt_cache_breakpointより前の内容をバイト列として安定させます。時刻、リクエストID、ユーザー固有情報を接頭辞へ混ぜるとキャッシュミスが増えます。
Converse API：AWS SDKの共通インターフェースを使う
複数モデルをAWS SDKの同じ呼び出し形へ寄せたい場合はConverseが便利です。OpenAI固有のreasoning_effortとprompt_cache_keyはadditionalModelRequestFieldsへ渡します。
import boto3
bedrock = boto3.client(
"bedrock-runtime",
region_name="ap-northeast-1",
)
response = bedrock.converse(
modelId="global.openai.gpt-5.6-terra",
messages=[
{
"role": "user",
"content": [
{"text": "メッセージキューの代表的な用途を3つ挙げてください。"}
],
}
],
inferenceConfig={"maxTokens": 512},
additionalModelRequestFields={
"reasoning_effort": "low",
"prompt_cache_key": "queue-guide-v1",
},
)
print(response["output"]["message"]["content"][0]["text"])
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。Converseの共通パラメータはinferenceConfigへ、モデル固有パラメータはadditionalModelRequestFieldsへ分けます。ストリーミングへ切り替える場合はconverse_streamを使い、IAMにストリーミング用アクションがあるか確認してください。
キャッシュとクォータをどう設計するか
キャッシュは長い安定接頭辞へ置く
GPT-5.6の3モデルはbedrock-runtimeでprompt cachingに対応します。Implicit cachingは既定で、最新のuserまたはtool message付近へ自動的にブレークポイントを置きます。Explicit cachingは、システム指示、ツール定義、参照文書など、繰り返し使う接頭辞の末尾を開発者が明示します。
各キャッシュブレークポイントの接頭辞には最低1,024トークンが必要です。短いプロンプトへ形だけブレークポイントを置いても条件を満たしません。AWSのprompt cachingドキュメントで、対象モデル、ブレークポイント数、TTL、利用APIの現行条件を確認してください。
- 変わらないsystem instruction、ツール定義、参照文書を前へ置く
- ユーザー入力、時刻、リクエスト固有値を後ろへ置く
cached_tokensとcache_write_tokensを計測し、ヒット率を確認する- GlobalとGeoの両方で、実際に使う推論プロファイルごとに負荷試験する
出力トークンはクォータ上10倍で消費される
GPT-5.6のon-demandクォータは推論プロファイルごとのTPMで管理され、GeoとGlobalは別の割当です。さらに、AWSの8月20日記事では入力トークンのburndownが1対1である一方、出力トークンのburndownは10倍とされています。長い回答を返すエージェントは、見かけの総トークン数より早くTPMを使い切る可能性があります。
クォータ上の概算は「入力トークン＋キャッシュ書き込み入力＋出力トークン×10」です。キャッシュから読み出した入力トークンはこの計算に含まれません。したがって、長い固定接頭辞をキャッシュし、max_output_tokensまたはmax_completion_tokensで必要以上の出力を抑えることは、コストだけでなくスロットリング対策にもなります。
CloudWatchでは推論プロファイルごとに呼び出し数、トークン、レイテンシ、スロットリング、エラーを分けて監視します。処理先リージョン単位だけでダッシュボードを作ると、アプリケーションが指定したプロファイルとクォータの関係を見失います。アラームと負荷試験もGlobal用とGeo用を分けてください。
本番導入で起きやすい失敗をどう避けるか
失敗1：東京から呼べるので日本国内処理だと思う
❌ ap-northeast-1のエンドポイントを使えば、プロンプトも東京だけで処理されると判断する。
⭕ ソースリージョン、推論プロファイル、デスティネーションリージョンを別の設定値として記録し、CloudTrailのinferenceRegionで処理先を監査する。
なぜ重要か：Global CRISは最も広い容量プールを使う設計であり、処理先を東京へ固定する機能ではありません。
失敗2：IAMだけ直してSCPの明示的Denyを見落とす
❌ ロールへbedrock:InvokeModelを追加すればGlobal CRISも動くと考える。
⭕ aws:RequestedRegion=unspecifiedとbedrock:InferenceProfileArnを前提に、Organizations側のSCPをセキュリティチームと確認する。
なぜ重要か：IAMのAllowは、上位のSCPにある明示的Denyを上書きできません。
失敗3：1Mコンテキストを毎回送り直す
❌ リポジトリや規程集を毎リクエストへ連結し、キャッシュヒット率と検索精度を測らない。
⭕ 安定接頭辞を1,024トークン以上の単位でキャッシュし、可変入力を後ろへ分離する。必要な証拠だけを選ぶRAGも併用する。
なぜ重要か：コンテキスト上限は容量の上限であって、関連性、遅延、受入品質を保証しません。
失敗4：モデル単価だけで必要クォータを見積もる
❌ 入出力トークンを同じ重みで数え、出力の長いエージェントを本番へ入れる。
⭕ 出力トークン10倍のburndownをクォータ計算へ反映し、GlobalとGeoを別々に負荷試験する。
なぜ重要か：コスト見積もりが収まっていても、TPMを先に使い切ればスロットリングが発生します。
失敗5：Bedrock APIキーを固定シークレットとして長期運用する
❌ 検証用に発行したキーをソースコード、CIログ、コンテナイメージへ残す。
⭕ 実行ロールのAWS認証情報から短期キーを生成し、Secrets Manager等の利用方針とローテーションを明文化する。
なぜ重要か：AWS公式例の短期キーは最長12時間です。認証更新を前提にしない実装は、期限切れか固定キー依存のどちらかになります。
よくある質問
GPT-5.6 Bedrockは東京リージョンから使えますか？
はい。2026年8月20日のAWS公式記事では、東京（ap-northeast-1）がGPT-5.6 Global cross-Region inferenceのソースリージョンに含まれています。bedrock-runtimeの東京エンドポイントとglobal.openai.gpt-5.6-*の推論プロファイルIDを使います。
東京から呼べば、データは日本国内だけで処理されますか？
いいえ。Global CRISは対応する商用AWSリージョンへ処理を振り分けます。日本国内処理が必須なら、Globalを前提にせず、現行モデルカードのin-Region・Geo対応と契約条件を確認してください。
GlobalとUS Geoの推論プロファイルIDは何が違いますか？
global.openai.gpt-5.6-terraは対応商用リージョンの広い容量プールを使います。us.openai.gpt-5.6-terraはUS地理内の定義済みリージョンへ処理を限定します。後者を東京から使えるという意味ではありません。
Responses、Chat Completions、Converseのどれを選べばよいですか？
OpenAI SDKの新規実装やResponses形式を使うならResponses、既存のChat Completions資産を保つならChat Completions、複数のBedrockモデルをAWS SDKの共通形へ寄せるならConverseが候補です。ストリーミング、モデル固有パラメータ、認証方式を含めて検証してください。
Global CRISはいくらですか？
この記事では変動するモデル単価を転載しません。AWSは2026年8月17日の発表で、OpenAIモデルのGlobal inferencingはin-RegionおよびGeo inferencingよりトークン単価が低いと説明しています。現在の単価はAmazon Bedrock料金ページで確認してください。
1MトークンのコンテキストならRAGやキャッシュは不要ですか？
不要にはなりません。RAGは必要な証拠と権限境界を絞り、キャッシュは長い固定接頭辞の再計算を減らします。1Mは入力可能な上限であり、関連性、速度、コスト、クォータを保証する数値ではありません。
GPT-5.6のすべての入出力が30日保持されますか？
いいえ。AWS公式ドキュメントが最大30日保持するとしているのは、自動abuse-detection分類器でフラグされたトラフィックです。保持モードとモデル条件を確認し、通常ログの設定とは分けて評価してください。
KiroのGPT-5.6とBedrockのGPT-5.6は何が違いますか？
KiroはIDE・CLI・Webで使うコーディング環境で、Kiro独自のクレジット乗数と272Kコンテキストが示されています。Bedrockはアプリケーション向けAPI基盤で、IAM、SCP、VPC、ログ、Global・Geoルーティング、1Mコンテキストを扱います。同じモデル名でも提供面と運用条件が異なります。
参考・出典
- Amazon Bedrock expands API support and introduces Cross Region Inferencing for OpenAI models — AWS、2026年8月17日（参照日：2026年8月27日）
- Introducing cross-Region inference for OpenAI GPT-5.6 models on Amazon Bedrock — AWS Machine Learning Blog、2026年8月20日（参照日：2026年8月27日）
- Supported Regions and models for inference profiles — Amazon Bedrock User Guide（参照日：2026年8月27日）
- Prompt caching for faster model inference — Amazon Bedrock User Guide（参照日：2026年8月27日）
- Amazon Bedrock abuse detection — Amazon Bedrock User Guide（参照日：2026年8月27日）
- GPT-5.6 Terra model card — Amazon Bedrock User Guide（参照日：2026年8月27日）
- GPT-5.6 is now available in Kiro — Kiro、2026年7月14日（参照日：2026年8月27日）
- Amazon Bedrock pricing — AWS（参照日：2026年8月27日）
ここまでの要点
GPT-5.6 Bedrockを東京から使う最短経路は、東京のbedrock-runtimeエンドポイントへ接続し、global.openai.gpt-5.6-*をモデルとして渡す構成です。ただしGlobalは日本国内処理を保証しません。処理地域を制約する要件がある場合は、Geoまたはin-Regionの現行対応をモデルカードで確認してください。
- 8月17日の追加対象はResponses、Chat Completions、ConverseとGlobal・Geo CRIS
- 東京はGlobal CRISのソースリージョンだが、デスティネーションは固定されない
- Global CRISのSCPでは
aws:RequestedRegion=unspecifiedを考慮する - キャッシュブレークポイントは1,024トークン以上、出力トークンのクォータburndownは10倍
- 自動abuse detectionでフラグされたトラフィックは最大30日保持され得る
- Kiroのクレジット・272KコンテキストとBedrockの料金・1Mコンテキストは別の提供条件
実装前には、対象データを「Globalで処理可」「地理内のみ」「単一リージョンのみ」に分類し、その結果から推論プロファイルを選びます。その後に東京ソースで最小コードを動かし、CloudTrailの処理リージョン、CloudWatchのプロファイル別メトリクス、キャッシュヒット、出力burndownを負荷試験で確認してください。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
