AIエージェントのメール誤送信をどう防ぐ？下書きと送信権限の分け方

AIエージェントに社内資料の整理やメール文面の作成を任せる際、システムにどこまでの操作を許可するかは重要な課題です。AIが作成した文面をそのまま送信できる状態では、意図しない宛先や不適切な内容で誤送信が起きるリスクがあります。

これを防ぐため、「AIには下書きの作成だけを頼み、送信は人が行う」という運用が考えられます。しかし、AIに対する「依頼文（プロンプト）」で送信を禁止することと、システム上で「送信する能力を持たせない」ことは根本的に異なります。企業担当者がAIを安全にメール業務へつなげるには、資料からメール文面を作るエージェントにどこまでシステムの接続を許可し、意図しない送信を実行前にどう止めるかを設計しなければなりません。

本記事では、AIエージェントの誤送信を防ぐための考え方を解説します。依頼文に頼るのではなく、メールシステムが持つ送信能力の仕様と、人が承認した宛先や内容をどこで分けて確認すべきかを整理し、安全な運用フローを構築するための到達点をお伝えします。

「下書きだけ」の依頼と、送信できない権限は違う

AIエージェントに「メールの下書きだけを作成し、勝手に送信しないでください」と指示することは、日常の業務で人に作業を頼む感覚に近いかもしれません。しかし、この指示はあくまでAIへのプロンプト（命令文）を通じた「お願い」にすぎず、システム的に送信を不可能にしているわけではありません。

たとえば、AIが処理する外部の資料や受信メールの中に、AIの行動を変えてしまう特殊な命令が含まれていた場合、元の指示が無視されて予期せぬ操作が実行されるリスクがあります。プロンプトの工夫だけで意図しない送信を完全に防ぐことは困難です。

システム的に送信を防ぐには、接続するメールシステムの権限仕様を理解する必要があります。たとえばGmailの場合、下書きを管理しメールを送信できるgmail.compose権限をシステムに付与すると、それだけでメールを送信する権限も同時に与えることになります。具体的には、下書きを作成する操作と、作成した下書きを送信する操作、さらには下書きとは別の送信経路である直接送信の操作は、すべて同じ権限スコープで実行可能です。「送信権限だけを外して下書き権限だけを渡す」という分離は、Gmail APIの基本仕様のみでは実現できません。

したがって、Gmail APIを直接呼べる資格情報までAIエージェントに与えた場合は、技術的には「メールを送信する能力」を持たせていることになります。この状態で承認前の送信を止めるには、送信処理の直前でシステムが確実に一時停止し、人間の承認を必須とする仕組みが必要です。たとえば、Claude公式Gmailコネクターでは、送信や返信などの操作を実行する前にユーザーの承認を求める挙動が既定となっています。ただし、Team・Enterpriseでは毎回の確認を省略できるかをOwnerが決めるため、運用ルールの確認が必要です。

もし、システム側で送信直前の承認プロセスを強制できない場合や、設定の管理に不安がある場合は、AIにメールシステムへの接続権限を一切渡さないという選択肢があります。PC環境でのファイル読み取りやAIサービスへの入力と、第三者へのメール送信は別経路の操作です。AIにはチャット画面上に「公開可能な企画メモから作成した社内確認依頼メールの文面候補」だけをテキストで出力させ、人がその内容を確認したうえで、手動で普段のメールソフトに転記して送信する代替案も有効です。AIにどこまでツールを公開するかを決定する際は、「下書きの依頼」という言葉に頼るのではなく、付与する資格情報が持つ実際の能力に基づいて許可範囲を決める必要があります。

承認するのは下書きIDではなく、宛先・本文・添付の組み合わせ

AIに下書きを作らせて送信直前に人が承認する運用を設ける場合、「AIが作成したこの下書き（ID）を送信してよいか」という確認方法では、意図しない内容が送られるリスクが残ります。たとえば、公開可能な企画メモから社内確認依頼メールの文面候補をAIに作成させる場面を想定します。ここで人が判断すべきなのは、相手へ渡してよい情報が適切に選ばれているか、差出人や宛先（To/Cc/Bcc）、件名、本文、そして添付ファイルが正しいかという、具体的な内容の組み合わせです。承認対象は「下書きの箱」ではなく「送信される情報そのもの」である必要があります。

なぜ下書きのIDを指定するだけでは不十分なのでしょうか。Gmail APIの仕様では、Draft（下書き）は安定したIDを持つ容器として扱われます。中のメッセージが置換されるとメッセージIDは変わりますが、Draft ID自体は同じまま維持されます。つまり、同じ下書きIDであっても内容は変わり得るということです。人が画面で内容を確認し「この下書きIDなら送信してよい」と承認した直後に、AIエージェントや他の処理が内容を書き換えてしまった場合、承認時とは異なる宛先や本文のまま送信操作（drafts.send）が実行されてしまう可能性があります。

さらに、添付ファイルが含まれる場合は別の死角も生まれます。たとえばClaude公式のGmailコネクターでは、添付ファイルのメタデータを参照することはできても、内容そのものは直接読めない仕様となっています。AIが中身を正確に把握できないまま下書きにファイルを添付した場合、人がファイルの中身まで開いて妥当性を確認しない限り、誤った資料が送付される原因になります。

