構造化出力はLLMの推論を壊すのか？「structure tax」の正体と、精度を落とさないスキーマ設計

はじめに — 「JSONにすると賢さが落ちる」という現場の感覚

LLMを本番システムに組み込むとき、出力を自由文のまま受け取ることはほとんどありません。下流のプログラムが値を取り出せるように、あらかじめ決めた形式に従わせる必要があります。JSONスキーマやXMLタグのように、モデルの生成を特定の構文に縛る手法を**構造化出力（structured output）**と呼びます。関数呼び出し（tool calling）やエージェントのツール選択も、この仕組みの上に成り立っています。

ところが、この構造化を施した途端にモデルの答えが怪しくなる、という感覚が現場では広く共有されてきました。これは単なる印象ではありません。Tam et al. (2024) は「Let Me Speak Freely?」において、JSONやXMLで出力を制約するとLLMの推論能力が有意に低下し、制約が厳しいほど劣化が大きいと報告しています。この損失は、構造化という行為そのものに課される避けがたい代償——structure tax（構造化税）——だと考えられてきました。生成空間を狭めれば、モデルが本来使えたはずの推論の余地も削られてしまう、という説明です。

本記事で扱う論文「Structure Tax: How Structured Output affects LLMs Performance」（PayPal AI、AACL IJCNLP 2026採択）は、この前提を5モデル・4データセット・5形式の実験で再検証します。結論を先に述べると、精度低下の主因は「構造化するかどうか」ではなく、スキーマ内のフィールド順でした。

同じ問題・同じモデルでも、答えを書くフィールドが推論より前にあるか後にあるかだけで挙動が変わります。

差は小さくありません。多段推論が必要な算数文章題GSM8Kでは、同じXML形式でも answer-first はLlama-3.1-8BとGemma3-4Bの両方で10.98%まで落ちる一方、reasoning-first なら83〜87%を保ちます。つまり「構造化＝劣化」ではなく、順序を誤った構造化だけが劣化を招くのです。以降では、なぜフィールド順が効くのかというメカニズムから、タスクごとの影響の違い、内部表現で何が起きているか、そして今日から使えるスキーマ設計の指針までを順に見ていきます。

structure tax とは何か — 何が問題とされてきたのか

**構造化出力（structured output）とは、JSONスキーマやXMLタグのように、あらかじめ決めた形式に従ってモデルに生成させる手法を指します。自由文の応答はそのままでは下流のプログラムが値を取り出せないため、本番システムでは関数呼び出し（tool calling）やエージェントのツール選択をはじめ、ほぼ例外なくこの仕組みが使われます。しかし、構造化を施すとモデルの推論精度が落ちる、という経験則が長く共有されてきました。この損失を、構造化という行為そのものに課される避けがたい代償とみなしたのがstructure tax（構造化税）**という概念です。

この現象を体系的に報告したのが Tam et al. (2024) の「Let Me Speak Freely?」（EMNLP 2024 Industry Track）です。同研究は、JSONやXMLのような標準形式での構造化生成がLLMの推論能力を有意に低下させ、制約が厳しいほど劣化が大きいと報告しました。続く Long et al. (2025)（NAACL 2025）はこれを4カテゴリ・15形式・8タスクに拡張し、形式の違いがスコアを揺さぶる現象をフォーマットバイアスとして定量化しています。たとえばChatGPTにおいて、同じ内容を異なるラッピング形式で包んだときのスコア分散は235.33（%²）に達し、対策後は0.71まで縮小しました。

ただし、これら従来研究には共通の限界があります。各フォーマットを「原子的な選択肢」として扱い、どの形式を選ぶかだけを問うていた点です。JSONかXMLか、あるいは自由文か——選択肢のラベルと精度の対応は測られても、なぜ劣化するのかという因果メカニズムは示されていませんでした。形式は複数の設計変数の束であり、その内訳が不明なままでは「構造化は損か得か」という問いから抜け出せません。

本論文の着眼点は、この束を1本の軸に分解したことにあります。それが推論（reasoning）フィールドと答え（answer）フィールドの相対位置、すなわちフィールド順です。

他の設計変数（フィールド名、タグの種類、空白の入れ方など）と異なり、この軸だけは効果の向きを理論から予測できます。LLMは自己回帰（autoregressive）に生成するため、位置 t のトークンはそれより前に生成されたトークンだけを条件にできるという制約があるからです。下図は、同じ2フィールドでも生成順序が反転すると依存の向きが逆になることを示しています。

flowchart TB
    subgraph RA["reasoning-first（R,A）"]
        direction LR
        r1["推論トークン t1..tk"] -->|条件づけ| r2["答えトークン tk+1"]
    end
    subgraph AR["answer-first（A,R）"]
        direction LR
        a1["答えトークン t1"] -->|条件づけ| a2["推論トークン t2..tk+1"]
    end

