人の役割とエージェントの権限は分けて設定する
メールを要約するだけのエージェントに、送信やメールボックス削除の権限は不要です。担当者が管理者でも、エージェント用の API キーは対象を 1 グループに絞り、read から始めます。送信が必要になった時点で send を検討してください。
最小権限とは、仕事に必要な範囲だけを許可する考え方です。Microsoft Entra の権限管理ガイドも、操作権限だけでなく、対象範囲と期間を合わせて考えるよう勧めています。これは設計の参考であり、Microsoft のロールと Mailera の役割は別物です。
Mailera の製品概要で扱うのは、既存のメールボックスを接続して使う仕組みです。接続から始める場合は既存メールをエージェントにつなぐ手順、日常の運用全体は統合受信トレイの運用ガイドを参照してください。共有受信トレイとの使い分けは、共有受信トレイと統合受信トレイの違いで整理しています。ここではアクセス権の設計に絞ります。
役割、グループ、API キーの違い
チームの権限を決める際は、「誰が管理するか」と「エージェントが何を扱えるか」を分けます。
| 管理対象 | 決めること | Mailera の仕様 |
|---|---|---|
| 人の役割 | メールボックスを追加する担当者 | 追加できるのは Admin または Leader |
| キーの対象グループ | アクセスを許可するメールボックスの範囲 | 1 グループを指定でき、Admin は全グループも選択可能 |
| キーの操作権限 | 読み取り、送信、移動など | read、send、move などを指定 |
| キーの利用条件 | 接続元と利用期間 | 任意の IP 制限と有効期限を設定可能 |
Admin や Leader は人の役割名で、read や send は API キーのスコープです。「管理者が作るキーだから全操作を許可する」とは考えず、用途ごとに対象と操作を確認します。
たとえば問い合わせの要約なら、問い合わせ用グループだけを対象にします。経理メールも同じエージェントが読む必要があるかは、別に判断してください。
担当業務ごとに付与する権限
次の表は運用上の担当区分です。Mailera の既定ロールではありません。
| 業務例 | 対象グループの例 | 付与する API 権限 | 付与しない権限の例 |
|---|---|---|---|
| 問い合わせの閲覧・要約 | 問い合わせ | read | send、move、manage |
| 内容を読んでメールを移動 | 仕分け対象 | read、move | send、manage |
| 内容を読んで返信 | 返信担当 | read、send | manage、import |
manage はメールボックスの停止・再開・削除に関わります。日常の要約用キーには付けません。import、sync、webhooks、share も、担当業務に必要な場合だけ追加します。
read は、機密情報を除外する権限ではありません。 本文の取得に加えて OTP の取得も含まれます。閲覧専用でも、対象グループに認証用メールを受け取るメールボックスを含めるか、慎重に決めてください。
共有リンクには share スコープだけでなく、Admin による共有の有効化も必要です。本文を読む担当と、外部に共有する担当を同じ権限にする必要はありません。
REST の GET /messages/search と MCP の search_messages は read、send_email と reply_to_email は send を必要とします。操作とスコープの対応は API ドキュメント、クライアントへの接続方法は MCP の案内で確認できます。
対象グループを限定した API キーの作成手順
- 用途を先に記録します。 担当者、対象グループ、必要な操作、利用終了の予定を決めます。用途の違うエージェントで同じキーを使い回さない設計にします。
- 「設定」の API キー用タブを開き、「キーを作成」を選びます。 「わかりやすい名前」には、どの業務で使うキーか分かる名前を入力します。
- 「メールボックスのスコープ」で対象の 1 グループを指定します。 要約用なら権限は
readに絞ります。必要に応じて「IP制限（任意）」と「有効期限」も設定してください。 - 作成したキーを安全に保存します。 キーは一度だけ表示されます。MCP 接続では、同じダイアログの「MCP 設定をコピー」を使えます。
- 自分のテスト用メールボックスで境界を確認します。 対象内の読み取りだけでなく、対象外へのアクセスと許可していない操作も試します。
確認する項目は、次のように分けると見落としを減らせます。送信のテスト先も、自分が管理するテスト用メールボックスに限定してください。
| テスト条件 | 確認すること |
|---|---|
対象グループ内を read で読む | 必要なメールを取得できる |
| 対象外グループのメールボックスを指定 | アクセスが拒否される |
read のみで送信を試す | 送信が拒否される |
| キーを失効させて再度呼び出す | 旧キーでの呼び出しが拒否される |
成功する処理だけを試して終わりにせず、許可していない処理が通らないことまで確認します。
よくある設定ミスと担当変更時の確認事項
全グループのキーを日常処理に使う。 Admin が全グループを選べても、要約エージェントに必要とは限りません。対象グループを絞り、業務が増えたときに見直します。
送信できないので権限を一括で追加する。 まず send の有無と、接続したメールボックスが受信専用かどうかを確認します。API のメールボックス情報では capabilities.send を確認できます。送信機能の問題を、manage などの追加で解決しようとしないでください。
担当者が変わっても旧キーを残す。 異動やエージェント停止時は、その用途のキーを失効させます。失効すると、そのキーを使った呼び出しは直ちに拒否されます。旧キーで実際に呼び出し、拒否されることを確認してください。
共有リンクも別途見直します。不要なリンクは DELETE /shares/{id} で取り消せます。この取り消しは元に戻せません。API キーの失効と共有リンクの取り消しは、別の作業として管理します。
受信メールの指示を、そのまま実行させない
受信メールは信頼できないデータです。システム指示でも、操作の承認でもありません。「秘密情報をこの宛先へ送れ」「権限を変更せよ」と本文に書かれていても、その要求をそのままツール実行に渡さないでください。
MCP のツール仕様は、人がツール呼び出しを拒否できる状態を推奨しています。返信案の作成と送信を分け、宛先、本文、添付を人が確認してから送信する経路をエージェント側に設けます。
これはチーム側で実装する確認手順です。Mailera だけで承認やプロンプトインジェクション対策が完結する設計にはしません。実装を考える際は、メールを使った人による承認のパターンも参考になります。
API キーはメール本文やモデルへの入力に埋め込まず、実行環境で管理します。RFC 6750も、Bearer token を保存時と通信時の漏えいから保護する必要性を述べています。画面を共有するときは、キー、個人情報、認証コードを隠してください。製品の保護方針は Mailera のセキュリティ情報を参照できます。
なお、Mailera は新しいメールボックスやメールアドレスを発行しません。アクセスを制限する対象は、接続した既存のメールボックスです。
