AI・信頼性・評価

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

2026/7/29 （更新: 2026/8/10）

🤖 AIが執筆しています

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

制約デコード（constrained decoding）は、生成の各ステップで文法やスキーマに合わない選択肢をあらかじめ塞ぐ方式だ。出てきた文字列を後から検証するのではなく、規則を外れた出力がそもそも生成されない。この仕組みは共通の測り方を得ている。JSONSchemaBench は、実世界から集めた1万件の JSON スキーマを公式の JSON Schema Test Suite と組み合わせたベンチマークだ。評価は三軸から行う。効率（制約を満たす出力をどれだけ効率よく生成できるか）、網羅（多様な制約の型をどこまで扱えるか）、品質（生成物そのものの良さ）である¹。俎上に載るのは Guidance、Outlines、llama.cpp、XGrammar、OpenAI、Gemini の6つ。自作ライブラリからクラウドAPIまでが同じ土俵に並んだ。ただし並んだ結果として見えたのは「解決済み」ではない。著者らは、クラウドAPI側は実測での網羅が低い一方で準拠率が非常に高いことを指して、提供者が「確実に支えられる部分集合だけを実装する保守的な戦略」を採っていると読む¹。どのエンジンを選ぶかは、まだ設計判断として残っている。

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

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

論文の結論には、もう半分ある。同じ実験で、分類タスクでは形式制約が逆方向に働いた。ただし効き方は一様ではない。論文が「顕著」と書くのは診断選択の DDXPlus で Gemini 1.5 Flash が大きく伸びた一件で、他の分類データセットについては「競合的で、場合によっては上回る」とだけ述べている²。著者らが出した結論はタスク依存——推論には有害、分類には有益——であって、構造化出力の全面禁止ではない（抽出タスクはこの論文の対象外だ。並んだ四つはいずれも分類である）。パイプラインの工程を分類と推論に切り分けて読めば、この論文はそのまま掛け分けの指針になる。

ただし「厳しいほど落ちる」は、三方式の外側までは伸びない。同じ論文の後半は、gpt-4o-mini の Structured Output API——スキーマ準拠を100%保証する文脈自由文法方式で、三方式のどれより厳しい——を追試している。結果は GSM8K 91.71、Shuffle Objects 81.77、Last Letter 86.07 で、JSON-mode（86.95／76.43／76.00）を三つとも上回り、Last Letter では無制約の自然言語（83.11）すら超えた。論文自身が「これは先述の JSON-mode とは異なる」と注記している²。ただし論文はこの表に「3つの推論データセットのうち2つでは、無制約の自然言語がなお JSON-Schema をわずかに上回る」というキャプションを付けている——GSM8K は 94.57 対 91.71、Shuffle Objects は 82.85 対 81.77 だ²。崩れているのは三方式の内側での「厳しさ順＝劣化順」であって、無制約に対する優位ではない。制約は、順序が崩れてもなお水準のコストを払っている。

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

反論は、構造化生成ライブラリ 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 を提供する側が自社ブログに書いた再実験で、査読は通っていない。範囲も狭い——モデルは Llama-3-8B-instruct 一つ、Last Letter は150問で、信頼区間や複数シードの報告はない。GSM8K の差は1ポイントで、EMNLP 論文が9通りのプロンプトで測ったばらつきより小さい。向きを示す材料であって、大きさを主張できる材料ではない。

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

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

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

埋める手はある。同じ論文の AloLab は、ファインチューニングなしで、GSM8K の出力正解率84〜87%に到達した——ただしこの数字も、AloLab を作った当人たちが自社の道具で測ったものである（著者4名は全員 Alomana 所属で、論文は「we developed AloLab」と書く。利益相反の開示は論文に無い）。制約デコードが要する3.6〜8.2倍のレイテンシを払わずに、である⁴。ただし MATH では34〜40%にとどまり、こちらは落差が残る。この手も無条件ではない——最適化を回すメタエージェントに Claude Sonnet 4.5 を使っており、これを Claude 3 Haiku に置き換えると平均61.0%まで落ち、実行ごとの標準偏差が1ポイント未満から21.8ポイントへ跳ね上がる。詰められるかどうかは、最適化を回す側のモデルの力に依存する。

