INSIGHT
形式が正しい。それだけでAIの出力を確定処理につながない
正しい形式で返ったこと以外に、その値を業務へ使ってよい根拠はあるか。
受注メールをAIに読ませ、注文番号、商品コード、数量、納期をJSONで返す仕組みを作った。JSONは、項目名と値を組にしたデータの形式である。必要な項目はそろい、日付も数値も決めた形になっているので、そのまま受注登録へつなごうとしている。
ここで一度、言葉を正確にしたい。「システムが読める」と「注文として正しい」は別である。注文番号が文字列でも、その注文が存在するとは限らない。数量が整数でも、元の依頼と一致するとは限らない。全項目が埋まっていても、在庫引当や請求を確定してよい承認にはならない。
形式に合うAI出力だけを根拠に、在庫、出荷、請求、支払、顧客記録などの確定処理へつないではいけない。
構造化出力が保証できる範囲を狭く読む
構造化出力は、自由文の代わりに、決めた項目名や型で結果を受け取る仕組みである。後続システムが解釈しやすくなり、項目不足や形式違反を検出しやすい。これは大きな利点だ。
ただし、保証される範囲は利用するサービスの仕様と設定によって異なる。JSONとして解釈できること、指定したスキーマに合うこと、列挙した値のどれかであることなどを、ひとまとめに「正しい」と呼ばない。提供元の現行仕様で、何が保証され、失敗時に何が返るかを確認する必要がある。
さらに、スキーマに合うことは次の問いに答えない。
- 元のメールにその注文番号や数量が本当に書かれていたか
- 注文番号が受注台帳に存在し、未処理であるか
- 商品と顧客の組合せが契約に合うか
- 納期が営業日、供給条件、配送能力に合うか
- その利用者と処理に確定権限があるか
JSONやスキーマに合うかは形式の確認で、上の問いは根拠、業務条件、権限の確認である。スキーマとは、受け取る項目や値の種類を決める定義を指す。形式が整うほど後続処理が迷わず進むため、後者の確認が抜けたときの影響も早く広がる。
確定処理の手前に、四つの関門を置く
AI出力を業務処理へ渡すなら、少なくとも四つを別々に検証する。
第一は構文と型である。必須項目があるか、数値や日付の型に合うか、余計な項目を拒否するかを機械的に見る。第二は元資料との一致である。抽出値の根拠となったメールや注文書の箇所を示し、値を照合する。読み取れない場合に推測で埋めず、「不明」として保留できる設計が必要だ。
第三は業務上の妥当性である。顧客、商品、契約、価格、数量上限、在庫、納期、重複の有無を、正本となる台帳やルールで確認する。第四は操作の許可である。誰の依頼として、どの処理を、どの範囲まで確定できるかを権限表と承認状態で確かめる。
OWASP Input Validation Cheat Sheet は、構文上の検証と意味上の検証を区別し、できるだけ早い段階で入力を検証する考え方を示す。これは一般的なセキュリティ指針であり、AI出力の正しさや、入力検証だけであらゆる攻撃を防げることを実測した資料ではない。それでも、「型が正しいから業務上も有効」と扱わない設計には使える。
AIが返した値は、AI自身に「正しいですか」と問い直して承認しない。元資料、正本データ、業務ルール、権限という独立した根拠で確かめる。
不一致を「エラー」ではなく仕事として受け止める
自動化の成否は、正常系が速いかだけでは決まらない。注文番号がない、本文と添付で数量が違う、顧客名が台帳に複数ある、価格条件が見つからない、といった不一致を、誰の仕事として扱えるかが重要だ。
確定できない出力は、元メールごと消したり、再生成を繰り返したりしない。「保留」として一意の受付番号を付け、元資料、AI出力、検証で落ちた条件を結び付ける。業務担当は顧客への確認や台帳の修正を選び、システム担当は抽出や検証の問題かを見る。緊急注文なら、手作業へ切り替える条件と、切替後の記録方法も決める。
ここで、曖昧な値を既定値で埋める設計には注意が要る。納期がないときに本日、数量が読めないときに1、顧客が不明なときに直前の顧客を入れれば、形式検証は通る。しかし、不明だったという重要な事実が消える。未入力、読取不能、候補が複数、正本と不一致を別の状態として返し、確定経路から外す。
AIから実行系へ渡る境界で、もう一度止める
AIの出力を検証する部品と、在庫引当や出荷を実行する部品は分ける。AIが実行用のJSONを直接送るのでなく、受け取り側が許可した項目だけを読み、正本を引き直し、承認済みの処理だけを発行する。
OWASP AI Agent Security Cheat Sheet は、ツールの最小権限、高い影響を持つ操作への人の関与、構造化出力とスキーマ検証、意思決定と不可逆な実行の分離などを挙げている。これは実装をそのまま転記すれば安全になる手順書でも、防御効果の数値を示す研究でもない。境界ごとに検証と許可を置く設計観点として参照する。
実行部品には、AIが知らなくてよい情報まで渡さない。たとえばAIは注文書から候補を抽出し、実行側は注文番号で正本を検索する。確定する顧客、価格、在庫、送付先は正本から取得する。AI出力と正本が一致しなければ止める。実行直前の画面には、元資料、確定値、変更対象、実行者を表示し、担当者が差分を見られるようにする。
承認後にAIが数量や送付先を修正した場合、その承認を新しい値へ引き継がない。承認した対象と値、実行時の対象と値を結び付け、変更があれば再確認へ戻す。承認ボタンの有無より、何を承認したかが実行まで変わらないことが重要だ。
形式検証を通ったことを実行許可にしない。実行側が業務ルールと権限を再確認し、許可された処理だけを発行する。
再開には、設計書ではなく通過記録が要る
止めた確定接続を再検討できるのは、次の条件がそろったときである。
- 利用するサービスの構造化出力仕様と、失敗時の挙動が現行文書で確認されている
- 項目ごとに、元資料の根拠箇所と正本の照合先が決まっている
- 値の上限、禁止状態、権限、承認を実行側で検証できる
- 不明・不一致・重複・検証不能が確定経路へ入らず、保留担当へ届く
- 手作業への切替、処理結果の確認、誤処理時の停止と是正が試されている
- 本番と同じ境界を持つ試験で、正常系と例外系の通過記録を業務責任者が確認している
再開の決裁者は、システムがJSONを受け取れた画面だけを見ない。どの注文が、どの根拠とルールで通り、どの例外が止まったかを見る。未確認の条件が残るなら、候補表示、担当者への振分け、台帳への下書き登録までに限定し、確定操作は人が行う。
作成者は、対象業務、許す操作、上限、例外、確認者、監視期間、停止権限を整理し、決める権限を持つ担当者へ確認する。業務上の上限や例外を、AIにもっともらしく埋めさせない。「精度が上がったら再開」のように測れない条件にせず、仕様やルール、権限が変われば、影響する試験をやり直す。
形式が正しくても受け付けてはいけない一件を、止められるか試す
構造化出力は、AIの回答を後続処理へ渡しやすくする。だからこそ、形式上の成功を業務上の承認へ読み替えない境界が必要になる。
登録につなぐ前に、形は正しいが、業務では受け付けられない一件を試験データで作る。存在しない商品番号、元メールと違う数量、すでに処理済みの注文などだ。その一件が確定せず、理由と元資料を付けて担当者へ戻るかを確かめる。読める形で返ったことではなく、通してはいけない内容を止めた記録を残してから、接続する範囲を広げる。