フォームの不具合・
メールが届かない
トラブルのご相談

問い合わせフォームの「送信完了」は、受付担当者が実際に受信した証明ではありません。画面表示、入力、送信処理、保存、メール配送、受信側、外部連携、担当通知を分け、同じテスト条件で順番に確認すると原因を絞れます。

問い合わせを受けられない可能性がある間は、復旧調査と同時に代替連絡手段を案内します。 既存の電話、メール、予約サービス等、実際に受け付けられる経路だけを掲載し、障害中のフォームへ誘導し続けません。個人情報を含むテスト送信は避けます。

症状を「届かない」だけでまとめない

最初に障害範囲と代替受付を確定する

1. 発生を確認した日時、最後に正常だった日時、変更作業の有無を記録します。
2. 全員か一部か、PC・スマートフォン、ブラウザ、回線、フォーム種類で範囲を分けます。
3. 画面エラー、入力内容、送信時刻、テスト用メールアドレス、受付IDを記録します。
4. 現在使える既存の連絡手段を確認し、障害案内と代替受付を表示します。
5. 復旧までは不用意な更新・キャッシュ削除・プラグイン停止を重ねず、変更履歴を残します。

医療・士業・採用・緊急対応等では、フォーム停止が利用者の判断へ与える影響も確認します。案内文には、停止中の機能、利用できる連絡方法、受付時間、復旧状況など、確認済みの情報だけを記載します。

送信から担当対応までを10段階に分ける

完了画面は主に1〜4の結果です。7〜10を別に確認しない限り、「届いた」「対応された」とは判断できません。

画面・入力・モバイルの不具合を確認する

• 代表的なPC・スマートフォン、ブラウザ、通常・プライベート表示で再現する
• 必須項目、文字数、メール形式、電話番号、日付、選択肢、同意を確認する
• エラー文が該当項目の近くに表示され、キーボードでも移動できるか確認する
• 固定ボタン、Cookie通知、広告、ヘッダーが送信ボタンへ重なっていないか確認する
• 二重クリック、戻る操作、通信切断で重複送信や入力消失が起きないか確認する
• 添付の種類・容量・ファイル名により失敗しないか確認する

広告ブロッカーやブラウザ拡張の影響もありますが、利用者へ無条件に無効化を求める前に、サイト側のJavaScriptエラー、外部スクリプト依存、同意管理を確認します。

WordPress・サーバー側は変更履歴とログから見る

WordPressでは、フォーム本体だけでなく、テーマ、プラグイン、PHP、サーバー、キャッシュ、セキュリティ機能の組合せで不具合が起きます。更新日と発生日時を照合し、バックアップやステージング環境がある場合はそこで再現します。

• PHP・Webサーバーのエラー、タイムアウト、メモリ、ファイル容量
• フォーム・SMTP・セキュリティ・キャッシュ関連の更新と競合
• REST API、非同期通信、nonce・トークン、セッションの失敗
• 送信先設定、条件分岐、テンプレート、権限、環境変数の変更
• 外部APIの停止、認証期限、利用上限、応答時間

WordPressのサイトヘルス（公式ドキュメント）は、構成や推奨事項を確認する入口になります。ただし、表示された項目を一括変更せず、フォーム障害との関係を確認してから個別に対応します。

キャッシュ・CDN・セキュリティ・CAPTCHAを切り分ける

キャッシュを全消去すると一時的に直ることがありますが、再発原因の特定にはなりません。変更前状態、対象、実施時刻、結果を記録します。

送信元・返信先・配送経路を混同しない

メール設定では、表示上の送信者（From）、返信先（Reply-To）、配送に使う送信元、受信先を分けます。訪問者が入力した外部メールアドレスを、そのままサイトのFromとして使うと、送信ドメインとの不一致になりやすいため、サイトで管理するドメインをFromにし、訪問者のアドレスはReply-To等へ適切に設定します。

• 管理者通知と自動返信で宛先・送信元・件名を別々に確認する
• テスト用アドレスを使い、実在顧客の内容を転送しない
• 送信サーバーの受付、キュー、応答コード、バウンスを確認する
• SMTPやAPIの認証情報を画面共有・チケット・公開ログへ貼らない
• 障害対応で一時設定を行った場合は、期限と戻し方を記録する

SPF・DKIM・DMARCは送信ドメイン単位で確認する

メール認証は、送信元の正当性を宛先側が判断する材料です。サイト、メールサービス、DNSを管理する事業者が異なる場合は、どのサービスが実際に送信するかを先に特定します。

