入力側で観測された差#

同じ内容のプロンプトをPlain Text / Markdown / JSON / YAMLで書き分けて比較した研究では、GPT-3.5-turboのコード翻訳タスクで最大40%の性能差が出た^1。GPT-4はフォーマット変更に対してより頑健だったが、それでもゼロではない。

同じ論文の中に、個人的に一番ぎょっとした数字がある。HumanEvalで、GPT-4 (32k) のプロンプトをJSONからPlain Textに変えたら300%以上の性能向上が出たという報告だ^1。コードを書かせるタスクだからプロンプトも構造化しておいたほうがいいだろう、という直感が、まるごと裏切られている。

オープンソースモデルではもっと極端で、LLaMA-2-13Bにおいて意味的に等価なフォーマット間で最大76ポイントの精度差が観測されている^2。しかもこの感度は、モデルサイズを増やしても、few-shotの例を足しても、instruction tuningをかけても解消されなかった。

さらに厄介なのが、モデル間でフォーマット性能の相関が弱いという指摘である^2。あるモデルで最適だったフォーマットが、別のモデルでも最適とは限らない。つまりフォーマットのチューニングは、モデルを乗り換えた瞬間に賞味期限が切れる可能性がある。

出力側で観測された差：Format Tax#

出力を構造化させると推論能力が落ちる、という現象はFormat Tax（フォーマット税）と呼ばれている。

これを実証的に示した先駆的な研究がGSM8K（小学生レベルの算数文章題）での比較で、数字はこうだ^9。

Claude-3-Haikuの86.5%→23.4%は、もはや別のモデルである。JSONで返してくれと頼んだだけで、算数が解けなくなっている。

同じ研究の中で、もうひとつ重要な非対称性が報告されている。分類タスクでは逆にフォーマット制約で精度が上がる^9。回答空間が制限されるぶん、余計なことを言わなくなるからだ。つまりFormat Taxは全タスク一律にかかる税ではなく、推論を要求するタスクに選択的にかかる。

原因の切り分けも進んでいて、劣化の主因はconstrained decodingではなくプロンプトレベルにあることが分かっている^8。デコード時に文法で縛ることそのものよりも、「JSONで出力せよ」という指示をプロンプトに含めること自体が精度低下の大部分を生んでいる。

フロンティアモデルではほぼ解消されている#

Format Taxを体系的に測り直した研究では、最新のクローズドモデルではほぼ劣化なしという結論が出ている^8。テストした全オープンウェイトモデルでは劣化が確認されたのに対し、GPT-4oやClaudeといったAPIモデルでは差がほとんど観測されなかった。

因果推論を使ってフォーマットの影響を分解した別の研究でも、GPT-4oは48ケース中43ケースで構造化出力に非感受性、GPT-4.1も同傾向、そしてOpenAI o3は全設定で耐性ありという結果が出ている^11。推論集約型のモデルは、内部でCoTを回すぶん構造化制約を吸収できる、という解釈になる。

なぜ解消されたのか：キャパシティの問題#

この現象をきれいに説明しているのが、Format Taxの本質はモデルの余剰キャパシティにある、という再解釈だ^10。

読み方はこうなる。フォーマットへの準拠は、それ自体が計算資源を食う作業である。タスクがモデルの能力限界から遠いところにあれば、余った資源で整形を済ませられるので何も起きない。タスクが限界ギリギリなら、整形に回した資源のぶんだけ推論が痩せる。

だからモデルが強いかどうかではなく、そのモデルにとってそのタスクが難しいかどうかが効く。フロンティアモデルのOpus 4.7でさえ、AIMEのような限界域のタスクではしっかり5ポイント落ちている^10。

そして対策も同じ研究から出ている。先に自由形式で推論させ、後からフォーマットに流し込む（delayed-structure ablation）だけで、劣化の80〜87%が回復する^10。これは前述の「劣化の主因はプロンプトレベル」という知見^8とも整合的で、要するに推論しているあいだ整形のことを考えさせなければいい、という話に尽きる。

問題そのものが溶けつつある#

ここは調べていて素直におもしろかったところなので、少し書いておきたい。

2024年の論文は、JSONで返させると算数が解けなくなるという話をしていた。86.5%が23.4%である。当時これは間違いなく実在する問題で、フォーマットの選択は性能を引き出すための技術だった。

それが2年で、48ケース中43ケースで差がない^11 になった。o3に至っては全設定で耐性ありである^11。

つまりモデルが強くなったことで、問題設定のほうが消えかけている。かつては「どの形式なら賢く振る舞うか」を探る必要があったのに、いまは「どれでもだいたい同じように動く」。フォーマットのチューニングという工夫が、モデルの進化に吸収されて不要になっていく過程を、ここ2年ぶんの論文を並べるとそのまま観測できる。

