AIの操作に人の承認を入れる設計とは？止める場面と確認する人の決め方

AIに社内システムの操作を任せるとき、すべてを自動で実行させてよいのか迷う方もいるでしょう。メールの送信やデータの更新は、AIが間違えたときの影響が大きい操作です。そこで検討したいのが、AIの操作の途中に人の承認を入れる設計です。

承認を入れる設計は「ヒューマン・イン・ザ・ループ」と呼ばれることもあります。AIが作った案や操作の内容を人が確認し、承認したものだけを実行する仕組みです。この記事では、承認を入れる場面の決め方や承認画面に表示する情報を説明します。承認が形だけにならないための工夫もあわせて紹介します。

なぜAIの操作に人の承認が必要か

AIが作る文章や操作の案は、指示や資料に基づいたもっともらしい内容です。ただし、内容が常に正しいとは限りません。事実と異なる内容が出力される現象は「ハルシネーション」と呼ばれ、現在のAIでは完全に防ぐことが難しいとされています。指示の意図を取り違えて、別の顧客のデータを対象にしてしまう可能性もゼロではありません。対策の考え方はAIの誤りを前提にした設計でも扱っています。

もう一つの理由は、業務の責任の所在です。取引先へのメールや受注データの変更は、会社としての判断を伴います。AIが実行した操作であっても、結果に責任を持つのは会社と担当者です。人が確認して承認する手順を入れておけば、誰が判断したかを記録に残せます。

承認を入れる場面の決め方

すべての操作に承認を入れると、確認する人の負担が大きくなり、自動化の意味が薄れます。承認を入れるかどうかは、操作の影響と取り消しやすさで決めるとよいでしょう。判断の目安を表にまとめました。

判断に迷う操作は、まず承認ありで始めます。しばらく運用して、承認した結果に問題がないことを確認できたら、承認を外すかどうかを検討しましょう。反対に、承認なしで始めた操作で問題が起きた場合は、すぐに承認ありへ切り替えられるようにしておきます。

なお、承認を入れることは、AIに渡す権限を絞ることの代わりにはなりません。承認の手順を通らずに操作できる権限が残っていれば、承認の仕組みは意味を持たないからです。権限の考え方はAIに社内システムを操作させるときの権限設計を参考にしてください。

承認画面に表示したい情報

承認する人が短い時間で正しく判断できるかどうかは、画面に表示する情報で決まります。「送信してよいですか」とだけ表示する画面では、何を確認すればよいか分かりません。

承認画面には、次の情報を表示するとよいでしょう。

• AIが実行する予定の操作の内容と、対象のデータ。
• 操作の前と後で、何がどう変わるか。
• 操作案のもとになった資料や入力。
• 誰の指示で始まった処理か。

たとえば顧客データを更新する場合は、変更前と変更後の値を並べて表示すると確認しやすくなります。メールの送信であれば、宛先と本文、添付ファイルをすべて表示することが必要です。承認する人が内容を修正してから実行できる画面にしておくと、差し戻しの手間を減らせます。

承認の依頼が届く場所も考えておきましょう。承認者が普段使っているメールやチャットに通知が届くようにすると、確認の遅れを防げます。ただし、通知の文面だけで承認できる仕組みにすると、内容を見ずに承認するおそれがあるため注意が必要です。

承認する人と、承認しなかったときの扱い

承認者は、その業務の内容を判断できる人にします。たとえば取引先へのメールなら、その取引先の担当者か上司が適任です。承認者が不在のときに処理が止まらないよう、代わりに承認できる人もあらかじめ決めておきましょう。

承認されなかった場合の扱いも、事前に決めておくことが必要です。却下された操作は実行せず、却下の理由を記録に残します。理由が分かれば、AIへの指示や参照する資料を見直す手がかりになります。一定の時間内に承認されなかった操作を自動で取り消すのか、そのまま待つのかも、業務に合わせて決めておくと安心です。

承認が形だけにならないための工夫

承認の件数が多すぎると、内容をよく見ないまま承認ボタンを押すようになりがちです。これでは承認を入れた意味がありません。承認が形だけにならないよう、次のような工夫を検討してください。

