AI・信頼性・評価

スキーマ制約は分類で効き、推論では指示を削らない

2026/7/29

🤖 AIが執筆しています

要点： JSON Schema で出力を縛る構造化出力は、もう特殊な工夫ではない。実世界の1万件のスキーマで6つのエンジンを効率・網羅・品質の三軸から比べるベンチマークまで整備された¹。そのうえで広く引かれる警告——形式制約は推論を落とす——は査読を通った知見であり、制約が厳しいほど低下は大きい。ただし同じ論文は、分類タスクでは形式制約がむしろ性能を上げると報告している²。構造化生成ライブラリ Outlines を作る .txt が同じ三つの推論ベンチでプロンプトを揃えて回し直すと、構造化した側がわずかに上回った³。そして本番で効くのは、また別の指標だ。答えが正しく、かつ JSON として妥当——この同時成立で測ると、小型モデルでは最大85%のタスク正解率が出力正解率0%に潰れる⁴。

制約デコードは共通のものさしを得た

制約デコード（constrained decoding）は、生成の各ステップで文法やスキーマに合わない選択肢をあらかじめ塞ぐ方式だ。出てきた文字列を後から検証するのではなく、規則を外れた出力がそもそも生成されない。この仕組みは共通の測り方を得ている。JSONSchemaBench は、実世界から集めた1万件の JSON スキーマを公式の JSON Schema Test Suite と組み合わせたベンチマークだ。評価は三軸から行う。効率（制約を満たす出力をどれだけ効率よく生成できるか）、網羅（多様な制約の型をどこまで扱えるか）、品質（生成物そのものの良さ）である¹。俎上に載るのは Guidance、Outlines、llama.cpp、XGrammar、OpenAI、Gemini の6つ。自作ライブラリからクラウドAPIまでが同じ土俵に並んだということは、「スキーマに合う文字列が返る」という保証は、もう各チームが作り込む部分ではないという意味になる。

「形式制約は推論を落とす」の中身

よく引かれる警告は、EMNLP 2024 Industry Track に採録された論文から来ている。Tam らは形式の縛り方を三つに分けた。JSON-mode（制約デコードで直接 JSON を出させる）、format-restricting instructions（FRI）（プロンプトで形式を指示する）、NL-to-Format（まず自然言語で答えさせ、次に整形させる二段方式）で、最後のものがいちばん緩い。この三つを比べると、形式制約のもとで推論能力は明確に低下し、制約が厳しいほど低下も大きいという傾向が出た。対象となった推論ベンチマークは GSM8K（小学校水準の算数文章題を解かせる標準ベンチ）、Last Letter Concatenation、Shuffled Objects である²。

論文の結論には、もう半分ある。同じ実験で、形式制約は分類タスクの性能を上げた。著者らが出した結論はタスク依存——推論には有害、分類や構造化抽出には有益——であって、構造化出力の全面禁止ではない²。パイプラインの工程を分類・抽出と推論に切り分けて読めば、この論文はそのまま掛け分けの指針になる。

プロンプトを揃えると推論の差は残らない

反論は、構造化生成ライブラリ Outlines を開発する .txt から出た。Will Kurt は五点を挙げる。論文自身のデータが分類では構造化生成の勝ちを示していること。構造化条件と非構造化条件で異なるプロンプトが使われていたこと。構造化側のプロンプトに課題の情報が足りず、たとえば JSON 用のプロンプトは使うべきツールに触れていなかったこと。パース手法の問題を生成性能の問題として扱っていること。そして構造化生成と JSON-mode を混同していることだ³。

最後の点は実装の選択に直結する。JSON-mode はファインチューニングで身につけさせた動作モードで、構文の妥当性に硬い保証はない。構造化生成のほうは、応答パーサを生成器として走らせるものだ——プロンプトとパーサと生成器を一つの系にまとめる設計であり、同じ「JSONで出す」という言い方でも得られる保証が違う。どちらを使っているかは、実装者が選べる。

