AI エージェントにメールへのアクセスを許可する前に

メールを読み、メールボックスを作り、DNS 設定を直してくれるアシスタントは便利です。一方で、指示を読み違えて別のメールボックスを削除してしまうかもしれません。

だからこそ、メール用の MCP サーバーで重要なのは、エージェントに何ができるかだけではありません。間違えたときに何が起きるかです。その影響の多くは、サーバーの周りに設けた権限と制約によって決まります。モデルの能力だけを頼りにしてはいけません。

MCP サーバーの仕組み、メール基盤でできる作業、リスクを減らす対策を見ていきます。トークンの分離、必要最小限の権限、破壊的な操作の確認、活動ログが基本です。ただし、どれかひとつで自律的な運用の安全が保証されるわけではありません。

MCP サーバーとは

Model Context Protocol は、AI クライアントが外部システムのツールを見つけて呼び出すための共通の仕組みです。MCP サーバーは、ツールの名前、説明、引数のスキーマを公開します。クライアントはその情報をモデルに渡し、モデルがツールを選ぶと呼び出しを実行して結果を返します。

利点は、特定のクライアントに依存しないことです。同じサーバーを Claude Desktop、Claude Code、Cursor、Windsurf などの対応アプリで使えます。ただし、通信方式、認可方式、必要な機能への対応は確認が必要です。共通プロトコルはアプリごとの開発を減らしますが、接続設定を不要にするものではありません。

メール基盤には自然に当てはまります。多くの操作がもともと API で提供されているからです。MCP サーバーは REST API の操作をツールとして説明します。そのため、制約はエージェント任せにせず、API、サーバー、クライアント側の連携で適用する必要があります。

MCP サーバー経由でエージェントができること

原文で説明した版には 200 を超えるツールがあり、おおむね次のように分かれています。実際に使えるツールは、版、設定、権限、プランによって異なります。

一部のツールは、秘密情報をモデルに渡さずに使えます。メールクライアントの設定を構造化データで取得でき、Outlook に必要なサーバー、ポート、ユーザー名が分かります。メールボックスのパスワードは含まれません。Apple Mail の構成プロファイルも生成できます。エージェントはパスワードを知らずに従業員の設定を手伝えます。ただし、認証情報を扱う別のツールもあるため、それぞれの権限と応答を確認してください。

トークンを分ける理由

静的トークンでは、基盤へのアクセスとメール本文へのアクセスを分けることが重要です。OAuth 接続では、認可時に付与された権限も適用されます。

分離によって、間違いの影響範囲を小さくできます。新しい従業員のメールボックスを作る自動化に、メールを読む権限は不要です。返信を準備するアシスタントに、ドメインの削除権限も不要です。ただし、メール用トークン、パスワード、転送を管理できる広い管理権限は、間接的なアクセス経路になり得ます。トークンの種類だけでなく、実際の権限を絞ってください。

そのため、管理用トークンの漏えいも重大な事故です。本文を直接読めなくても、何を変更・作成できるかによって被害は変わります。

大まかな権限と細かな権限

各トークンの内部でも、スコープによってアクセスをさらに限定します。OAuth は、利用者に分かりやすい権限グループと API 内の詳しい確認を組み合わせます。

当初の同意画面には、五つの大まかな権限グループがありました。mail:read、mail:write、mail:admin、messages:read、messages:send です。短い一覧は、多数の細かな項目より判断しやすくなります。現在は追加の権限もあるため、実際の画面を読んでください。例えば、下書きの管理と送信は別の能力です。

API は操作ごとに細かな権限を確認します。転送設定を読む場合と変更する場合では、必要な権限が異なります。アクセスを許可するときの分かりやすい分類が、実行時の厳密な確認に代わるわけではありません。

権限はプランとアカウントで現在利用できる機能にも左右されます。原文では、Nano はアドレス検証のみ、Starter は読み取りと検証、Pro と Agency はより広い操作に対応すると説明しています。現在の権限には、ドライブや別途契約したサービスなどの追加機能が含まれる場合があります。プラン名だけで判断せず、トークンを発行するときに利用可能な権限を確認してください。

