9月2日、Mostafa Ibrahimが「Your JSON Is Valid but Your Data Is Wrong: Five Failure Modes LLM Structured Outputs Won't Catch」と題した記事を公開した。Ibrahim自身が構築した分類パイプラインは約12回に1回、もっともらしいが捏造された値を返していた。JSONは常にパースが通り、Pydanticもエラーを出さない。ダウンストリームのチェックがすべて構造的なものだったため、気づくまでに数週間かかったという。さらに驚くべきことに、制約デコーディングを適用したモデルは適用しないモデルより精度が低いという逆転現象まで確認されている。
「JSONが通れば正しい」という思い込みの危険性
OutlinesやSGLangなどの文法ベースの制約デコーディング（constrained decoding）が登場する前、LLMから有効なJSONを得るにはリトライループを繰り返すしかなかった。制約デコーディングはトークン選択を有限状態機械に通すことでその問題を解決し、スキーマ適合率はほぼ100%に達した。
その結果、静かに広まった思い込みがある。「JSONがスキーマに対して検証を通れば、データは正しい」というものだ。
BAMLのベンチマークはその前提を否定する。関数呼び出しタスクにおいて、制約なしの生成に事後パースを組み合わせた手法は93.63%の精度を達成したのに対し、同じモデルに制約デコーディングを適用すると91.37%まで低下した。常にパースが通るJSONのほうが、時々壊れるJSONより正確さで劣るという逆転現象が起きている。
Lee et al.の研究はそのコストを定量化している。オープンウェイトモデル全体で、構造化出力フォーマットを強制すると3〜9ポイントの精度低下が生じた。数学的推論タスクに限ると、その差は15ポイント超に達した。フォーマットの強制はタダではない。
5つの失敗パターン
スキーマ検証はフィールドの型エラーは検出できる。しかし以下の5つは、構造的には有効でありながら実質的に誤った出力を生む。
1. Enum hallucination（列挙値の幻覚）――最も見落とされやすい
["low", "normal", "high", "urgent"] のような列挙型では、文法がこの4値のいずれかを保証する。しかし文脈に応じた重み付けはしない。ルーティンな依頼に "urgent" が、緊急案件に "low" が返ってもスキーマは両方を受理する。
実運用でこれが厄介なのは、値の分布を時系列でモニタリングしない限り検出できない点だ。個々の出力を見ても異常がわからない。
2. Confident fabrication（自信を持った捏造）
制約デコーディングはモデルの「拒否する能力」を奪う。スキーマが値を要求すれば、モデルは入力が何であれ値を提供する。BAMLはゾウの写真を領収書として送信する実験を行い、制約デコーディングが拒否せずに完全なスキーマ準拠の経費精算書を返したことを実証している。
3. Cross-field contradiction（フィールド間の矛盾）
スキーマ検証は各フィールドを独立に検査する。{"sentiment": "positive", "score": 0.1}（ポジティブラベルなのにスコアは0に近い）や、{"start": "2026-03-15", "end": "2026-03-10"}（終了日が開始日より前）はいずれも個別検証を通過する。矛盾はフィールド間にあり、単一フィールドのバリデーターは設計上それを捕捉できない。
4. Distributional collapse（分布の収縮）
制約デコーディングは有効なトークン集合の中で確率の高いトークンに偏る。0.95、"medium"、"general" といった「安全なデフォルト値」はコンテキスト固有の値より基底確率が高い。Ibrahim自身の分類パイプラインでは信頼スコアが3週間にわたり0.98に張り付いた。Collin Wilkinsも同様の事例として、ランダムな入力を含むすべての出力で信頼スコアが0.99になったケースを報告している。
5. Array hallucination（配列の幻覚）
モデルは空配列 [] を返したがらない。文法がオブジェクト生成パスに高い重みを置くため、[] は低確率なトークン列になる。抽出タスクでは「0件」が正解のときに幻のエントリが生成され、「3件見つかりました」と報告される。
「バリデーションを増やせばいい」は機能しない
最初の直感は「バリデーションルールを増やす」ことだ。既知のパターンにはそれが効く。Pydanticのmodel_validatorで start_date > end_date を検出できる。
しかし構造的正しさは閉じた問題だ（所定のスキーマに対する有効なJSON形状は列挙できる）。意味的正しさは開いた問題だ。まだ見ていない誤答に対するルールは書けない。モデルは新しい誤り方をバリデーター追加のペースより速く見つける。
3層の防御
Ibrahim は以下の3層を提案する。
- Layer 1（スキーマ検証）: Pydantic、JSON Schema、Zodによる型・構造チェック。これは維持する。
- Layer 2（セマンティック検証）: フィールド間制約関数（「sentimentがpositiveならscoreは0.5超」等）と、フィールド値の出力エントロピー監視（各フィールドの値がどれだけばらついているかをシャノンエントロピーで定量化する手法）。エントロピーが閾値を下回ったら分布収縮のアラートを出す。あいまい入力に対するサンプル監査も有効だ。
- Layer 3（不確実性の明示化）: 抽出値ごとにオプショナルな
confidenceフィールドを付与する。CleanlabのCONSTRUCTベンチマークでは、フィールド単位の信頼性スコアリングがGPT-4oやGeminiの構造化出力エラーをプロンプトレベルの信頼推定より高精度で検出できることが示されている。高リスクなフィールドにはLLM-as-judgeによる第2モデル呼び出しを加える。
ほとんどのチームはLayer 1しか持っていない。Layer 2を追加するだけで、サイレントな失敗の大半を捕捉できる。
パイプラインが静かに壊れているときの3つのシグナル
個別出力の目視では検出できない。シグナルは統計的なものだ。
- 出力エントロピーが低下している: 本来ばらつくはずのフィールドが特定の値に集中し始めたら、モデルが安全なデフォルトに収縮している。値の分布を週次でプロットする。
- 配列フィールドが一度も空にならない: 空になるべきケースが存在するはずなのに
[]が一度も返ってこなければ、エントリが捏造されている。 - 上流に変更がないのに下流の指標が動く: モデルのバージョン、プロンプト、スキーマに変更がないのにビジネス指標がずれたなら、構造準拠を保ったまま意味的精度が劣化している可能性がある。最も帰属が難しく、多くの場合最初に現れるシグナルだ。
スキーマはデータが正しいとは教えてくれない。形が正しいと教えてくれるだけだ。スキーマ準拠は上限ではなく下限である。
詳細はYour JSON Is Valid but Your Data Is Wrong: Five Failure Modes LLM Structured Outputs Won't Catchを参照していただきたい。
