PHP更新を依頼する予定で、「作業後にどこまで確かめてもらえばよいか」が分からないサイト管理者の方へ。トップページの表示に加えて、止まると困る機能の操作と、その結果まで確認範囲に入るかを相談しましょう。先に正常な状態を記録しておくと、更新前後を同じ条件で比べられます。
■ 「開けた」の先に、仕事のゴールがある
問い合わせフォームなら、入力欄が見えること、送信操作を進められること、決めた宛先で内容を受け取れることは、それぞれ別の確認です。完了画面が表示されただけで、担当者への通知まで届いたとは判断できません。
PHP公式の移行ガイドは、例えば8.3から8.4への移行について、本番環境の切替前に互換性をテストするよう案内しています。WordPress公式も、テーマやプラグインが新しいPHPで動くかは確認が必要と説明しています。特定のページを一度開くだけでは、使っていない処理まで確認できないためです。
説明用の図・架空の問い合わせフォーム例です。実サイトの診断や送信テストの結果ではありません。
■ 図の①②③を、依頼する範囲に置き換える
①表示では、入力欄や説明文を確認します。②操作では、必須項目の未入力時に案内が出るか、許可されたテスト内容で完了画面まで進めるかを確認します。③結果では、テスト用の受信先で内容を確認するなど、目的を達成した状態を見ます。
この3段階を分けると、「フォームは確認済み」という報告が、画面を開いただけなのか、通知まで確かめたのかを揃えやすくなります。図はその整理例であり、すべてのサイトでフォーム送信が必要という意味ではありません。
検索機能なら「決めた語で検索し、想定する結果が出る」、会員向けページなら「許可されたテスト用アカウントで、必要なページを開ける」など、サイトの役割に合わせて選びます。掲載情報を読むだけのサイトなら、画面・リンク中心の確認が合うこともあります。
■ テストで本物の通知や注文を増やさない
問い合わせの送信はメールを発生させ、予約や購入の操作は受付・決済につながる場合があります。検証環境、テスト用の宛先、操作してよい内容を担当者と先に決めましょう。本番へ無断で送信したり、実際の予約・注文を作ったりする確認は避けます。
検証環境だけで確認した項目と、本番で許可を得て確認した項目も分けます。環境が違えば設定も同じとは限らないので、「検証環境で成功」をそのまま「本番も確認済み」にしないことが大切です。
■ 更新前に、比べる基準と戻す準備をそろえる
現在と更新先のPHP、CMS・テーマ・プラグインの構成を整理し、互換性を調べる範囲を決めます。重要な画面・機能は、更新前の正常な動きも記録しておきます。もともとあった不具合と、更新後の変化を混同しないためです。
WordPressを使う場合、通常のサイトの復元にはファイルとデータベースの両方が必要です。バックアップの対象と日時、復元手順、PHP設定を戻す条件、判断する担当者まで、作業前に確認しておきましょう。
既存の保守担当者と確認項目が決まっているなら、その一覧を使えます。新たな有料支援が必ず必要なわけではありません。項目や担当が曖昧な場合は、まず「どこまで見積りに含めたいか」を整理します。
■ そのまま使える確認メモ
・止まると困る画面/機能:____
・正常な動き(更新前の記録):____
・表示/操作/結果のどこまで確認するか:____
・検証環境と本番で確認する範囲:____
・許可するテスト操作/通知・決済の扱い:____
・確認担当/実施日時/結果:____
・未確認の項目と、次に確認する担当:____
「未確認」は「問題なし」と分けて残してください。限られた動作確認は、すべての機能や安全性の保証にはなりません。また、PHPのサポート終了と、特定サイトに特定の脆弱性が存在することは別です。
PHP更新を相談する際は、このメモを添え、確認してほしい機能と対応範囲を見積り前にすり合わせましょう。パスワードや顧客データをメモへ記載する必要はありません。
■ 確認した公式情報
確認日:2026年11月4日(日本時間)
PHP公式「Migrating from PHP 8.3.x to PHP 8.4.x」
WordPress公式「Get a faster, more secure website: update PHP today」
WordPress公式「Backups」