(R,A) では、答えのトークンが十分に展開された思考連鎖に条件づけられます。一方 (A,R) では、推論が始まる前に答えが確定してしまうため、後続の推論はすでに決まった結論を正当化する役割しか果たせません。この非対称性は「chain-of-thought（CoT）を答えより先に書かせると精度が上がる」という既知の知見（Wei et al. 2022）と整合しますが、本論文の貢献はそれをプロンプトの工夫ではなく出力スキーマの設計変数として定式化した点にあります。以降の実験が示すとおり、形式感度の大部分は「構造化するか」ではなく、このフィールド順の一軸で説明できてしまいます。

なぜフィールド順が効くのか — 自己回帰生成の因果性という仕組み

LLMは自己回帰（autoregressive）生成を行います。トークンを1つずつ順番に出力し、次に出すトークンを「すでに生成し終えたトークン列」だけを条件に決める方式です。Transformerの内部ではこれを**因果マスク（causal mask）**で実現しており、位置 t のトークンは t より前の位置しか参照できません。まだ生成されていない未来のトークンは、そもそも存在しないので参照のしようがない。この一方向の依存関係が、出力スキーマのフィールド順を「見た目の好み」から「計算条件の設計」へと変えます。

reasoning-first（R,A）では、{"reasoning": ..., "answer": ...} の順に生成が進みます。答えのフィールドに到達した時点で、文脈には展開しきった推論トークン列がすでに並んでいます。答えのトークンは、その思考連鎖全体に条件づけられて初めて確定します。逆に answer-first（A,R）はこの依存関係を反転させます。{"answer": "D", "reasoning": ...} と書くとき、モデルは計算を一切行っていない段階で答えのトークンを出力しなければなりません。その後に続く推論フィールドに入る時点では、結論はすでに文脈上に固定されています。後続のトークンは因果マスク越しにその結論を参照できてしまうため、推論は「答えを導く計算」ではなく「確定済みの答えを正当化する文章」として生成されることになります。

flowchart TB
  subgraph RA["reasoning-first (R,A)"]
    direction LR
    R1["推論トークン列を生成"] --> A1["答えトークン<br/>推論全体に条件づけられる"]
  end
  subgraph AR["answer-first (A,R)"]
    direction LR
    A2["答えトークン<br/>計算前に確定"] --> R2["推論トークン列<br/>確定済みの結論を正当化"]
  end
  RA -.->|"順序の違いだけ"| AR

この非対称性は、既知の知見とも整合します。「推論を先に書かせると精度が上がる」という chain-of-thought（CoT）の効果（Wei et al. 2022）はまさにこの構造を利用したものです。本論文の貢献は、その効果をプロンプトの工夫としてではなく、出力スキーマの設計変数として定式化した点にあります。同じ問い・同じモデルでも、フィールドの並びを入れ替えるだけで答えトークンが条件にできる文脈が変わる、というわけです。

CoTの忠実性（faithfulness）研究（Lanham et al. 2023）を踏まえると、この仕組みがもつ含意はさらに明確になります。答えのトークンが推論より先に出力されている以上、その後に続くもっともらしい推論は、実際の計算過程の反映ではなく事後的な正当化でありえます。つまり（A,R）で観測される推論フィールドは、内容が正しく見えても、モデルが答えをどう決めたのかの証拠にはなりません。フィールド順は精度だけでなく、推論テキストの解釈可能性にも直接影響する設計判断だと言えます。

実験の設計 — 5モデル・4データセット・5形式

「構造化するかどうか」ではなく「どう構造化するか」が精度を左右する、という主張を検証するには、モデル・タスク・形式の3軸を系統的に振る必要があります。本論文はこれを、5モデル・4データセット・5形式の組み合わせで行いました。単一のプロバイダーや単一のタスクに依存しない設計が、結論の一般性を支えています。

5つのモデル — フロンティア3社とオープンウェイト2スケール

モデルは大きく2群に分かれます。1つ目はフロンティア（プロプライエタリ）モデルで、GPT-4o、Gemini-Flash-2.0、Claude-Sonnet-4.5の3社を横断します。特定のプロバイダーに偏った結果を避けるための選択です。2つ目はオープンウェイトモデルで、Llama-3.1-8B（隠れ次元 d=4096、33層）とGemma3-4B（d=2560、35層）の2つです。こちらは4Bと8Bという2つのスケール、かつ2つの異なるアーキテクチャ族を用意することで、後述する内部表現の分析（CKAや線形プローブ）を可能にし、そのパターンがモデル固有ではないことを確かめる役割を担います。

4つのデータセット — 「タスク内在構造」の連続体

データセットの選び方に、この研究の設計思想が最もよく表れています。4つは単なる「難しいタスクの寄せ集め」ではなく、タスク自身が持つ構造の強さという1本の軸に沿って並べられています。ここでいう「タスク内在構造」とは、出力形式とは無関係に、タスク自体が有効な答えに課す合成的・逐次的な制約の度合いです。

