CPIでPHPが更新できない？WordPress脆弱性の確認・旧プラン移行

CPIのレンタルサーバーでWordPressを運用し、PHPが古い、または新しい修正版を選べない場合は、WordPress本体だけを更新しても2026年10月のPHP本体の脆弱性対策にはなりません。まず契約プラン・Webサーバー名・WordPressが実際に使うPHPを特定し、CPIに今回のCVE-2026-109618／CVE-2026-109619への修正適用状況を確認します。修正版へ切り替えられるならバックアップと互換性検証をして変更します。選べない、または適用状況が確認できないなら、公開継続のリスクを判断し、プラン変更や移転の工程を組みます。

本記事は「CPIなら全部古い」「PHP 8.0と表示されたら必ず未対策」とは言いません。CPI公式は利用可能なPHPは契約プラン・Webサーバーの種類で異なると説明しています。PHPプロジェクトの修正版番号より古く見える場合でも、ホスティング事業者が修正をバックポートした可能性があり、利用者が見た番号だけで適用有無を断定できません。その一方で、回答のないまま「事業者がきっと直している」と推測して運用を続けるのも危険です。この記事では確認の根拠と、更新できないときの実務的な選択肢を分けて整理します。

対象はCPIの共用レンタルサーバーやマネージド環境でWordPressを運用する担当者です。2026年10月23日時点のPHP公式勧告、WordPress.orgの注意喚起、CPIのプラン別PHP確認案内を基にしています。料金、選べる版、サーバー側パッチの状況は変わるため、操作直前には公式情報を再確認してください。紹介する手順は一般的な判断の枠組みであり、個別契約の安全性を保証するものではありません。

CPIのPHPが古いとき、最初に判断すること

答えは「CPIの契約が今回の脆弱性の影響を受け、すでに修正されたか」を確認することです。PHP公式は、未認証の遠隔コード実行につながり得る2件を修正した版として、PHP 8.2.35、8.3.36、8.4.27、8.5.12を示しています。対象はWebリクエストを処理するPHP環境で、WordPressだけの問題ではありません。PHP 8.1以前はPHPプロジェクトから更新が出ない系列です。ただし、ディストリビューションやLTS事業者のバックポートがあり得るため、古い番号だけから「未修正」とは断定しません。

WordPress.orgも、この件の修正対象はPHPであり、この問題のためだけのWordPress本体更新は予定していないと案内しています。WordPress、テーマ、プラグインの通常の更新は必要ですが、それとPHP本体の更新は別の作業です。たとえばWordPressの管理画面で「すべて最新」と表示されても、実行PHPが安全と証明されたことにはなりません。反対にPHPを修正済み版へ変更しても、古いプラグインの別の脆弱性まで消えるわけではありません。両者を一つのチェック欄で「対策済み」にしないことが、最初の誤判断を防ぎます。

最初の10分で確認する5項目

1. 対象URLと契約をつなぐ。公開ドメイン、CPIの契約番号・プラン名、Webサーバー名を確認します。会社に複数契約があると、管理画面で見ているサーバーと公開WordPressが異なることがあります。サーバー名や契約番号は社内台帳に記録し、公開記事やスクリーンショットに不要に載せません。
2. 実行中のPHPを見る。WordPressの「ツール→サイトヘルス→情報→サーバー」にあるPHPバージョンを確認します。複数サイト・サブドメイン・検証環境は別々に確認します。CLIのphp -vはコマンドライン用で、公開Webリクエストの実行版と異なる場合があります。
3. 選択可能なPHPを調べる。CPIのFAQに従い、契約プランの操作マニュアルと、現在のコントロールパネルの表示を照合します。一般の検索結果に出る「CPIで使えるPHP8.4」という説明を、自分の旧契約にそのまま当てはめません。
4. 事業者の今回の対応状況を確認する。PHPのCVE-2026-109618／109619を明記した告知またはサポート回答が、対象契約・Webサーバー・PHP系列に適用されるかを確認します。別プランの更新情報や過去のPHPアップデート告知だけでは今回の修正適用を証明できません。
5. 運用判断と次の時刻を残す。修正済みが確認できた／未確認／未適用のどれか、担当者、情報源URL、確認日時、次回確認時刻を記録します。判断保留のままなら、公開継続を決める責任者も明確にします。

簡単な台帳を作るなら、列は「サイトURL」「契約プラン」「Webサーバー名」「WordPress側PHP」「選択候補」「CVEへの修正適用状況」「根拠URL」「確認日時」「担当」「次の行動」で十分です。1行に1サイトを入れます。複数サイトが同じ契約でも、.htaccessの設定や設置先ディレクトリが異なれば実行版が違う可能性があるため、各サイトの実測値を残してください。台帳にパスワード、認証コード、FTP接続情報は書きません。

古い番号を見たときの3つの判断

確認できた状態	まず行うこと	その理由
当該契約・PHPに対する事業者の修正適用が確認できた	回答と日時を保存し、サイトの異常・ログを確認。サポート終了系列からの移行計画は別途立てる。	今回の緊急パッチと長期保守は同じではないため。
修正済み版を選べるが、まだ旧版で動作	バックアップ、互換性確認、切替と動作検証を実施。	選択肢があるだけでは実行中のPHPは変わらないため。
修正済み版が選べず、事業者の適用も不明	サポートへ照会。公開継続のリスクを判断し、移行または一時的なアクセス制限を計画。	「選べない＝未修正」も「見えない＝適用済み」も証明できないため。

