Mcp Emails

MCPEmails

AI エージェントに受信トレイを持たせましょう。 Claude、Cursor、その他の MCP 対応クライアントから、既存のメールボックスを通じてメールの閲覧、検索、送信、整理、予約ができる、ホスト型のModel Context Protocolサーバーです。メールが保存されることはありません。

メールボックスを一度接続し、エージェントに URL を貼り付けるだけで、受信トレイをリアルタイムに操作できます。メールは必要なときに取得され、保持されることはありません。認証情報は保存時に暗号化され、必要なリクエストのためだけに当社のサーバー上で復号されます。

🔗 mcpemails.com · 📚 ドキュメント · 💳 料金

---

目次

• 仕組み
• クイックスタート（エージェントの接続）
• 機能
• ツール
• OAuth スコープ
• 対応プロバイダー
• 料金
• アーキテクチャ
• リポジトリの構成
• ローカル開発
• 環境変数
• データベースとマイグレーション
• デプロイ
• セルフホスティング
• 国際化
• セキュリティモデル

---

仕組み

1. メールボックスを接続します。 mcpemails.comにサインインし、Outlook / Microsoft 365（Microsoft でサインイン、Microsoft Graph 経由）、Gmail（IMAP 経由の Google アプリパスワード）、または任意の IMAP/SMTP アカウント（アプリパスワード）を接続します。認証情報はデータベースに保存される前に AES‑256‑GCM で暗号化されます。
2. アクセス権を取得します。 OAuth 対応クライアント（claude.ai、Claude Desktop、Cursor）は、OAuth 2.0 + PKCE を使ってワンクリックで接続します。それ以外はスコープ付き API キー（mcpe_…）を使います。
3. クライアントをサーバーに接続します。 MCP エンドポイントは単一の URL です。

   https://mcpemails.com/api/mcp
   

4. エージェントが受信トレイを操作します。 inbox_list、email_read（action: "search"）、email_compose（action: "send"）、schedule（action: "create"）などのツールを呼び出します。リクエストごとにプロバイダーからリアルタイムでデータを取得するため、サーバー側でミラーリングやキャッシュは行われません。

権限はキーごとに設定されるため、エージェントに read:email だけを付与したり、削除権限を公開することなく、送信やフォルダー管理の権限を付与したりできます。

クイックスタート（エージェントの接続）

Claude Desktop / Cursor（OAuth）： https://mcpemails.com/api/mcp を指定するリモート MCP サーバーを追加し、同意画面で承認します。エージェントに付与するスコープを選択してください。

API キー（任意の MCP クライアント）： ダッシュボードでキーを作成し、スコープを選択します（必要に応じて、特定の受信トレイだけに制限できます）。その後、ベアラートークンとして送信します。

// Example MCP client config
{
  "mcpServers": {
    "mcpemails": {
      "url": "https://mcpemails.com/api/mcp",
      "headers": { "Authorization": "Bearer mcpe_your_key_here" }
    }
  }
}

プロトコルは HTTP 上の JSON‑RPC 2.0（MCP 2025-06-18、ストリーミング可能なトランスポート）です。各セッションは inbox_list から開始してください。これにより、キーがアクセス可能な受信トレイ、プロバイダーごとの機能、バージョン管理された互換性プロファイルが返されます。このプロファイルは、正規化された操作を exact、different、unavailable として示すため、エージェントはリクエストの内容をひそかに弱めることなく、プロバイダーごとの差異を維持できます。

セットアップガイド

各クライアント向けのコピー＆ペースト可能な手順と、それぞれの設定ファイルの保存場所はこちらです：mcpemails.com/docs/clients。

Claude · Claude Code · ChatGPT · Cursor · VS Code · Cline · Windsurf · Gemini CLI · Zed · JetBrains · Raycast · Warp · curl

機能

