AI・信頼性・評価

LLMの構造化出力で精度は落ちる？分類と推論での使い分け

2026/7/29 （更新: 2026/11/3）

🤖 AIを使用して執筆

制約デコードの実装は同じベンチマークで比べられるようになった

制約デコード（constrained decoding）は、指定した型を生成の段階で守らせる方式で、生成の各ステップで文法やスキーマに合わない選択肢を選べないようにする。出てきた文字列を後から検証するのではなく、規則を外れた出力をそもそも生成させない。

この方式の実装は、同じベンチマークで比べられるようになった。JSONSchemaBench は、実世界から集めた1万件の JSON スキーマを公式の JSON Schema Test Suite と組み合わせたベンチマークだ。評価は三軸から行う。効率（制約を満たす出力をどれだけ効率よく生成できるか）、網羅（多様な制約の型をどこまで扱えるか）、品質（生成物そのものの良さ）である³。対象は Guidance、Outlines、llama.cpp、XGrammar、OpenAI、Gemini の6つで、自作ライブラリからクラウドAPIまでを含む。

比べた結果からは、どのエンジンを選ぶかがまだ設計判断として残っていることが分かる。著者らは、クラウドAPI側は実測での網羅が低い一方で準拠率が非常に高いことを指して、提供者が「確実に支えられる部分集合だけを実装する保守的な戦略」を採っていると読む³。効率の差も大きい。出力トークンあたりの時間は、Outlines が無制約の約2〜3倍かかる。著者には Guidance 側の研究者が含まれ、その Guidance は約0.4〜0.6倍で、無制約より速い³。

「厳しいほど落ちる」が成り立つのは三方式の中だけ

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

この傾向を測ったモデルの範囲は限られている。主実験に載ったモデルは Gemini 1.5 Flash・Claude 3 Haiku・GPT-3.5-Turbo・LLaMA 3 8B Instruct・Gemma 2 9B の5つで、費用の制約から LLaMA 70B や GPT-4o のような強いモデルを含められなかったことを、論文自身が限界に挙げている¹。付録では GPT-4o-mini と Mistral-7B にも形式指示の種類（自然言語・JSON・YAML・XML）を入れ替えて当てており、その図のキャプションは、GPT-4o（付録本文の表記では GPT-4o-mini-2024）は形式制約を足しても概ね一貫していると書く。これは形式指示の入れ替えであって、JSON-mode や制約デコードの比較ではない¹。

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

三方式より厳しい方式では、「厳しいほど落ちる」の順序が崩れた。同じ論文の後半は、gpt-4o-mini 一つで、その Structured Output API を追試している。この 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 だ。標準偏差は 3.95 と 0.68、5.67 と 6.86 で、本実験と同じ9通りのプロンプトの平均と読めるが、この節は試行数を明示していない¹。差は小さい。3タスクの平均では 0.33ポイントで、負けている2つの差（2.86／1.08）は論文が同じ表に併記した標準偏差（0.68〜6.86）と同じ桁である。

プロンプトを揃えた再実験では推論の差が縮んだ

反論は、構造化生成ライブラリ Outlines を開発する .txt から出た。Will Kurt は五点を挙げる。論文自身のデータが分類では構造化生成の勝ちを示していること。構造化条件と非構造化条件で異なるプロンプトが使われていたこと。構造化側のプロンプトに課題の情報が足りず、たとえば JSON 用のプロンプトは使うべきツールに触れていなかったこと。評価の要が、第二の LLM（claude-3-haiku）に答えを抜き出させる「Perfect Text Parser」にあること。そして構造化生成と JSON-mode を混同していることだ²。

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

.txt がプロンプトを揃えて三つの推論ベンチを回し直すと、結果は逆を向いた。GSM8K が0.77 → 0.78、Last Letter が0.73 → 0.77、Shuffle Object が0.41 → 0.44（非構造化 → 構造化）。三つとも構造化側がわずかに上回っている²。

ここでの「非構造化」は、前節の「無制約の自然言語」とは別物だ。両条件とも同じ JSON 要求プロンプトを使い、制約デコードを掛けるかどうかで分けている（.txt は Last Letter で自然言語のプロンプトも測っており、縛らない場合は0.65〜0.66、正規表現で縛ると0.68 で、どちらも JSON 側の0.73・0.77 に届いていない）。この条件の揃え方を確かめられるのは公開された再現ノートブックのほうで、ブログ本文が手順を書いているのは Last Letter だけだ。そのノートブックでは、三つのベンチとも出力長の制限方法も両条件で違う。非構造化側はトークン数の上限で、構造化側はスキーマの文字数上限で長さを抑えている。

この再実験は差の向きを示す材料であって、大きさを主張できる材料ではない。Outlines を提供する側が自社ブログに書いたもので、査読は通っていない。範囲も狭い。モデルは Llama-3-8B-instruct 一つ、Last Letter は150問で、信頼区間や複数シードの報告はない。GSM8K の差は1ポイントで、EMNLP 論文が報告する標準偏差より小さい。

JSONSchemaBench の著者らも、プロンプトの設計を .txt の設定に倣い、Llama-3.1-8B-Instruct で Last Letter・Shuffle Objects・GSM8K を回し直している。著者らはフレームワークによらず制約デコードが無制約を上回ったと書くが、表の値では Shuffle Objects で llama.cpp が無制約と同値（ともに52.6%）で、上回った幅も最大で4ポイントに満たない。全実験が貪欲デコードの単一生成で、分散は報告されていない³。

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

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

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

