Amazon Bedrockが、OpenAIのGPT-5.6モデルであるTerraとLunaを、インド地域のクロスリージョン推論(India geographic cross-Region inference)でインドにおいてサポートしました。金融サービス、ヘルスケア、公共部門を含め、インドにローカルなデータ処理要件がある場合に、これらのOpenAIモデルであるTerraとLunaを大規模に利用でき、Amazon Bedrockは推論リクエストとデータをインド国内で処理します。

GPT-5.6のTerraとLunaは、長い文書、大規模なコードベース、およびテキストと画像が混在するワークロードを1回のリクエストで処理できます。インド地域のクロスリージョン推論において、これらの処理は国外に出ません。

インド地域のクロスリージョン推論の仕組み

インド地域のクロスリージョン推論では、Amazon Bedrockはリクエストをアジアパシフィック(ムンバイ)リージョン(ap-south-1)やアジアパシフィック(ハイデラバード)リージョン(ap-south-2)などのインド地域内のリージョン間のみでルーティングします。データをインド国内で処理したままデータレジデンシー要件を満たしつつ、需要に合わせてスケールできます。リクエストはap-south-1とap-south-2の間でのみルーティングされ、入力プロンプトと出力結果はこの2つのリージョン間で移動することがあります。データはAmazonネットワーク内の転送中に暗号化されます。

インド地域の地理的推論プロファイル(India geographic inference profiles)は2つあり、GPT-5.6 Terraには `in.openai.gpt-5.6-terra`、GPT-5.6 Lunaには `in.openai.gpt-5.6-luna` を使います。いずれかのインドのリージョンをソースとして推論プロファイル(inference profile)を呼び出すと、Amazon Bedrockがキャパシティに基づいて宛先のインドのリージョンへリクエストをルーティングします。ワークロードにローカルのデータ処理要件がある場合は、推論を国内にとどめる`in.`をプレフィックス(prefix)とするIndia推論プロファイルを使用し、グローバルクロスリージョン推論(global cross-Region inference)は使用しません。

クロスリージョン推論(cross-Region inference)は、複数のAWSリージョンにまたがって推論リクエストを自動的にルーティングしてスループットの向上を助け、各リージョンのキャパシティを自分で管理する必要がない仕組みであり、主にキャパシティのための仕組みです。リクエストが1つのリージョンのキャパシティに縛られず、より広いコンピュートのプールを利用するため、負荷時にスループットと安定した性能を維持するのに役立ちます。負荷時にスループットと安定した性能を維持できることは、トラフィックのピーク時に最も重要になります。インド地域のクロスリージョン推論では、推論を国内に保ったまま、ムンバイとハイデラバードのリージョンにまたがってスケールできます。

プロンプトキャッシュの割引とモデルの仕様

Amazon Bedrock上のGPT-5.6モデルのプロンプトキャッシュでは、キャッシュからの読み取りが、キャッシュされない入力トークンと比べて90パーセント割引で課金されます。Retrieval Augmented Generation(RAG)やエージェントのワークロードでは、多くのターンにわたって同じコンテキストを繰り返すため、このキャッシュ読み取りの割引がすぐに積み上がります。プロンプトキャッシュはインド地域の地理的推論プロファイルでも使えるため、インドのデータレジデンシー境界の下でもコスト削減を維持できます。

Amazon Bedrockは、OpenAIのGPT-5.6モデルであるTerraとLunaをインドでサポートしており、インド地域のクロスリージョン推論を利用できます。どちらのモデルも100万トークン(1-million-token)のコンテキストウィンドウを持ち、テキストと画像の入力を受け付けて、テキストを出力します。Amazon Bedrock上のGPT-5.6モデルは、OpenAI Responses APIの形式にネイティブ対応しています。

Responses APIでは、入力に単一の`input`フィールドを使い、生成されたテキストは`output_text`で返されます。出力の上限は`max_output_tokens`で設定します。アプリケーションがすでにOpenAIのモデルを呼び出している場合は、既存のOpenAI SDKのクライアントをインドのリージョン(ムンバイまたはハイデラバード)のAmazon Bedrockエンドポイントに向け、`model`パラメータにインドの地理的推論プロファイルIDを渡せば、そのクライアントをResponses APIにもChat Completions APIにも使えます。GPT-5.6モデルで推論の深さを制御するには、任意のパラメータ`reasoning`を設定できます（例: `reasoning={"effort": "low"}`）。Amazon Bedrock上のGPT-5.6モデルがサポートする推論の強度(reasoning effort)のレベルは、`none`、`low`、`medium`、`high`、`xhigh`、`max`です。`reasoning`パラメータを省略すると、モデルのデフォルトが使われます。

