PHP更新後にWordPressのフォームが送れない？原因の切り分けと復旧手順

PHPのセキュリティ更新後に「WordPressのお問い合わせフォームが送れない」「送信完了と表示されるのにメールが届かない」と気付いたら、最初にフォームの画面、WordPressからの送信、メールの配送・受信を分けて確認します。更新直後という時間の一致だけで、PHPの脆弱性や修正版そのものを原因と決めつけないことが大切です。フォームの設定、プラグインの互換性、SMTP接続、送信ドメイン認証、迷惑メール判定など、障害が起きる場所は複数あります。

この記事は、会社サイトのWordPressを運用し、PHPを更新した後の問い合わせ機会損失を避けたい担当者向けです。Contact Form 7とWP Mail SMTPを例に、症状の切り分け、復旧の優先順位、受信漏れの確認、再発防止まで具体的に説明します。独自のフォームや別のメールプラグインを使う場合も、同じ順序で「画面→アプリケーション→配送→受信」を確認できます。確認日：2026年10月23日。製品やサーバーの画面は変更されるため、操作前に各公式資料を確認してください。

PHP更新後にフォームが送れないとき、最初の10分で確認すること

結論：「送信ボタンが動かない」「赤枠で失敗する」「緑枠で成功するがメールがない」では、疑うべき場所が違います。変更履歴と時刻を残し、実際のフォームを一度だけ安全にテストし、受信箱・迷惑メール・送信テストの結果を並べてください。最初からPHPを旧版へ戻したり、フォームプラグインを消したりすると、原因が見えなくなります。

①症状を三つに分け、問い合わせを取りこぼさない

障害を見つけた担当者は、まず対象URL、発生した時刻、更新したPHPの前後の版、同時に更新したWordPress・プラグイン・テーマ、フォームの種類を記録します。個人情報を扱う問い合わせがあるサイトでは、検証は架空の氏名と自分たちのテスト用メールアドレスで行い、画面を撮影するときも本物のお客様の入力を写さないでください。次に、スマートフォンとPCの両方で公開ページを開き、送信前・送信後の状態と表示されたメッセージを記録します。ボタンが反応しない場合はブラウザー側のスクリプトやフォーム読み込み、送信後にエラーが出る場合はアプリケーションやメール処理、成功画面なのにメールがない場合は配送・受信に重点を置きます。

受付停止中の機会損失は診断と同時に防ぎます。電話番号や代替窓口が既にあるなら公開ページの上部に案内し、顧客からの連絡が届かない可能性を担当部署へ伝えてください。復旧できるまでフォームが「送信できた」と誤認させる状態を放置しないことが重要です。ただし、顧客の情報を守るため、フォーム内容を外部の個人アカウントへ無断転送したり、テストのために本番の顧客データを複製したりしないでください。受付停止の開始時刻と代替窓口への誘導開始時刻も記録すれば、後で問い合わせ漏れの範囲を特定できます。

②Contact Form 7の色とメッセージを読み違えない

Contact Form 7の公式FAQでは、赤い枠はwp_mail()を使った送信が失敗した状態、オレンジの枠はスパムと判断された状態、緑の枠は送信処理が成功した状態として説明されています。緑枠は「相手の受信箱まで届いた」ことの証明ではありません。迷惑メールフォルダや受信側フィルターで止まる場合があります。また、同じエラー文面がメール送信失敗とスパム判定に使われるため、文字だけで判断しないで枠色やフォームの状態を見ます。公式の日本語FAQとフォーム状態の説明を基準にしてください。

見えた症状	最初に疑う場所	最初の確認
ボタンが反応しない、画面が固まる	画面・JavaScript・通信	別ブラウザー、開発者ツール、フォームの読み込み
赤枠のエラー	WordPressからのメール送信	フォーム設定、WP Mail SMTPテスト、送信エラー
オレンジ枠のエラー	スパム判定	CAPTCHA・Akismet・スパム対策の設定
緑枠で成功、受信箱にない	配送・受信	送信先、迷惑メール、メール認証、受信側ログ
500エラーや管理画面も停止	PHP互換性・致命的エラーなど	サーバーログ、WordPressリカバリーモード

表は「原因の確定」ではなく、調査を始める順番です。例えば赤枠でもプラグインの設定不備、メールサーバーの拒否、送信経路の遮断など候補は複数あります。更新前のテスト結果がない場合は「更新が原因」と言い切らず、「更新後に発見した障害」と記録してください。復旧後に同じ手順で再試験できるよう、試験時刻、送信先、画面上の結果、実際の受信の有無を一行ずつ残します。

③PHPのセキュリティ修正版を戻す前に代替策を確認する

2026年10月21日にPHP公式が公開したセキュリティリリースは、重大な脆弱性への修正を含みます。WordPress公式もPHP側の更新を促しています。フォーム不具合が同じ日に判明しても、脆弱性がメール機能を止めたという根拠にはなりません。旧版へ安易に戻すと、サイトの露出を増やす可能性があります。まずテスト環境でプラグインやテーマの互換性を確認し、メール設定や認証、サーバーの送信制限を調べてください。やむを得ず一時的なロールバックを検討する場合は、サイト管理者・ホスティング事業者と公開範囲、期間、暫定防御、修正版へ戻す期限を合意します。

PHPの脆弱性自体の対象と修正版はPHP公式のリリースで確認できます。ホスティング事業者が修正をバックポートしている場合、画面上の版番号だけでは判断できないため、事業者の告知も見ます。詳しい対象確認はPHPの対象バージョン確認記事、更新全体の流れはWordPressのPHP安全更新記事を参照してください。本記事はその次の「フォームが動くか」に集中します。

「送信できない」と「届かない」を切り分ける実務手順