この連続体の狙いは明確です。もし「構造化の害」が構造そのものに由来するなら、すでに強い構造を持つSpiderでは害が大きく出るはずです。逆に、害が「スキーマが推論の順序を壊すこと」に由来するなら、自前の構造を持たないMMLUやLogicBenchでこそ、スキーマ設計の良し悪しが効いてくるはずです。この対比が、後続の結果セクションで「逆構造勾配」として結実します。なお、いずれも訓練データを使わないheld-out評価セットで、Spiderは1,030問（validation）、GSM8Kは1,319問（test）、MMLUは1,531問（validation）、LogicBenchは500問（eval）です。

5つの形式 — 順序と形式ファミリーを分離する

比較する出力条件は5つです。自由文のFree-formをベースラインに、JSONとXMLそれぞれについて**answer-first（A,R）とreasoning-first（R,A）**の2順序を用意しました。つまり Free-form、JSON(A,R)、JSON(R,A)、XML(A,R)、XML(R,A) の5条件です。システムプロンプト以外は全条件で固定されており、モデル固有のチューニングもありません。

この設計の要は、フィールド順（A,R か R,A か）と形式ファミリー（JSON か XML か）という2つの変数を分離した点にあります。従来研究は各形式を「原子的な選択肢」として扱い、JSONとXMLのどちらが良いかだけを問うていました。本論文はその中から「推論フィールドと答えフィールドの相対位置」という1軸を切り出し、性能差を「いつ答えにコミットするか」に帰属できるようにしたのです。

answer-first をわざわざ比較対象に含めた理由も論文は明示しています。第一に、開発者が人間のレビュアーに読みやすいから答えを根拠の前に置く、という本番で実際に起きるパターンを反映するため。第二に、効果の「向き」は直感的でも、その「大きさ」と「モデル依存性」は実測しないと分からないため。第三に、(A,R) を置くことで順序の効果を形式ファミリーの区別から切り離せるためです。

評価指標 — 精度・キャリブレーション・内部表現の3本柱

測定は3つの層で行われます。第一に精度で、GSM8K・MMLU・LogicBenchは完全一致率、Spiderは実行精度（Execution Accuracy、予測SQLの実行結果が参照クエリと一致するか）で評価します。第二にキャリブレーションで、モデルが申告する確信度と実際の正解率がどれだけ一致するかを、ECE（Expected Calibration Error、期待較正誤差）や過信率、confidence–correctness相関（ρ）で測ります。第三に内部表現で、CKA（Centered Kernel Alignment）による正解群と不正解群の隠れ状態の分離度と、線形プローブによる「答えの符号化」の検出を行います。

実験設定は厳格です。temperature=0、各条件5回実行して平均と標準偏差を報告し、スキーマ違反は全実験でゼロでした。プロンプトテンプレートは付録に全文掲載されており、事実上の再実装可能な成果物になっています。この「精度・較正・内部表現」という3層の同時測定こそ、単一の指標のアーティファクトではないことを示すための布石です。以降の結果セクションでは、この3層すべてに同じ「逆構造勾配」が現れることを見ていきます。

結果1：順序が精度を決める — reasoning-first は自由文に勝ち、answer-first は崩壊する

実験の中心となる発見は、精度を左右するのは形式（JSONかXMLか）でも「構造化したか否か」でもなく、推論フィールドと答えフィールドのどちらを先に置くかだという点です。ここで reasoning-first（R,A） は「推論→答え」の順、answer-first（A,R） は「答え→推論」の順を指します。両者は同じスキーマの要素を入れ替えただけであり、モデル・データセット・プロンプトはすべて固定されています。それにもかかわらず、精度には無視できない落差が生じます。

最も劇的な例が算数文章題のGSM8Kです。同じXML形式でも、answer-first の XML(A,R) はLlama-3.1-8BとGemma3-4Bの両方で**10.98%まで落ちます。一方、同じモデル・同じXMLで順序だけを reasoning-first に変えた XML(R,A) は83〜87%**を維持します。10%台と80%台という差は、表層的なゆらぎでは説明できません。順序という1つの設計変数が、事実上「解けるタスク」と「解けないタスク」を分けています。

（数値は5回実行の平均精度、単位は%。）

20あるモデル×データセットの組み合わせのうち13で、XML(R,A) か JSON(R,A) が最良形式となりました。重要なのは、answer-first が勝つタスクであっても reasoning-first は崩壊しないという非対称性です。つまり reasoning-first は「外れくじを引かない」選択であり、タスクやモデルを見極められない状況でも安全側に倒せる既定値になります。

同じ reasoning-first の順序の中でも、XMLがJSONを上回る場面があります。LogicBench の Claude-Sonnet-4.5 では最大12.2ポイントの差が付きました。タグの境界が「推論から答えへの切り替え」をより確実に足場づけるためと解釈されています。ただし、この形式間の差よりも順序の効果のほうがはるかに大きい点は強調しておくべきです。

順序への感度はモデルの規模にも依存します。Llama-3.1-8BとGemma3-4Bという小規模モデルは answer-first で最大の崩壊を示し、実行ごとのばらつきも大きくなりました。対してフロンティアモデルも順序には敏感ですが、破滅的な失敗はしません。4B〜8Bクラスを本番に置くなら、この順序の影響は特に注意して実測する必要があります。