• リアルタイムで処理し、保存しません — メールは呼び出しごとにプロバイダーから直接読み取られ、メッセージ本文は保存されません。
• 複数のプロバイダーに対応 — Microsoft Graph（Microsoft でサインイン）経由の Outlook／Microsoft 365、IMAP 経由の Google アプリ パスワードを使った Gmail、およびアプリ パスワードを使った任意の IMAP／SMTP メールボックス（Fastmail、iCloud、Yahoo、Zoho、Yandex、セルフホスト環境など）に対応します。
• プロバイダー経由で送信 — 送信メールは、実際のメールアドレスを差出人として、お客様のプロバイダーの SMTP／API 経由で送信されます。クラウドのアドレスからの接続をプロバイダーが拒否する場合、IMAP／SMTP 接続は当社独自のトンネル（HTTP CONNECT リレー）を経由します。TLS はプロバイダーまでエンドツーエンドで実行されるため、リレーがメールや認証情報を見ることはありません。
• きめ細かなスコープ — 8 つの権限スコープがあり、API キーごと、受信トレイごとに個別に付与できます。
• 一括処理と検索・実行 — 1 回の呼び出しで、数百件までのメッセージを読み取り、移動、削除、またはフラグ付けできます。「検索してから移動／削除」するコンビネーターも利用できます。
• 下書きとスケジュール送信 — 下書きを作成し、将来の送信に向けてメッセージをキューに登録できます（サーバー側で送信）。
• プロバイダーに依存しない検索 — Gmail 構文、Microsoft Graph KQL、IMAP SEARCH は、1 つの email_read（action: "search"）インターフェースで利用できるように統一されています。
• ビジネスでの利用に対応：Business プランでは、複数のワークスペース、役割を設定できる無制限のメンバー、保留中の送信に対する管理者の承認を利用できます。

ツール

直接呼び出せるツールは 21 個です。ほとんどはリソース指向で、特定の操作と、（異なる権限が必要な操作の場合は）必要なスコープを選択する action 引数を受け取ります。

• inbox_list - キーでアクセスできる受信トレイと、それぞれのプロバイダーの機能を一覧表示します。
• email_read - メッセージの一覧表示、読み取り、検索をまとめて実行し、添付ファイル、抽出した添付ファイルのテキスト、元の .eml も取得します。
• email_organize - IDで指定したメッセージを、1件ずつまたはまとめて移動、コピー、フラグ設定、アーカイブします。
• email_search_and_move - 検索条件に一致するすべてのメッセージをフォルダーに移動します。専用のツールであり、破壊的な操作を行うツールです。誤ったフィルターを指定すると、受信トレイ全体が移動されるためです。
• email_delete - メッセージを1件ずつ、まとめて、または検索によってゴミ箱に移動するか、完全に削除します。
• email_compose - ご自身のプロバイダーを通じて、実際のアドレスから送信、返信、転送します。
• folder_list - プロバイダー固有のIDとメッセージ数を含め、フォルダー（Gmailではラベル）を一覧表示します。読み取り専用です。
• folder - フォルダー（Gmailではラベル）を作成、名前変更、削除します。
• draft_list - 受信トレイに保存された下書きを、下書きIDとともに一覧表示します。読み取り専用です。
• draft - プロバイダー固有の返信を含め、下書きを作成、更新、送信、削除します。
• schedule_list - 今後の配信に向けてキューに登録されている内容を一覧表示します。読み取り専用です。
• schedule - メッセージを今後の配信に向けてキューに登録し、キューに登録済みのメッセージをキャンセルします。
• reminder_list - サーバーが管理するフォローアップとスヌーズを、期限到来分、今後の予定分、またはすべてについて一覧表示します。読み取り専用です。ProおよびBusinessで利用できます。
• reminder - 返信のない送信済みメールにフォローアップし、指定した時刻までメッセージを受信トレイからスヌーズします。チャットを閉じている間もサーバー側で実行されます。ProおよびBusinessで利用できます。
• signature_get - 受信トレイに設定されている署名と送信者名を読み取ります。読み取り専用です。
• signature_set - 送信メールに追加する署名と送信者名を設定します。
• automation_read - トリアージルールを一覧表示し、個別のルールを読み取り、実行履歴を表示し、フィルターをドライランします。読み取り専用です。
• automation - モデルを介さずに動作する、無人のトリアージルールを作成、更新、有効化、無効化、削除します。
• contact_search - 保存されたアドレス帳を使わず、最近のメールをリアルタイムでスキャンして連絡先を検索します。
• draft_read - 送信前の下書きを1件、全文読み取ります。たとえば、ユーザーが下書きエディターカードで編集した後に使用します。読み取り専用です。
• draft_editor_hide - 1つの受信トレイまたはワークスペース全体で、チャット内の下書きエディターカードを表示または非表示にします。表示設定のみを変更します。