WordPressサイトヘルスで「PHP 8.0」のように系列だけが見える場合、パッチ番号を確かめずに修正済みと判断できません。一方、CPIが独自に修正を提供する場合は、PHP公式の番号と一致しなくても脆弱性対策が入る可能性があります。問い合わせでは「PHP8.0に対応していますか」ではなく、今回の2件のCVEが、この契約サーバーの現在の実行PHPで修正済みかと聞きます。これにより一般的なPHP提供有無と今回のセキュリティ対応を混同しません。

「サイトが普通に開くから大丈夫」も根拠になりません。脆弱性への対策状況はトップページの表示だけでは分かりません。反対に、サーバー会社のコントロールパネルが一時的に開かないことも、公開サイトが侵害された証拠とは限りません。管理画面障害、契約権限、ブラウザー側の問題を切り分け、公式の障害情報と照らします。無理に設定操作を繰り返すより、現在値と時刻を控え、サポートから情報を得るほうが安全です。

この記事を使う前の前提と境界

本記事は共用レンタルサーバーを中心に書いています。専用サーバー、マネージドプラン、VPSに相当する環境では、OS、PHPパッケージ、PHP-FPMやApacheの更新責任が異なります。「CPIが提供しているから全て自動更新」とも、「利用者が常にrootで更新できる」とも言えません。契約書またはサポート回答で責任分界を確認します。サーバーの種類に自信がないときは、契約名、Webサーバー名、コントロールパネル名を添えて問い合わせます。公開中のWordPressのURLだけからプランは確定できません。

侵害の痕跡がある場合は、単純なPHP切替作業より証拠保全と被害拡大防止を優先します。知らない管理者アカウント、見覚えのないPHPファイル、改ざんされたページ、異常な外部通信があれば、ログやファイルの時刻を残して専門家と事業者へ連絡してください。脆弱性が存在する可能性と、実際に侵害されたことは別です。後者を示す証拠がない限り「感染した」と断定せず、前者を否定する根拠がない限り「完全に安全」とも断定しない姿勢が重要です。初動の詳細はWordPress侵害の疑いがあるときの初動対応で扱っています。

契約プランと選択可能なPHPを確認する

CPIで使えるPHPは、会社名だけでは決まりません。CPI公式FAQは、契約プランごとに違うため利用中プランの操作マニュアルを見るよう案内しています。たとえば共用サーバー向けPHPマニュアルには、ビジネス スタンダードとSV-BasicでもWebサーバー名別の利用可能系列が示されています。別ページのマネージドプラン向けPHPマニュアルは、さらに異なる表を持ちます。検索結果の一部を切り取って「CPIは8.3が選べる／選べない」と一括りにしないでください。

確認の順番は「契約名→Webサーバー名→設置先→実行版」

まず請求書や契約画面で、プランを特定します。同じ「共用」でも契約時期や移行履歴で管理画面が異なる場合があります。次にCPIのコントロールパネルに表示されるWebサーバー名を確認します。公式表はWebサーバー名で対象を分けているため、この文字列がないと誤った行を読む可能性があります。契約を扱うユーザーポータルと、Webサイトの設定を扱うコントロールパネルは役割が異なります。ログインできる画面が一つだけでも、PHP設定へ辿り着けるとは限りません。

そのあと公開WordPressの設置先を確認します。サイトがCPIに載っているつもりでも、DNSの切替や旧サイトの残置により別サーバーで動いている可能性があります。公開ドメイン、コントロールパネルの対象ドメイン、WordPress管理画面のURL、サーバー内の設置ディレクトリを照合します。DNSだけを見てサーバーが同じと判断しないでください。CDNやリバースプロキシがあると、公開側のIPと実際のPHP実行サーバーは直接一致しないことがあります。

最後にWordPressのサイトヘルスでPHPの実行版を見ます。CPIの操作マニュアルはプランや配置場所によって.htaccessでPHPを指定する方法も説明しています。そのため「契約上使えるPHP」と「このサイトが実際に使うPHP」は別です。CPIの共用サーバー向けマニュアルは、バージョンを指定しない場合の標準版についても説明しています。.htaccessに以前の指定が残っていれば、管理者が思っていた標準版とは異なるPHPでWordPressが動くことがあります。

.htaccessでPHPを指定している場合の注意

.htaccessはファイル一つの変更で下位ディレクトリの動作にも影響し得ます。CPI公式の対象プランのPHPマニュアルを開き、そこに書かれた記法だけを使います。インターネット上の別プラン向けAddHandlerをそのまま貼り付けません。編集前には元ファイルを手元に保存し、変更した行を記録し、元に戻す方法を決めます。ファイル名の先頭にドットがあるため、FTPソフトの表示設定によっては見えない場合があります。

「PHPバージョンを変更したい」だけなら、まず事業者のマニュアルに従った標準の変更手段を確認します。サーバー会社のUIが用意されている契約で、編集する必要のない設定ファイルを触るのは避けます。手動で編集する場合も、何を変更したか一行ずつ残し、公開画面・管理画面・フォームを検証します。PHP設定とセキュリティパッチ適用は同じではありません。AddHandlerで古い提供版から別の古い提供版へ変えても、今回の脆弱性が解消する保証はありません。

さらに、CPIの一部プラン向けマニュアルは、.htaccessでphp_valueやphp_flagを使えず、500エラーになると明記しています。PHP公式の緩和策に設定項目が載っていても、共用サーバーの利用者がそれを.htaccessへ書けば安全になるとは限りません。今回の問題はPHP内部の処理に関わるため、サーバー側の修正適用状況を必ず確認します。設定を一文字間違えたときの影響範囲も、事業者の注意書きと照合してください。

「8.3が選択肢にある」と「今回の修正が入った8.3」は違う