Responses APIでマルチターンの会話をするときは、`store=True`を設定するとAmazon Bedrockがレスポンスをサーバー側に保持します。次のターンでは`previous_response_id`でそのレスポンスを参照し、新しいターンだけを送ればよく、それまでの会話履歴を再送する必要はありません。ただし、`previous_response_id`でつなぐ場合、つなぎ元のレスポンスは`store=True`で作成されている必要があり、保存されていないレスポンスからつなぐとエラーが返ります。Responses APIでストリーミングするには、`stream=True`を設定してイベントを順に処理(iterate)します。

Amazon Bedrock上のGPT-5.6モデルは、system instruction、knowledge baseの抜粋、few-shot例の集合のように、プロンプトが長く安定した共通のプレフィックスを共有する場合に、プロンプトキャッシュ(prompt caching)をサポートします。プロンプトキャッシュにはimplicit(暗黙的)とexplicit(明示的)の2つのモードがあります。implicitキャッシュでは、Amazon Bedrockがキャッシュブレークポイントを自動的に配置し、最小プレフィックス長は1,024トークンです。explicitキャッシュでは、ユーザー自身がキャッシュ境界を指定して精密に制御でき、キャッシュされたプレフィックスは少なくとも30分間は有効(warm)な状態に保たれます。

プロンプトキャッシュを使った最初の呼び出しでは、プレフィックスが保存される際に`cache_write_tokens`に値が入ります。後続の呼び出しでは、同じトークンが`cached_tokens`として返り、キャッシュ読み取りレートで課金されます。`cache_write_tokens`と`cached_tokens`の件数は`input_tokens`に上乗せされるのではなく`input_tokens`の一部であるため、キャッシュされたトークンは1回だけカウントされ、課金されます。

Amazon Bedrockはzero data retention(ZDR、データ保持0)のデータセキュリティモデルを採用しており、デフォルトではモデルの入力も出力も保存しません。ただし、GPT-5.6を含む一部のモデルでは、Amazon Bedrockの自動不正利用検知分類器(classifier)がフラグを立てたコンテンツが、オフラインの不正利用検知のために保持されます。詳細はAmazon Bedrock User GuideのAbuse detectionを参照してください。

Amazon Bedrockはインドでも、グローバルクロスリージョン推論と、`global.`をプレフィックスとするグローバル推論プロファイルを提供しています。これらは最大のキャパシティを得るため、世界中の対応する商用AWSリージョンにルーティングします。グローバルクロスリージョン推論は、Sol、Terra、LunaなどのOpenAI GPT-5.6モデルに対応しています。

グローバル推論プロファイルを使う場合、モデルIDにグローバルプロファイルIDを指定して、インドリージョンのエンドポイントであるAsia Pacific (ムンバイ) ap-south-1またはAsia Pacific (ハイデラバード) ap-south-2にリクエストを送ります。リクエストを処理する宛先リージョンは、Amazon Bedrockが決める。

インド地域の地理的推論プロファイルは、bedrock-runtimeエンドポイントで利用可能であり、このエンドポイントは新規アプリケーションに推奨されています。既存のワークロードがbedrock-mantleエンドポイント上にある場合は、引き続き完全にサポートされ変更も不要ですが、インド地域の地理的推論プロファイルを採用するには、そのワークロードをムンバイまたはハイデラバードのbedrock-runtimeエンドポイントに向ける必要があります。

認証方法として、Amazon Bedrockは標準のAWS認証情報かAmazon Bedrock APIキー(Amazon Bedrock API key)のどちらかを受け入れます。OpenAI SDKにはAPIキーを使う方法が適しており、SDKはAPIキーをbearer tokenとして渡します。本番環境では、`aws-bedrock-token-generator`パッケージを使用して短期のAPIキーをプログラムで生成することが勧められています。このパッケージは既存のAWS認証情報からbearer tokenを導出するため、静的なキーを保存する必要がありません。

