先に、宛先と照合する印を決める

自分が管理するフォームと、テストを受け取る人を決めます。件名・本文の印・送信時刻で、その一通を見分けられるようにしてください。送信元、送信先、フォームに入力する返信先は、それぞれ別の項目です。

  1. 管理設定の送信先を確認する

    問い合わせを届ける宛先を管理担当と照合します。送信元や入力した返信先とは別の設定です。公開ページに宛先が見えないことだけで、宛先未設定とは判断しません。

  2. 受信者と一度のテストを取り決める

    受信者がテストを受け取ると分かっている宛先を使います。テストを行う時刻と、受信側で照合する人を決めてから次の入力確認へ進みます。

  3. 件名・本文の印・時刻を照合する

    名前を「問い合わせフォーム送信テスト」、本文に確認日時と「返信不要」を入れると通常の問い合わせと区別できます。実際に届く件名と本文の印を受信者と比べる方法を決め、宛先や秘密情報は本文に書きません。

本文の記入例（日時は実際の送信時に置き換える）
本番お問い合わせフォームの到達確認テストです。返信は不要です。
確認日時: YYYY-MM-DD HH:mm（日本時間）
照合用の印: FORM-CHECK-01

実際に送る前に、入力条件を確認する

名前・返信先・本文を入力し、対象URLが任意なら空欄で受け付けられるかを確認します。必須欄の空欄、返信先の形式、文字数の上限は、隔離したテスト環境で先に確認すると余分な本番メールを増やしません。本文には認証コード、パスワード、顧客データを入れません。

evulixでは、任意の対象URLを送らないと配列のキー参照で失敗する不具合を修正しました。画面に空欄を送る場合と、リクエストに項目自体がない場合は別です。開発者はこの二つをテストで確認し、読者としての点検では実際の入力欄が使えることを確認します。

送信ボタンを押しても送れない場合

まず画面の入力エラーを確認し、通信が始まったかで次の確認先を分けます。

  1. 最初の入力エラーへ戻る

    必須欄、メールアドレスの形式、文字数、同意欄など、画面に表示された条件を確認します。ブラウザの入力チェックで止まった場合は、欄を直すまで送信リクエストが発生しないことがあります。

  2. 通信の有無と応答を確認する

    実装担当は開発者ツールのNetworkを開き、許可されたテスト一回の送信を確認します。Fetch/XHRだけに絞ると通常フォームのDocument通信を見落とすため、両方を確認します。POSTの応答と移動後の画面を分けて読みます。

  3. 通信がなければ画面側、通信があれば応答を調べる

    入力エラーがなく通信もない場合は、ボタンの無効化やJavaScriptの例外を確認します。通信がある場合は、移動先の200だけで成功とせず、入力エラー・403・419・500などを下の応答別の説明と照合します。

送ったか分からない状態で、通信を再現するために何度も本番送信しないでください。送信時刻と画面を控え、受付記録と照合してから再送を判断します。

手順の参照：MDN：フォームの入力検証（英語）（別タブ）。に資料を確認しました。

一度送って、画面の結果を記録する

送信ボタンを一度押し、返った画面、成功または失敗の表示、時刻を記録します。送信待ちの間に連打しません。タイムアウトした場合は、画面に結果が返らないままサーバー側では送信されている可能性があるため、すぐに再送しないでください。

evulixでは、メール処理が例外を返さなかった場合に成功表示へ戻ります。これはアプリケーションの送信処理が完了したという意味です。SMTPサーバー以降の迷惑メール判定や受信側の振り分けまでは、この画面で判断できません。

受信側で件名・本文・時刻を照合する

受信トレイでテストの件名を探し、本文の印と送信時刻を比べます。見当たらなければ迷惑メールや受信ルールも確認します。以前のテストメールを今回の到達と取り違えないため、同じ文面を使う場合でも日時を更新してください。