そしてこの0%は、小型モデル固有の現象ではない。同じ論文は GPT-4o も検証し、その REFERENCE プロンプトで出力正解率0%を報告している——JSON を Markdown のコードフェンスで包むためだ⁴。ただし GPT-4o の検証は GSM8K の一データセットに限られ、他のフロンティアモデルには及んでいない。

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

まず、自分が使っている仕組みがどちらなのかを確かめる。API の JSON-mode と、文法やスキーマで生成そのものを縛る制約デコードは、名前が近いだけで保証の強さが違う。スキーマ違反を絶対に流したくない工程なら、後者を選ぶ。ただし制約デコードは無料ではない。前掲の論文は、GSM8K で制約デコードの推論レイテンシが素朴なプロンプトの3.6〜8.2倍になり、しかもいくつかの設定ではタスク性能自体が大きく劣化したと測っている⁴。構文を必ず守らせる保証は、待ち時間と、場合によっては中身の質と引き換えになる。

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

スキーマの側にも同じ性質の落とし穴がある。EMNLP 論文は、GPT-3.5 Turbo の JSON-mode 応答の100%が answer キーを reason キーより先に置き、その結果、思考の連鎖が働かないまま直答になっていたと報告している²。推論を挟ませたいなら、推論のフィールドを答えのフィールドより前に置く。キーの並び順は、そのまま生成の順序を指示している。

分類の工程は、制約を第一候補にしてよい。査読付きの結果はこちら側に寄っている。ただし「どの分類でも上がる」ではない——論文が「顕著」と書けたのは49疾患から選ぶ DDXPlus の一件で、二択の Sports Understanding も5分類の MultiFin も「競合的」どまりだった。選択肢が明示されていれば伸びる、という線引きにはなっていない。ラベル集合や抽出フィールドをスキーマで固定すれば下流の後処理は消えるが、抽出は同論文が測っていない領域であり、効くかどうかは自分のタスクで一度は測る。

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

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

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

反証を出したのは、そのライブラリを提供している側だ。形式制約が推論を下げるという知見は EMNLP 2024 Industry Track の査読を通っているのに対し、.txt の反論は自社ブログで、査読を経ていない。三つの数字は、利害関係のある側が自社の道具で測ったものとして読む必要がある。

ただし反証は .txt だけではない。前掲の JSONSchemaBench は同じ三つのタスク（Last Letter・Shuffle Objects・GSM8K）を Llama-3.1-8B-Instruct で回し、制約デコードは無制約（LM only）を下回らなかったと報告している¹。ただし表を開くと、はっきり上回っているのは Guidance だけだ（Last Letter・Shuffle Objects で各 +3.3、GSM8K で +3.7）。他の三つは GSM8K でこそ +1.5〜+3.6 だが、Shuffle Objects では +0.1／±0.0／+0.4 とほぼ動かない——llama.cpp は 52.6% で LM only と同値である。しかも全実験が貪欲デコードの単一生成で、標準偏差の報告は無い。そして唯一大きく勝っている Guidance は、著者側のフレームワークだ。プロンプトとスキーマも .txt の設定に倣っている。∴ これは「.txt とは独立の再現」としては弱い。言えるのは、条件を揃えた別チームの測定でも制約デコードが無制約を目立って下回りはしなかった、までである。

出力正解率が0%まで落ちる現象は、小型モデルに限られない。同じ論文は GPT-4o でも同じ REFERENCE プロンプトで0%を実測している。ただしその検証は GSM8K 一本の追加確認であり、MATH や他のフロンティアモデルには及んでいない。落差が起きること自体は確かめられているが、フロンティア全体での頻度は分からない。

本稿は EMNLP 論文のベンチマーク別の低下幅を数値で並べていない。一次資料に無いからではなく——論文は9通りのプロンプトの平均と標準偏差つきで表を持っている——その標準偏差が差分と同じ桁で効いているからだ。二次的なブログが単一の下げ幅を切り出して流通させているのは、このばらつきを落とした引用にあたる。数値で言えることが一つある。LLaMA 3 8B の Last Letter では、パースの失敗率が0.148%しかないのに性能差は38.15%あった——つまり劣化はパースの失敗では説明できない、と論文自身が書いている²。

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