メール受信の実践 / 結果の記録

お試し利用の確認記録:結果を残し、認証コードは残さない

チームに共有するのは、手順が完了したかどうかです。ログインできる情報を渡す必要はありません。リクエスト、受信、認証を分けて記録し、あとから確認できる結果を残しましょう。認証コードやアクセス情報は共有文書に載せないようにします。

約9分で読めます お試し利用の確認

役に立つお試し利用の確認記録なら、引き継ぐ人が「何をしたか」「実際に何を確認したか」「次に誰が対応するか」の3点を把握できます。認証コードはその場の認証に使うもので、この3点の記録にはなりません。以下では、許可を得たソフトウェアのお試しテストを例に、元のメールを長期間保存せずに記録する方法を紹介します。

まずテスト範囲を限定する:許可された低リスクのお試し利用だけを確認

テストを行う前に、ウェブサイトが今回のテストを許可していることと、使用予定のアドレス形式を受け付けていることを確認してください。使い捨てメールは、1回限りの認証コードや資料の受け取りなど、リスクの低い用途に適しています。銀行、決済、仕事用のメインアカウント、長期的なアカウント復旧には使用しないでください。お試し回数の制限を回避したり、大量に登録したり、サイトの制限を逃れたりする目的で使わないでください。

記録の冒頭にテスト範囲を明記しましょう。たとえば「お試し登録フォームを1回送信し、有効化の表示まで確認。決済とアカウント復旧はテスト対象外」とします。請求書、更新通知、安全に関する通知も今後受け取る必要がある場合は、継続して使える受信先を先に用意してください。一時アドレスで登録が完了しても、長期間使えるアカウント用メールアドレスになるわけではありません。送信前に、ソフトウェアお試し登録の6ステップ確認リストに目を通しておくとよいでしょう。

2026年の共有記録に潜むリスク:コピーは想像以上に増える

チームでは、スクリーンショットをチケットに添付したり、画面録画を共有ドライブにアップロードしたり、自動整理ツールでテキストを抽出したりすることがあります。「メールが届いた」ことを示すつもりが、認証コードや確認リンク全体、ほかのアカウント通知まで一緒に共有してしまうおそれがあります。文字認識、検索インデックス、バージョン履歴によって、さらにコピーが作られることもあります。

すべてのツールで情報漏えいが起きるということではありません。アップロードする前に、共有する情報を減らしておくことが大切です。元画像をアップロードしてから文書上に色付きの図形を重ねたり、メール全文を自動要約ツールに渡して「認証コードは無視して」と指示したりしないでください。まずローカル環境で情報をマスキングしたコピーを作り、チームで承認されたアクセス権と保存ルールに従って共有します。認証コードの期限が切れても、スクリーンショットに写った氏名、住所、その他の情報の機密性がなくなるわけではありません。

記録表は必要最小限に:メール本文がなくても結果を確認できるようにする

1回の操作につき1つのケース番号を付け、記録をまとめます。時刻は日付、秒までの時刻、タイムゾーンを統一して記載しましょう。複数地域のチームで連携する場合は、UTCに統一できます。端末とブラウザーは再現に必要なバージョンだけを記録し、個人アカウント、完全なメールアドレス、ブラウザー設定をついでに収集しないでください。

共有記録には事実を残し、実行可能な認証情報は残さない
項目 記録する内容 添付しないもの
ケースと範囲 ケース番号、許可されたテスト対象のページと目的 実際の顧客情報、無関係なアカウント情報
リクエスト時刻 送信ボタンを押した時刻、タイムゾーン、画面に表示されたメッセージ ネットワークリクエスト内のtoken、Cookie
受信状況 メールを初めて確認した時刻、件名の種類、テストアドレスの識別名 認証コード、完全な受信アドレス、メール本文のコピー
認証結果 送信時刻、成功または失敗の表示、お試し利用のページに進んだか 確認リンクのパラメーター、ログインセッション
引き継ぎ内容 担当者、次の対応、再確認の期限 現在の受信箱にアクセスするための認証情報