結論：一つのテスト送信で、画面の完了表示、WordPressの送信処理、メール配送、受信箱への到達を別々に記録します。テストを繰り返す前に送信制限や本番顧客への通知を確認し、二重送信で混乱を増やさないようにします。

テストメールの条件をそろえる

本番フォームで検証する場合は、利用者の入力項目と同じ形式のダミー情報を使い、件名か本文に検証IDと時刻を入れます。例えば「検証 2026-10-23 15:00 A」として、同じ検証IDを作業記録、送信先受信箱、サーバーへの問い合わせに使います。管理者宛と自動返信の両方がある場合は、別々に到達を確認してください。一通が届いても、もう一通が失敗していれば問い合わせ業務としては未復旧です。送信先は管理者と実際の受信運用に近い社内アドレスに限定し、外部の無関係なアドレスへテストをばらまきません。

送信テストの期待結果も先に決めます。フォームの送信完了、管理者宛の到達、自動返信の到達、添付ファイルの受信、問い合わせ内容の文字化けの有無、受付担当への通知やCRM連携がある場合の記録までが検収対象です。まず添付なしの最小入力で試し、成功したら添付・長文・複数選択など実際に利用する入力条件へ進みます。最初から大きなファイルを添付すると、メールサイズ制限とPHP更新の関係が見えにくくなります。各条件を変えるのは一つずつにしてください。

送信前に「最終受信者」と業務の流れを確認する

メールの送信先がWordPressの設定画面で正しく見えても、実際にはメーリングリスト、社内転送、共同受信箱、CRM取り込み用アドレスなどを経由する場合があります。受付担当は、最初の宛先だけでなく最終的に誰がどの画面で問い合わせを見るのかを確認します。フォームのメールが社内サーバーまでは届き、共同受信箱への転送で止まっているなら、WordPress側の設定を何度変えても改善しません。逆に受付担当が個人の受信箱だけを見ている間に、チーム共有の受信箱へは届いていることもあります。

診断用の表には「公開フォームの送信先」「送信サービス上の宛先」「最終受信箱」「実際に読む担当者」を別の列に書きます。社外委託先が確認しているなら、契約上の連絡経路と営業時間も書きます。緊急時に外部の個人メールへ転送先を変えると、顧客情報の保護や後の引き継ぎに問題が出るため、事前に承認された代替窓口を使います。作業の完了条件は「担当者がテスト問い合わせを業務画面で開き、返信できること」です。メールの技術的な配送だけでは、顧客対応の再開を確認したことになりません。

フォーム画面の結果を確認する

クリック前からボタンが無効になっている場合、必須項目の未入力、同意チェック、JavaScriptの読み込み失敗などを先に調べます。別ブラウザー・シークレットウィンドウで再現するか、開発者ツールのコンソールと通信タブにエラーがあるかを記録します。ネットワーク上で403が出ている場合はWAFなどの遮断も候補です。ただし、WAFの機能を無効にして本番全体へ影響させる前に、対象リクエストと遮断ルールをホスティング事業者へ確認してください。画面だけ成功でも、その時点では管理者のメール受信は未確認です。

Contact Form 7なら枠色と状態を見ます。赤枠ではメール送信処理、オレンジ枠ではスパム判定に進みます。オレンジ枠を「SMTPエラー」と決めつけてメールプラグインを交換しても改善しません。緑枠なら受信側とメール認証へ進みます。公式FAQは、緑枠でも迷惑メールフィルターなどで受信できない場合があると説明しています。緑枠で届かない場合の公式FAQを参考にしてください。

WP Mail SMTPのテスト結果と実フォームの結果を比べる

WP Mail SMTPを使っているなら、管理画面のテストメール機能で検証用アドレス宛に一通送ります。公式ドキュメントは、設定したメーラーやドメインの確認とともにテストメールを送る手順を示しています。テストメールも失敗すれば、SMTP認証、APIメーラー、送信先へのネットワーク接続、送信ドメイン認証、サーバーの制限など共通の経路を調べます。テストメールだけ成功して実フォームだけ失敗するなら、フォーム側の差出人、宛先、ヘッダー、添付やフォームプラグインとの連携を優先します。公式のテストメール手順とトラブルシューティングに沿って確認します。

WP Mail SMTPを利用していないサイトでは、このプラグインの導入が唯一の解決策ではありません。既にホスティング事業者のSMTPやメールAPI、別の送信プラグインを利用している場合は、その送信経路でログとテスト結果を確認します。複数のメール送信プラグインを同時に追加すると送信経路が分かりにくくなるため、まず現在の構成を図にしてください。「フォーム→WordPress→送信プラグインまたはPHPのメール機能→メールサービス→受信側」のどこまで証拠があるかを判断します。送信プラグインを入れ替えるのは、その経路で障害箇所が特定された後です。

二つのテストを掛け合わせて障害箇所を絞る

実フォームの送信とメールプラグインのテストを、同じ時刻帯・同じ受信先で比べると、次のように調査の順番を絞れます。両方失敗なら共通の送信経路を優先します。テストメールだけ成功ならフォーム固有の設定や送信条件を見ます。両方成功表示で未着なら受信・配送を見ます。実フォームだけ成功表示で受信もでき、テストメールだけ失敗なら、テスト機能で選ばれた差出人やメーラー設定が本番フォームと異なる可能性があります。単純な二分法ではなく、差出人、件名、宛先、添付の違いも書き添えて判断します。

実フォーム	メールテスト	優先調査	次の証拠
失敗	失敗	共通の送信経路	送信サービスのエラーと接続
失敗	成功	フォーム固有の設定	差出人・宛先・設定検証
成功表示、未着	成功表示、未着	配送・受信側	配送ログ・隔離・認証
成功して到達	失敗	テスト機能の条件	メーラー・差出人の差