組織がService Control Policy(SCP)を使用して未使用リージョンを制限している場合、リージョン固有のSCP条件は、地理的推論プロファイルに記載されたすべての宛先リージョン(destination Region)を許可しなければなりません。インド地域での推論の地理的推論プロファイルでは、`ap-south-1`と`ap-south-2`の両方を許可する必要があります。どちらか一方の宛先リージョンをブロックすると、ソースリージョンがアクセス可能な状態であっても、クロスリージョン推論は失敗します。

インド地域での推論の地理的推論プロファイルは、Amazon Bedrockの他のモデルですでに使用しているものと同じアカウントレベルの制御で動作します。リクエストは、オンデマンドリクエストと同様にAmazon Bedrockのモデル呼び出しログ(model invocation logging)に記録されます。これらのログは、Amazon Simple Storage Service(Amazon S3)またはAmazon CloudWatch Logsに配信できます。

呼び出し回数、トークン数、レイテンシ、スロットル、エラーのCloudWatchメトリクスは、推論プロファイルごとに公開されます。ムンバイまたはハイデラバードからのGPT-5.6モデルの使用状況を、リージョンをまたぐログを自分で突き合わせることなく追跡できます。どの宛先リージョンが特定のリクエストを処理したかを確認するには、CloudTrailイベントの`additionalEventData`フィールドにある`inferenceRegion`キーを見ます。インドのプロファイルでは、この値は常に`ap-south-1`または`ap-south-2`であり、推論がインド国内にとどまったことの監査可能な記録になります。

使用量はAWS Cost ExplorerとAWS Cost and Usage Reportに項目別に表示されます。モデル別の支出の帰属は、Amazon Bedrockの他のワークロードと同じように機能します。

GPT-5.6 TerraおよびLunaモデルは、OpenAI Responses API、OpenAI Chat Completions API、Amazon Bedrock Converse APIのいずれからでも呼び出すことが可能です。

AWSは、本番ワークロードの規模を見積もる前に、現行のGPT-5.6の料金をAmazon Bedrockの料金ページで確認することを勧めています。また、GPT-5.6 TerraとLunaを使い始めるにあたっては、両モデルのモデルカードとAmazon Bedrock User GuideのCross-Region inferenceのセクションを確認し、ムンバイまたはハイデラバードのAmazon Bedrockコンソールでのプレイグラウンドでプロンプトを試したうえで、コード例を組み込むよう勧めています。

ユーザーはプロファイルIDをモデルとして呼び出し、そのプロファイルが、使用するモデルとAmazon BedrockがリクエストをルーティングできるAWSリージョンを定義します。インド地域の地理的推論プロファイルは、そのルーティングをインド国内に留めます。

推論プロファイルを使用する場合、どのバックエンドのリージョンがリクエストを処理したかにかかわらず、課金とクォータ消費はソースリージョンのアカウントに対して追跡されます。Amazon CloudWatchとAWS CloudTrailはログエントリをソースリージョンにのみ記録するため、モニタリングは1か所に留まります。新規アプリケーションには、bedrock-runtimeエンドポイントの利用が推奨されています。このbedrock-runtimeエンドポイントは、Bedrock-nativeのInvokeModel APIとConverse API、OpenAI互換のResponses APIとChat Completions API、Anthropic Messages APIをサポートしています。また、Guardrails、intelligent prompt routing、クロスリージョン推論といったAmazon Bedrockの機能が利用できるのもこのエンドポイントです。

コンソール、認証とIAM権限、Codexでの利用

Amazon Bedrockコンソールのtext playgroundでは、コーディングやSDKのセットアップなしにGPT-5.6を試せます。プロンプトの送信、推論パラメータの調整、バリアントの切り替えができ、APIを組み込む前に各モデルの感触をつかむことが可能です。まず、モデルが利用できるリージョン（例：Asia Pacific (ムンバイ) ap-south-1）でAmazon Bedrockコンソールを開きます。次に、ナビゲーションペインのTestの下でPlaygroundを選択します。ページ中央のSelect modelを選択し、OpenAI GPT-5.6 Terraを検索して、IN OpenAI GPT-5.6 Terraを選択し、Applyを選択します。プロンプトを入力してRunを選択すると、応答が生成されます。