CPI公式の版一覧に「8.3系」と記載されていても、その説明ページの更新日が今回のPHPセキュリティ公開より前なら、今回のCVEが修正済みとは言えません。2026年10月21日のPHP公式修正版は8.3.36です。たとえば「8.3.26」という表示は、PHPプロジェクトの今回の修正版より古い番号です。ただし事業者が8.3.26相当の表記のまま修正を戻し入れた可能性は、番号だけでは排除できません。反対に、メニューに「8.3」としかない場合はパッチ番号すら不明です。契約サーバーへ修正が適用されたかを確認します。

公式の版表を読むときは、少なくとも「対象プラン」「対象Webサーバー名」「ページ更新日」「選択可能系列」「実行中の版」「今回のCVEへの対応」を別々の欄にしてください。一般的な機能追加の告知に「PHP 8.3を提供」とあっても、2026年10月の2件への対応とは別です。同じ公式サイトの情報でも、書かれた目的と時点が違います。安全判断に使う情報は、今回のCVE番号、対象環境、適用日時を含む告知または個別回答でなければ足りません。

実務用の確認表

確認欄	どこを見るか	完了の判断
契約プラン	契約・請求画面、CPIマイページ	WordPressが載る対象契約と一致
Webサーバー名	コントロールパネルのサーバー情報	公式マニュアルの該当行と照合
利用可能PHP	プラン別のCPI公式マニュアル	系列だけでなく、今回のパッチ情報も別途確認
実行中PHP	WordPressのサイトヘルス	対象サイトごとに表示値と時刻を記録
今回の修正	対象契約に適用されるCPIの告知・回答	CVE番号、適用範囲、日時が明確

この表の最初の四つが埋まっても、最後の「今回の修正」が空欄なら、セキュリティ判断は未完了です。WordPress本体が動いていること、プランの機能表に8.3が載っていること、バックアップがあることは、それぞれ意味がありますが、今回のCVEが修正済みであることとは別です。作業担当者が変わる場合は、空欄を「不明」と表示し、次の確認担当と期限を置きます。曖昧な「対応中」だけでは引き継ぎ後に誰も確認しなくなるためです。

複数ドメイン・検証環境があるときの数え方

一つのCPI契約に企業サイト、採用サイト、キャンペーンページが同居している場合、契約単位だけの確認では足りません。まずドメインとサブドメインを列挙し、WordPressが動くURLと静的HTMLだけのURLを分けます。次に、各WordPressがどのディレクトリへ配置され、どのPHP設定を継承するか確認します。親ディレクトリの設定が子ディレクトリへ影響する場合もあるため、各サイトのサイトヘルスを実測して照合します。管理画面に入れないサイトがあれば、担当者を決め、理由と次回確認時刻を台帳に残します。

検証環境は本番とは別に記録します。「検証サイトではPHP 8.3を使えた」という結果は、本番の設置場所や契約も同じと確認できなければ、本番の安全性の根拠にはなりません。逆に、検証環境にだけ古いPHPが残ると、公開ドメインから推測されるURLや既知のサブドメイン経由でアクセスされる可能性があります。検証用だから放置してよいと考えず、アクセス制限、不要なら削除、必要なら更新という順で扱います。サイト一覧には、公開・検証・休止の状態も付けてください。

公開URLを調べるときは、外部の不明な「PHPバージョン診断サイト」へ管理画面のURLや接続情報を入力しないでください。CPIの契約画面、WordPress管理画面、担当者の台帳という、管理できる情報源を先に使います。技術者が一時的な診断ファイルを置く場合は、内容、設置時刻、アクセス制限、削除担当を明確にします。phpinfo()の画面を無制限に公開したままにすると、環境設定やパスなど余計な情報を第三者に見せます。調査用ファイルの削除も作業完了条件に含めます。

修正版が選べない場合の事業者照会と暫定対応

この段階では、設定を推測して変更する前に、CPIへ契約サーバーの修正適用状況を確認するのが基本です。CPIの旧プランや独自構成では、メニューに表示される最も新しいPHPがPHP公式の今回の修正版より古い場合があります。その場合、「一番上の版に変えた」だけでは対策完了と言えません。ただしCPIが当該版に修正をバックポートしていれば、表示番号だけで未対策とも言えません。両方の誤りを避けるため、契約情報とCVE番号を含む回答を取得します。

問い合わせに添える情報と、送らない情報

サポートには契約サービス名、サーバー名またはID、対象ドメイン、WordPressで表示されるPHP、コントロールパネルで選べる系列、確認時刻を伝えます。質問は「CVE-2026-109618とCVE-2026-109619の修正が、当契約で実行中のPHPに適用済みか」「未適用なら予定と利用者側の措置は何か」「サポート中のPHPへ移るためにプラン変更が必要か」です。もしサイトの表示障害もあるなら、発生時刻とHTTPステータスを分けて書きます。パスワード、二段階認証コード、秘密鍵、データベース接続文字列は問い合わせ本文に入れません。

件名：当契約PHPのCVE-2026-109618／109619修正適用状況について
契約プラン：［プラン名］
Webサーバー名・ID：［管理画面表示］
対象ドメイン：［公開URL］
WordPressサイトヘルスのPHP：［表示値］
コントロールパネルの選択候補：［表示される系列］
確認日時：［年月日時刻・JST］
質問1：今回2件の修正は、このサーバーで現在実行中のPHPに適用済みでしょうか。
質問2：未適用または段階適用中なら、対象サーバーへの予定時刻と利用者が取るべき措置を教えてください。
質問3：修正済みのサポート中PHPへ移るために必要なプラン変更、移転、互換性上の注意点を教えてください。