ツール	アクション	スコープ
inbox_list	(単一アクション)	read:email
email_read	list、read、read_batch、search、attachment、extract、original	read:email（search は search:email も受け付けます）
email_organize	move、move_batch、copy、copy_batch、flag、archive	manage:folders
email_search_and_move	(単一アクション)	manage:folders
email_delete	delete、delete_batch、search_and_delete	delete:email
email_compose	send、reply、forward	send:email
folder_list	(単一アクション)	read:email
folder	create、rename、delete	manage:folders
draft_list	(単一アクション)	manage:drafts
draft	create、reply、update、send、delete	manage:drafts（create/reply/update/delete）、read:email（replyにも必要）、send:email（send）
schedule_list	(単一アクション)	schedule:email
schedule	create、cancel	schedule:email
reminder_list	(単一アクション)	read:email
reminder	follow_up、snooze、done、cancel	manage:automations（snooze とスヌーズの cancel には manage:folders も必要です）
signature_get	(単一アクション)	read:email
signature_set	(単一アクション)	send:email
automation_read	list、get、runs、preview	manage:automations
automation	create、update、enable、disable、delete	manage:automations
contact_search	(単一アクション)	manage:contacts（read:email も受け付けます）
draft_read	(単一アクション)	manage:drafts および read:email
draft_editor_hide	(単一アクション)	manage:drafts
すべてのスコープを持つキーでは、tools/list に29個のツールが表示されます。上記の21個に加えて、手作業で組み立てるのではなく、チャット内のカードを操作するアプリ専用ツールが8個あります。approval_review、approval_decide、approval_update、approval_schedule（保留中の送信）、bulk_execute、bulk_cancel（プレビュー済みの一括操作）、draft_editor_save（下書きエディターの保存ボタン）、card_automation（自動化カードのオン／オフスイッチ）です。6個のapproval_*およびbulk_*ツールには、常に_meta.ui.visibility: ["app"]が設定されています。draft_editor_saveには、下書きエディターが有効な場合にこの設定が付き、無効な場合はすべての呼び出しが拒否されます。card_automationは、カードが有効な場合にのみ一覧に表示されます。

prompts/listには、ユーザーが呼び出す7個のワークフロープロンプト（morning_inbox_triage、find_and_brief、follow_up_radar、decision_tracker、prepare_reply_drafts、clean_up_safely、review_scheduled_sends）があり、それぞれ、必要なスコープを持つキーにのみ表示されます。

注：

• ツールでは、明示的なinbox_id（UUID）またはinboxメールアドレスのいずれかを指定できます。単一受信トレイ用のキーでは、対象が自動的に解決されます。
• 1回の呼び出しで処理できる一括操作の上限は、メッセージの既読化では50件（email_readのread_batch）、移動／削除／フラグ付けでは500件です。
• 対象を指定して変更する場合は、まずemail_readをaction: "search"で使用し、返されたmessage_idまたはmessage_idsをemail_organizeかemail_deleteに渡してください。検索フィールドを指定できるのは、email_search_and_moveと、email_deleteのsearch_and_deleteアクションだけです。
• contact_searchは最近のメールをリアルタイムで検索するため、保存されたアドレス帳はありません。
• email_readのoriginalアクションは、プロバイダーに保存されているMIMEメッセージ全体を1通、ポータブルな.emlファイルとして返します（最大25 MB）。読み取り専用で、メッセージを既読にすることはありません。
• draftのsendアクションにはmanage:draftsではなくsend:emailが必要です。そのため、下書きの管理しかできないキーを使って、メール送信の同意要件を回避することはできません。
• draftのreplyアクションは、元の会話内にプロバイダー標準の未送信の返信を作成します。manage:draftsとread:emailの両方が必要で、既定では送信者のみに返信します。
• 読み取り専用の機能（folder_list、draft_list、schedule_list、signature_get、automation_read）は、2026-09-09に書き込みツールから分離されたため、読み取り専用キーには書き込みツールが表示されません。以前の統合形式（folderのaction: "list"、draftのaction: "list"、scheduleのaction: "list"、signatureのaction: "get"／"set"、automationのaction: "list"／"get"／"runs"／"preview"）は、すでに接続済みのクライアント向けに引き続き受け付けられますが、現在は案内されません。
• automationは、無人で実行するスケジュール済みトリアージルールを管理します。ルールは保存済みの検索と1つの固定アクションで構成され、モデルが介在せず、設定された頻度で評価されます。メールを削除するアクションはなく、forwardは常に人間の承認を待ち、draft_replyは下書きを作成するだけです。docs/automations-trust-boundary.mdを参照してください。
• APIキーの場合、tools/listには、そのスコープで許可されるツールのみが返されます。OAuth接続ではすべてのツールが一覧に表示され、付与されていないスコープが必要な呼び出しには、MCPの追加認証チャレンジ（insufficient_scope）が返されます。

OAuthスコープ

スコープ	許可される操作
read:email	受信トレイとフォルダーの一覧表示、メッセージの一覧表示・読み取り・検索、受信トレイの署名の読み取り、連絡先の検索
search:email	email_readのsearchアクションのみを許可する、より限定的な代替スコープ
send:email	メッセージの送信・返信・転送、署名と差出人名の設定。下書きの送信にも必要
manage:folders	フォルダーの作成・名前変更・削除、メッセージの移動・コピー・フラグ付け・アーカイブ
delete:email	メッセージをごみ箱に移動、または完全に削除
manage:drafts	下書きの作成・編集・削除（送信にはsend:emailも必要）
manage:contacts	最近のメールから連絡先をリアルタイムで検索
schedule:email	メッセージの将来の配信を予約
manage:automations	無人で実行するスケジュール済みトリアージルールの作成と管理（削除アクションはなく、転送には引き続き承認が必要）