この表でも原因を断定できない場合があります。送信サービスのログに受け付け記録があるのか、受信サービスに配送・隔離記録があるのかを確認してください。WordPress側の「送信成功」は、受信側のサーバーがメールを受け入れた証拠とは別です。ログが保存される期間はサービスごとに異なるため、調査依頼を後回しにしないことも重要です。障害の開始時刻が曖昧な場合は、最後に正常受信できた問い合わせと、最初に未着が判明した問い合わせの間を調査対象にします。

メールの「受け取れない」を受信側からも調べる

フォームは成功、送信テストも成功なのに担当者に届かない場合は、宛先の表記、転送設定、迷惑メールフォルダー、受信側の隔離領域、ドメインごとの受信拒否を確認します。受信サーバーやメールサービスの管理者がログを見られるなら、検証ID・送信時刻・差出人・受信者を渡して配送結果を照合します。「送信成功」は受信保証ではありません。GmailやMicrosoft 365のような受信サービスでは、迷惑メール判定や組織ポリシーで個人の受信箱に出ないこともあります。担当者個人の画面だけでなく、組織の管理者が確認できる範囲を使います。

送信ドメインのSPF、DKIM、DMARCは、差出人の正当性を判断する手掛かりです。WP Mail SMTPのテスト結果には送信ドメインの設定上の問題が示される場合があります。設定が足りないと分かったら、メールサービスの公式手順とDNS管理者を確認し、既存レコードを把握してから変更します。SPFを何本も追加すると逆に誤動作する場合がありますし、DMARCを強い拒否設定にする前には既存の正規送信経路を洗い出す必要があります。急いでDNSを変更するより、まず現在の値と利用中の送信サービスを照合することが安全です。

Contact Form 7の設定・プラグイン互換性を確認する

結論：フォームのメール設定とプラグインの動作を別々に確認します。特に差出人と返信先を混同しないこと、設定エラーを検証すること、PHPのエラーログを安全に見ることが重要です。PHP更新を理由にすべてのプラグインを一括停止する必要はありません。

差出人・宛先・返信先を役割で整理する

Contact Form 7の「メール」設定には、送信先、送信元、題名、追加ヘッダー、本文、添付ファイルが分かれています。公式のメール設定手順は、送信元にサイトのドメインに属するメールアドレスを使うことを勧めています。問い合わせ者が入力したメールアドレスを送信元に直入れすると、なりすましと判断されやすくなります。返信が必要なら追加ヘッダーにReply-To: [your-email]を設定します。ただし、実際のフォームタグ名がyour-emailでない場合は一致する名前へ直します。テストでは未入力や不正なアドレスがヘッダーに入らないことも確認してください。

たとえば自社ドメインの「フォーム通知用アドレス」を送信元、受付チームのアドレスを送信先、入力された利用者のアドレスを返信先にすると、運用上の役割が明確です。自動返信メールの差出人も自社ドメインの送信可能なアドレスにし、利用者の入力内容をそのまま件名に入れないようにします。メールサービスによっては送信元アドレスの事前登録やドメイン認証が必要です。WordPress画面の設定値だけでなく、メールサービス側にその差出人を使う許可があるか確認します。顧客が入力したアドレスを公開記事やログに掲載しないでください。

設定検証の警告を読んでから修正する

Contact Form 7の設定検証は、メールタブの不正なヘッダーやメールボックス構文を検出します。警告を「よく出るもの」として無視せず、どの欄とどのタグの対応に問題があるかを調べます。送信先へフォームタグを使っている場合、任意入力なら空になる可能性があります。メールアドレスを必須のemail*項目にしたうえで、メールタグがその項目を参照しているか確認してください。本文中のタグ誤記は送信そのものを止めなくても、お客様の入力内容が欠ける原因になります。設定変更前の画面を保存し、戻せる状態にしてから一項目ずつ修正します。

公式の設定エラーの説明と日本語の設定検証FAQを参照してください。警告が消えたことだけを完了条件にせず、実フォームから管理者宛と自動返信の両方が届くか確認します。修正後に追加ヘッダーが期待通り入っているか、受信したメールのヘッダーも見ます。ここで返信先が顧客のアドレスになっていれば、担当者が「返信」を押したときの誤送信を減らせます。メールの細かなヘッダー情報には個人情報が含まれるため、共有範囲を限定してください。

Mail (2)の自動返信は通知メールと分けて点検する

Contact Form 7でMail (2)を使うと、管理者宛とは別のメールテンプレートを送れます。担当者へ通知が届いても、自動返信が未着なら、応募者や顧客は「送信できなかった」と考えて再送するかもしれません。逆に自動返信だけ届いて管理者通知が止まれば、問い合わせは受け付けたつもりで放置されます。二つのメールは宛先、送信元、本文、添付の条件が違うので、それぞれのテストIDを同じ案件として記録します。Mail (2)の宛先に入力者のメールタグを使うなら、そのタグが必須で妥当なメール形式か確認してください。

自動返信メールの本文へ、お客様が書いた自由記述を全文転載する運用は慎重に検討します。誤入力や機密情報が含まれていた場合、メール経由で情報が拡散するからです。受付番号や問い合わせ日時、返信の目安、代替の連絡先など、必要な情報だけを案内する設計も可能です。障害の復旧試験では、こうした文面の変更を同時に行うと原因が追いにくくなります。まず送信経路を復旧し、その後で文面・運用改善を別の変更として実施します。返信目安を変更する場合は、実際の受付体制と一致させてください。

PHP互換性の問題を疑う証拠を集める

