AI Structured Output とは？GPT・Gemini・Claude が構造化 JSON を支える理由

先に結論：Structured Output は「JSON を返してください」というプロンプトではありません。API がデコード時に JSON Schema で不正な token を遮断し、最終返答をプログラムがそのままパースできるようにする仕組みです。GPT、Gemini、Claude がこれを第一級の機能にしたのは、スライド映えするからではなく、Agent、抽出、フォーム入力がモデルをパイプラインに接続しなければならないからです。散文は JSON.parse を通りません。下流の Schema はさらに通りません。

本稿は2026年9月8日時点の内容です。三社ともいま、ユーザーまたは次のサービスへ渡す最終 JSON を制約できます：OpenAI は response_format.json_schema（strict）、Gemini は responseMimeType + responseJsonSchema、Claude は GA 済みの output_config.format（旧 beta の output_format は移行期間中も使えます）。フィールドの書き方とサブセットの差は、8月にすでに整理しました。本稿が答えるのは二つだけです：それは何か、そして三社がなぜ出さざるを得なかったか。手順は《Prompt から Structured Output へ》を見てください。OpenAI と Gemini の対照は《Structured Output API 比較》です。

Structured Output とは何か

Structured Output とは：先に JSON Schema を渡し、モデルの最終返答がその Schema に合う JSON でなければならない、ということです。保証は各 token を生成するときに起きます。「JSON らしく見せよう」としたあとではありません。名前は違います：OpenAI は Structured Outputs、Google は Structured Output、Anthropic は structured outputs / JSON outputs と書きます。余分な s はブランディングです。仕事は同じです。

