INSIGHT
AI同士が同意した。それだけで、確認が済んだことにするな
複数のAIが同意したこと以外に、別の根拠で確かめた結果はあるか。
顧客から届く返金依頼を、複数のAIで処理する仕組みを作った。一つが理由と金額を整理し、別のAIが規程に合うかを確認する。二つの答えが一致したので、「ここまで確認したなら大丈夫だ」と、次のAIから返金処理までつなごうとしている。
だが、二つが同じ顧客記録を取り違え、同じ古い規程を参照していたら、一致は正しさを増やさない。確認役が「承認」と出力しても、誰の権限で返金してよいかは生まれない。AIが増えるほど、前の出力が後ろの指示となり、どこで根拠を失ったか見えにくくなる。
別のAIが「確認済み」と答えたことだけで、返金・送金・顧客記録変更などの確定処理へつないではいけない。
二つの回答が一致しても、照合する根拠は増えていないかもしれない
複数のAIに同じ内容を確認させる方法は、見落としの候補を探したり、説明の違いを比べたりする補助にはなり得る。しかし、回答の数は業務承認の条件ではない。確認役が何を見て、何を見ていないかが分からなければ、「問題なし」という言葉だけが次へ渡る。
返金なら、少なくとも、依頼者と注文の一致、返品や解約の事実、適用する規程の版、返金可能額、既処理の有無、支払先、承認者の権限を確認する。これらはAI同士の多数決ではなく、注文台帳、入金記録、規程、権限表など会社が正本と定める情報に照合する。
業務承認は、内容がもっともらしいという評価ではない。権限を持つ主体が、対象、金額、根拠、例外を確認し、会社の行為として確定を許す手続きである。確認AIの出力は、判断材料や差戻し候補になっても、承認者の権限そのものにはならない。
二つのAIが独立しているように見えても、同じ検索結果、同じプロンプト、同じ誤った入力、同じ提供基盤を使っていれば、誤り方は重なる可能性がある。「別のAI」という製品上の区別ではなく、確認対象と照合元が独立しているかを見る。
会社が事前に承認した条件の下で自動処理する仕組みまで、一律に否定しているわけではない。その場合も、自動化の権限は会社が定めた規程と実行側の制御から来る。確認AIがその場で「承認」と書いたことから生まれるのではない。
AI間のメッセージを、根拠のない合図にしない
複数のAIをつなぐと、最初のAIが作った要約が、次のAIには入力となる。次のAIの「承認候補」が、実行担当には命令として渡る。途中で元の顧客依頼、参照した注文、規程の版が省かれれば、最後の処理から根拠へ戻れない。
Microsoft AzureのAIエージェント分担モデル は、あるエージェントの出力が別のエージェントの命令となり、新しい信頼境界が生じると説明する。他のエージェントからのメッセージを信頼済みの命令にせず、境界ごとに入力を検証すること、操作ごとに権限を確認すること、高い影響を持つ操作に人の関与を置くことなどを挙げている。
この資料は説明的なガイダンスで、法的な責任分担を決めたり、個別契約を書き換えたりするものではない。提供形態や契約で分担が変わることも明記されている。自社では、製品の責任表をそのまま移すのではなく、AI間で渡す項目を次のように定める。
- 元の依頼を指す識別子と版
- 参照した正本、その取得時刻、適用した規程
- 確認できた条件と、未確認・不一致の条件
- 次のAIへ依頼する作業。許可ではなく作業内容として記す
- 確定できる主体と、確定前に再取得する情報
「承認済み」という一語を受け渡さない。何をどの根拠で確認し、何が未確認かを次の工程へ渡す。
確認役には、正解と差戻し先が要る
確認AIを置くなら、評価対象と合格条件を決める。「おかしな点がないか確認して」では、網羅範囲が分からない。返金額の上限、返品受付の有無、対象期間、支払先の一致など、確認項目を業務の言葉で定義する。業務条件は規程とその管理担当へ確認し、作成者がAIの回答で決めない。確認できない項目は、推測で合格させず、保留理由と一緒に返す。
評価に使う正解データも必要である。過去に人が処理した結果をそのまま正解にすると、過去の誤りや例外判断が混ざる場合がある。規程と証拠が確認できる事例を選び、正常、却下、追加確認、規程外の例外を含める。見逃しと誤検知を別に数え、業務への影響を見る。
OWASP AI Agent Security Cheat Sheet は、AIの出力や実行パラメータの検証、最小権限、高い影響を持つ行為への人の関与、反復やツール連鎖の制限、監査記録などを設計観点として示す。これは防御効果の実測でも、掲載された例を使えば本番品質になるという保証でもない。
確認AIが規程外を見つけたら、実行AIへ渡さず、担当者の待ち行列へ送る。担当者が原依頼と証拠を開き、返金する、差し戻す、上位承認へ回すと判断する。人の役割を「AIの結果を見るだけ」にせず、例外を引き受けられる情報と権限を渡す。
権限は連鎖させず、実行の直前に確かめる
受付AIが利用者の代理で依頼を作れても、返金を確定する権限まで持たせる必要はない。確認AIが規程への一致を評価できても、支払システムの認証情報を渡す理由にはならない。各AIには、その作業に必要なデータと操作だけを与える。
実行側は、上流の「承認」フラグを見て処理するのではなく、対象顧客、注文、金額、支払先、承認記録を正本から取り直す。承認者の役割と金額上限が現在も有効かを確認し、依頼後に注文状態や規程が変わっていれば止める。高額、支払先変更、規程外、本人確認不能など、影響の大きい条件は人の承認へ戻す。
AI同士が相互に再試行できる構成では、同じ案件を繰り返したり、相手の依頼を拡大解釈したりしないよう、回数、時間、費用、呼び出せる操作を制限する。停止操作は、AIの一つへメッセージを送るだけでなく、実行権限や処理待ち行列を止められる場所に置く。
上流AIの評価を権限トークンのように扱わない。実行直前に、会社の正本と承認記録から操作の許可を取り直す。
再開は、AIの一致率ではなく業務の通過記録で決める
確定処理を含む自動化を再検討できるのは、少なくとも次がそろい、会社が対象と条件を承認したときである。
- 各AIの役割、入力、出力、利用できるデータと操作が一覧になっている
- AI間で元依頼・正本・時点・未確認事項を失わず引き継げる
- 確定側が操作ごとに現在の権限と業務条件を再検証する
- 正常、却下、追加確認、規程外、情報更新後の事例で、適切に停止・差戻しできる
- 高影響の例外を人が判断でき、記録から根拠へ戻れる
- 反復・処理件数・費用の上限と、実行権限を止める担当が確認されている
再開の証拠は、二つのAIが同じ答えを返した画面ではない。どの根拠でどの条件を通し、どの例外を止め、人が何を確認したかという業務の記録である。業務責任者、システム管理者、確定権限の所有者が、対象と上限を明示して承認する。
そろわない間は、AI同士の比較を候補整理に使っても、確定は人が行う。自動化できるのは、根拠を集める、差分を示す、保留理由を分類するところまで、と範囲を切る。AIの数を増やすことを、承認を外す理由にしない。
AIの同意の数ではなく、別の根拠で確かめた結果を残す
複数のAIは、受付、照合、候補作成を分担できる。しかし、前のAIの判断は、次のAIが会社の確定操作を行う権限にはならない。二つが一致しても、同じ誤った根拠を見ていれば、承認は成立しない。
次のAIをつなぐ前に、一つの依頼について、各AIが何を見て一致したのかをたどる。同じ要約だけを見ていたなら、元の依頼や正本に戻る照合を足す。試験用の不一致や情報不足が、合意の言葉で消されず保留へ戻るかを確かめる。AIの数ではなく、何を別の根拠で確認できたかを記録してから、次の工程へ進める。