2026年10月6日のevulixのテストでは、送信後に問い合わせページへ戻り成功表示を確認しました。その後、所有者から受信トレイの画像が提供され、テストの件名・本文・20:28:40の記録が一致しました。受信者の画像は宛先等を含むため公開せず、下表に確認できた事実だけを示します。

2026年10月6日の本番テストで分かったこと

段階結果確認の範囲
入力必須項目を入力して1通送信所有者が許可したテストのみ
送信処理成功表示、問い合わせ画面へ移動アプリケーション処理の完了
受信受信トレイ画像で照合件名・本文・20:28:40の一致
継続的な配送この1通だけでは保証しない別の送信者や将来のメールは別確認

未着なら、失敗した段階から調べる

最初に、送信ボタンを押した後の表示と時刻を控えます。evulixの通常フォームは、入力エラーでも送信処理の成功・失敗でも302で別の画面へ戻ります。戻り先のページが200で表示されたことだけでは、送信できたかを判定できません。JSON形式の検証エラーは422ですが、通常フォームの入力エラーがすべて422になるわけではありません。

入力エラーなら、送信処理より前の必須項目・形式・長さを見直します。送信失敗表示なら、管理者が該当時刻のアプリログとメールサービスの受付記録を確認します。例外が出たことだけで、メールが絶対に届いていないとは断定できません。evulixでは過去にSMTPホストが空だった記録がありますが、今回の原因として一律に決めつけることはできません。

成功表示なのに未着の場合は、実際の宛先、受信側の迷惑メール・ルール、利用しているメールサービスの配送記録を確認します。設定が存在するだけで認証成功や配送成功とはいえません。送信済みか不明な間は再送を止め、配送記録を確認してから一通だけ再確認します。

  1. 画面の文言と時刻を残す

    入力欄のエラー、送信処理の失敗、成功表示、結果が返らない状態を区別します。ボタンを押した時刻と対象ページを控えます。返信先や本文を公開の記録へ写す必要はありません。

  2. 入力エラーは該当する欄へ戻る

    エラー一覧のリンクで該当欄へ移動し、指摘された形式や長さを直します。入力検証で止まったことを確認できれば、SMTP設定を先に変える必要はありません。

  3. 送信結果が不明なら再送を止める

    失敗表示やタイムアウトでは、管理者が同じ時刻のログと送信サービスの記録を照合します。送信設定の値、パスワード、メール本文を記事や共有メモへ貼り付けません。

  4. 受信結果と次の担当を別に書く

    成功表示は受信の証拠に含めません。受信者が件名・本文の印・時刻を確認し、未着や未確認なら調べる場所と担当を残します。追加の実送信は状況を整理し、受信者と条件を決めてから行います。

画面と応答だけで分かる範囲を限定する

見えた状態分かること／分からないこと次の確認と担当
入力内容をご確認ください。今回の通常フォーム検証では302後に入力エラーを表示。メール処理には進まない。入力する人が一覧のリンクで該当欄を直す。
JSONで422、errorsに項目名JSON形式の入力検証エラー。通常フォームの画面表示とは別。実装担当がエラー項目と入力条件を照合する。
送信処理を完了できませんでした。送信処理で例外。例外だけでは実際の到達を断定できない。再送を止め、管理者が時刻・ログ・サービスの受付記録を照合する。
送信しました。だが受信箱にない成功表示のみ確認。配送と受信は未確認。受信者が迷惑メール・ルール、管理者が送信先と配送記録を確認する。
待ち続ける／結果が返らないどの段階で止まったか不明。裏で送信されている可能性も残る。連打せず時刻と状態を残し、管理者へ渡す。

入力エラー・403・419・500を分けて記録する

運営担当はまず、対象URL、ボタンを押した時刻、画面の文言、入力が残っているかを控えます。応答コードを取得できなければ「未確認」で構いません。送信ボタンやブラウザの再送を繰り返さず、同じ一件の記録を実装担当へ渡します。

