「PHPのバージョンアップが必要です」と言われたら？放置するリスクと見積もり金額が決まる仕組み
目次
【AIによる要約】
– PHPのサポートが切れるとセキュリティ修正が止まり、脆弱性を突かれて改ざん・情報漏洩・メール送信不能などの事故につながります。
– 利用中のPHPバージョンがセキュリティサポート期間内かどうかが最初の確認ポイント。
– 見積もり金額は「PHPだけの作業」ではなく一連の工程に対するもの。特に「テスト環境での検証」が含まれているかが妥当性を見極めるポイントです。
「お使いのサイトはPHPのバージョンが古いため、アップグレード作業が必要です。お見積りをお送りしますのでご確認ください。」
普段お世話になっている保守会社や制作会社から、突然このような連絡を受けた担当者様・経営者様は少なくありません。そして多くの場合、次のような疑問と不安が同時に湧いてくるのではないでしょうか。
- 「そもそもPHPのバージョンアップって何のために必要なの？」
- 「今ちゃんと動いているのに、やらなくてもいいのでは？」
- 「数十万円の見積もりって、妥当な金額なの？」
私たちカジヤは、業界歴10年以上・300社を超える企業のWebサイトやWebシステムの構築・保守に携わってきました。その現場で「PHPのバージョンアップを先送りにした結果、事故に発展したケース」と「適切なタイミングで対応して安全に延命できたケース」の両方を、実際に何度も見てきました。
この記事では、技術的な背景がなくても理解できるよう、①放置すると何が起きるのか、②なぜ費用がかかるのか（作業の裏側）、③見積もりの妥当性をどう見極めるかを解説します。社内で説明したり、見積もりを評価したりする際の判断材料としてお使いください。
1. PHPのバージョンアップとは？なぜ必要なのか
PHPは、WordPressやEC-CUBEなど、多くの企業サイトの土台となっているプログラミング言語です。サイトそのものはHTMLとして表示されていても、その裏側ではPHPが動いています。
PHPには、いわば「製品の保証期間」があります。PHPプロジェクト公式は、各バージョンについてアクティブサポート→セキュリティサポート→サポート終了（EOL）というスケジュールを公開しており、EOLに達したバージョンはセキュリティ修正すら提供されなくなります。
出典：php.net 公式のサポート期間一覧（PHP: Supported Versions）
保守会社から「バージョンアップが必要です」と言われるのは、主に次の2つのケースです。
- サーバー会社がPHPの提供を終了する：レンタルサーバー各社は古いPHPの提供を順次終了します。終了後はサイトそのものが動かなくなるため、移行が必須になります。
- 利用中のPHPがEOL（サポート終了）に近い、または到達した：セキュリティリスクの観点から、計画的な移行を提案するものです。
つまりこれは「営業トーク」ではなく、土台の部品の保証期限が切れようとしているという事実のお知らせです。
2. 放置すると何が起きるのか？現場で見てきた4つのリスク
「今動いているから大丈夫」というのが、最も危険な判断です。私たちの現場で実際に目にしてきたリスクを挙げます。
リスク1：セキュリティ修正が止まり、攻撃の的になる
EOL後のPHPには、発見された脆弱性（セキュリティの穴）への修正が一切提供されません。攻撃者は古いバージョンの脆弱性情報を利用して機械的に攻撃を仕掛けてくるため、「鍵の壊れた金庫」が住所付きで公開されている状態と同じです。
改ざん被害を受ければ、サイトの表示が書き換えられるだけでなく、訪問者を詐欺サイトへ誘導する不正スクリプトを埋め込まれる、問い合わせデータが漏洩するといった二次被害につながります。政府の情報セキュリティ関連の注意喚起でも、古いソフトウェアの利用継続が改ざん被害の主要因として繰り返し指摘されています。
出典：IPA 情報セキュリティ（独立行政法人情報処理推進機構）
リスク2：ある日突然、サイトが動かなくなる
レンタルサーバー会社が古いPHPの提供を終了すると、何もしていないのにサイトがエラーで表示されなくなることがあります。コンビニエンスストアで言えば、静かに「この商品は販売終了です」と棚から消えているのではなく、店ごと突然シャッターが下りるイメージです。
ECサイトでこれが起きたら、ダウンした時間帯の売上は取り返しがつきません。私たち自身も日本酒ラボやSAKE CABINETなど複数のWebサービス・EC事業を運営しており、サイトが1日落ちることの機会損失の重さは、支援する側である前に当事者として身にしみてわかっています。
リスク3：対応可能な業者が減り、費用が高くなる
古いPHPが動く環境に詳しいエンジニアは年々減っています。放置するほど「対応できる業者」と「即日対応できる技術者」が減り、結果として急ぎ対応の割増料金を払うことになりがちです。「今やれば定額で済む作業」が「緊急対応の高額案件」に変わるのが、先送りの代償です。
リスク4：メール送信や決済など、周辺機能の連鎖停止
古いPHP環境では、決済モジュールや配送会社の連携APIなど外部サービスのライブラリが対応できなくなり、「サイトは表示されるのに、決済だけ失敗する」「注文通知メールだけ届かない」といった分かりにくい障害が発生します。顧客からの指摘で初めて気づくケースも多く、信用を失ってから気づくのが最も痛いパターンです。
3. なぜ「ボタン一つ」ではないのか？見積もり金額が決まる仕組み
「バージョンアップって設定を変えるだけでは？」——多くの方がそう思われるのは自然なことです。実際、サーバーの管理画面でPHPのバージョンを切り替える操作自体は、数分で終わります。
では、なぜ数十万円単位の見積もりになるのか。それは、切り替えの前後に必須となる工程が存在するからです。保守会社の見積もりに書かれている工程の「中身」を解説します。
工程1：現状調査（何が壊れる可能性があるかの洗い出し）
まず、サイトを構成するプログラム（WordPress本体、テーマ、プラグイン、独自に書かれたコード）が、新しいPHPで動作するかを調査します。PHPはバージョンが上がると「古い書き方」が使えなくなるため、昔に作ったサイトほど非互換（動かなくなる箇所）が見つかる傾向があります。この調査あってこそ、見積もり金額に根拠が生まれます。
工程2：非互換コードの改修
調査で見つかった古い書き方を、新しいPHPでも動く書き方に修正します。テーマやプラグインの範囲で済めば軽微ですが、過去に独自開発された部分があるとここが工数の中心になります。ここの分量が見積もりの差額として現れます。
工程3：テスト環境での検証（最重要）
改修後、本番環境とは別のテスト環境（ステージング）を用意し、実際に新しいPHPで動かして確認します。トップページの表示だけでなく、問い合わせフォームの送信、会員登録、ECであれば商品購入から決済まで、ユーザーが使うすべての導線を機械ではなく実機で確認します。
工程4：本番反映と実機テスト
計画的な日時（多くはアクセスの少ない夜間や早朝）に本番へ反映し、反映後にもう一度主要導線を実機でテストします。問題があれば元に戻す（ロールバックする）準備も済ませておきます。
つまり見積もり金額とは、「設定変更」という数分の作業ではなく、調査・改修・検証・反映・テストという一連の品質担保工程への対価です。
4. 見積もりの妥当性を見極めるチェックリスト
前工程を踏まえると、見積もりの良し悪しはある程度機械的に判断できます。社内で検討する際に、次の項目を確認してください。
- テスト環境（ステージング）の利用が工程に含まれているか
含まれていない場合、本番環境で直接改修する可能性が高く、最も避けるべき見積もりです。テスト環境の準備にはサーバー費用と工数がかかるため、あえて省いて安く見せる業者が存在します。詳細は後述します。 - 現状調査（影響範囲の調査）の費用が明記されているか
調査なしに一括金額だけ提示される場合は、改修範囲の根拠が不明瞭です。「調査後に正確な金額をご提示する」方式はむしろ誠実です。 - 改修対象（テーマ・プラグイン・独自コードのどれか）が特定されているか
「全体」でなく「どこを直すのか」が書かれているか。 - 反映後の実機テスト（フォーム送信・購入テストなど）が含まれるか
「反映」で終わっている見積もりは、事故の温床になります。 - 万が一に備えたバックアップと切り戻し（ロールバック）計画があるか
- 事前に新PHPでの動作確認が可能か（確認用URLの提供など）
逆に言えば、テスト環境での検証と反映後テストが明記されている見積もりは、金額が高めでも誠実です。工程の中身が透明であることの方が、表面的な金額より重要です。
5. 【持論】安さの裏側——なぜ「本番で直接いじる」業者が存在するのか
ここで一つ、業界の裏側についてお話しします。
PHPバージョンアップの作業を「テスト環境なし・検証なし」で行えば、工数は大幅に削減でき、見積もりは半分以下にできます。格安の見積もりの中には、構造的にこの方式しかあり得ないものが存在します。
作業は正味数時間で終わりますが、問題は「動作確認をしていない状態が本番に流れる」ことです。フォームが壊れたまま数週間気づかれない、決済だけ失敗して注文が途絶える——そうした事故は、削った工数のコストをはるかに上回る損害として跳ね返ってきます。
当社の基準をはっきり言います。「テスト環境での検証」を省略したPHPバージョンアップは、たとえ金額が魅力的でも受けるべきではありません。 当社自身、300社以上の支援と自社事業運営の中で、検証工程を省いた改修が後々どれだけ高くつくかを数え切れないほど見てきました。金額の妥当性を判断する最短の質問は、「テスト環境で検証しますか？」の一言です。
6. 対応の目安と、放置する場合の最低限の工夫
- EOLが近い／サーバーから終了通知が来た場合：計画的な対応を開始すべきタイミングです。繁忙期を避け、1〜2ヶ月程度のリードタイムを持って進めましょう。
- まだサポート期間内だが通知が来た場合：急ぐ必要はありませんが、「いつまでに対応するか」を社内で決めて記録に残すことをおすすめします。先送りの記録は残らず、対応の記録だけが残りがちだからです。
どうしても予算確保に時間がかかる場合は、以下を最低ラインとして保守会社と相談してください。
- サーバー会社のEOL日程を確認し、カレンダーに登録する（日程は動かせません）
- バックアップ体制の確認（復旧できる状態を維持する）
- 死活監視の導入（サイトの異常に早く気づく仕組み）
- 決済・フォームの動作を定期的にテストする（連鎖停止の早期発見）
まとめ：迷ったら「期限」と「テスト環境」の2点だけ確認する
- PHPのバージョンアップ通知は営業ではなく、土台の保証期限の事実連絡。EOL後はセキュリティ修正すら止まる。
- 放置すると、改ざん・突然の停止・対応業者の減少・周辺機能の連鎖停止という現実的なリスクを抱えることになる。
- 見積もり金額は「調査→改修→テスト環境での検証→本番反映→実機テスト」という品質担保工程への対価。ボタン一つの作業ではない。
- 妥当性を見るポイントは、テスト環境の有無・調査の明記・反映後テスト・切り戻し計画。特に「テスト環境なし」の格安案は避けるべき。
「見積もりが高いのか安いのか分からない」「そもそも自社のPHPバージョンがいくつなのか分からない」という場合は、まず現状だけでも把握しておくことをおすすめします。
当社カジヤでは、代理店を挟まず社内の専任エンジニアが直接対応するWebサイト保守管理サービスを提供しています。PHPのバージョンアップだけでなく、日常の更新からセキュリティ対策まで一貫して支援しており、「本当にその作業が必要か」も含めて正直にご提案することを大切にしています。見積もりの評価に迷っている段階でも、お気軽にお問い合わせフォームからご相談ください。