これはプロンプトエンジニアリング全般で起きていることの縮図でもあると思っていて、去年まで必須だったテクニックが、今年はモデルの標準装備になっているという現象が、フォーマットという小さな窓からきれいに見えている。工夫が要らなくなるのは寂しくもあるが、悩まなくていいことが増えるのは端的にいいことだ。

ただしここで溶けたのは精度の軸だけである。もうひとつの軸、つまりトークン効率のほうはまったく溶けていない。JSONはいまでもTOONの1.66倍のトークンを食う^6し、それはモデルが賢くなっても1バイトも減らない。精度は収束したが、コストは収束していない。 だから2026年にフォーマットを選ぶ理由は、賢さから金と設計のほうへ完全に移っている。

つまり2026年時点の実務的な立場としては、フロンティアモデルを使う前提なら、フォーマット選択を精度の問題として悩む必要はほぼない。悩むべきは別の軸である。それが次の話になる。

入力の第一原則：XMLタグで区切る#

Anthropicの公式ドキュメントが強く推奨しているのがXMLタグによる構造化で、ClaudeはXMLタグをセマンティックな境界として認識するよう調整されている^3 ^4。OpenAIの公式ガイダンスでも、Markdownの見出しやリストとXMLタグを組み合わせてセクションを明示することが推奨されている^5。

効果としては、マルチステップ推論での精度向上、リトライ間の一貫性の改善、指定フォーマットへの準拠率の向上などが報告されている^3。

ただし正直に書いておくと、この効果について流通している定量値（+20〜40%といった数字）は、Anthropicの査読付き論文として公表されたものではない。第三者記事が内部ベンチマークとして引用しているものが多く、厳密な再現性は確認できていない。公式ドキュメントで推奨されているという事実と、定量的な効果量が検証済みであるという話は、分けて受け取ったほうがいい。

XMLタグを使う目安はシンプルで、プロンプトに3つ以上の異なる構成要素があるときだ^3。指示・コンテキスト・例・出力形式が混ざり始めたら、区切ったほうがいい。

入力の第二原則：大量データにJSONを使わない#

これは筆者の「なんとなくJSON」を直接殴ってくる知見だった。

LLMへの入力としてJSONは冗長すぎる。引用符とブラケットとキーの繰り返しが、そのままトークンを食う。

2025年に登場したTOON（Token-Oriented Object Notation）という入力特化のシリアライゼーション形式のベンチマークが分かりやすい^6。

JSONに対して約40%のトークン削減をしながら、精度は落ちていない。均一なオブジェクト配列（DBの出力や分析データ）では最大60%削減される。

ただしこれは開発者自身によるベンチマークで、第三者の独立検証はまだ限定的である。数字を鵜呑みにするより、JSONが入力として非効率であるという方向性を受け取るのが正しい読み方だと思う。実際、大規模なエビデンス入力を扱うワークフローの比較でも、Raw JSONを基準にコンパクト形式が入力サイズを0.25〜0.40倍に圧縮しつつ精度・引用・長さ制御すべてで上回った、という報告がある^7。

そこでの提言が端的で、JSONはAPI境界（出力側）に使うべきであって、入力に使うものではない^7。

補足として、深いネスト構造ではJSONのほうが適切という但し書きもついている^6。表になるデータはコンパクト形式、階層が深いデータはJSON、という切り分けになる。

入力側のまとめ#

1. 下流のコードがパースする → JSON#

システムに組み込む、つまり出力を次の処理に食わせるなら、JSONで確定していい。

ただし理由は精度ではない。契約が結べるからである。

OpenAIのresponse_format + JSON Schema、AnthropicのTool Use。どちらもconstrained decodingでスキーマ準拠を保証してくれる^5。ここが決定的で、MarkdownやHTMLには「必ずこの構造で返る」ことを機械的に保証する仕組みがない。正規表現でMarkdownの見出しをパースする実装は、いつか必ず壊れる。

そして前述のとおり、フロンティアモデルではJSON制約による劣化がほぼ消えている^8 ^10 ^11。かつては「パースの安全と引き換えに精度を捨てる」というトレードオフだったものが、いまは片方をほぼタダで取れる。だったら取ったほうがいい。

分類・抽出タスクに至っては、JSON modeのほうが精度が上がる^9。回答空間が制限されるからだ。ここはトレードオフですらない。

2. 人間が編集し続ける → Markdown#

出力が人間の手に渡って、直され、また使われるなら、Markdownを選ぶ。

