メインコンテンツへスキップ
VEGA開発からの知見
AIシステム設計

AIの推論と、実行の権限を分ける

例えばAIが支払候補を正しく選んでも、実行までの間に承認が取り消されることがあります。判断の正しさだけを確認していては、その変更を見落とします。操作を実行する時点で、許可と条件を確かめる必要があります。

VEGAの開発では、研究・判断・執行・検証の役割を分けて設計してきました。AIの提案を業務ルールで評価し、実行側が権限と上限を確認し、実行後には相手側の記録と照合します。

設計で決めておくこと

提案の確からしさと、実行してよい範囲を別々に検証する。

01

一つのAIに、提案から実行までを委ねない

推論は、変化する情報から候補や理由を組み立てる工程です。実行の判定は、対象、上限、有効期限、許可範囲を確かめる工程です。役割を分けることで、説得力のある文章が、そのまま操作権限になることを防げます。

例えばAIが「この請求を支払うべき」と提案しても、送金先の確認、金額の上限、支払承認、重複の確認を通過する必要があります。推論が正しいかと、実行してよいかは別々に評価します。

提案
候補、理由、根拠、成立条件、未確認事項を出力する。
検証
入力の品質と、業務ルールを満たすかを判定する。
実行
有効な権限と制約の範囲で、対象の操作だけを行う。
結果確認
相手側の記録を照合し、実際の完了状態を確定する。

02

許可は、実行する瞬間の条件に結び付ける

提案時には有効だった条件が、実行時には変わっていることがあります。他の処理が資金や在庫を使った、設定の期限が切れた、運用が停止されたといった変化を、実行直前に確認します。

事前承認による自動処理は、毎回人に聞かなくても進められます。その代わりに、どの利用者の、どの対象へ、どの設定の版で実行するかを固定し、範囲外の操作を拒否する仕組みが必要です。

実行側で確認する条件

  • 利用者・口座・処理対象が一致している
  • 許可した操作、金額、回数の範囲内である
  • 設定の版と有効期限が一致している
  • 停止・取消の指示が反映されている
  • 未確定の処理を重複して実行しない

03

「確認済み」の意味を一つにしない

単体テストが通ったこと、外部サービスと接続できたこと、業務として実行してよいこと、実際の結果を確認したことは、それぞれ別の証拠です。一つの合格表示にまとめると、残っている課題が見えなくなります。

表は横にスクロールして確認できます。

確認の種類と、そこから言えること
確認確認できること別途必要なもの
ローカル検証与えた入力に対する処理の振る舞い実環境の制約・接続・復旧の確認
実環境の検証対象環境での接続と振る舞い業務上の実行許可
実行許可誰が、どの範囲を許可したか外部処理が完了した証拠
結果の照合対象の処理が実際にどう終わったか継続して運用するための監視

04

受け入れ条件は、困る場面から作る

正常に一度動くデモだけでなく、許可が切れた場合、入力が古い場合、同じ依頼が二回来た場合、途中で再起動した場合を確認します。起きてほしくない結果を先に挙げ、その結果を防げるかを試します。

例えば「期限切れの許可では送信しない」「未確定の処理がある間は同じ操作を追加しない」と、止める条件を具体的に決めます。その条件を実行側で検証できることが、自動処理を任せる前提になります。

復旧と信頼性

タイムアウトの後、再送する前に確かめること

応答がなくても、相手側では処理が完了しているかもしれません。送り直してよいかを判断するために、送信前の記録と相手側の照会を使い、再起動後にも照合できるようにします。

読む →
AIガバナンス

AI業務に人間承認ゲートが必要な理由

操作ごとに人が承認するか、条件を先に承認して自動処理するか。承認する人、対象の版、有効期限、実行前の確認を決め、許可のない操作を止める設計を紹介します。

読む →
検証と改善

自己改善するAIの変更を、いつ採用するか

試した変更の中から、たまたま良かった結果だけを選んでいないか。評価条件を先に決め、探索に使っていない事例と、費用や運用の負担も含めて採用を判断します。

読む →

CONTACT YOLX

自社の業務でAIを使うには

対象の業務と使えるデータを確認し、AIに任せる処理、人が判断する場面、停止後の対応を決めます。設計から実装、検証までご相談ください。