構造化出力（JSONスキーマ）とは。AIの答えを型にはめる仕組みと見積書で見る4点

AI の試作がうまくいったのに、既存システムにつなぐ段階で工数が膨らむことがある。原因の多くは精度ではなく、答えの形が毎回違うことにある。

「請求書から金額を読み取る」機能を作ったとする。あるときは 合計金額は132,000円です。 と返り、あるときは 132000 とだけ返り、あるときは ご質問ありがとうございます。合計金額は… と前置きが付く。人が読む分には全部正解だが、会計システムに渡す数値としては 3 つとも違う。

この「形を先に決めて、その形でしか返させない」仕組みが構造化出力である。

構造化出力とは何か

構造化出力とは、AI の回答をあらかじめ定義した形式（スキーマ）に従わせる機能である。形式の書き方として広く使われているのが JSON スキーマで、主要な API の多くがこれを受け取れる。

先ほどの請求書の例なら、こう指定する。

項目名	型	取りうる値
issuer	文字列	発行元の会社名
total_amount	整数	税込の合計金額（円）
issue_date	文字列	YYYY-MM-DD の形式
tax_rate	列挙	10 / 8 / mixed / unknown のいずれか
confidence	列挙	high / low のいずれか

こう決めておくと、返ってくるのは次のような形だけになる。前置きも、単位付きの文字列も、項目名の揺れも起きない。

{ "issuer": "〇〇商事", "total_amount": 132000, "issue_date": "2026-10-01", "tax_rate": "10", "confidence": "high" }

受け取る側のプログラムは、total_amount を整数として読めばよい。これだけで、文字列から数字を取り出す処理も、「円」や「¥」を取り除く処理も、前置きを捨てる処理も要らなくなる。

プロンプトに「JSONで返して」と書くのでは足りない理由

試作段階では、指示文に「JSON 形式で返してください」と書く方法がよく使われる。これはほとんどの場合うまくいく。問題は、ほとんどであることである。

実運用で起きる壊れ方は、だいたい次の 5 つに分かれる。

1. 余計な文が付く — 説明文やコードブロックの記号が前後に付く
2. 途中で切れる — 出力の上限に当たり、閉じ括弧が無いまま終わる
3. 項目名が揺れる — total_amount が totalAmount や 合計金額 になる
4. 型が揺れる — 金額が 132000 のときと "132,000" のときがある
5. 想定外の値が入る — 税率に 10% や 軽減税率 のような、決めていない表記が入る

1 万件に 1 件でも、処理は止まる。止まったときに人が直す運用になると、自動化の効果が消える。

構造化出力は、この 5 つのうち 1・3・4・5 を仕組みで防ぐ。指示文で「お願い」するのではなく、生成の段階で形式から外れた出力を作れなくする方式が使われているためである。2 の「途中で切れる」は出力の長さの問題なので、スキーマでは防げない。出力トークンの上限を十分に取るか、1 回で返す件数を減らす設計で対応する。

形は保証されるが、中身の正しさは保証されない

ここが発注側にとって一番重要な点である。

構造化出力が保証するのは器の形だけである。total_amount が整数で返ってくることは保証されるが、その整数が請求書に書かれている金額と一致しているかは保証されない。

むしろ注意が要るのは、スキーマで必須にした項目は「必ず何かが入る」という点である。読み取れなかった場合でも空欄にはならず、もっともらしい値が入ることがある。ハルシネーションが、構造化されたきれいな形で出てくるぶん、見た目では気づきにくい。

だから設計では、「わからない」を表す値をスキーマ側に用意しておく。先の表で tax_rate に unknown を、confidence に low を入れてあるのはこのためである。low が返ったものだけ人が確認する運用にすれば、全件確認せずに済む。この仕分けの設計が、AI-OCR や文書処理の案件で工数を決める。

費用と速度にどう効くか

構造化出力はほぼ無料の機能に見えるが、課金には影響する。

• スキーマは入力トークンに乗る。 項目が多く、説明文が長く、入れ子が深いほど入力が増える。ツール定義と同じ扱いで、毎回のリクエストに付く
• 出力は短くなることが多い。 前置きや言い訳の文が消えるため、出力トークンは減る傾向にある。出力単価は入力より高いので、合計では安くなる場合もある
• 初回に準備の時間がかかる場合がある。 提供元によっては、初めて使うスキーマの処理に追加の待ち時間が生じると説明されている。同じスキーマを使い回す設計なら、影響は初回だけで済む

つまり**「項目を増やすほど入力単価が上がる」**関係にある。使わない項目を念のため足していくと、1 件あたりの費用が静かに増える。

設計で決める 4 つの判断

1. 自由文にするか、列挙にするか。 分類・判定は列挙にする。列挙にすれば、後工程の分岐をそのまま書ける。「その他」と「unknown」は分けて用意する
2. 必須にするか、任意にするか。 必須にすると必ず埋まる。読み取れない可能性がある項目は任意にするか、unknown を許す
3. 入れ子をどこまで深くするか。 階層が深いスキーマは入力トークンを食い、後工程の処理も複雑になる。表形式で収まるなら平らにする
4. 確信度を返させるか。 返させるなら、その値で人の確認に回す基準を先に決める。基準を決めないまま返させても使われない

この 4 つは技術の話に見えるが、決めるのは業務側である。どの項目を人が確認するかは、間違えたときの損害で決まるからである。開発会社だけでは決められない。

見積書で確認する 4 点

1. 出力スキーマの項目一覧が提案に付いているか。 付いていれば、後工程の仕様がほぼ決まる。付いていない見積もりは、連携部分の工数が読めていない可能性がある
2. 「わからない」の扱いが書かれているか。 読み取れなかったデータをどうするか。自動で人の確認に回すのか、そのまま通すのか
3. 形式の検証と、中身の検証が分けて書かれているか。 形式が正しいことと、値が正しいことは別の作業である。後者には評価データセットが要る（評価と運用を先に決める）
4. スキーマを変えるときの扱い。 項目を 1 つ足す作業が保守の範囲なのか、別途見積もりなのか

1 番が特に効く。項目一覧が出せる会社は、業務の流れまで理解している。出せない会社は、まだ試作の段階で見積もっている。

まとめ

構造化出力は、AI の答えを既存システムが読める形に固定する仕組みである。指示文でお願いするのではなく、形式から外れた出力を作れなくする点が違う。これによって、項目名の揺れ・型の揺れ・想定外の値という、運用で一番多い壊れ方が消える。

ただし保証されるのは形だけで、中身の正しさは別である。必須にした項目は必ず埋まるため、「わからない」を表す値をスキーマに入れておくことが、実務では精度の工夫より効く。

発注側がやることは 2 つでよい。出力してほしい項目の一覧を自分で書き出すことと、どの項目をどんなときに人が確認するかを決めることである。この 2 つを渡せば、どの会社も同じ前提で見積もれる。無料で相見積もり・相談の案件票では処理件数・精度要件・連携先を選択式で揃えているので、そこに項目一覧を添えるだけでよい。すでに見積書を受け取っているなら、見積書チェックで出力仕様が書かれているかを確認できる。

関連して、外部システムに AI から処理を依頼する仕組みはAIと外部システムの連携、指示文そのものの設計はプロンプト設計とはに整理している。