PHP更新後に500エラー、管理画面の致命的エラー、フォームのAjax応答でサーバーエラーが出るなら、テーマやプラグインのPHP互換性を調べます。WordPressの「サイトヘルス」の情報タブではPHPバージョンなど環境情報を確認できます。ホスティング事業者のエラーログやWordPressのデバッグログで、実際にエラーを出したファイル、行、発生時刻を照合します。WordPress公式のデバッグ手順はログ出力方法を説明していますが、原則としてローカルやステージングで調査します。本番で画面にエラーを表示するとパス等が漏れるので、WP_DEBUG_DISPLAYを有効にしたまま公開しないでください。

エラーを見つけたら、直近で更新した拡張機能のバージョン、開発元の対応情報、再現する操作をセットで記録します。PHPの新しい版で非推奨警告が出ても、それだけでフォーム送信失敗の原因とは限りません。逆にFatal errorがフォーム送信時だけ発生していれば、関係が強くなります。重要なのは「時刻」「実行した操作」「発生したログ」「停止した機能」の四つを結び付けることです。プラグインを更新すると改善する可能性はありますが、同時に別の変更が入るため、バックアップと検証環境を用意してから一つずつ進めます。

競合確認は安全な範囲で、一つずつ行う

プラグインやテーマの競合が疑わしい場合は、可能ならステージング環境で再現し、フォーム、メール送信、キャッシュ、セキュリティ、カスタムコードの順に影響を切り分けます。WordPress公式のトラブルシューティングモードは、管理者のセッションでプラグインを一時停止して確認する方法を説明しています。ただし、管理者だけの表示で成功しても、実際の訪問者に同じ挙動が出るとは限りません。検証の最後は公開フォームで行います。テーマ切替も表示や計測を変えるため、本番へいきなり適用しないでください。

フォーム停止が重大でも、全部のプラグインを本番で一度に無効化すると決済、会員認証、計測、セキュリティまで止まる恐れがあります。変更は一つずつ、変更前の状態・実施時刻・試験結果を記録します。例えば「キャッシュプラグインのフォームページだけ除外」「送信プラグインの認証を再接続」「フォームプラグインを公式の互換版へ更新」のように対象を限定します。改善しなかった変更は元に戻し、次の仮説へ進みます。これにより、何が効いたか分からない「偶然直った」状態を避けられます。

メール配送と受信設定を直す：SMTP・認証・迷惑メール

結論：「フォーム送信は成功」「テストメールも成功」でも、受信までは別です。送信サービスの認証・配送ログ、DNS、受信側の隔離を順番に見ます。設定を変える前に現在の送信経路を確定してください。

送信経路を一枚の図にする

担当者がまず確認するのは、WordPressのフォームがどの仕組みでメールを出しているかです。Contact Form 7はWordPressのwp_mail()を呼びます。そこからサーバー標準のメール送信へ進む構成もあれば、WP Mail SMTPなどがSMTPサーバーやメールAPIへ接続する構成もあります。複数のプラグインを使っていると、実際の送信経路が設定画面の想像と違うことがあります。サイトの担当者、サーバー事業者、メールサービス管理者が同じ図を見られるよう、「フォーム名→送信プラグイン→サービス名→送信ドメイン→受信先」を書き出してください。

この図には、認証情報そのものを記載しません。接続先や設定を確認するときも、APIキーやSMTPパスワードをチャットや公開チケットに貼らないでください。管理者が引き継ぎできるよう、認証情報の保管場所と管理権限だけを記録します。メール経路が分からないと、PHP更新後に「mail()が使えなくなった」と推測して送信プラグインを追加し、二重設定を作る危険があります。先に送信元を特定し、検証用メールのエラーがその経路のどこで出たかを探します。

SMTP接続失敗と認証失敗を混同しない

SMTP接続のタイムアウトや拒否は、ホスト名、ポート、暗号化方式、外向き通信の制限、サーバー側の許可リストなどを確認します。認証失敗なら、利用しているメールアカウントの状態、アプリパスワードやOAuthの期限、サービス側の認証方式変更を確認します。WP Mail SMTPの接続エラーの公式手順は、接続エラーと認証設定の点検、テストメールでの再試験を案内しています。エラーメッセージに秘密情報が含まれることがあるため、スクリーンショットやログを事業者へ送る際は伏せます。

送信サービスに接続できても、差出人アドレスが認証済みドメインと合わない場合は拒否されることがあります。ホスティングのメールサーバーから外部サービスへ移した後に、フォームの「送信元」だけ古いまま残るケースもあります。設定変更はメールサービスの管理者と合意し、WordPress側、DNS側、送信サービス側の三か所を同時に確認します。送信後はテストメールだけでなく、実フォームの管理者宛と自動返信を試します。送信元を変えると迷惑メール判定や返信先の挙動も変わるため、担当者のメールクライアントでの見え方まで確認します。

メールサービスのログを読むときの順序

送信サービスの画面に「受け付け」「一時失敗」「恒久失敗」「配送」「抑制」などの状態がある場合は、用語をそのサービスの公式説明で確認して読みます。一般に、送信要求をサービスが受け付けたことと、相手の受信箱に表示されたことは別の出来事です。まず検証IDを含むメールがサービスに渡ったか、次にサービスから相手側へ渡ったか、最後に受信側で隔離されていないかを調べます。もし送信サービス側に検証IDが全くないなら、WordPressからそのサービスへ届く前の段階を優先します。

ログには送信先や件名が記録されるため、社外サポートへ転送する前に個人情報を隠します。エラーコードが出ていればコードと時刻だけでも調査が進みますが、「認証失敗」と「接続できない」は対処が異なります。接続できないときにパスワードを変えても解決しませんし、認証失敗なのにWAFを止めても効果は期待できません。サービスが一時失敗から再試行している場合は、即座に同じ問い合わせを手動で再送すると重複到達する可能性があります。自動再試行の有無と最終状態を確認してから再送してください。

