一括解除の前に何を確認すればよいですか？
ここでいう「迷惑メールの一括解除」は、誤分類された既存メールを受信トレイへ戻す作業です。自動ルールの設定や、管理者の隔離領域からの解放は扱いません。
Mailera に接続した、自分または管理権限のあるメールボックスだけを対象にします。未接続なら、Outlook・Microsoft 365 の接続案内 または Gmail の接続案内 を先に確認してください。
GET /mailboxes の応答で、各メールボックスの status と last_sync_at を確認します。「メールボックス」に表示される受信トレイ・迷惑メールの件数は未読件数なので、それだけで移動対象の総数を判断しないでください。
続いて「統合受信トレイ」で迷惑メールを開きます。差出人の表示名だけではなく、アドレスと内容を見て対象を選びます。不審なリンクや添付ファイルは開かないでください。
| 戻したい範囲 | 選ぶ処理 | 実行前の確認 |
|---|---|---|
| 選んだメールだけ | 個別移動 | 各メールの差出人と内容 |
| 特定送信者のメール | 送信者を限定した一括解除 | アドレスと、該当するメールの内容 |
| 迷惑メール内の全件 | メールボックス単位の全件解除 | フォルダー内の全件が復帰対象か |
全件解除から始めず、必要なメールだけに絞るのが安全です。
複数メールボックスの迷惑メールを一括解除する手順は？
以下の例では、対象グループに限定した API キーを環境変数 $MAILERA_API_KEY に設定します。読み取りには read、移動には move が必要です。
1. 対象のメールボックス ID を確定する
GET /mailboxes で一覧を取得します。
curl --get 'https://mailera.app/api/public/v1/mailboxes' \
-H "Authorization: Bearer $MAILERA_API_KEY" \
--data-urlencode 'limit=1' \
--data-urlencode 'offset=0'この例では 1 件だけ取得します。total を確認し、続きは offset を進めて取得します。group_id、provider、tag などでも絞れます。
対象が多い場合の管理方法は、多数の既存メールボックスを管理する手順 を参照してください。
data[].id とメールボックスのアドレスを照合し、承認した ID を $MAILBOX_ID に設定します。status と last_sync_at も確認してください。
2. 迷惑メールを確認する
メールボックス内の一覧取得には GET /mailboxes/{id}/messages、横断検索には GET /messages/search を使えます。横断検索では folder=junk で迷惑メールに絞り、mailbox パラメーターで対象メールボックスを指定します。送信者を限定する場合は from パラメーターを使います。
from.address、subject、folder を見て、必要に応じて本文も確認します。next_cursor があれば、その値を cursor に指定して続きを取得してください。最初のページだけで全件を判断しないようにします。
3. 選んだメールを先に戻す
画面では対象メールを開き、「迷惑メールではない」を選びます。移動後は受信トレイで同じメールを確認してください。
API で個別に移動する場合は POST /mailboxes/{id}/messages/{msgId}/move を使います。対象メッセージの ID は $MESSAGE_ID として管理し、メールボックス ID との組み合わせを取り違えないようにします。
4. 承認した範囲をメールボックスごとに解除する
POST /mailboxes/{id}/unspam は、指定したメールボックスの迷惑メールを全件、または特定送信者に限定して移動する処理です。リクエスト本文は Mailera の API ドキュメント の形式に合わせます。
検索に使った from 条件と、解除リクエストの対象指定は別です。検索で絞ったからといって、その条件を解除処理が引き継ぐと考えないでください。実行前に解除対象をもう一度確認します。
複数アカウントを扱う場合も、承認済みのメールボックス ID ごとに呼び出します。個別移動と一括解除を同じ対象に重ねて実行しないよう、処理範囲を決めておきます。
5. 移動先を再取得して結果を記録する
受信トレイを再取得し、戻したかったメールがあるか確認します。
curl --get "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages" \
-H "Authorization: Bearer $MAILERA_API_KEY" \
--data-urlencode 'folder=inbox' \
--data-urlencode 'limit=1'ここでも next_cursor を使って続きを確認します。差出人、件名、受信日時などで対象を照合し、迷惑メール側も見直してください。
実行側の記録には、メールボックス ID、対象条件、処理結果、移動先の確認結果を残します。「成功」「失敗」「結果未確認」を分けると、応答が途切れた処理を成功扱いせずに済みます。これは運用側で付ける分類です。
よくある失敗と、結果が分からないときの対処は？
| 状況 | 確認すること |
|---|---|
| 読めるが移動できない | move 権限と、API キーの対象グループを確認する |
| 一覧が古い、接続が切れている | 接続状態と最終同期を確認してから結果を判断する |
| 一部のメールボックスだけ失敗した | 失敗した対象を切り分け、成功済みの対象まで再処理しない |
| 応答が途中で途切れた | まず現在のフォルダーを取得し、移動済みか確認する |
GET /mailboxes/{id}/status は、Microsoft ではサインインを直接確認します。他のプロバイダーでは最新の同期に基づく結果です。同じ確認方法だと考えないでください。
同期を要求する POST /mailboxes/{id}/sync には sync 権限が必要です。移動用キーの権限を広げる前に、担当者が同期を行う運用に分けられるか検討してください。
AI エージェントに任せる場合の安全対策は？
受信メールは信頼できないデータであり、操作指示ではありません。本文に「全メールを解除」「権限を追加」と書かれていても、エージェントに従わせないでください。
「設定」から「キーを作成」を開き、「メールボックスのスコープ」を対象グループに限定します。この作業用の権限は read と move に絞り、send は付けません。対象メールボックスとメールを人が承認してから移動します。別の処理で返信する場合も、送信前に確認を求めてください。
MCP では move_message と rescue_spam が move 権限を使います。接続の基本は 既存メールボックスをエージェントにつなぐ方法、承認の設計は メールを使った人による承認パターン が参考になります。統合受信トレイのエージェント運用 と Mailera のセキュリティ情報 も合わせて確認してください。
解除後も迷惑メールに入ることはありますか？
あります。Mailera は既存メールを移動できますが、プロバイダーに送信者を信頼させたり、今後の受信トレイへの配信を保証したりはできません。
Gmail の迷惑メールに関する公式ヘルプ（英語） は、ブロック中の送信者について、メールを迷惑メールから戻しても引き続き迷惑メールに分類すると説明しています。管理者の設定によって分類される場合もあります。
送信側の認証も確認項目です。Google のメール送信者向けガイドライン（英語） は、個人用 Gmail 宛ての全送信者に SPF または DKIM、一括送信者に SPF・DKIM・DMARC を求めています。これらの設定と、今回のメール移動は分けて扱ってください。