アドレスは「テストアドレスA」のように識別できます。許可された調査のために完全なアドレスが必要な場合は、全員が見られる表には載せず、チームで承認されたアクセス制限のある経路を使って個別に共有してください。リクエスト時刻と受信確認時刻の差は「今回の観察間隔」と記録し、正確な配信所要時間やサービスの保証値として扱わないでください。

受信と認証を別々のイベントとして記録する

メールが一覧に表示されたことから分かるのは、メールを確認できたということです。認証コードがサイトに受け付けられたとは限りません。確認リンクをクリックしても、お試し利用が有効になったとは限りません。リンクの期限切れ、追加情報の入力、利用可能なお試し用ワークスペースの未作成などが表示されることがあります。

曖昧な「成功」の代わりに、2つの結果を記録する

  • 受信イベント:該当メールを初めて確認した時刻と、本文を開けたかどうか。
  • 認証イベント:認証コードを送信、または確認操作を行った時刻、サイトに表示されたメッセージ、目的のページに到達したかどうか。

たとえば「メール受信済み。認証は未実施」は、正確で十分な途中経過です。サイトに送信済みと表示されても、それはサイト側で確認できる表示にすぎません。ニュースレターの登録でも、この2つの手順を分けて確認してください。確認メールが届いただけで、登録完了と判断することはできません。

スクリーンショットで隠すべき情報:共有前にマスキングする

まず結果を示すのに必要な範囲だけを切り出し、機密情報を不透明な単色で覆います。ぼかしやモザイク、移動可能な文書上のマスクだけに頼らないでください。書き出した後に統合済みのマスキング画像を使い、マスクのレイヤーを解除できる元の編集ファイルは共有しません。

  • 認証コード、リカバリーコード、QRコード、認証に使える数字列を隠す。
  • アドレスバーやリンクのプレビュー、クエリパラメーターを含め、確認リンク全体を取り除く。
  • 開発者ツール、リクエストヘッダー、ブラウザーのストレージにあるtokenやCookieを写さない。
  • 個人用メールアドレス、氏名、プロフィール画像、署名、無関係な通知を取り除く。
  • 画面録画にタブのタイトル、自動入力、通知ポップアップ、過去の画面が映り込んでいないか確認する。

画像を書き出したら、もう一度開いて拡大し、端に隠れた文字レイヤーや統合されていないマスクがないか確認してください。画面録画を確実に編集できない場合は、必要最小限の操作を改めて録画します。必要な結果表示は残しつつ、「ページ全体を見せる」ためにブラウザー全体を公開しないでください。

正常な手順を記録する:架空のケースで例を紹介

以下は記入形式の例です。Rapidfwdの実際の配信テストではなく、標準的な速度を示すものでもありません。テストアドレスは識別名のみとし、実際にアクセスできるメールアドレスやクリック可能な確認リンクは掲載しません。

架空のケース / RF-QA-026

範囲
許可されたデモ製品のテスト。お試し利用の有効化のみ確認。
リクエスト
2026-11-05 09:20:00 UTC、テストアドレスAから送信。画面に「認証メールを送信しました」と表示。
受信確認
09:20:14 UTC、メール一覧で認証メールを初めて確認。本文を開ける。
認証結果
09:20:42 UTC、認証を送信した後に「お試し利用が有効になりました」と表示され、目的のお試し利用ページに移動。
保存した記録
有効化の表示を写したマスキング済み画像1枚。認証コード、確認URL、メール本文は保存しない。

ブラウザーのアドレスバーは、アカウントが有効になったことの十分な証拠ではありません。URLの変更は、単なるリダイレクトの場合もあります。サイトに明示されたメッセージと、実際に確認できる目的のページを記録してください。明確な結果が表示されない場合は、「ページに移動したが、有効化は未確認」と記録し、システムの状態を推測しないでください。

問題の引き継ぎ:未着、期限切れ、拒否を分けて記録する

メールを確認できないことは、送信されなかった証拠ではない

