登録時に認証コードが届かない場合は、まず受信診断チェックリストをご確認ください。

診断を見る
InboxCloak

受信記録 · 手がかりを残し、秘密は残さない

認証コードのリクエストを秘密をスクリーンショットに残さず記録するには?

時刻、画面の通知、操作の順番を記録すれば、受信トラブルの大半を把握できます。認証コードそのものや完全なメールアドレス、アクセス情報までメモに残す必要はありません。

まずは「何が起きたか」を記録し、認証コード自体は記録しない

一時メールの受信トレイに新着メールが届かないと、何度も再送を押したり、画面全体を撮って問い合わせたりしがちです。その結果、操作の順番は記録されない一方で、認証コードや完全なアドレス、ブラウザーのタブまで公開されてしまうことがあります。より効果的なのは、いつ何を操作し、画面に何が表示され、その後何を確認したかを簡潔に記録することです。

この認証コードメールのリクエスト記録は、アカウント情報をまとめるものではありません。今回使ったメールアドレスを「アドレス A」とし、リクエストごとに R1、R2 と番号を付けます。認証コードについては「受信」または「未受信」とだけ記録してください。メモを共有することになっても、アカウントにログインできる秘密をそのまま渡さずに済みます。

2026年も押さえておきたい3つの出来事

認証コードの画面はシンプルになってきましたが、「送信しました」はサービス側が表示する概括的な通知にすぎない場合があります。以下の3つは、それぞれ別の出来事です。途中で何が起きたかわからない場合は、推測で埋めず「不明」と記録しましょう。

画面に表示された通知から、どの段階まで確認できる?
出来事 記録できる証拠 まだ証明できないこと
リクエストが受け付けられた 画面に「リクエスト成功」と表示された、または再送の待機時間が始まった。 メールが送信システムから送信されたこと。
メールが送信された 権限のある送信側のログで、次の処理先に引き渡されたことが確認できる。 受信トレイでメールを受信し、表示したこと。
受信トレイに届いた 受信トレイの一覧に該当するメールが表示された。 記載されたコードがまだ有効であること、または最後のリクエストに必ず対応すること。

一般ユーザーが確認できるのは、通常、最初と3つ目の段階だけです。件名に「認証コード」と書かれていても、リクエストとの関連を示す証拠にはなりません。リクエスト ID や送信元からの説明がない場合は、不確かなまま記録してください。

リクエスト記録に残す情報は4つだけ

端末に標準搭載されているメモアプリで十分です。まず日付とタイムゾーンを書き、次に以下の項目を記録してください。公開設定や自動共有が有効な文書にメモを保存するのは避けましょう。

  • 時刻:操作したときの現地時刻とタイムゾーン。例:「2026-08-12、UTC+08:00」。「さっき」だけでは不十分です。
  • 場所と画面の通知:サイト名、ページのパス、画面に表示された通知の正確な文言を記録します。クエリパラメーターやアカウント情報は省いてください。
  • アドレスの識別名:今回は「アドレス A」とします。別のアドレスに切り替えたら「アドレス B」に変え、2回分の観察記録を混同しないようにしましょう。
  • リクエスト番号と結果:R1 は最初のリクエスト、R2 は再送です。それぞれのクリック時刻、画面の通知、初めてメールを確認した時刻を記録します。

受信メールに M1、M2 と番号を付けると、本文を識別に使わずに済みます。一覧に表示されるメールの時刻と「自分が初めて確認した時刻」は、別々に記録してください。後者は更新したタイミングやページを開いていたかどうかで変わるため、正確な配信時刻ではありません。

再送後は、2回のリクエストをひとまとめにしない

新しいリクエストで古いコードが無効になるか、有効期限をどう計算するかを把握しているのは送信元だけです。最後に届いたメールのコードが最新だとは限りませんし、受信順が送信順と同じとも限りません。ネットワーク上の遅延や再試行、ページの更新によって、確認できる順番が入れ替わることがあります。

再送の待機時間が表示されたら、終了するまで待ち、クリックごとに別の番号を付けましょう。画面に明確な関連情報がなければ、「M1、M2 と R1、R2 の対応関係は不明」と記録します。どのコードを使うかは送信元サイトの案内に従い、記録の空白を埋めるためにコードを順番に試すのは避けてください。余計な制限がかかるおそれがあります。

