AI・信頼性・評価

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

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

🤖 AIを使用して執筆

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

構造化出力とは、JSON Schema のような型で出力の形を先に指定し、モデルの応答をその型で受け取ることを指す。その型を生成の段階で守らせにいくのが制約デコード（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（FRI）（プロンプトで形式を指示する）、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-mini について、形式制約を足しても非常に一貫していると書く。ただしこれは形式指示の入れ替えであって、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%である⁴。タスク正解率だけを見ているかぎり、この落差は計測に一切現れない。

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

制約デコードで構文を強制すれば、構文の側の落差は塞がる。ただし同じ論文の測定では、その代償も小さくない。論文は、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%にとどまり、こちらは落差が残る。論文はこの落差の一部を、形式を守らせたことでタスク正解率がわずかに下がる代償と読む（Qwen では REFERENCE の中身の正答47.5%に対し、AloLab の出力正解率は34.3%）⁴。論文は MATH のコンテキスト長を全モデルで8,192トークンに固定しており、これが人為的な上限になりうるとも書く⁴。

この手も無条件ではない。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 の検証は GSM8K の一データセットに限られ、他のフロンティアモデルには及んでいない。

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