SPF・DKIM・DMARCは既存の正規送信元を数えてから触る

メール認証は技術担当者だけの問題ではありません。フォーム通知のほか、注文メール、予約通知、メールマガジン、MAツールなどが同じドメインで送っていれば、DNSの変更はそれらにも影響します。まず「どのサービスが、どの差出人ドメインで送っているか」を一覧化し、各サービスの公式指示に従ってSPF・DKIMを照合します。DMARCのポリシーを強めるのは、正規の送信元が認証に通ると分かってからです。WP Mail SMTPのテストメール資料は、SPF・DKIM・DMARCなどの警告を確認する方法を示しています。

例えば新しいメールAPIへ切り替えた直後に、管理者宛の社内ドメインでは届くが、顧客向けのフリーメール宛には届かない場合、配送ログと認証結果を比較します。これだけでPHPの不具合とは言えません。受信側の隔離や迷惑メールにも同じ検証IDを使い、見つかった場所を記録してください。迷惑メールから「許可」にするだけでは、送信ドメインの認証不備を根本解決できない場合があります。受信側の暫定ルールと送信側の恒久対応を分けて管理します。

問い合わせを逃した可能性を調べる

障害が解消しても「今日のテストが届いた」で終わらせません。障害開始時刻から復旧時刻までに、フォーム送信が何件あったかを確認します。フォーム側に保存機能や外部連携がある場合は、該当期間の受付記録とメール受信記録を突き合わせます。保存機能がない場合、アクセスログや送信サービスのログから件数を推定できるかを管理者へ確認します。ただし、アクセスログの一行をそのまま一件の問い合わせと数えないでください。再送やスパム、確認画面だけのアクセスが混ざります。確定件数と推定件数を分け、漏れが疑われる顧客への連絡は個人情報保護の方針に従います。

フォームの送信が失敗していた期間は、顧客の入力内容が保存されていない可能性があります。ログに顧客のメールアドレスや本文が残っている場合でも、復旧目的に必要な担当者だけがアクセスし、保管期限を決めます。運用上、通知メールだけに頼っていたなら、今後は適切なアクセス制御を備えた受付履歴やCRM連携を検討します。ただし、個人情報を保存する仕組みを増やすことには漏えいリスクもあります。保存先、権限、保存期間、削除手順を決めたうえで導入してください。

ログがない場合に「漏れなし」と言わない

フォームに送信履歴がなく、メールサービスにも過去ログが残っていない場合、過去の送信数を正確に復元できないことがあります。このとき「ログがないので問い合わせはありませんでした」と報告してはいけません。分かることは、最後に受信を確認できた日時、最初に障害を確認した日時、その間のアクセス状況、再送依頼や電話問い合わせの件数などに限られます。数字を示す際は「確認できた件数」と「推計」を分けてください。原因と影響範囲が未確定なら、その旨を社内に明記し、顧客向けに案内するかどうかをサイト責任者と法務・個人情報担当が判断します。

再発防止として、問い合わせの受付時に一意の番号を発行し、権限管理された場所へ最低限の状態を残す仕組みを検討できます。これは単にメールを二か所へ送ることとは違います。メール二通とも同じ経路で止まる可能性があるからです。保存する情報は、受付日時、受付番号、処理状態など業務に必要な範囲に絞り、本文や添付の保存は目的と保管期間を決めます。通知メールが届かない場合でも受付記録を確認できる運用が、次の障害時の顧客対応を助けます。

復旧の進め方：安全に変更し、公開フォームで検収する

結論：変更は「担当者・対象・戻し方・完了条件」を決めて一つずつ実施します。PHPの修正版維持を原則とし、フォームやメール経路を直した後に公開ページで再試験します。緊急対応と恒久対応を混ぜないことが復旧を早めます。

15分で始める初動、当日中の復旧、翌営業日の振り返り

最初の15分は、受付停止の範囲と代替窓口の案内を優先します。担当者は、サイト責任者、WordPress保守担当、メール管理者を最低限決め、検証ID付きのテストを一度行います。得られる成果物は、障害開始時刻、症状、対象フォーム、利用者への暫定案内、担当者一覧です。当日中は、切り分け表を使い、送信経路のログと設定を照合し、原因に対応した最小の変更を加えます。完了条件は「管理者宛、自動返信、受付記録が公開フォームから再現性をもって確認できること」です。翌営業日は、取りこぼし確認、設定の文書化、監視の設定、同様の変更を行うときの試験手順を残します。

緊急度はサイトで違います。たとえば予約や見積依頼が売上に直結するサイトなら、代替窓口を先に出し、受付再開を最優先にします。採用応募フォームなら応募者の個人情報が入るため、安易なメール転送を避け、採用担当と保護方針を確認します。会員サイトのパスワード再設定メールまで止まっているなら、フォームだけでなくサイト全体のメール経路が障害範囲です。担当者の判断で一つのフォームだけ直したつもりにならず、サービスの重要メールを一覧にして影響を評価します。

架空の3ケースで復旧判断を具体化する

ケースA：企業サイトの見積フォーム。PHPの更新から二時間後、Contact Form 7が緑枠になるのに管理者メールが届かないと判明したとします。Web担当は公開ページに既存の電話窓口を案内し、テストIDを付けた送信を行います。WP Mail SMTPのテストメールは受信できるため、フォーム固有の送信先と差出人を照合し、誤った宛先設定を一か所修正します。受付担当が管理者宛と自動返信を確認し、過去二時間の受付履歴を確認できたら案内を戻します。この例では、PHP更新と不具合が同時でも、設定ミスが実際の原因です。