結果2：タスクの構造が強いほど、形式の影響は小さい

フィールド順の効果は、どのタスクでも同じ大きさで現れるわけではありません。ここで効いてくるのが**タスク内在構造（task-intrinsic structure）**という考え方です。これは、出力形式に関係なく、タスク自体が有効な答えに課す合成的・逐次的な制約の度合いを指します。実験ではこの度合いを4段階の連続体として選んでいます。最も強いのがSpider（text-to-SQL）で、SQL文法が出力を厳密に縛ります。中間がGSM8K（算数の文章題）で、多段推論は必要ですが構文の強制はありません。最も弱いのがMMLU（57科目の知識問題）とLogicBench（論理推論）で、多肢選択という形式は外から与えられただけで、推論の道筋は自由です。

結果は明確な逆構造勾配を示しました。形式感度、つまりフィールド順を入れ替えたときの精度差は、タスク内在構造の強さと反比例します。以下はXML形式での (R,A) と (A,R) の精度差です（正ならreasoning-firstが優位）。

注目すべきはSpiderです。5モデル中3モデルで自由文が依然として競争力を持ち、XML(A,R) と XML(R,A) の差はほぼゼロか、わずかに逆転しています。SQL生成が自前の構造を持ち込むため、スキーマが上乗せできる足場がほとんど残っていない、という解釈です。逆に、答えの正しさを検証できる連鎖を持たない知識QAや論理推論では、出力形式が熟慮の順序を決める唯一の手がかりになるため、設計の効果が大きく出ます。

graph LR
  A["Spider（高構造）<br/>SQL文法が足場を提供<br/>→ 順序の影響はほぼ無視できる"] --> B["GSM8K（中間）<br/>多段推論はあるが構文強制なし<br/>→ 順序の影響が最大"]
  B --> C["MMLU / LogicBench（低構造）<br/>推論経路が自由<br/>→ 順序の影響が中程度"]

実務的な含意は明快です。text-to-SQLのように出力言語そのものが合成制約を持つタスクでは、フィールド順の設計にコストをかけても回収は小さい。一方で、知識QAや論理推論のように自由度の高いタスクでは、同じ設計変更が数十ポイントの差を生みます。限られた設計工数をどこに投じるかを判断する材料として、この勾配は使えます。

結果3：表面プロンプトを変えても順序効果は消えない

フィールド順の効果が本物だとしても、それが単なる「プロンプトの書き方」の産物なら設計指針には使えない。そこで論文は、表層的なプロンプト摂動に対する頑健性を確かめている。

ここでいう**プロンプト脆性（prompt brittleness）**とは、意味的に無関係な表層の違い——区切り文字、大文字小文字、空白の数——だけでモデルの精度が大きく揺れる現象を指す。過去の研究では、テンプレートを変えるだけで40ポイント規模の変動が報告されており、順序効果も同じ種類のノイズではないかという懸念があった。

検証はGSM8K（小学校算数の文章題）で、Llama-3.1-8BとGPT-4oの2モデルを使い、モデル・データセット・フィールド順を固定したうえでシステムプロンプトの表層だけを3通りに摂動させて行われた。

• V1：指示文の言い換え（スキーマ定義はバイト単位で同一）
• V2：スキーマ名のPascalCase化（XMLタグやJSONキーの大小文字を変更）
• V3：空白の増減（空行の削除、スキーマ定義の1行圧縮）

GSM8Kの精度（%）をベースラインと3変種で並べると次のようになる。

結果は明確である。全24組み合わせ（2モデル × 4つの順序付き形式 × 3変種）で、(R,A) > (A,R) の符号が保存された。表層をいくら揺らしても順序の優劣が反転することはない。最小の差でも+37ポイント（GPT-4oのJSON、ベースライン）に達する。一方、同一セル内での表層摂動による変動幅は最大11.5ポイント（Llama-3.1-8BのJSON(R,A)）にとどまり、大半のセルは5ポイント未満だった。

つまり順序効果の大きさ（37〜70ポイント超）は、表層摂動の揺らぎ（多くは5ポイント未満）を一桁上回る。この差は、両者が質的に異なる現象であることを示している。プロンプト脆性は効果の向きが事前に予測できない経験的なノイズだが、フィールド順の効果は自己回帰生成の因果性という仕組みから向きが実験前に予測できる構造に根ざした効果である。したがって「プロンプトの言い回しを工夫すれば順序の問題は解決する」という期待は成り立たない。まずフィールド順そのものを直すことが、表層の調整よりはるかに大きな回収をもたらす。

結果4：構造化はキャリブレーションも改善する

精度が同じでも、モデルが「どれくらい自信があるか」の申告が当てにならなければ、本番での閾値判断や人間へのエスカレーションは機能しません。そこで論文は、キャリブレーション（calibration）——申告した確信度と実際の正解率がどれだけ一致しているか——も形式ごとに測定しています。指標は**ECE（Expected Calibration Error、期待較正誤差）**です。確信度を10個の等幅ビンに分け、各ビンで「平均確信度」と「実際の正解率」の差を、そのビンのサンプル数で重み付けして平均した値で、0に近いほど確信度が実力と一致しています。

