JSONで読めてエラーもない。それでもAIの出力をそのまま登録しない理由

たとえば、請求書から金額と支払期日をAIで取り出し、そのまま登録画面へ入れる。JSONとして読み込めてエラーも出なければ、登録ボタンを有効にしたくなるかもしれません。しかし、小計が30,000円、税額が3,000円なのに、合計が36,000円でも、すべて数値としては正しく扱えます。

構造化出力は、AIの回答をシステムへ取り込みやすい形にする機能です。値の採用は、業務側で判断します。請求候補を業務システムへ取り込む場面を、4つの例で見ていきます（想定例）。

図1は、権限のない情報を照合画面へ出さないため、実行権限と参照先を内容照合より前に置いた説明例です。途中で不一致・不明が見つかった候補は、その先へ流しません。

図1：判定結果と画面表示の対応。条件を満たした候補だけが、矢印の先へ進みます。人が確認する範囲は用途ごとに決めます。

形式を満たしても登録できない、四つの候補

以下のJSONは、説明に必要な項目だけの抜粋です。付属の完全なJSON4例は、同じ説明用のデータ規則を満たします。共通条件は、通貨JPY、登録単位は円、値がある場合の金額は整数、日付は「年-月-日」の文字列です。操作者は組織T-Aに所属し、許可された顧客・注文だけを扱います。

例01：数値の型は合うが、合計が違う

{"subtotal": 30000, "tax": 3000, "total": 36000}

元資料の小計30,000円と税額3,000円を足した合計は33,000円です。候補の36,000円は整数でも採用できません。通常計算との差3,000円と、元資料の合計を並べ、「修正待ち」にします。AIが再回答した場合も、再計算と原文の照合をやり直します。

例02：他人のIDや存在しない参照先が入っている

{"customer_id": "CUS-B200", "order_id": "ORD-404"}

元資料は、自組織の顧客と注文を指しています。一方、AI候補の顧客は別組織に属し、注文は登録されていない設定です。IDの文字列形式が正しくても、存在確認と対象ごとの権限確認が必要です。OWASPも、対象のIDを受け取る処理では、その利用者にその操作が許されるかを確認するよう求めています。

実装では、認証済みの利用者と組織を基点に、許可範囲内で対象を探します。AIが返したIDや「権限あり」という説明でアクセス範囲を広げません。画面には「この対象は利用できません」と表示し、他組織の顧客名や存在の有無を明かさず、許可された一覧から選び直してもらいます。

例03：合計は合うが、金額の単位が違う

{"amount_unit": "yen", "subtotal": 30, "tax": 3, "total": 33}

元資料の単位は千円です。30＋3＝33という項目間の整合だけを見ると通りますが、登録単位の円へ直した合計は33,000円です。通貨が同じJPYでも、円と千円は別の条件です。単位欄と見出しを含めて原文を確認し、換算係数1,000を通常処理で適用して候補との差を示します。

例04：日付の形は整っているが、根拠が足りない

{"due_date": "2026-10-11", "total": 33000, "source_ref": null}

元資料には「支払期限：10/11」とだけあり、年も、月日・日月の並びの規則もありません。金額の記載もないため、2026年10月11日や33,000円に確定する根拠はありません。日付として読めても、資料がその年月日を裏付けているかを確かめます。発行元への確認や、対象の契約・注文情報の確認へ戻し、不明な間は保留します。

4例の違いと、次にする操作

例	元資料・信頼できる条件との照合	主に止める点検	画面と次の操作
01 合計違い	30,000＋3,000＝33,000円。候補は36,000円	項目間の整合、元資料との一致	修正待ち。原文と通常計算を照合
02 ID違い	許可範囲外の顧客ID、存在しない注文ID	実行権限・参照先	選び直す。対象の詳細は表示しない
03 単位違い	原文33千円は33,000円。候補は33円	元資料との一致	修正待ち。単位を見て換算
04 根拠不足	日付の年・並びが不明。金額の記載なし	元資料との一致	保留。発行元や業務で正式に採用する資料へ問い合わせ

4例とも形式の検査だけでは止められません。例02は権限・参照先で止め、後続の内容照合は実行しない想定です。実際の照合画面には、その利用者が閲覧できる情報だけを出します。

配布4候補をコードで判定した結果

2026年10月26日、配布ZIPの4候補JSONをPython 3で読み、固定した形式規則と、独立に用意した元資料・対象の条件へ分けて判定しました。コードと使い方は既存の検証キットへ追加しています。従来のJSON・スキーマ・Excel・Wordの内容は保持しました。

配布候補	固定した形式規則	通常コードでの判断
01：合計36,000円	適合	合計違いで修正待ち
02：別顧客・注文ID	適合	対象を利用できない。内容照合へ進めない
03：33円	適合	原文の33千円と不一致
04：根拠のない日付・金額	適合	根拠不足で保留