サポートしているプロバイダー

プロバイダー	接続方法	読み取り／検索	送信	フォルダー	完全削除	下書き
Gmail / Google Workspace	アプリパスワード（IMAP/SMTP）	✅	✅	ラベル	✅（Gmail の IMAP 削除設定に従います）	✅
Fastmail	アプリパスワード（IMAP/SMTP）	✅	✅	✅	✅	✅
iCloud、Yahoo、AOL、GMX、Zoho、Yandex	アプリパスワード（IMAP/SMTP）	✅	✅	✅	✅	✅
IONOS、STRATO、One.com、OVHcloud、Namecheap Private Email、Hostinger、Infomaniak、Hetzner	メールボックスのパスワード（IMAP/SMTP）	✅	✅	✅	✅	✅
cPanel、Plesk、SiteGround、Bluehost などの共有ホスティング	メールボックスのパスワード（IMAP/SMTP）	✅	✅	✅	✅	✅
その他の IMAP/SMTP メールボックス	アプリパスワードまたはメールボックスのパスワード	✅	✅	✅	✅	✅
Outlook / Microsoft 365	OAuth 2.0（Microsoft Graph）	✅	✅	✅（入れ子）	✅	✅

ウェブホスト上にある独自ドメインのメールは、通常の IMAP メールボックスと同じ方法で接続できます。1 つのワークスペースに複数のメールアドレス（info@、sales@、support@）を登録できます。100 のプロバイダーに関するホストごとの設定と既知の注意点は、mcpemails.com/connect に掲載されています。プロバイダーごとの機能対応状況はプロバイダー互換性マトリックスをご覧ください。また、調査済みの IMAP/SMTP ホスト、ログイン方式、サイズ制限は、オープンなプロバイダーデータセット（JSON および CSV、CC BY 4.0）として無料でダウンロードできます。

Outlook は IMAP ではなく、「Microsoft でサインイン」を使用して Microsoft Graph に接続します。個人用 Microsoft アカウント（outlook.com、hotmail.com、live.com、msn.com）は直接接続できます。職場または学校の Microsoft 365 テナントでは、Microsoft の既定の同意ポリシーにより、従業員が自分でメールのアクセス許可を承認できません。そのため、IT 管理者が組織のアプリを一度承認する必要があります。ダッシュボードでは、ユーザーが管理者に送れる共有可能な承認リンク（/auth/outlook/admin-consent）が提供され、管理者は MCPEmails のアカウントを作成する必要はありません。Exchange Online メールボックスがない Microsoft アカウントは、IMAP の案内とともに接続を拒否されます。ラベルツールは Gmail 専用です（Outlook はフォルダーを使用します）。ただし、自動化のラベルアクションは Outlook のカテゴリを適用します。また、Graph ではテキスト検索と未読、添付ファイル、フラグ付き、日付の各フィルターを組み合わせることはできません。

料金プラン

料金の基準となる指標は接続済みの受信トレイです。Freeでは1つ、Personalでは最大3つ、事業を運営する1人向けのProでは最大10個のメールボックスを接続できます。Businessには10個のメールボックスが含まれ、追加分は1つにつき月額$3で、ロールを設定できる無制限のメンバーと、クライアントごとに分かれたワークスペースも利用できます。年払いにすると約20%お得です。

	Free	Personal	Pro	Business
料金	$0	月額$9・年額$86.40（月額$7.20）	月額$15・年額$144（月額$12）	月額$39・年額$374.40（月額$31.20）
接続済みの受信トレイ	1	3	10	10個まで含む。追加分は1つにつき月額$3（年額$28.80）
メール操作／月	150（最初の3日間はカウント対象外）	月間上限なし（公正利用の範囲内）	月間上限なし（公正利用の範囲内）	月間上限なし（公正利用の範囲内）
API キー	無制限	無制限	無制限	無制限
メンバー	1人（オーナーのみ）	1人（オーナーのみ）	1人（オーナーのみ）	無制限。ロールを設定可能。追加料金なし
公正利用のレート制限	60 req/min	120 req/min	300 req/min	1,000 req/min
ロール、管理者による送信承認、複数のワークスペース	いいえ	いいえ	いいえ	✅
サポート	コミュニティ	メール	メール	メール