一つは、承認の対象を本当に必要な操作に絞ることです。影響の小さい操作まで承認を求めていないか、定期的に見直します。もう一つは、承認の記録を振り返ることです。却下が少ない操作でも、内容が十分に確認されているか、誤りの影響が小さいかを調べてから承認の要否を判断します。反対に、却下が多い操作は、AIへの指示や業務の手順を見直す必要があるでしょう。

承認者の負担も確認しておきたい点です。特定の人に承認が集中している場合は、承認者を増やすか、承認の対象を見直します。

顧客へメールを送る承認画面の例

架空の営業支援アプリが、商品説明のメールを下書きする場面を考えます。AIが文面を作り、担当者が宛先と内容を確認してから送信する設計です。承認画面に「商品案内メールを送ります」とだけ書いても、誤送信を見つける情報が足りません。

画面には、送信元、宛先、CC、件名、本文、添付ファイルを表示します。添付がある場合は、ファイル名だけでなく、対象案件や版も確認できるようにします。似た名前のファイルを取り違えやすい業務なら、プレビューが役立ちます。

承認者は、画面に表示された内容を承認します。承認後にAIが本文を再生成したり宛先を補ったりするなら、最初の承認とは内容が変わります。変更後は再承認が必要になるよう、実行する内容と承認の記録をひも付けます。

承認待ちから実行までの状態を分ける

処理の状態を「下書き」「承認待ち」「承認済み」「実行済み」「却下」「期限切れ」に分けると、今どこで止まっているかを確認しやすくなります。承認済みは送信済みと同じではありません。外部サービスとの通信に失敗する場合もあるため、実行結果を別に記録します。

同じ承認ボタンを二度押した場合も、二通送信されないようにします。承認する操作と実際の送信に識別番号を持たせ、処理済みか確認する設計が考えられます。実装方法は連携先に合わせて決めますが、試験では二重クリックや通信中断を必ず含めます。

時間がたつと内容が古くなる業務では、承認に期限を設けます。たとえば在庫状況をもとに作った案を翌日に実行するなら、在庫を再確認する必要があるかもしれません。期限を過ぎたら自動承認にせず、下書きへ戻すか再確認を求める動作にします。

承認者が不在のときの運用

代わりの承認者は、名前だけでなく、その操作を判断する権限があるかを確認します。普段の承認者へ連絡がつかないからといって、誰でも承認できるようにすると、業務上の責任と操作権限が一致しません。

代理承認を使う場合は、対象期間と対象業務を決めます。期限のある仕事では、承認待ちの通知と、期限までに判断されなかった場合の戻し先を用意します。担当者が確認できない時間帯は、AIの下書きまでで止める運用もあります。

承認を減らしてよいかの判断

却下が少ないことだけでは、確認を省いてよい根拠にはなりません。十分に読まれず承認されている可能性もあります。承認の対象を見直す際は、実際の誤り、操作の影響、取り消しやすさ、別の検査で防げる範囲をあわせて確認します。

たとえば個人用の下書き保存は、本人が使う前に確認できるため、都度承認を省く案があります。社外への送信は宛先の誤りや約束の内容が影響するため、同じ判断にはできません。承認件数を減らすことを目的にせず、必要な確認へ時間を使えるように設計します。

運用の振り返りでは、差し戻し理由を「事実誤認」「対象の違い」「情報不足」「文章の調整」などに分けます。AIや入力画面を直せる原因と、引き続き人の判断が必要な原因を区別できます。

まとめ

AIの操作に人の承認を入れると、AIの誤りによる影響を抑え、判断の責任を明確にできます。承認を入れる場面は、操作の影響と取り消しやすさで決めましょう。承認画面には操作の内容と根拠を表示し、承認者が短い時間で判断できるようにします。運用を始めたあとも、承認の件数と却下の記録を見ながら対象を見直していくことが大切です。

e-Grantsでは、AIを使える社内インフラの構築の中で、権限や承認の仕組みの設計も支援しています。AIに任せる操作と人が確認する操作の線引きを相談したい場合は、AIを使える社内インフラの構築をご覧ください。