問い合わせは回答を待つ間も記録に残します。「受付番号」「送信日時」「回答予定」「次の確認担当」を入れます。メールだけでは担当変更で見落としやすいため、作業台帳から参照できる場所へ控えます。問い合わせ先のメールアドレスやフォームURLは、検索で見つけたものを無条件で使わず、契約者向けCPI公式サポートから開きます。緊急時ほど偽のログイン案内やフィッシングに注意してください。

回答別の対応を先に決める

「当サーバーに今回の2件は修正済み」と回答された場合、その回答が対象プラン・対象サーバー・実行PHPに適用されるか読みます。適用範囲が合っていれば、回答と確認時刻を保存し、公開画面、管理画面、フォーム、エラーログを確認します。PHP8.0や8.1のようなPHPプロジェクトのサポート終了系列を使っているなら、今回の修正が入ったとしても長期運用の課題は残ります。更新計画を別途立て、古いままでよいという結論にしません。

「未適用で、修正版を選べる」と回答された場合、必要なバックアップと互換性確認をして切り替えます。切替の操作場所はプラン別マニュアルに従い、公開サイトとWordPress管理画面を検証します。複数ドメインに共通の設定か、ディレクトリ単位かを事前に確認します。トラブル時に元の版へ戻せる場合でも、その版が未修正なら安全な最終状態ではありません。旧版へ戻すのは復旧までの短期措置として、事業者と相談して期限を決めます。

「未適用で、修正版も選べない」または「回答未着」の場合、CPIの正式な暫定対策を確認します。公開サイトの利用状況、個人情報・決済・問い合わせの有無、代替手段、停止可能時間を責任者と評価してください。公式案内で完全な緩和策が示されないなら、WAFやWordPressのメンテナンス表示だけで完全防御と考えません。必要に応じてWeb側のアクセス制限、公開停止、別の修正済み環境への移行を検討します。公開を続ける決定をする場合も、根拠と次の確認時刻を残します。

暫定策と根本対策を混同しない

PHP公式は緩和のための設定を説明していますが、更新を根本対策と位置づけています。共用サーバーではリクエストを処理する前の設定やワーカー再起動を利用者が制御できない場合があり、WordPress内のプラグイン一つでPHP本体の不具合を完全に塞げるとは限りません。.user.iniや.htaccessへネット上の設定を貼り付ける前に、CPIがその契約で許可する方法か、効力の範囲はどこか、実行PHPに反映されるかを確認します。設定を入れてサイトが壊れた場合の復旧手順も必要です。

WAFは特定の攻撃パターンを遮断する補助策として有用な場合がありますが、今回の2件すべての攻撃経路を止めると保証できるものではありません。ログイン画面の二段階認証、プラグイン整理、管理者権限の見直しも通常の防御として重要ですが、未認証のPHP本体の問題への直接の修正ではありません。「できる対策を全部やった」ことと「今回のCVEが解消した」ことを別欄に書いてください。対策の意味を分けると、関係者への報告も正確になります。

公開継続を判断する会議で決めること

運用責任者、制作担当、インフラ担当の三者がいる場合、各自の役割を決めます。運用責任者は公開を続ける理由と事業影響を判断し、制作担当はWordPress・フォーム・テーマの互換性を検証し、インフラ担当はCPI回答、PHP設定、移行先サーバーを確認します。担当が一人でも、役割を時間順に分けて記録します。誰が「サーバー側は対応済み」と言ったかが曖昧なまま、制作担当がPHPを無理に切り替える状況を避けます。

最低限、公開継続の条件、再判断する時刻、停止を発動する条件、顧客への連絡先、復旧を確認する方法を決めます。たとえば「事業者から当契約への修正適用が確認できないまま翌営業日を迎えたら公開を制限する」は、組織ごとの例であり、全サイトに同じ期限を推奨するものではありません。扱う情報の機密性、代替ページの有無、事業影響によって判断は変わります。見た目だけのメンテナンス画面がPHPへのリクエストを止めるとは限らないため、停止の実装方法はCPIと確認します。

回答別の判断例――「確認済み」と「不明」を混ぜない

例1：対象契約への修正適用が明記された場合。担当者はCPIの回答を保存し、どのPHP系列とWebサーバーが対象かを記録します。WordPressサイトヘルスの実行版と照合し、対象から漏れる別サイトがないか確認します。今回の緊急対応は完了と判断できても、サポート終了系列の継続使用、古いテーマ、バックアップ不備が残るなら別の改善計画を立てます。「修正済み」の言葉をサイト全体の恒久的な安全保証へ広げないことが重要です。

例2：修正版を選択できるが互換性が未確認の場合。サイト担当はファイルとDBを取得し、検証環境でテーマ、フォーム、予約、管理画面を試します。失敗した機能と使っているプラグイン版を記録し、代替・更新・改修を選びます。事業責任者は切替可能な日時と、失敗時に戻す条件を決めます。検証を無期限に延ばして未修正の本番を放置しないよう、担当者と次の判断時刻を設定します。必要なら公開範囲の一時制限も選択肢に入れます。

例3：選べる修正版がなく、CPIからの回答も未着の場合。この状態を「安全」または「侵害済み」と断定せず、「今回のCVEへの適用状況未確認」と記録します。扱う個人情報、フォームの有無、攻撃面、顧客影響を確認し、公開継続の責任者を決めます。移行先候補と切替工程を先に調べ、サポートには回答予定と暫定措置を確認します。外向けの告知が必要なら、事実として確認できた範囲だけを伝えます。証拠なく「当社サイトが攻撃された」と書いたり、逆に「影響はありません」と保証したりしないでください。