API キーごとの制限も適用されます（100 req/min・1,000/hr・10,000/day）。レート制限に達した場合は再試行できます。JSON-RPC エラー -32003 として返され、data.retry_after に秒数が示されます。

Freeのワークスペースでは、暦月（UTC）あたり150回のメール操作が可能です。登録後の最初の3日間はカウントされません（2026-10-17より前に作成されたワークスペースは7日間）。また、inbox_list とダッシュボードは常にカウント対象外です。上限に達すると、翌月1日までその他すべてのメール操作が拒否され、無人の自動化は一時停止して1日に自動再開されます。オーナーには使用量が80%および100%に達した時点でメールが送られます。Personal、Pro、Businessには月間上限はありませんが、公正利用が適用されます（各プランの上限は不正利用防止のための制限であり、プランの機能ではなく、どこにも表示されません）。拒否された操作は再試行できず、JSON-RPC エラーでもありません。通常のツール結果として返され、isError: true が設定されます。テキストはカウント数とリセット日から始まり、_meta["com.mcpemails/usage_limit"] ブロックは reset_at にクリアされます。

内部プラン ID はプラン名より前から使われています。solo は Pro として販売され、pro は Business として販売されています（2026-10-19までは Team）。新しい personal ID だけが表示名の Personal と一致します。2026-08-19の料金改定より前から存在するすべてのユーザーは、永久に無料で無制限の受信トレイを利用できます。10個の上限が導入された時点ですでにProだったワークスペースは、無制限の受信トレイを利用できます。また、2026-09-12に操作回数の上限が導入される前に作成されたすべてのワークスペースは、使用量の計測対象外となる既存メンバーです。詳しくは apps/web/src/lib/stripe/plans.ts を参照してください。

アーキテクチャ

flowchart LR
    Agent["MCP client<br/>(Claude, Cursor, …)"] -->|"JSON-RPC / OAuth or API key"| Web

    subgraph Vercel["Vercel — Next.js 16"]
      Web["/api/mcp route<br/>+ marketing site + dashboard"]
    end

    subgraph Supabase
      Edge["mcp-server<br/>edge function (Deno)"]
      DB[("Postgres<br/>RLS + encrypted creds")]
      Cron["outlook-token-refresh<br/>edge function"]
    end

    Web -->|proxies| Edge
    Edge -->|decrypt creds, fetch live| Providers["Email providers<br/>Gmail API · Microsoft Graph · IMAP/SMTP"]
    Edge --> DB
    Cron --> DB
    Web --> Stripe[("Stripe<br/>billing")]

• /api/mcp は、Next.js の薄いルートハンドラーで、Supabase エッジ関数 mcp-server にプロキシします。実際の MCP 実装はこの関数にあり、認証情報の復号とプロバイダーの呼び出しを行います。
• Postgres データベースには、ワークスペース、メンバー、受信トレイ（暗号化されたトークン／パスワード）、ハッシュ化された API キー、OAuth クライアント、予約送信、アクティビティログが保存されます。これらはすべて Row‑Level Security によって保護されています。
• Cron エッジ関数（outlook-token-refresh）は、Outlook OAuth トークンを有効期限前に更新します。

技術スタック： Next.js 16（App Router）・React 19・next‑intl 4・Supabase（Auth、Postgres、Edge Functions）・Stripe・Resend・TypeScript。メールの解析とサニタイズはエッジ関数（supabase/functions/mcp-server/mime.ts）で行います。署名の HTML は、ブラウザーでは DOMPurify を使い、サーバーでは依存関係のない許可リストを使ってサニタイズします。

リポジトリの構成

.
├── apps/
│   └── web/                     # Next.js 16 app (marketing, dashboard, /api/mcp proxy)
│       ├── app/                 # App Router routes ([locale], dashboard, api, auth)
│       ├── components/          # marketing/ + dashboard/ React components
│       ├── messages/            # next-intl translations (en, nb, es, fr, zh)
│       ├── src/lib/             # stripe/, supabase/, blog/, crypto helpers
│       └── proxy.ts             # middleware: i18n + Supabase session + CDN cache
├── supabase/
│   ├── functions/
│   │   ├── mcp-server/          # the MCP server (tools, auth, scopes)
│   │   └── outlook-token-refresh/
│   └── migrations/              # SQL migrations (schema + RLS)
└── package.json                 # npm workspaces (apps/*)

ローカル開発

前提条件： Node.js 20以降、npm、Supabase CLI（マイグレーションとエッジ関数用）。

# 1. Install (npm workspaces — run from the repo root)
npm install

# 2. Configure environment
cp .env.example apps/web/.env.local
#   then fill in the values (see below) and generate the two secrets:
openssl rand -hex 32   # ENCRYPTION_KEY
openssl rand -hex 32   # CSRF_SECRET

