01
parametersだけを取り出す
関数パラメーターのプロファイルには、parameters内のオブジェクトを入力します。nameやstrictを含む関数定義全体、APIリクエスト全体は対象外です。ラッパーを検出した場合は、どこを取り出すか診断を確認してください。
AI / LLM Dev Tools
構造化出力スキーマ検証
JSONスキーマ本体と対象を指定し、パス付きの診断で修正すべき箇所を確認します。関数はparametersの内容だけを入力します。
構造化出力スキーマ
JSONスキーマを入力してください。
入力と参照はこのブラウザー内で処理し、検証データの送信や外部参照の取得は行いません。
スキーマ本体を入力してください。関数の場合はparameters内のオブジェクトだけを貼り付けます。
ルール確認日：2026-09-15。 公式ルール
ローカルの事前検査です。APIの受理や特定モデルの対応を保証するものではありません。
JSONスキーマを入力してください。
型定義から生成したJSONが正しくても、モデル側の制約まで満たすとは限りません。構造化出力スキーマの事前検証では、スキーマの書き方の問題と提供元ごとの条件を分けて確認できます。どのオブジェクトを直すべきか、まず診断のパスを見てください。
JSONスキーマ検証を通った任意項目が、OpenAI厳格モードでは問題になることがあります。関数呼び出しのパラメーターを移植するときも同じです。Gemini構造化出力と比較しながら、変更が必要な理由を元の定義を残したまま整理できます。
構造化出力スキーマを先に確認する理由
構文・構造・対象ルールを混同しない
任意項目や追加キーを許す定義は、一般的なJSON Schemaでは有効です。構造化出力スキーマをOpenAI strictで使うには別の条件があります。検証結果にはメタスキーマの判定と対象ルールの診断が並ぶため、文法だけ直して同じエラーを繰り返す状況を避けられます。
対象を変えても入力はそのまま
OpenAIからGeminiへ切り替えると診断を再計算します。requiredの追加や未確認キーワードの削除は自動で行いません。提案を読む段階では元の契約が残るので、受信側のコードが変更後のデータを扱えるか判断してから編集できます。
任意項目と対象の違いを確かめる
02
二つの例で挙動を見る
通常の例には必須かつnullを許す値が含まれます。問題のある例はOpenAI用の条件が不足しており、Geminiへ切り替えると診断が変わります。例の読み込みは置き換え内容をプレビューしてから適用するため、入力が突然消えることはありません。
03
編集後のレポートを使う
自動チェックは入力が止まって350ms後に動きます。オフにすると検査ボタンとCtrl/Cmd + Enterが使えます。入力や対象を変更した直後は古いレポートを保存できません。取り消しは入力と対象、直前の結果を一緒に戻します。
対応範囲を確認しながら設計する
スキーマ自体の構造を検証
同梱の2020-12メタスキーマで、キーワードの値や構造を検査します。重複キー、JavaScriptで丸められる数値は拒否します。コメント、末尾カンマ、Markdownの囲みは自動修復せず、構文エラーとして位置を示します。
入れ子の定義までパスを表示
JSON Pointerで問題のある箇所を示し、プロパティ名のスラッシュやチルダも扱います。同一文書内の参照先が存在するか確認します。allOfという名前の業務項目と、スキーマのallOfキーワードは区別して走査します。
未確認項目を警告に残す
OpenAIの二つのプロファイルは非ファインチューニングのstrict向けです。Geminiは公開されたJSON Schemaの対応範囲を使います。確認できていないキーワードやformatは要確認と表示し、暗黙に対応扱いにしません。
判断材料をJSONで共有
対象、ルール確認日、構造の判定、件数、診断コードをレポートに保存できます。長い診断は最初に50件を表示し、必要に応じて続きを開きます。コピーやダウンロードには表示済みの分だけでなく、レポート全体が含まれます。
この検査で確定しないこと
- 実際のAPI接続は別に確認
- ルール確認日は2026-09-15です。アカウント権限、エンドポイント、SDKによる正規化、拒否応答や特定モデルの動作は判定しません。微調整済みOpenAI、Anthropic、Geminiの関数呼び出し、代理サービス向けのプロファイルはありません。
- 草案と参照の範囲を固定
- メタ構造は2020-12で検査します。古い草案の明示は対象外として扱い、勝手に移行しません。外部参照や名前付きアンカーは解決しません。再帰定義は有限に確認しますが、あらゆる展開結果の遠隔側の複雑度までは保証しません。
- 大きすぎる入力は停止
- 上限は500000文字、50000解析ノード、JSONの入れ子40階層です。Workerは5秒で停止し、診断が1000件を超える場合も成功扱いにしません。これらはブラウザーの処理予算で、OpenAIのプロパティ数や列挙値の制限とは別に扱います。
- 契約を自動で書き換えない
- requiredの追加、nullの許可、追加キーの禁止には意味の変化があります。この検査は提案を出すだけです。nullを許してもキーの省略が許されるわけではありません。enumがある項目では、列挙にもnullを含める必要があるか見直してください。
- 実際の応答値は対象外
- 検査するのはモデルに渡す定義です。応答インスタンスの検証、サンプルからの推定、回答生成、壊れたJSONの修復はしません。形式が正しい値でも業務上の誤りはあり得るため、受信後のバリデーションと業務ルールを残してください。
構造化出力スキーマのよくある疑問
OpenAIの厳格モードで全項目がrequiredになるのはなぜですか？
厳格モードでは出力オブジェクトの形を固定するため、宣言したキーを必須にします。値が不明な場合は、契約に合うならnullを許してください。enumを指定した項目では列挙側も確認が必要です。任意項目の省略と、必須項目のnullは異なる条件です。
OpenAI、Anthropic、Geminiの出力定義は同じですか？
共通のJSON Schemaを土台にしていても、要求される条件やリクエストの包み方は異なります。本ページはOpenAI strictとGemini出力の確認済み範囲を比較します。Anthropicの認証は行わず、他のプロファイルで通った結果をそのまま転用できるとは判断しません。
JSONモードだけで信頼できる出力になりますか？
JSONとして読めることと、必要な項目や値が正しいことは別です。JSONモードの構文上の制約だけでは、期待する契約への一致を確認できません。スキーマに対する検証に加え、受け取った値が業務上妥当かをアプリケーションで確認してください。
APIへ送信する前にスキーマを検証できますか？
はい。構文とメタ構造を確認し、その後に対象のルールを事前検査できます。ただし、未確認ルールの警告も読む必要があります。最後は使用予定のエンドポイントとモデルで実際にテストし、ローカル判定をAPI受理の証明としないでください。
サンプルのJSONを貼るだけでも使えますか？
サンプルでは、省略してよい項目や許可する追加キー、値の範囲まで定義できません。typeやpropertiesなどを持つスキーマ本体が必要です。付属の例から開始しても構いませんが、実際に必要な契約に合わせて各条件を見直してください。
未対応のケースがありますか？