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

> LLMのStructured Output、JSON mode、Function Callingの違いを整理し、Schema適合と業務上の正しさを分けて検証する方法を示します。

Canonical URL: https://labs.eastbraver.com/guides/structured-output
Published: 2026-07-01
Updated: 2026-07-15
Category: field-guide
Tags: software-engineering, llm-inference, safety

Structured Outputは、[LLM](/guides/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](https://json-schema.org/specification)は、JSON documentの構造とValidation keywordを定義します。ただし、Model APIのStructured OutputがJSON Schemaの全Keywordを支えるとは限りません。

[OpenAI Structured Outputs](https://openai.com/index/introducing-structured-outputs-in-the-api/)と[Claude Structured Outputs](https://platform.claude.com/docs/en/build-with-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](/guides/tool)は、モデルが外部機能の利用を要求するために使います。

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

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

Tool callの引数がSchemaに適合しても、その操作を許可してよいとは限りません。[Authorization](/guides/ai-identity-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を行います。

1. APIの終了理由を確認する
2. RefusalやErrorを分ける
3. JSONをParseする
4. 自社SchemaでValidationする
5. Domain ruleとAuthorizationを確認する
6. 保存・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ではなく、一つの用途に必要な最小単位へ絞ります。変更時に評価と互換性確認を行える大きさを保ちます。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [エージェント運用の境界が具体化](/digest/ai-digest-20260709)
- [GPT-5.6とAI実行基盤の境界](/digest/ai-digest-20260710)

## 検証範囲

- 一次情報: 公式ドキュメント / 仕様書 / 設計面からの分析
- ローカル検証: 手元で再現しています
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開