コンパイラと型検査だと思ってください。プロンプトはコメントです——モデルは聞くかもしれません。Schema は型システムです——誤ったフィールド名、欠けた required、数値であるべき場所の文字列は、そもそも出てきません。プログラムが受け取るのはオブジェクトであり、```json フェンスに包まれた散文ではありません。

三社が読める Schema は、だいたい扁平です：ルートは object、properties / required を明示し、additionalProperties: false。OpenAI の strict では、「任意」は required から外すのではなく、nullable にすることが多いです。サブセットは同一ではありません。先に交差を取ってください。

{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "task": { "type": "string", "enum": ["extract", "classify", "summarize"] },
    "ok": { "type": "boolean" },
    "fields": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "orderId": { "type": "string" },
        "total": { "type": "number" },
        "note": { "type": ["string", "null"] }
      },
      "required": ["orderId", "total", "note"]
    }
  },
  "required": ["task", "ok", "fields"]
}

JSON Mode でも、Tool Calling でもない

三つの名前が一つに潰されがちです。層が違います：

JSON Mode が保証するのは、括弧が対応し、JSON.parse が通ることだけです。モデルは、あなたが orderId を求めても order_id を発明できますし、金額を文字列で出せます。本番では、「パースできる」は「INSERT できる」ではありません。

Tool Calling / Function Calling が制約するのは、ツールへ伸ばす手であり、ユーザーへの最後の一文ではありません。在庫照会、ファイル書き込み、MCP の tools/call はツール側 Schema です。メール抽出、チケット分類、下流 API 向け JSON の出力は Structured Output です。本格的な Agent はしばしば両方を開きます——引数は tools、最終返答は出力 Schema。層の分け方は《MCP とは》と《Agent の JSON データフロー》を見てください。

三社がそろって対応し始めた理由

2023年なら、プロンプトに賭けることもまだできました。2026年の Agent はモデルをループに埋め込みます：出力はデータベースへ、次のツールへ、別ベンダーのモデルへ入ります。三社がプレスを合わせて出したわけではありません。同じ製品圧力と、同じ契約——JSON Schema——にぶつかったのです。

1. 下流の消費者は読者ではなく、プログラムです。チャットは散文でよい。パイプラインはオブジェクトが要ります。カンマが一つ欠け、フィールド名が一つ変われば、夜間の再試行キューが埋まります。ベンダーは、顧客一人ひとりに修復ロジックを書かせるより、デコーダで不正な経路を切りたいのです。
2. Agent が「形が安定していること」を必須にしました。多段ループでは、前ターンの JSON が今ターンの入力です。一度ドリフトすれば、その先は全部違います。Tool Calling が答えるのは「どう手を伸ばすか」。Structured Output が答えるのは「結論をどう返すか」。どちらも Schema が要ります——《JSON Schema は Agent の Contract になるか》を見てください。
3. プロンプトでは足りないことが証明されました。「JSON のみ、markdown なし」はベンチではよく見えます。しかし長いコンテキスト、ツールの再注入、言語の混在では、フィールドを落とし、フェンスを足し、enum を類義語に言い換えます。制約デコードは「ときどき」を API 400 か、再試行できる Schema エラーに変えます。
4. JSON Schema はすでに最小公約数でした。OpenAPI、MCP の inputSchema、Pydantic / Zod のエクスポート——どれもそれです。モデル側に別の独自 IDL を置けば、Host は二重に翻訳しなければなりません。最終返答を同じ Schema に繋ぐことこそ、ベンダー入れ替えを安くします。
5. 競争は「チャットできるか」ではなく、「本番に出せるか」になりました。一社がハード制約を出すと、ゲートウェイ、Agent フレームワーク、調達リストは必須項目に書きます。残る二社は追随するか、同じ編成に差し込めなくなります。2026年9月、Structured Output のないフラッグシップ API は、行を INSERT する顧客には売りにくいです。

だから日付が固まります：OpenAI は 2024年8月に Structured Outputs を GA にしました。Gemini は MIME + Schema を生成設定に取り込みました。Claude は 2025年末まで beta ヘッダのままで、いまは output_config.format を安定フィールドとして出しています。名前は一度も揃いませんでした。圧力は揃いました。

GPT、Gemini、Claude それぞれの開き方

概念は揃えてください。フィールドをベンダー横断で貼り付けないでください。下表は 2026年9月8日にドキュメントへ書ける入口であり、完全な SDK チュートリアルではありません。

ラッパーは違います。Schema 本体は同じファイルであるべきです。モデルを替えるのは封筒であり、orderId と required ではありません。Claude の例（仕様フィールド。業務 Schema は差し替えてください）：

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 1024,
  "messages": [
    {"role": "user", "content": "Extract orderId and total from the order text"}
  ],
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "properties": {
          "orderId": { "type": "string" },
          "total": { "type": "number" }
        },
        "required": ["orderId", "total"]
      }
    }
  }
}

OpenAI は同じ schema を response_format.json_schema に置き、strict を入れます。Gemini は responseJsonSchema に置き、JSON MIME を宣言します。完全な Python 対照は、いまも《OpenAI vs Gemini》にあります。製品面（ChatGPT / claude.ai / Gemini ウェブ）が同じハード制約を出すとは限りません。SLA は、実際に呼ぶその API に対して書いてください。

制約デコードが実際に止めるもの

Structured Output がないとき、モデルは語彙全体からサンプリングし、プロンプトで JSON らしく見えることを期待します。Structured Output があるとき、デコーダは Schema から合法な接頭辞を維持します：次の token はまだ合法なものだけ——"、orderId、true、または }。不正な経路の確率はゼロになります。

止めるのは形です：末尾カンマ、markdown フェンス、必須の欠落、型のドリフト、additionalProperties が false のときの余分なキー。止めないのは捏造です：total は number でも、値は作り出せます。合法な enum 値でも、間違ったものを選べます。本番では同じ Schema を検証器に通し、失敗したら再試行、劣化、または人手へ回します。制約デコードが減らすのはパース事故であり、幻覚ではありません。

窓が大きくても同じです。1M token は見える材料を増やすだけで、出力の形は縛りません。ダンプを詰め込んでも、Schema は要ります——《1M Token コンテキストウィンドウ》を見てください。

いまどう使うか

1. 先に Schema を書き、それからモデルを選んでください。フィールド名、必須、enum は製品契約です。GPT / Gemini / Claude は入れ替え可能なバックエンドです。契約はリポジトリに置き、プロンプトに書かないでください。
2. 抽出、分類、フォーム入力は Structured Output。副作用は Tool Calling。Structured Output が在庫 API をすでに叩いたかのように装わないでください。プロセスをまたいでツールを再利用するなら、そこで MCP を足します。
3. ベンダー横断では Schema の交差を取る：扁平な object、additionalProperties: false、浅い $ref、ルートの anyOf は使わない。OpenAI の strict は「任意」を nullable にします。三社それぞれがドリフトするフィールド表を持たないでください。
4. API が通っても、それが最後の検査ではありません。Schema と 2〜3 組の正 / 反フィクスチャを JSON として保存し、本サイトで検証と Diff をしてください。何もアップロードされません。制約デコードのあとの第二関門です。
5. 失敗は構造化して戻す：パースや二次検証が失敗したら、オブジェクトで返す（どのフィールド、期待型）。生のスタックトレースを次のターンに流し込まないでください。

FAQ

まとめ

Structured Output は 2026年フラッグシップ API の標準ソケットです：最終返答は JSON Schema に対してデコードされ、プログラムはプロンプトの括弧に賭けるのをやめます。GPT、Gemini、Claude がみな出したのは、Agent と抽出が「形が安定していること」を受け入れ条件に書き、JSON Schema が三社ともすでに話していた契約だったからです。JSON Mode ではありません。Tool Calling や MCP の代わりにもなりません。

モデルを替えるなら、ラッパーのフィールドだけを替えてください。フィールド名と required はリポジトリに置き、本番前に同じ Schema でサンプルをローカル検証してください。各社 API の設定と、ツール層との分担は、本サイトですでに書いています。本稿は「何か、なぜか」だけをはっきりさせます。