Structured Outputとは：LLMの構造化出力と根拠の検証

執筆：Ai Flowi · 公開日 2026-10-11

Structured Output（LLMの構造化出力）は、自由な文章ではなく、事前に定義したフィールドに整理されたモデルの応答です。文書の識別子、抽出した条項、根拠の状態など、後続処理が名前付きの値を必要とする場合に役立ちます。構造に適合していても、抽出した事実が正しいと確認できたことにはなりません。

実際に原文から裏付けられる内容に合わせてフィールドを設計します。情報が不明な場合の表現方法を設け、出力の構造と各値の根拠の両方を確認してください。原文が不完全な場合に、見た目だけ整ったオブジェクトを求めてはいけません。

抽出・解析・検証

抽出では、モデルに原文を解釈させ、選んだ情報を返すよう求めます。解析では、JSONオブジェクトのテキストなどの表現をデータに変換します。構造の検証では、必須キーと許可された型を確認します。意味の検証では、値がタスクの要件を満たし、原文によって裏付けられているかを確認します。

これらの段階で確認することはそれぞれ異なります。形式が完全に整っていても、架空の条項を含むオブジェクトをパーサーが受け入れることがあります。原文に裏付けられた抜粋でも、フィールドが欠けた状態で届くことがあります。形式の不備と根拠のない事実は別々の失敗として扱い、担当者が何を修正すべきか判断できるようにします。

既存のオブジェクトテキストの変換は、JSON String Parserのリファレンスで説明しています。このページでは、それに先立つモデルによる抽出の契約と、結果を利用する前に必要な確認を扱います。

文書の根拠を記録するスキーマの考え方

承認済みの文書に通知義務が含まれているか、確認担当者が調べるとします。記録には原文の識別子と該当箇所の正確な抜粋を残すか、提供された原文では回答できないことを明示する必要があります。もっともらしい通知期間をモデルに埋めさせてはいけません。

これは出力契約の概念例です。標準のoutput_schemaテーブルのインポート形式ではありません。アプリケーションで本当に必要なフィールドと許容する表現を決め、入力前にエディターのスキーマ設定を確認してください。

欠落と不明は異なります。evidence_statusが欠けている場合、この契約に違反します。原文に必要な情報がない場合は、不明という明示的な状態が有効な結果になり得ます。空のテキスト、null、キーの省略は自動的に同じ意味にはなりません。後続の確認処理で解釈できる表現を選びます。

AI Flowi WorkflowのStructured Output

以下で使う生成インターフェースは、コンポーネントカタログのStructured Outputの項目で説明しています。

抽出では、記録を後続処理に渡す前に、確認担当者が根拠の欠如と応答の形式不備を区別できるよう、必要なフィールドを決めます。

抽出設定の提案例

設定例であり、実施・記録済みのテストではありません

Structured Output
input_value: the synthetic document identifier and source text
system_prompt: Extract the relevant notice clause from the supplied source.
               Use unknown when evidence is absent. Preserve source wording.
schema_name: document_evidence
output_schema: configure the reviewed field contract in the editor
model: select your configured provider model

自分のプロバイダーアカウントとAPIキーを使い、モデルと変数のリファレンスに従ってモデルの認証情報を設定します。プロバイダーの料金は別途発生します。

想定する結果は、確認に適したデータ記録であり、モデルが作り上げた条項ではありません。この設定による出力は記録されていません。Structured Outputはカタログに記載されていますが、Ai Flowiによる本番環境でのテストは実施されていません。

構造化出力の構造と意味をどの順で検証しますか？

1. 記録の構造を確認します。 必須キー、想定する値の型、許可された状態の値を確認します。データ契約を満たせない応答は拒否します。
2. 原文の識別情報を確認します。 識別子が別の文脈ではなく、提供された利用許可済みの文書に属することを確認します。
3. 根拠による裏付けを確認します。 原文で抜粋を見つけ、前後の限定条件を調べます。実在する抜粋でも、広く解釈しすぎている場合があります。
4. 不明と矛盾の扱いを確認します。 未解決の情報を見える状態に保ちます。不明を、肯定的な判断が得られたものとして扱ってはいけません。
5. 受け入れた後にだけ後続処理での利用を許可します。 拒否された結果や不確かな結果は、保存やアクションの経路に渡さないようにします。

抽出に金額や期間が含まれる場合は、抽出した値と単位を検証してから、決定論的な計算処理を使います。数値の型が正しくても、通貨、報告期間、条項が違う可能性があります。このページでは、精度の数値や、事実を自動検証できるという保証は提示していません。

有効なオブジェクトでも失敗する抽出例

架空の原文として「アーカイブ済みの記録には通知が必要ですが、現在の記録には必要ありません」を使います。「記録には通知が必要」だけを抽出した記録では、対象区分の境界が失われています。抜粋フィールドには該当する文言を残し、裏付けのある判断では対象となる記録の区分を明示する必要があります。短くした表現が文書内に見つかるだけでは、より広い結論の妥当性を確認できません。

次に、添付の別表を参照しているものの、別表そのものが含まれていない文を提供します。出力には未解決の問いを残し、別の文書や以前の会話から期間を推測してはいけません。文書の識別子は、提供された文書一式のものに固定します。モデルが前のタスクの識別子を返した場合は、抽出した文言がもっともらしくても、その記録を拒否します。

数値フィールドについては、ある条項では日数、別の条項では月数というように、単位の異なる2つの架空の数値を提供します。値を、単位、適用対象の区分、原文の位置とともに確認します。後続の計算にはその文脈が必要です。数字を正常に解析できても、モデルが適用すべき条項を選んだことの確認にはなりません。生成前に必要な箇所が切り詰められていた場合は、記録を不完全とし、確認済みの原文の文脈を使って抽出し直します。出力を説得力のあるオブジェクトに書き換えて、根拠の欠落を補ってはいけません。

検証を通過した判断の振り分けを抽出処理と分ける

状態による判定を設ける提案では、Conditionのインターフェースを使います。上記の根拠確認を行った後にだけ、key_name=evidence_status、operator="equals"、compare_value=supportedを設定します。

supportedとされた記録でclause_excerptが空の場合、提案した根拠の契約に矛盾します。状態だけを信頼せず、振り分け前にその組み合わせを拒否します。一方、unresolved_questionが明確なunknownの結果は、構造としては受け入れ可能でも、検証を通過した判断を処理する分岐には進めません。

抽出結果が根拠の確認を通過した後は、WebhookからSheetsへのチュートリアルを使って、出力先と行の対応付けを設定します。

よくある誤りと関連概念

原文ですべての問いに答えられない場合に、全フィールドを必須にしてはいけません。解析できるJSONを検証済みの根拠と同一視してはいけません。不確かな結果をシートに書き込み、後の確認担当者が不確かさに気づくことに期待してはいけません。

関数呼び出しは操作を要求し、構造化出力は回答を整理します。AIエージェントの状態は、フィールドを使って進捗と未解決の作業を記録します。エージェントのガードレールは、後続のアクションに権限と確認の境界を加えます。既存のユースケースには、参考となる文書化済みの例があり、それぞれのテスト範囲も示されています。

ワークフローの利用料金

プラン：Goは年払いで月額USD8から（月払いUSD10）、Plusは月額USD16から（月払いUSD20）、Pro 100は月額USD80から（月払いUSD100）、Pro 200は月額USD160から（月払いUSD200）、Pro 500は月額USD400から（月払いUSD500）。毎月5,000～250,000 Flowi Tokensが含まれ、追加購入も可能です。ノード実行1回につき1トークン。サードパーティのAPIとモデルの利用料金は含まれません。