実験では1〜10の口頭確信度を申告させ、ΔECE = ECE_freeform − ECE_XML を計算します。正なら「自由文のほうが較正が悪い（XMLのほうが良い）」という意味です。

結果のパターンは精度とほぼ同じで、タスクの内在構造の強さと反比例します。LogicBenchでは全モデルでXMLが改善し、MMLUでは5モデル中4モデルで改善（例外はGPT-4oで、自由文がわずかに良い較正）、GSM8Kはほぼ形式不変、Spiderは自由文が有利なモデルもありました。算数は自前の検証可能な連鎖が、SQLは自前の合成構造が、それぞれ確信度を導く材料になるため、外から与えるスキーマの上乗せ余地が小さいと解釈できます。

XML条件のECE絶対値を並べると、タスク間の差がはっきり出ます。

最も良いのはGSM8K（Claude-Sonnet-4.5で0.020）、最も悪いのはSpider（Gemma3-4Bで0.283）です。ただし限界もあります。**confidence–correctness相関（ρ）**は全条件で低いままで、XMLは「集計レベル」の較正を改善するものの、個々の例で正解・不正解を言い当てる識別力は限定的でした。

もう一つの重要な発見は、口頭確信度とトークンレベルのロジット確率の乖離です。GPT-4oでは両者が中程度に相関し（MMLUでrs=0.44、LogicBenchで0.67、平均KLは約0.5）、口頭スコアが内部確率を部分的に反映します。一方Llama-3.1-8BはMMLUでほぼ無相関（rs=−0.05、p>0.05、KL=3.62）で、口頭確信度が内部確率から切り離されています。Gemma3-4Bはさらに極端で、ロジットのECE（0.402）が口頭のECE（0.212）よりはるかに悪く、ロジットは較正された不確実性ではなくトークン分布に支配されていました。

実務的な含意は明確です。スキーマに確信度フィールドを入れるなら、小規模モデルの口頭スコアは「内部不確実性の正直な反映」ではなく「タスク条件付きのヒューリスティック」として扱い、ロジットが取得できるなら併用して検証すべきです。

結果5：内部では何が起きているのか — 表現の分離と答えの符号化

精度と較正の差は、モデル内部の計算のどこに現れるのか。論文は2つの道具でこれを追跡する。1つ目はCKA（Centered Kernel Alignment）。正解した問題と不正解した問題の隠れ状態が、層ごとにどれだけ幾何的に異なるかを測る指標で、値が低いほど「正しい／誤っている」の表現が分離していることを意味する。2つ目は線形プローブ。答えの文字を生成する直前の隠れ状態から、モデルが選んだ答えを線形分類器で復元できるかを調べる。

CKAの結果は精度の結果と見事に一致した。MMLUでは自由文のクロスグループCKAが序盤から上昇し続ける一方、XML(R,A)は中間層で0.15未満に抑えられる。つまり、出力スキーマが熟慮を強制したときだけ、モデルは正誤を分ける表現を構築する。LogicBenchも同様の緩やかなパターン、GSM8Kはほぼ同等。そしてSpiderだけが逆転し、自由文のほうが低いCKAを示す。この向きは4タスクすべてで精度効果の向きを正しく予測した。SpiderはXMLが精度を下げる唯一のタスクであり、CKA比がパリティを下回る唯一のタスクでもある。

線形プローブはさらに踏み込んだ事実を明かす。(R,A)では中間層以降で答えの正体が線形に復元できる（MMLUのL19でbalanced accuracy 0.64、LogicBenchのL18で0.70）。ところが(A,R)では早期・中間層でほぼチャンスレベルに停滞する。答えは出力列には存在するのに、推論フェーズのあいだモデルは「自分がどの答えを選んだか」の表現を構築していないのだ。

flowchart LR
    A["(R,A) 推論→答え"] --> B["中間層で答えが線形に復元可能<br/>MMLU L19: 0.64 / LogicBench L18: 0.70"]
    C["(A,R) 答え→推論"] --> D["早期・中間層でチャンスレベル<br/>答えは出力にあるが内部表現にない"]

この結果が示すのは、答えのフィールドが先頭にあると、モデルは明示的な推論を経ずに答えの文字を出してしまうということだ。コミットが熟慮に先行する。なお、このパターンはGemma3-4Bでも同じ向きで再現され（MMLU L17で+0.27、LogicBench L13で+0.26）、特定モデル固有の現象ではない。ただしXMLは熟慮の順序を強制できても、モデルがそもそも持っていない事実を供給することはできない。MMLUで自由文の表現抑制が最大なのに精度向上が控えめなのは、その限界を示している。

2つの失敗モード — 「もっともらしい言い訳」と「早すぎる決断」

answer-first (A,R) のスキーマで精度が落ちるといっても、その壊れ方は一様ではありません。推論フィールドの語数を測ると、質的に異なる2種類の失敗が浮かび上がります。診断のしかたもそれぞれ違うため、実務では両者を区別して監視する必要があります。

