機能概要
構造化出力(Structured Outputs)を使用すると、モデルの応答が定義した JSON Schema に厳密に従うようになり、正規表現や後処理なしでプログラムから直接パースできる戻り値が保証されます。 プロンプトでモデルに「JSONで返してください」と依頼する方法とは異なり、構造化出力は制約付きデコーディング(Constrained Decoding)に基づいています。上流プロバイダが JSON Schema を文法規則にコンパイルし、推論過程でトークンごとに生成を制約するため、モデルが Schema に違反するコンテンツを出力することは不可能です。 典型的なユースケース:- 非構造化テキストからのエンティティ・フィールド抽出
- 分類 / ラベリング / 感情分析
- マルチステップ推論における中間結果の標準化された受け渡し
- Agent ツール呼び出しパラメータの厳密な型制約
各プロトコルのパラメータ対照表
3つのプロトコルでパラメータ名は異なりますが、基本的なメカニズムは同じです:モデルの出力が提供された JSON Schema に厳密に一致します。
| プロトコル | パラメータ | 対応モデル |
|---|---|---|
OpenAI Chat /v1/chat/completions | response_format.type: "json_schema" | Claude 4.5+、GPT-4o / GPT-5 シリーズ、Gemini シリーズ |
Anthropic Messages /v1/messages | output_config.format.type: "json_schema" | Claude 4.5+(直接接続 / Vertex);Bedrock は 4.5~4.6 のみ |
OpenAI Responses /v1/responses | text.format.type: "json_schema" | 上流モデルの対応状況に準ずる |
AWS Bedrock の制限事項
AWS Bedrock 上の Claude 4.7 以降のバージョンは Mantle 推論パスを使用しており、このパスは現在output_config.format をサポートしていません。ゲートウェイはこれらのモデルに対して自動的に format フィールドを除去し、レスポンスヘッダーにデグレードを記録します(下記のデグレードメカニズムを参照)。リクエストはこれによりエラーになることはありません。
クイックスタート
OpenAI プロトコル(推奨)
構造化出力に対応するすべてのモデルに適用でき、プロバイダ横断で共通して使用できます。他のモデルの使用(GLM-5.2 の例)
同じ OpenAI プロトコルのパラメータが構造化出力に対応するすべてのモデルに適用でき、model を切り替えるだけで使用できます。
Python
Claude ネイティブプロトコル
Anthropic SDK を使用して直接呼び出します。パラメータはoutput_config.format です。
Schema の記述ポイント
必須フィールド
すべてのobject 型には additionalProperties: false を明示的に宣言する必要があります。これがない場合、一部の上流プロバイダがリクエストを拒否します。
ネストされたオブジェクト
ネストされたobject にも同様に additionalProperties: false が必要です:
クロスプロトコル間の Schema 差異
| 特性 | OpenAI プロトコル | Anthropic プロトコル |
|---|---|---|
name フィールド | 必須 | 非対応(ゲートウェイがクロスプロトコル呼び出し時に自動処理) |
strict フィールド | 任意、true 推奨 | 非対応 |
数値制約 (minimum, maximum 等) | 対応 | 非対応(ゲートウェイが自動クリーニング、リクエストに影響なし) |
文字列制約 (minLength, maxLength) | 対応 | 非対応(ゲートウェイが自動クリーニング) |
自動デグレードメカニズム
ゲートウェイはデフォルトですべてのリクエストに対して構造化出力の自動デグレード保護を有効にしています。モデルまたはプラットフォームがサポートしていない場合、ゲートウェイはエラーを返さず、自動的に Schema 制約を除去し、レスポンスヘッダーにデグレードの理由を記録します。リクエストは引き続き正常なモデル応答を受け取りますが、出力は Schema による強制制約を受けません。 これにより、クライアント側で構造化出力を統一的に有効化でき、モデルごとの互換性判断を行う必要がなくなります:- マルチモデル切り替えが安心:同一のコードで Claude、GPT、Gemini、GLM 間でモデルを切り替える際、対象モデルが構造化出力をサポートしていなくてもリクエストはエラーになりません
- フォールバックルーティングが透過的:メインチャネルが利用不可でバックアップチャネルにフォールバックルーティングされた場合、バックアップチャネルのモデルバージョンが構造化出力をサポートしていなくても、リクエストは正常に完了します
- クライアントロジックの簡素化:「どのモデルが構造化出力をサポートしているか」のリストを管理する必要がなく、ゲートウェイが自動処理済み。クライアントはレスポンスヘッダーを確認して追加のパース処理が必要かどうかを判断するだけです
レスポンスヘッダー
| reason | 意味 |
|---|---|
model_unsupported | 当該モデル(または当該モデルの現在のプラットフォーム上)が構造化出力をサポートしていません |
json_object_unsupported_on_anthropic | json_object モードは Anthropic フォーマットに変換できません |
json_schema_missing_schema | json_schema タイプが指定されましたが schema フィールドがありません |
schema_keywords_stripped | Schema 内の一部の制約キーワードがクリーニングされました(例:minimum、maxLength) |
検出の例
Python
json_object モードとの違い
json_schema(構造化出力) | json_object | |
|---|---|---|
| 出力保証 | 指定された Schema に厳密に一致 | 有効な JSON であることのみ保証 |
| フィールド制御 | フィールド名、型、必須かどうかがすべて制約される | 制約なし |
| 対応プロトコル | OpenAI / Anthropic / Responses | OpenAI 互換プロトコルのみ |
| Claude 対応 | output_config.format 経由 | 非対応 |
よくある質問
どのモデルが Structured Outputs に対応していますか?
どのモデルが Structured Outputs に対応していますか?
Claude シリーズ(Anthropic API の
output_config.format 経由):- Opus / Sonnet / Haiku 4.5 以降
- Fable / Mythos 5 以降
- Bedrock プラットフォームは 4.5~4.6 のみ対応;Vertex AI は直接接続と同一
response_format 経由):- GPT-4o 以降、GPT-5 シリーズ
responseSchema 経由):- Gemini 2.5 以降
Bedrock 上の一部の Claude モデルが構造化出力に対応していないのはなぜですか?
Bedrock 上の一部の Claude モデルが構造化出力に対応していないのはなぜですか?
AWS Bedrock 上の Claude 4.7 以降は新しい Mantle 推論パスを使用しており、このパスは現在
output_config.format パラメータを受け付けません。ゲートウェイが自動的に処理します:format を除去して正常にレスポンスを返し、同時にデグレードヘッダー X-Structured-Output-Degraded: model_unsupported を記録します。Claude 4.5~4.6 は Bedrock 上で完全にサポートされています。クロスプロトコル呼び出し時に JSON Schema は変更されますか?
クロスプロトコル呼び出し時に JSON Schema は変更されますか?
はい。OpenAI プロトコル経由で Claude モデルを呼び出す場合、ゲートウェイが自動的に以下を実行します:
response_formatをoutput_config.formatに変換- Anthropic が非対応の Schema キーワード(
minimum、maxLength等)を除去 - キーワードがクリーニングされた場合、レスポンスヘッダーに
schema_keywords_strippedを記録
Structured Outputs と Extended Thinking は同時に使用できますか?
Structured Outputs と Extended Thinking は同時に使用できますか?
はい。
output_config 内の format(構造化出力)と reasoning 内の effort(思考強度)は独立したパラメータであり、同時に設定できます:OpenRouter などの集約プラットフォームと比較して、デグレードメカニズムにはどのような違いがありますか?
OpenRouter などの集約プラットフォームと比較して、デグレードメカニズムにはどのような違いがありますか?
多くの API 集約プラットフォームは、モデルが構造化出力をサポートしていない場合にエラーを直接返します。AIHubMix はグレースフルデグレード戦略を採用しています:互換性のないパラメータを自動的に除去し、モデルのレスポンスを正常に返した上で、
X-Structured-Output-Degraded レスポンスヘッダーでクライアントにデグレードの理由を通知します。これにより、アプリケーションが中断されることはありません。