ケースB：採用応募フォーム。送信ボタンを押すと赤枠になり、メールテストも同じ認証エラーを出すとします。保守担当はメールサービスの認証トークンが失効していたことをログで確認し、管理者権限で再接続します。応募者に入力内容を個人メールへ再送させる前に、受付停止のお知らせと代替の公式窓口を用意します。再接続後は、ダミーの応募データで通知・自動返信・添付の到達を確認します。障害期間の応募が残っていない可能性は「ゼロ件」と扱わず、採用担当と影響範囲を確認します。

ケースC：会員サイトの資料請求。フォーム画面が500エラーになり、会員登録の通知も遅れたとします。サーバーログから古いカスタムプラグインでPHPの致命的エラーが出たことを保守担当が確認します。ステージングで修正版プラグインの動作を試し、会員登録・資料請求・パスワード再設定の三つを検収します。緊急時には一時的に受付を停止し、顧客へ状況を明示します。この例ではPHPの互換性が問題でも、対処は「すべてのサイトを旧PHPへ戻す」ことではなく、問題の拡張機能を修正・更新することです。三例は手順を示す架空のケースであり、実在の障害実績ではありません。

変更前にバックアップと戻し方を決める

設定変更前に、WordPressのデータベースとファイル、フォーム設定、メール送信プラグインの構成、DNSレコードを記録します。バックアップが「存在する」だけでなく、復元先・必要時間・担当者・直近の復元試験日を確認してください。フォームの設定だけを直す場合も、更新画面のスクリーンショットを残せば、差分を戻しやすくなります。DNSを変える場合は既存の正規送信元に影響するため、メール管理者の承認と切戻し手順を用意します。PHP版を切り替える場合はサーバー事業者の手順と、他のWordPressや同居システムへの影響を確認します。

一つの変更後に、必ず同じ検証IDの形式で試験を行います。改善したら変更内容と確認結果を残し、改善しなければ変更を戻します。メールが一度届いたことだけでは再発の可能性が残るため、異なる受信先や時間帯でも必要に応じて試します。ただし、大量のテスト送信は送信制限や迷惑メール判定を招くため、事業者の制限内で少数に絞ります。復旧記録には「変更後もPHP修正版を使用しているか」を含め、緊急対応で安全性を落としていないか確認します。

検収表：公開フォームでどこまで確認すればよいか

検収項目	実施者	合格条件	不合格時の戻し先
PCとスマホのフォーム表示	Web担当	項目・同意・ボタンが正常	テーマ・スクリプトの変更履歴
最小入力の送信	Web担当	完了表示と検証IDが一致	フォーム設定とブラウザー通信
管理者宛メール	受付担当	期待する受信箱に本文が到達	送信ログ・宛先・受信隔離
自動返信メール	Web担当	外部テスト用の受信箱へ到達	Mail (2)・送信元・認証
添付・長文・必須入力	業務担当	実運用の入力で破損・欠落なし	容量・形式・メール本文
他の通知メール	サイト責任者	会員・予約等の重要メールも正常	共通メール経路
PHPとエラーログ	保守担当	修正版維持、同じエラーが再発しない	拡張機能・サーバー設定

チェック表の担当は自社の体制に合わせて変更してください。重要なのは「画面に成功と出た」だけで完了にしないことです。メール本文にテスト用の氏名・件名が正確に入るか、添付が開けるか、自動返信の差出人と返信先が適切かを確認します。問い合わせ内容がメール以外の受付履歴へも保存される場合は、同じ検証IDで照合します。検収後は代替窓口の案内を撤去する前に、窓口担当へ復旧を伝え、切替時刻を記録します。

復旧を急ぐときほど変更の承認と停止基準を決める

障害対応の現場では「試せる設定を片っ端から変更する」ことが起きがちです。しかし、SMTPの認証を入れ直し、フォームの差出人を変え、DNSも変更し、PHPも戻すと、どの操作が効いたのか判断できません。事前に、サイト責任者は顧客案内と公開可否、保守担当はWordPressとPHP、メール管理者は送信サービスとDNSを担当すると決めます。変更ごとに実施者、承認者、期待する結果、戻し方、検収者を一行で記録します。小さな変更でも、公開フォームが顧客に使われている時間帯には影響を確認してから適用します。

停止基準も具体的にします。たとえば「変更後に会員ログインができない」「メール送信が改善しても決済通知が止まる」「PHP修正版を外さないと動かない」なら、そこで追加変更を止め、サイト責任者と事業者へ相談します。最優先は問い合わせの代替窓口を確保し、安全性を保ちながら原因を特定することです。応急処置でフォーム表示だけ戻っても、受信漏れや脆弱なPHPが残るなら恒久復旧ではありません。最終的な完了記録には、公開フォームの検収結果、安全なPHP版、取りこぼしの調査結果、残った課題と担当者を含めます。

WordPressとサーバー会社へ相談するときの連絡文

事業者へは「メールが届きません」だけでなく、切り分け結果を渡します。次のテンプレートを自社の状況に合わせて埋めてください。認証情報、フォームに入力された顧客情報、非公開のAPIキーは送らないでください。ログを添える場合も必要な行だけを抜き出し、秘密情報と個人情報を伏せます。

件名：WordPressフォームの送信／受信障害の調査依頼

サイトURL：［公開URL］
障害を確認した日時：［日時とタイムゾーン］
PHP更新日時・前後の版：［確認できた範囲］
WordPress・フォーム・メール送信プラグインの版：［版］
症状：［ボタン無反応／赤枠／オレンジ枠／緑枠だが未着／500等］
対象フォーム：［ページURL］
テスト検証ID・時刻：［IDと日時］
管理者宛・自動返信の結果：［結果］
メールテストの結果：［成功／失敗とエラーの要約］
既に確認した受信側：［迷惑メール・隔離・転送等］
変更した設定と戻し方：［変更履歴］
確認してほしい事項：［送信ログ、PHPエラーログ、SMTP/API通信、WAF遮断、修正版への対応等］