01の合計を33,000円へ訂正すると、すぐ登録可能にはせず「担当者の確認待ち」になりました。同じ内容を確認した後は登録候補へ進め、確認後に日付を変えた場合と、注文を取消状態へ変えた場合は止めています。合計がnullの候補は形式を満たしても保留となり、未確定のまま計算や登録へ進めません。

形式の検査は、このキットにある項目・型・許容値等の固定規則だけを扱います。任意のJSON Schemaやモデルの対応を検証するものではありません。また、候補は配布済みの架空データで、今回AIから取得した結果ではありません。本番DBへの登録・同時処理・実際の権限設定は別に確認が必要です。

形式の検査は、どこまで確かめられるか

最初に、JSONとして読めること、指定した項目や型を満たすこと、業務上正しいことを区別します。たとえば、金額が数値であることは型の問題ですが、その数値が請求書の合計と一致するかは内容の問題です。

段階	分かること	それだけでは分からないこと
JSONとして読める	プログラムが構文を解析できる	必要な項目がそろっているか
指定したデータの規則に合う	指定した項目・型・許容値を満たす	合計、日付の解釈、参照先、権限が正しいか
業務条件を照合する	元資料やマスターと照合した範囲で採否を判断できる	照合していない事実や、照合後のデータ変更まで正しいか

データの規則では、項目名、型、必須項目などを指定します。OpenAIの公式ガイドは、JSON modeと指定したデータの規則に合わせるStructured Outputsを区別し、後者にも内容の誤りが残り得ると説明しています。対応するモデル・データの規則と、拒否・未完了などの例外は、利用するAPIの仕様確認が必要です。

AIの出力は、まず「候補」として扱います。元資料にない情報は、項目を必須にしても根拠を得られません。不明な値はnullなどで表せる契約にし、ゼロや推測値で埋めない設計にします。nullを受け付けるか、nullのまま登録できるかは、用途ごとに条件を決めます。

合計と原文を、AIの回答とは別に照合する

答えが規則や正式な資料から決まる部分は、通常のコードで判定します。金額の範囲、許可された通貨、対象の存在、処理できる状態、合計などを一つずつ確かめます。この例は通常の請求を対象とします。返金や相殺など負の金額が必要な業務では、その条件を別に決めます。

例01の説明用計算では、明細Aが12,000円×2、明細Bが6,000円×1で、小計は30,000円です。税額は「小計の10％、1円未満を四捨五入」という架空の計算規則で3,000円、合計は33,000円になります。実際に使う際は、業務で採用している税率と端数処理を指定します。付属のExcelには入力値、単位、規則、計算式を残しています。

元資料の金額を独立した原文・正式な資料と照合できて初めて、再計算を採否の材料にできます。AIが読み違えた小計と税額から計算し直すだけでは、整合した誤りを作り直す可能性があります。原本自体の合計が明細と合わない場合も、黙って直して登録せず、発行元へ確認します。

「元資料との一致」は、その資料が実際に値を裏付けるかで判断します。入力時にシステムが保持した資料IDと版を基点に、該当するページ・項目と候補を照合します。AIが返すsource_refは照合先の候補にとどめ、実際に入力した資料に含まれ、その値を裏付けるかを確かめます。資料と一致していても契約変更前の古い版なら採用できないため、どの資料を正式に採用するかも決めます。

外部資料に書かれた指示で、点検の省略や権限変更が起きないようにします。OWASPの対策は、外部内容の区別、通常コードによる出力確認、最小権限、重要操作の人による承認などを組み合わせるものです。これらは影響を抑える対策で、完全な防止には至りません。

値を作る処理と、採用を決める処理を分けます。モデルの自己評価や見直しは調査の補助には使っても、元資料、操作権限、確定条件の代わりにはしません。

承認後に値や注文が変わったら、登録前に止める

画面では「読み取り中」「修正待ち」「保留」「確認待ち」「登録済み」を区別します。候補欄に値が入っただけで、完了を示す表示にしません。例01ならAI候補36,000円、通常計算33,000円、原文の該当箇所を並べ、確認する担当者が何の違いを判断するのか分かるようにします。

同じ操作を二度登録しないこと、通信が切れたときに完了したかを調べられることも必要です。登録の応答がないだけでは「未登録」とは限りません。結果が分かるまで再送を保留し、成功を確認してから「登録済み」と表示します。

実装時の重複防止・同時登録・結果照会

確定した値を保存する処理には、同じ業務操作を識別するキーを持たせます。キーはAIの回答ごとに作り直さず、同じ登録操作の再送に引き継ぎます。同じキーと同じ内容なら前の結果を返し、内容が変わっていれば競合として止める、という契約を決めます。DBへの登録と重複判定を同じトランザクションや一意制約で守り、二つの要求が同時に来る場合も確認します。