一時的に公開を制限するときの実務

暫定的な制限の目的は、危険が疑われる処理への到達を減らし、確認・移行の時間を確保することです。手段はサイト全体の停止、特定機能の停止、IP制限、事業者が正式に案内する設定など、構成により異なります。管理画面だけを隠しても、今回の問題の対象となるPHPリクエスト全体を遮断したとは言えません。また、キャッシュされたトップページだけを見て「停止できた」と判断しないでください。制限する対象、許可するIP、例外URL、解除時刻と担当を先に決めます。

公開制限をするとフォームや予約が止まり、利用者への案内が必要になることがあります。代替の連絡手段を用意する場合、個人情報を安全に受け取れる経路か確認します。SNSの公開コメントに問い合わせ内容を書かせるような案内は避けます。作業後は一般利用者と許可ユーザーの両方の視点からアクセスを試し、制限が効いていることを確認します。ログを保存し、解除前にCPIの修正適用、移行完了、主要機能の動作という条件を改めて確認します。

障害・侵害の疑いがあるときは記録を先に守る

PHP切替を急ぐ中で、見覚えのない管理者、突然増えたPHPファイル、改ざんされたページ、身に覚えのない外部通信を見つけた場合は、通常の更新作業とは別の対応へ切り替えます。発見者は画面のURL、発見時刻、表示内容を記録し、アクセスログとエラーログの保全を依頼します。ファイルを手当たり次第に削除すると、何が起きたかを判断する材料を失う可能性があります。侵害の疑いを持つことと、原因が今回の2件のCVEだと特定できることは別です。調査結果がない段階で原因を断定しません。

顧客情報や認証情報への影響が疑われる場合、影響を受ける範囲を把握し、事業者と専門家、社内の責任者へ早く共有します。個人情報の扱いには法令や契約上の連絡義務が関わることもあるため、広報文の前に法務・セキュリティ担当へ確認します。利用者に必要な知らせは事実に基づき、判明したこと、まだ調査中のこと、次の更新予定を分けます。安易な「被害はありません」という断言も、憶測による被害拡大の表現も避けます。復旧用バックアップを使う場合は、そのバックアップが問題発生前のものか確認してください。

ログを外部へ渡す際には、アクセス元IPやURLのクエリに個人情報・認証情報が入っていないか確認します。共有先、保存期間、削除方法を決め、公開チャットに生ログを貼り付けないでください。検証が済んでいない段階では、修正済みPHPへ更新しても、侵害により設置された不正ファイルや盗まれた認証情報が自動的に消えるわけではありません。更新後もアカウント、ファイル、プラグイン、外部接続を調査します。危険を見つけたときに誰が公開を止められるか、権限も決めておきます。

旧プランからの移行計画と切替手順

今回の緊急対応を終えても、長期的にはサポート中のPHPを継続して使える環境へ移る必要があります。CPI公式FAQは、旧共用レンタルサーバープランから新しい共用プランへの「プラン変更」が可能な場合があると案内しています。ただしストアカート、マネージド専用、root権限付専用から共用へは同じ手続きで変更できないなど例外があります。旧契約をすぐ解約して新契約を入れるのではなく、まず契約種別と移行手続きをCPIに確認します。

移行の判断材料を一枚に集める

移行計画には「現在の契約でCVE修正が適用されたか」「サポート中PHPの選択肢があるか」「WordPress本体・テーマ・プラグインがそのPHPで動くか」「データベース版」「メールを同じ契約で使っているか」「DNSの管理者」「旧サーバー停止日」を入れます。サイトデータだけをコピーしても、メール、DNS、SSL、外部API、定期実行、決済、フォーム通知が抜けると業務が止まります。契約変更によって何が移るかは、プランの条件で異なります。CPIの公式プラン変更マニュアルと個別回答で移行対象を確定してください。

「新プランならPHP 8.4がある」という一般論だけで申し込まず、対象サーバーの修正済みパッチ番号、WordPressが使う拡張、データベース互換性を確認します。テーマに古いPHP構文が含まれると、PHPを上げたとたん管理画面が白くなる場合があります。事前に検証環境を用意し、画面表示だけでなくフォーム送受信、管理者ログイン、画像アップロード、検索、予約や購入を試してください。もし古いプラグインに最新版がなく、修正済みPHPで動かないなら、代替機能の選定を移行工程へ入れます。

工程表：旧サーバーを早く止めすぎない

段階	担当の作業	成果物・完了条件	問題が出たら
現状確認	契約、PHP、DB、DNS、メール、外部連携を台帳化	漏れのない移行対象一覧	不明欄を残しCPIと担当者へ照会
バックアップ	ファイルとDBを別の場所へ保存、復元方法を試す	取得日時・保存先・復元担当が分かる	不完全なら切替を延期
新環境構築	修正済みPHPとWordPressを検証用URLで再現	公開画面・管理画面・主要導線が動く	テーマ・プラグイン・DB互換を切り分け
並行稼働	新旧を同時に保持し、差分更新と切替時刻を決定	DNS・メール・SSLの切替手順が明確	旧環境を保持したまま戻し方を実行
切替と監視	DNS等を切替、フォーム実送信とログ確認	利用者導線と運用導線が正常	障害条件に応じて切戻しを判断
旧環境停止	差分・メール・バックアップを最終確認	責任者が停止承認、旧契約終了	不明点があれば停止日を延ばす

CPIの公式FAQは、新サーバーへの移転作業や運用切替が終わる前に旧サーバーが止まらないよう、停止希望日は余裕を持って指定するよう説明しています。この点は重要です。DNSが新環境へ向いても、利用者の一部に旧環境が見える時間や、メールが旧環境へ届く運用が残る可能性があります。短い切替ウィンドウだけで全て完了したと判断せず、必要な並行稼働期間とデータ同期を事前に決めます。