REFERENCE で0%になった2モデルの失敗は同じで、どちらも JSON を Markdown のコードフェンスで包んでいた。論文は表の脚注に、寛容なフォールバック・パーサを通せばタスク正解率が88.4%（Gemma 2-9B）・95.7%（GPT-4o）まで回収できると併記している⁴。厳密な契約の下では0点だが、崩れているのは推論ではなく出力の癖ひとつだ。付録の記録では、最適化ループが2巡目に書き足した出力形式の規則3行（生の JSON だけを出す・コードブロックで包まない・キーを二つに限る）だけで、検証セットの出力正解率が0%から約80%へ戻っている。ただし論文は、この癖はモデル固有で、観察せずに事前に書ける静的プロンプトの作者はいない、とも書き添えている。

制約デコードで構文を強制すれば、JSON として読めない応答は出なくなる。同じ論文の測定では、その代償は小さくない。論文は、vLLM の JSON 文法を掛けると GSM8K の推論レイテンシが素朴なプロンプトの3.6〜8.2倍になると本文に書く（Figure 2 では、Llama の REFERENCE＋制約デコードが約2.7倍の位置に載る）。

いくつかの設定では、制約デコードでタスク性能そのものが大きく落ちた。REFERENCE の手順の指示を残し、形式の指示だけを文法に任せた併用では、出力正解率が Qwen 2.5-7B で REFERENCE だけの74.3%から46.9%に、Llama 3.1-8B で44.4%から19.6%に落ちた。Gemma 2-9B は REFERENCE の出力正解率がコードフェンスで0%だったが、フォールバック・パーサで読めば中身は88.4%が正しかった。併用では出力正解率22.9%で、論文は Gemma についても、制約デコードは構文を守らせる代わりにタスク正解率を下げると書く。プロンプトの指示を付けずに制約デコードだけを掛けた条件では、Qwen が32.8%、Llama が52.5%だった（制約デコードを測ったのは小型の3モデル・GSM8K だけで、各条件1回の走行である）⁴。

制約デコードを使わずに落差を縮めた結果も、同じ論文にある。著者らの AloLab は、ファインチューニングなしで、GSM8K の出力正解率84〜87%に到達した。この数字も、AloLab を作った当人たちが自社のツールで測ったものである（著者4名は全員 Alomana 所属で、論文は「we developed AloLab」と書く）。AloLab は、制約デコードのこのレイテンシを払わずにこの数字に届いている⁴。

MATH では出力正解率が34〜40%だった。Llama と Gemma ではこの値が、素朴なプロンプトでの中身の正答率（4.1%・10.4%）も上回っている。中身の正答率を下回る落差が残ったのは Qwen で、論文はこの落差の一部を、形式を守らせたことでタスク正解率がわずかに下がる代償と読む（Qwen では REFERENCE の中身の正答47.5%に対し、AloLab の出力正解率は34.3%）⁴。この34.3%は5走行の平均である。うち2走行は答えの LaTeX を二重にエスケープしたためにパーサが読めず、中身の正答率は高いのに出力正解率がほぼ0だった。論文は、こうした走行が信頼区間を広げ、この落差に重なっているとも書く⁴。論文は MATH のコンテキスト長を全モデルで8,192トークンに固定しており、これが人為的な上限になりうるとも書く⁴。

AloLab の結果は、最適化を回す側のモデルに左右される。AloLab は最適化を回すメタエージェントに Claude Sonnet 4.5 を使っており、Llama 3.1-8B・GSM8K に限った置換実験（各5回）で Claude 3 Haiku に替えると、平均が84.2%から61.0%へ落ち、実行ごとの標準偏差が1ポイント未満から21.8ポイントへ跳ね上がる。落ち方は一様ではない。5回のうち3回は44〜45%で終わり、これは出発点である REFERENCE プロンプト（44.43%）と同じ水準である。論文は4エポックのうち検証セットで最良のチェックポイントを採用するので、途中で崩れた走行でも出発点より下には落ちない。残る2回は Sonnet の最良と同等の出力正解率に達している。弱いオプティマイザでも、ときには良いプロンプトを見つける。ただし、毎回は見つけられない。つまり、出力正解率を上げられるかどうかではなく、安定して上げられるかどうかが、最適化を回す側のモデルの力に懸かっている。

もっとも、ばらつきは最適化を回す側の強さだけで決まるのでもない。Sonnet のままでも Qwen の GSM8K は5走行のうち1走行がエポック2で JSON 出力が崩れ、REFERENCE と統計的に区別できないところで終わっている⁴。

そしてこの0%は、小型モデル固有の現象ではない。さきに挙げた2モデルのうち一方は、GPT-4o である⁴。論文はこの一致を「サイズ由来の限界ではなく、モデル固有の生成既定」の証拠として読み、同じ GPT-4o で AloLab を回すと95.2%（95%区間 94.8–95.6）まで戻ることも併せて報告している。この落差は GPT-4o でも小型モデルでも起き、どちらでもプロンプトの最適化で戻った。ただし GPT-4o の検証は GSM8K の一データセットに限られ、他のフロンティアモデルには及んでいない。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。