確認した時間帯、アドレスの有効性、貼り付けた内容を確認したか、サイトに送信成功と表示されたかを明記してください。送信システムのログがないなら、「送信サーバーの障害」とは記録しないでください。たとえば「09:20~09:25 UTCに該当メールを確認できず。アドレスは期限内。送信画面には成功と表示。原因は未確認」と記録し、次に認証コードが届かないときの診断に沿って項目ごとに確認します。

リンク切れとサイト側の拒否は、それぞれの表示を記録する

リンクが無効な場合は、表示されたメッセージの内容、操作時刻、再送の有無、どの回のメールを使ったかを記録し、リンク全体をチケットに貼らないでください。サイトが使い捨てアドレスを明確に拒否した場合は、どの手順で起きたかを記録し、アドレスを何度も変えて試すのはやめましょう。相手のルールに従い、使用可能なメールアドレスを選んでください。

そのまま使える引き継ぎテンプレート

ケース番号 → 完了した操作と時刻 → 実際に表示されたメッセージ → 未確認の点 → 試した対応 → 引き継ぎ先と再確認時刻。

再試行が必要な場合は、新しい許可済みテストケースで新たに認証をリクエストしてください。認証コードや受信情報を共有して、同僚にブラウザーのセッションを引き継がせないでください。

期限前に保存するのは結果。メールを丸ごと保存しない

Rapidfwdの使い捨てメールボックスは、初期状態で3時間有効です。受信画面から延長すると、1回につき3時間延長でき、最長24時間まで保持できます。実際の残り時間は、ホームページのツール表示とAPIの応答で確認してください。延長する場合は期限前に操作し、新しい期限を確認します。延長する予定を、すでに延長済みとして扱わないでください。

期限が切れると、アドレスとメールは削除され、復元できません。終了前にケースの結論、マスキング済みの証拠、必要な機密性のない引き継ぎ情報を保存してください。資料のダウンロードがある場合は、許可された範囲で必要なファイルも保存します。「あとで使うかもしれない」という理由で、認証メールをすべて書き出すのはやめましょう。確認リンクと認証コードにもそれぞれ有効期限があり、受信箱を延長しても期限は延びません。詳しくはアドレスの有効期限と延長についてをご覧ください。

翌日以降の確認には転送用エイリアスを。アーカイブは永久保存の監査記録ではありません

翌日のリマインダーやお試し期間中の後続通知も確認する場合は、フォームを送信する前に、ログインして長期利用できる転送用エイリアスを作成することを検討してください。メールはご自身のメールアドレスに転送され、ダッシュボードには30日間オンラインで保存されます。ブロックされたメールもアーカイブで確認できます。ただし、期限切れになった使い捨てアドレスを自動的に引き継ぐものではありません。

30日間はオンラインアーカイブの保存期間であり、永久的な監査記録を保証するものではありません。また、チームの証拠保存ルールに代わるものでもありません。確認結果を長期間保存する必要がある場合は、アクセス権と保存ルールが設定されたチームのシステムに保管してください。外部メールアドレスに転送されたコピーも別途管理が必要です。使い捨てアドレスも転送用エイリアスも受信専用で、テストメールへの返信には使えません。

終了時の確認:次の担当者と対応を明確にする

  • 「メール受信済み」「認証済み」「有効化済み」を区別し、確認できていない点を明記する。
  • 本文だけでなく、添付ファイル、チケットのコメント、画面録画、自動要約も確認する。
  • チームのルールに従って、一時的な元画像、書き出しファイル、不要なコピーを削除する。認証情報を誤って共有した場合は、担当者に知らせて対応する。
  • 引き継ぎ先、次回の確認時刻、認証を再度行う必要があるかを記載する。
  • アドレスの残り有効時間が次の作業に合っているか確認する。期限切れのアドレスを同僚に渡して、そのまま待たせない。

良い記録なら、元のメールが消えた後も当時の状況を説明できます。保存するのは事実、範囲、担当者です。再ログインするための鍵は残さないでください。