人が承認した返金先と、AIが実際に返金する相手は同じか？
AIが返金処理の案を作り、担当者が金額と対象を確認して承認します。開発チームは、重要な操作には人が介在する仕組みができたと説明しました。
ところが、承認の後に対象が変わった場合も、同じ承認のまま処理できたとしたら、どうでしょうか。
これは、承認の設計を考えるための想定例です。問題は、担当者がよく見たかどうかだけではありません。その人が確認した内容と、接続先で実行される内容が、同じ条件に従っているかという点です。
承認を、誰が、どの操作を、どんな条件で、いつまで認めたかという実行上の制御にします。承認画面があることと、承認されていない操作が実行できないことを、別々に確かめる必要があります。
確認ボタンの存在は、何を証明するか
画面に確認ボタンがあれば、人が内容を見る機会を作れます。顧客に不利益が生じる処理や、外部へ情報を送る処理では、重要な役割があります。しかし、ボタンを押す画面だけを評価しても、その後の操作まで制御しているかはわかりません。
次の点を確認します。
承認が未完了でも、別の経路から同じ操作へ到達できないか
承認した内容を、その後に変更していないか
期限を過ぎたり、承認を取り消したりした場合に、実行側へ反映されるか
これらは画面の見た目とは別の確認になります。
OWASPのTransaction Authorization Cheat Sheetは、処理の承認をサーバー側で強制し、実行前に適切な許可を確かめることを推奨しています。AIが関与する処理でも、この原則を省略する理由にはなりません。
AILとしては、重要な操作を任せる前に、承認の記録と実行の記録を同じ対象で突き合わせることを提案します。人が確認したという説明を、具体的な処理の証拠へ変える作業です。
承認したのは、処理の種類か、具体的な一件か
冒頭の返金処理なら、返金という機能を使ってよいことと、特定の顧客の特定の金額を返してよいことは異なります。業務に応じて、どの粒度の許可が必要かを決めなければなりません。
一件ごとの承認を求める業務では、対象、金額、送信先、操作の種類など、判断を左右する情報を対応させます。氏名だけでは対象を識別し切れない場合もあり、何を使って一致を確かめるかは接続先の設計と合わせて決めます。
反対に、すべての読取りまで毎回人に戻すと、業務が止まることも考えられます。一定の条件で自動実行を許可する業務なら、その条件を事前に定義し、条件を外れる処理だけを承認へ回す方法があります。
どちらを選ぶにしても、会話の流れでAIが自分の権限を広げないことが重要です。ある処理を任せたという業務上の許可を、別の対象や操作への包括的な承認へ読み替えないようにします。
内容を直したとき、確認をやり直すのか
想定場面の担当者は、承認後に返金先の情報を修正する必要が生じました。顧客に関わる変更であり、元の内容とは違います。そのとき、以前の承認を何に対するものとして扱うべきでしょうか。
判断に影響する情報が変われば、再承認が必要になる条件を定めておきましょう。表示文の誤字の修正と、金額や対象の変更を同じ扱いにする必要はありません。何が変わったら承認を無効にし、どこへ戻すかを業務側と決めます。
一度の承認を使える期間も、処理の性質に合わせます。待っている間に契約や予約の状態が変わるなら、承認が有効でも実行の前提は変わっているかもしれません。実行時に再び確かめる条件を分けておきます。
OWASPも、承認対象の変更からの保護や、実行時の最終確認、許可の有効期間などを扱います。これを一つのボタンの仕様へ縮めず、内容と状態が変わる仕事として設計しましょう。
承認がないとき、接続先は何をするか
正常に承認して実行する試験は必要です。同じくらい、承認しなかった場合の試験も重要になります。処理が止まったことを、接続先の結果で確認しておきましょう。
承認を待っている、拒否された、取り消された、期限が切れたという状態を分け、実行を許す状態を決めます。状態が不明なときに、会話を続けるためといって操作まで進めないことが必要です。
また、承認者が利用者や操作の範囲を認められる立場にあるかも確認します。担当者が誰でもボタンを押せるのであれば、業務上必要な承認権限と一致していないかもしれません。操作を依頼する権限と、他の人の処理を承認する権限を分けて考えます。
この確認を、AIが承認者の名前を記述したことで代替しません。正式な承認の結果を、信頼する仕組みから取得し、実行側で確かめます。文章の内容と実際の許可を区別する必要があります。
返答が来ないとき、もう一度承認すればよいか
想定例で、返金の実行後に通信が途切れたとします。担当者は結果を確認できず、AIも失敗と表示しました。ここで同じ依頼を繰り返すと、二重の処理にならないでしょうか。
実行の許可と、処理の完了状態は別に管理する必要があります。一度の承認を複数回使えないようにすることに加え、結果が不明な場合に何を照会し、再実行を誰が判断するかを決めておきましょう。
これは、一回しか実行されないことを簡単な設定で常に保証できるという話ではありません。接続先の仕様や分散した処理の条件によって、可能な制御は変わります。重複を抑える方法、状態を調べる方法、例外を人へ戻す方法を組み合わせます。
通常の処理だけを試していると、この点が残りやすくなります。承認後の実行失敗、結果不明、再試行という状態も、対象業務の重要度に合わせて評価しましょう。
人が内容を判断できる画面になっているか
実行側の制御が適切でも、人が何を確認しているかわからなければ、承認の品質は上がりません。対象や変更内容が長い要約の中に埋もれていないかを見直す必要があります。
例えば、変更前と変更後、外部へ送る情報、宛先、取り消せるかを、業務上重要な順で示します。担当者が何を根拠に許可したかを残せることも大切です。AIの説明をそのまま信じるだけの画面にしません。
ただし、確認項目を増やせばよいとは限りません。毎回同じ大量の情報が並ぶと、実際の変更点が見えなくなります。必要な判断と、そのための表示を対応させる方がよいでしょう。
承認を急がせる通知や、期限が切れそうなら自動承認する運用も、業務被害との関係で確認しておきましょう。人が介在する仕組みを設けたのに、その判断の時間を事実上なくしていないかを問う必要があります。
六つの状態を、一つの操作で確かめる
自社の検証では、まず一つの重要な操作を選び、期待する結果を次のように整理できます。
ここに、承認する役割の違いも加えます。業務責任者が正解の条件を定め、開発担当者が強制する場所を説明し、評価者が実際の結果を確認します。それぞれの役割が同じ証拠に結び付くことが重要です。
試験は許可された環境とデータで行い、実行できたこと、拒否されたこと、未確認のことを分けて記録します。画面が止まっただけで合格とせず、接続先で起きた結果を対応させます。
例外承認を、抜け道として残さない
業務上、通常と異なる判断が必要な場合もあります。そのための例外の仕組みを作るなら、対象、理由、承認できる人、期間、残るリスクを明確にする必要があります。
一度例外を許したから、以後すべての処理でも同じ許可を使える状態にはしないようにします。例外の期限と終了条件を確認し、通常の手順へ戻ることまで管理します。
また、緊急対応のために承認を省略できる機能があるなら、その利用権限と記録を独立に評価します。便利な運用のために設けた別経路が、通常の承認制御を無意味にしていないかを確かめておきましょう。
例外が繰り返される場合は、担当者に注意するだけでなく、業務の設計を見直す手がかりになります。通常の条件が実務に合っていないのか、必要な機能が足りないのかを調べ、承認の基準を正式に変える判断へ戻します。
代理承認と、自動処理の許容範囲を決めておく
承認者が不在の夜間に問い合わせが増えたとします。現場は待ち時間を減らすため、代理の担当者にまとめて承認してもらいたくなります。その人が承認できる範囲を事前に決めていなければ、画面に承認ボタンがあるだけで権限の根拠が生まれてしまいます。
代理承認を認めるなら、対象業務、期間、上限、除外する操作を決めます。本人が戻った後に代理権限を終えられるかも確認します。特に、顧客情報の送信先を追加するような操作は、日常の照会と同じ承認権限で扱ってよいかを分けて判断しましょう。
少額の処理を自動化する場合にも、一回の金額だけで十分かを考えます。短時間に繰り返す処理や、同じ対象への累積をどう扱うかは、業務の許容条件によって変わります。AIへ「少額だけ」と伝える文章で代用せず、必要な条件を実行側で確認する設計が求められます。
また、承認者の画面に表示した情報の出所も重要です。AIが説明した内容だけを見せ、対象の取引や変更前後の値を確かめられないなら、人に判断を求めても材料が足りません。判断に必要な情報を、信頼できる業務記録から確かめられる形で示しましょう。
承認を増やすほど安全になるとは限りません。重要な操作に判断を集中し、不要な確認を減らすことも設計の一部です。何を自動で許し、何を止め、人がどの証拠を見て決めるのでしょうか。その線引きまで合意して初めて、承認手続きが業務として動き始めます。
次のレビューでは、承認後の一件を追う
最初に確かめるなら、最近承認した一つの処理を選びます。担当者が見た内容、正式な許可の記録、接続先の実行内容が対応するかを追ってみてください。
一致していれば、その範囲の根拠になります。内容や状態の対応が取れないなら、何を追加で記録するか、どの条件を実行前に確認するかを決めます。AIにもっと慎重に行動するよう頼むことだけで終えません。
人が最後に確認することは、重要な選択肢です。その価値を実際の統制にするには、人の判断とシステムの実行を結ぶ必要があります。
参考情報
公表情報の確認基準日：2026年10月22日。返金や例外承認は設計上の想定例です。検証方法は採用システムの仕様・業務条件に応じて決める必要があります。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
