はじめに
LLMをプロダクションで使うとき、最大の課題のひとつが 「出力のフォーマットが安定しない」 ことです。
「JSONで返して」とプロンプトに書いても、余計な説明文がついたり、キーの名前が揺れたり、そもそもJSONとして壊れた文字列が返ってきたりします。
この問題を根本的に解決するのが 「構造化出力（Structured Output）」 です。2024年にOpenAIが正式サポートして以降、Anthropic（Claude）、Google（Gemini）など主要プロバイダが続々と対応し、2026年現在は プロダクションLLMアプリの標準機能 になっています。
この記事では、構造化出力の仕組みと実装方法を、Pythonのコード例とともに解説します。
なぜ構造化出力が必要なのか
たとえば、商品レビューの感情分析をLLMにやらせるケースを考えましょう。
構造化出力なし（従来の方法）
response = llm.invoke("このレビューを分析して: '配送が早くて助かりました'")
# → "このレビューはポジティブな感情を示しています。星5つ相当と考えられます。"
テキストとしては正しいですが、これをプログラムで処理するには 文字列をパースする 必要があります。「星5つ」を数値として取り出すには正規表現や文字列操作が必要で、LLMの出力フォーマットが変わるたびにパーサーが壊れます。
構造化出力あり
# → {"sentiment": "positive", "score": 5, "summary": "配送速度への満足"}
最初から決められたスキーマのJSONで返ってくるので、パース不要で即座にプログラムで利用できます。
構造化出力の仕組み
構造化出力の基本的な考え方は、「LLMにJSON Schemaを渡して、そのスキーマに完全準拠した出力を強制する」ことです。
① 開発者がスキーマ（型定義）を用意
↓
② APIリクエスト時にスキーマを添付
↓
③ LLMがスキーマに従ったJSONだけを生成
↓
④ SDKがJSONをPydanticオブジェクトに自動変換
LLM側では、トークン生成時にスキーマに違反するトークンの出力確率をゼロにする 制約付きデコーディング が行われています。これにより、OpenAIの公式評価では 100%のスキーマ準拠率 を達成しています。
実装方法①：OpenAI SDK
OpenAIは2024年8月に構造化出力を正式サポートしました。PydanticモデルをそのままAPIに渡せます。
Pydanticでスキーマを定義
from pydantic import BaseModel
class ReviewAnalysis(BaseModel):
sentiment: str # "positive" / "negative" / "neutral"
score: int # 1〜5
summary: str # 要約（1文）
keywords: list[str] # キーワードのリスト
APIに渡して構造化出力を取得
from openai import OpenAI
client = OpenAI()
completion = client.beta.chat.completions.parse(
model="gpt-4o",
messages=[
{"role": "system", "content": "商品レビューを分析してください。"},
{"role": "user", "content": "配送が早くて助かりました。梱包も丁寧でした。"},
],
response_format=ReviewAnalysis,
)
result = completion.choices[0].message.parsed
print(result.sentiment) # → "positive"
print(result.score) # → 5
print(result.keywords) # → ["配送", "梱包", "丁寧"]
.parse() メソッドが Pydantic モデルを自動的にJSON Schemaに変換し、返ってきたJSONを型付きオブジェクトに戻してくれます。result.sentiment のようにドット記法でアクセスでき、IDE の補完も効きます。
実装方法②：LangChainで抽象化する
複数のLLMプロバイダに対応したい場合は、LangChainの with_structured_output() が便利です。OpenAI、Anthropic、Google など、プロバイダを問わず同じインターフェースで構造化出力を利用できます。
from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field
class ReviewAnalysis(BaseModel):
sentiment: str = Field(description="positive / negative / neutral")
score: int = Field(ge=1, le=5, description="1〜5の評価スコア")
summary: str = Field(description="レビューの要約（1文）")
keywords: list[str] = Field(description="キーワードのリスト")
llm = ChatOpenAI(model="gpt-4o")
structured_llm = llm.with_structured_output(ReviewAnalysis)
result = structured_llm.invoke("配送が早くて助かりました。梱包も丁寧でした。")
print(type(result)) # → <class 'ReviewAnalysis'>
print(result.score) # → 5
Ollamaに切り替える場合
from langchain_ollama import ChatOllama
llm = ChatOllama(model="llama3.2")
structured_llm = llm.with_structured_output(ReviewAnalysis)
# → ローカルLLMでも同じインターフェースで構造化出力が使える
LangChainの抽象化レイヤーを使えば、バックエンドのモデルを差し替えてもアプリケーションコードを変更する必要がありません。
実践例：レビュー一括分析パイプライン
構造化出力の真価は、複数データを一括処理してプログラムで集計するとき に発揮されます。
reviews = [
"配送が早くて助かりました。梱包も丁寧でした。",
"サイズが合わなかった。返品手続きが面倒。",
"普通です。可もなく不可もなく。",
"デザインが写真と全然違う。がっかりした。",
]
results = [structured_llm.invoke(r) for r in reviews]
# 平均スコアを計算
avg = sum(r.score for r in results) / len(results)
print(f"平均スコア: {avg}") # → 平均スコア: 2.75
# ネガティブレビューだけ抽出
negatives = [r for r in results if r.sentiment == "negative"]
print(f"ネガティブ件数: {len(negatives)}") # → ネガティブ件数: 2
フリーテキストの回答では不可能な 「LLMの出力を集計・フィルタリング・DB保存する」 といった後続処理が、構造化出力なら自然に書けます。
ベストプラクティス
① Field(description=...) で各フィールドに説明をつける
Pydanticの Field にdescriptionを書くと、それがJSON Schemaに含まれてLLMへの指示として機能します。フィールド名だけでは伝わらないニュアンスを補足できます。
class Article(BaseModel):
title: str = Field(description="記事タイトル。30文字以内")
body: str = Field(description="本文。Markdown形式")
tags: list[str] = Field(description="タグ。最大5個")
② Enumで選択肢を制限する
sentiment のような有限の選択肢は、Python の Enum や Literal で定義すると出力が安定します。
from typing import Literal
class ReviewAnalysis(BaseModel):
sentiment: Literal["positive", "negative", "neutral"]
score: int = Field(ge=1, le=5)
③ 必ずバリデーションを行う
構造化出力はスキーマ準拠率が非常に高いですが、ビジネスロジック上の妥当性 は保証されません。たとえば「sentimentがnegativeなのにscoreが5」といった矛盾が生じる可能性があります。Pydanticの model_validator で追加のバリデーションを入れるのがおすすめです。
シリーズとの繋がり
| シリーズ記事 | 構造化出力との関係 |
|---|---|
| RAG | 検索結果を構造化してLLMに渡すことで、回答の精度と一貫性が向上 |
| LangGraph | エージェントのStateに構造化出力を格納し、次のノードの判断材料にする |
| Ollama | LangChain経由でローカルLLMでも構造化出力を利用可能 |
| Dify | DifyのワークフローノードでJSON出力を指定し、後続ノードで活用 |
まとめ
| キーワード | 一言で言うと |
|---|---|
| 構造化出力 | LLMの出力をJSON Schemaに従わせる技術 |
| Pydantic | Pythonの型定義ライブラリ。スキーマ定義に最適 |
with_structured_output() |
LangChainの抽象化メソッド。プロバイダ非依存 |
| 制約付きデコーディング | スキーマ違反トークンの出力を抑制する仕組み |
| ベストプラクティス | description付与 + Enum/Literal + バリデーション |
構造化出力は「LLMをAPIとして組み込む」ための必須技術です。フリーテキストのパースに苦しんでいる方は、まずは1つのPydanticモデルを定義して .with_structured_output() を呼んでみてください。世界が変わります。
参考：