AI によるサインアップページのレビュー:メールまでフロー全体を確認する

最初に、私たちのおすすめを書いておきます。 私たちは Proxy Mail QA を作っているので、中立ではありません。この記事では、サインアップのレビューのうち、ボタンが押された後の部分にこれをおすすめします。確認メールが届くか、そのコードやリンクでサインアップが完了するか、メールが正しく送信・作成されているか、ちょうど 1 通届くか、です。Proxy Mail QA は、ページの見た目やコンバージョンの良し悪しは判断しません。SMS コードは受け取れず、Sign in with Google などのソーシャルサインインもテストしません。

AI エージェントにサインアップページのレビューを頼むと、たいていはフォームを見ます。ラベル、項目、ボタンです。そこはめったに壊れません。ユーザーに届くバグは、その次に起きることの中にあります。

• 確認リンクが localhost を指しているため、自分のマシンでしか動かない。
• メールプロバイダーがまだサンドボックスモードなので、何も届かない。
• フォームが 2 回送信される、またはコードの 2 か所がそれぞれ送信するため、メールが 2 通届く。
• メールにはリンクの有効期限が 24 時間とあるのに、サーバーでは 1 時間で期限切れになる。
• 使用済みのリンクや、新しいリンクが送られた後の古いリンクが、まだ使える。

これらは、本物のメールが本物の受信トレイに届くまで表に出ません。この記事では、レビューのたびにエージェントにこれらを確認させる方法を説明します。

エージェントが確認すること

Proxy Mail QA は自分でリンクを開かないので、エージェントが受け取った時点で 1 回限りのリンクは未使用のままです。エージェントが見るのは、コードかリンクと、それに関するいくつかの情報だけで、メールの本文は見ません。

Qoder で接続する

1. Qoder Marketplace の Connectors タブから Proxy Mail QA を接続するか(グローバルサイト、中国サイト)、プラグイン をインストールします。同じツールに加えて 8 つのスキルが使えます。
2. Qoder に求められたらブラウザで Proxy Mail QA にサインインし、エージェントが使ってよいプロジェクトを選びます。
3. Qoder の権限レベルを Auto approve ではなく Ask every time に設定し、Proxy Mail QA の各ステップを承認します。

代わりに手動で追加するには、Qoder IDE Settings → MCP を開き、My Servers タブで + Add を選び、次を追加します。

{
  "mcpServers": {
    "proxymail-qa": {
      "type": "http",
      "url": "https://api.proxymail.qa/mcp"
    }
  }
}

レビューを依頼する

Review the sign-up at https://staging.acme.dev/signup with Proxy Mail QA. Start a run.
Sign up with a new address (use form_values for the fields), note the time just before
you submit, and finish the verification with the code or link from the email.
Check you're signed in. Run check_email with expect_host: staging.acme.dev, and
count_emails since the sign-up: exactly one email should have come.
Then request a second verification email, and check the first link no longer works.
Finish the run and give me the report, with what to fix first.

サーバーの test_signup_flow プロンプトは、MCP プロンプトを表示するクライアントで、サインアップ、check_email、count_emails のステップを同じ方法で実行します(2 通目の確認メールは除きます)。プラグインをインストールしている場合、proxymail-qa スキルは 1 回のサインアップを扱います。auth-regression-pack はサインアップ、パスワードリセット、招待を毎回同じ方法で繰り返します。account-email-audit はアプリが送るすべてのアカウント関連メールを送信させ、修正すべき点を一覧にします。

レポート

finish_run はセッションを Markdown で返します。各ステップ、成功した点と失敗した点、そして各チェックについて 1 行の理由です。プルリクエストに貼り付けてください。後で auth_regression_pack を再度実行すると、レポートには前回からの変化が示されます。そのため、リセットメールを壊した変更は、長い一覧を読まなくても変化として表れます。

よくある発見事項と、変更すべき点

これが再発しないように、プロジェクトのルールか認証タスクの最初で、エージェントにルールを与えてください。

When changing sign-up, login, password reset, invites or any email-sending code:
- Build links from the app's public URL setting, never a hard-coded localhost.
- Keep the expiry stated in an email equal to the one the server enforces.
- Make single-use links and codes stop working once used or replaced.
- Tell me which emails to test by hand after the change.

できないこと

• ページそのもののレビュー。 レイアウト、文言、アクセシビリティ、速度には、別のツールか人の目が必要です。サインアップページをレビューする方法をご覧ください。
• SMS、認証アプリ、ソーシャルサインイン。 Proxy Mail QA はメールのみを受信します。
• アカウントの作成やフォームの送信。 これはエージェントが自身のブラウザツールで行います。
• サンドボックスモードのメールプロバイダーでの利用。 何も届かなかったことと、その理由を示すことしかできません。
• 大手消費者向けサービスの本番サイトのテスト(Google、Instagram、Amazon など)。自分で作っているアプリ、またはテストを許可されたアプリを、ステージングやローカルでテストするためのものです。

詳細:メール認証のテスト、MCP server、Qoder 向けの Proxy Mail QA。