この情報があれば、事業者は時刻や検証IDでログを探しやすくなります。返答に「送信成功」とだけ書かれていたら、それがWordPressの送信処理なのか、メールサービスへの受け渡しなのか、受信側への配送なのかを確認してください。証拠が止まった場所を共有することが、復旧と取りこぼし確認の両方に役立ちます。依頼後も代替窓口を維持し、担当者が顧客対応を続けます。

よくある質問と再発防止

結論：復旧後は、フォームの定期テストと受信経路の見える化を運用に入れます。PHPやプラグインの更新時だけでなく、DNSやメールサービスの変更時にも同じチェックを使えば、障害を早期に見つけられます。

次の更新前に作る「フォーム一覧」と試験の順番

お問い合わせフォームが一つとは限りません。資料請求、採用応募、イベント申込、会員登録、パスワード再設定、注文確認など、同じWordPressからメールを送る機能を一覧にします。各行に、公開URL、担当部署、フォーム・通知の種類、管理者宛の受信先、自動返信の有無、送信サービス、保存先、機会損失の大きさを記録します。HTMLやブロックのフォームを見落とさないよう、サイトマップやメニュー、CTAからも探します。利用者が操作する画面と裏側のメール経路を対応付ければ、次のPHP更新時に「トップページが表示されるから問題ない」で終わらせずに済みます。

更新前のテスト順は、重要度と失敗したときの影響で決めます。売上や応募につながるフォームを最初に、確認メールやパスワード再設定のような継続利用に必要なメールも必ず含めます。ステージング環境があっても、そこでは本番とメールサービス・DNS・外向き通信が違う場合があります。ステージングで互換性を確認し、本番で少数の検証ID付きテストを行う二段階にしてください。テスト用アドレスや架空情報を使い、顧客に通知が届かない設計にすることも重要です。更新前に管理者宛と自動返信の正常な到達時刻を記録しておくと、更新後の比較ができます。

更新当日の担当者は、サイト変更担当、受信確認担当、判断・承認担当を分けます。一人で全ての画面を操作していると、受信側の異常を見落としがちです。更新後の試験に失敗したら、事前に決めた受付停止・代替窓口の案内へ移ります。正常な場合は、更新前後のPHP版、プラグイン版、テストID、受信結果を一枚の記録に残します。毎回同じ形式を使えば、「前回もメールは遅れていたのか」といった比較が可能になります。更新作業を完了と判断するのは、表示、操作、配送、業務上の受信まで確認した後です。

Q. PHPを更新した直後に止まったなら、PHPを戻すべきですか？

すぐには戻しません。まずフォーム状態、送信プラグインのテスト、PHPエラーログ、送信サービスのログを確認します。PHPのセキュリティ修正版を旧版へ戻すとリスクがあるため、互換性や設定の原因を特定し、可能なら修正版を維持したまま直します。サイト全体が停止するなど緊急度が高い場合でも、事業者と公開範囲・期間・暫定対策・再更新日を決めて判断します。「更新直後」という時間の一致は調査の手掛かりですが、それだけでは因果関係を示しません。

Q. Contact Form 7で緑色の完了表示が出ています。復旧済みですか？

まだです。緑色は送信処理が成功した状態であり、受付担当の受信箱へ届いた保証ではありません。管理者宛と自動返信を実際に受け取り、迷惑メールや隔離も確認してください。添付や長文が業務上必要なら、その条件も試します。緑枠で未着の場合、フォームの宛先、受信側のフィルター、配送ログ、SPF・DKIM・DMARCなどを確認します。受付履歴が別にあるなら、同じ検証IDが残るかも照合します。

Q. 赤枠とオレンジ枠の違いは何ですか？

Contact Form 7の公式FAQでは、赤枠はwp_mail()によるメール送信の失敗、オレンジ枠はスパム判定を示します。同じようなエラー文でも対処は異なります。オレンジ枠ならAkismet、CAPTCHA、その他のスパム対策の判定や通信を確認し、赤枠ならメール設定と送信経路を調べます。色や画面表示がテーマで変わっているサイトでは、フォームの状態やログを追加で確認します。色だけで設定を断定しないことも重要です。

Q. WP Mail SMTPのテストメールは届きますが、フォームだけ届きません。

メールサービスの共通経路が動いている可能性は高まりますが、フォーム側の設定や個別の送信条件は残ります。Contact Form 7の送信先、送信元、追加ヘッダー、添付、Mail (2)、設定検証の警告を確認します。実フォームだけで使う差出人や宛先が、テストメールと違うかもしれません。受信先を一時的に検証用の社内アドレスへ変える場合も、変更前の設定を保存し、個人情報の転送先を増やさないようにします。原因が分かったら本番の宛先へ戻して再試験します。

Q. フォームも管理画面も500エラーです。何を渡して相談しますか？

サイトURL、障害時刻、PHPの前後の版、直近のWordPress・プラグイン・テーマ更新、サーバーエラーログの該当行をサーバー会社と保守担当に伝えます。顧客情報や認証情報が含まれるログをそのまま公開しないでください。WordPressのリカバリーモードやホスティングのバックアップから復旧できるかも確認します。PHP版を戻す判断は、脆弱性修正版を外すリスクも含めて合意します。WordPress公式は管理画面へ入れないときのプラグイン切り分けも説明しています。

Q. 毎回手作業で送信を確認するしかありませんか？

