Bedrock Mantle の Responses API はどこまで Azure と互換性があるか試してみた
前回の記事では、Codex CLI v0.124.0 を用いて Bedrock Mantle の Responses API に接続し、AWS 認証だけでコーディングエージェントが利用できることを確認しました。
Bedrock Mantle での Responses API の基本的な使い方は、たかくにさんの記事も参照してください。
2026 年 2 月、OpenAI と Amazon は戦略的パートナーシップを発表し、Bedrock 上で動作する Stateful Runtime Environment の共同開発を発表しました。それから約 2 ヶ月、4 月 28 日に Amazon CEO の Andy Jassy は Bedrock 上での OpenAI モデル提供が数週間以内に始まると言及しています。
一方、Azure AI Foundry では Responses API が 2025 年から GA 済みで、previous_response_id によるステートフル会話やサーバーサイドツール(web_search、code_interpreter、file_search)を含むフル機能が利用可能です。
本命は近日提供予定の GPT-5 系モデルですが、今回はその到来に備え、現時点で動くモデルを使って Responses API のポータビリティとアーキテクチャの差分をあらかじめ素振りしておきます。
検証環境
| Azure AI Foundry | Bedrock Mantle | |
|---|---|---|
| リージョン | East US 2 | us-east-1 |
| モデル | gpt-4.1-mini | openai.gpt-oss-120b |
| エンドポイント | /openai/v1/responses |
/v1/responses |
| 認証 | API Key | AWS IAM (SigV4) |
Azure と Bedrock で Responses API に対応しているモデルが異なるため、それぞれで利用可能なモデルを使用しました。Azure は GPT-5 系を含む多数のモデルが対応していますが、Bedrock は openai.gpt-oss-120b と openai.gpt-oss-20b の 2 モデルのみです(第1弾で検証済み)。また、Azure 上の gpt-oss-120b は Responses API に非対応(Chat Completions のみ)のため、同一モデルでの比較はできない状況です。
比較の軸はモデルの性能差ではなく、Responses API のレスポンス構造の互換性とツール対応の差に絞っています。
ステートフル会話(previous_response_id)
Responses API の previous_response_id を使うと、サーバー側で会話履歴が保持されるため、クライアント側で履歴を管理せずにコンテキストを引き継げます。ただし、内部的には過去の入出力がプロンプトに含まれて課金されるため、ターンが進むと課金対象のトークン量が増える可能性があります。ワークロードに応じた使い分けが必要です。
実務的なシナリオとして、ECS タスクのエラーログ解析を試しました。
Azure AI Foundry
Turn 1 で CloudWatch のエラーログを投げます。curl 内の gpt-41-mini はデプロイ名です(モデル名 gpt-4.1-mini のデプロイ時にピリオドを含められないため)。
curl -s "${ENDPOINT}openai/v1/responses" \
-H "Content-Type: application/json" \
-H "api-key: ${KEY}" \
-d '{
"model": "gpt-41-mini",
"instructions": "You are a DevOps engineer assistant. Be concise.",
"input": "Our ECS task keeps failing. Here is the error from CloudWatch:\n\nResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 3 time(s): RequestError: send request failed caused by: Post https://api.ecr.us-east-1.amazonaws.com/: dial tcp 10.0.1.42:443: i/o timeout"
}'
レスポンス(jq '{id, object, status, output: [.output[] | {type, content}]}' で抽出):
{
"id": "resp_087784ee8eba51a60069f0bed6d29c819585e6d3c2530c9844",
"object": "response",
"status": "completed",
"output": [
{
"type": "message",
"content": [
{
"type": "output_text",
"text": "The ECS task is failing because it cannot retrieve ECR registry auth due to a network timeout when trying to reach the ECR endpoint.\n\n**Likely causes:**\n1. The ECS task's subnet does not have proper internet access or NAT gateway configured.\n2. Security group or NACL blocking outbound HTTPS (port 443).\n3. Missing or incorrect VPC endpoint for ECR if running in a private subnet without internet.\n\n**Actions to fix:**\n- Ensure the ECS tasks are in subnets with NAT Gateway or Internet Gateway for outbound HTTPS access.\n- Check and allow outbound port 443 in Security Groups and NACLs.\n- Alternatively, configure VPC Endpoints for ECR (`com.amazonaws.us-east-1.ecr.api` and `com.amazonaws.us-east-1.ecr.dkr`) and for S3 if needed to avoid internet dependency."
}
]
}
]
}
Turn 2 で previous_response_id を付けてフォローアップします。エラーログは再送していません。
curl -s "${ENDPOINT}openai/v1/responses" \
-H "Content-Type: application/json" \
-H "api-key: ${KEY}" \
-d '{
"model": "gpt-41-mini",
"input": "What VPC networking changes should I check? Give me the AWS CLI commands.",
"previous_response_id": "resp_087784ee8eba51a60069f0bed6d29c819585e6d3c2530c9844"
}'
Turn 1 のコンテキスト(ECR エンドポイントへの接続タイムアウト)を踏まえた VPC トラブルシューティング手順と AWS CLI コマンド(aws ec2 describe-route-tables、aws ec2 describe-nat-gateways、aws ec2 describe-security-groups、aws ec2 describe-vpc-endpoints 等)が返却されました。
Bedrock Mantle
同じシナリオを Bedrock でも試しました。
# Turn 1
curl -s --aws-sigv4 "aws:amz:us-east-1:bedrock-mantle" \
--user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
-H "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
-H "Content-Type: application/json" \
-X POST "https://bedrock-mantle.us-east-1.api.aws/v1/responses" \
-d '{
"model": "openai.gpt-oss-120b",
"instructions": "You are a DevOps engineer assistant. Be concise.",
"input": "Our ECS task keeps failing. Here is the error from CloudWatch:\n\nResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 3 time(s): RequestError: send request failed caused by: Post https://api.ecr.us-east-1.amazonaws.com/: dial tcp 10.0.1.42:443: i/o timeout"
}'
レスポンス(同じ jq フィルタで抽出、reasoning タイプは省略):
{
"id": "resp_pbknkjxqs4ekzxoujxftabh2msmflyzyb4yfge4rs3zg3gazjtjq",
"object": "response",
"status": "completed",
"output": [
{
"type": "message",
"content": [
{
"type": "output_text",
"text": "## TL;DR\n\nThe error means the task's execution role cannot reach the Amazon ECR public endpoint (or the VPC endpoint you've set up for it). In practice this is almost always a networking problem (security group, subnet routing, NAT/Internet gateway, VPC endpoint, DNS, or a mis-configured task execution role).\n\n..."
}
]
}
]
}
# Turn 2: previous_response_id 付き
curl -s --aws-sigv4 "aws:amz:us-east-1:bedrock-mantle" \
--user "${AWS_ACCESS_KEY_ID}:${AWS_SECRET_ACCESS_KEY}" \
-H "x-amz-security-token: ${AWS_SESSION_TOKEN}" \
-H "Content-Type: application/json" \
-X POST "https://bedrock-mantle.us-east-1.api.aws/v1/responses" \
-d '{
"model": "openai.gpt-oss-120b",
"input": "What VPC networking changes should I check? Give me the AWS CLI commands.",
"previous_response_id": "resp_pbknkjxqs4ekzxoujxftabh2msmflyzyb4yfge4rs3zg3gazjtjq"
}'
Bedrock でも、Turn 1 のエラーログを踏まえた VPC トラブルシューティング手順と AWS CLI コマンドが返却されました。
互換性の確認
両方のレスポンスを並べると、JSON の構造(id, object, status, output[])が同一フォーマットであり、output 配列内の message → content → output_text の階層も同じでした。Bedrock のレスポンスには reasoning タイプの出力も含まれますが、message タイプの構造は Azure と同一です。
モデルが異なる(gpt-4.1-mini vs gpt-oss-120b)ため、トークン消費やレスポンス速度の比較は行っていません。
ツール対応の比較
| ツール | Azure | Bedrock | 備考 |
|---|---|---|---|
function |
✅ | ✅ | |
mcp |
✅ (server_url) | ⚠️ (connector_id) | 接続方式が異なる※ |
web_search |
✅ | ❌ | |
code_interpreter |
✅ | ❌ | Azure はコード実行・結果返却 |
file_search |
✅ | ❌ |
※ MCP は両方で受理されますが、Azure は server_url で直接接続、Bedrock は connector_id による AWS 側のコネクタ経由接続を要求します。
function ツール — 両方動作
同じ関数定義で両方にリクエストしました。
# Azure
curl -s "${ENDPOINT}openai/v1/responses" \
-H "Content-Type: application/json" \
-H "api-key: ${KEY}" \
-d '{
"model": "gpt-41-mini",
"input": "What is the weather in Tokyo?",
"tools": [{"type": "function", "name": "get_weather", "description": "Get weather", "parameters": {"type": "object", "properties": {"city": {"type": "string"}}}}]
}'
Bedrock も同じペイロード(モデル名とエンドポイント、認証方式のみ異なる)でリクエストし、両方とも function_call を返却しました。output の構造も同一です。
code_interpreter ツール — Azure のみ
Azure ではサーバーサイドで Python コードを実行できます。
curl -s "${ENDPOINT}openai/v1/responses" \
-H "Content-Type: application/json" \
-H "api-key: ${KEY}" \
-d '{
"model": "gpt-41-mini",
"input": "Calculate the first 10 Fibonacci numbers using Python.",
"tools": [{"type": "code_interpreter", "container": {"type": "auto"}}]
}'
レスポンスの output に code_interpreter_call タイプが含まれ、実行されたコードと結果が返却されました。
{
"output": [
{"type": "message", "content": [{"type": "output_text", "text": "Sure! Here's a Python code snippet..."}]},
{"type": "code_interpreter_call", "code": "def fibonacci(n):\n fib = [0, 1]\n ..."},
{"type": "message", "content": [{"type": "output_text", "text": "The first 10 Fibonacci numbers are:\n\n0, 1, 1, 2, 3, 5, 8, 13, 21, 34"}]}
]
}
Bedrock の非対応ツール
Bedrock で web_search、code_interpreter、file_search を指定すると、すべて同じエラーが返りました。
Invalid 'tools': unknown variant `web_search`, expected `function` or `mcp`
各ツールのエラーメッセージ
web_search:
Failed to deserialize the JSON body into the target type: ?[0]: Invalid 'tools': unknown variant `web_search`, expected `function` or `mcp` at line 4 column 37
code_interpreter:
Failed to deserialize the JSON body into the target type: ?[0]: Invalid 'tools': unknown variant `code_interpreter`, expected `function` or `mcp` at line 4 column 74
file_search:
Failed to deserialize the JSON body into the target type: ?[0]: Invalid 'tools': unknown variant `file_search`, expected `function` or `mcp` at line 4 column 69
Bedrock Mantle がサポートするツールタイプは function と mcp の 2 つのみです。
まとめ
本記事では、Azure AI Foundry と Bedrock Mantle の Responses API を同じテストで比較しました。GPT-5 系モデルの Bedrock 提供に備えた素振りとして、現時点で分かったことを整理します。
- ✅ レスポンス構造は互換 —
id,object,status,output[]の JSON 構造が同一。既存のクライアントコードはエンドポイントとモデル名の変更だけで流用可能 - ✅
previous_response_idは両方で動作 — サーバー側での会話履歴保持が Azure でも Bedrock でも機能する - ⚠️ サーバーサイドツールは Azure のみ —
web_search、code_interpreter、file_searchは Bedrock 未対応。アプリケーション側でのツール層の抽象化が必要 - ⏳ 対応モデルの拡大待ち — Bedrock は gpt-oss の 2 モデルのみ。GPT-5 系が提供されれば、同一モデルでの比較が可能になる
これらのギャップ(サーバーサイドツールとプロプライエタリモデル対応)が、Stateful Runtime Environment で埋まることが期待されます。利用可能になり次第、同一モデルでの検証を改めて行う予定です。
参考リンク
- Codex CLI v0.124.0 の Amazon Bedrock 対応を試してみた(第1弾)
- Amazon Bedrock が OpenAI の Responses API をサポートするようになりました(たかくにさん)
- Bedrock Mantle ドキュメント - Generate responses using OpenAI APIs
- Use the Azure OpenAI Responses API
- The Responses API in Azure AI Foundry is now generally available
- Introducing the Stateful Runtime Environment for Agents in Amazon Bedrock
- OpenAI and Amazon announce strategic partnership