失敗モード1：合理化（rationalization）

多肢選択タスクで起きます。答えのトークンを先に確定させると、後続の推論フィールドが collapse し、熟慮ではなく簡潔な事後正当化へと圧縮されます。MMLUの推論フィールドの語数中央値（5モデル集計）は、XML(R,A)の121語に対してJSON(A,R)は33語——およそ4分の1です。モデルは「もっともらしい言い訳」を短く添えているだけで、選択そのものを計算し直してはいません。

失敗モード2：早すぎるコミット（premature commitment）

算数タスクで起きます。GSM8Kでは推論長が4つの順序すべてでほぼ一定（108〜127語）なのに、精度は(R,A)の0.92からJSON(A,R)の0.55へ落ちます。同じだけ書いているのに答えが誤るのは、答えを決めるはずの計算が、すでに確定した答えを正当化する方向に縛られるからです。自己回帰生成の因果性により、先に出力された答えトークンは後から修正できません。

（推論フィールドの語数中央値、5モデル集計）

推論長だけでは精度を予測できません。80セル全体の相関はr=+0.04とほぼ無相関で、有意なのはJSON(A,R)のr=−0.73（p<0.001）だけです。これは「JSON(A,R)が圧縮しないセル（GSM8K、Spider）こそ精度が最悪」という逆説を反映しています。コミット後の冗長な推論は、コミット後の圧縮された推論より悪いのです。順序が、努力が決定の前にあるか後にあるかを決めます。

監査のしかた

flowchart TD
    A["出力を収集"] --> B{"推論フィールドが<br/>reasoning-first 比で急減？"}
    B -- "はい（例: 121語→33語）" --> C["合理化の疑い<br/>事後正当化に圧縮されている"]
    B -- "いいえ（長さ維持）" --> D{"推論が確定済みの答えと<br/>意味的に整合？"}
    D -- "いいえ" --> E["早すぎるコミットの疑い<br/>計算が答えに縛られている"]
    D -- "はい" --> F["順序の影響は小さい"]

合理化は出力長だけで検出しやすい一方、早すぎるコミットは推論長が保たれるため検出が難しい。構造化パイプラインを監査するときは、推論フィールドの量と、確定した答えとの意味的な整合性の両方を見るのが確実です。

どう使うか — 精度を保つスキーマ設計の実務指針

ここまでの結果を、そのまま現場のスキーマ設計に落とし込みます。結論はシンプルで、推論（reasoning）フィールドを答え（answer）フィールドより前に置く。この一点を守るだけで、精度・キャリブレーション・内部表現のすべてが改善方向に動きます。以下、6つの原則として整理します。

原則1：推論フィールドは常に答えより前

// 良い例：推論が先、答えが後
{"reasoning": "...", "answer": "D"}

<reasoning>...</reasoning>
<answer>D</answer>

逆に {"answer": "D", "reasoning": "..."} の順にすると、答えのトークンが推論より先に確定し、以後の推論は結論を正当化するだけになります。GSM8Kでは同じXML形式でも順序だけで10.98%対83〜87%という差が出ました。

原則2：迷ったら reasoning-first の XML を既定にする

同一の reasoning-first 条件ではXMLがJSONを上回る場面があり、LogicBench／Claude-Sonnet-4.5では最大12.2ポイント差でした。タグ境界が「推論から答えへの切り替え」を確実に足場づけるためと解釈されています。順序の効果のほうが形式差よりはるかに大きいので、まず順序を直し、そのうえで既定をXMLに置くのが安全です。

原則3：タスクの構造密度で投資判断を変える

形式感度はタスク自身が持つ構造制約と反比例します。text-to-SQL（Spider）では5モデル中3モデルで自由文が依然競争力を持ち、順序設計の回収は小さい。逆に知識QA（MMLU）や論理推論（LogicBench）のような自由度の高いタスクでこそ効果が最大になります。

原則4：小規模モデルを本番に置くなら順序の影響を必ず実測する

フロンティアモデルは順序に敏感でも破滅的にはなりませんが、Llama-3.1-8BやGemma3-4Bのような4B〜8Bクラスはanswer-firstで崩壊し、実行間の分散も大きくなります。自環境のモデルとデータで計測するのが確実です。

原則5：既存スキーマを監査する

人間のレビュアーが読みやすい順序は、生成にとって最悪の順序であることが多い。{"answer": ..., "rationale": ...} のようになっていないか確認し、答えを末尾へ移すだけで改善が見込めます。監査では次の2点を同時に監視します。

原則6：確信度フィールドは小規模モデルで過信しない

口頭の確信度スコアをスキーマに含める場合、小規模モデルの数値は内部不確実性の代理として信頼できません（Llama-3.1-8BはMMLUでロジットとの相関rs=−0.05）。ロジットが取れるなら両者を比較して検証します。

さらに粒度を上げる余地

推論→答えの二分割は出発点にすぎません。計画・中間ステップ・検証を分けたスキーマにすると、生成順序がより丁寧に保存されます。

