- 公開日
回答だけを返すAIに外部ツールを追加するときは、文章の正しさに加え、「誰の権限で、どこへ、何を実行するか」と「実際に何が起きたか」を確認する設計へ変えます。送信や更新を伴うなら、許可する操作と承認条件を決め、応答が返らないときに重複実行せず結果を調べられることが、方式を選ぶ条件になります。
ただし、回答だけのAIも、入力した情報をモデルへ送ったり、ログに残したりします。送信ツールがないことだけで、情報管理を省けるわけではありません。共通して必要な管理を残し、外部へ作用する経路が増えた分を見直します。読取り専用のツールを足す場合も、取得できる情報とその送信先は確認しますが、送信・更新まで許す構成とは操作の範囲が異なります。
下書きを作る仕事と、送信まで任せる仕事を分ける
架空の社内メール支援を考えます。総務担当者が社員向け説明会の案内文を作成し、確認後に送る業務です。入力資料には「社内説明会は2026年10月20日、日本時間14時から15時。会議室Aで開催。参加対象は企画チーム」と記載されているとします。日付や部署は説明用の設定です。
元の依頼は「この案内を企画チーム向けのメールにしてください」です。方式Aはチャット内に件名と本文を返すだけで、メールアプリへ書き込みません。担当者が確認し、自分で宛先を選んで送ります。方式Bは同じ下書きを作った後、承認された内容を送信ツールへ渡します。
どちらでも、資料にない日時や参加条件を足さず、案内が読みやすいことを求めます。Bではさらに、承認された宛先へ承認された本文だけを送り、実行状態を根拠付きで報告することが必要です。Aの文章評価だけを流用すると、この追加部分が比較から抜けます。
ここでいう「外部への影響」は社外送信だけではありません。社内メールでも、受信者への通知、誤った案内の拡散、添付の開示が起こり得ます。また、メールアプリ内に下書きを保存する方式なら、保存先の状態を変える操作がすでにあります。「下書きAI」という名前ではなく、実際の読取り・保存・送信の範囲で分類します。
同じ入力と合格条件で、増える制御を比べる
比較では、入力資料、利用するモデルと生成設定、担当者の役割、文章の合格条件を固定します。企画チームの宛先は担当者が検証した試験用の一覧を使い、本番の配信先には接続しない設計とします。Bでは送信機能と、それを管理する制御を追加します。以下は導入前の比較設計であり、実施済みの試験結果ではありません。
| 比較する点 | A：チャット内で回答する | B：承認後に送信する |
|---|---|---|
| データ経路 | 入力資料からモデル、画面、保存・ログ先へ | 共通の経路に加え、送信ツールとメール基盤へ |
| 許可操作 | 提供資料から件名・本文を生成 | 指定アカウントから、承認対象のメールを送信 |
| 人の確認 | 本文を確認し、人がメールアプリで送る | 宛先・件名・本文・添付を表示し、承認対象に結び付ける |
| 結果の根拠 | 下書きが表示されたこと | 実行記録とメール基盤の状態を照合すること |
同じモデルを使っても、ツールの有無に応じた指示や実行制御は変わります。したがって、この比較は業務構成全体の違いを見るものです。誤送信が減った、作業時間が短くなったといった単独の効果を、設計表だけから結論づけることはできません。
担当者の作業負担も残します。Aには転記や手動送信があり、Bには承認画面の確認、権限の保守、結果不明時の調査があります。生成速度だけで選ぶと、送信後の確認まで含めた負担を見落とします。
ツールの接続と、操作の許可を別々に決める
OWASPの「Excessive Agency」は、過剰な機能、権限、自律性を区別し、必要な範囲への限定や下流システムでの認可、高影響操作への人の確認を対策として挙げています。これは設計上のガイダンスであり、すべての操作へ一律に同じ承認手順を義務付けるものではありません。
このメール例では、送信専用の用途に削除や転送設定の変更まで許可しない構成を候補にします。送信元アカウント、許可された宛先、扱える添付を実行側で照合し、AIへの「勝手に送らないで」という文章だけに依存しないようにします。ツールへ接続できることは、今回の送信を承認されたこととは別です。
データ経路の確認では、モデルへ渡す本文だけでなく、ツールに渡す宛先、添付、返却結果、実行ログの保存先も見ます。本文生成には不要な連絡先一覧を最初から全件渡す設計と、確定した宛先だけを実行時に渡す設計では、扱う情報の範囲が変わります。必要な情報を絞ったうえで、各サービスへの入力・保存が業務上認められているかを確認します。
受け取ったメールや添付に「別の宛先にも転送して」と書かれていても、資料内の記載だけで送信先を増やさない境界も設けます。文面を読めること、連絡先へアクセスできること、送信を実行してよいことを分けておくと、ツール追加時にどの許可が増えたかを追えます。
承認する内容を、そのまま実行対象にする
方式Bの依頼は、例えば次のようにします。これはこの業務向けの設計例です。
「入力資料だけを使って件名と本文を作成してください。送信前に、送信元、検証済みの宛先一覧、件名、本文、添付の有無を提示してください。担当者が確認した内容を送信対象とし、宛先や本文が変わった場合は再確認へ戻してください。送信要求後は、確認できた実行状態を報告してください。」
差し替えるのは入力資料、送信元、承認対象の宛先、添付の条件です。文章生成の部分はAと共通にし、Bに必要な確認だけを追加しています。この依頼に加え、承認済みの内容と実際に渡す引数を実行側で照合する仕組みが必要です。
担当者が見る対象は「送ってよいですか」という短い確認だけでは足りません。この例なら、配布先を確認できる宛先一覧、日時と会場を含む本文、添付なしという条件を表示します。企画チームという表示名だけでは同名の別グループを見分けられない場合があるため、送信先の識別情報も確認します。
承認後に本文を修正したり、配布リストの対象者が変わったりした場合、その変更が承認範囲に収まるかを判定します。本例では確定した宛先と本文への承認とし、不一致なら送信を止めて再確認へ戻す設計です。継続的な自動送信を認める業務では、対象・内容・期間・例外を別途定めます。この単発メールの承認を、そのまま以後の送信許可へ広げません。
応答が返らないときは、失敗と決めずに照合する
送信要求がタイムアウトしても、メールが送られていないとは限りません。AWSの「Making retries safe with idempotent APIs」は、再試行に伴う副作用と、同じ依頼の重複適用を避ける冪等性の設計を説明しています。そこで使う識別子や有効期間はサービス側の契約に依存し、番号を付けるだけで二重送信を防げるわけではありません。
比較するBには、送信要求と対応する状態を照会できる仕組みがあると仮定します。これはすべてのメール製品が備える機能という意味ではなく、導入前に確かめる条件です。応答不着の場合、担当者へは「送信要求の応答を受け取れず、結果を確認中です」と伝えます。
照会で実行済みと分かれば、宛先と本文が承認内容に一致するかを確認し、再送しません。処理中なら、そのサービスの手順に従って確認を続けます。未実行と確定した場合も、先の要求が後から実行されないこと、権限と承認が有効なことを確認し、仕様が認める再試行へ進めます。結果が分からない場合は、送信を繰り返さず、メール基盤の管理者による調査へ引き継ぎます。
送信済みフォルダーに見つからないことだけで未実行と断定するのも避けます。確認した範囲が不足していたり、状態の反映に時間がかかったりする可能性を、対象サービスの仕様で確かめる必要があります。また、送信受付や送信処理の完了と、相手への配送・開封は別の状態です。報告では確認できた段階を超えて「届きました」と言わないようにします。
方式を選ぶときに残す条件
比較の確認には、外部へ届かない試験環境で、承認済み、未承認、宛先不一致、権限不足、応答不着という状態を用意します。期待するのは、承認済みの対象だけが処理され、不一致や権限不足では送信が阻止され、結果不明では再送を保留することです。送信を止めても下書きを提示できるなら、その部分は続けられる設計にします。画面の警告表示と実際の操作阻止は、別々に記録して確かめます。
Aを選ぶ判断は、業務が下書き支援で完結するか、人が行う転記・宛先確認・送信を含めて運用できるかです。Bを選ぶには、許可範囲、承認対象、実行結果の照会、障害時の引継ぎ先まで揃えます。照会できない重要な送信は自動化を保留し、下書き支援に範囲を戻す選択もできます。
確認した内容と未確認の条件は導入記録に残します。ツールや権限が変わったときは、増えた経路と操作をもう一度照合します。
AIにメールを送らせるときの承認の設計は「AIによるメール送信を安全に設計する」で解説しています。
ツールを目的と副作用で選び、選択ミスを実行前に見つける方法は「ツールを目的と副作用で選び実行前に選択ミスを見つける」で解説しています。