実務上の原則は、自動化ごとに独立したトークンを発行し、必要最小限の権限だけを与えることです。別の用途に使い回さないでください。複数のスクリプトで共有すると権限が合わさり、どのスクリプトが操作したかも追いにくくなります。詳しくは、API のスコープと権限をご覧ください。

破壊的な操作の確認

モデルが自信を持って答えても、正しいリソースを選んだとは限りません。削除では特に注意が必要です。

メールボックスを削除する最初の呼び出しでは、削除インテントを作成します。この時点では削除しません。確認後に何が起こるかを説明し、関連する設定や実行中の移行など、リソースとリスクの情報を返します。有効期間は既定で十分間です。ドメインの削除も同じ手順だとは考えないでください。別の処理になっています。

次の呼び出しでインテントを確認し、明示的な確認ヘッダーが必要になります。その間に影響を読むのは有用ですが、保護の保証ではありません。両方のツールを持つエージェントは、両方の操作を実行できます。人の承認が必要なら、独立した承認手順を設け、確認操作へのアクセスを制限してください。

削除したメールボックスは、まずごみ箱に移ります。保持期間内は復元できますが、完全に消去された後は戻せません。ドメインには同じごみ箱がありません。API は利用中のメールボックスがあるドメインの削除を拒否し、エイリアスドメインとの関連も先に解消する必要があります。アカウント削除には別の影響があり、メールボックスの手順によって元に戻せるようにはなりません。

メール送信と移行には、それぞれ専用の制約があります。詳しくは、安全上の制約と削除インテントをご覧ください。

再試行と冪等性

タイムアウト後、エージェントは通常のクライアントと同じように再試行することがあります。操作は成功していて応答だけが失われた場合、無対策で再試行するとリソースを重複して作る可能性があります。

対象となる更新操作では、API が冪等キーを使います。結果が保持されている間は、同じリクエストを同じキーで再送してください。保存済みの応答を返し、操作の再実行を避けられます。同じキーで異なるデータを送ると競合になります。無期限に重複を防ぐ保証ではありません。メールボックス作成にも送信にも重要です。同じメールを繰り返し送ると、顧客に悪い印象を与えます。

制限はトークン、アカウント、メールボックス単位で適用される場合があります。制限による拒否を受けたら、クライアントは Retry-After に従って待機します。破壊的な操作には厳しい制限があります。誤ったループを抑えますが、すでに実行した操作や被害は元に戻せません。

監査ログの役割

管理画面の監査イベントでは、トークン、操作、リソース、時刻を確認できます。保持期間は既定で 90 日です。ただし、すべての呼び出しを記録する保証ではありません。対象範囲は操作と設定によって異なり、メールの読み取りは一部だけを抽出して記録する場合があります。

ログは報告書のためだけにあるのではありません。エージェントを常に監視できないとき、操作の経緯をたどる助けになります。例えば、知らないアドレスへの転送を誰が設定したかを調べられます。ただし、アクセス制限の代わりにはならず、どんな疑問にも答えられるだけの情報があるとは限りません。

予期しないトークンの活動を見つける助けにもなります。個別のトークンを失効させれば、その自動化の以後の呼び出しを制限できます。ただし、実行済みの操作と、ほかに有効な認証情報は別に確認してください。

役立つ自動化

最も役立つ作業は、派手ではないものが多いでしょう。

従業員の入社と退社。新しい従業員にはメールボックス、エイリアス、グループ、設定手順が必要です。退社時はアクセスを取り消し、転送とアーカイブの扱いを決めます。自動化はチェックリストを順に実施する助けになりますが、結果の確認は必要です。毎回正しく実行する保証はありません。

代理店の顧客ドメイン設定。ドメイン追加、DNS 設定、メールボックス作成、検証、報告といった繰り返しの手順は、合意した権限内で自動化しやすい作業です。