バックアップは「作成」より「戻せる」を重視

WordPressのバックアップはファイルとデータベースの両方が必要です。ファイルにはテーマ、プラグイン、アップロード画像、設定が含まれ、データベースには投稿、設定、ユーザーなどが含まれます。プラグインのバックアップファイル一つに何が入っているかを確認し、PCなど別の保存先にコピーします。ファイルサイズが大きいだけでは正常に取得できた証拠にはなりません。最低でもファイルが開けること、DBダンプが存在すること、復元方法を担当者が理解していることを確認します。

復元テストは本番を消して試すことではありません。隔離した検証環境にコピーし、画像、投稿、パーマリンク、ログイン、プラグイン設定が再現できるか確認します。フォームから実際にメールを送る場合はテスト用アドレスを使い、本番の顧客へ通知が飛ばないようにします。決済や予約がある場合はサービスごとのテストモードや検証アカウントを使い、実データを処理しないでください。検証環境がなくても、少なくとも取得したファイルの一覧、DBサイズ、保存先、復元手順を記録し、不確実性を責任者へ報告します。

DNS・メール・SSL・外部連携を忘れない

サーバー移転はWordPressだけの引っ越しではありません。ドメインのDNSレコード、メールのMX/SPF/DKIM/DMARC、SSL証明書、自動返信の送信元、外部サービスに登録したIP、cron、バックアップ先、アクセス解析、Search Consoleの所有権確認などが影響を受けることがあります。ただし契約や構成により実際の変更範囲は異なります。CPIのプラン変更マニュアルに従い、現在の設定を一覧化してから、新環境で必要な項目だけを再設定します。

特にメールは、Webだけ先に切り替えて旧サーバーに受信箱を残すと、問い合わせ通知の見落としにつながります。問い合わせフォームの「送信成功」表示と、管理者宛メールが届くことは別です。迷惑メールフォルダ、送信元ドメイン認証、別のメールサーバーを使う設定まで含め、実際の受信を確認してください。切替後にメールが来ない場合、PHPの版だけを疑わず、MX、SMTP、送信プラグイン、送信ログを切り分けます。関係者にはテスト期間と顧客への影響可能性を先に伝えます。

公開URLと検索流入を守る

移行の際、記事URLやパーマリンクを不要に変えないことも重要です。サーバーだけを変えるなら原則として既存URLを維持し、canonical、サイトマップ、robots、構造化データ、内部リンク、画像URLを検証します。検証環境を検索エンジンにインデックスさせない一方、本番切替後に誤ってnoindexを残さないようにします。HTTPSの証明書とリダイレクトを確認し、旧サーバーのホスト名が公開ページの画像やCSSに混ざっていないか調べます。公開後は代表記事、検索流入上位ページ、問い合わせ導線を優先して確認します。

切替時にはDNSの反映に幅があります。新旧で投稿やフォーム送信が同時に起こると、データが分散するおそれがあります。編集停止時間を設けるか、差分同期の担当と方法を決めます。ユーザー投稿や予約など更新が多いサイトは、閲覧だけの企業サイトより移行設計が複雑です。移行業者へ任せる場合も、「どのデータをどの時刻で同期するか」「切戻し条件」「障害時の連絡経路」を契約前に確認してください。完了報告はDNS切替時刻ではなく、運用上重要な機能の検証結果を含めます。

サイトの種類別に移行の優先順位を変える

次の3例は実在案件の実績ではなく、作業設計を説明する架空のケースです。企業情報サイトなら、更新頻度が低いページと問い合わせフォームの機能確認が中心です。URL一覧、画像、フォーム送受信、管理画面の編集を優先し、編集停止時間を決めます。主要記事のURLが変わらなければ、検索から来た読者の導線を保ちやすくなります。ただし固定ページに古い埋め込みコードがある場合、トップページだけの確認では見逃すため、アクセス上位の下層ページも確認します。

予約・決済サイトなら、新旧サーバーで同じ注文を二重に処理しないことが中心です。DNS切替前後の注文受付をどう扱うか、決済サービスのテストモードと本番資格情報をどう分けるか、通知メールやWebhookの宛先を誰が変えるか決めます。切戻しをする場合、切替後に入った注文や予約を旧DBへどう反映するかが難所です。「障害が出たら旧サーバーに戻す」だけでは、切替後データが失われる可能性があります。データ同期の方針が決まらなければ、移行日時を延期してください。

複数サイトを一契約で運用する場合、ドメインごとに設置先と実行PHPが異なる可能性があります。一つのプラン変更で全ドメインが新サーバーに移るか、メールも同時に移るか、サブドメインのDNSを誰が管理するかを一覧化します。最も重要なサイトだけ先に移す方針もあり得ますが、残したサイトのPHP対応が不明ならリスクも残ります。サイトごとに「移行済み」「並行稼働」「旧環境のみ」を表示し、最後のサイトが完了するまで旧サーバー停止を承認しないようにします。

依頼する相手に渡す作業条件

制作会社やインフラ担当に移行を依頼するなら、「PHPを新しくする」だけでなく、対象URL、契約プラン、CPI回答、必要なPHP系列、現在のテーマ・プラグイン、使用中のメール、バックアップ範囲、切替希望日、障害時の連絡先を渡します。発注範囲には、検証環境の構築、主要機能のテスト、DNS切替、旧環境とのデータ差分、切戻しの実施条件、作業報告を明記します。画面が見えることだけを検収条件にしないでください。

