IFStruct：構造化出力の遵守度を測る

構造化出力は、言語モデルにとって今なお典型的な失敗要因です。とりわけスキーマが複雑になり、文字列に丁寧なエスケープが必要になる場面で顕著です。制約付き生成は構文の妥当性を強制できますが、それだけではモデルが正しいフィールド、値、エスケープされた内容を選ぶようにはなりません。スキーマ制約のもとであっても、モデルのロジットはユーザーが求めた構造を意味のある形で反映している必要があります。

私たちは、出力の妥当性とスキーマ追従を検証する生成型ベンチマーク IFStruct を構築しました。このタスクは小さなモデルにとって非常に学習しやすく、テストセットとは別に用意した専用の学習データで強化学習を行った LFM2.5-350M は、Qwen3.5-4B や granite-4.0-h-tiny といったはるかに大きなモデルの性能を上回ります。

構造化出力は、LLM にとって最も一般的な実務タスクのひとつです。IFStruct が狙うのは、既存ベンチマークが取りこぼしている点 — 実際のユーザーからの依頼は、スキーマ要件をさまざまな形で提示し、しばしば書式に関する追加の制約を伴う、という現実です。

IFStruct が測るもの

IFStruct の狙いは、次の問いに絞った信号を得ることです。

IFStruct の各プロンプトは、ランダムに選ばれた対象について少数のインスタンスを生成するようモデルに求めます（「ブルーベリーパンケーキのレシピを 2 つ生成してください」）。スキーマ要件の提示のしかたはさまざまです。評価するのは構造のみで、内容そのものは評価しません。これは意図的な設計です。生成品質、情報抽出能力、推論能力と混ざらない形で、出力形式に関する指示追従能力だけを測ることを目指しています。

検証器は、出力が目標スキーマ（フィールド、型、列挙値、数値の範囲、要素数の厳密な一致を含む）を満たすことを要求します。出力形式は JSON または YAML で、コードフェンスの有無や、追加のコメントを許すかどうかといった制約もサンプリングして加えます。

採点は二値です。要求されたすべての構造制約を満たした場合にのみ合格となります。難易度は、フロンティアモデルであればほぼ 100% の正答率に達するよう調整しています。

データセットの生成

IFStruct のテストセットは、厳選した分類体系群からサンプリングして多様なスキーマを生成する形で、生成的に作成しました。例を示します。

Generate exactly 3 poetry anthologies for a regional writing contest shortlist.
Compose field values as they would appear in a typeset proof copy before printing.
This anthology is for a regional writing contest shortlist.
Each poem text must preserve its line breaks, indentation, and blank lines exactly as the poet laid them out. In the poem texts, include quotation marks around spoken phrases within the poem.

Each poetry anthology for a regional writing contest shortlist should have:
- `anthology_title`: string - Title of the anthology or collection
- `editor_name`: string
- `poems`: a list of 3-4 anthology poems, each with:
- `poems[].poem_title`: string - Title of the poem
- `poems[].poet_name`: string
- `poems[].poem_text`: string - The complete poem with all line breaks, indentation, and stanza gaps preserved
- `poems[].line_count`: integer (between 2 and 40)

Return JSON. Wrap the array in an object with the key `poetry_anthology`.
Follow the requested field set exactly, without adding related fields.
No code block needed - output the JSON directly.

上の例はスキーマを平易な英語の箇条書きで提示していますが、これは表示形式のひとつにすぎず、スキーマ自体とは独立にサンプリングされます。

一部のサンプルでは、必要な形式を注釈付きの例として提示します。

[  // 1 item
  {
    "vendor_name": string,  // Vendor, contractor, or company issuing the invoice
    "invoice_total_usd": number (≥50, ≤25000),
    "tax_total_usd": number (≥0, ≤3000),
    "currency": "usd"|"eur"|"gbp"|"cad",
    "paid_by_bank_transfer_allowed": boolean
  },
  ...
]

さらに、サンプルの半分は LLM によって人間らしい文章に書き換え、要件が平易な文中に織り込まれた自然なチャット依頼を模しています。多様性を確保するため、書き換えでは複数の文体を用いました。そのなかには、最終仕様が固まるまでに何度も推敲や考え直しが起こる「考えながら話す」スタイルも含まれます。整った完成済みのスキーマをただ提示する場合よりも、現実味と難易度を高めるのが狙いです。