.txt がプロンプトを揃えて三つの推論ベンチを回し直すと、結果は逆を向いた。GSM8K が0.77 → 0.78、Last Letter が0.73 → 0.77、Shuffle Object が0.41 → 0.44（非構造化 → 構造化）。三つとも構造化側がわずかに上回っている³。ただしこれは Outlines を提供する側が自社ブログに書いた再実験で、査読は通っていない。

正しくても構文が壊れていれば0点

Galeone らは、小型言語モデルの構造化出力を調べるなかで出力正解率（output accuracy）を定義した。答えが数学的に正しく、かつ JSON として妥当な構造を持つ——この二つが同時に成り立ったときだけ正解と数える、同時成立の指標である⁴。下流のプログラムから見れば当たり前の要求だ。パースに失敗した応答は、中身が何であれ使えない。

測ってみると、二つの数字は簡単に離れる。素朴なプロンプト（NAIVE）では GSM8K のタスク正解率が最大85%に達したにもかかわらず、出力正解率は全モデル・全データセットで0%だった。参照例を与える REFERENCE プロンプトでも、検証した4モデルのうち2つで出力正解率0%である⁴。タスク正解率だけを見ているかぎり、この落差は計測に一切現れない。

埋める手はある。同じ論文の AloLab は、ファインチューニングなし・過大なレイテンシなしで、GSM8K の出力正解率84〜87%、MATH で34〜40%に到達した。反復的なプロンプト最適化だけで差の大半は詰まる⁴。この結果の範囲は小型言語モデルであり、フロンティアモデルで同じ0%が起きるという話ではない。

パイプラインのどこを制約するか

まず、自分が使っている仕組みがどちらなのかを確かめる。API の JSON-mode と、文法やスキーマで生成そのものを縛る制約デコードは、名前が近いだけで保証の強さが違う。スキーマ違反を絶対に流したくない工程なら、後者を選ぶ。

制約をかけるとき、プロンプトから課題の説明を落とさない。形式の指示を足すぶん、手順や使えるツールの記述が押し出されて消えやすい。測定された劣化の相当部分は、その差から来ていた。形式の枠を足すのであって、指示を差し替えるのではない。

分類と抽出の工程は、遠慮なく制約してよい。ここは査読付きの結果が制約の側に立っている。ラベル集合や抽出フィールドをスキーマで固定すれば、下流の後処理も一緒に消える。

推論を伴う工程は二択になる。制約下でもプロンプトを十分に保つか、推論と整形を分けるかだ。後者は論文自身が最も緩い方式として並べた NL-to-Format——まず自然言語で考えさせ、別の呼び出しで JSON に整形する——にあたる。整形側の仕事は分類に近いので、そこは強く縛ってかまわない。

評価は同時成立で組む。タスク正解率と構文妥当率を別々の列で眺めるのではなく、両方を満たしたケースの割合を一つの数字にする。小型モデルを載せるなら、この数字がパイプラインの律速になる。

この報告を、どう割り引くか

証拠の重みは同じではない。形式制約が推論を下げるという知見は EMNLP 2024 Industry Track の査読を通っており、それに対する反論は Outlines を開発・提供する .txt の企業ブログ記事で、査読を経ていない。プロンプトを揃えた再実験の三つの数字は、利害関係のある側が自社の道具で出したものとして読む必要がある。

出力正解率が0%まで落ちた結果は小型言語モデルの話で、フロンティアモデルにそのまま移せない。大きなモデルで同じ落差が起きるかどうかは、この論文からは分からない。

本稿は EMNLP 論文のベンチマーク別の低下幅を数値で書いていない。二次的なブログでは具体的な下げ幅が流通しているが、一次資料から確認できなかったため引用を見送った。確かめられたのは向きとタスク依存性までで、どの工程にスキーマを掛けるかを決めるには、その二つで足りる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。