AI出力を業務データに書き戻す前のバリデーション設計｜守る順番
AIに処理させた結果を、そのまま業務テーブルに入れる——このボタンを押す直前、少し手が止まりませんか。
読み取った請求書の金額。分類させた問い合わせのカテゴリ。要約させた対応履歴。形式はちゃんとしている。パースも通る。それでも「これを本番のデータに書き込む」となると、急に重たくなる。その感覚、まっとうだと思います。読み間違いや取り違えが1件混じっても、書き戻したあとでは誰も気づけないからです。
この記事は、AIの出力を業務データに書き戻す前に、何を・どの順番で確かめるかの話です。全部を人が見るのは現実的ではないし、かといって素通しにもできない。その間に、機械で止められるものを機械で止める関門を作ります。今日ひとつ仕込めれば十分な粒度で整理しました。
結論：AI出力の検証（バリデーション）は、4つの関門を安いものから順に通します。①形式——必須項目・型・桁がそろっているか（機械で一括）。②中身——値が実在するか・範囲に入っているか（マスタ照合・上下限）。③業務ルール——単体では正しくても組み合わせがありえなくないか（合計の一致・重複・日付の前後）。④人の目——ここまでを通らなかったもの、および「金額が大きい」「AIの確信度が低い」などあらかじめ決めた条件に当たるものだけを確認に回す。そして書き戻し方そのものも設計する：いきなり本番の確定データにせず下書き（保留）状態を経由し、「AIが入れた」という出所を必ず列に残し、同じ処理を2回流しても二重登録にならない形にして、戻せるようにしておく。要は、AIを疑うのではなく、業務データを守る設計です。
一度に4つとも作らなくて大丈夫です。 まずは「①形式」と「出所を残す」の2つから。これだけでも、後から追える状態になります。
何が起きているのか——「読める」と「業務的に正しい」は別もの
まず、起きていることを共有させてください。AIの出力を業務データに入れて事故になるとき、原因はたいてい「出力が壊れていた」ではありません。きれいに整った形で、もっともらしい嘘が返ってくるのが本当のこわさです。
構造化出力（JSONなど決まった形での返答）が通ることと、その値が業務として成立していることは、まったく別の話です。現場でよく見かけるのは、こんな型です。
- 実在しないコードが入る：商品コードや取引先コードが、それらしい桁数・それらしい並びで返ってくる。でもマスタを引くと、そんなコードは無い。もっともらしい誤り（ハルシネーション）は、形式チェックを素通りします。
- 単位や桁がずれる：金額が税込と税抜で混ざる、
1,200が1200ではなく1.2になる、数量の単位が「ケース」と「個」で入れ替わる。1件だけ見ると気づけません。 - 範囲外の値が入る：日付が来年になっている、割引率が120%になっている、ステータスが定義済みの選択肢のどれでもない文字列になっている。
- 組み合わせがありえない：明細の合計が伝票の合計と合わない。開始日が終了日より後になっている。同じ伝票が二重に登録される。1項目ずつ見れば全部「正しい」のに、束ねるとおかしいという型です。
- 空欄が「推測」で埋まる：読み取れなかった項目を、AIが気を利かせてそれらしく埋めてくる。空欄のまま返してほしかったのに、と後で分かる。
やっかいなのは、これらが例外を投げないことです。処理は成功します。ログにも異常は出ません。だから、数か月後に月次の集計が合わなくて初めて気づく。そのとき、どのデータがAI由来だったかを追えないと、調査の入口すら見つかりません。
だから、ここで一拍おいて関門を作ります。順番は「安い確認から先」。機械で一瞬で終わるものを先に置き、人の時間を使う確認をいちばん後ろに回します。
① 形式を確かめる——ここは機械にまるごと任せる
最初の関門は、そもそも受け取れる形かです。ここは判断が要らないので、全件を機械にかけます。
- 必須項目がそろっているか：頼んだキーが全部あるか。
nullや空文字で来ていないか。 - 型が合っているか：数値であるべき所が数値か。日付が日付として解釈できる形か。真偽値が「はい」という文字列になっていないか。
- 桁・長さが収まっているか：DBのカラム長を超えていないか。コードの桁数は定義どおりか。
- 想定外のキーが増えていないか：頼んでいない項目が付いてきたとき、無視するのか警告を出すのか、方針を決めておく。
ここはスキーマ検証のライブラリ（「この形に合っているか」を定義どおりに自動で照合してくれる道具）を1つ入れると、まとめて片づきます。アプリの入り口で1回通す共通の関数にしておくと、機能が増えても使い回せます。
出力そのものが崩れる（前置きの一文が付く、途中で切れる）ケースの防ぎ方はAIの構造化出力（JSON）を安定させる｜崩れたときの復旧までに分けて整理しています。この記事は「形式は通った、その次」の話です。
② 中身を確かめる——実在するか、範囲に入っているか
形式が通っても、まだ書き込みません。次は値そのものが業務世界に存在するかを見ます。ここが、ハルシネーションを止められる一番の関門です。
- マスタに照合する：商品コード・取引先コード・部署コード・勘定科目——コード類は必ず実マスタを引いて、存在を確認する。存在しなければ、そこで止めます。AIが返した文字列を、そのまま外部キーとして信じない。
- 選択肢は定義済みの値に限定する：ステータスや分類は、あらかじめ決めた選択肢の一覧と突き合わせて、一致しないものは弾く。「未対応」と「未対応 」（末尾に空白）のような揺れも、ここで正規化して吸収します。
- 上下限を決めておく：金額・数量・割合・日付に、業務としてありえる範囲を設定します。「1件あたりの金額は0円以上、100万円以下」「日付は前後1年以内」といった、ゆるくていい範囲で構いません。範囲を超えたものを止めるだけで、桁ずれの多くは引っかかります。
- 「分からない」を許す：読み取れなかった項目は、空欄のまま返させて、空欄として受け取る設計にしておきます。AIに埋めさせない。空欄は後で人が埋められますが、間違った値は誰も直せません。
マスタ照合・選択肢の限定・範囲チェック。この3つだけで、書き戻し事故のかなりの部分は入口で止まります。 もっともらしい誤りの見分け方そのものはAIのハルシネーションの見抜き方も合わせてどうぞ。
③ 業務ルールに照らす——単体では正しい「ありえない組み合わせ」を止める
ここからが、AI特有というより業務システムの腕の見せどころです。1項目ずつは正しいのに、束ねるとおかしい——これを止めます。
- 合計が合うか：明細の合計と、伝票のヘッダの金額が一致するか。消費税の計算が合うか。計算で検算できるものは、必ず計算し直して突き合わせる。AIが出した合計値を信じず、こちらで足し直す。
- 前後関係が成立するか：開始日 ≦ 終了日。受注日 ≦ 出荷日。契約期間の中に対象日が入っているか。
- 重複していないか：同じ伝票番号・同じ請求書番号がすでに存在しないか。AI処理は再実行されやすいので、ここは特に効きます。
- 参照先の状態が正しいか：紐づく取引先が「取引停止」になっていないか。締め処理済みの月に書き込もうとしていないか。
- 既存データと矛盾しないか：同じ顧客の情報を上書きするとき、すでに人が手で直した値を、AIの推測で塗りつぶしていないか。人が触った項目は上書きしないというルールを持っておくと安心です。
ここは既存の業務ロジックに、すでに似た検証が書かれていることも多いはずです。AI経由だからと新しく作らず、人が手入力するときに通っているチェックを、そのまま通す——これがいちばん堅くて速い道です。「画面からの入力なら弾かれるのに、API経由のAI書き込みだけ素通り」という抜け道を作らないこと。ここだけは注意しておきたいところです。
④ 人の目を通す線引き——全部見るのは無理、だから条件を先に決める
ここまでの3つを通ったものは、機械的には問題ありません。それでも、全部を自動で確定させるのが不安な領域はあります。その不安は正しいので、消さずに設計に入れます。
大事なのは、「全部見る／全部見ない」の二択にしないことです。先に条件を決めて、その条件に当たるものだけ人に回します。
- 金額や影響の大きさで切る：「10万円以上の伝票だけ確認」「削除・更新は確認、新規追加は自動」など。
- AI側の確信度で切る：確信度や根拠を一緒に返させて、低いものだけ回す。ただし確信度そのものもAIの申告なので、過信はしない——あくまで優先順位づけの材料として使います。
- 新しいパターンで切る：初めて見る取引先、初めて見る帳票レイアウトなど、過去に確認実績がないものだけ回す。
- 導入直後は多め、慣れたら絞る：最初の1〜2週間は全件を目で見て、実際の誤りの出方を見てから条件を決める。最初から自動化率を上げにいかないほうが、結局は早く軌道に乗ります。
この「どこに人を挟むか」の組み立ては人の確認を挟むAIワークフロー｜HITLの組み方に詳しく整理しています。確認の待ち行列が溜まって止まらないよう、期限と代替経路も一緒に決めておくと安心です。
書き戻し方そのものも設計する——下書き・出所・やり直せること
検証を通った後、どう書くかも同じくらい効きます。ここが弱いと、事故が起きたときに戻せません。
- いきなり確定データにしない：まず下書き（保留・未確定）状態で登録し、確認や条件を満たしたら確定に進める。専用の取り込み用テーブルを一段挟むのも同じ考え方です。確定していないデータは、集計にも画面にも出さないようにしておきます。
- 出所を必ず残す：どのデータがいつ・どのモデル／どのプロンプト版で・どの入力から作られたかを、列やログに残します。「AI由来フラグ」を1つ持っておくだけでも、後の調査がまるで違います。プロンプトの版管理は本番のプロンプトを管理・バージョン管理するも参考にどうぞ。
- 2回流しても大丈夫にする：AI処理は失敗して再実行されがちです。同じ入力なら何度流しても結果が1件にしかならないように、伝票番号などの業務キーで重複を防ぐ制約を持たせます。リトライの組み方はAI出力が不安定なときのフォールバック設計｜リトライの型に整理しています。
- 一括処理は途中で止まっても壊れない形に：100件を1件ずつ確定していく処理なら、1件単位で完結させ、途中で落ちても「どこまで終わったか」が分かるようにする。まとめて1トランザクションにするか1件ずつにするかは、業務上「半分だけ入っている」が許されるかどうかで決めます。
- 戻せるようにしておく：取り消し方（論理削除、変更前の値の保持、取り込み単位でのまとめ取り消し）を、書き込みを作るのと同じタイミングで用意します。「戻し方が無い書き込み」は、本番に出す前に一度立ち止まるサインです。
そして、弾いた件数と理由を記録に残すこと。どの関門で何件止まっているかが見えると、プロンプトを直すべきか、範囲設定が厳しすぎるかの判断ができます。測り方はAI機能の効果測定｜導入後に見るログと指標の設計も下敷きになります。
明日からやること（まずこの3つ）
大がかりな作り込みは要りません。まずこの3つだけで、状況はかなり変わります。
- コード類のマスタ照合を1本入れる：AIが返したコードを、書き込む前に実マスタで存在確認する。存在しなければ止める。いちばん短時間で、いちばん効きます。
- AI由来を示す列（またはログ）を足す：「いつ・何が入れたか」を残すだけ。今日の10分で足せて、半年後の自分を確実に助けます。
- 範囲の上下限を、ざっくり決めて入れる：金額・数量・日付に「業務としてありえる幅」を1つ設定する。細かく詰めなくて大丈夫です。ゆるい範囲でも、桁ずれは引っかかります。
①③④の関門を全部そろえるのは、後からで構いません。 今日ひとつ「そのまま書き込む」をやめられたなら、それだけで前に進んでいます。
AI出力を書き戻す前のチェックリスト
書き込み処理を作るとき・レビューするときに、さっと確認します。全部に○が要るわけではなく、その機能で気になる所だけで十分です。
① 形式
- 必須項目の有無・型・桁を、機械でまとめて検証しているか
- 想定外のキーが増えたときの扱いを決めているか
② 中身
- コード類は実マスタに照合してから使っているか
- ステータス・分類は、定義済みの選択肢に限定しているか
- 金額・数量・日付に、業務としてありえる上下限を決めているか
- 読み取れなかった項目を、AIに推測で埋めさせていないか
③ 業務ルール
- 合計・税などの計算を、こちらで検算して突き合わせているか
- 日付の前後関係・重複（同じ伝票番号）を確認しているか
- 人が手で直した値を、AIの推測で上書きしていないか
- 画面入力なら通っているチェックを、API経由でも通しているか
④ 人の目・書き戻し方
- 人に回す条件（金額・確信度・新規パターン）を先に決めているか
- いきなり確定せず、下書き（保留）状態を経由しているか
- 「いつ・何が入れたか」の出所を列やログに残しているか
- 同じ処理を2回流しても二重登録にならない形か
- 取り消し・戻し方を用意しているか
- 弾いた件数と理由を記録し、後から見られるようにしているか
この記事のまとめ
AIの出力を業務データに書き戻すのが不安なのは、慎重さの表れであって、心配しすぎではありません。実際、形式が正しくても業務的にありえない値は普通に返ってきます。
だから、安い確認から順に関門を置く。①形式を機械で通し、②実マスタと範囲で中身を確かめ、③業務ルールで組み合わせを見て、④残ったものだけ人が見る。そして、下書きを経由し、出所を残し、戻せるようにして書く。この形にしておけば、間違いが混じっても気づけるし、直せるようになります。
完璧な検証は要りません。要るのは、間違いが起きたときに追えることです。まずはマスタ照合ひとつからで十分です。
AIに任せる範囲が広がるほど、最後に効いてくるのは「書き込む直前の一手間」です。 今日、マスタ照合をひとつ足せたなら、それは半年後の自分と、隣の担当者を確実に助けます。人の確認の挟み方は人の確認を挟むAIワークフロー｜HITLの組み方、出力そのものの安定化はAIの構造化出力（JSON）を安定させるも、必要なときにのぞいてみてください。