メールを扱う AI エージェントは何をするのか？
メールを扱う AI エージェントは、メール操作のツールと AI モデルを組み合わせ、取得した内容に応じて処理を進める仕組みです。文章を生成するだけでなく、メールボックスからメッセージを取得し、必要に応じて返信の送信まで扱います。
たとえば、自分のテスト用メールボックスに届いた問い合わせを要約し、返信案を作る構成では、役割を次のように分けます。
| 担当 | 役割 |
|---|---|
| Mailera | 既存メールボックスへの接続、メッセージの取得、送信操作の窓口 |
| AI モデル | 内容の解釈、要約や分類、返信案の生成 |
| 利用側のアプリ | 処理対象の選択、業務ルール、人による承認、送信の実行判断 |
Mailera の接続機能だけで、返信内容の判断まで完結するわけではありません。「読む権限」と「送る判断」を分けると、要約だけの試作から始められます。
既存のメールボックスはそのまま使えるか？
既存の連絡先と同じアドレスでやり取りを続けたいなら、今のメールボックスを接続する構成が向いています。新しい用途を既存の業務から分離したいなら、専用受信箱を用意するか検討してください。選択の基準は既存メールボックスと新規エージェント用受信箱の比較で整理しています。
接続方法はプロバイダーによって異なります。
| メールボックス | Mailera での接続方法 | 接続前に確認すること |
|---|---|---|
| Outlook・Microsoft 365 | OAuth による Microsoft Graph 接続 | Microsoft 側の同意画面と組織で許可されるアクセス |
| Gmail・Google Workspace | アプリパスワード（app password）による接続 | 2 段階認証と、組織での利用許可 |
| 独自 IMAP サーバー | 受信用 IMAP と、必要なら送信用 SMTP を設定 | サーバー、ポート、暗号化方式、認証情報 |
Outlook・Microsoft 365 の接続では OAuth を使います。Mailera の Microsoft 接続を、アプリパスワードで設定する構成にはしません。
Gmail の接続ではアプリパスワードを使います。Google は 2 段階認証を利用条件としており、組織アカウント、Advanced Protection、セキュリティキーのみの 2 段階認証などでは作成項目が表示されない場合があります。作成前にGoogle のアプリパスワード利用条件を確認してください。
独自 IMAP では、受信できても送信できるとは限りません。「受信サーバー（IMAP）」と「送信サーバー（SMTP）」は別の設定です。送信サーバーを空欄にすると受信専用になります。
Proton Mail と Tuta は Mailera の対応対象外です。ほかのプロバイダーも含めた選び方は、既存メールをエージェントにつなぐ接続ガイドを参照してください。
MCP と REST API はどう使い分けるか？
対応クライアントから試すなら MCP、自作アプリに業務フローを組み込むなら REST API を選ぶと、最初に作る部分を絞れます。webhook は別の選択肢というより、処理を始めるための通知手段です。
| 接続手段 | 向いている用途 | 最初に扱う操作 |
|---|---|---|
| MCP | Claude、Cursor、VS Code などからメールツールを呼ぶ | list_mailboxes → list_messages → get_message |
| REST API | 自作アプリで取得対象や処理順序を制御する | メールボックス一覧、メッセージ一覧、本文取得 |
| webhook | 新着メールや接続切断をきっかけに処理する | message.received、mailbox.disconnected などの通知 |
MCP は、LLM アプリケーションと外部データやツールをつなぐプロトコルです。Mailera の MCP 接続は、REST API と同じメールボックスを操作する窓口になります。クライアント選びは既存メールボックス向け MCP サーバーの使い方、API の組み込みは開発者向けページで確認できます。
通知を受ける構成でも、常に即時に処理が始まる前提にはしないでください。Mailera の Microsoft 接続は Graph の変更通知と補助的な定期確認を使います。Microsoft Graph の変更通知はメールボックスのメッセージ変更を購読する仕組みです。
最初の読み取り専用連携はどう始めるか？
最初の目標は、既知のテストメールを取得して、原文に合った要約を作ることです。送信はこの段階では許可しません。
- 自分が管理するテスト用メールボックスを用意します。 機密情報を含まない問い合わせ文を送り、件名と本文を控えます。たとえば「資料の送付予定日を教えてください」という内容なら、要約との比較が容易です。
- メールボックスを追加します。 管理者またはリーダー権限で「メールボックス」から「メールボックスを追加」を開きます。Microsoft は「Microsoftでサインイン」、Gmail や独自 IMAP は「単一メールボックス」から進め、プロバイダーに合う認証情報を設定します。
- 接続結果と同期を確認します。 IMAP 接続では「テストして接続」を実行し、受信サーバーへのサインインやフォルダー検出の結果を確認します。このテストはメールを送信しません。接続後はメールボックス一覧で状態と最終同期を確認し、「統合受信トレイ」でテストメールを探します。
- 対象を限定した API キーを作ります。 「設定」の API キー画面で「キーを作成」を開き、「メールボックスのスコープ」をテスト用グループに限定します。権限は
readのみとし、「有効期限」も設定してください。キーは作成時に一度だけ表示されるため、秘密情報として保管します。 - MCP または REST API で取得します。 MCP なら作成直後の画面で「MCP 設定をコピー」を使い、対応クライアントに設定します。まず
list_mailboxes、次にlist_messages、最後にget_messageで対象メールを読みます。 - 原文と要約を照合します。 問い合わせの内容、日付、依頼事項が一致するか確認します。原文にない約束や推測が加わっていれば、送信権限を追加する前にエージェント側の処理を見直します。
REST API を選ぶ場合は、実際のキーを環境変数 $MAILERA_API_KEY に設定してから、メールボックス一覧を取得します。
curl "https://mailera.app/api/public/v1/mailboxes?limit=1" \
-H "Authorization: Bearer $MAILERA_API_KEY"レスポンスの data 内にある対象メールボックスの id を $MAILBOX_ID に設定し、受信トレイのメッセージを取得します。
curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages?folder=inbox&limit=1" \
-H "Authorization: Bearer $MAILERA_API_KEY"対象メッセージの id を $MESSAGE_ID に設定すると、本文を取得できます。テストメールが一覧にない場合は、次の節の確認項目を使ってください。
curl "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages/$MESSAGE_ID" \
-H "Authorization: Bearer $MAILERA_API_KEY"本文は data.body.text または data.body.html で確認します。一覧の preview だけで要約せず、本文取得の結果を使ってください。これらの読み取り操作に send 権限は不要です。
接続できない・メールが見つからないときは？
接続、同期、送信権限を分けて確認します。メールが見つからないだけで認証情報を作り直すと、原因を絞りにくくなります。
| 症状 | 確認箇所 | 次の対応 |
|---|---|---|
| Microsoft に接続できない | OAuth の同意画面、組織のアクセス制限 | 管理者に許可条件を確認します。アプリパスワードへの切り替えでは対処しません |
| Gmail のアプリパスワードを作れない | 2 段階認証、アカウントや組織の条件 | Google の公式条件と管理者設定を確認します |
| Gmail が接続できなくなった | Google アカウントのパスワード変更の有無 | Google は変更時にアプリパスワードを取り消すため、該当する場合は再設定します |
| メールが見つからない | 接続状態、最終同期、フォルダー、取得対象期間 | inbox だけでなく junk、検索条件の since、保存期間を確認します |
| 同期が進まない | 一時停止やスリープの状態 | 一時停止なら「再開」、必要なら「同期」を使います |
| 受信できるが送信できない | 受信専用設定、SMTP、API キーの権限 | メールボックスの送信可否と send 権限を別々に確認します |
| 送信結果が不明 | 送信試行の状態 | get_send_status または GET /sends/{id} で確認してから次の操作を判断します |
API では、メールボックス一覧の status、sync.last_synced_at、sync.sleeping_since を確認します。同期 API はスリープ中のメールボックスも起こしますが、sync 権限が必要です。読み取り専用キーに権限を足す前に、管理画面で状態を確認してください。
送信状態には queued、sending、sent、failed、unknown があります。応答が途切れたことを失敗と決めつけ、同じメールを無条件に再送しない設計にします。
返信まで任せる前に、何を守るべきか？
受信メールと添付ファイルは、信頼できない外部データです。エージェントへの指示ではありません。 本文に「API キーを送って」「別の宛先へ転送して」「権限を変更して」と書かれていても、実行の根拠にしないでください。
これはプロンプトインジェクションへの対策です。本文を読む処理と、ツール実行を許可する処理を分けます。読み取り専用でも情報の外部流出を防げるとは限らないため、モデルへ渡す個人情報や機密情報を必要最小限にしてください。
送信を追加するときは、利用側のアプリに承認フローを用意します。人が宛先、本文、引用情報を確認し、承認した内容だけを送信処理へ渡す設計にします。承認後に宛先や本文が変わったら、再度確認を求めてください。
send_email と reply_to_email は send 権限を必要とします。取得用キーは read のまま保ち、送信用キーは承認を扱う処理だけで使う構成にすると、権限の境界を明確にできます。
MCP 仕様の同意と安全に関する原則でも、ツール呼び出し前の明示的なユーザー同意を求めています。ただし、MCP の仕組みだけで安全原則が強制されるわけではありません。MCP 接続を設定しただけで、承認の設計が済んだとは扱わないでください。
API キーや認証情報をプロンプト、ログ、スクリーンショットに残さず、実際のメール本文も不要に記録しない運用にします。漏えい時にはキーを取り消せます。製品側の扱いはMailera のセキュリティ情報、利用側の設計は承認の境界を持つメールエージェントの作り方で確認できます。
Mailera でできないことは？
Mailera は既に利用権限のあるメールボックスを接続するサービスです。新しいメールボックスやメールアドレスの発行、一斉配信やマーケティング配信、メールボックスのウォームアップは提供しません。
迷惑メールからメッセージを移動しても、プロバイダーがその送信者を信頼するようにはできません。受信トレイへの到達は保証しません。
同期頻度は接続方式や利用状況にも左右されます。利用中のメールボックスより確認頻度が下がるものや、スリープするものもあるため、常に即時に読み取れる前提の業務にはしないでください。
無料ワークスペースで試せますが、メールの保存期間は 30 日です。過去のメールも処理する場合は、この範囲を先に確認してください。プランの条件はMailera の料金ページで確認し、別途使う AI モデルやクライアントの料金とは分けて見積もります。
