F-17: 構造化出力強制 vs 自由出力＋抽出¶

この相反は何か¶

AI エージェントが出力を生成する際、「LLM の出力フォーマットを JSON Schema や型定義で事前に強制するか（構造化出力強制）、それとも LLM に自由形式で出力させた後にパーサーや後処理で必要な構造を抽出するか（自由出力＋抽出）」という二択が F-17 の相反です。

この選択が排他的になる理由は、出力フォーマットの制約をどの段階で課すかで、LLM の推論過程と出力品質への影響が質的に異なるためです。構造化出力強制では、LLM はトークン生成の段階でスキーマに従う制約を受けます（response_format や constrained decoding）。これにより表現の自由度が制限されますが、出力の型安全性が保証されます。自由出力＋抽出では、LLM は制約なしに思考・生成し、後段のパーサーが必要な情報を取り出します。表現の自由度は最大ですが、抽出の失敗リスクがあります。

AI エージェントの文脈では、出力が人間に読まれるだけでなく下流のコードやAPIに渡される場面が多く、この選択がシステムの信頼性を左右します。ツール呼び出しの引数生成、構造化データの抽出、次のステップへの状態受け渡しなど、機械可読性が求められる場面では特に重要です。

選択肢A：構造化出力強制¶

構造化出力強制とは、LLM の出力が必ず特定のスキーマ（JSON Schema、TypeScript の型定義、Pydantic モデルなど）に従うよう、API レベルまたはプロンプトレベルで制約する方式です。OpenAI の response_format、Anthropic の tool use、各種フレームワークの structured output 機能などがこれに該当します。

構造化出力強制の最大の強みは型安全性の保証です。出力が必ず定義されたスキーマに従うため、下流のコードでパースエラーが発生しません。必須フィールドの欠損、型の不一致、未定義のフィールドの出現といった問題が構造的に排除されます。これは下流に API 呼び出しやデータベース書込がある場合に決定的な利点です。

また、後処理の実装がシンプルになります。自由形式テキストからの情報抽出は、正規表現やアドホックなパーサーに依存しがちで、境界ケースでの失敗が多くなります。構造化出力強制であれば、出力を単純にデシリアライズするだけで済みます。

弱点は表現の自由度の制約です。LLM が構造に従うことに認知リソースを割くため、内容の品質が低下する場合があります。特に、長い自由記述を含むフィールド、複雑なネスト構造、条件分岐のあるスキーマでは、制約に従うことに注力するあまり内容が表面的になることがあります。

さらに、スキーマの設計と維持にコストがかかります。出力形式が変わるたびにスキーマを更新する必要があり、頻繁に変更がある場合は保守負荷が高くなります。

選択肢B：自由出力＋抽出¶

自由出力＋抽出とは、LLM にフォーマットの制約を課さず自由に生成させ、生成後に後段のパーサー（正規表現、別の LLM、ルールベースの抽出器など）で必要な構造化データを取り出す方式です。

自由出力の最大の強みは生成品質の最大化です。LLM はフォーマットの制約に認知リソースを割かず、内容の推論と生成に集中できます。特に、創造的な文章生成、長文の要約、ニュアンスのある分析など、自由度が品質に直結するタスクでは、構造化の制約が品質を損なう可能性があります。

また、出力形式の変更に対する柔軟性が高いです。スキーマを事前に厳密に定義する必要がないため、プロトタイピング段階や、出力形式が未確定の段階での開発速度が向上します。

弱点は抽出の信頼性です。自由形式テキストからの情報抽出は本質的に不完全であり、LLM の出力フォーマットが予期しない形式で返ってくることがあります。「JSON で返して」とプロンプトに書いても、余分なテキストが付加されたり、キー名が揺れたり、フォーマットが壊れたりすることがあります。この不確実性は、後段でのエラーハンドリングを複雑化させます。

さらに、抽出パーサーの保守コストが発生します。LLM の出力フォーマットはモデルの更新やプロンプトの変更で変わりうるため、抽出ロジックの安定性は低くなります。

選定基準¶

この相反の選定は [accountability] と [task_variability] の二つの駆動変数で決まります。

構造化出力強制を選ぶべき条件：

下流にコード・API・データベースがあり、出力を機械的に消費する場合。型の不一致やフィールドの欠損が実害を生む場面です。
[accountability] が高い場合。出力の構造が事前に定義されていることで、検証・監査・テストが容易になります。
出力スキーマが安定しており、頻繁な変更が見込まれない場合。
[failure_cost] が高い場合。パースエラーや型の不一致が連鎖的な障害を引き起こすリスクがある場面です。

自由出力＋抽出を選ぶべき条件：

[task_variability] が高く、出力形式を事前に厳密に定義できない場合。探索的なタスク、創造的な生成、ユーザー対話の応答などです。
出力が主に人間に読まれる場合。自然な文章表現が品質の重要な要素である場面です。
出力形式が頻繁に変わるプロトタイピング段階。スキーマの定義・維持コストが利益を上回ります。
LLM の生成品質がフォーマット制約で劣化することが確認された場合（特に複雑なスキーマで発生しやすいです）。

デフォルトとハイブリッド¶

デフォルト：下流にコードがある（機械消費）なら構造化出力強制、人間が読むだけなら自由出力がデフォルトです。

ハイブリッド：自由生成後に構造化抽出パスを通すという二段構成が実用的な折衷案です。まず LLM に自由形式で思考・生成させ（chain-of-thought を含む）、その出力を別の LLM 呼び出し（または同一呼び出しの第二段階）で構造化データに変換します。これにより、生成品質を維持しつつ下流への型安全性を確保できます。ただし、追加の LLM 呼び出しによるコストとレイテンシの増加があります。

E4 Verified Structured Output パターンは、構造化出力強制にさらにビジネスルール検証を加えた構成を扱っています。

判断を誤ったときの症状¶

構造化出力強制を選んだが自由出力が適切だった場合の症状：

出力の内容品質が期待を下回っています。特に長文フィールドや説明フィールドの記述が表面的で、同じプロンプトを自由形式で実行すると明らかに品質が高くなります。
スキーマの変更頻度が高く、スキーマの更新→テスト→デプロイのサイクルが開発のボトルネックになっています。
複雑なネスト構造のスキーマで、LLM のスキーマ違反率が高く、リトライが頻発しています。

自由出力＋抽出を選んだが構造化出力強制が必要だった場合の症状：

後段のパーサーでのエラー率が高く、抽出失敗のハンドリングに工数が割かれています。
LLM の出力フォーマットが微妙に変わるたびに（モデル更新、プロンプト修正で）、抽出ロジックの修正が必要になります。
型の不一致やフィールドの欠損が下流システムでサイレントに問題を引き起こし、発見が遅れています。
「ほとんどの場合はうまくいくが、時々壊れる」という不安定さが本番で問題になっています。