AIにメールアドレスを教えるのと受信箱アクセスを許可するのは別物：何を認めるべきか

安全かどうかは、実際に行っている3つの異なる行為のどれかによって決まります。フォームにメールアドレスを入力するのは、識別子を共有することです。アシスタントに1つの受信箱を読む許可を与えるのは、その受信箱の中身を共有することです。連携機能でメールボックス全体を接続するのは、何年分ものメッセージと、それらに対して操作する能力を共有しえます。これらはフォームの入力欄や同意画面では一つの決断のように見えますが、結果は大きく異なり、別々に決められるものです。

この記事は、その決断を意識的に行うためのものです。連携ができることを確認し、一回限りのタスクには必要な分だけを与え、タスクが終わったら各権限を閉じます。

アドレス共有・受信箱アクセス・メールボックス全体の接続

アドレスを共有するとは、アシスタントがあなたのメールを登録フォームやメッセージヘッダーに入力することです。サイトはそのアドレスを知りますが、アシスタントが得るものはすでに持っていたもの以上ではありません。新しい場所に何かが届くわけでも、アドレスを知っただけでメールを読める人がいるわけでもありません。

受信箱アクセスとは、アシスタントがメールボックスを開き、届いたものを読めるようにする認証情報や権限です。狭くも（1つのメールボックス、読み取り専用、寿命1時間）、広くもできます。「アクセス」という言葉がこの違いを隠すので、次のセクションがあります。

メールボックス全体の接続とは、メールボックス連携が要求しうるものです。メッセージ履歴へのアクセスや、送信・削除といった操作です。実際にメールを管理する継続的なアシスタントには有用ですが、「確認コードを1つ取ってきて」には過剰です。

連携が実際にできることを確認する

許可する前に、機能名ではなく要求されたスコープを見てください。「メールを要約する」アシスタントが、送信、削除、メール変更の権限を持ち続けているかもしれません。OWASPの過剰な代理権（excessive agency）に関するガイダンスはこのパターンを明確にしています。要約のためにメールを読む拡張は読み取り権限だけを持つべきで、影響の大きい操作には人間の承認を要求すべきだと（OWASP LLM06）。

4つの点を確認します。

• スコープ： 読み取り、送信、削除、設定。この権限が実際に与えるのはどれか？
• 範囲： 1つのメールボックスかアカウント全体か？新着メールだけか、履歴全体か？
• 永続性： 権限はタスクとともに終わるか、自分で取り消すまで有効なままか？この連携がタスクで失効するか確認してください。しないなら、タスクは終わっても扉は開いたままです。
• 他のツール： このアクセスを持っている間、アシスタントは他に何に触れられるか。ブラウザ、ファイル、接続済みの他サービスなど。

最後の点は見た目以上に重要です。受信メールは信頼できない入力であり、メッセージにはアシスタントを誘導するために書かれたテキストが含まれえます。これは仮定の話ではありません。CVE-2026-33654は、nanobotアシスタントのメールチャネルにおけるプロンプトインジェクション脆弱性で、リモートの攻撃者が1通のメールを送るだけで、所有者が何もしないうちにモデルに指示を実行させシステムツールを呼び出せました。これは一製品の欠陥であり、すべてのAIメール機能の性質ではありませんが、受信箱そのものと同じくらい、受信箱を取り巻く権限が重要である理由を示しています。メッセージのテキストがどうやって指示になるかの仕組みは、メール利用者のためのプロンプトインジェクションで解説しています。

タスク専用の受信専用受信箱を優先する

確認コード、確認メール、ダウンロードリンクなど、メールを受け取るだけでよい低リスクのタスクには、そのタスク専用に作られたメールボックスが、必要最小限の選択肢です。

TempMail.Bestでは、エージェントが10分または1時間の有効期間を持つメールボックスを作成し、新着メールを待ち、メッセージを読み、終わったらメールボックスを削除できます。サービスは受信専用です。そのアドレスからメールを送ることはできません。エージェントの認証情報が開くのはそのメールボックスだけで、背後にアカウントはなく、中に履歴もありません。

拡大解釈されがちな2つの限界があるので、正確に述べておきます。

• 別の受信箱は、その受信箱だけを露出します——アシスタントの他の権限とツールが同じくらい限定されている場合に限ります。同じアシスタントがファイルやブラウザにも触れられるなら、受信箱の境界は、誤誘導されたアシスタントがそれらを通じてできることを小さくしません。
• 「受信専用」はこのサービスの説明です。エージェントはTempMail.Bestを通じてメールを送ることはできませんが、この一時メールボックスを削除することはできます。そして、他の接続済みサービスを通じてできることは、ここの何ものによっても影響を受けません。

タスクに紐づいた受信箱のモデルについては、AIエージェント受信箱とはで説明しています。

許可すべきでないとき

以下を伴うタスクには、一時受信箱も、AIへのメールボックスアクセス全般も使わないでください。

• 銀行、決済、投資、異議申し立てや返金の可能性がある購入
• 医療、保険、行政サービス、身分証明書
• 仕事のメール、メインアカウント、機密の会話
• パスワードリセット、復旧リンク、セキュリティ設定の変更
• 更新・解約・復旧が必要になりうるサブスクリプションやサービス
• アシスタントが承認なしにメールを送信したりアカウントを変更したりしうるすべてのフロー

永続的なアカウントには、長期で管理できるアドレスか、管理型転送エイリアスを使います。サイトが使い捨てアドレスを拒否したら、それを尊重してください。そのタスクは、そもそも一時受信箱向きではないのかもしれません。

タスクを閉じ、各権限を解除する

アシスタントが完了を報告したら、まず結果を確認します。コードは機能したか、ダウンロードは手元にあるか、アカウントは存在するか。それから、2つの別々のシステムが関わるため、2つの別々の手順でアクセスを閉じます。

1. 一時メールボックスを削除する。 これでその受信箱のエージェント認証情報が終わり、メッセージも削除されます。メールボックスはどのみち予定どおり期限切れになりますが、タスク完了時に閉じることで露出する期間が短くなります。
2. サードパーティの権限を取り消す。 TempMail.Bestの受信箱を止めても、AIプラットフォーム上のものは何も取り消されません。他の許可済みツール、連携、アクティブなセッションはそちらで管理されており、自分で削除するまで残ります。タスクの前に何を許可したかを確認し、一つずつ元に戻してください。

削除でできないことが1つあります。アシスタントがすでに読んだメールを「未読」に戻したり、他の場所に保存したものを取り消したりすることはできません。露出を抑えるのはタスクの前です。後始末は記憶の問題ではなく、扉の問題です。

どんなメールタスクを許可する前にも、AIエージェントのメール認証の事前チェックを実行してください。問いは「AIが全体的に信頼できるか」ではありません。「このタスクにこの範囲のアクセスが必要か」です。一回限りの受信になら、ほとんどの場合、答えはノーです。