2026年8月27日、Amazon BedrockでOpenAI GPT-5.6 TerraとLunaをインド国内で推論できるようになりました。インドにデータ処理要件を持つシステムでも、Bedrockの運用基盤から両モデルを選べる更新です。

ただし、「インド国内で処理される」と「Mumbaiだけで処理される」は同じ意味ではありません。今回の仕組みは、MumbaiとHyderabadの容量を使う地理的クロスリージョン推論です。

採用判断の鍵は、国境内という境界を守りながら、二つのAWSリージョンへ処理を分散する点にあります。APIの変更量だけでなく、権限、保存、監査までつなげると、この更新をどのワークロードに使えるかが見えてきます。

インドGeoプロファイルはMumbaiとHyderabadを容量で使い分ける

India geographic cross-Region inferenceでは、Asia Pacific (Mumbai)のap-south-1、Asia Pacific (Hyderabad)のap-south-2のどちらかを呼び出し元にします。Amazon Bedrockは容量に応じて、この二つのリージョン内で推論先を選びます。

利用者がリージョンごとの容量配分やクライアント側ルーティングを組む代わりに、推論プロファイルがモデルと転送可能なリージョン集合をまとめます。モデルIDはTerraがin.openai.gpt-5.6-terra、Lunaがin.openai.gpt-5.6-lunaです。

この考え方は突然現れたものではありません。Amazon Bedrockのクロスリージョン推論は2024年8月27日に、トラフィック急増時に複数リージョンの計算資源を使う仕組みとして公開されました。今回のIndia Geoプロファイルは、その容量分散をインドという地理境界の内側に限定します。

Amazon Bedrockの推論方式を境界で比べると、違いは次のようになります。

つまり、インド国内処理が要件ならin.で始まるプロファイルを選びます。単一リージョン固定が要件なら、India Geoはその代替ではありません。プロンプトと出力はインド国外へ出ませんが、MumbaiとHyderabadの間を移動する可能性があるためです。

bedrock-runtimeではエンドポイントとmodelIdが処理境界を決める

新規アプリケーションにはbedrock-runtimeエンドポイントが案内されています。OpenAI互換のResponses APIとChat Completions APIに加え、Amazon BedrockのConverse APIを利用できるため、既存クライアントの構成に合わせて入口を選べます。

OpenAI SDKからResponses APIを呼ぶ最小構成は、エンドポイントをインドのリージョンへ向け、modelへIndia GeoプロファイルIDを渡す形です。次はTerraをMumbaiから呼ぶ例です。

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

REGION = "ap-south-1"
MODEL_ID = "in.openai.gpt-5.6-terra"

# AWS認証情報から短期トークンを取得し、静的なAPIキーの保存を避けます。
client = OpenAI(
    base_url=f"https://bedrock-runtime.{REGION}.amazonaws.com/openai/v1",
    api_key=provide_token(region=REGION),
)

# India Geoプロファイルをmodelへ指定し、処理範囲をインド国内に限定します。
response = client.responses.create(
    model=MODEL_ID,
    input="請求書から支払期限と合計金額を抽出し、JSONで返してください。",
    max_output_tokens=512,
)

print(response.output_text)

既存のbedrock-mantleワークロードは引き続きサポートされますが、India Geoプロファイルを使うにはMumbaiまたはHyderabadのbedrock-runtimeへ向け直します。AWS SDKとSigV4認証を統一したい場合は、同じプロファイルIDをConverse APIへ渡す設計も選べます。

TerraとLunaは同じ国内境界でも役割が異なる

両モデルは100万トークンのコンテキストウィンドウを持ち、テキストと画像を入力してテキストを出力します。一方、AWSのモデルカードはTerraを一般的な本番処理向けのバランス型、Lunaを分類・要約・ルーティングなど大量処理向けの高速・低コスト型として位置付けています。

これは用途選定の出発点であり、品質やレイテンシを保証する比較結果ではありません。同じ代表データと評価基準で両モデルを試し、出力品質、応答時間、トークン消費を測ってから選ぶのが自然です。長いコンテキストを受け取れることと、毎回100万トークンを渡すことが最適であることも別の話ですね。

IAMとSCPは二つのインドリージョンを許可する

アプリケーションから見える変更はエンドポイントとモデルIDが中心ですが、組織側のリージョン制御は二リージョン分が必要です。地理的クロスリージョン推論のIAM要件では、推論プロファイル、呼び出し元リージョンの基盤モデル、すべての転送先リージョンの基盤モデルへの権限が必要とされています。

India Geoではap-south-1とap-south-2の両方を許可します。AWS OrganizationsのSCPで未使用リージョンを拒否している場合、どちらか一方でもブロックすると、許可済みの呼び出し元リージョンからでもクロスリージョン推論が失敗します。bedrock:InferenceProfileArn条件で利用可能なプロファイルを絞れば、二リージョンを開けながら呼び出し先を限定できます。

国内処理でも保存と監査は別々に設計する

データレジデンシーは「どこで推論処理されるか」の境界です。「何も保存されない」ことを無条件に意味するわけではありません。Amazon Bedrockはデフォルトでモデル入出力を保存しないZDRを採用していますが、GPT-5.6 Terra/Lunaでは悪用検知分類器がフラグを付けたトラフィックを、オフラインの悪用検知用に最大30日保持します。クロスリージョン推論時の保持先は、実際に処理した転送先リージョンです。

Responses APIでstore=Trueを指定して会話状態をサーバ側に残す場合や、利用者側で呼び出しログを有効化する場合も、明示的な保存経路が増えます。モデル呼び出しログはデフォルトで無効で、有効にすると設定に応じてリクエスト、レスポンス、メタデータをCloudWatch LogsまたはS3へ配送します。ログの保存期間、暗号化、アクセス権も推論境界とは別に決める必要があります。

監査では、CloudTrailイベントのadditionalEventData.inferenceRegionから実際の処理先を確認できます。India Geoならap-south-1またはap-south-2になり、国内処理を運用記録として追えます。

採用判断は「国内・二リージョン」を一つの要件として行う

India Geoプロファイルが合うのは、インド国外へ推論を出せない一方、MumbaiとHyderabadのどちらで処理されてもよいワークロードです。単一リージョン固定が必要なシステムでは、今回の機能だけで要件を満たすとは判断できません。

導入時は、次の順序にすると境界を見失いにくくなります。

1. コンプライアンス要件が「インド国内」か「単一リージョン」かを言葉で分ける。
2. bedrock-runtimeとin.openai.gpt-5.6-*で代表データを試し、TerraとLunaを比較する。
3. IAMとSCPでMumbai・Hyderabadの両方を許可し、利用プロファイルを条件で絞る。
4. ZDRの例外、store、呼び出しログ、CloudTrail、現在の料金を本番運用の設計へ落とし込む。

この更新の実務的な意味は、OpenAIモデルをインド国内で使えることだけではありません。国境内の二リージョンを一つの推論容量として扱い、その境界をモデルID、権限、ログで一貫して管理できることにあります。そこまで設計できるワークロードなら、データレジデンシーとスケールを両立する選択肢になります。

出典

• Title: Introducing OpenAI models on Amazon Bedrock for in-country inferencing in India
• URL: https://aws.amazon.com/blogs/machine-learning/introducing-openai-models-on-amazon-bedrock-for-in-country-inferencing-in-india/