検収では、責任者が代表ページを開き、管理者が投稿を編集し、運用担当がテストフォームを送って受信を確認します。サーバー担当はPHPの実行版と今回の修正適用の根拠を提出し、移行担当はバックアップと切戻し手順の場所を示します。未完了項目があるなら「完了」と「暫定運用」を区別します。特にCPIの旧サーバー停止日が迫る場合、検収で見つけた問題を修正する余地を残す必要があります。日程だけで停止を確定せず、マニュアルとサポートの案内に沿って調整してください。

移行費用を比較するときは「月額」だけを見ない

プラン変更と他社移転を比較する際、サーバー月額だけで安さを判断しないでください。実際には初期設定、WordPressの移行、メールの移行、独自ドメインとDNS、SSL、動作検証、切替立会い、切戻し準備、旧契約の並行利用などが作業量に入ります。金額は契約条件と作業範囲で変わるため、この記事では価格を断定しません。CPIの現行料金と変更可能なプランは、申し込み前に公式ページと個別見積もりで確認します。

見積もりを依頼するなら、「対象3ドメイン、WordPress2サイト、メール10アカウント、フォーム2種類、予約連携1件」のように対象を具体的に書きます。これは比較方法を示す架空例です。A案はCPI内のプラン変更、B案は外部サーバーへの移転として、含まれる作業、検証回数、緊急時対応、切戻し、旧サーバーの費用、公開後の保守を同じ表で比べます。安い案でもフォームの実送信やメール移行が対象外なら、後から追加費用と障害が発生し得ます。質問は「何を検査して完了とするか」まで含めます。

また、事業者のPHP修正適用が確認できるまで待つ費用も、単なるゼロ円ではありません。担当者の確認時間、公開制限による機会損失、未確定のリスク、再照会の工数があります。反対に、準備不足のまま移転を急ぐと、注文や問い合わせを取りこぼす可能性があります。どちらの選択でも、期間、担当、成果物、未解決リスクを一枚に並べ、責任者が判断できる状態にします。数値を入れる場合は自社の実績や見積もりに基づき、根拠のない被害額を広告的に膨らませないでください。

更新・移行後の動作確認とよくある質問

PHPを切り替えた、あるいは移転先へドメインを向けた直後は、公開ページ・管理画面・フォーム送受信・エラーログの4点を最低限確認します。トップページだけが表示できても、投稿編集や問い合わせが壊れている可能性があります。コントロールパネルの選択値、WordPressのサイトヘルス、公開サイトを別々に見るのが基本です。CPIが修正済みパッチを適用したかというセキュリティ判断も、切替後のWordPress動作確認とは別に記録します。

切替後の確認を担当者と完了条件に分ける

1. サーバー担当：対象契約・ドメインのPHP選択値、CPIの修正適用回答、エラーログの時刻を確認します。問題が出たら変更前の記録と比較します。
2. WordPress担当：サイトヘルスの実行PHP、ログイン、投稿編集、画像アップロード、検索、主要プラグインを確認します。古いキャッシュや別のサイトを見ていないかも確かめます。
3. 運用担当：公開トップ、代表記事、スマホ表示、問い合わせフォームの送信と受信、予約・購入など主要導線を確認します。未検証の機能は「未確認」と明記します。
4. 責任者：作業記録と未確認項目を読み、公開継続・切戻し・追加調査のどれにするか承認します。障害がなくても翌営業日の再点検時刻を決めます。

フォームのテストでは、送信完了画面、管理者宛メールの受信、自動返信メールの受信を分けて記録します。通常の閲覧者がアクセスするページだけでなく、投稿者や管理者の権限で操作する画面も確認します。エラーログは「ゼロであること」だけにこだわらず、PHP切替時刻以降に新しく増えた致命的エラー、プラグイン由来の警告、処理に失敗したURLを確認します。共有サーバーでは他サイトのログが混じる可能性もあるため、時刻、パス、対象ドメインで切り分けます。

30分・翌営業日・1週間で見る内容

切替から30分以内は、公開トップと代表記事、管理画面、フォームの実送信、画像、SSL、エラーログを確認します。障害が出たら変更時刻と現象を記録し、あらかじめ決めた切戻し条件に当てはめます。閲覧だけのチェックでは、フォームで送信ボタンを押したあとに管理者宛メールが届かない障害を見落とします。テスト結果は「成功／失敗／未実施」で残し、未実施を成功に数えません。

翌営業日は、担当者が実際の運用をして初めて分かる不具合を調べます。投稿編集、予約管理、添付ファイル、通知メール、定期実行、外部API連携を確認し、アクセスログのエラー増加を切替前と比較します。メールの到着遅延やDNS反映のばらつきも見ます。利用者から問い合わせが来た場合は、発生時刻、URL、操作、エラー文を聞き、パスワードやカード情報を送らないよう案内します。

1週間以内は、検索流入の多いページ、サイトマップ、canonical、リダイレクト、画像欠落、フォームの受信漏れを確認します。Search Consoleは反映に時間差があるため、当日の数値だけで移行が成功・失敗したと断定しません。旧サーバーへのアクセスがまだある場合、DNSキャッシュ、古いリンク、外部システムの設定を確認します。旧サーバーを止める前に、必要なログとバックアップを保全し、運用責任者の承認を取得します。

白画面や500エラーが出たら

まず表示障害が公開ページだけか、管理画面も含むかを確かめます。次に切替時刻前後のエラーログを保存し、テーマ・プラグイン・PHP設定のどこで失敗したかを絞ります。.htaccessを編集した直後なら、元ファイルへ戻して表示が復旧するかを検証します。CPIのマニュアルでは、契約によってphp_valueやphp_flagの記述が500エラーになると案内されています。インターネット上の一般的なApache設定例を無条件でコピーしたなら、その行も確認対象です。