# 3. Run the web app (http://localhost:3000)
npm run dev

# 4. Production build
npm run build

next.config.js はビルド時／起動時に必須の環境変数を検証し、弱い ENCRYPTION_KEY の値を拒否します。そのため、環境設定に誤りがあっても実行時ではなく、すぐに失敗します。

環境変数

.env.example をコピーし、実際の値を設定してください。すべての環境で必須です：

変数	用途
NEXT_PUBLIC_SUPABASE_URL / NEXT_PUBLIC_SUPABASE_ANON_KEY	Supabase クライアント（公開用）
SUPABASE_SERVICE_ROLE_KEY	サーバー側の管理者キー（RLS を迂回します）— シークレット
NEXT_PUBLIC_APP_URL	正規のベース URL。OAuth リダイレクト URI に使用します
GOOGLE_SITE_VERIFICATION (optional)	Google Search Console の HTML タグ確認トークン。本番環境でのみ設定してください
ENCRYPTION_KEY	保存時の認証情報を暗号化するための 64 桁の 16 進数 AES-256-GCM キー — シークレット
CSRF_SECRET	CSRF トークン用の 64 桁の 16 進数 HMAC キー（上記とは別のキー）— シークレット

機能に応じて必要：

変数	必要な機能
GMAIL_CLIENT_ID / GMAIL_CLIENT_SECRET	Gmail OAuth（gmail.readonly、gmail.send、gmail.modify）
OUTLOOK_CLIENT_ID / OUTLOOK_CLIENT_SECRET / OUTLOOK_TENANT_ID	Outlook OAuth（Mail.ReadWrite、Mail.Send、offline_access、openid、profile、email）。OUTLOOK_TENANT_ID は省略可能で、既定値は common です
NEXT_PUBLIC_OAUTH_VERIFICATION_PENDING	Google の確認が完了するまで、未確認アプリの警告を表示します（Microsoft の発行元はすでに確認済みです）
STRIPE_SECRET_KEY / STRIPE_WEBHOOK_SECRET / NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY	課金
STRIPE_PRICE_PERSONAL_MONTHLY / _YEARLY、STRIPE_PRICE_SOLO_MONTHLY / _YEARLY、STRIPE_PRICE_PRO_MONTHLY / _YEARLY	プランの価格 ID（personal = Personal、solo = Pro、pro = Business。現在の Business の価格は STRIPE_PRICE_BUSINESS_* にあります）
STRIPE_WEBHOOK_PROXY_KEY	省略可能です。/api/stripe/webhook へのアクセスを、その手前にある配信キューに制限します。未設定の場合、制限はありません。キューがキーを送信するようになってから設定してください。そうしないと、すべての配信が 401 になり、デッドレターに送られます。
STRIPE_WEBHOOK_TOLERANCE_SECONDS	省略可能です。Stripe 署名の有効期間の上限。既定値は 7 日です。キュー経由の再送では元の署名が使われるため、保留された再試行がすべて拒否されてしまう Stripe の既定値 300 秒より広く設定しています。

Fastmail などの IMAP プロバイダーはアプリパスワードで接続するため、OAuth 認証情報は不要です。

Stripe の Webhook はキュー経由で配信されます。 Stripe は Queuey のイングレスに POST し、イングレスから /api/stripe/webhook に転送します。このキューでは、動作に欠かせない設定が 2 つあります。ペイロードは raw passthrough（署名は正確なバイト列に対して計算されます）にし、mapped header で header:Stripe-Signature を転送する必要があります。マップされたヘッダーがないと、すべての配信が Missing stripe-signature header. というエラーで失敗します。なお、STRIPE_WEBHOOK_SECRET には、古い直接接続のエンドポイントではなく、イングレスを宛先とする Stripe エンドポイントの署名シークレットを設定してください。

データベースとマイグレーション

スキーマと行レベルセキュリティポリシーは supabase/migrations/ にあります。主なテーブル：workspaces、workspace_members、inboxes（暗号化された認証情報、論理削除）、api_keys（ハッシュ化、スコープ設定、受信トレイによる制限）、oauth_clients、scheduled_sends、workspace_invites、月ごとにパーティション分割された activity_log。

# Apply one migration to the linked project, then record it in the history
npx supabase db query --linked -f supabase/migrations/<file>.sql
npx supabase migration repair --status applied <version> --linked

# Regenerate TypeScript types from the live schema
npm run gen:types

このプロジェクトの DB 変更における信頼できる情報源は、Supabase CLI です。

apps/web/src/types/database.types.ts は生成されます