例:1回のリクエストと1回の再送、その後に届いた2通のメール

以下は記録方法を示す架空の例で、InboxCloak の実際の配信速度を示すものではありません。完全なアドレスや認証コード、メール本文は含まれていません。

アドレス A · 登録フローの確認 2026-08-12 · UTC+08:00 · 手動記録
  1. R1 · 最初のリクエスト

    登録ページに「認証コードを送信しました」と表示。受信トレイに新着メールはまだありません。

  2. R2 · 待機時間の終了後に再送

    アドレスは A のまま。ページに再び送信通知が表示されましたが、リクエストとの関連を示す番号はありません。

  3. M1 · 最初のメールを確認

    件名はログイン認証コード。本文とコードは記録せず、どのリクエストに対応するかは不明です。

  4. M2 · 更新後に2通目を確認

    同じ種類の件名ですが、R2 に対応するとも、コードが有効とも推測しません。

結論は「確認した時間内に2通のメールが表示された」とだけ記録し、「2回のリクエストがどちらも正常に届いた」とは書きません。

スクリーンショットは切り抜いてから、元に戻せない方法でマスキング

文章で説明できるなら、スクリーンショットは不要です。必要な場合は、関係する通知だけを切り抜き、無関係なタブや通知、パスワードマネージャーの画面を閉じてから撮影します。アドレスバーやメール本文、開発者ツールは通常、写す必要がありません。

次の5種類の情報は、原則として共有しない

  • 認証コード、リカバリーコード、ログイン用のワンタイムリンク、およびそれらを含む件名やプレビュー。
  • 完全な受信アドレス、実際のメールアドレス、アカウントを特定できる個人情報。
  • クエリパラメーター付きのリクエスト URL。特にアクセス情報を含むリンク。
  • token、Cookie、Authorization ヘッダー、ブラウザーのストレージに保存された内容。
  • 認証アプリの QR コードやセットアップキー、QR コードの横に表示された予備情報。

認証コードのスクリーンショットをマスキングする際は、ぼかし、モザイク、移動できる半透明レイヤーだけに頼らないでください。機密部分を不透明な単色で覆い、1枚の画像に書き出してから開き直し、隠した情報が見えないことを確認します。マスキングを取り消せる編集元ファイルは送らないでください。記録上のアドレス識別名に置き換え、スクリーンショットに残った完全なアドレスもすべて隠しましょう。

共有する前に、ファイル名や OCR の結果に情報が漏れていないかも確認します。秘密情報をすでに送ってしまった場合、画像を削除してもすべてのコピーを回収できるとは限りません。その認証情報の使用をやめ、送信元サイトまたはメールサービスの案内に従って対処してください。

開発・運用での再現テスト:配信を断定せず、確認した時間を記録する

メールテストの記録には、テストの権限を明記しましょう。自分のテスト用アカウント、自分で管理する受信アドレス、テストを許可された環境だけを使用します。調査を理由に大量登録したり、レート制限を回避したり、他人のメールアドレスに認証コードを繰り返し送ったりしないでください。

ブラウザーのバージョンやテスト環境など、変更する条件は一度に1つだけにします。テスト日、端末、環境名、操作手順、観察を開始・終了した時刻を記録してください。「5分間確認したがメールは見当たらなかった」は結果の記録ですが、「システムは5分以内に配信できない」は証拠の範囲を超えた断定です。

送信側のログを確認できる権限がある場合は、認証情報を含まない関連 ID を保存し、ログがキューへの登録、送信処理、受信側からの応答のどれを示すのか明記します。ブラウザーのネットワークパネルから出力した生データには、Cookie、リクエスト本文、token が含まれることがあります。チケットにそのまま添付しないでください。英語のメモでは receive verification code email を手順名として使えますが、テスト結果は各段階を分けて記録しましょう。

サポートへの問い合わせは、必要最小限の情報が役立つ