• SPF: 利用する送信元がドメインの許可範囲に含まれるか
• DKIM: 送信メールへ署名され、公開鍵で検証できるか
• DMARC: SPF・DKIMとの整合、方針、レポート先が適切か
• TLS: 送信経路で暗号化が利用されるか

Googleのメール送信者のガイドラインでは、Gmail宛て送信者に認証等の要件を示しています。必要条件は送信量や構成で異なるため、利用中のメール・DNS事業者の現行手順も確認します。認証設定は到達を保証するものではありません。

受信側の迷惑メール・隔離・転送・容量も調べる

送信側が正常でも、受信側のルールや容量で見えなくなることがあります。個人の受信箱だけでなく、組織のメール管理ログや隔離領域を確認します。

• 迷惑メール、隔離、削除済み、全メールを件名・送信元・時刻で検索する
• 受信ルール、転送、共有アドレス、グループ、エイリアスの変更を確認する
• メールボックス容量、アカウント停止、受信拒否、許可リストを確認する
• 宛先サーバーの拒否理由や一時エラーと、送信側の再試行を照合する
• 担当者退職・異動後も旧アドレスだけへ送られていないか確認する

自動返信は受付確認と情報漏えいの両方を見る

自動返信が届かない場合、入力したメールアドレス、送信処理、配送、受信側を確認します。自動返信に問い合わせ本文や機微情報をそのまま再掲すると、誤入力時の漏えい範囲が広がります。

• 受付日時や受付ID等、必要最小限の情報だけを返す
• クレジットカード、健康、本人確認等の機微情報をメールへ含めない
• 添付ファイルを自動返信へ付け直さない
• 返信予定を示す場合は、実際の運用で守れる条件だけを書く
• 自動返信が本人確認や契約成立を意味しない場合は誤認を避ける

Webhook・CRM・予約・通知ツールは外部連携として確認する

フォームの保存が成功しても外部連携だけ失敗する場合があります。利用者へ完了を表示する条件と、運用上の受付成立条件を決め、失敗時の再処理手順を用意します。

ログと個人情報は必要最小限にする

診断にログは必要ですが、問い合わせ本文、氏名、電話、メール、添付、IP等を無制限に残しません。取得目的、閲覧者、保存期間、削除、バックアップ、外部サービスへの送信を確認します。

• ログへ残す項目を受付ID、時刻、結果コード等に絞る
• 画面共有や障害票では個人情報・認証情報をマスクする
• 本番テストに架空の非機微データと管理下の連絡先を使う
• アクセス解析へフォーム入力値を送らない
• 復旧後に一時ログ、テストデータ、仮アカウントを整理する

復旧判定は受入試験表で行う

修正担当者だけでなく、実際の受付担当者が受信・割当・返信まで確認して復旧とします。メールが遅延する構成では、判定までの待機時間も決めます。

監視はページ表示と実受信を分ける

HTTP監視だけではメール配送や担当通知の停止を検知できません。利用規約と個人情報に配慮したテスト環境・テスト宛先を使い、必要な範囲で定期確認します。

• フォームページのHTTP、必要スクリプト、送信API
• テスト送信の受付ID・保存・管理者通知・自動返信
• 外部サービスの応答、認証期限、利用上限
• メールのバウンス、隔離、キュー、DMARCレポート
• 担当者・共有先・返信運用の変更

監視の自動送信が本番の問い合わせ件数やCRMを汚さないよう、テスト識別、除外、削除手順を決めます。

サイト運営者・制作会社・各事業者の担当を分ける

管理権限や契約が分散している場合、原因調査前に窓口、契約者、ログ取得可否を整理します。制作会社だけでメール事業者や社内受信ルールを変更できない場合があります。

修正方法と費用は原因・権限・再発防止で変わる

フォーム数、条件分岐、添付、外部サービス、メール環境、管理権限、緊急度、監視範囲を確認して個別に見積もります。料金の考え方は料金案内、継続管理はWordPress保守管理で確認できます。

原因調査から復旧・監視までの8工程

1. 症状、発生日時、影響範囲、直前変更を確認します。
2. 変更前の設定・本文・ログを保存し、代替受付を確認します。
3. 画面、入力、受付処理、保存、メール、受信、連携を順番に再現します。
4. 原因候補を絞り、影響範囲と修正・戻し方を合意します。
5. 必要箇所だけを修正し、認証情報や個人情報を保護します。
6. 端末、入力エラー、管理者通知、自動返信、外部連携を試験します。
7. 受付担当者が実受信・割当・返信まで確認して復旧を承認します。
8. 監視、更新、担当変更、障害時の代替受付を運用へ残します。

問い合わせフォーム不具合のよくある質問