構造化出力とは

構造化出力とは

構造化出力は、LLM（Large Language Model）の出力を事前に定めた項目と型の形式に従わせる機能です。
LLMの通常の出力は自由な文章で、同じ依頼でも項目の順序や書き方が変化することがあります。
構造化出力では、項目の名前、文字か数値か、必須かどうか、選択肢を、プログラムが処理するデータの形式であるJSONの項目と型の定義、つまりスキーマで指定し、LLMは生成の段階で、その形式に適合しない語を選択の候補から除外して出力を生成します。

たとえば取引先から受領した請求書のPDFから、請求元、請求日、金額、支払期限を抽出して会計システムに登録するとします。
自由な文章の出力では、金額が「12万円」「120,000円（税込）」のように表記が変動し、登録の処理が失敗することがあります。
構造化出力で金額を数値の項目、支払期限を日付の項目と指定すると、出力は毎回同じ項目と型になり、システムがそのまま処理できます。
ただし、スキーマが提供者の対応範囲内であり、回答の拒否や途中の終了がないことが条件です。
役所の申請書の記入欄に相当し、自由記述の手紙の代わりに、所定の欄に所定の形式で記入させる機能です。

LLMに外部の操作を実行させるツール呼び出しでも、操作の引数を指定した形式に従わせるために同じ仕組みを利用します。

プロンプトでJSONでの回答を指示するだけの方法は、LLMが指示に従うかどうかに依存し、項目の欠落や形式の誤りが発生することがあるため、構造化出力とは区別します。
OpenAIのAPIのJSONモードのように、出力がJSONとして解釈できることだけを保証し、項目や型を保証しない機能もあり、構造化出力とは区別します。

プロンプトの指示だけでは形式が統一されない理由

LLMは、学習した文章の傾向から後続の語を1つずつ生成します。
プロンプトで形式を指示しても、生成の仕組み自体は変化しないため、必須の項目が欠落する、選択肢にない値を出力する、文章の説明を前後に追加するといった誤りが一定の割合で発生します。
OpenAIが2024年に公表した自社の評価では、複雑なスキーマを指定したとき、2023年のモデルであるgpt-4-0613がスキーマの形式どおりに出力できた割合は40%未満でした。
指示だけでは、形式の誤りが発生しないことを保証できません。
システムに統合する処理では、1件の形式の誤りが処理の停止や登録の失敗の原因になります。
そのため構造化出力の登場前は、出力の形式を確認し、誤りがあれば再度生成させる処理を開発者が個別に実装していました。

OpenAIとAnthropicの構造化出力は、LLMが次の語を選択する段階で、選択の候補からスキーマに適合しない語を除外します。
制約付きデコーディングと呼ばれるこの方式により、出力の形式はスキーマに従います。

2026年11月時点では、OpenAI、Anthropic、Googleの主要なAPIが構造化出力を提供しています。
対応するスキーマの範囲は提供者ごとに異なるため、利用するモデルの提供者の文書で確認します。

構造化出力が保証することと保証しないこと

構造化出力が保証するのは出力の形式で、内容の正確さではありません。
たとえば請求書の例では、金額の項目に数値が格納されることは保証されますが、その数値が請求書の金額と一致するかは保証されません。
構造化出力は、計算の手順の誤りのようなJSONの値の中の誤りまでは防止しません。

項目	構造化出力で保証されるか
必須の項目がすべて出力される	保証される
数値の項目に数値が格納される。日付などの書式は、提供者が対応する範囲で保証される	保証される
選択肢を指定した項目に、選択肢の値だけが格納される	保証される
金額や日付が元の書類と一致する	保証されない
書類に記載がない項目に、もっともらしい値を補完しない	保証されない

形式が保証されても、次の場合には出力がスキーマに従わないことがあります。

• 安全上の理由でLLMが回答を拒否した場合。OpenAIとAnthropicのAPIは、拒否を識別できる情報を返却する
• 出力の長さの上限に到達して、出力が途中で終了した場合
• スキーマが、提供者が対応する範囲を超える場合。複雑すぎるスキーマや、最大の文字数のような対応しない制約は、エラーで拒否されるか無視される

Googleは、出力がJSONとして正確でも、値はアプリケーションの側で検証するよう推奨しています。

構造化出力の効果とコスト・リスク

効果

