問い合わせフォームの「送信完了」は、受付担当者が実際に受信した証明ではありません。画面表示、入力、送信処理、保存、メール配送、受信側、外部連携、担当通知を分け、同じテスト条件で順番に確認すると原因を絞れます。
問い合わせを受けられない可能性がある間は、復旧調査と同時に代替連絡手段を案内します。 既存の電話、メール、予約サービス等、実際に受け付けられる経路だけを掲載し、障害中のフォームへ誘導し続けません。個人情報を含むテスト送信は避けます。
症状を「届かない」だけでまとめない
| 症状 | 最初に見る場所 | 確認例 |
|---|---|---|
| ページが開かない | HTTP、CDN、サーバー、CMS | 端末・回線を変えた表示、ステータス、エラーログ |
| 入力・選択できない | HTML、JavaScript、重なり、端末 | 必須項目、キーボード操作、スマートフォン |
| 送信ボタンが進まない | 入力検証、トークン、CAPTCHA、JavaScript | エラー表示、開発者コンソール、期限切れ |
| 送信エラーになる | サーバー、フォーム処理、権限、外部API | 時刻、リクエスト、アプリ・サーバーログ |
| 完了画面は出るが届かない | 保存、メール生成、配送、受信側 | 受付記録、送信ログ、拒否・隔離、宛先 |
| 自動返信だけ届かない | 入力メール、送信元認証、受信側 | 誤入力、From、迷惑メール、バウンス |
| 遅延・重複する | キュー、再試行、二重送信、Webhook | 受付ID、送信時刻、再送回数 |
| CRM・予約表へ入らない | Webhook、認証、項目対応 | 外部サービスの応答、トークン、マッピング |
最初に障害範囲と代替受付を確定する
- 発生を確認した日時、最後に正常だった日時、変更作業の有無を記録します。
- 全員か一部か、PC・スマートフォン、ブラウザ、回線、フォーム種類で範囲を分けます。
- 画面エラー、入力内容、送信時刻、テスト用メールアドレス、受付IDを記録します。
- 現在使える既存の連絡手段を確認し、障害案内と代替受付を表示します。
- 復旧までは不用意な更新・キャッシュ削除・プラグイン停止を重ねず、変更履歴を残します。
医療・士業・採用・緊急対応等では、フォーム停止が利用者の判断へ与える影響も確認します。案内文には、停止中の機能、利用できる連絡方法、受付時間、復旧状況など、確認済みの情報だけを記載します。
送信から担当対応までを10段階に分ける
| 段階 | 成立条件 | 証拠 |
|---|---|---|
| 1. 表示 | フォーム本体と必要なスクリプトが読み込まれる | HTTP応答、ブラウザ表示 |
| 2. 入力 | 項目、選択、添付、同意が操作できる | 端末別操作記録 |
| 3. 検証 | 必須、形式、トークン、CAPTCHAが正しく判定される | 画面エラー、リクエスト |
| 4. 受付処理 | サーバーや外部サービスが送信を受け取る | アプリ・サーバーログ |
| 5. 保存 | 必要に応じ受付記録や受付IDが残る | 管理画面、データベース、監査ログ |
| 6. メール生成 | 宛先、件名、本文、ヘッダーが組み立てられる | アプリログ、メールログ |
| 7. 配送引渡し | 送信サーバーが宛先サーバーへ引き渡す | キュー、応答コード、バウンス |
| 8. 受信 | 宛先側が受け入れ、受信箱・隔離等へ振り分ける | メール管理ログ、検索結果 |
| 9. 担当通知 | 共有先、CRM、チャット等で担当へ届く | 通知履歴、担当割当 |
| 10. 対応 | 担当者が受付を確認し返信・処理する | 受付台帳、返信記録 |
完了画面は主に1〜4の結果です。7〜10を別に確認しない限り、「届いた」「対応された」とは判断できません。
画面・入力・モバイルの不具合を確認する
- 代表的なPC・スマートフォン、ブラウザ、通常・プライベート表示で再現する
- 必須項目、文字数、メール形式、電話番号、日付、選択肢、同意を確認する
- エラー文が該当項目の近くに表示され、キーボードでも移動できるか確認する
- 固定ボタン、Cookie通知、広告、ヘッダーが送信ボタンへ重なっていないか確認する
- 二重クリック、戻る操作、通信切断で重複送信や入力消失が起きないか確認する
- 添付の種類・容量・ファイル名により失敗しないか確認する
広告ブロッカーやブラウザ拡張の影響もありますが、利用者へ無条件に無効化を求める前に、サイト側のJavaScriptエラー、外部スクリプト依存、同意管理を確認します。
WordPress・サーバー側は変更履歴とログから見る
WordPressでは、フォーム本体だけでなく、テーマ、プラグイン、PHP、サーバー、キャッシュ、セキュリティ機能の組合せで不具合が起きます。更新日と発生日時を照合し、バックアップやステージング環境がある場合はそこで再現します。
- PHP・Webサーバーのエラー、タイムアウト、メモリ、ファイル容量
- フォーム・SMTP・セキュリティ・キャッシュ関連の更新と競合
- REST API、非同期通信、nonce・トークン、セッションの失敗
- 送信先設定、条件分岐、テンプレート、権限、環境変数の変更
- 外部APIの停止、認証期限、利用上限、応答時間
WordPressのサイトヘルス（公式ドキュメント）は、構成や推奨事項を確認する入口になります。ただし、表示された項目を一括変更せず、フォーム障害との関係を確認してから個別に対応します。
キャッシュ・CDN・セキュリティ・CAPTCHAを切り分ける
| 要素 | 起きる症状 | 確認 |
|---|---|---|
| ページキャッシュ | 古いトークンや設定が残る | 対象URL、除外設定、ログイン外表示 |
| CDN・WAF | 送信リクエストが遮断される | 時刻、IP、ルール、応答コード |
| JavaScript最適化 | 検証・送信処理が実行されない | 結合・遅延対象、コンソールエラー |
| CAPTCHA | 判定失敗やキー・ドメイン不一致 | 管理画面、スコア、期限、登録ドメイン |
| Cookie・同意管理 | 必要な処理が許可前後で変わる | 同意状態別テスト、スクリプト分類 |
キャッシュを全消去すると一時的に直ることがありますが、再発原因の特定にはなりません。変更前状態、対象、実施時刻、結果を記録します。
送信元・返信先・配送経路を混同しない
メール設定では、表示上の送信者（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・予約・通知ツールは外部連携として確認する
| 確認項目 | 見る内容 |
|---|---|
| サービス状態 | 障害情報、メンテナンス、利用上限 |
| 認証 | APIキー、トークン、権限、期限 |
| 送信結果 | HTTP応答、タイムアウト、再試行 |
| 項目対応 | 必須項目、形式、選択肢、文字コード |
| 重複防止 | 受付ID、冪等性、二重クリック、再送 |
| 担当通知 | チャンネル、割当、通知停止、権限 |
フォームの保存が成功しても外部連携だけ失敗する場合があります。利用者へ完了を表示する条件と、運用上の受付成立条件を決め、失敗時の再処理手順を用意します。
ログと個人情報は必要最小限にする
診断にログは必要ですが、問い合わせ本文、氏名、電話、メール、添付、IP等を無制限に残しません。取得目的、閲覧者、保存期間、削除、バックアップ、外部サービスへの送信を確認します。
- ログへ残す項目を受付ID、時刻、結果コード等に絞る
- 画面共有や障害票では個人情報・認証情報をマスクする
- 本番テストに架空の非機微データと管理下の連絡先を使う
- アクセス解析へフォーム入力値を送らない
- 復旧後に一時ログ、テストデータ、仮アカウントを整理する
復旧判定は受入試験表で行う
| 試験 | 期待結果 | 証拠 |
|---|---|---|
| 正常入力 | 1回だけ受付され完了が表示される | 画面、受付ID、保存記録 |
| 入力エラー | 該当項目を示し送信されない | 画面、受付記録なし |
| 管理者通知 | 正しい宛先へ実受信する | 受信時刻、ヘッダー |
| 自動返信 | テスト宛先へ必要最小限の内容で届く | 受信時刻、本文 |
| 外部連携 | CRM・予約・通知へ1件登録される | 連携履歴、受付ID |
| 端末 | 代表的PC・スマートフォンで操作できる | 端末別結果 |
| 代替受付 | 障害時に有効な連絡先へ到達できる | リンク・受付確認 |
修正担当者だけでなく、実際の受付担当者が受信・割当・返信まで確認して復旧とします。メールが遅延する構成では、判定までの待機時間も決めます。
監視はページ表示と実受信を分ける
HTTP監視だけではメール配送や担当通知の停止を検知できません。利用規約と個人情報に配慮したテスト環境・テスト宛先を使い、必要な範囲で定期確認します。
- フォームページのHTTP、必要スクリプト、送信API
- テスト送信の受付ID・保存・管理者通知・自動返信
- 外部サービスの応答、認証期限、利用上限
- メールのバウンス、隔離、キュー、DMARCレポート
- 担当者・共有先・返信運用の変更
監視の自動送信が本番の問い合わせ件数やCRMを汚さないよう、テスト識別、除外、削除手順を決めます。
サイト運営者・制作会社・各事業者の担当を分ける
| 担当 | 主な確認範囲 |
|---|---|
| サイト運営者 | 受付先、担当者、代替連絡、個人情報、復旧承認 |
| 制作・保守 | 画面、CMS、フォーム処理、ログ、公開・監視 |
| サーバー事業者 | Web・PHP・メール送信基盤、制限、障害 |
| DNS・メール事業者 | SPF・DKIM・DMARC、配送、受信、隔離 |
| 外部サービス | フォーム、CAPTCHA、CRM、予約、Webhook、API |
管理権限や契約が分散している場合、原因調査前に窓口、契約者、ログ取得可否を整理します。制作会社だけでメール事業者や社内受信ルールを変更できない場合があります。
修正方法と費用は原因・権限・再発防止で変わる
| 区分 | 作業例 |
|---|---|
| 緊急切り分け | 再現、影響範囲、代替受付、ログ保全 |
| 画面・CMS修正 | フォーム、検証、テーマ、競合、モバイル |
| メール修正 | 送信元、SMTP・API、DNS認証、受信ルール |
| 外部連携修正 | 認証、項目対応、再試行、重複防止 |
| 再発防止 | 受入試験、監視、ログ、担当・手順整備 |
フォーム数、条件分岐、添付、外部サービス、メール環境、管理権限、緊急度、監視範囲を確認して個別に見積もります。料金の考え方は料金案内、継続管理はWordPress保守管理で確認できます。
原因調査から復旧・監視までの8工程
- 症状、発生日時、影響範囲、直前変更を確認します。
- 変更前の設定・本文・ログを保存し、代替受付を確認します。
- 画面、入力、受付処理、保存、メール、受信、連携を順番に再現します。
- 原因候補を絞り、影響範囲と修正・戻し方を合意します。
- 必要箇所だけを修正し、認証情報や個人情報を保護します。
- 端末、入力エラー、管理者通知、自動返信、外部連携を試験します。
- 受付担当者が実受信・割当・返信まで確認して復旧を承認します。
- 監視、更新、担当変更、障害時の代替受付を運用へ残します。
問い合わせフォーム不具合のよくある質問
完了画面が出ればメールも届いていますか？
断定できません。フォーム処理が完了しても、メール生成、送信サーバー、宛先サーバー、隔離、受信ルール、担当通知で止まる場合があります。実受信と受付記録を確認します。
自分宛てだけ届かない場合もサイト側の問題ですか？
サイト側・受信側の両方が候補です。送信ログと応答、別の管理下テスト宛先、受信ルール、迷惑メール・隔離、容量を同じ時刻で照合します。
SMTPを入れれば必ず直りますか？
保証できません。送信経路が改善する場合はありますが、From・Reply-To、SPF・DKIM・DMARC、受信側、フォーム処理、外部連携も確認が必要です。
原因調査だけ依頼できますか？
可能です。対象URL、症状、発生日時、最後に正常だった時刻、直前変更、管理範囲を確認し、再現、原因候補、緊急対応、恒久対応を分けます。
復旧後は何を確認すればよいですか？
代表端末、正常・異常入力、管理者通知、自動返信、外部連携、重複防止、代替受付を試験し、受付担当者が実受信と対応開始まで確認します。
フォーム不具合の調査・WordPress保守を相談する
対象URL、症状、発生日時、最後に正常だった時刻、直前の更新、利用中のフォーム・メール・外部連携、管理できる範囲が分かると、緊急対応、原因調査、修正、受入試験、監視を分けて整理できます。フォーム自体が停止している場合は、現在利用できる既存の連絡手段からご連絡ください。