提示スタイルの全体は次のとおりです。

• 自然に書かれたチャット依頼のなかでの、その場限りのスキーマ説明
• 明示的なパスを伴う箇条書き（poems[].poem_text）
• 生の JSON Schema
• 注釈付きの構造例（JSON または YAML）
• フラットなパス一覧
• ASCII テーブル

多くの依頼では、文字列のエスケープに意図的な負荷をかけています。引用符、コードスニペット、ファイルパス、スタックトレースを含む複数行の自由記述テキストを、妥当な JSON や YAML に収めるよう求めるもので、実務でよく破綻する箇所です。

検証

検証器は、フェンス付きブロックがあればその中身を取り出し、なければ生のままパースします。フェンスの有無は、プロンプトが明示的に要求または禁止した場合にのみ加点・減点の対象とします。

チェックする制約は 2 種類あります。1 つ目はプロンプトごとにスキーマとは独立してサンプリングされ、応答全体の形を規定します。

• 形式：JSON または YAML。
• 最上位の構造：素の配列か、厳密なキーのもとで配列を包む単一オブジェクトか（「配列を poetry_anthology というキーのオブジェクトで包んでください」).
• 項目数：厳密な個数（「ちょうど 3 件生成してください…」）または範囲指定（"Generate 2-4…").
• コードフェンス：特定のフェンス（```json、```yaml）が必須、汎用のフェンスが必須、あるいは明示的に禁止（「JSON をそのまま出力してください」).
• 補足説明：許可される場合と禁止される場合があります（「JSON のみを出力し、追加のテキストやコメントは含めないでください」).
• 余分なフィールドの禁止：すべてのプロンプトで、要求された以外のキーを禁止しています。

2 つ目はスキーマ自体に由来するもので、すべてのオブジェクトと入れ子リストを再帰的にたどって検証します。

• フィールド：必須フィールドは存在しなければなりません。任意フィールドは省略しても減点されません。スキーマが求めていないキーが含まれていれば不合格です。この規則を厳格にしているのは意図的で、フィールドを勝手に作り出すモデルはスキーマに従っているとは言えず、出力を受け取る側のコードにとって想定外のキーは、良くてノイズ、悪ければパースの破綻になるからです。
• 型：文字列、整数、数値、真偽値。数値フィールドに真偽値が入ることも、その逆も認められません。
• 有効な値：列挙値は許可されたリテラルのいずれかに一致し、数値は許容範囲に収まっている必要があります。
• 入れ子構造：入れ子のオブジェクトやオブジェクトのリストも同じ基準で検証し、入れ子リストの最小長・最大長も対象とします。

結果

データセットが生成的に作られているため、学習データも容易に用意できます。私たちはテストセットとは別に用意したデータセット上で GRPO を用いて LFM2.5-350M を学習させました。

ベースのチェックポイントはテストサンプルの 21.10% しか通過しません。強化学習の後、同じモデルは 44.90% を記録しました。これは Qwen3.5-4B（36.25%）や granite-4.0-h-tiny（38.75%）を含む、はるかに大きなモデルと同等かそれ以上の成績です。

関連研究

この領域の先行研究は、スキーマ追従と出力の妥当性を、指示追従・情報抽出・推論といった要素と組み合わせて評価することが多くあります。スキーマ適合性については、JSONSchemaBench [1] が約 1 万件の実世界 JSON スキーマを評価しており、主眼は制約付きデコードのエンジン比較ですが、ハーネスの統合によってモデル本来の制約なしでのスキーマ充足能力も採点します。StructEval [2] は 18 の形式と 44 のタスク種別にまたがり、一部は内容ベースのソフトな採点を行います。DeepJSONEval [3] は深い入れ子に負荷をかけます。抽出精度を対象とする構造化出力評価としては、テキスト・画像・音声を横断する Structured Output Benchmark（SOB）[4]、文書から JSON への変換を扱う ExtractBench [5]、複数の API とプロンプト強制設定のもとで評価する LLMStructBench [6] があり、STED [7] は厳格な採点の代わりに木編集距離に基づくソフトな類似度指標を提供します。