• スキーマを登録先の形式と一致させれば、会計、在庫、顧客管理などのシステムへの登録処理で、LLMの出力の形式の変換が不要になる
• 形式の誤りを検出して再生成させる処理の実装と保守の負担が減少する
• 問合せの分類や書類の項目の抽出で、出力を件数や割合で集計できる

コストとリスク

• スキーマの設計と保守。業務の項目が変更されるたびに、スキーマと登録先のシステムの両方を更新する必要がある
• 値の誤りの見逃し。形式が正常なため誤りが発見されにくく、確認を省略すると、たとえば不正確な金額や日付がそのまま登録される
• 記載のない項目の補完。書類に記載がない項目も必須なら、何らかの値を出力する必要があるため、もっともらしい値を出力することがある
• 初回の待ち時間。新規のスキーマや変更したスキーマの最初の処理では、準備のための待ち時間が追加されるため、スキーマを変更した直後の応答は遅延する。2024年時点のOpenAIの説明では、待ち時間は通常は10秒未満、複雑なスキーマでは最大1分程度
• 入力の増加。提供者によっては形式を説明する指示が自動で追加され、入力のトークン数がわずかに増加し、トークン数に応じた利用料も増加する
• 提供者による差。対応するスキーマの範囲や指定の方法は提供者ごとに異なり、提供者を変更するとスキーマの修正が必要になることがある

構造化出力を業務に導入するときの設計

構造化出力は、LLMの出力をシステムが処理する用途では、利用するモデルと基盤が対応していれば標準の手段として利用します。
LLMの出力を人が閲覧するだけで後続の処理で利用しない用途、たとえば会議の要約や文章の下書きには不要です。

自社で稼働させるオープンウェイトモデルでも、vLLMのような推論の基盤が構造化出力に対応しています。
利用するモデルと基盤が対応していない場合は、出力の形式を検証して再生成させる処理を自社で実装する必要があります。

書類に記載がない場合の値を用意する

書類に記載がない項目を必須の項目にすると、LLMは何らかの値を出力する必要があるため、もっともらしい値を補完することがあります。
記載がない場合は空の値を返却できる項目にし、分類の選択肢には「該当なし」「判定できない」を用意します。
空の値や「判定できない」の件数は、人が確認する対象として抽出します。

値をシステムの側で検証する

システムで確認できる規則は、登録の前に自動で検証します。
請求書の例では、金額の合計と明細の一致、日付の前後関係、取引先の名前が取引先の一覧にあるかを確認します。
検証に失敗した出力は登録せず、人の確認の対象にします。
安全上の理由による回答の拒否と、出力の長さの上限による途中の終了も検知し、同じく登録せずに人の確認の対象にします。

誤りの影響に応じて人の確認を維持する

誤りを含む値の登録が支払いや顧客への通知に直結する処理では、件数が多くても、重要な項目は人が確認してから確定します。
請求書の例では、金額と支払先が該当します。
社内の集計や分類のように誤りの影響が軽微な処理は、自社の書類の実例でAIの誤りの割合を測定し、現在の人手の入力での誤りの割合以下なら自動で登録し、上回るなら人が確認してから登録します。
実例は書類の種類や書き方のばらつきを含めて用意します。
正規近似で95%信頼区間を計算すると、100件の実例では、95%前後の正答率を前後4ポイント程度の幅でしか測定できません。
99%前後の正答率を確認するには数百件から千件以上の実例が必要で、誤りの件数が少ないため、正規近似ではなくWilson法などの方法で区間を計算します。

よくある誤解

構造化出力の利用で抽出の精度が向上する

構造化出力で改善するのは出力の形式の安定性で、書類の内容を読解する正確さではありません。
読み取りの正確さは、使用するモデル、書類の画質、プロンプトでの項目の説明に依存します。
精度の改善には、自社の書類の実例で正答率を測定し、項目の説明やモデルを比較します。

構造化出力の出力はそのまま信頼してシステムに登録できる

形式の正確さと値の正確さは別です。
形式が正常なため、誤りを含む値は人が発見しにくくなります。
システムでの検証と、誤りの影響が重大な項目の人の確認を併用します。

AIの出力をシステムに登録する処理を設計するときは、先に値の検証の規則と人の確認の範囲を決定し、その後でスキーマを設計します。
検証と確認の範囲が確定しないうちにスキーマを固定すると、空の値や「判定できない」を返却できる項目の設計が後回しになるためです。