PHPの系列変更でテーマやプラグインが動かない場合、元の版へ戻して緊急復旧できることがあります。ただし元の版が今回の脆弱性に未対応なら、復旧しただけで対策完了とは言えません。公開リスク、事業影響、修正可能な互換性、代替環境への移行を責任者と決めます。ログを見ずにプラグインを大量に削除したり、感染が疑われるファイルを丸ごと古いバックアップへ戻したりすると、原因や証拠が失われます。復旧と調査を両立できる手順を選びます。

よくある質問：WordPress本体を更新すればPHP脆弱性は直りますか？

いいえ。今回のCVE-2026-109618／109619はPHP本体の問題です。WordPress.orgの案内も、この問題のためのWordPress本体更新は予定していないと説明しています。通常のWordPress更新は別の脆弱性や互換性のために必要ですが、サーバー側のPHP修正適用と同一視しないでください。WordPressの更新完了メール、プラグイン一覧の「更新なし」、テーマの最新版表示は、PHPの修正状況の証明にはなりません。

よくある質問：CPIの管理画面にPHP 8.3が出ていれば安全ですか？

それだけでは判断できません。選択肢にある版と、そのサイトが実行する版は異なります。また「8.3」という系列名だけではパッチ番号が分からず、今回の修正が入った8.3.36相当か確認できません。事業者のバックポートがあれば番号が古く見えても修正済みの可能性があります。契約プラン・Webサーバー・実行PHP・CPI回答を結びつけて判断します。何を確認したかは台帳に残し、回答の適用範囲が別契約なら使わないでください。

よくある質問：PHP8.0のままならWordPressは必ず侵害されていますか？

いいえ。古いPHPを使っていることと、実際に侵害されたことは別です。ただしPHPプロジェクトはPHP8.0へ今回の通常の修正版を配布していません。ベンダー独自の修正、緩和策、移行先の確認が必要です。侵害の有無は不審なファイル、管理者、アクセスログ、改ざん、外部通信などの証拠から調べます。疑いがある場合は証拠を保存し、事業者と専門家へ連絡してください。現時点の表示だけで感染も安全も断定しないことが重要です。

よくある質問：CPIのSecure File Managerで接続できません

まず、ログインに使う資格情報の種類、契約プラン、アクセス制限、公式の利用条件を確認します。FTPアカウントとCPIマイページのアカウントは役割が異なる場合があります。SecureFileManagerの公式マニュアルと管理画面で、現在のプランに合う手段を確認してください。接続できないからといってIP制限や認証を無計画に解除しないでください。FTPソフトを使う場合も、暗号化方式・接続先・ポート・許可IPを事業者の案内と照合します。パスワードや認証コードを制作会社へチャットで送るのは避けます。

よくある質問：プラン変更とPHP切替はどちらを先にしますか？

今回の修正済み版を現契約で選べ、互換性検証もできるなら、先に安全な版へ変更し、長期的なプラン変更を別工程にする判断が考えられます。現契約で選べない場合は、事業者のパッチ適用状況を確認したうえで、公開継続のリスクを評価し、移行を急ぎます。移行に時間がかかるなら事業者の正式な暫定措置やアクセス制限を検討します。CPIのプラン変更可否は契約種別で異なるため、管理画面の見た目だけで移行可能と決めず、公式FAQと個別回答を照合してください。

よくある質問：旧プランをすぐ解約してもよいですか？

避けてください。CPI公式は、移転作業や運用切替より先に現行サーバーが停止しないよう、停止希望日には余裕を持つよう案内しています。WordPressファイルとDBの移行だけでなく、DNS、SSL、メール、フォーム受信、バッチ処理を確認してから旧契約の停止を判断します。サイトによっては検索エンジンがクロールするURL、顧客のブックマーク、外部サービスに登録された通知先も影響します。撤去する前に、旧環境で最後に受けたデータと新環境に入ったデータが一致するか確認します。

公開後の継続点検と、この記事の位置づけ

今回のPHPの修正適用を確認した後も、PHPのサポート期限、WordPress本体、テーマ、プラグイン、管理者の認証、バックアップ、復元テストを定期的に見直します。サーバー会社の対応は時間とともに更新されるため、「2026年10月23日に確認した」というメモは永続的な安全証明にはなりません。少なくともCPIから新しい告知が出たとき、プランを変更したとき、WordPressに新しいプラグインを入れたときは台帳を更新します。

本記事はCPIに絞った契約・プラン・移行の判断を扱いました。4社を横断した操作順はレンタルサーバー4社のPHP対応手順、自サイトが対象かの一次判定はPHPの版と修正状況の確認方法、PHP切替前の一般的なバックアップと検証はWordPressのPHP更新手順も参照してください。重なる情報を一つの記事で何度も繰り返すより、自分が今困っている段階に合う記事から読む方が早く判断できます。

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

サーバーの脆弱性対応では、公式情報を読み、作業内容を記録し、相手に分かる言葉で報告する力が欠かせません。AIは告知の要点整理、問い合わせ文の下書き、確認表の作成を助けます。ただし、AIの回答だけでパッチ適用や安全性を断定せず、PHP・WordPress・CPIの一次情報と実際の管理画面で検証してください。

WithAIは脆弱性の緊急対応窓口ではありません。日々の情報整理や仕事でのAI活用を学びたい人は、WithAIの無料学習案内を確認してください。学習と安全な運用の両方を、根拠のある手順で進めましょう。