まとめ
Azure API Management（APIM）のAI Gateway機能が、OpenAIのResponses APIをどこまでカバーしているかを棚卸しした。
結論を先に言うと、対応は「リクエスト/レスポンスが通過する瞬間に処理できる機能」に偏っている。
トークン計測・診断ログ・content safetyの対応は厚い一方、Responses APIの本質であるステートフル性、つまりサーバー側に保存される会話状態・previous_response_id の連鎖・30日保持に対するゲートウェイ機能はゼロだ。
この偏りは個別機能の遅れではなく構造的なものだ。
従来のAPIゲートウェイは通過時点の観測・制御を前提に設計されており、状態にまたがる機能はその前提の外にある。
APIMでの検証を始める人の地図として、バックエンド（Foundry / Azure OpenAI）側とAPIM側それぞれの対応状況をまとめる。
Foundry / Azure OpenAI側：第一級サポート
v1 APIへの移行が実害の出るレベルで進行中
中心は2025年8月に始まったv1 API（/openai/v1/responses）で、日付付きapi-versionは廃止の方向にある。
Microsoft自身が新規プロジェクトの推奨インターフェースと位置づけ、Foundry Agent ServiceもResponses APIの上に構築されている。
移行は建前ではなく、コーディングエージェントのRoo CodeがResponses形式の必須化で動かなくなった事例が出るレベルで進んでいる。
ツールはMCP（リモートサーバー）、CUA、function calling、background mode、file search、code interpreterに対応する。
Deep research（o3-deep-research）もResponses経由だ。
プロジェクトエンドポイント経由なら、memoryやSharePoint連携などのFoundry専用ツールも乗る。
契約・実装上の注意点
- Web検索は
web_search_previewのみ対応で、web_searchタイプは未対応。かつGrounding with Bing経由の検索にはMicrosoftのDPAが適用されないという契約上の重要事項がある - Content filterの結果が入る
content_filters配列はOpenAIベーススキーマに無いFoundry拡張のため、SDKに型付きプロパティが無く、raw/extraフィールドとして読む必要がある。入力ブロック時はHTTP 400とcontent_filterエラーコードが返る。ゲートウェイでレスポンスをパースする場合は考慮が要る
制約
- 保存の保持期間は30日固定で延長不可。Zero Data Retention構成も不可（Abuse Monitoringを無効化しても残る）
- 対応リージョン・モデルが限定される
previous_response_idでモデルをまたぐ連鎖はできない- カスタムヘッダーは10個までで、超過すると431が返る。さらに将来はヘッダーパススルー自体の廃止が予告されており、ヘッダーでのユーザーID伝搬に依存した設計は地雷になる
APIM側：ポリシー別マトリクス
| 機能 | 対応 | 備考 |
|---|---|---|
| ガバナンス宣言 | ○ | chat completions / responses / real-time APIを対象と明記 |
llm-emit-token-metric | ○（厚い） | cached/reasoning/thinkingトークンまで、Responses形式・Anthropic Messages形式横断で記録 |
llm-token-limit | △ | ストリーミング時はprompt/completionとも推定値。reasoning等は制限計算の対象外 |
| 診断ログ | ○ | ストリーミング対応、CorrelationIdでチャンクを結合。ストリーム切断時はトークン量が欠落する可能性 |
llm-content-safety | ○ | MCP/A2Aにも適用可。ストリーミングをスライディングウィンドウでバッファして検査 |
| セマンティックキャッシュ | ×（推定） | chat completion / completion APIのみ明記で、responsesへの言及なし。実機確認が必要 |
| response id所有権 | × | ビルトイン無し。DIYのみ |
| Unified Model API（preview） | 部分 | フォーマット変換込みの単一エンドポイント |
response id所有権の欠如が何を意味するかは、response idは秘密情報として別記事にまとめた。
ステートレスな部分だけが進む理由
対応が進む機能と空白の機能を分けるもの
トークン計測・診断ログ・content safetyに共通するのは、リクエスト/レスポンスが流れる瞬間に処理が完結することだ。
ゲートウェイが従来から得意としてきた「通過時点の観測・制御」の延長にあるため、対応が進む。
一方、Responses APIの本質であるステートフル性に関わる機能は空白のままだ。
response idが指すサーバー側の状態、previous_response_id の連鎖、30日の保持期間。
これらを扱うAPIMのビルトイン機能はゼロで、認可の穴もこの構造的偏りの一症状にすぎない。
ステートフルAPIはゲートウェイの前提を3方向から壊す
従来のAPIゲートウェイは「リクエスト/レスポンスが通過する瞬間にすべてを観測・制御できる」という前提で設計されている。
Responses APIはサーバー側に状態を持ち込むことで、この前提を3方向から壊した。
- 認可：response idがcapability token化し、リソース単位の認可では守れない
- ルーティング：encrypted content（reasoning項目）がデプロイにバウンドされ、負荷分散の前提である「デプロイの交換可能性」が消える。LiteLLMでは別デプロイへのルーティングによる復号失敗が実際にインシデント化し、同一デプロイに固定する複数のaffinity機構が実装された
- 監査：会話状態がゲートウェイの外（バックエンドの30日ストア）に存在し、通過時点のログだけでは追跡が完結しない
エコシステムの対応は「通過時点で処理できるもの」から進み、「状態にまたがるもの」は空白のまま残っている。
各プレイヤーが、自分に観測可能な範囲だけを固めている構図だ。
この空白を埋めるには、ゲートウェイとバックエンドの間に状態を扱うプロキシ層を置くか、store: false を強制して状態機能そのものを諦めるかの二択になる。
残る検証事項
このマトリクスには推定が含まれる。
実機で確認すべき事項を挙げておく。
store: false指定時にprevious_response_idが完全に無効化されるかllm-token-limitのストリーミング時トークン推定の精度（コスト按分に使えるレベルか）- セマンティックキャッシュのresponses非対応は「記載が無いことからの推定」であり、実打での確認が必要
llm-content-safetyのスライディングウィンドウ検査の挙動。「ゲートウェイはSSEボディを読めない」という通説を部分的に覆すため、どこまで任せられるかの見極め