Structured Output を調査してみて分かったこと

この記事は tacoms Advent Calendar 2025 19日目の記事です

qiita.com

はじめに

こんにちは、株式会社 tacoms の Camel チームでエンジニアをやっている t_fujisawa です。

最近、社内で LLM(大規模言語モデル)を業務に活用する機会が増えてきました。 コードレビュー、仕様整理、設計の下書き生成など、いろいろ便利に使える反面、複雑なドキュメント生成をさせようとした瞬間に「揺れ」や「抜け漏れ」といった問題にぶつかることも多くなります。

そこで今回の記事では、LLM の Structured Output(JSON Schema に基づく出力制御)をテーマに、 「これを使うと文書生成の揺れはどこまで抑えられるのか?」 「プロンプト中心の運用と何が違うのか?」 といった観点で調査した内容をまとめます。


■ Structured Output は「文章生成」ではなく「構造生成」を LLM にさせるもの

普通の LLM は自然な文章を書くのが得意ですが、その反面、

  • 表現が変わる
  • 出力の粒度が変わる
  • タイトルや章構成が揺れる

といった問題も起きやすい。

Structured Output はこれを、“この JSON Schema に合う構造で出力してください”という縛りでコントロールします。 これにより、

  • 出力項目の抜け漏れが減る
  • 章や構造が毎回同じになる
  • 後処理(Markdown 化・可視化)がしやすい
  • CI や差分比較と相性が良い

など、「LLM が業務で扱いやすい存在になる」方向に寄せられます。


■ プロンプトよりも「構造(Schema)」に責務を寄せる方が揺れない

一番大きな発見はこれでした。

出力の安定性は、プロンプトの工夫ではなく Schema の設計によって決まる

プロンプトで細かく指示しても、 LLM は気分によって無視することがあります。

しかし、

  • フィールド構造
  • 必須項目
  • 配列の形
  • ネストのルール
  • 値の型

などを Schema で決めてしまうと、 LLM はその“型”に沿って出力するしかなくなるため、安定性が大幅に向上します。

つまり:

  • プロンプト → “何を書くか”という意味のガイド
  • Schema → “どう出すか”という形式のガイド

と役割分担させると、運用がとても扱いやすくなります。


■ “参照してほしい資料”を構造化して促すと安定する

複雑なドキュメントでは、 「このガイドライン見てね」「この方針に沿ってね」がよく出てきます。

ただ、プロンプトに書いたからといって、 本当に参照してくれる保証はありません。

そこで有効だったのが、

「参照したかどうか」を JSON のフィールドとして出力させる

という方法です。

例えば:

  • どの資料を参照したか
  • なぜ参照したのか(または参照しなかったのか)

を必ず構造化して出させるようにすると、 参照漏れの検知やレビューが非常にやりやすくなります。

“読んだ/読んでない”を自己申告させるだけでも、揺れが減りやすい印象でした。


■ Structured Output の限界と割り切り

もちろん、これだけで「完全に正しいドキュメントが出てくる」わけではありません。

調査した限りだと、以下はどうしても限界があります。

  • 深い理解が保証されるわけではない
  • 内容の正しさは人間のレビューが必要
  • Schema の複雑さはそのまま保守コストに跳ね返る

つまり、Structured Output は

AI が業務プロセスに参加しやすくするためのインターフェース

であって、 AI が全部を自動化するための魔法ではありません。


■ 開発プロジェクトにどう活かせるか?

― AIと人間で「扱う形式」を分けるのが一番現実的

調査してみて思ったのが、

AI と人間は、読む・扱うのに適した形式がそもそも違う

という点です。

  • 人間 → 自然言語で整えられた Markdown が読みやすい
  • LLM → JSON のような構造化データの方が圧倒的に扱いやすい

ここを無理に合わせようとするから難しくなる。

なので、

  • LLM:構造化データ(JSON)でやり取り
  • 人間:CI等で構造化データから自然言語ドキュメント(Markdown)を生成し、レビュー

という 役割分担を行えば、 結果として最も安定した運用になるのでは? と感じました。

「AI には構造を。人には自然言語を。」 という割り切りは、今後の実務的な運用でかなり効くはずです。


■ おわりに

今回のまとめとしては、以下のような感じです。

  • Structured Output は LLM 出力の揺れ対策として非常に有効
  • “構造”を先に設計してしまうとプロンプト運用が楽になる
  • 参照漏れのような問題も構造化である程度コントロール可能
  • 最終的な品質判断はやはり人間が必要
  • AIはJSONを作り、JSON -> Markdownに変換して人間が読むという分業が現実的かつ強い

「AI に文書を書かせる」というテーマはまだ発展途上ですが、 構造化という観点を持ち込むだけで、運用しやすさや再現性が大きく変わることを実感しました。

LLMでの文書作成で同じ問題に直面してる方のお役に立てたら幸いです。