このファイルは npm run gen:types（supabase gen types typescript --linked）によって全内容が書き込まれます。このコマンドはマイグレーションファイルではなく、リンク済みの稼働中プロジェクトを読み取ります。 手動で編集しないでください。手動で追加したカラムは次回の再生成時に黙って削除されます。また、データベースに存在したことのないカラムを手動で追加すると、コンパイルは問題なく通る一方、本番環境で 500 エラーになります。マイグレーションを適用する変更と同時に型を再生成し、生成結果をコミットしてください。 テーブル、ビュー、RPC 関数はすべて対象となっており、apps/web の .ts／.tsx ファイル（型チェック対象プログラム全体）で宣言されているすべての Supabase クライアントは SupabaseClient<Database> です。そのため、.from()、.select()、.insert()、.rpc() は実際のスキーマに対して型チェックされます。テーブルやカラムが見つからないように見える場合の修正方法は npm run gen:types であり、Supabase クライアントにローカルで as any を付けることではありません。残っているキャストは、ジェネレーターでは本当に表現できないもの、つまり jsonb ペイロードの形状、null 許容の関数引数、複数の RPC を単一のシグネチャで呼び出すヘルパーに対するものです。それぞれに、その理由を示すコメントが付いています。

.ts／.tsx という条件は重要です。apps/web/tsconfig.json では checkJs が設定されておらず、include は **/*.ts と **/*.tsx なので、app/dashboard/[[...section]]/page.js のような .js ファイルはプログラムの対象外です。つまり、そこにある JSDoc の @param 型はドキュメントにすぎず、何も検証されません。呼び出し元から渡されるものとドキュメントが少なくとも一致するように、型は SchemaTypedClient（SupabaseClient<Database> の @typedef）として記述されていますが、正確さを保つのは手作業です。

型引数なしの SupabaseClient は絶対に使わないでください。 型引数を指定しないと SupabaseClient<any, "public", any> として解決されます。これは as any と同じですが、as any を grep しても見つかりません。db: SupabaseClient と宣言された関数ではカラムのチェックが一切行われず、存在しないカラムを .insert() に指定してもコンパイルが通ります。SupabaseClient<any> も同じ抜け穴を明示したものです。SupabaseClient<any | Database> や、エイリアスが any である SupabaseClient<Alias> も同様です。そのため、apps/web/eslint.config.mjs は any を探すのではなく、Database を必須にしています。npm run lint は、Database を指定していない SupabaseClient 型への参照と、型引数のない createServerClient(...)／createBrowserClient(...) にエラーを出します。

これらは構文上のセレクターです（このリポジトリでは型情報を使った lint は実行していません）。そのため、使用箇所の表記に基づいて照合され、次の 3 つのパターンはそのままでは検出をすり抜ける可能性があります。import { SupabaseClient as SB }、import * as Supa の後に Supa.SupabaseClient を使うパターン、そして const mk = createServerClient; mk(...) です。セレクターはこれらを見抜けないため、設定では一段上の対策を講じています。SupabaseClient のインポート名を変更すること、および @supabase/ssr や @supabase/supabase-js を名前空間インポートすること自体をエラーにしています。また、no-restricted-imports により、src/lib/supabase/ のラッパー以外のすべてのファイルで createClient／createServerClient／createBrowserClient を使えないようにしています。クライアントを構築するのはこのラッパーだけであり、常に <Database> を渡します。それ以外のファイルでは、これらのラッパーをインポートします。