到達状況の監視。受信サーバーの SMTP 応答を含むバウンス情報を取得し、原因を分類して設定の問題が疑われるものを示します。週次の集計は SPF レコードの不備を見つける助けになりますが、すべての配信障害を検出する保証ではありません。

移行の監督。一括処理を開始し、フォルダー別の進捗を追い、エラーを調べ、照合結果を報告します。タスクの終了をコピーの完全性と混同しないでください。メールの一括移行も参照してください。

読み取り専用で受信トレイを整理。エージェントはメールを要約し、分類を提案できます。そのトークンでは送信できませんが、書き込み権限なしにフラグを変えることもできません。分類やフラグを実際に適用するには、送信を許可せず、必要な権限だけを与えます。

避けたい運用

設定を楽にするために全権限を与えない。何年も後まで、過剰な権限を持つトークンが有効なままかもしれません。

外部宛ての送信を最初から任せない。まず下書きの品質を確認してください。下書きの管理と送信は別の権限ですが、大まかなグループに両方が含まれる場合もあります。実際に与えた権限を確認しましょう。

トークンをリポジトリに保存しない。環境変数や、内容が Git に入らないシークレット管理の仕組みを使います。ログやツールの応答に秘密情報が出ていないかも確認してください。

監査ログを放置しない。最初の週に読み、期待する操作とイベントを比較して、記録されない操作も把握してください。

ドメイン削除を自動化しない。ドメインにはごみ箱がありません。モデルの確認をそのまま繰り返すのではなく、人がリソースと影響を調べる必要があります。

よくある質問

どの AI クライアントが MCP サーバーに対応しますか？

Claude Desktop、Claude Code、Cursor、Windsurf などの MCP 対応アプリです。プロトコルによって連携しやすくなりますが、通信方式、認可、クライアントの版、接続設定は確認が必要です。

エージェントはメールを読めますか？

メール API で直接読むには、読み取り権限のあるメール用トークンか、適切な OAuth 認可が必要です。管理用トークンは本文を直接読みません。ただし、トークン作成、パスワード変更、転送設定の広い権限は、間接的なアクセスにつながる場合があります。不要な権限を与えないでください。

重要なリソースの削除を何が防ぎますか？

メールボックスには、既定で十分間有効な削除インテントと、明示的なヘッダーによる確認があります。完全消去前なら、ごみ箱から復元できます。ただし、人の確認を保証する仕組みではありません。ドメイン削除は別の処理で、ごみ箱がなく、自律的に実行させるべきではありません。

MCP サーバーはメールを AI 事業者へ送りますか？

取得したデータがモデルに渡るかは、クライアントと実行場所によって異なります。クラウドモデルなら外部事業者への転送を伴う場合があり、ローカル処理は別に考える必要があります。アクセスを制限し、データの扱いと間接的な取得経路を確認してください。直接の読み取りを禁止するだけでは、漏えいがない保証にはなりません。

メール操作には別のトークンが必要ですか？

静的トークンでは、基盤とメールで種類を分けています。OAuth では、与えた権限と接続用に作成したトークンも関係します。分離はリスクを減らしますが、広い管理権限がすべて安全になるわけではありません。

エージェントが制限に達するとどうなりますか？

リクエストが拒否されます。クライアントは Retry-After に従い、適切なら後で再試行してください。破壊的な操作の制限は厳しくなっていますが、誤ったループが被害を起こす前に止まる保証ではありません。

先週エージェントがしたことを確認できますか？

管理画面のログで、保存したイベント、トークン、対象リソースを確認できます。既定の保持期間は 90 日です。記録範囲と一部の読み取りの抽出記録に注意してください。すべての呼び出しがログにあるとは限りません。

MCP の利用に追加料金はかかりますか？

原文では API と MCP はプランに含まれ、Nano はアドレス検証、Starter は制限された操作、Pro と Agency はより広い機能に対応すると説明しています。現在のアカウント機能と権限を確認してください。追加サービス、消費クレジット、外部モデルの利用には別途料金がかかる場合があります。