APIキーではなくAWS SDKとSigV4認証を使いたい場合、Amazon BedrockのConverse APIがGPT-5.6モデルをサポートしており、Amazon Bedrock上の他のモデルと同じ統一インターフェースで利用できます。ストリーミングには`ConverseStream`が対応しています。OpenAIのResponses APIとChat Completions APIは、`bedrock:CallWithBearerToken`と`bedrock:InvokeModel`を`project/default`リソースに対して付与するポリシーを使うことで、Amazon Bedrock APIキーで認証して推論を実行できます。IAMポリシーで付与するfoundation modelへのアクセスは、`bedrock:InferenceProfileArn`条件によって1つのプロファイルに限定され、ポリシーは`project/default`リソースに対して`bedrock:CallWithBearerToken`と`bedrock:InvokeModel`も付与します。

AWS Identity and Access Management(IAM)ロールがインド地域の地理的推論プロファイル経由でGPT-5.6モデルを呼び出せるようにするには、3つのリソースへのアクセス権限を付与する必要があります。これらは、インド地域の地理的推論プロファイル自体、ソースリージョンのfoundation model(FM)、そしてプロファイルに記載された各宛先リージョンのfoundation modelです。具体的には、1つ目のstatementでソースリージョンから発信されるリクエストに対してインド地域の地理的推論プロファイルへのアクセスを付与し、2つ目のstatementでソースリージョンとすべての宛先リージョンのfoundation modelへのアクセスを付与します。権限の付与には、AmazonBedrockLimitedAccessマネージドポリシーを使うことも独自のポリシーを作成することもできます。GPT-5.6 Terraを使う権限の例では、ソースリージョンがap-south-1、宛先リージョンがap-south-1とap-south-2です。`<ACCOUNT>`は自分のアカウントIDに置き換え、ロールが両方のモデルを必要とする場合は`in.openai.gpt-5.6-luna`用にリソースを複製します。ハイデラバードをソースにする場合は、1つ目のstatementでap-south-2の推論プロファイルARNを使います。2つ目のstatementのfoundation modelリソースは、すでにインドの両リージョンを列挙しているため変わりません。

Codexは、Amazon Bedrock Runtimeを通じて地理的推論プロファイルを利用できます。Amazon Bedrock Runtime モデルプロバイダーを使うCodex CLI(codex-cli 0.149.1 以降)のセットアップでは、まずガイドに従い、IDプロバイダー、対応するAWSフェデレーションリソース、Bedrock権限を持つIAMロールを設定し、そのうえで `~/.aws/config` に名前付きプロファイルを追加します。この名前付きプロファイルを使うのは、ヘルパーがデフォルトプロファイルで解決される認証情報を置き換えないようにするためです。IDプロバイダーがOkta、Auth0、Microsoft Entra ID、Amazon Cognito、AWS IAM Identity Centerのいずれかである組織向けに、AWS OIDC Auth Helperリポジトリがサンプルの認証情報ヘルパーを提供しています。このフェデレーションヘルパーはOIDCトークンを一時的なAWS認証情報に交換し、Codexは標準のAWS認証情報チェーンを通じてそれを読み取るため、追加の設定は不要です。次に、`~/.codex/config.toml` を作成または更新し、AWSプロファイルを参照させます。Codexで使うAWSプロファイルのヘルパーに有効なキャッシュ済みセッションがない場合、ヘルパーは設定されたサインインページをブラウザで開きます。Amazon Bedrock上のGPT-5.6をCodexから使う場合、リクエストはAWS SigV4で署名されます。プロファイルがAWS IAM Identity Centerに基づいている場合、認証情報はすでに短期のものであり、SSOセッションとともにローテーションされます。認証すると、ヘルパーはcredential_processを通じて一時的なAWS認証情報を返します。

Codexをアジアパシフィック(ハイデラバード)リージョン(ap-south-2)で使うには、AWSプロファイルとCodexの設定の両方で、リージョンをap-south-2に設定する必要があります。ローカルにすでにAWS認証情報が設定されている場合、Codexはそれを直接使えます。この場合は、Amazon Bedrock RuntimeプロバイダーをAWSプロファイルとインドのリージョンに向け、モデルにはインドの地理的推論プロファイルIDを設定します。