IFStruct が埋めるのは、構造化出力の要件を、その場限りの自然なチャット依頼を含む多様で現実的な形で提示するという空白です。コードフェンスの指定や追加コメントの禁止といったユーザーがよく求める制約に加え、文字列のエスケープのような典型的な失敗要因を狙い撃ちする依頼も含めています。

今後の展望と限界

内容の正しさや品質ではなく構造要件のみを評価するという設計上の選択は、 スキーマさえ守っていれば、依頼のうち内容に関わる部分（「詩を 10 行出力してください」など）を無視しても合格できることを意味します。品質の検証が行われないため、このベンチマークに向けて最適化する場合（強化学習など）は、報酬関数の一部として LLM ジャッジのような独自の品質信号を加えるべきです。

IFStruct の依頼の難易度は、能力が低〜中程度のモデルを識別できるよう調整されており、フロンティア水準では飽和します。今後の版では、明示的に評価される内容ベースの追加要件で失敗要因を狙ったり、スキーマの入れ子や複雑さを増したりすることで、難易度を高められるでしょう。

検証器はまだ JSON のすべての制約を強制していません。正規表現による文字列パターン、日付やメールアドレスの形式、長さの上下限、配列の一意性、条件付き依存関係、重複キーの拒否、そして YAML のスカラー型強制の落とし穴（引用符なしの no が真偽値になる、1.10 が 1.1 になるなど）への意図的な負荷は今後の課題です。

まとめ

実運用の LLM ワークフローの多くは構造化出力に依存しています。ところが既存の評価の大半は、制約付きデコードに頼るか、書式の遵守と内容の品質をまとめて評価しています。そのため、モデルの出力妥当性とスキーマ追従だけを切り出して見ることが難しくなっています。

私たちは IFStruct を、構造化出力の遵守度を測るオープンソースのベンチマークとして公開します。あわせて テストセットを Hugging Face.

謝辞

執筆：Sam Paech。協力：Maxime Labonne、Tim Seyde、Leonie Monigatti。

引用

引用の際は、以下の参考文献または BibTeX をご利用ください。

@article{liquidAI2026IFStruct,
    author = {Liquid AI},
    title = {IFStruct: Measuring structured-output compliance},
    journal = {Liquid AI Blog},
    year = {2026},
    note = {www.liquid.ai/blog/ifstruct-v1.0}
}

参考文献

[1] Saibo Geng, Hudson Cooper, Michał Moskal, Samuel Jenkins, Julian Berman, Nathan Ranchin, Robert West, Eric Horvitz, and Harsha Nori. (2025). Generating Structured Outputs from Language Models: Benchmark and Studies (JSONSchemaBench). https://arxiv.org/abs/2501.10868

[2] Li et al. (2025). StructEval: Benchmarking LLMs' Capabilities to Generate Structural Outputs. https://arxiv.org/abs/2505.20139

[3] DeepJSONEval: Benchmarking Complex Nested JSON Data Mining for Large Language Models. (2025). https://arxiv.org/abs/2509.25922

[4] Abhinav Kumar Singh, Harsha Vardhan Khurdula, Yoeven D Khemlani, and Vineet Agarwal. (2026). The Structured Output Benchmark: A Multi-Source Benchmark for Evaluating Structured Output Quality in Large Language Models (SOB). https://arxiv.org/abs/2604.25359

[5] Ferguson et al. (2026). ExtractBench: A Benchmark and Evaluation Methodology for Complex Structured Extraction. https://arxiv.org/abs/2602.12247

[6] Sönke Tenckhoff, Mario Koddenbrock, and Erik Rodner. (2026). LLMStructBench: Benchmarking Large Language Model Structured Data Extraction. https://arxiv.org/abs/2602.14743

[7] Wang et al. (2025). STED and Consistency Scoring: A Framework for Evaluating LLM Structured Output Reliability. https://arxiv.org/abs/2512.23712

[8] Jeffrey Zhou, Tianjian Lu, Swaroop Mishra, Siddhartha Brahma, Sujoy Basu, Yi Luan, Denny Zhou, and Le Hou. (2023). Instruction-Following Evaluation for Large Language Models (IFEval). https://arxiv.org/abs/2311.07911