Markdownは出力フォーマットの中で推論への影響が最も小さい部類にいる。GPT-4は推論タスクでMarkdown形式のプロンプトが優位、という報告もある^1。ただ、Markdownを選ぶ理由の本体はそこではない。

本体は運用側にある。Gitに乗る。diffが読める。人間がエディタで直接直せる。壊れても壊れ方が緩やかで、見出しレベルを間違えても情報は失われない。JSONで同じことをやろうとすると、エスケープされた改行だらけの1行の中を人間が編集する羽目になる。あれは無理である。

その代わり、Markdownをパース前提にしてはいけない。Markdownは構造化データの器ではなく、プレゼンテーションのための形式だ^12。「Markdownで出させて見出しを正規表現で拾う」という設計は、JSONを使うべき場面の妥協でしかない。人間が読み書きする経路と、コードが読む経路は、分けたほうがいい。

3. 人間が読むだけで触らない → HTML#

レポート、ダッシュボード、可視化。人間が見るだけで編集しないなら、HTMLで直接出させる。

理由は、そのまま表示できるからだ。Markdownを吐かせてレンダラを通す一手間が省ける上に、テーブルの装飾やレイアウトなど、Markdownでは表現できないものが最初から表現できる。

ただしこれには条件がついていて、高性能なモデルを使うことが前提になる。

構造化出力ベンチマークのStructEvalによると、JSON・HTML・CSV・Markdown・YAMLの基本的な生成は多くのモデルで90%を超えて飽和している^12。つまり「valid なHTMLを吐く」という課題自体は、もう解けている。

問題はその先で、同じベンチマークが2つの階段を報告している^12。

• 生成タスク > 変換タスク（ゼロから作るほうが難しい）
• 視覚コンテンツの生成 > テキスト構造の生成（見た目を作るほうが難しい）

そして最先端のo1-miniでも平均スコアは75.58にとどまっている。SVGや複雑なネスト構造は依然として困難だとも書かれている。

要するに、HTMLとして妥当なものは出るが、見た目が意図どおりである保証はない。ここが弱いモデルだと崩れる。だからHTML出力は、キャパシティに余裕のあるモデルにだけ任せる。前述のキャパシティ理論^10とも一貫している。HTMLは冗長でトークンを食うぶん、整形コストの高い出力形式だからだ。

そして人間が触らないという条件も、外せない。HTMLはdiffが読めない。1文字直したいだけでタグの海を泳ぐことになる。人間が編集するかもしれないなら、迷わずMarkdownに倒すべきである。

判断フロー#

まとめるとこうなる。

最後の行を足したのは、実際にはこれが一番忘れられがちだからだ。中間ステップの出力にまでフォーマットを課す必要はない。むしろ課さないほうがいい。

小型モデル・ローカルLLMを使うとき#

Format Taxが生きている世界に戻る。テストされた全オープンウェイトモデルで劣化が確認されている^8し、キャパシティ限界付近のモデルでは28〜36ポイント落ちる^10。

このときの処方箋ははっきりしていて、推論と整形を2パスに分ける。

1. まず自由形式で推論させる（Chain-of-Thought）
2. 別の呼び出しでその結果を構造化フォーマットに変換する

これで劣化の80〜87%が戻る^10。extended thinkingやscratchpadを使って1回の呼び出しの中で分離しても同じ効果が得られる^8。呼び出しが2回になるコストと、28ポイントの精度低下を比べれば、答えは明らかだと思う。

タスクがモデルの限界に近いとき#

モデルのサイズではなく、タスクの難易度で決まる。Opus 4.7でさえAIMEでは5ポイント落ちている^10。自分のタスクがそのモデルにとってどれくらい余裕のある問題なのかは、結局測ってみないと分からない。

モデルを乗り換えたとき#

フォーマット性能のモデル間相関は弱い^2。あるモデル向けに詰めたプロンプト形式が、次のモデルでそのまま効く保証はない。モデル更新のたびにフォーマットのA/Bを取り直せるようにしておくと、後で楽になる。

なぜバイアスは消えないのか#

根本原因についての分析も出ていて、フォーマットバイアスの主因は事前学習データの不均衡だとされている^13。学習コーパスにJSONやMarkdownが多く含まれるぶん、モデルは特定形式への選好を獲得する。これはattention分配の偏りとして内部的に観測できて、推論時のattention再重み付けで部分的に緩和できるものの、バイアスの向き自体は固定的だという。

つまりこれはプロンプトの書き方でどうにかなる話ではなく、学習側の問題である。当面はモデルごとの癖として付き合っていくしかない。