人が承認した版と、実際に送信される内容を確実に同じにするには、送信システムの設計に工夫が求められます。送信の実行をAIシステムに許すのであれば、人が承認した時点の差出人・To/Cc/Bcc・件名・本文・添付内容のすべてに送信処理を結び付け、内容が少しでも変われば再承認を要求する仕組みが考えられます。内容のハッシュ（計算値）を記録して送信前に比較する手法もありますが、それだけでは確認と送信の間に並行して更新される隙を完全に防ぐことは困難です。送信処理側が「承認済みの内容」を固定して送信に用い、下書きを経由しない別経路の直接送信（messages.send）や、新しい内容を渡して下書きを更新しながら送信する迂回経路を閉じるような条件を組み込むことで、意図した内容だけを送信する安全なフローに近づけることができます。

送信の入口を絞り、不合格と障害で止まるか確かめる

AIエージェントによる意図しないメール送信を実行前に止める設計では、承認プロセスの導入に加えて、送信の入り口を制限し、異常発生時に処理が安全に停止するかを確かめる試験が重要です。

まず、エージェントがメールを送信するための経路（ツール）を一つに絞り込みます。前節で触れたように、Gmail APIなどには下書きを経由しない直接送信や、内容を更新しながら送信する迂回経路が存在します。AIエージェントに対して標準の送信ツールをそのまま公開するのではなく、システム側で「人間が承認した確定済みの宛先・本文・添付ファイル」のみを送信処理へ渡す専用の入り口を用意し、他の送信経路は利用できないよう閉じておく設計が考えられます。

次に、この専用の入り口が呼び出された際に、送信を実行する前に処理を一時停止し、承認状態を検査する仕組みを設けます。たとえば開発ツールには、ツールの実行前に対応するイベントを検知して処理を拒否できるフック（Hook）と呼ばれる機能が存在します。このような機能を利用し、「未承認である」あるいは「承認時の内容から変更されている」と判定された場合は、送信処理を強制的にブロックしてAIに差し戻します。

しかし、設定ファイルにブロックの記述が存在するだけでは、すべての状況で送信が停止する保証にはなりません。検査の仕組み自体に障害が起きた場合の挙動も確認する必要があります。フックで実行するスクリプトの起動に失敗したり、通信のタイムアウトが発生したりした場合、既定では操作が継続されてツールが実行されてしまうことがあります。こうした検査不能な状態に陥った際、処理を通過させるのではなく確実にブロックする設定（たとえば、処理失敗時に実行を遮断するよう指定する設定）が機能しているかを確かめる必要があります。

安全な運用に向けては、対象外の経路からの送信や、検査機能の不合格試験を事前に実施することが求められます。編集上の架空の応用例として、システムを導入する際には以下のような試行条件を決め、それぞれで送信が止まるか、あるいは正しく記録されるかを確認する設計が考えられます。

• 未承認・内容変更：承認されていない状態や、承認後に内容が書き換えられた状態で送信要求が来た場合に拒否されるか。
• 検査不能：承認状態を確認するシステム自体がダウンしたり、応答が遅延したりした場合に、送信が実行されずに停止するか。
• 重複要求：通信エラーなどで同じ送信要求が複数回繰り返された場合に、二重送信を防げるか。
• 送信結果不明：送信処理の途中でエラーが起きた際、実際に送信されたのか失敗したのかが記録に残り、追跡できるか。

AIによる資料整理をメール送信へとつなげる許可範囲を決める企業担当者にとって、システムが「想定外の事態でも安全側に倒れて止まるか」を評価するための重要な基準となります。

よくある質問

Q1. AIにメールシステムを接続せず、人が手動で転記する方法なら誤送信のリスクは完全にゼロになりますか？

完全にゼロになるわけではありません。AIにメール接続の権限を渡さないことで、AIシステムが直接メールを誤送信するリスクは防げます。しかし、人が手動でメールソフトへ転記する際に宛先を間違えるといった人為的なミスは起こり得ます。

Q2. Gmailの権限仕様上、下書きと送信を分けられないとのことですが、安全に運用するには独自のシステム構築が必須ですか？

必ずしも独自システムの構築だけが必須というわけではありません。Googleの権限スコープが持つ能力と、AIに対して下書き専用ツールだけを公開して資格情報を隔離するシステム設計は別のものです。独自にシステムを構築して送信経路を遮断することも有効ですが、既製のコネクターでも安全に配慮されたものがあります。たとえば、Claude公式Gmailコネクターでは、送信などの操作を実行する前にユーザーの承認を求める機能が既定で提供されています。ただし、Team・Enterpriseでは毎回の確認を省略できるかをOwnerが決めるため、自社の運用ルールに合った設定の確認が必要です。

Q3. 外部データによるプロンプトインジェクションの危険性が挙げられていますが、最新のAI製品なら防げるのでしょうか？

本記事で紹介した外部ツールのデータに含まれた命令がエージェントの行動を変える間接プロンプトインジェクションを調べる研究は、メールやカレンダーなどのダミー環境を用いたものであり、最新製品の実際の事故率や、本記事で提示した設計による防止率を測定したものではありません。しかし、AIへの「指示（プロンプト）」だけでシステム的な操作を完全に制御することは困難です。そのため、AIの性能に依存するのではなく、送信直前の承認プロセスや送信経路の制限など、システム側で実行を止める仕組みを設けることが重要です。

Q4. AIが作成した下書きに添付ファイルがある場合、承認時にどのような点に注意すべきですか？

添付ファイルの名前だけでなく、ファイルの中身を人が直接開いて確認する必要があります。AIは添付ファイルの内容を直接確認できない場合があるためです。たとえば、Claude公式のGmailコネクターでは、添付ファイルのメタデータを参照することはできても、内容そのものは直接読めない仕様となっています。AIが中身を正確に把握できないまま下書きにファイルを添付している可能性があるため、人が妥当性を確認しない限り、誤った資料が送付される原因になります。