🐼

Structured Outputs×JSON Schemaの実務 ―OpenAI / Claude / Geminiで“壊れない”型を通す

に公開
JSON Schema
llm
zennfes2025ai
tech

はじめに――フォーマットは合っているのに、後段で落ちる

抽出や連携の現場でよくあるのは、「見た目はJSONだけど、下流の検証で落ちる」問題。キーが足りない、型がズレる、入れ子が深くなると破綻――このあたりでつまずきがちです。
今年はスキーマ準拠を強制する仕組みが主要モデルで出揃いました。ここでは、OpenAI／Claude／Geminiの“型を守らせる”実務ポイントだけ、手短にまとめます。

いま使える“型の強制”の選択肢

  • OpenAI：APIにStructured Outputsが入り、JSON Schemaに厳密一致させられます（strict指定）。従来のJSONモードは「JSONにはするが任意スキーマ保証はしない」のが違い。(OpenAI)
  • Claude：Tool Useを“出力整形だけ”に使う手が公式で案内されています。ツールを1個だけ定義し、tool_choiceで強制するのがコツ。(Claude Docs)
  • Gemini：Function Calling＋Structured Output（2.5系）で、OpenAPI/JSON Schemaサブセットを使って型宣言→出力制約が可能。サポート範囲の注意点（再帰・$refの扱いなど）も明記。(Google AI for Developers)

メモ：Azure経由のStructured OutputsはOpenAI本家と同等のサブセットに従います（制限事項あり）。(Microsoft Learn)

現場で効いた“設計の順番”

  1. 先にスキーマを書く：出力の最小必須から決める（任意項目は後ろに寄せる）。
  2. 入れ子を浅く保つ：3層を超えた複雑スキーマは崩れやすいので、分割応答か後段マージで回避。評価系の研究でも5層以上は難度が跳ねるとされます。(arXiv)
  3. 生成と実行を分ける：API呼び出しや副作用は関数呼び出しで分離し、出力は純データに。Gemini/Claudeの関数・ツール設計の基本は公式ベストプラクティスどおり。(Google Cloud)
  4. “回答時の権限”を通す：参照できても出力して良いかは別。回答組立の段階でもポリシーを当てると事故が減ります。(OpenAI 開発者)

ありがちな落とし穴を、最小コストで避ける

  • JSONなのに受け側で死ぬ → 原因：スキーマ非準拠。対策：OpenAIはStructured Outputsのstrictを使用／Claudeは単一ツール＋強制呼び出し／GeminiはStructured Output対応モデルを選択。(OpenAI)
  • 入れ子が深くて崩れる → 対策：応答を段階分割（親→子）し、後段で検証しながら統合。深いネストは難度上昇の報告あり。(arXiv)
  • プロバイダ間で挙動が違う → 対策：同じ“構文”でも実装差がある前提で比較テストを。実務ブログや比較記事でも差異に注意の指摘。(Medium)
  • コミュニティでの揺れ（バグ/仕様差） → 対策：既知事象を踏まえパーサ側の冗長トリムを用意しておくと安全。(OpenAI Community)

ミニ評価の回し方（30分で十分）

  • 固定プロンプト×5問を用意（単純／入れ子／欠損／enum／多言語）。
  • 指標はスキーマ完全一致率とポストバリデーション通過率だけに絞る。
  • 失敗サンプルは“どこで壊れたか（必須欠損／型違い／enum外）”を短く記録。
    公開の評価軸（Support / Fluency / Nugget）は本文の文体評価に使えるが、型検証は上の2軸で十分です。(vellum.ai)

実装の入口（GitHub／デモ）

  • OpenAI Structured Outputs：公式の導入記事とResponses APIブログ。strict指定と構造化出力のレシートの概念が要点。(OpenAI)
  • Claude Tool Use：スキーマ目的の“擬似ツール”運用の勘所がまとまっています。(Claude Docs)
  • Gemini Function Calling / Structured Output：OpenAPIサブセット、制約事項（再帰や$ref）を必ず確認。(Google AI for Developers)

さらに触るなら：ONNX/ブラウザ実装と同様に、回帰用の小さな評価セットをレポに同梱しておくと運用がラクになります。(vellum.ai)

まとめ――“きれいなJSON”より“検証に耐えるJSON”

大事なのは、出力を作る前に型を決めること、入れ子を浅く保つこと、生成と実行を分けること、そして検証を小さく回すこと。
仕組み自体は各社そろいました。あとは、壊れ方の想像と最初の設計です。

参考（一次情報・比較）

  • OpenAI：Structured Outputsの公式発表／厳密一致の考え方。(OpenAI)
  • OpenAI：Responses APIの“レシート”（ツール呼び出し・構造化出力の記録）。(OpenAI 開発者)
  • Claude：Tool Useでスキーマ準拠のJSONを出させる方法。(Claude Docs)
  • Anthropic（設計記事）：ツール設計とLLMフレンドリーなドキュメント化の勘所。(Anthropic)
  • Google：GeminiのFunction Calling／Structured Output（2.5系）の制約と実装。(Google AI for Developers)
  • Azure：Structured Outputsの対応スキーマと制限。(Microsoft Learn)
  • 評価観点：S/F/Nなど公開の基準。(vellum.ai)
  • 実務ノート：実装差への注意喚起、Deep JSON評価、既知事象の共有。(Medium)

タイトル候補（運用ルール準拠）

  1. 「Structured Outputsで“スキーマ落ち”0件へ：OpenAI/Claude/Gemini 実践チェック【2025年10月】」
  2. 「JSON Schema厳密一致の通し方：Function Calling/Tool Use/Structured Output 比較ガイド」
  3. 「LLMの“壊れない”出力設計：入れ子3層までで回す分割戦略【2025】」
  4. 「OpenAPIサブセットで型を守る：Gemini 2.5 Structured Outputの注意点まとめ」 (Google AI for Developers)
  5. 「ClaudeのTool Useを“整形専用”で使う：スキーマ準拠JSONを安定化する手順」 (Claude Docs)

Discussion