この記事の要約
PHP保守とは、PHPで構築したシステムを安全に動かし続けるための継続的な取り組みです。PHPは毎年新しいバージョンが公開され、各バージョンのサポートは4年で終わるため、「作って終わり」にはできません。本記事では、PHP保守で管理すべき5つのレイヤーと、保守が不十分なときのセキュリティリスクを整理します。そのうえで、リスクを最小化する7つの実践、頻度別の保守カレンダー、重大脆弱性が出たときの72時間の初動、成果を測るKPI、外注先の選び方までを解説します。
PHP保守とは、PHPで構築したシステムを安全に動かし続けるために、パッチ適用・依存ライブラリの更新・脆弱性監視・障害対応・バージョンアップ計画を継続して行うことです。
PHPは、世界のWebサイトで最も多く使われているサーバーサイド言語です。その一方で、サポートが終了した古いバージョンのまま運用されているサイトも少なくありません。
2026年10月の重大脆弱性「PHP2Shell」では、多くの企業が緊急対応に追われました。パッチをすぐ当てられた企業と、どのサーバーで何が動いているかの確認から始めた企業の差は、日頃の保守体制の差です。本記事では、セキュリティリスクを最小化するPHP保守の進め方を、実務の視点で解説します。
1. PHP保守とは？一般的なシステム保守との違い
まずは、PHP保守の範囲と、一般的なシステム保守との違いを確認しましょう。PHPには、保守を継続しなければならない構造的な理由があります。
1-1. PHP保守の定義と主な業務
PHP保守には、大きく分けて次の6つの業務が含まれます。
- パッチ適用：PHP本体のパッチリリース（例：8.4.26→8.4.27）を適用する
- 依存ライブラリの更新：Composerで管理するフレームワークやパッケージを更新する
- 脆弱性監視：新たな脆弱性情報を収集し、自社システムへの影響を判断する
- 障害対応：エラーや性能劣化を検知し、原因を調査して復旧する
- バックアップと復旧：データとソースコードを保全し、復旧手順を整える
- バージョンアップ計画：サポート期限を見据えて、メジャーバージョンの更新を計画する
一般的なシステム保守の考え方は「システム保守とは？必要なスキルや外注する際のポイント」で解説しています。ここからは、PHPならではのポイントに絞って見ていきます。
1-2. PHP保守で管理すべき5つのレイヤー
PHPで動くシステムは、PHP本体だけでなく、いくつもの層が積み重なってできています。PHP保守では、次の5つのレイヤーをそれぞれ管理する必要があります。
| レイヤー | 主な保守内容 | 頻度の目安 | 主な担当（例） |
|---|---|---|---|
| ① PHP本体 | パッチ適用、メジャーバージョンアップ | 月次＋緊急時／数年ごと | インフラ担当、ホスティング事業者 |
| ② OS・Webサーバー・拡張モジュール | OS更新、Nginx・Apache・PHP-FPMの設定と更新 | 月次 | インフラ担当 |
| ③ フレームワーク・CMS | Laravel・CakePHP・WordPressなどの更新 | 月次〜四半期 | 開発会社、保守会社 |
| ④ Composer依存ライブラリ | 脆弱性チェック、バージョン更新 | 週次チェック＋月次更新 | 開発会社、保守会社 |
| ⑤ アプリケーションコード・設定 | 不具合修正、セキュアコーディング、設定の見直し | 随時 | 開発会社、保守会社 |
よくある失敗は、レイヤーごとに担当が分かれているのに、全体を見る人がいないことです。たとえば、ホスティング事業者がPHP本体を更新しても、アプリ側のライブラリは誰も更新していない、という状態が起こりがちです。
1-3. PHPは毎年更新され、サポートは4年で終わる
PHPは毎年11月ごろに新しいバージョンが公開されます。2026年も、PHP 8.6が11月19日にリリース予定です。
各バージョンは、2年間のアクティブサポートと2年間のセキュリティサポートを受け、合計4年でサポートが終了します。つまり、PHPシステムは少なくとも数年に一度、メジャーバージョンの更新が必要になります。直近では、PHP 8.2のセキュリティサポートが2026年12月31日に終了します。詳しくは「PHP 8.2サポート終了への対応｜更新・延命・刷新の判断と移行手順」をご覧ください。
2. PHP保守が不十分なときに起こるセキュリティリスク
では、PHP保守を後回しにすると何が起こるのでしょうか。IPAの「情報セキュリティ10大脅威 2026」でも、組織向けの脅威として「システムの脆弱性を悪用した攻撃」が4位、「サプライチェーンや委託先を狙った攻撃」が2位に挙げられています。ここでは、PHPシステムで起こりやすい5つのリスクを紹介します。
2-1. PHP本体の脆弱性が放置される
INTERNET Watchの記事によると、サーバー側言語が判明しているWebサイトの69.3%がPHPを使用しています（W3Techs、2026年10月時点）。さらに、バージョンが判明しているPHPサイトの半数近くが、サポートの終了したバージョンで動いていると報じられています。
2026年10月には、ログイン不要で遠隔から悪用できる重大脆弱性「PHP2Shell」が公開され、実際の攻撃も確認されました。パッチをすぐ適用できる体制があるかどうかが、被害の有無を分けます。
2-2. 依存ライブラリ経由の脆弱性を見逃す
PHPシステムは、本体だけでなく多くのライブラリに依存しています。フレームワークやComposerパッケージに脆弱性が見つかることも珍しくありません。
同じ記事では、2025年に報告された脆弱性は48,000件を超え、2021年の2.4倍に増えたと紹介されています。人の目だけで追いかけるには、すでに量が多すぎるのが現状です。
2-3. サポート切れのPHPを使い続けてしまう
保守の体制がないと、サポート期限そのものを把握できません。気づいたときには、PHP本体もフレームワークもサポートが終わっている、というケースは少なくありません。
サポート切れのPHPでは、新たな脆弱性に公式の修正版が提供されません。バージョンアップの計画も、PHP保守の重要な業務の一つです。
2-4. 属人化・ブラックボックス化で緊急対応ができない
保守を特定の担当者に任せきりにしていると、その人が退職・異動した時点で対応が止まります。ドキュメントがなく、構成や依存関係を誰も把握していない状態では、緊急時に迅速なパッチ適用はできません。
属人化の解消方法は「システムのブラックボックス化とは？原因と属人化を解く5ステップ」で詳しく紹介しています。
2-5. 「誰が対応するのか」が決まっていない
「サーバーはホスティング事業者、アプリは開発会社、契約は自社」というように担当が分かれていると、PHP2Shellのような緊急時に誰がパッチを当てるのかの確認だけで時間を失いがちです。
特に注意したいのが、PHPのメジャーバージョンアップが保守契約の範囲外になっているケースです。保守契約は「現状維持」を前提にしていることが多く、バージョンアップは別途の改修案件として扱われがちです。
PHPシステムの保守運用、24時間365日の体制で任せませんか？
HBLABのマネージドサービスは、監視・パッチ適用・脆弱性対応・障害対応までをワンストップで提供します。他社が開発したPHPシステムの引き継ぎにも対応します。
3. 脆弱性リスクを最小化するPHP保守の7つの実践
リスクを理解したところで、具体的な対策に移りましょう。PHP保守でセキュリティリスクを最小化するには、次の7つの実践が効果的です。
実践1. PHP資産台帳を整備する
最初に、どのシステムが、どのサーバーで、どのPHPバージョンとフレームワークで動いているかを一覧化します。本番だけでなく、ステージング、バッチサーバー、コンテナも対象です。
台帳には、少なくとも次の項目を記載しておきましょう。
- システム名と公開範囲（インターネット公開か社内のみか）
- PHPのバージョンと入手元（php.net公式、OS同梱、ホスティング提供）
- フレームワーク・CMSとそのバージョン
- 主要な依存ライブラリ
- 各レイヤーの担当者・委託先
台帳がなければ、脆弱性が公開されたときに影響範囲をすぐに判断できません。 依存関係の一覧（SBOM）を作成しておくと、ライブラリの脆弱性にも素早く対応できます。
実践2. パッチ適用のルールとサイクルを決める
次に、PHP本体やライブラリのパッチを定期的に適用するルールを決めます。通常は月次でまとめて適用し、緊急度の高い脆弱性は臨時で対応する、という二段構えが現実的です。
緊急対応の優先度は、次の2つの軸で判断するとよいでしょう。
- 深刻度：遠隔から悪用できるか、ログインが不要か、実際の攻撃が確認されているか
- 公開範囲：インターネットに公開されているか、社内からのみ利用されるか
インターネットに公開され、悪用が確認されている脆弱性は最優先で対応します。
実践3. 依存ライブラリの脆弱性を自動で検知する
Composerの composer audit コマンドを使うと、既知の脆弱性を持つパッケージを検出できます。CIに組み込んで、ビルドのたびに自動でチェックする運用がおすすめです。
あわせて、DependabotやRenovateなどのツールを使うと、ライブラリの更新を自動で提案させることができます。人が気づくのを待つのではなく、仕組みで見逃しを減らすことが重要です。
実践4. 脆弱性情報の収集経路を決める
脆弱性情報は、待っていても届きません。確認する情報源と担当者、確認の頻度を決めておきましょう。主な情報源は次のとおりです。
- php.net：PHP本体のリリース情報とセキュリティ修正
- JVN・IPA・JPCERT/CC：国内向けの脆弱性情報と注意喚起
- フレームワークの公式サイト：LaravelやCakePHPなどのセキュリティアドバイザリ
あわせて、IPAの「安全なウェブサイトの作り方」などを参考に、SQLインジェクションやクロスサイトスクリプティングなど、アプリケーション側の脆弱性対策も定期的に見直しましょう。
実践5. WAF・ログ監視・改ざん検知で攻撃を早期に捉える
パッチを当てるまでの間も、システムを守る仕組みが必要です。次の3つを組み合わせて、攻撃を入口で防ぎ、異常に早く気づける体制を整えます。
- WAF：既知の攻撃パターンを遮断する
- ログ監視：エラーの急増や不審なアクセスを検知する
- ファイル改ざん検知：Webシェルの設置やファイルの書き換えを検知する
夜間・休日のアラートに誰が対応するかも、あらかじめ決めておきましょう。攻撃は業務時間外にも起こります。
実践6. バックアップと復旧訓練を定期的に行う
万が一侵害された場合に備え、データとソースコードのバックアップを取得します。バックアップは、本番環境とは別の場所に保管することが重要です。
復旧手順は、実際に試して初めて機能するかがわかります。 「バックアップはあったが復元できなかった」という事態を防ぐため、定期的にリストア訓練を行いましょう。
実践7. バージョンアップのロードマップを持つ
最後に、サポート期限から逆算して、次のバージョンアップ時期をあらかじめ計画します。PHP本体だけでなく、フレームワークのサポート期限もあわせて管理しましょう。
目安として、サポート終了の1年前には移行の準備に着手すると、検証やテストに十分な時間を確保できます。期限直前の対応は、テスト不足や業務影響の原因になります。
3-8. PHP保守カレンダー：頻度別のタスク一覧
7つの実践を、実行頻度ごとに整理すると次のようになります。自社の保守体制のチェックリストとしてご活用ください。
| 頻度 | 主なタスク |
|---|---|
| 日次 | エラーログ・アラートの確認、WAFの検知状況の確認、バックアップ取得の確認 |
| 週次 | 脆弱性情報の収集、composer audit の実行、不審なアクセスの確認 |
| 月次 | PHP本体・ライブラリのパッチ適用、資産台帳の更新、運用レポートの作成 |
| 四半期 | フレームワーク・CMSの更新、アカウントと権限の棚卸し、運用レビュー |
| 年次 | サポート期限の確認、メジャーバージョンアップの計画、リストア訓練 |
| 緊急時 | 重大脆弱性の影響調査、パッチ適用または暫定策、侵害調査 |
4. 重大な脆弱性が公表されたときの初動フロー（72時間）
日頃の保守がどれだけ整っていても、PHP2Shellのような重大脆弱性は突然公表されます。ここでは、公表から72時間で行うべき初動を時系列で整理します。
4-1. 0〜24時間：影響を確認し、優先度を決める
まずは、脆弱性の内容と、自社システムへの影響を確認します。
- 影響を受けるバージョンと、悪用が確認されているかを確認する
- 資産台帳から、該当するシステムを特定する
- 公開範囲と深刻度から、対応の優先順位を決める
- 対応の責任者と、関係者（ホスティング事業者・開発会社）への連絡を行う
4-2. 24〜48時間：パッチを適用する、または暫定策を講じる
次に、優先度の高いシステムから対応します。修正版がある場合は、検証環境で確認したうえで本番に適用します。
すぐにパッチを適用できない場合は、WAFによる遮断、アクセス制限、一時的なサービス停止などの暫定策でリスクを下げます。
4-3. 48〜72時間：侵害の有無を調査し、記録・報告する
パッチを適用しても、それ以前に侵入されていれば被害は続きます。ログの確認、Webシェルや改ざんファイルの調査を行い、必要に応じてAPIキーやデータベースのパスワードなどの認証情報を変更します。
最後に、対応内容を記録し、経営層に報告します。個人データの漏えいが疑われる場合は、個人情報保護委員会への報告が必要かどうかも確認しましょう。侵害調査の具体的な手順は「PHP2Shellとは？影響の確認方法と今すぐ取るべき対策・侵害調査手順」で解説しています。
72時間はあくまで目安です。悪用が確認されている脆弱性では、さらに短い時間での対応が求められます。
5. PHP保守の成果を測る6つのKPI
PHP保守は「何も起きないこと」が成果になるため、取り組みの効果が見えにくい業務です。次のようなKPIを設定しておくと、保守の状態を客観的に把握し、経営層にも説明しやすくなります。
| KPI | 内容 | 目標の例 |
|---|---|---|
| パッチ適用リードタイム | 修正版の公開から本番適用までの日数 | 緊急時は72時間以内、通常は30日以内 |
| EOLバージョンの稼働数 | サポート切れのPHP・フレームワークで動くシステムの数 | 0件 |
| 未対応の脆弱性アラート数 | composer audit などで検出され、未対応の件数 |
深刻度「高」は0件 |
| MTTR（平均復旧時間） | 障害の検知から復旧までの平均時間 | 前四半期より短縮 |
| 重大インシデント件数 | 業務に影響した障害・セキュリティ事故の件数 | 減少傾向を維持 |
| 復旧テストの成功率 | バックアップからのリストア訓練の成功率 | 100% |
目標値は一例です。システムの重要度や体制に合わせて設定してください。
これらのKPIを月次の運用レポートで追いかけると、保守にかけた費用が、どのようにリスク低減につながっているかを示しやすくなります。
6. 社内対応か外注か：PHP保守体制の選び方
7つの実践を、すべて社内でまかなうのは簡単ではありません。ここでは、社内対応の難しさと、外注する際のポイントを整理します。
6-1. 社内だけで保守を続ける3つの難しさ
社内でPHP保守を行う場合、次のような課題に直面しがちです。
- 人材の確保：PHPに加え、インフラとセキュリティの知識を持つ人材は限られています。
- 24時間対応：夜間・休日の障害や緊急パッチに対応する体制を組むのが難しくなります。
- 新規開発との両立：保守に工数を取られ、新しい施策やDXに手が回らなくなります。
特に、Web担当者や情報システム担当者が1人、という企業ほど負担が集中します。担当者が不在のときに重大脆弱性が出れば、対応は止まってしまいます。
6-2. PHP保守を外注するときの7つのチェックポイント
こうした課題を解決する手段が、保守運用の外注です。委託先を選ぶ際は、次の7点を確認しましょう。
- 対応範囲：5つのレイヤーのうち、どこまでを対象にするか
- 対応時間とSLA：24時間365日対応か、初動や復旧の目標時間が明確か
- バージョンアップの扱い：PHPやフレームワークのバージョンアップが、契約に含まれるか、別見積もりか
- 引き継ぎ実績：他社が開発したPHPシステムを引き継いだ実績があるか
- セキュリティ体制：ISO/IEC 27001などの認証や、脆弱性診断・ペネトレーションテストの体制があるか
- 報告の透明性：月次レポートや運用レビューで、状況とKPIを共有してくれるか
- 費用モデル：固定の月額か、チケット制か、作業時間による精算か
外注の進め方全般は「システムの運用保守とは？外注する際のポイント」もあわせてご覧ください。
6-3. 保守費用を左右する要因と契約形態
PHP保守の費用は、主に次の要因で変わります。
- システムの規模と数：サーバー台数、アプリケーションの数、コードの規模
- 対応時間：平日日中のみか、24時間365日か
- 対応範囲：監視と障害対応のみか、パッチ適用や改修まで含むか
- システムの状態：PHPやフレームワークが古いほど、調査や対応の工数が増える
- ドキュメントの有無：設計書や運用手順書がなければ、最初に整備が必要
契約形態は、作業量が読みにくい場合はチケット制、改修が多い場合は作業時間による精算（Time & Material）、継続的に一定の作業がある場合は専任チーム、というように、運用の実態に合わせて選ぶのがおすすめです。
6-4. 保守を引き継ぐときに準備しておく情報
保守会社を変更する、または初めて外注する場合は、次の情報を準備しておくとスムーズに引き継げます。
- ☐ ソースコードと、リポジトリへのアクセス権
- ☐ サーバー・クラウドの構成と、管理者権限
- ☐ PHP資産台帳（なければ、引き継ぎの中で作成）
- ☐ 設計書・運用手順書（あれば）
- ☐ 過去の障害履歴と、対応記録
- ☐ ホスティング事業者や外部サービスとの契約内容
情報がそろっていなくても、引き継ぎは可能です。 ソースコード解析や現行環境の調査から、ドキュメントを整備するところから始められます。
7. HBLABのマネージドサービスによるPHP保守
HBLABのマネージドサービスは、ここまで紹介した7つの実践を、オンサイトとオフショアの連携でまとめて提供します。
- 24時間365日の監視と障害対応：ITIL 4に基づく運用プロセスで、夜間・休日のインシデントにも対応します。
- 情報セキュリティ対策：脆弱性検出、セキュリティ評価、ペネトレーションテスト、コンプライアンス監視まで対応します。
- AIを活用した運用：AIコードレビューでセキュリティ上の問題を自動検出し、AIによるインシデント対応で平均復旧時間（MTTR）を73%削減した実績があります。
- 柔軟な契約形態：チケット制、Time & Material、専任チームの3つから選べます。国内MSPと比べて約35%のコスト最適化を実現しています。
- 3つの提供パターン：開発から保守までの一貫対応、既存業務の引き継ぎ、オフショア拠点との共同開発・運用に対応します。
7-1. HBLABの保守運用の実績
HBLABは、さまざまな業界のシステムで保守運用を担当しています。
- 労務管理システムの開発・運用（AWS・Java・PHP）：日本の労働法対応を支えるシステムで、保守、既存機能の改善、新機能の開発を継続して担当しています。コミットメントの遵守率100%を維持しています。
- グローバル見積もりシステムの保守引き継ぎ：社内体制の縮小と属人化が課題だったシステムを、1か月のナレッジトランスファーで引き継ぎました。ITILに準拠した24時間体制を整え、重大インシデントを60%削減し、チケットの平均解決時間を約8時間から2.5時間に短縮しています（.NET・SAP・Salesforce環境）。
ほかの事例は実績ページでご覧いただけます。また、PHP2Shellの影響調査には「PHP2Shellアセスメントサービス」、古いPHPシステムの刷新には「モダナイゼーションサービス」もご用意しています。
PHP保守の見直し、まずは現状のご相談から
「保守担当が不在になった」「脆弱性対応が追いつかない」「他社が開発したPHPシステムを引き継いでほしい」など、どの段階からでもご相談いただけます。
8. PHP保守に関するよくある質問
PHP保守の費用はどのくらいかかりますか？
システムの規模、対応時間（平日日中のみか24時間365日か）、対応範囲によって大きく変わります。HBLABでは、チケット制・Time & Material・専任チームから、運用の実態に合った形態をご提案します。まずは現状をお聞かせください。
他社が開発したPHPシステムでも保守を依頼できますか？
はい、対応可能です。ナレッジトランスファーの期間を設け、ソースコードと現行環境を調査して全体像を把握したうえで、保守運用を引き継ぎます。
保守契約にPHPのバージョンアップは含まれますか？
契約によって異なります。一般的な保守契約は現状維持が前提で、メジャーバージョンアップは別途の改修として扱われることが多いため、契約前に必ず範囲を確認しましょう。HBLABでは、保守の中でサポート期限を管理し、バージョンアップの計画からご提案します。
レンタルサーバーを使っていればPHP保守は不要ですか？
不要ではありません。PHP本体の更新は事業者が行う場合もありますが、フレームワークやライブラリ、アプリケーションの脆弱性対応、PHPのバージョン変更への追従は利用者側の責任です。
小規模なWebサイトでも保守は必要ですか？
必要です。攻撃者は規模に関係なく、脆弱なサイトを自動で探して攻撃します。小規模なサイトでも、少なくともパッチ適用、バックアップ、ログの確認は継続して行いましょう。
まとめ
PHPは毎年新しいバージョンが公開され、サポートは4年で終わるため、継続的な保守が欠かせません。5つのレイヤーを意識しながら、資産台帳の整備、パッチ適用のルール化、依存ライブラリの自動チェック、情報収集、監視、バックアップ、バージョンアップ計画の7つを実践することで、セキュリティリスクを最小化できます。社内での対応が難しい場合は、24時間365日対応できる外部パートナーの活用も有効です。脆弱性が増え続ける今こそ、PHP保守の体制を見直しましょう。
