AIに業務を任せる範囲を決めるときは、「自動化してよい」という一文を、個々の操作へ分けます。資料を読む、文面を作る、共有フォルダへ保存する、顧客へ送るという操作では、必要な確認が異なります。
OWASPは、AIに過剰な機能、権限、自律性を与えることをExcessive Agencyのリスクとして整理しています。OWASPの説明
操作ごとに許可範囲を決める
| 操作 | 導入時に決めること | 承認時に見るもの |
|---|---|---|
| 読み取り | 対象の資料・期間・利用者 | 取得範囲 |
| 下書き保存 | 保存場所・共有者 | 原稿と保存先 |
| 送信・公開 | 宛先や公開場所 | 最終本文・添付・日時 |
| 更新・削除 | 対象と復元方法 | 変更前後と件数 |
| 発注・決済 | 契約・金額・実行者 | 最終条件と支払先 |
承認を受けた後で宛先や本文を変えた場合は、同じ承認で実行しない設計にします。承認画面で見た版と、実際に使った版を照合できるようにします。
再試行による二重実行を防ぐ
外部サービスの応答が途切れても、処理が失敗したとは限りません。先に送信履歴や保存結果を確認し、成功か不明な場合は自動で繰り返さず保留にします。実行IDと対象を記録し、同じIDを二度処理しない方法を実装側で検討します。
例えば、営業メールなら「下書き完成」「最終版承認」「送信開始」「送信確認」「結果不明」を別の状態として扱います。下書きが直っただけで、送信が承認された状態へ進めません。
止める人と例外時の動きを決める
管理者が連携や実行を停止できることを確認します。例外が発生したからといって、AIが自分で権限を追加する運用にはしません。履歴には、実行内容、対象、許可した人、許可した版、時刻、結果を残します。
承認画面と、実際の操作が一致するかを試す
「送ってよいとAIが判断した」という出力を、システムの実行許可にしない設計が必要です。操作を行う側で、利用者、対象、許可した版、実行できる範囲を確かめます。OWASPも、権限の確認をLLMの判断だけに頼らず、連携先で実施することを勧めています。OWASPの権限と認可の説明
| 試験条件 | 期待する動き |
|---|---|
| 承認した本文の宛先だけ変更した | 承認済みとして実行せず、変更を再確認する |
| 添付が承認後に差し替わった | 確認した版と違うことを検出する |
| 同じ実行が二つ同時に来た | 実装側で重複を防ぎ、結果を照合する |
| 実行途中で利用権限が失効した | 処理時点の権限を確かめ、許可されない操作を止める |
| 送信後の応答だけ届かない | 結果不明とし、履歴確認前に再送しない |
一覧は必要な試験の例で、すべての製品がこの制御を備えるという意味ではありません。利用する接続機能で実現できるかを確認し、できない場合は人が実行する範囲を残します。
最初は読む処理と下書きまでを試し、外部に影響する操作を増やす際に、実際の業務シナリオで確認します。対象となる操作を書き出してAI業務フローを相談してください。必要な権限と、人が判断する箇所を工程別に整理できます。