LLM Output Parsing（エルエルエムアウトプットパーシング）
LLMが生成した自然言語テキストから構造化データ（JSON、XML、テーブル、リストなど）を抽出・解析する技術。正規表現、専用パーサー、再帰的修正プロンプトなどの手法で、プログラムが処理可能な形式に変換する。
LLM Output Parsingとは
LLM Output Parsing（出力パーシング）は、大規模言語モデルが生成したテキストから構造化データを抽出し、アプリケーションが利用可能な形式に変換する技術である。LLMの出力は本質的に非構造化テキストであり、そのままではデータベースへの格納やAPI応答、UIレンダリングに使えない。パーシングはLLMをソフトウェアシステムに統合する際の必須工程だ。
なぜOutput Parsingが必要か
LLMに「JSONで返してください」と指示しても、以下の問題が頻繁に発生する。
- 余計なテキスト混入: JSON前後に説明文やマークダウンフェンスが付く
- フォーマット崩れ: カンマ抜け、引用符の不整合、末尾カンマ
- 型の不一致: 数値を文字列で返す、配列をカンマ区切り文字列で返す
- スキーマ逸脱: 指定したフィールド名と異なるキーを使う、必須フィールドの欠落
- 幻覚データ: 存在しない製品名や架空の数値を含む
これらを吸収して確実に構造化データを得るのがOutput Parsingの役割だ。
主要なパーシング手法
正規表現ベース
json フェンスの検出やキーバリューパターンの抽出に使う。最もシンプルだが脆弱で、LLMの出力フォーマットが少しでも変わると破綻する。プロトタイプやシンプルなケースに限定して使用する。
専用パーサーライブラリ
LangChainのOutputParser、Guardrails AIのGuard、InstructorなどのライブラリがLLM出力のパーシングに特化した機能を提供する。スキーマ定義からバリデーション、エラー時の自動リトライまでを一貫して処理する。
LLM自己修正（Self-healing）
パーシングに失敗した場合、エラーメッセージとともに元の出力をLLMに再送し、修正を求めるループ。最大3〜5回のリトライで成功率を大幅に向上させる。Guardrails AIやInstructorはこのパターンを組み込んでいる。
制約付き生成（Constrained Generation）
LLMのデコード段階で出力トークンを制約し、特定のスキーマに適合する出力のみを生成させる。Outlines、Guidance、llama.cppのGBNF文法などが該当する。パーシング自体が不要になる最も根本的なアプローチだ。
主要ライブラリ比較
| ライブラリ | アプローチ | 対応モデル | 型安全 | リトライ | 特徴 |
|---|---|---|---|---|---|
| Instructor | Pydanticスキーマ強制 | OpenAI/Anthropic/Gemini/Ollama | ○ | ○ | 最もシンプル、Pydantic v2統合 |
| LangChain OutputParser | パーサーチェーン | 汎用 | △ | △ | エコシステムが広い |
| Guardrails AI | バリデーター連鎖 | 汎用 | ○ | ○ | ガードレール統合 |
| Outlines | 制約付き生成 | HF/vLLM/llama.cpp | ○ | 不要 | 文法レベルで制約 |
| Guidance | テンプレート生成 | Azure OpenAI/HF | ○ | 不要 | Microsoft製 |
| LMQL | クエリ言語 | OpenAI/HF | ○ | 不要 | SQL風の制約記述 |
パーシング戦略の選択基準
| ユースケース | 推奨手法 | 理由 |
|---|---|---|
| APIレスポンスの型安全化 | Instructor + Pydantic | 最小コードで型保証 |
| RAGパイプラインの中間処理 | LangChain OutputParser | エコシステム統合 |
| 高信頼性が必要な業務データ | Guardrails AI | 多段バリデーション |
| ローカルLLMでの構造化出力 | Outlines + GBNF | デコード段階で制約 |
| 実験・プロトタイプ | 正規表現 + json.loads | 迅速だが脆弱 |
エラーハンドリングのベストプラクティス
フォールバック戦略
- まずJSON Modeやstructured outputでの直接生成を試行
- 失敗したらマークダウンフェンスからJSONブロックを正規表現で抽出
- それでも失敗したらエラーメッセージ付きでLLMにリトライ要求
- 最終手段として部分的なパーシング結果をデフォルト値で補完
ログとモニタリング
パーシング成功率、リトライ回数、失敗パターンをログに記録し、プロンプトの改善に活用する。成功率が95%を下回る場合はプロンプトエンジニアリングの見直しが必要だ。
よくある質問
Q: JSON Modeがあればパーシングは不要ですか？
A: JSON Modeは出力がJSON形式であることを保証するが、スキーマ（フィールド名、型、必須項目）の準拠は保証しない。OpenAI structured outputsやAnthropicのtool_useはスキーマレベルの制約を提供するが、全モデルで利用可能ではない。Instructorのような上位ライブラリでスキーマ検証を追加するのが実践的だ。
Q: 制約付き生成とプロンプト指示はどちらが信頼性が高いですか？
A: 制約付き生成（Outlines、GBNF）はデコード段階でトークン確率を制約するため、理論上100%のスキーマ準拠を保証する。プロンプト指示は確率的でありミスが避けられない。ただし制約付き生成はローカルモデル向けで、APIモデル（GPT-4o、Claude）には適用できない制約がある。
Q: パーシング失敗時のリトライは何回まで許容されますか？
A: 一般的に3回が上限だ。リトライごとにAPIコストと遅延が発生する。Instructorのデフォルトは3回、Guardrails AIは設定可能。3回失敗したらフォールバック値を使うかエラーとしてユーザーに返す設計が適切だ。