構造化出力ツール

LLM 構造化出力 JSON Schema バリデーター＆自動修正ツール

Q: それでもLLMのレスポンスを Zod や Pydantic で検証すべきですか？

はい。 制約付きデコーディングはJSONの型と必須キーの一致を保証し、正の金額・有効な日付・認可済みIDなどのビジネス不変条件はアプリケーション側のバリデーターが担保します。

関数呼び出しや response_format 用の JSON Schema を貼り付けるだけで、OpenAI・Claude・Gemini で HTTP 400 拒否を引き起こす箇所を特定し、正規化済みの strict スキーマをワンクリックでコピーできます。

実行方式ログイン不要・100%ブラウザ完結スキーマルール確認日：2026年11月11日

元の JSON Schema を入力

自動正規化された strict JSON Schema

request.example

{
  "type": "object",
  "properties": {
    "invoiceId": {
      "type": "string"
    },
    "currency": {
      "type": [
        "string",
        "null"
      ],
      "enum": [
        "USD",
        "EUR",
        "GBP"
      ]
    },
    "totalAmount": {
      "type": "number"
    },
    "customer": {
      "type": [
        "object",
        "null"
      ],
      "properties": {
        "name": {
          "type": "string"
        },
        "taxId": {
          "type": [
            "string",
            "null"
          ]
        }
      },
      "required": [
        "name",
        "taxId"
      ],
      "additionalProperties": false
    }
  },
  "required": [
    "invoiceId",
    "currency",
    "totalAmount",
    "customer"
  ],
  "additionalProperties": false
}

互換性診断の詳細

$.additionalPropertiesstrict モードでは、すべてのオブジェクトスキーマに "additionalProperties": false の指定が必要です。
$.required (currency, customer)OpenAI の strict モードでは全プロパティを required に列挙する必要があります。任意プロパティは null 許容ユニオンへ自動変換されました。
$.properties.invoiceId.pattern厳格な構造化出力では値制約キーワードが拒否されることが多いため、条件は description に移し、アプリケーション側で Zod や Pydantic により検証してください。
$.properties.totalAmount.minimum厳格な構造化出力では値制約キーワードが拒否されることが多いため、条件は description に移し、アプリケーション側で Zod や Pydantic により検証してください。
$.properties.customer.additionalPropertiesstrict モードでは、すべてのオブジェクトスキーマに "additionalProperties": false の指定が必要です。
$.properties.customer.required (taxId)OpenAI の strict モードでは全プロパティを required に列挙する必要があります。任意プロパティは null 許容ユニオンへ自動変換されました。

技術リファレンスと本番導入チェック

標準の Draft-07 JSON Schema でも LLM API で HTTP 400 エラーになる理由

制約付きデコーディングエンジンは生成開始前に、JSON Schema を文脈自由文法や有限オートマトンのトークンマスクへコンパイルします。文法コンパイルを高速かつ有界に保つため、OpenAI・Anthropic・Google はいずれも Ajv、Zod、Pydantic がデフォルト出力するものより厳格な JSON Schema サブセットを要求します。

例えば OpenAI の strict: true モードでは、additionalProperties: false の省略や required 配列に含まれないプロパティがあるオブジェクトは拒否されるため、任意項目も required に含めた上で ["string", "null"] のような null 許容ユニオンにする必要があります。逆に、Google Gemini の generationConfig.responseSchema は additionalProperties キーワード自体を一切受け付けません。

スキーマ制約ルール	OpenAI Strict (strict: true)	Anthropic 厳格ツール / JSON	Gemini responseSchema
ルート type が "object"	必須	必須	推奨
全オブジェクトに "additionalProperties": false	必須（省略時は 400）	必須（省略時は 400）	使用不可（指定時は 400）
全プロパティを "required" に列挙	必須（任意項目は [type, "null"]）	任意キーの省略可	任意キーの省略可
正規表現 pattern / minLength / format	strict 文法では非対応	一部制限あり（description＋アプリ検証推奨）	大半の文字列 format は非対応

信頼性の高い構造化抽出・ツールスキーマのための本番チェックリスト

文法エラーの自動修正で HTTP 400 は回避できますが、抽出精度を高めるにはスキーマ内の明確な意味定義も不可欠です。フィールド名は自明にし、深い再帰ネストを避け、モデルの拒否応答（refusal）を常に明示的に処理してください。

正規表現パターン、文字数制限、数値範囲はフィールドの description に記述し、パース後に Zod や Pydantic で決定論的に検証してください。
JSON.parse を呼ぶ前に finish_reason（または stop_reason）で max_tokens による途中切れがないか確認してください。strict モードでも途中切れのJSONはパースに失敗します。
パース済みの構造化出力を読み取る前に、安全性やポリシーによる明示的な拒否フィールドを確認してください。

よくある質問

OpenAI の strict モードで任意フィールドはどう表現しますか？

オブジェクトの required 配列にそのフィールド名を含めたまま、type を ["string", "null"] のような null 許容ユニオンに変更します。上の自動修正ツールはこの変換を自動で行います。

OpenAI で動作するスキーマが Gemini で拒否されるのはなぜですか？

OpenAI の strict モードは全オブジェクトに additionalProperties: false を必須としますが、OpenAPI由来の Gemini responseSchema パーサーは additionalProperties を含む未知のキーワードを拒否します。上の対象ドロップダウンを Google Gemini に切り替えると、非互換のキーを一括除去できます。

それでもLLMのレスポンスを Zod や Pydantic で検証すべきですか？

はい。制約付きデコーディングはJSONの型と必須キーの一致を保証し、正の金額・有効な日付・認可済みIDなどのビジネス不変条件はアプリケーション側のバリデーターが担保します。

実際のモデルルートで strict スキーマを検証する

上で正規化した JSON Schema をコピーし、LLMFly AI で非ストリーミングリクエストを送って検証してください。

APIキーを取得