最初に私たちのおすすめを。 Proxy Mail QA は私たちの製品ですが、このリストのほとんどは私たちのものではありません。Proxy Mail QA をおすすめするのは1か所だけです:ウェブサイトにサインアップ、ログイン、パスワードリセットがある場合や、招待などのアカウントメールを送る場合に、それらのメールが機能するか確認するテスト用受信トレイを提供します。アカウントがなくメールも送らないサイトなら不要ですが、このガイドの残りの部分は役立ちます。
リスト
| 必要なもの | 用途 | よく使われるもの |
|---|---|---|
| コードを書く・生成する場所 | サイトの構築 | VS Code や Qoder IDE などのエディター、Qoder、Claude Code、Cursor などの AI コーディングエージェント、またはコードなしなら Webflow、Framer、Squarespace、WordPress などのビルダー |
| バージョン管理 | ミスの取り消し、共同作業、デプロイ | Git と GitHub または GitLab |
| フレームワーク(任意) | ゼロから始めずにページ、ルーティング、データを扱う | Next.js、Astro、SvelteKit、Nuxt |
| ホスティング | サイトをインターネットに公開し、変更ごとにプレビューを用意 | Vercel、Netlify、Cloudflare Pages、Render |
| ドメイン名 | 独自のアドレスと、メールの送信ドメイン | 任意のレジストラ。DNS はレジストラまたは Cloudflare |
| サインアップとログイン(アカウントがある場合) | アカウント、パスワード、コード、マジックリンク | Supabase Auth、Clerk、Firebase Authentication、Auth0、Auth.js、Better Auth |
| データベース(何かを保存する場合) | アカウント、注文、コンテンツ | Postgres(Supabase、Neon)、Firestore、SQLite |
| メールプロバイダー(メールを送る場合) | 自分のドメインからの確認、リセット、領収書のメール | Resend, Postmark, Amazon SES, SendGrid, Mailgun |
| 決済(販売する場合) | カード、サブスクリプション、請求書 | Stripe、Paddle、Lemon Squeezy |
| アクセス解析 | 利用者が何を使っているかを知る | Plausible、PostHog、Google Analytics |
| エラー追跡 | ユーザーに言われる前に、何が壊れたかを知る | Sentry |
| テスト | 変更によってサインアップや決済が壊れていないことを確認する | ブラウザには Playwright または Cypress、コードには Vitest または Jest、メールには Proxy Mail QA |
| チェック用ツール | 速度、アクセシビリティ、リンク、SEO | Lighthouse、axe DevTools、リンクチェッカー、Google Search Console。詳しくは ウェブサイトの構築とチェックに役立つツール をご覧ください |
| 法的ページ | プライバシーポリシー、利用規約、必要に応じて Cookie の告知 | 自分のサイトとユーザーの所在地に合わせて書いたもの |
省略できるもの
- アカウントのないサイト(ポートフォリオ、カフェ、ランディングページ):ビルダーまたはフレームワーク、ホスティング、ドメイン、アナリティクス。メッセージを受け取りたい場合はフォームサービス。認証、データベース、メールのテストは不要です。
- ショップ:Shopify などのホスト型ショッププラットフォームは、ホスティング、決済、アカウント、メールをまとめて提供することがあります。テストするのは、変更が許されている部分です。
- アカウントのあるアプリ(SaaS 製品、コミュニティ、予約サイト):リストのほとんどが必要です。特に見落とされやすいのは、メールプロバイダーの設定とメールのテストです。
Proxy Mail QA の位置づけ
ユーザーがサインアップできるようになると、サイトは確実に届くべきメールを送ります。確認コードやリンク、パスワードのリセット、招待です。これらは他のテストでは見つからない形で壊れます。リンクが localhost を指している、プロバイダーがまだサンドボックスモードで何も送っていない、1 通のはずが 2 通送られる、などです。
Proxy Mail QA は試行ごとに新しいプライベートなテスト用アドレスを用意し、コードやリンクを取り出し、メールの送信のされ方をチェックします。ブラウザで Proxy Mail QA for Chrome を使って手動で、npm パッケージで Playwright や Cypress のテストから、または MCP server を通じて Qoder などの AI エージェントから使えます。無料プランでは合計 500 件のテスト用アドレスを使えます。
構築、ホスティング、デザインは行わず、サイトのメール送信もしません。メールプロバイダーは別途必要です。
アカウントのあるアプリの最初のスタック
Qoder で構築する場合の組み合わせの一例です:
- コード: Qoder のエージェント。リポジトリは GitHub 上の Git リポジトリ。
- フレームワークとホスティング: Vercel 上の Next.js。ブランチごとにプレビューデプロイ。
- アカウントとデータ: サインアップ、ログイン、データベースに Supabase。
- メール: 独自ドメインから送信する Resend。Supabase の組み込みメールは自分のチームにしか送れず、1 時間に数通までです。他の人がサインアップする前に、独自のメールプロバイダーを設定してください。
- エラー: Sentry。
- テスト: サインアップフローに Playwright、確認メールに Proxy Mail QA。各プレビューデプロイで実行します。
どの行も表の別の選択肢に置き換えられます。ブランドより順番のほうが重要です。
設定する順番
- ドメインは早めに購入します。 メールプロバイダーは自分の名前で送信するためにドメインを必要とし、SPF、DKIM、DMARC の DNS レコードは反映に時間がかかることがあります。
- リポジトリとホスティングを設定します。 プレビューデプロイを有効にして、すべての変更にテスト用のリンクができるようにします。
- アカウントとメールは同時に追加します。 プロバイダーで送信ドメインを認証し、サンドボックスモードを解除してください。そうしないと、確認メールは自分にしか届きません。
- 共有する前にプレビューでサインアップをテストします。 新しいアドレスで、メールが届くこと、リンクが
localhostではなくプレビューを指すこと、その後アカウントが使えることを確認します。 - アナリティクスとエラートラッキングはリリース前に追加します。 最初の苦情が来てからでは遅いです。
Qoder で構築する場合は、Qoder Marketplace から Proxy Mail QA を接続し、認証コードを変更するたびにサインアップメールをチェックするようエージェントに頼めます。仕組みはこちら。