欄ごとの入力エラー
通常フォームでは、戻った画面のエラーを確認します。JSONの422と区別し、形式・必須項目・長さを直します。入力検証で止まった根拠がある場合だけ、その段階まで分かったと記録します。
419・Page Expiredなどの表示
Laravelではリクエストの保護で止まる場合があります。表示だけでセッション切れやメールの未着と断定しません。実装担当が同時刻の応答・例外、送信元の判定とセッション／トークンの対応を確認します。Cookieやトークンの値を共有メモへ貼り付ける必要はありません。
500・Internal Server Error
サーバー側のエラーですが、処理がどこまで進んだかはコードだけでは分かりません。実装担当が同時刻のログと受付記録を照合するまで、結果不明として再送を保留します。evulixのメール処理の例外は捕捉して302後に失敗表示へ戻すため、500と同じ経路ではありません。
応答がない・タイムアウト
送信済みか判断できない状態です。画面と時刻を残し、受付・配送・受信を別々に確認します。画面を開き直す操作と、もう一度送る判断を分けてください。
実装担当が確認する根拠と、隔離検証の範囲

Laravel 13の標準保護は送信元の判定を先に確認し、通らない場合はセッションとトークンを照合します。同じ送信元で通る条件もあり、設定やバージョンによって挙動は異なります。保護を無効にして送信を通す方法ではなく、どの判定で止まったかを調べます。 送信元だけを検証するoriginOnly設定では、判定を通らない応答は403になります。419が出ないことだけで保護を通ったと判断せず、実際の設定と応答を照合してください。この設定の403は、下の隔離検証では実測していません。

Laravel 13のリクエスト保護（公式資料・別タブ）、HTTP 500の意味（MDN・別タブ）

2026-10-09 / Laravel 13.19.0 / PHP 8.5.1
メモリ内のリクエストとセッションを用いた隔離検証。
テスト用クラスだけで通常のテスト省略を解除。
トークンの照合へ進む条件:
  トークンなし → 419 / 後続ハンドラ 0回
  不一致 → 419 / 後続ハンドラ 0回
  一致 → 仮の後続ハンドラ 1回
同じ送信元の判定が通る条件:
  トークンなし → 仮の後続ハンドラ 1回
実メール 0通 / 受信 未確認

ミドルウェアを直接呼び、例外からの419応答を確認した記録です。実ブラウザのPOST・本番障害・問い合わせ処理・SMTP・受信を再現したものではありません。500はこの検証では発生させていません。上の10月7日の入力・送信処理のテスト、10月6日の本番受信とは別の確認です。

画面・応答・未確認を記録して次の担当へ →

運用に残すのは結果と、次に確認する場所

対象フォーム、確認日、入力条件、画面の表示、受信結果、まだ分からないことを残します。画面の表示、送信サービスの受付、受信者による確認は別々に記録してください。受信が不明なら到達は未確認です。画面だけで送信処理の完了とも判断せず、フォーム・SMTP・宛先を変えたら再点検します。

読者向けページには受け付ける内容、必要な報告情報、返信できない場合を簡潔に案内します。名前・返信先・本文以外の必須項目は用途から判断します。動作の点検と、何を連絡できるかの説明が揃って初めて、使える連絡先になります。

送信・受信点検の記録用メモ
点検識別名／対象の公開版・設定の識別（秘密の値は書かない）:
対象フォーム:
確認日時・タイムゾーンと照合用の印:
確認方法（実ブラウザ／配送を止めたテスト等）:
画面を確認した担当／受信を確認する担当:
実送信の許可と照合方法（実送信する場合）:
入力条件（任意URLなし等）:
画面の結果・確認日時:
アプリログの照合結果・日時・確認した担当:
送信サービスの受付記録・日時・確認した担当:
受信側の結果・確認日時・確認した担当:
今回確認していない段階:
再送の判断と根拠（結果不明なら保留）:
追加送信を判断する担当／受信者の許可と照合方法:
次に調べる場所と確認条件:
確認する担当／確認予定日: