LLM構造化出力(Structured Output)完全ガイド2026｜OpenAI/Claude/Gemini Strict Mode・Pydantic・Instructor

LLM構造化出力(Structured Output)とは｜本番LLMアプリの必須技術

LLM構造化出力(Structured Output / JSON Mode)は、LLMの出力を事前に定義したスキーマ(JSON Schema)に従って確実に構造化する技術です。自由記述のテキストではなく、決められた型・フィールド・値域を持つJSONとして受け取れるため、後続処理との統合・テスト・バリデーションが劇的に容易になります。2026年時点では「本番LLMアプリでは必須」の技術と位置付けられ、OpenAI・Anthropic・Google Gemini・AWS Bedrockの主要全プロバイダがネイティブ対応しています。

本記事では構造化出力の3方式(Tool/Native/Prompted)、主要プロバイダ対応状況、Pydantic/Instructor/Pydantic AI/Zod等の実装ライブラリ、そしてrenue独自視点として「本番運用6原則」を解説します。LLM連携全体の設計はFunction Calling完全ガイド、AgentOps、Context Engineeringも参照してください。

なぜ構造化出力が必要か｜「JSONを正規表現でパースする時代は終わった」

自由テキストは壊れる：「以下のJSONを返して」と指示してもマークダウンコードブロックや余計な説明文が混入する
後続処理の信頼性：DB挿入・API呼び出し・フロント表示など全てで「予期しない型」が致命傷
バージョン管理：スキーマをコードで定義できるためGit管理・レビュー・テストが可能
エラーハンドリング：型が一致しない場合に自動リトライ・フォールバックを組める
コスト削減：不正出力→再リクエストのループがなくなる

2026年は「プロンプトに『JSONで返して』と書いて正規表現でパースする」実装はアンチパターンです。

構造化出力の3方式

方式	仕組み	品質	使いどころ
Tool Output (Function Calling)	ツール呼び出しの引数スキーマとして出力	高い	OpenAI/Anthropic等ツール呼出し併用時
Native Output (Strict Schema)	ネイティブ構造化出力API、Constrained Decodingで保証	最高(100%保証)	OpenAI Strict/Gemini responseJsonSchema等
Prompted Output	プロンプトにスキーマを埋め込み、生成後パース	中(再試行必要)	古いモデル・非対応モデル

2026年の実務ではNative OutputまたはTool Outputが標準で、Prompted Outputは非対応モデルのフォールバックに留まります。

主要プロバイダの対応状況(2026年)

プロバイダ	モード	特徴
OpenAI	Structured Outputs (Strict Mode)	2024年8月にConstrained Decodingでスキーマ100%保証、`.parse()`でPydantic直受け
Anthropic Claude	Structured Output(GA 2026年初頭)	Claude Opus/Sonnet/Haiku 4.5/4.6系で対応、Anthropic API/Amazon Bedrockで利用可
Google Gemini	responseJsonSchema (Gemini 2.0+)	標準JSON Schemaとの互換性が高い
AWS Bedrock	プロバイダごとに提供	Claude/Mistral等のネイティブ機能を利用
OSS LLM(Llama/Qwen/DeepSeek)	Instructor/Outlines/Guidance等のライブラリ経由	Constrained Decodingを外付け実装

特にOpenAIのStrict Modeは「Constrained Decoding」という技術で、トークン生成時にスキーマに反するトークンを確率から除外する仕組みで、スキーマ遵守率100%を保証します。これは2024年の革新であり、2026年のスタンダードになりました。

Pydanticによるスキーマ定義｜Python実装の事実上標準

Pythonでの構造化出力定義の標準はPydanticです。以下の擬似コード例を見てみます。

from pydantic import BaseModel, Field
from typing import Literal

class ArticleExtraction(BaseModel):
    title: str = Field(description="記事タイトル")
    category: Literal["news", "howto", "opinion"] = Field(description="カテゴリ")
    tags: list[str] = Field(max_length=5, description="最大5つのタグ")
    summary: str = Field(max_length=200, description="200文字以内の要約")
    confidence: float = Field(ge=0.0, le=1.0, description="抽出信頼度")

# OpenAI Structured Outputs
response = client.beta.chat.completions.parse(
    model="gpt-5",
    messages=[...],
    response_format=ArticleExtraction,
)
article: ArticleExtraction = response.choices[0].message.parsed

この方式なら:

スキーマがPythonコードとして定義されテスト・lintが効く
Literal/Field(max_length=...)等で値制約まで記述できる
パース結果が型付きオブジェクトで返ってくる
スキーマ変更は単なるPydanticモデル変更なのでGit管理が容易

主要ライブラリ比較

ライブラリ	言語	特徴
Pydantic AI	Python	Pydantic公式のAIフレームワーク。Tool/Native/Prompted 3方式対応、型安全
Instructor	Python / TS / Go / Ruby	15+プロバイダ対応、自動リトライ、ストリーミング、マルチ言語
LiteLLM (Structured Outputs)	Python	LiteLLMのJSON Mode統一インターフェース
Outlines	Python	OSS LLM向けのConstrained Decoding実装
Guidance	Python	Microsoft製、正規表現・文法ベースの制約デコーディング
Zod	TypeScript	TS版Pydantic、Vercel AI SDK等で標準
Marvin	Python	高レベル抽象、Pydantic統合

