こんにちは、大平です。
2026年10月21日に公開されたPHPの重大な脆弱性は、総理大臣がXで「大至急のお願い」としてアップデートを呼びかけるところまで話が広がりました。 僕がこのニュースを見て最初に思ったのは、技術的な話ではありません。 「保守契約を結んでいないのに、作ったベンダーに『直してくれ』と頼む発注者が、これから大量に出てくる」ということでした。
実際に蓋を開けてみると、その数は想像以上でした。 そして、その多くは断られるか、相場の何倍もの見積を受け取ることになります。
この記事では、なぜそうなるのかを、作る側の論理として説明します。 保守料は人件費ではなく、保険料です。保険は、事故が起きてから入ることはできません。
「PHPのバージョンが古いだけ」が、いま致命傷になる理由
今回の脆弱性は、認証なしでリモートからコードを実行できる種類のものです。 IPAが事前にセキュリティリリースの予告を出し、修正版はPHP 8.5.12、8.4.27、8.3.36、8.2.35として公開されました。 公開翌日には攻撃の試みが観測され、国内の大手サービスでも緊急メンテナンスやサービス停止が起きています。
ここで決裁者に見てほしい点は二つあります。
一つは、修正版が出たのがサポート中のバージョンだけだということです。 PHP 8.1以前で動いているサイトには、公式の修正版がありません。 バージョンを上げること自体が、前提の作業になります（サポート終了が何を意味するかはレガシーシステムの判定基準にまとめています）。
もう一つは、攻撃側の速度です。 AIの普及には負の側面があり、脆弱性の公開から攻撃コードが出回るまでの時間は明確に短くなっています。 数年前なら「来月の定例で対応しましょう」で間に合った更新が、いまは当日中の対応を求められます。
つまり、情報資産を持つ側に求められているのは「脆弱性が出たら即日で当てられる体制」です。 全員がエンジニアになれるわけではないので、その体制はたいてい外部のベンダーとの契約で用意することになります。 その契約が、保守契約です。
保守契約がない発注者は、ベンダーから見れば一見さんと同じ
コーポレートサイトの保守料として月3万円を提示すると、「高い」と言われることがよくあります。 発注者側の論理は明快で、「安定して動いているのに、なぜ毎月人件費を払うのか」というものです。 この感覚は理解できますし、保守契約を結ばないお客さんが多いのも事実です。
作る側としては、納品したあともお客さんのビジネスを支え続けたいと思っています。 ただ、僕らはボランティアではなく、事業としてやっています。 契約がなければ、人を割り当てる根拠がありません。
だから発注側の方には、はっきりこう心得ておいてほしいのです。 保守契約のないお客さんは、数年前に大きな発注をしていても、初めて問い合わせてきた一見さんと同じ扱いになります。 これは冷たい話ではなく、ベンダーの中で何が起きているかを正直に言っているだけです。 担当者は別の契約先の仕事を抱えていて、空いた枠を売る相手を選ぶ立場にあります。
ベンダーの見積は作業量ではなく「リスク」で決まる
保守料を保険料として見ると、値付けの仕組みも見えてきます。 保険会社は、加入者のリスクを計算して料率を決めます。 ソフトウェアの保守も同じで、市場価格があるわけではなく、ベンダーが引き受けるリスクの大きさで値段が決まります。
事故が起きてからスポットで依頼した場合、次の三つが同時に値段を押し上げます。
- 放置年数：PHPのバージョンを一つ上げるだけでは済まず、何年分の変更を一度に当てて、動く状態まで持っていく必要があります。すでにマルウェアが入っている可能性もあり、調査から始まります
- 緊急度：今すぐ対応してほしいという依頼は、別の契約先の予定をずらして人を出すことになります。その分の対価が乗ります
- 関係値：相手がどういうお客さんか分からないこと自体がリスクです。事故が起きてから初めて連絡してくる相手は、要求が過大で、支払いも揉めやすいというのが現場の経験則です
この三つが揃うと、通常の保守料の数倍の見積になるのは自然なことです。 ぼったくりではありません。 リスクの見積がそのまま値段になっているだけです。
「過去にさかのぼって」保守料を支払う必要があるケースもある
保守料が保険料であることを、もっと徹底しているのが大手ソフトウェアベンダーの保守ポリシーです。
大手の商用データベースや業務パッケージでは、保守契約を一度切ってから再加入しようとすると、切っていた期間の保守料をさかのぼって請求されるのが一般的です。 未加入期間のバックサポート料に加えて再加入料が上乗せされ、通常の更新より数倍の費用になるケースもあります。 切っていた期間に一度もサポートを使っていなくても、使っていたものとして計算されます。
これを「ひどい」と感じる方は多いと思いますが、保険の論理では一貫しています。 健康なときに保険料を払う人がいるからこそ、事故が起きた人を支える原資ができます。 事故が起きそうなときだけ加入して、収まったら解約する人ばかりになれば、仕組みそのものが成り立ちません。
中小のWeb制作会社やシステム開発会社は、大手ベンダーのように厳格なポリシーを明文化していないだけです。 明文化していない分、個別の見積という形で同じ判断が現れます。
事故が起きてから入れる保険はない。待っているのは拒否
スポット対応を頼んで高い見積が来るのは、まだ良いほうです。 実際には、見積すら出てこないケースが珍しくありません。
今回のPHP脆弱性のような全国規模の事故では、ベンダーの手は契約先の対応で埋まります。 契約先を後回しにして一見さんを優先する理由は、どこにもありません。 断られるか、「来月以降なら」と言われて、その間サイトは無防備なままになります。
発注者側の責任感の問題ではなく、構造の問題です。 数年前に大きな予算で作ってもらったという事実は、担当者の頭の中には残っていても、契約の優先順位には反映されません。
保守料を払い続けるか、切るか。決裁者が判断すべきこと
最後に、決裁者として判断すべきことを順に書いておきます。
まず、自社のシステムで「事故が起きたときに自分たちで修正できるか」を確認してください。 社内に手を動かせるエンジニアがいて、脆弱性情報を自分で追い、当日中に更新できるなら、保守契約は必須ではありません。 自己責任で引き受けられるものに保険をかける必要はないからです。
次に、それができないシステムについては、保守契約を「人件費」ではなく「保険料」として予算に入れ直してください。 月3万円が高いかどうかは、「サイトが止まったとき、あるいは改ざんされたときに失うもの」と比べて判断することです。 人件費と比べるから高く見えます。
そのうえで、すでに契約を切っているシステムがあるなら、事故が起きる前に関係値を作り直してください。 平時に結ぶ保守契約と、事故後にスポットで頼む対応では、同じ作業でも値段が数倍違います。 いま何も起きていないことが、いちばん安く入り直せる条件です。
今回の騒動を機に、保守料に対する世の中の見方が少し変わればいいと思っています。 保守料は、何も起きていない月に払うものです。 何か起きた月には、もう売っていません。
まとめ
- 保守料は人件費ではなく保険料：安定稼働している月に払うことで、事故の月に即日対応を受けられます
- 契約がなければ一見さん：過去の発注実績は、ベンダーの優先順位に反映されません
- 値段はリスクで決まる：放置年数、緊急度、関係値の三つが揃うと、通常の数倍になるのが自然です
- 事故後の加入は遅い：高い見積が来るのはまだ良いほうで、拒否されるケースが現実に増えています
自社のシステムについて「自分たちで直せるか」を一度確認し、直せないものには事故が起きる前に保険をかけてください。