LLM構造化出力ハンドブック

 (nanonets.com)
3 ポイント 投稿者 GN⁺ 2026-01-18 | 1件のコメント | WhatsAppで共有
  • 大規模言語モデル（LLM） が JSON、XML、コードなどの構造化形式を生成する際に発生する不安定性を解決するための 開発者向け実務ガイド
  • 確率的な特性により出力が非決定的に壊れることがあり、それを補うための 決定的な構造化手法 を扱う
  • 内部動作原理、ツールおよび技術の選定、デプロイ・拡張・コスト最適化、出力品質の改善 など全プロセスを網羅
  • 急速に変化する構造化生成分野の最新情報を 継続的に更新される文書形式 で統合提供
  • データ抽出、コード生成、ツール呼び出し など、LLMをプログラム的に活用する開発者にとって必須の参考資料

構造化されたLLM出力の必要性

  • LLMは JSON、XML、コードなど 構文的に有効な出力 を多くの場合生成するが、確率的な特性により 形式エラーや不完全な結果 が発生する可能性がある
    • これはデータ抽出、コード生成、ツール呼び出しなどの 自動化されたプロセス で問題を引き起こす
  • こうした問題を解決するために 決定的（Deterministic）な構造化出力方式 が必要
  • ハンドブックは、開発者が構造化出力を安定して実装できるよう ツールと技法全般 を扱う

ハンドブックの主な内容

  • 内部動作原理、最適なツールと技術、ツール選定基準、システム構築・デプロイ・拡張方法、レイテンシ・コスト最適化、出力品質向上 など、実務中心のテーマを含む
  • 各項目は 開発者が直接適用できる段階的アプローチ で構成
  • 構造化出力に関する最新の研究とオープンソースツールを 1つの文書に統合整理

最新性とアップデート

  • 構造化生成技術は 非常に速いペースで進化 しており、既存資料はすぐに 時代遅れ になりうる
  • 本ハンドブックは 定期的に更新されるリビングドキュメント（living document） として維持される
  • 開発者は複数の論文、ブログ、GitHubリポジトリを探し回る必要なく 1か所で最新情報にアクセス可能

活用方法

  • 全体を順に読むことも、必要なトピックをすぐに参照するリファレンス形式 として活用することも可能
  • 実務開発者中心の構成 で、特定の問題を解決する際に素早く参照できる

制作者とコミュニティ

  • ハンドブックは Nanonetsチーム が制作
  • LLM開発者コミュニティのニュースレター を通じて、隔週で最新のインサイト、ブレークスルー、有用なツールや技術を提供

関連記事

