AIエージェントにメール送信やデータ更新を任せるときは、実行できる操作を一つずつ確認します。返信案を作るための接続に、送信や削除の権限まで付いていないか。人が承認した宛先や変更内容と、実際の操作が一致するか。導入前に、業務の流れに沿って確かめます。
ここでいうAIエージェントは、指示に応じて外部のツールを呼び出し、複数の作業を進めるシステムを指します。この記事では、メールと顧客管理システムを使う架空の業務を例に、社内で決める操作範囲を整理します。製品ごとの設定名や実現できる制御は、提供元の仕様を確認してください。
閲覧・下書き・送信・更新の権限
最初に、任せたい仕事を操作へ分解します。問い合わせに返信するという業務でも、メールの閲覧、商品情報の参照、下書きの保存、外部への送信が含まれます。
セキュリティ団体OWASPは、LLM06:2025 Excessive Agencyで、必要以上の機能、権限、自律性が与えられるリスクを整理しています。導入担当者は、サービスへの接続可否に加え、接続後に何ができるかを確かめる必要があります。
| 操作 | 限定する範囲の例 | 試行時の扱いの例 |
|---|---|---|
| メールの閲覧 | 試行用の受信箱と指定期間 | 全社員のメールを読める接続にしない |
| 下書きの作成 | 指定した下書き保存先 | 担当者が開いて確認できる状態で止める |
| 外部への送信 | 承認した宛先、本文、添付ファイル | 初回試行では人が内容を確認して送信する |
| 顧客情報の更新 | 指定レコードの特定項目 | テスト環境で変更前後の差分を確認する |
| 削除や権限変更 | 今回の返信業務には不要 | 利用できる操作に含めない |
上の表は業務に合わせた設定案です。選んだ製品では閲覧と送信を分離できない、接続すると広い範囲を読めてしまう、という場合もあります。その制約を把握したうえで、別の接続方法や、下書きまでにとどめる使い方を検討します。
送信・更新の直前に人が確認する内容
ここでいう承認は、AIが用意したメールやデータの変更案を担当者が確認し、その内容で実行してよいと許可することです。AIは送信や更新の直前でいったん止まり、担当者の確認を待つ流れにします。
メールを送る前の確認
担当者が確認するのは、宛先のメールアドレス、CC・BCC、件名、本文、添付ファイルです。添付ファイルは名前だけでなく中身も開いて、別の顧客向けの資料や社外に出せない情報が入っていないか確かめます。
たとえば、AIが取引先への見積もりメールを用意した場合、担当者は送付先と見積金額、添付する見積書を確認します。誤りがあれば送信を止め、修正した内容を確認してから承認します。「メールを送信してよいですか」という質問だけでは、何が送られるか判断できません。
顧客情報を更新する前の確認
データを変更する場合は、どの顧客の、どの項目を、何から何へ変えるのかを確認します。変更する件数も表示し、依頼と関係のない顧客まで更新されないかを確かめます。
顧客の住所を変更する例（架空）
顧客から住所変更のメールが届き、AIが変更案を作ったとします。確認画面には、顧客名と顧客ID、現在の住所、変更後の住所、更新件数「1件」を表示します。担当者は元のメールと照らし合わせ、対象の顧客と新しい住所が合っていれば承認します。承認後、AIはその1件だけを更新します。同名の顧客が複数いて対象を特定できない場合は、更新を止めて担当者が確認します。
承認後に内容が変わった場合
承認は、担当者が確認した内容に対してだけ有効にします。承認後に宛先や添付ファイル、更新対象などが変わった場合は、実行前にもう一度確認を求める仕組みが必要です。
導入担当者は、試行用のメールやデータでこの流れを試します。確認に必要な情報を画面で見られるか、承認するまで送信・更新が止まるか、承認した内容どおりに実行されるかを確かめます。
外部から受け取る文章と操作の制限
エージェントが読むメールやWebページには、通常の資料に見せかけた操作指示が含まれる可能性があります。たとえば、受信メールの本文に、顧客一覧を別のアドレスへ転送するよう書かれていた場合を考えます。
導入時の確認では、外部文書の記載によって、利用者が依頼していない送信や取得が実行されないかを試します。試験には架空の情報と管理下の送信先を使い、実際の顧客情報を漏らすテストにしないようにします。
プロンプトに禁止事項を書く方法だけに頼らず、接続先の権限や許可された操作の範囲も確認します。不要な送信権限を持たせない設定を選べれば、モデルが不適切な指示を生成した場合でも、その操作を実行できる範囲を狭められます。
試行で確認すること通常の依頼を正しく処理できるかに加え、宛先不明、対象が複数、確認待ちなどの場面で、勝手に補って進まないかを確かめます。
本番前に試す異常時の動き
メール1件の送信に成功しても、運用全体を確認できたことにはなりません。途中で処理が止まったときに、どこまで完了したか分かる必要があります。
| 試す場面 | 確認したい動き |
|---|---|
| 承認を却下する | 送信や更新が実行されず、却下を迂回した再試行も起きない |
| 送信後の結果取得でエラーになる | 送信状況を確認できる。未確認のまま同じメールを再送しない |
| 同名の顧客が複数見つかる | 推測で選ばず、識別に必要な情報を担当者へ求める |
| 処理中に停止する | 新規操作が止まり、完了した操作と未完了の操作を区別できる |
| 承認後に更新対象が変わる | 変更後の内容を再確認し、古い承認で別の更新を実行しない |
これらは試験項目の例です。利用する製品と接続先で実現できる範囲を確認し、できない項目があれば手動の確認工程を加えるか、任せる操作を減らします。
停止・復旧と運用記録
停止担当者は、管理画面を開けることに加え、どの設定や接続を止めれば新しい操作が止まるかを確認します。停止後にも実行待ちの処理が残る製品なら、その確認方法も手順へ入れます。
顧客情報の更新では、変更前の値や履歴を確認できるかを確かめます。修正が必要なとき、誰がどの操作を戻すかまで決めます。履歴に顧客情報が含まれる場合は、閲覧者と保存期間も管理します。
メールは、送信後の回収を前提に運用しない方がよいでしょう。誤送信が起きた場合の連絡先と対応手順を用意し、まず追加の送信を止めます。エージェントに訂正メールを自動で送らせると、状況を確認する前に連絡が重なるため、担当者が送付内容を判断します。
開始後は、承認の却下、担当者による修正、重複実行、停止の記録を見直します。問題を人が防いでいた場合は、その確認工程を省く根拠にしないようにします。
よくある質問
すべての操作に人の承認が必要ですか
操作の影響と取り消しやすさに応じて決めます。限定した資料の閲覧と、顧客への約束を含むメール送信では条件が違います。承認を省く範囲を広げるなら、対象、件数、停止条件を限定して別途検証します。
会社で承認済みのAIなら、そのエージェント機能も使えますか
既存の承認範囲を確認します。文章作成だけを認めた承認で、送信や更新まで認められているとは限りません。追加される接続先と操作権限を整理し、変更の確認を受けます。