この記事で分かること
結論から言うと、2026年10月のPHPの脆弱性騒動は、AIを組み込んだサーバー管理の体制が整っていれば、かなり早く対応できた可能性があります。脆弱性に気づく、影響を調べる、更新の準備と試験をする、といった作業の多くはAIに任せられるからです。ただし、ロリポップやさくらのような共用のレンタルサーバーでは、PHPの土台を直す権限はサーバー会社にあり、AIを使っていても利用者側ですぐに直せたとは限りません。AIが役立つのは、検知・影響の調査・復旧後の確認を早めるところです。この記事では、人の手だけで対応する場合との違い、AIでできること・できないこと、レンタルサーバーという仕組みそのものの弱点、任せる前に確かめることを説明します。
ホームページの更新や保守を、社内の担当者や付き合いのある制作会社に「何かあったら連絡して」と任せている会社は多いと思います。
ところが、今回のPHPの脆弱性のように「公開された日から急いで直すべき」知らせは、人の手だけの体制だと気づくのが遅れがちです。夜に発表され、翌朝に担当者が気づき、制作会社に連絡して、見積もりと日程を調整するうちに、数日が過ぎてしまいます。
この記事では、今回の騒動を例に、AIを組み込んだ運用に任せておくと何が早くなるのか、そして人が判断すべきところはどこかを、社長の目線で整理します。
今回のPHP騒動は何が問題だったのか
2026年10月21日、PHP（多くのホームページを動かしているプログラムの土台）で、2件の重大な脆弱性（CVE-2026-109618とCVE-2026-109619）が修正されました。
どちらも、条件によっては、ログインしていない第三者がサーバー上で好きなプログラムを動かせる恐れがある危険なものです。PHPの公式も、すぐに更新するよう呼びかけています。
| PHPの系列 | 修正版 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
PHP 8.2は2026年12月31日で修正の提供が終わるため、長い目で見ればサポートが続く系列への移行も考えるべきです。
共用のレンタルサーバーでは、サーバー会社がPHP本体を修正版に入れ替えます。当社が10月22日に確認した範囲では、さくらのレンタルサーバでは修正版がすでに入っていました。一方、VPS（自社専用の仮想サーバー）の中のPHPは、利用者自身が更新しなければなりません。
社長が今すぐ確かめることや、作業のためにサイトを止めるときの注意点は、PHPの脆弱性に社長が今すべきことにまとめています。
実際に何が、いつ起きたか
今回の流れを、公式の発表をもとに時系列で整理します。時刻は日本時間です。
| 日時 | 出来事 |
|---|---|
| 10月20日 | PHPの開発チームが「重大なセキュリティ修正を翌日に公開する」と予告 |
| 10月21日 | IPA（情報処理推進機構）が、修正版の公開に向けた事前準備を呼びかけ |
| 10月21日 夜 | PHPの修正版が公開。さくらインターネットは22時30分から予防のための緊急メンテナンスを開始。ロリポップも修正版の公開に先立つ予防措置としてメンテナンスを実施 |
| 10月22日 未明〜朝 | ロリポップは一部サーバーのサイトを一時停止。さくらは8時15分時点で、対応が終わったサービスから順次再開と発表 |
| 10月22日 日中 | ロリポップはサイトを順次再開し、15時33分にユーザー専用ページ（管理画面）なども再開。IPAがCVE番号を明記した注意喚起を掲載 |
注目したいのは、修正版が出る前日に予告があり、IPAも事前準備を呼びかけていたことです。準備に使える時間は、およそ1日ありました。
人の手だけで対応すると、なぜ時間がかかるのか
時間がかかる原因は、作業そのものよりも「気づく」「調べる」「頼む」「日程を合わせる」といった、作業の前の段取りにあります。人の手だけの体制と、AIを組み込んだ運用を比べると、次のようになります。
| 段階 | 人の手だけの体制 | AIを組み込んだ運用 |
|---|---|---|
| 知らせに気づく | 担当者がニュースやメールで気づくまで。夜間・休日なら翌営業日以降 | 公式情報を毎日決まった時刻に確認し、該当すれば通知 |
| 自社への影響を調べる | 担当者がサーバー会社や制作会社に問い合わせる。数日かかることも | サーバーに接続してバージョンを確認し、影響の有無を数分で整理 |
| 対応の案を用意する | 制作会社が見積もりと作業内容を作る | 修正版・バックアップ・元に戻す手順を案としてまとめる |
| 試験をする | 作業日に本番で直接試すことが多い | 検証用の環境で更新し、主要ページや問い合わせの動きを確かめる |
| 本番に反映する | 作業日の調整後。全体で数日〜2週間程度かかることも | 人が承認すれば反映。反映後もエラーを見張る |
表の日数は、地方の中小企業でよくある体制を想定した目安です。人の手だけの体制でも、保守契約で緊急対応を決めている会社なら、もっと早く動けます。逆に、担当者が辞めて誰も管理していない場合は、気づかないまま放置されることもあります。
ポイント
差がつくのは作業の速さではなく、作業を始めるまでの段取りです。「誰かが気づくのを待つ」体制から、「毎日決まった確認が走る」体制に変えることが、緊急時の速さにつながります。
AIに管理を任せていたら、どう対応できたか
AIに事前に監視と作業の権限を設定しておいた場合、今回のような知らせには、次の5つの流れで対応できます。
- 1. 脆弱性の情報を見つける：PHP公式やCVE（脆弱性の共通番号）の情報を毎日確認し、自社に関係がありそうなものを拾います。
- 2. 自社のサーバーを調べる：サーバーに接続し、使っているPHPのバージョンや、影響を受けるサイトを特定します。
- 3. 対応の案をつくる：どの修正版にするか、バックアップはあるか、うまくいかなかったときにどう戻すかをまとめます。
- 4. 検証用の環境で試す：本番とは別の環境で更新し、WordPressや問い合わせフォームなど、業務で使う機能が動くかを確かめます。
- 5. 人が承認して本番に反映・監視：内容を確認して承認したあとに本番へ反映し、反映後もエラーが出ていないかを見張ります。
ここで大切なのは、これは「事前に監視と権限を設定しておいた場合」の動きだという点です。Claude Code（AIに作業をさせる道具の一つ）を入れただけで、AIが自分から24時間見張ってくれるわけではありません。毎日決まった時刻に確認を走らせる仕組みや、自動テスト、本番への反映の仕組みと組み合わせてはじめて、この流れが回ります。
webcan.jpで実際に行ったこと
当社が運営するwebcan.jpでも、修正版が公開された翌日に、AIがサーバーへ接続してPHPのバージョンを確認しました。
同じサーバーに置いている4つのサイトがすべて修正版の8.3.36で動いていること、ほかの系列も入れ替わっていることを数分で確かめ、その結果をもとに、社内の判断と、この記事の前提になる記事の執筆まで進めています。
人が一つずつ管理画面を開いて確かめていたら、半日はかかっていた作業です。AIに任せたことで、人は「対応が必要かどうか」の判断だけに時間を使えました。
レンタルサーバーでは、AIを使っても直せないことがある
ここまで「AIなら早い」と書いてきましたが、ロリポップやさくらのような共用のレンタルサーバーを使っている場合は、結論が少し変わります。
共用のレンタルサーバーでは、PHPの実行環境と、セキュリティの修正を当てる権限を、基本的にサーバー会社が持っています。仮にClaude CodeなどのAIがサイトを管理していても、サーバー会社が止めた管理画面を動かしたり、サーバー全体のPHPを直接直したりすることはできません。
また、WordPress本体やプラグインを更新しても、今回の脆弱性は直りません。直すにはサーバー側のPHP本体を入れ替える必要があり、そこはサーバー会社の作業です。
| 作業 | レンタルサーバーでのAIの対応 | 補足 |
|---|---|---|
| PHPの脆弱性の情報を見つける | ◎ 自動にできる | 公式情報やサーバー会社の告知を毎日確認 |
| サイトごとの影響を調べる | ○ 条件つきで可能 | サーバーに接続できる権限があれば、バージョンを確認できる |
| WordPressの更新 | ○ 権限があれば可能 | ただし今回の脆弱性はこれでは直らない |
| サーバーの土台のPHPを直す | × 原則できない | サーバー会社の作業 |
| サーバー会社の緊急停止を解除する | × できない | 再開を待つしかない |
| 復旧後の動作確認 | ◎ 自動にできる | 表示・問い合わせフォーム・予約の動きを確認 |
つまり、レンタルサーバーでAIが力を発揮するのは「直す」ところではなく、「早く気づく」「自社への影響を素早く整理する」「再開したらすぐに動作を確かめる」ところです。止まっている時間そのものを縮められるかどうかは、サーバー会社の準備と仕組みしだいです。
本当の論点：レンタルサーバーは、利用者がほとんど手を出せない
今回の騒動で差がついたのは、AIを使っていたかどうか以上に、サーバー会社が脆弱性の公開前にどこまで準備できていたかです。予告から修正版の公開まで、準備の時間は1日ほどありました。
AIを導入しているサーバー会社なら、情報収集や影響範囲の洗い出し、更新の準備は効率化できたはずです。ただし、実際にどれだけ停止時間を縮められたかは、各社のシステムの作りによります。
そして利用者の立場から見ると、より大きな問題があります。レンタルサーバーは、重大な脆弱性が出たときに、利用者側ではほとんど何も制御できない仕組みになっているということです。サイトが止まるかどうか、いつ再開するかは、サーバー会社の判断に任せるしかありません。
| 比べる点 | 共用のレンタルサーバー | VPS・自社管理のサーバー |
|---|---|---|
| PHPを直す人 | サーバー会社 | 自社（または保守を頼んだ会社） |
| 直す速さ | サーバー会社の準備しだい。利用者は待つだけ | 自社の体制しだい。AIを組み込めば準備から試験まで速くできる |
| 止まるかどうかの判断 | サーバー会社が決める | 自社で決められる |
| 日ごろの手間と知識 | 少ない | 多い。AIや保守会社の手助けが前提 |
| 向いているサイト | 会社案内など、短時間止まっても困らないサイト | 予約・ネットショップなど、止まると売上に響くサイト |
どちらが正解ということではありません。大切なのは、自社のサイトが止まったら何が困るのかを踏まえて、サーバーと運用の形を選ぶことです。
レンタルサーバーを使い続けるなら、決めておくこと
- サーバー会社の告知を自動で拾う：緊急メンテナンスや再開の知らせを、担当者が見落とさない仕組みにする。AIで毎日確認する方法もある。
- 対応の早いサーバー会社を選ぶ：過去の緊急時に、どれだけ早く告知し、どれだけ早く再開したかを選ぶ基準に入れる。
- 止まったときの代わりの窓口を決める：サイトが止まっても、電話やGoogleビジネスプロフィールで問い合わせを受けられるようにしておく。
- 再開後の確認を決めておく：再開したら、表示と問い合わせフォームの送信を誰が確かめるかを決める。AIに任せやすい部分。
- 止まると困るサイトは移行も考える：予約やネットショップなど、止まると売上に響くサイトは、自社で制御できるVPSとAIを組み込んだ運用への移行を検討する。
AIに任せても、人が判断すべきこと
では、すべてを自動にすればよいかというと、そうではありません。おすすめは、次のように役割を分ける設計です。
| 役割 | やること | 理由 |
|---|---|---|
| AIに任せる（自動） | 脆弱性の検知、影響の調査、更新の案づくり、バックアップ、検証用の環境での試験 | 手順が決まっていて、毎日くり返すほど価値が出る作業 |
| 人が承認する | 本番のサイトを止める判断、PHPの大きなバージョンの変更、本番への更新の反映 | 止めれば問い合わせが減るなど、経営への影響がある判断 |
| 再びAIに任せる（自動） | 反映後の監視、異常の検知、事前に決めた条件での元の状態への戻し | すぐ気づいて、すぐ戻すことが被害を小さくする |
重大な脆弱性では、修正版が出る前に、一時的にアクセスを制限したり、サイトを止めたりする判断が必要になることもあります。これは売上やお客様への影響を伴うので、AIではなく人が決めるべきことです。
また、AIによる試験が成功しても、それでセキュリティ上の安全が完全に保証されるわけではありません。AIは「速く・漏れなく準備する役」、人は「最後に決める役」と考えると、任せ方を決めやすくなります。
サーバーの種類によって、AIで対応できる範囲は変わる
AIでどこまで対応できるかは、自社のサイトがどんなサーバーに置かれているかで変わります。主な環境ごとに整理しました。
| サーバー環境 | AIによる対応 | 注意点 |
|---|---|---|
| VPS＋Docker（コンテナ） | 非常に相性がよい | 修正版を含むイメージへの更新と、作り直し（再ビルド）が必要 |
| VPSでWordPressを運用 | 対応できる | テーマやプラグインが新しいPHPで動くかの確認が必要 |
| ロリポップなどの共用サーバー | 一部のみ | PHP本体の修正と緊急停止の判断は運営会社。自社は検知・影響の確認・再開後の動作確認 |
| さくらのレンタルサーバー | 一部のみ | 同上。修正版への入れ替えは運営会社が行う |
| Shopify（ネットショップの仕組み） | 基本的に不要 | PHPの土台は利用者が管理するものではない |
特に、さくらのVPSなどでRocky Linux（サーバー用の基本ソフト）とDockerを使っている環境なら、Claude CodeとGitHub Actions（更新を自動で反映する仕組み）などを組み合わせた自動化が現実的です。
PHPの公式Dockerイメージを使っている場合は、修正版を含むイメージへの更新、コンテナの作り直し、動作の試験という流れになります。Rocky Linuxの部品としてPHPを入れている場合は、提供元のセキュリティ更新を確認する必要があります。
共用のレンタルサーバーでは、PHP本体の修正はサーバー会社の仕事です。それでも、自社がどのバージョンを選んでいるか、新しいPHPで問い合わせフォームが動くか、といった確認は自社側に残ります。AIによる毎日の確認は、ここで役に立ちます。
社内の担当者・制作会社・AI運用の比べ方
自社に合う任せ方を選ぶために、3つの体制を比べました。どれが正解というより、自社の状況に合わせて組み合わせる考え方が現実的です。
| 比べる点 | 社内の担当者 | 制作会社の保守（人の手） | AIを組み込んだ運用 |
|---|---|---|---|
| 知らせに気づく速さ | 担当者しだい。兼務だと遅れがち | 契約しだい。営業時間内が多い | 毎日決まった時刻に確認 |
| 夜間・休日 | 対応が難しい | 別料金や対応外のことが多い | 確認と準備は止まらない。最終判断は人 |
| 抜け漏れ | 担当者の経験に左右される | 会社による | 同じ手順を毎回くり返せる |
| 記録 | 残らないことが多い | 報告書の形で残ることがある | 作業ごとに記録を残せる |
| 担当者が辞めたとき | 引き継ぎが途切れやすい | 契約が続けば影響は小さい | 仕組みとして残る |
社内の担当者が辞めたときの影響については、Web担当者の代行やホームページの運用代行の記事でも、任せる範囲の決め方を説明しています。
AIを組み込んだ運用に任せる前に確かめる5つのこと
任せ先を選ぶときは、「AIを使っています」という言葉だけで決めず、次の5つを確かめてください。
- どこまで自動で、どこから人が承認するか：本番への反映やサイトの停止を、誰が承認するのかが決まっているか。
- 何を毎日確認しているか：PHP、WordPress本体、プラグイン、サーバーの基本ソフトなど、確認する対象が書き出されているか。
- バックアップと戻し方：更新の前に自動で保存し、問題が出たら元に戻す手順が決まっているか。
- 報告の形：何が起きて、何をして、何が残っているかを、社長が読める言葉で報告してくれるか。
- 権限の範囲：AIに渡すサーバーの権限が必要な範囲に絞られ、作業の記録が残るか。
今後のサーバー運用をどう考えるか
今回の出来事から言えるのは、AIを「文章やプログラムを書く道具」としてだけでなく、サーバーやサイトの運用を手伝う担当者として使う価値が大きいということです。
たとえば、AIを組み込んだ仕組みで、複数のサイトのPHP、WordPress、Docker、サーバーの基本ソフトの状態を毎日確かめ、問題が見つかったときに更新の案と影響の範囲を知らせる運用は、すでに十分に実現できます。
そして本当に大切なのは、今回のような緊急時に対応することだけではありません。ふだんから、更新を試して反映できる状態を保っておくことです。日ごろから小さな更新を続けているサイトほど、緊急の更新も短時間で終わります。
よくある質問
Q. AIに任せれば、人は何もしなくてよいのですか。
いいえ。脆弱性の情報を集める、影響を調べる、更新の案と元に戻す手順を用意する、検証用の環境で試す、といった下準備はAIに任せられます。一方、本番のサイトを止めるか、本番に更新を反映するか、PHPの大きなバージョンを変えるかは、人が内容を見て承認する形にするのが安全です。
Q. AIが勝手にサイトを更新して、壊してしまうことはありませんか。
任せ方しだいです。本番への反映は人の承認を必須にし、反映前に検証用の環境で試す、反映後はエラーを監視して決めた条件で元に戻す、という決まりを先に作っておけば、勝手に本番を壊す事態は防げます。権限の範囲を最初に決めることが大切です。
Q. Claude Codeを入れれば、24時間見張ってくれるのですか。
Claude Code（AIに作業をさせる道具の一つ）だけで、自発的に24時間見張るわけではありません。毎日決まった時刻に確認を走らせる仕組みや、サーバーの監視、自動テスト、デプロイ（本番への反映）の仕組みと組み合わせて、はじめて継続的な見張りになります。
Q. レンタルサーバーでも、AIによる運用の意味はありますか。
あります。ただし、できることは限られます。PHP本体の修正や、サーバー会社による緊急停止の解除は、AIでもできません。AIが役立つのは、サーバー会社の告知や脆弱性の情報に早く気づくこと、自社のサイトへの影響を整理すること、再開後に表示や問い合わせフォームが動くかを確かめることです。
Q. 今回、WordPressを更新すれば脆弱性は直りましたか。
直りません。今回の脆弱性はPHP本体にあるため、サーバー側のPHPを修正版に入れ替える必要があります。共用のレンタルサーバーではサーバー会社の作業、VPSでは自社または保守会社の作業です。
Q. 社内の担当者に任せるのと、何が違いますか。
一番の違いは、気づくまでの時間と、抜け漏れの少なさです。担当者は他の仕事と兼務していることが多く、夜間や休日の知らせには気づきにくいものです。AIを組み込んだ運用なら、決めた確認を毎日同じ手順で行い、結果を記録に残せます。
Q. 費用はどのくらいかかりますか。
サイトの数や、サーバーの種類、どこまで自動にするかで変わります。一般的なホームページの保守契約は月1〜3万円程度が多く、緊急対応が別料金になっていることもあります。まずは今の契約で何が含まれているかを確かめ、足りない部分だけを相談するのが近道です。
まとめ：緊急時に速いのは「任せる仕組み」と「選んだサーバー」の両方
- 今回のPHPの脆弱性は、気づく・調べる・準備するという段取りで差がついた。
- AIを組み込んだ運用なら、検知から試験までの下準備を毎日の仕組みとして回せる。
- 本番のサイトを止める判断や、本番への反映は、人が承認する設計にする。
- 共用のレンタルサーバーでは、PHPの修正も停止の解除もサーバー会社しだいで、AIでも直せない。AIの役割は検知・影響の整理・再開後の確認。
- 止まると売上に響くサイトは、自社で制御できるサーバーとAIを組み込んだ運用への移行も考える。
- 任せる前に、承認のルール、確認の対象、バックアップ、報告、権限の5つを確かめる。
「うちのサイトは誰が見ているのか分からない」「緊急の知らせが来ても、すぐ動ける体制になっていない」と感じたら、一度ご相談ください。現在のサーバーと保守の状況を確かめ、どこをAIに任せ、どこを人が判断するかの設計からご提案します。サイトの基本的な状態はSEO無料診断でも確認できます。WEBCANのサービス全体はサービス一覧をご覧ください。
相談の入口
「今の保守契約で緊急時に間に合うか」「AIに任せるなら、どこまで任せてよいか」といった段階から相談できます。サーバーの種類、管理している人、更新の手順を一緒に確かめ、御社に合った任せ方を整理します。売り込みはしません。
出典
- PHP公式ニュース（2026年10月21日：セキュリティ勧告と各系列の修正版）
- GitHub Security Advisory GHSA-w8hw-w9fx-j79w（CVE-2026-109618）
- GitHub Security Advisory GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）
- IPA【事前準備のお願い】PHPのセキュリティリリース公開予定について（2026年10月21日）
- さくらインターネット【重要】PHPの脆弱性に関する当社の対応状況について（2026年10月22日）
- ロリポップ！レンタルサーバー 緊急メンテナンスのお知らせ
著者について
webcan.jp編集部 主筆 K.Takenouchi。Webディレクター・SEOコンサルタントとして10年以上の現場経験を持ち、大手金融系メディアや医療系コーポレートサイトのコンテンツマーケティング支援、ECサイトの企画運営・KPI設計、月商数百万円から月商1億円規模への成長支援などに携わってきました。