外部システムへの登録は、自社DBと一体で成功するとは限りません。応答が途切れた場合は「未登録」と決めつけず、操作キーと処理記録で結果を照会します。外部側で成功したことを確認してから登録済みと表示し、不明な間は再送を保留します。通信が途切れたときの結果照会と再送は、API連携の要件｜待ち時間・再送・二重実行で確認できます。

人による確認の範囲は用途と実行権限で変わります。本例の請求確定では担当者による確認を置きますが、外部送信も正式登録もない文章下書きへ、金額計算や重複防止の全工程を強制する必要はありません。一方、下書きに見えても送金・発注・他人のデータ更新につながるなら、承認と権限の境界を明確にします。人の承認も、権限不足を解除する代わりにはなりません。

金額が同じ33,000円でも、注文が変われば確認は持ち越さない

確認した候補が「顧客A・注文O1・33,000円・元資料v2」だったとします。登録前に注文だけO2へ変わった場合、合計も形式も変わりません。それでも、O1について行った確認をO2へ使うことはできません。

登録直前の変化を試す教材（ZIP）の structured は、確認時点の項目と、登録直前の項目・元資料の版を分けて持つ模型です。2026年10月26日に次の四条件を比較しました。

確認後に起きたこと	模型の判定
項目も元資料v2も変わらず、未登録	登録へ進める候補
金額は33,000円のまま、注文をO2へ変更	確認し直す。新規登録へ進めない
項目は同じでも、元資料がv3へ改訂	元資料を照合し直す
同じ内容はすでに登録済み	既存の結果を返し、新規登録を増やさない

教材は確認内容の一致と、登録済みかどうかの条件を計算しているだけで、実際のデータベースへ保存しません。実システムでは、登録直前に対象の存在・権限・状態も確認し、内容の一致を表す値を利用者が書き換えて通せないようにします。確認後に注文が取り消された場合も登録を止めます。二人の同時登録と、保存後に応答が途切れた場合は、同じ保存先を使った試験で確かめます。

既存の4候補の教材は「最初に受け取った候補を採れるか」、今回の教材は「確認した後に変わっていないか」を見るためのものです。前の確認が正しくても、その後の変更や再実行は別に調べます。

根拠不足と処理の失敗で、戻す先を変える

受信段階では本文の値だけでなく、APIの完了状態と拒否の有無を見ます。OpenAIのガイドには拒否や出力未完了を区別する例があり、Responses APIとChat Completionsでは確認するフィールドも異なります。拒否文や途中までのJSONを、通常の業務候補として通してはいけません。

戻し先は原因に合わせます。入力資料が足りないなら聞き返す。例04のように解釈が決まらないなら保留し、発行元や業務で正式に採用する資料で確かめる。許可範囲内の対象を選べないなら担当者へ引き継ぐ。拒否は安全上の制約を回避するよう再試行せず、処理対象と権限を見直します。一時的な通信障害は、回数・間隔・打ち切り条件を定めて再試行しますが、登録結果が不明な場合は先に結果照会を行います。

手作業へ戻す場合も、権限の点検、計算、重複防止を外した抜け道を作りません。担当者が根拠を照らし合わせて値を入力した後、同じ確定処理へ渡します。記録は資料ID・版、検証した規則の版、失敗理由、確認者、操作キー、最終状態など必要な範囲に絞り、閲覧権限と保存期間を決めます。

実装前に、各項目の基準となる資料と、機械で判定できる条件を決めます。人が見る箇所、処理を止める条件、同じ操作を見分ける方法もそろえます。付属の確認票は、記入済み見本と空欄版を用意しています。受入時には「正しく登録できる例」だけでなく、この4例、拒否、未完了、再送、承認後の変更を期待結果付きで確かめてください。確認範囲の組み立て方は、システムの受入テスト・検収で確かめることにつながります。

検証例と確認票をダウンロード

AIから外部の道具へ接続する構成を選ぶときは、APIとMCPの役割を同じ例で比べられます（MCP・API・RAG・AIエージェントの関係）。

まずAIで取り出したい項目を一つ選び、正しい値をどの資料のどの欄で確かめるかを書いてみてください。

実装を依頼する前に、照らし合わせる根拠、操作できる人、確定処理へ渡す条件をそろえます。ここまで決まると、AIを入力補助にとどめる部分と、業務システムへ組み込む部分を判断できます。対象業務・利用する資料・品質条件が具体化した段階では、生成AI社内導入支援で、既存ツールの活用、製品の設定、専用機能の開発という依頼範囲を確認できます。

参考出典

• OpenAI「Structured model outputs」
• OWASP「LLM01:2025 Prompt Injection」
• OWASP「API1:2023 Broken Object Level Authorization」

資料の確認日：2026年9月15日。