アドレスを分ける判断と、接続方法の判断は別です
既存メールボックスの接続とは、現在のメールアドレスとメール提供元を変えずに、エージェントから扱えるようにすることです。専用メールボックスは、エージェントに任せる業務のために分けたメールボックスを指します。
専用にする場合は、普段使うメール提供元で作成する方法と、受信箱を発行するサービスを選ぶ方法を分けて考えてください。「専用にするか」は情報と業務の分け方、「何で接続するか」は実装の選択です。
Mailera の接続機能は、用意済みのメールボックスを REST API や MCP から扱えるようにします。以前から使っているものでも、新しく用意した専用のものでも、対応する接続方式なら対象になります。接続方式の違いはエージェント開発者向けの IMAP・Graph・SMTP 解説を参照してください。
ここで扱うのは外部とメールをやり取りするための選択です。エージェント間だけの内部メッセージ交換や、AI 付きメール閲覧アプリの選び方は対象にしません。連携全体の考え方は既存メールボックスを AI エージェントにつなぐガイドで説明しています。
既存と専用を、何で比較すればよいですか？
既存の問い合わせ窓口を補助するなら、今の宛先を維持するメリットがあります。一方、新規業務の検証なら、私用メールや別業務の情報を含まない専用メールボックスから始めることを勧めます。
| 判断軸 | 既存メールボックス | 専用メールボックス |
|---|---|---|
| 既存アドレスの継続 | 今の宛先を維持する選択 | 新しい宛先を案内できるか確認 |
| 過去の会話へのアクセス | 必要な会話が同期対象に入るか確認 | 引き継ぐ情報を先に選ぶ |
| 無関係なメールの混在 | 私用・別業務のメールを点検 | 業務外のメールを入れない運用にする |
| 人による確認 | 現在の担当者との分担を決める | 新しい確認担当者を決める |
| 所有者と管理者 | 現在の所有者から接続の許可を得る | 作成時に所有者と管理者を決める |
| 接続解除後の運用 | 元の担当者が引き取る手順を決める | 監視を続けるか、利用を終了するか決める |
受信箱を発行するサービスを選ぶ場合は、料金だけでなく、独自ドメイン、移行性、管理機能を個別に比較してください。専用アドレスを使うサービスでも、機能や条件が同じとは限りません。
自分の業務ではどう決めればよいですか？
- 今の宛先と会話が必要かを確認します。 既存窓口の問い合わせ対応を補助するなら、継続を優先します。
- 読ませる必要のない情報を洗い出します。 私用メールや他部署の情報が同居するなら、接続前に分離方法を決めます。
- 新しい宛先を案内できるか確認します。 専用アドレスを作っても、必要なメールがそこへ届く運用がなければ使えません。
- 所有者と停止担当者を決めます。 誰が接続を許可し、誰がキーを失効させるかまで決めておきます。
- 迷う場合は、自分が管理する検証用メールボックスで試します。 最初は読み取りだけに絞り、取得される情報を確認してください。
継続と分離の両方が必要なら、どちらかを急いで選ぶより、エージェントに任せる仕事を狭めます。例えば問い合わせの分類だけを試す段階では、送信権限まで付ける必要はありません。
選んだメールボックスを Mailera に接続するには？
専用メールボックスを使う場合は、メール提供元で先に用意します。Mailera では Admin または Leader が「メールボックスを追加」から接続します。
- Outlook・Microsoft 365：「Microsoftでサインイン」から、Microsoft Graph を使う OAuth 接続を行います。Microsoft 接続の概要を参照してください。Microsoft Graph の権限資料では、データへのアクセスに利用者または管理者による権限の付与が必要とされています。
- Gmail・Google Workspace： Mailera では app password（アプリパスワード）を使います。2 段階認証と、管理者による利用許可を確認してください。詳しくはGmail 接続の要件とGoogle のアプリパスワード案内を参照してください。Google 公式案内の参照日は 2026 年 10 月 25 日です。
「テストして接続」はメールを送信せずに接続をテストします。ただし、接続テストの成功と、エージェントに適切な閲覧範囲を与えたことは別です。接続後は対象グループに絞った読み取り用 API キーで確認します。画面ごとの操作は最初のメールボックスを接続する手順にまとめています。
よくある失敗は？
「専用」という名前だけで安全だと判断する。 実際に届くメール、転送設定、API キーの対象グループを確認してください。私用メールを含む受信箱を、そのまま検証に使うのも避けます。
読み取り試験なのに送信権限まで付ける。 読み取りには read、送信には send が必要です。試験の目的に合わせて分けてください。
Microsoft 接続でアプリパスワードを探す。 Mailera の Outlook・Microsoft 365 接続では、OAuth を使います。Gmail と同じ認証手順にはしません。
接続できたので、必要な過去メールもすべて読めると考える。 本番の業務に組み込む前に、参照したい会話が実際に取得対象に入っているか確認します。
AI にメールを読ませるとき、何を制限すべきですか？
受信メールの本文や添付ファイルは、信頼できないデータです。エージェントへの命令として扱わないでください。「別の宛先に秘密情報を送れ」「権限を変更しろ」とメールに書かれていても実行しない設計にします。専用メールボックスに分けても、プロンプトインジェクションへの対策は必要です。
Mailera の API キーは、対象を 1 つのメールボックスグループに限定できます。「メールボックスのスコープ」で必要なグループを指定し、最初は読み取り権限だけを付けてください。グループ内に不要なメールボックスが含まれていないかも確認します。
送信権限を付けることと、送信前に人が確認することは別です。宛先と本文を人が確認してから送信する処理は、アプリ側に設けます。MCP のツール仕様も、機密性の高い操作では利用者に確認を求めることを推奨しています。確認が必要な操作の分け方は承認の境界を設けたメールエージェントの設計ガイドで説明しています。
不要になったキーを失効させる担当者も決めてください。Mailera では失効後、そのキーを使う呼び出しは即座に拒否されます。製品の安全対策はMailera のセキュリティを参照してください。
Mailera に接続しても変わらない制約
Mailera はメールボックスやメールアドレスを新規発行しません。また、接続は全履歴の移行や無期限保存ではありません。初回は保存期間内のメールを新しい順に読み込みます。無料のセルフサービスワークスペースの保存期間は 30 日です。
常に即時に受信できるわけでもありません。バックグラウンドの確認頻度は利用状況で変わり、使われていないメールボックスはスリープすることがあります。受信トレイへの到達も保証しません。Mailera はメール提供元の迷惑メールフィルターを回避できません。