flowchart LR
    A[planning<br/>方針の言語化] --> B[intermediate steps<br/>計算・根拠]
    B --> C[verification<br/>答えの再確認]
    C --> D[answer<br/>最終回答]

各フィールドが前段に条件づけられる限り、この並びは自己回帰生成の因果性と一致します。ただし粒度を上げるほどトークン消費とレイテンシも増えるため、低構造タスク（知識QA・論理推論）から段階的に導入するのが現実的です。

この研究が変える問い — 「構造化するか」から「どう構造化するか」へ

論文の中心的な言明は明快です。構造化出力に帰属されてきた「structure tax（構造化税）」は、構造そのものの代償ではなく、answer-first というフィールド順の設計選択の産物である、というものです。これは単一の指標のアーティファクトではありません。精度（タスク正解率）、キャリブレーション（ECE・過信率・confidence–correctness相関）、隠れ状態の幾何（CKA・線形プローブ）という3つの異なる分析レベルで、同じ「逆構造勾配」——タスクの内在構造が弱いほどフィールド順の影響が大きい——が再現されました。4タスクすべてでCKA効果の向きが精度効果の向きを正しく予測し、SpiderはXMLが精度を下げる唯一のタスクであり、同時にCKA比がパリティを下回る唯一のタスクでもありました。行動レベルの数値と内部表現の変化が同じ方向を指していることが、この結論の重みを支えています。

実務への転換点はここにあります。これまでスキーマ設計は「下流システムがパースできるか」「人間のレビュアーが読みやすいか」という基準で評価されることがほとんどでした。本論文以降、そこに「モデルの推論を保存できるか」という第3の基準が加わります。フィールド順は、読みやすさの最適化と生成順序の最適化が衝突する典型例であり、迷ったときには後者を優先すべき設計変数です。この2つの問いの違いを整理すると次のようになります。

graph LR
  subgraph Old["従来の問い: whether to structure"]
    O1["構造化するか / 自由文のままか"]
    O2["どの形式を選ぶか (JSON vs XML)"]
  end
  subgraph New["本論文の問い: how to structure"]
    N1["フィールド順<br/>(reasoning-first / answer-first)"]
    N2["構造の粒度<br/>(planning / steps / verification)"]
    N3["タスク構造との一致<br/>(高構造タスクでは投資を抑える)"]
  end
  Old -->|問いの移動| New

問いが移ったことで、エンジニアが最初に手を入れるべき箇所も変わります。形式の選択や下流パーサの実装よりも前に、まずスキーマのフィールド順を確認する、という順序です。

ただし、この研究がすべてを解き明かしたわけではありません。論文自身が限界として挙げる点は、次の実務判断に直結します。

• 構造密度の「スイートスポット」は未確定です。4データセットはタスク内在構造の連続体上の粗い4点にすぎず、単一のタスク族内で制約密度を系統的に振る実験が求められます。
• 表現分析はLlama-3.1-8BとGemma3-4Bの2モデルに限られ、スケールやアーキテクチャをまたいだ一般性は未検証です。
• 比較したのは「推論が先」と「答えが先」の2つの順序のみです。実務のスキーマはplanning、intermediate steps、verificationなどより細かい構造を持ち、二値の順序を超えた粒度の効果は未解明です。
• すべてプロンプトによる実験であり、構造化形式でのファインチューニングが同じ表現幾何を生むかは不明です。

問いは「構造化するか」から「どう構造化するか」へ移りました。そして現時点で最も確実な「どう」の中身は、推論フィールドを答えフィールドより前に置くという一行の変更から始まります。

よくある質問

構造化出力を使うと本当に精度が落ちるのですか？

落ちるかどうかはスキーマの設計次第です。同じモデル・同じデータセットでも、推論を先に書く reasoning-first (R,A) なら自由文と同等以上、答えを先に書く answer-first (A,R) なら推論タスクで急落します。たとえば多段推論が必要な算数文章題GSM8Kでは、同じXML形式でも Llama-3.1-8B と Gemma3-4B の両方が answer-first で 10.98% まで落ちる一方、reasoning-first なら 83〜87% を保ちます。つまり「構造化するかどうか」ではなく「どう構造化するか」が精度を決めており、構造化すること自体が劣化を招くわけではありません。

なぜフィールドの順序だけでそんなに変わるのですか？

LLMは自己回帰（autoregressive）に生成するため、位置 t のトークンはそれより前に生成されたトークンしか参照できません。答えのトークンを推論より先に確定してしまうと、後から書かれる推論はその結論を正当化することしかできず、計算によって答えを導く経路が失われます。逆に推論を先に置けば、答えのトークンは十分に展開された思考連鎖（chain-of-thought）に条件づけられます。この非対称性は、推論を経て答えを出す自然な生成順序と、フィールド順が一致しているかどうかの問題だと言えます。

JSONとXMLのどちらを使うべきですか？

