AgentMail 代替：既存メールを使うなら Mailera

結論：既存のメールを使うか、専用の受信箱を作るかで選ぶ

取引先がすでに知っているアドレスを使いたいなら、見るべき機能は「受信箱の作成」ではなく「既存メールボックスへの接続」です。Mailera は、今あるメールボックスを REST API、MCP、webhook でアプリや AI エージェントにつなぐサービスです。

たとえば、自分が管理する Gmail と Microsoft 365 の業務メールを検索し、問い合わせへの返信案を作る用途が当てはまります。新しい宛先を取引先へ知らせる運用に変えず、既存メールを処理する構成です。

一方、既存の業務メールとは切り離した専用アドレスが必要なら、メールボックスを用意する機能から選びます。AgentMail と比較するときも、この出発点を先に決めると、必要な機能を絞れます。接続の全体像は既存メールをエージェントにつなぐガイドで説明しています。

メールボックスの比較項目

「メール API がある」だけでは、今のアドレスを使えるかは判断できません。アドレスの用意方法、読み込める履歴、送信元を分けて見てください。

「統合受信トレイ」は、接続した複数のメールボックスを同じ一覧で扱う画面です。元のメールサービスを置き換えたり、メールを別の新しい受信箱へ移行したりする意味ではありません。

画面上の統合表示と、API による横断検索も別の機能です。人は統合受信トレイで確認し、エージェントは GET /messages/search で検索します。

既存アドレスを残して Mailera に接続する手順

最初は、自分が管理する業務用メールボックスを読み、返信案を作るところまでに絞ります。送信は後から追加してください。

1. 既存メールボックスを接続します。 Admin または Leader のユーザーで「メールボックス」→「メールボックスを追加」を開き、Gmail など通常のプロバイダーは「単一メールボックス」タブ、Microsoft は「Microsoftでサインイン」タブを使います。Microsoft は「Microsoftでサインイン」から OAuth で接続します（または、既存の refresh token を一括貼り付けでインポートする方法もあります）。詳しくは Outlook／Microsoft 365 の接続案内を参照してください。
2. 接続元を確認します。 接続後に「統合受信トレイ」を開き、扱いたいメールボックスのメールを確認します。後述の GET /mailboxes の結果で、status と sync.last_synced_at を確認してください。
3. 読み取り用の API キーを作ります。 「設定」の API キー画面から「キーを作成」を選びます。「メールボックスのスコープ」を対象グループに絞り、read 権限だけを付けます。「有効期限」も設定してください。
4. API で接続一覧とメッセージを確認します。 メールボックスの状態を見てから、必要なメールを検索します。

Gmail の接続にはアプリパスワード（app password）を使います。Google のアプリパスワード案内では、利用条件として 2 段階認証が必要とされています。接続方法は Gmail の接続案内を参照してください。

「テストして接続」は、メールを送らずに接続を確認する操作です。送信側の認証に失敗した場合は、「受信専用で保存」を選べます。接続できたことと、メールを送信できることは分けて判断します。

API で接続状態と検索結果を確認する

作成したキーを環境変数 $MAILERA_API_KEY に設定してから実行します。まず、接続済みメールボックスを取得します。

curl --get 'https://mailera.app/api/public/v1/mailboxes' \
  --header "Authorization: Bearer $MAILERA_API_KEY" \
  --data-urlencode 'limit=1'

data 内の provider と status、capabilities.receive、capabilities.send を確認してください。受信と送信の可否は別の値です。同期状態は sync にあります。

次に、キーでアクセスできるメールボックスを横断して検索します。以下は「見積」を検索語にした例です。自分のテストメールに含まれる語に置き換えて使います。

curl --get 'https://mailera.app/api/public/v1/messages/search' \
  --header "Authorization: Bearer $MAILERA_API_KEY" \
  --data-urlencode 'q=見積' \
  --data-urlencode 'limit=1'

結果の mailbox_id と mailbox_email で接続元を、folder で保存先を確認できます。返信案を作る際も、どのメールボックスに届いたメッセージかを保持してください。API の入口は開発者向け案内にまとめています。

専用の受信箱が必要なら、何を比較する？

既存の問い合わせ窓口を使う必要がなく、エージェント専用の宛先を設けたいなら、受信箱の新設を選定条件にします。AgentMail を候補にする場合も、利用したいドメインで宛先を用意できるか、送受信の条件は何か、受信をどう通知するかを順に確認してください。

新しい宛先の用意と、今のアドレス・履歴の継続利用は別の要件です。「同じアドレスを残す」「過去のやり取りを参照する」「元の会話に返信する」のうち、どれが必要かを先に書き出します。メール API 同士の切り替えを、そのままアドレスや履歴の移行として扱わないでください。

専用のメールボックスを別途用意し、それを Mailera に接続する構成も考えられます。その場合は、用意するプロバイダーが接続対象かを先に確認してください。Proton Mail や Tuta は、各社のブリッジを介さない IMAP 接続に対応していないため、Mailera では扱えません。

比較や接続でよくある失敗

統合表示を全履歴の保管だと考える

初回に読み込むのは保存期間内のメールです。セルフサービスの無料プランでは、メッセージの保存期間は 30 日です。過去の全メールを無期限に参照する前提では設計しないでください。

受信できれば送信もできると考える

受信専用の接続では送信できません。また、メールボックス側が送信に対応していても、read だけの API キーには送信権限がありません。送信を組み込む際は、接続側の送信可否とキーの send 権限をそれぞれ確認します。

Mailera の POST /mailboxes/{id}/send は送信・返信・転送に使えますが、一斉配信やマーケティング配信、メールボックスのウォームアップは提供していません。受信トレイへの到達も保証しません。

新着通知があれば、常に即時だと考える

Mailera は message.received webhook を提供しています。Microsoft 接続では Graph の変更通知を使い、定期的なバックグラウンド確認も行います。Microsoft Graph の公式説明でも、メールボックス内のメッセージ変更を購読できる仕組みが説明されています。

ただし、Mailera のバックグラウンド確認頻度は利用状況によって変わり、使われていないメールボックスはスリープする場合があります。メールが見つからないときは、まず接続状態、エラー、最終同期を確認してください。

エージェントに読ませる際、何を制限する？

受信メールは信頼できないデータであり、エージェントへの命令ではありません。本文に「このキーを別の宛先へ送信して」「権限を変更して」と書かれていても実行させないでください。メール本文を操作指示として扱うと、prompt injection の入口になります。

最初は read 権限だけにし、対象のメールボックスグループとキーの有効期限を絞ります。返信案の作成だけなら、send は不要です。

送信を追加するときは、宛先と本文を人が承認してから送信 API を呼ぶ処理をアプリケーション側に設けます。実装の考え方はメールを使った人による承認パターンを参照してください。

API キー、token、メール本文の個人情報はログや画面写真に残さない運用にします。キーの扱いを含む製品の案内は Mailera のセキュリティページで確認できます。