まず、問題がどちら側で起きているか確認します。登録ページでエラーが出る、またはアドレスが受け付けられない場合は、そのサイトにお問い合わせください。InboxCloak でアドレスの作成、受信一覧の更新、本文の表示に問題がある場合は、当サイトのサポートまでご連絡ください。マスキングしたメモを、以下の順に整理すれば十分です。

  1. クエリパラメーターや秘密情報を含むフラグメント、非公開ページの内容を含めず、ページのパスと機能名を記載。
  2. 発生日、現地時刻、タイムゾーン、ブラウザーと端末のおおよそのバージョン。
  3. R1、R2 の操作順、画面に表示された通知の正確な文言、確認した M1、M2。
  4. 期待していた結果と実際の結果。必要に応じて、切り抜き・マスキング後に再確認したスクリーンショットを1枚添付。

宛先: support@inboxcloak.com 初回のお問い合わせに、メール全文や受信情報を添付する必要はありません。さらに詳しい調査が必要な場合は、まず連絡手段と必要な項目を確認し、必要最小限の機密情報を含まない識別情報だけをお送りください。認証コード、認証アプリのセットアップキー、ログイン token は、こちらから送らないでください。

記録でわかる範囲:ブラウザー上での成功は、メールの配信を意味しない

メモで把握できるのは、自分が確認した範囲の経過です。送信キュー、メール転送、受信システムのログに代わるものではありません。ページに成功と表示されても配信確認にはなりません。新着メールが一時的に見当たらないだけで、メールが破棄された、ドメインがブロックされた、どこかで障害が起きたと断定することもできません。

メールアドレスを隠すことで減らせるのは、普段使いのアドレスを外部に伝える回数です。配信経路全体が見えるようになるわけではありません。また、一時メールがすべてのサイトで使えるとは限りません。次に何を確認するか判断するには、認証コードの受信診断チェックリストをご覧ください。スクリーンショット1枚だけで結論を出さないようにしましょう。

対応後は、3か所に残ったコピーを確認する

問題が解決したら、不要になった一時メモを削除しましょう。テスト結果を残す必要がある場合は、マスキング済みの概要だけにします。続いて、ダウンロードフォルダー、スクリーンショットの編集元ファイル、ごみ箱、クリップボードの履歴も確認してください。送信した画像だけを削除しても十分ではありません。

共有ドキュメント、チャットの添付ファイル、問い合わせチケットに残るコピーも最後に確認し、不要な情報は各サービスの手順に従って削除します。メールサービス側のログ、端末に保存したファイル、共有済みのスクリーンショットは、それぞれ別のコピーです。1か所で削除しても、ほかの場所から自動的に消えるとは限らず、受信者が保存していないとも限りません。

よくある質問:メール全文と長期的なアカウント復旧

調査のためにメール全文を貼り付ける必要がありますか?

通常は必要ありません。メール全文にはログインリンク、個人情報、トラッキング用パラメーター、非表示の項目が含まれていることがあります。まずリクエスト時刻、画面に表示された通知、確認できた結果をお知らせください。具体的に必要な情報を確認してから、必要な項目だけを別途整理し、元のメールファイルは転送しないでください。

一時メールアドレスを長期的なアカウント復旧に使えますか?

おすすめしません。InboxCloak の新しい一時メールボックスは、初期設定で3時間有効です。利用時間を延長するたびに3時間追加されます。期限切れになった後やアドレスを変更した後は、アカウント復旧メールの受信先として頼らないでください。通知を継続して受け取るには、専用ログイン付きの長期転送エイリアスをご検討ください。ただし、重要なアカウントには、信頼できる復旧手段も必ず設定しておきましょう。

ページ上のデモメールをテスト結果に記録できますか?

できません。デモメールは画面上でメールがどう表示されるかを示すもので、今回のリクエストが配信された証拠ではありません。テストでは実際に届いたメールだけを記録してください。区別できない場合は「未確認」と明記し、デモの内容を成功結果として扱わないでください。

必要な手がかりだけを持って、ツールに戻る

受信トレイに戻って実際のメールを確認してください。まだ届いていない場合は、個別の診断チェックリストを順に確認すれば十分です。画面全体を再び撮影する必要はありません。