定期点検を仕組みにできます。更新前のステージング試験、更新後の公開フォームの少数テスト、メールサービスの障害通知、受付件数の異常検知、受信箱の運用確認を組み合わせます。自動監視を導入する場合は、フォームに不要な個人情報を送らないこと、監視用メールが迷惑メールを増やさないこと、送信上限を超えないことを設計してください。監視だけで「顧客のメールが必ず届く」とは言えないため、受付担当が問い合わせ件数と実際の業務を定期的に照合します。更新手順には、管理者宛と自動返信の両方の検収を必ず入れます。

Q. SMTPプラグインを追加すれば必ず直りますか？

必ずしも直りません。メールテストも実フォームも失敗し、原因が現在の送信経路にあると分かったときには、認証されたSMTPやメールAPIの導入が選択肢になります。しかし、フォーム自体が読み込まれない、スパム判定でブロックされる、送信先が間違っている、受信側が隔離している場合は、プラグイン追加だけでは解決しません。既存の送信プラグインと機能が重複すると、二つの経路が競合する恐れもあります。導入前に、現在の送信方式と障害の位置を図にし、メールサービスの送信ドメイン認証、費用、送信上限、ログ保存期間、障害時の代替手段を比較してください。

新しい送信サービスを使う場合は、顧客情報がサービスへ渡るため、契約・プライバシー上の条件も確認します。運用担当者がトークン更新や障害通知を受け取れるかまで決めなければ、次の認証失効で同じ問題が起こります。導入の完了条件はテスト機能が一通成功することではなく、公開フォームの通知、自動返信、重要なサイトメールが期待どおり届き、旧経路の不要な設定が整理されていることです。

Q. オレンジ枠が出る場合、スパム対策を全部止めてもよいですか？

全部を本番で止める前に、どの判定が検証用送信を止めたか確認します。Contact Form 7はオレンジ枠をスパム判定の状態として説明していますが、reCAPTCHA、Akismet、追加のセキュリティプラグインなど候補があります。公式のreCAPTCHA FAQは、スクリプトの未読み込みや不具合が影響する場合も示します。ブラウザーの通信、スパム対策のログ、最近の設定変更を見て、対象を絞って調べてください。スパム対策を広く止めると迷惑送信が増える可能性があります。テスト環境や時間を限った調査とし、復旧後は保護が有効な状態で実フォームを検収します。

Q. フォームの送信記録が残っていない場合、顧客にはどう伝えますか？

まず受付停止の開始・終了時刻と、確定できた事実を社内で整理します。入力された内容が保存されていないなら、個別の利用者へ「あなたの送信は失敗した」とは断定できません。案内が必要な場合は、対象期間の利用者へ再送をお願いする文章をサイト責任者が確認し、代替の公式窓口を明示します。顧客の情報が漏れたという証拠がなければ、メール未着だけで漏えいと表現するのも不正確です。逆に、障害範囲がまだ不明なら「全ての問い合わせが正常に届いた」とも書けません。根拠、未確認の点、再送方法、問い合わせ先を分けて伝えることが重要です。

Q. 2026年のPHP脆弱性がこのメール障害を起こしたのですか？

この記事で扱う症状だけでは判断できません。PHP公式が公開したのはセキュリティ修正の必要性であり、「フォームメールが停止する」という一般的な症状を示すものではありません。更新に伴う互換性や設定変更が影響する可能性はありますが、実際のエラーログと変更履歴で証明する必要があります。セキュリティ対応とメール障害の診断を混同すると、修正版の適用をためらったり、無関係な設定を変更したりします。まず安全な版を維持し、障害箇所を切り分けるのが実務的です。

まとめ：問い合わせが届くことまで確認して完了にする

WordPressのフォーム復旧は、画面の成功表示だけでは終わりません。送信経路、受信箱、管理者通知、自動返信、受付履歴、他の重要メールを、同じ検証IDで確認して初めて業務として復旧します。PHP更新後に問題が出ても、脆弱性や修正版が直接の原因と決めつけず、変更履歴とログで調べてください。代替窓口を先に案内し、最小の変更を一つずつ検証すれば、問い合わせ機会損失と安全性の低下を抑えられます。次回のPHPやメール設定の変更に備え、この記事の検収表と事業者への連絡文を社内手順へ取り込んでください。

特に社内で引き継ぐときは、障害原因だけでなく「どの証拠で原因と判断したか」を残します。フォームの設定画面、テスト送信ID、送信サービスの結果、受信側の結果、変更した箇所、切戻し方法、最後に確認した日時があれば、次の担当者も同じ障害を短時間で調べられます。資料に顧客情報や秘密情報を入れず、権限のある担当者だけが見られる場所で管理してください。復旧後一週間ほどは受付件数とメール配送の傾向を確認し、再発がないかを見ます。件数の変動だけで障害を断定せず、フォームのテストと実際の問い合わせ業務を合わせて判断します。

受付担当が交代する場合も、代替窓口と未解決の問い合わせを引き継ぎます。技術的な復旧と顧客対応の完了は別です。

AIスキルで、未来の自分をアップデート！

今なら完全無料でAIを学べる！

フォームの確認項目、問い合わせ対応の記録、関係者への連絡文の整理には、AIの活用が役立ちます。ただし、顧客情報や認証情報をそのまま入力せず、最終判断と公開内容は担当者が確認してください。学び直しを始めたい方は、WithAIの無料学習案内を確認してください。

参考・出典（2026年10月23日確認）：PHP公式セキュリティリリース、WordPress日本語公式の告知、WordPress公式サイトヘルス、WordPress公式デバッグ手順、Contact Form 7公式FAQ、Contact Form 7公式メール設定、WP Mail SMTP公式トラブルシューティング。