2026年実務ベストプラクティス

ネイティブ構造化出力を最優先：OpenAIの.parse()、GeminiのresponseJsonSchema、Claudeの構造化出力を使う
それでもPydantic/Zodで二重バリデーション：プロバイダが保証してもビジネスロジックの値チェックは別途必要
スキーマは小さく分割：巨大なネストスキーマはコストとエラー率が上がる。複数呼び出しに分割
enum/Literalで列挙型を明示：自由文字列より列挙型の方が精度が上がる
description必須：各フィールドの意味をdescriptionで明文化。LLMの精度に直結
オプショナルフィールドは明示：必須/オプショナルをOptionalで区別
リトライ戦略：バリデーション失敗時の自動リトライを組む(Instructor等が標準機能)
ストリーミング対応:長大なスキーマはストリーミング+部分パースで応答性向上

Function Calling との関係

構造化出力とFunction Callingは密接に関係します。Function Callingはツール呼び出しの引数を構造化出力として返す仕組みで、Tool Output方式の構造化出力そのものです。違いは用途で、構造化出力は「データを構造化して返す」目的、Function Callingは「ツールを実行する」目的です。実装上は同じ技術を使うため、2026年はこの2つを統一的に扱うライブラリが標準になっています。

よくある失敗パターン

プロンプトで「JSONで返して」と指示するだけ：非ネイティブ方式、出力破損多発
巨大なネストスキーマ：精度低下・コスト増・レイテンシ悪化
description未記載：LLMが各フィールドの意味を推測できず精度低下
バリデーションなしで信頼：Strict Modeでもビジネスロジック違反は通るため二重検査必須
値域制約の省略：confidence: floatでは0〜1を強制できない。Field(ge=0, le=1)を書く
OSSモデルでネイティブ方式を期待：Llama/Qwen等はInstructor/Outlines経由で
Prompted Outputの混在：同じアプリ内でプロバイダによって実装方式がバラバラ

renueの視点｜本番LLMアプリの構造化出力6原則

renueは広告代理AIエージェント・AI PMOエージェント・Drawing Agent・SEO記事生成エージェント等を複数自社運用しており、構造化出力を本番運用する知見を6原則にまとめています。

(1) プロバイダ非依存の抽象化層を挟む：OpenAI/Anthropic/Geminiそれぞれのネイティブ方式をアプリから直接呼ばず、LiteLLMやPydantic AI等の抽象化層を挟みます。プロバイダ切替・フォールバック・評価の全てが容易になります。

(2) スキーマはPydanticでGit管理：スキーマをコードとして管理し、変更はPR経由。プロンプト管理(Context Engineering)と同じ規律を適用します。

(3) 二重バリデーション必須:プロバイダがスキーマ遵守を保証しても、ビジネスロジック(日付の整合性、金額の範囲、関連フィールドの相関)はPydanticの@validatorやmodel_validatorで別途チェックします。

(4) スキーマは小さく・浅く：巨大なネストスキーマより、複数の小スキーマに分割して並列呼び出しする方がコスト・精度・レイテンシ全てで有利です。

(5) descriptionは第二のプロンプト：各フィールドのdescriptionはLLMにとって指示文そのものです。「カテゴリ」ではなく「記事のカテゴリ。news(ニュース), howto(手順解説), opinion(意見記事)のいずれか」のように明示的に書きます。

(6) 評価CIにスキーマ適合率を含める：通常のGolden Set評価に加えて「スキーマ違反率」「必須フィールド欠損率」「値域逸脱率」をCIで継続計測します(LLM評価指標/LLM Observability)。モデル更新で劣化することがあります。

よくある質問（FAQ）

Q1. Strict Modeで本当に100%保証されますか？

OpenAIのStrict ModeはConstrained Decodingでスキーマ遵守を100%保証しますが、ビジネスロジック違反(無効な値の組み合わせ等)は保証対象外です。二重バリデーション必須です。

Q2. 構造化出力とFunction Callingはどう使い分けますか？

「データを取り出したい」なら構造化出力、「外部ツール/APIを実行したい」ならFunction Callingです。技術的には同じ仕組みを使うため明確な境界はありません。

Q3. OSSモデル(Llama/Qwen等)でも構造化出力は使えますか？

Instructor/Outlines/Guidanceなどのライブラリ経由で使えます。精度はモデルサイズに依存します。

Q4. 大量のフィールドを持つスキーマは扱えますか？

50フィールド以上は避けるべきです。コスト増・精度低下・エラー率増が発生します。複数呼び出しに分割するのが正攻法です。

Q5. renueは構造化出力の設計を支援していますか？

はい。スキーマ設計・抽象化層構築・評価CI統合・本番運用まで一貫して支援しています。

構造化出力・LLMアプリ設計のご相談はrenueへ

renueは複数のAIエージェント事業を自社運用するAIエージェント開発企業として、構造化出力のスキーマ設計・プロバイダ抽象化層・評価CI統合までワンストップで支援しています。本番LLMアプリの信頼性でお困りの方はお気軽にご相談ください。

AIエージェント開発の事例を見る