ルールは **/*.ts(x) に限定されていないため、インポートや呼び出しの制限は .js／.jsx／.mjs にも適用されます。ただし、それらのファイルでは JSDoc の型を読み取れません。構文上のセレクターには、その型に対応する AST ノードがないためです。これは上述した既知の制限であり、ルールが対象としているかのように見せかけているものではありません。

tsc がエラーなしでも、次の 2 点はわかりません。

• --linked は supabase/migrations/ ではなく、本番環境を読み取ります。 実際のライブプロジェクトに存在する内容がそのままファイルに反映され、ドリフトも含まれます。また、ローカルには存在していてもプッシュされていないマイグレーションは反映されません。型の再生成にはリンク先プロジェクトの認証情報が必要なため、CI ではリポジトリだけを使ってこのファイルを再現できません。型がマイグレーションの内容を表していると判断する前に、supabase migration list --linked を確認してください。2026-09-16 時点では、このコマンドは両方向に 8 件の不一致を報告します。
• キャストを使うと、依然としてチェックが無効になります。 (row as any).some_column と client as unknown as SupabaseClient<Database> は、どちらもどんな記述でもコンパイルを通します。上記の lint ルールが検出するのはクライアントの 宣言 であり、呼び出し箇所で any にキャストされたクライアントではありません。こうしたキャストを検出するのは @typescript-eslint/no-explicit-any です。このルールに対する eslint-disable は意図的な選択なので、その理由を記述してください。

デプロイ

Web アプリ → Vercel（プロジェクト mcp-emails-web）：

vercel --prod --yes

セキュリティヘッダーと関数のタイムアウトは vercel.json で定義されています。マーケティングページのルートには CDN でキャッシュ可能な Cache-Control（proxy.ts で設定）が適用されるため、クローラーや再訪問者はエッジキャッシュを利用できます。ダッシュボード、認証、API のルートは no-store のままです。

MCP サーバー → Supabase エッジ関数：

npx supabase functions deploy mcp-server --project-ref <your-project-ref> --no-verify-jwt

先にマイグレーション、次に関数をデプロイしてください。 PostgREST は認識していないカラムに対して undefined を返すのではなく、エラーを返します。また、サーバー共通の受信トレイの列選択（INBOX_SELECT_COLUMNS）はすべてのメールツールで使われており、各ツールはクエリエラーを「受信トレイが見つかりません」として処理します。そのため、マイグレーションより先に関数をデプロイすると、新しいカラムを必要とする機能だけでなく、メール関連機能全体が停止する可能性があります。新たにマイグレーションされた受信トレイのカラムは、個別の小さなクエリ（readSendReviewMode、readBulkReviewMode、readInboxDraftEditorHidden）で意図的に読み取るようにしているため、順序が逆のデプロイでも、その機能だけに影響を限定し、すべてが壊れるのを防げます。これは安全策であり、順序を省略してよいという意味ではありません。

セルフホスト

ホスト型サービスにメールを預けたくない場合は、同じ MCP サーバー をご自身のマシンで実行できます。self-host/ にはコンテナ化されたスタック（Postgres + PostgREST + Deno サーバー。Supabase／Stripe／ダッシュボードは不要）が含まれており、認証情報はご自身だけが保持するキーで暗号化され、ご自身のコンテナ内でのみ復号されます。セルフホストガイドでは、ホスト型サービスとの違いを比較しています。

cd self-host
make setup      # generate secrets (.env)
make up         # build + start the stack
export IMAP_PASSWORD='your-app-password'
make provision [email protected] IMAP_HOST=imap.fastmail.com SMTP_HOST=smtp.fastmail.com SERVICE=fastmail
make key NAME="my agent"   # mint an mcpe_ key, then point your client at http://localhost:8787

アプリパスワードによる IMAP／SMTP を優先しており、Fastmail、iCloud、Yahoo、Zoho、Yandex などに対応しています。Gmail／Outlook の OAuth と Web ダッシュボードは引き続きホスト型サービスでのみ利用できます（Outlook では、ご自身の Microsoft Entra アプリ登録も必要です）。コンテナは supabase/functions/mcp-server/ を変更せずに実行します。詳しくは、完全なガイド self-host/README.md をご覧ください。

国際化

next‑intl（安定した正規 URL のため、localePrefix: 'as-needed'、localeDetection: false）で構築されています。英語は / で提供され、その他のロケールには接頭辞（/nb、/es、/fr、/zh）が付きます。翻訳は apps/web/messages/ にあります。

対応ロケール：英語、ノルウェー語（ブークモール）、スペイン語、フランス語、中国語（簡体字）。

セキュリティモデル

• 認証情報は保存時に AES‑256‑GCM で暗号化され、必要なリクエストの処理中に限りサーバー上で復号されます（mcp-server エッジ関数、および接続を確認またはテストする Web API ルート）。
• メッセージは保存されません。メール本文と添付ファイルはその都度取得され、永続化されません。添付ファイルのテキスト抽出はリクエスト中に一時的に実行され、生の添付ファイルのバイトデータは返しません。
• API キーはハッシュ化され、表示用に保存されるのはプレフィックスのみです。権限ごと、受信トレイごとにスコープが設定され、任意で有効期限も指定できます。
• クライアント認可には OAuth 2.0 + PKCE、MCP クライアントには Dynamic Client Registration（RFC 7591）を使用します。
• Row‑Level Security により、データベース層で各ワークスペースのデータを分離します。
• すべてのレスポンスに、厳格な CSP、HSTS、X-Frame-Options: DENY などのヘッダーを適用します。

ライセンス

MCPEmails は GNU Affero General Public License v3.0（AGPL‑3.0）のオープンソースソフトウェアです。mcpemails.com のホスト型サービスでは、セルフホスト可能なものと同じサーバーが稼働しているため、コードを読んで検証し、ご自身で実行できます。信頼モデルについては /security をご覧ください。

---

_{あらゆるエージェントからメールを送受信できます。© MCPEmails、AGPL‑3.0。}