同じ reasoning-first の順序であれば、XMLがJSONを上回る場面があります。たとえば LogicBench と Claude-Sonnet-4.5 の組み合わせでは最大12.2ポイントの差が確認されており、タグ境界が「推論から答えへの切り替え」をより確実に足場づけるためと解釈されています。ただし順序による効果のほうがはるかに大きいため、まずフィールド順を直すのが優先です。論文が推奨する既定は reasoning-first XML で、構造が効くタスクでは損をせず、効かないタスクでも精度と較正を保ち、下流のパース性も犠牲にしません。

既存の本番スキーマはどう直せばいいですか？

まず {"answer": ..., "rationale": ...} のように答えが先頭に来ていないかを確認します。人間のレビュアーにとって読みやすい順序は、生成にとって最悪の順序であることが多いためです。答えのフィールドを末尾に移し、推論を先頭に置くだけで改善が見込めます。監査ではさらに、推論フィールドの語数が急減していないか（合理化のシグナル）と、推論内容が宣言された答えと意味的に整合しているか（早すぎるコミットのシグナル）の両方を確認すると、失敗の種類まで切り分けられます。

小規模モデルでも同じ指針が当てはまりますか？

当てはまりますが、影響はより深刻です。Llama-3.1-8B と Gemma3-4B は answer-first で最大の崩壊と大きな実行間分散を示した一方、フロンティアモデルは順序に敏感でも破滅的な失敗はしませんでした。4B〜8Bクラスを本番に置くなら、reasoning-first の徹底と自環境での実測が特に重要になります。なお、小規模モデルでは口頭の確信度が内部の不確実性とほとんど連動しない（Llama-3.1-8B は MMLU でロジットとの相関 rs=−0.05）ため、申告された確信度の数値もそのままは信頼しないでください。

まとめ

「構造化出力にするとLLMの精度が落ちる」という経験則は、長らく構造化そのものの代償——structure tax（構造化税）——だと説明されてきました。しかし5モデル・4データセット・5形式を比較した検証は、この説明が成り立たないことを示しています。同じモデル・同じXMLでも、推論を先に書く reasoning-first (R,A) ならGSM8Kで83〜87%を保つのに対し、答えを先に書く answer-first (A,R) ではLlama-3.1-8BとGemma3-4Bがともに10.98%まで落ちます。精度を分けているのは構造化の有無ではなく、スキーマ内のフィールド順です。

この順序効果は、単一の指標に見かけ上現れた差ではありません。精度、キャリブレーション（ECE）、隠れ状態の幾何という3つの分析レベルで、同じ向きの効果が再現されました。線形プローブでは、(R,A)は中間層以降で答えの正体が線形に復元できる（MMLUのL19でbalanced accuracy 0.64）一方、(A,R)はチャンスレベルに停滞します。答えのトークンを先に確定してしまうと、モデルは推論フェーズのあいだ「自分がどの答えを選んだか」の表現を構築しない、という計算上の説明が付きます。

効果の大きさはタスクの内在構造に依存します。多段推論が必要でも構文強制のないGSM8Kで差は最大になり、出力言語自体が合成制約を持つtext-to-SQL（Spider）では順序の影響はほとんど消えます。形式への感度は、タスク自身が持つ構造の強さと逆相関する、という整理です。

失敗の仕方も一様ではありません。多肢選択では推論が短い事後正当化へ圧縮される合理化が起き（MMLUでJSON(A,R)は33語、XML(R,A)は121語）、算数では推論長が108〜127語でほぼ一定のまま答えだけを誤る早すぎるコミットが起きます。前者は推論フィールドの語数から検出できますが、後者は語数が保たれるため、宣言された答えと推論内容が意味的に整合しているかまで確認する必要があります。

問いは「構造化するか」から「どう構造化するか」へ移りました。推論フィールドを答えより前に置く reasoning-first を既定に据え、既存スキーマに {"answer": ..., "rationale": ...} のような順序が残っていないか見直し、推論の量と答えとの整合性の両方を監視する。それが今日から取れる、最も確実な一手です。

参考資料

• Structure Tax: How Structured Output affects LLMs Performance（Vineet Kumar, Kanishka, Bhuvanesh Mandora / PayPal AI）— https://arxiv.org/abs/2610.12056
• Tam et al. (2024) "Let Me Speak Freely? A Study On The Impact Of Format Restrictions On Large Language Model Performance." EMNLP 2024 Industry Track — https://aclanthology.org/2024.emnlp-industry.91/
• Long et al. (2025) "LLMs Are Biased Towards Output Formats! Systematically Evaluating and Mitigating Output Format Bias of LLMs" NAACL 2025 — https://aclanthology.org/2025.naacl-long.15/
• Lanham et al. (2023) "Measuring Faithfulness in Chain-of-Thought Reasoning" — https://arxiv.org/abs/2307.13702

関連記事

• 推論トークンは本当に元を取れるのか？——LLMの「考えるコスト」を測る Token Economy Score（TES）
• LLM評価は「測るたびに揺れる」——事前登録された5万件の監査が暴いた、LLMジャッジの計測としての脆さ
• LLMデコンパイラは「コンパイルが通る」ほど正しくない——再コンパイル可能性が隠す挙動乖離と、脆弱性が「消える」問題