Structured Outputとは — JSON Schemaで生成結果を受け取る設計

Structured Outputは、LLMの出力を、あらかじめ定義した構造に沿って受け取る仕組みです。

LLMに「JSONで返して」と頼み、返ってきた文章を後から正規表現で切り出す。最初は動いても、出力が少し変わるだけで壊れます。

JSON Schemaなどで期待するField、型、必須項目、許容値を指定します。

機械処理はだいぶ楽になります。ただし、Schemaに合うことと、内容が事実・業務ルールに合うことは別です。

JSONであることとSchemaに合うことは違う

方法	保証する範囲
Promptで「JSONを返して」と依頼	モデルへの指示だけ
JSON mode	構文上ValidなJSON
Structured Output	Providerが対応するSchemaへの適合
Application validation	自社Schemaと追加制約への適合
Domain validation	ID存在、権限、状態遷移、整合性

JSON Schema Specificationは、JSON documentの構造とValidation keywordを定義します。ただし、Model APIのStructured OutputがJSON Schemaの全Keywordを支えるとは限りません。

OpenAI Structured OutputsとClaude Structured OutputsはいずれもSchemaに沿った出力を提供しますが、対応Model、Keyword、制限、Refusal時の形はProviderごとに確認が必要です。

Schemaは業務契約として小さく作る

json

{
  "type": "object",
  "properties": {
    "category": {
      "type": "string",
      "enum": ["billing", "technical", "other"]
    },
    "summary": {
      "type": "string"
    },
    "needsHumanReview": {
      "type": "boolean"
    }
  },
  "required": ["category", "summary", "needsHumanReview"],
  "additionalProperties": false
}

自由なstringだけを返す巨大なSchemaでは、構造化の利点が減ります。Enum、必須項目、長さ、追加Propertyの可否を、利用するProviderの対応範囲で定義します。

一方で、業務ルールをすべてSchemaへ埋め込む必要はありません。顧客IDが現在の利用者に属するか、返金可能期間内か、残高が足りるかは実行時に確認します。

Structured OutputはTool callと用途が異なる

Structured Outputは、分類結果、抽出結果、画面表示用の構造などを返すために使えます。Function CallingとToolは、モデルが外部機能の利用を要求するために使います。

同じJSON Schemaを使う場合でも、後続処理が違います。

Structured Output: アプリケーションが出力データを利用する
Tool call: アプリケーションが引数を検証し、外部処理を実行する

Tool callの引数がSchemaに適合しても、その操作を許可してよいとは限りません。Authorizationを別に確認します。

Refusal、途中終了、未対応Schemaを扱う

Structured Outputを有効にしても、常に期待Objectが返るとは限りません。

Safety上のRefusal
出力Token上限による途中終了
Request Schema自体の不備
Providerが未対応のKeyword
Model/API Versionの非対応
Network errorやRate Limit

成功ResponseとRefusal、API error、Validation errorを別の型として扱います。失敗時に空Objectで処理を続けると、後続のDefault値が誤った業務判断になります。

Web実装では境界で再検証する

ProviderがStrictなSchema適合を示していても、自社アプリケーションの境界でParseとValidationを行います。

APIの終了理由を確認する
RefusalやErrorを分ける
JSONをParseする
自社SchemaでValidationする
Domain ruleとAuthorizationを確認する
保存・Tool実行へ進む

Schema Versionも記録します。Field追加やEnum変更では、過去データ、Cache、再試行中Requestとの互換性を考えます。

よくある誤解

JSON modeなら指定したSchemaに一致する

JSON modeが保証するのはValid JSONまでの場合があります。必須FieldやEnumへの適合はStructured OutputまたはApplication validationで確認します。

Schemaに合えば内容も正しい

存在しない顧客IDや、根拠のない金額も型としてはValidです。事実性と業務整合性は別に確認します。

Structured OutputならPromptは不要になる

Schemaは出力形を伝えます。分類基準、判断条件、曖昧な場合の扱いはInstructionやExamplesで伝えます。

Provider間で同じJSON Schemaをそのまま使える

対応するDraftやKeyword、再帰、上限が異なります。共通部分を確認し、ProviderごとのValidationをCIで行います。

EastBraver Labsの判断基準

EastBraver Labsでは、後続コードが読む出力にStructured Outputを使います。自然言語から壊れやすいParseを行う構成は避けます。

ただし、Schema適合を安全性の完了条件にはしません。型のValidation、Domain validation、Authorizationを順番に通す。どこで拒否したかもTraceへ残します。

Schemaは広い万能Objectではなく、一つの用途に必要な最小単位へ絞ります。変更時に評価と互換性確認を行える大きさを保ちます。