1件のコメント

 
GN⁺ 2026-01-18
Hacker Newsのコメント

  • 本当に美しいガイド。複数ページにわたるタブ切り替えアニメーションが特に気に入った。
    自分は grammar-constrained generation をかなりよく理解しているつもりだったが（llama.cpp の grammar 実装にもいくつか貢献した）、それでもこのガイドから新しい洞察を得られた。
    構造化出力は、LLM エンジンの最も過小評価されている機能の一つだと思う。文法制約のおかげで、LLM をより大きなパイプライン（例: tool-calling agent）の一部として安定して使える。
    出力が意味的に間違うことはあっても、文法的には常に正しい。特にローカルモデルを使うとき、この点は非常に重要だ。
    たとえば Jart の Raspberry Pi ベースのスパムフィルタの例 のように、TinyLlama モデルに "yes" または "no" だけを出力するよう grammar を適用すれば、小さなハードウェアでも安定して動作する。

    • モデルが別の出力を出したがるときにどうなるのか、llamafile の内部で処理したほうがよいのか、それとも外部ラッパーで処理したほうがよいのか気になる。リトライ設定や JSON の範囲指定をどうするのかも知りたい。

  • 本当に素晴らしいガイド。私は博士課程でstructured generationを研究していたので、興味のある人向けにいくつか資料を共有する。
    ライブラリとしては Outlines, Guidance, XGrammar がある。
    論文としては Efficient Guided Generation for Large Language Models, Automata-based constraints for language model decoding, Pitfalls, Subtleties, and Techniques in Automata-Based Subword-Level Constrained Generation を勧める。
    ブログ記事としては LLM Decoding with Regex Constraints と Coalescence: making LLM inference 5x faster がある。

    • Outlines がスタックの中で正確にどんな役割を果たすのかよく分からない。大手モデルプロバイダが提供するstructured output APIに近いのか、それとも BAML のようなプロジェクトと比較できるのか気になる。
    • DFybOGeGDS 論文 の canonical filtering の部分は、pretokenization を考慮していないように見える。pretokenization regex を実際に反映した canonical generation の研究があるのか知りたい。
    • 「他の参考資料」と言いつつ、すでにガイドに載っているライブラリ一覧をまた並べているように見える。
    • まさに宝の山だ。オートマトンベースの制約は興味深いテーマだ。

  • よく整理されたガイドだ。Guidance と llguidance の最適化についてもっと知りたいなら、私たちが書いた短い論文を読むとよい。

    • その論文を読んだ著者の一人だ。特にdense token mask のための slicing 実装が印象的だった。

  • このガイドは、人々が主に使う二つの方法をうまく扱っている。ただしconstrained generationは、本来の LLM の分布から外れる可能性がある。
    たとえば LLM が長い構造化オブジェクトを生成するとき、「…」のようなパターンを好むことがあるが、制約付き生成ではそれを強制的に閉じる引用符などで補正してしまい、かえって誤った結果になることがある。
    一方でresamplingは、有効な結果が出るまで繰り返すのでより安定している。
    また、schema エラーを文脈に追加して長さを増やしていくより、単純にリトライするほうが品質とコストの面でよいと思う。

    • ハイブリッドなアプローチも可能だ。まず非制約生成（unconstrained）を試し、失敗した場合にだけ制約生成（constrained）を適用する方法だ。

  • SoTA モデル（Opus、Gemini など）でも依然としてoutput schema enforcementが必要なのか気になる。
    最近のモデルは JSON やコード生成でほとんど文法エラーを出さないが、内部的にはまだ schema 検証をしているのか知りたい。
    小型モデルに構造化生成が必要なのは理解している。

    • スキーマが複雑になるほど、LLM はカウントが苦手なので依然として有用だ。モデルが良くなっても、確率的な性質のため完璧にはならない。
    • 最新モデルでも json\n のような不要なトークンを付けることがあるので、依然としてJSON 応答スキーマを指定するのが安全だ。

  • 構造化出力を強制すると性能低下が生じる。場合によっては 2〜3 倍遅くなることもある。状況に応じて受け入れ可能なコストか判断する必要がある。

  • 本当に驚くほど素晴らしいガイドだ。1 年前にこういう資料があればよかったと思う。周囲の人たちにもぜひ共有したい。

  • 良いガイドだ。特に masked decoding の図 が気に入った。

    • 著者の一人だ。リンクの問題を確認してみる。商用モデルプロバイダがどこもstructured output 機能を追加しつつあるので、このガイドは今後も更新していく予定だ。

  • JSON より信頼性が高く、パースしやすい出力フォーマットがあるのか気になる。YAML や TOML にはそれぞれ欠点があるが、トークン数やコストの面では有利かもしれない。

    • その目的のために TOON フォーマット を使っている。
    • 人間ですら JSON を書くのを面倒だと感じるように、LLM にとってもTypeScript のようなコード形式で結果を生成させるほうがよいかもしれない。ただしセキュリティ上、サンドボックス化とリソース制限は必要だ。
    • 私たちはMarkdown + YAML front matterベースのコンテンツ変換パイプラインを開発中だ。JSON のツール群は弱いが、検証自体は難しくない。
    • 私は正規表現で XML スキーマを強制し、XML パーサーでデコードしている。特にコードブロックは CDATA で包んで自由度を高めている。OpenAI API の regex structured output は、JSON よりコードに向いている。
    • 実際に評価（evaluation）をしてみるのがよい。私の実験では XML は JSON よりout-of-distribution タスクで常に良い結果を出した。

  • ドキュメント/クックブックページの技術スタックが気になる。MkDocs や GitBook には見えないが、何を使ったのだろう。

    • Docusaurus を使った。