第１ 本記事の対象と結論
１ 対象と基準日
令和８年１０月２１日，PHPの開発チームは，認証を受けていない第三者による遠隔コード実行につながり得る二つの重大な脆弱性（CVE-2026-109618及びCVE-2026-109619）を修正した版を公開した。
本記事は，ウェブサイトを発注した事業者と，制作会社・保守会社との間で，PHPの更新や脆弱性への対応を誰が行う義務を負うか，放置して侵害された場合に損害賠償責任や責任制限条項がどう扱われるかを，民法，裁判例及び情報処理推進機構（IPA）と経済産業省のモデル契約から整理するものである。
基準日は令和８年１０月２３日である。
民法の条文はe-Gov法令検索で現行の版を確認し，裁判例は裁判所ウェブサイトの裁判例検索に掲載された判決の全文で確認した。
修正版への更新の手順は，PHPの緊急セキュリティ更新とWordPress保守―法律・税理士事務所の確認，バックアップ，互換性試験及び復旧手順で扱っている。
２ 結論
①制作会社・保守会社がPHPの更新をする義務を負うかは，契約書だけでなく，提案書・仕様書・保守の手引書等を含めた合意の内容で決まる。
②前橋地裁令和５年２月１７日判決は，構築を受託した会社がファイアウォールを全ての通信を許可する設定のまま引き渡したことを債務不履行とし，責任を契約金額までに限る条項は重過失があるときは適用されないとして，約１億４３００万円の賠償を命じた。
③他方，同じ判決は，保守契約に基づく修正の義務については，契約や保守手引書を見てもその修正が保守契約の対象かどうか判然としないとして，債務不履行を認めなかった。
保守契約があるだけで，PHPの更新まで当然に保守会社の義務になるとはいえない。
④東京地裁令和５年２月２７日判決（ベネッセの個人情報漏えい）は，システムの保守・運用を担う会社に，技術の進歩に伴って新たに生じた脆弱性に対応して設定を見直す注意義務を認めた。
⑤PHPの公式発表が直ちの更新を求めた今回のような場面で，更新が保守の範囲に入っていながら放置した場合は，重過失として責任制限条項が働かないと判断される可能性がある，と本記事では考える。
⑥発注者は，保守の範囲（ミドルウェアの更新，脆弱性情報の収集と対応，サポート終了版の移行）と対応の期限を契約で具体的に定めておく必要がある。
第２ 前提となるPHPのサポート期間と今回の修正
PHP公式の「Supported Versions」によれば，各系列は最初の安定版の公開から２年間は全面的にサポートされ，その後の２年間は重大なセキュリティ問題についてだけサポートされ，合計４年でサポートが終了する。
令和８年１０月２２日時点の表では，8.2のセキュリティサポートは２０２６年１２月３１日まで，8.3は２０２７年１２月３１日まで，8.4は２０２８年１２月３１日まで，8.5は２０２９年１２月３１日までとされている。
8.1は２０２５年１２月３１日にサポートが終了し，最終版は8.1.34である。
今回の修正版は，8.5.12，8.4.27，8.3.36及び8.2.35である。
PHP公式は，8.1以前はPHPプロジェクトからの更新を受けないとしつつ，今回は深刻さに鑑みて，ソースから構築する利用者等のために7.4，8.0及び8.1への最小限の修正を示した。
また，Linuxのディストリビューションや長期サポートを提供する事業者の中には，修正を取り込んだ独自の版を提供するものがある。
サポートの終了した版のPHPを使っているサイトでは，今回の修正を当てるだけでなく，サポート対象の版へ移行する作業が必要になる。
PHP Foundationが１０月２１日に公表した報告によれば，Linuxのディストリビューションや長期サポートを提供する事業者は，利用者が速やかに更新できるよう，修正を事前に受け取っていた。
他方で，同じ報告は，Chainguardが協調公開の６時間以上前に，公開前の情報の取扱いの取決め（エンバーゴ）を一方的に破って修正を含むイメージを公開したとしている。
保守を委託する側から見ると，委託先が脆弱性の情報を事前に受け取れる立場にあるか，受け取った情報をいつ，どの範囲で使えるかによって，対応を始められる時刻が変わる。
そのため，保守契約や秘密保持の取決めでは，事前通知の受領と利用の範囲，早期の公開を認める例外の条件及びその場合の通知の方法を，あらかじめ明文で定めておくことが望ましいと考えられる。
【令和８年１０月２４日追記】PHP公式の１０月２３日付追加告知には，特定のセッション設定とコードの組合せについての注意もある。
保守の範囲や対応期限を検討するときは，版番号だけで完了とせず，対象環境の条件とその後の公式情報も確認する。
第３ 制作・保守の契約の性質
１ 請負と準委任
民法６３２条は，請負を，当事者の一方がある仕事を完成することを約し，相手方がその仕事の結果に対して報酬を支払うことを約する契約としている。
サイトの制作のように成果物を納める契約は，請負に当たることが多い。
保守は，内容によって請負又は準委任になる。
準委任には委任の規定が準用され（民法６５６条），受任者は「委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う。」（同法６４４条）。
債務の本旨に従った履行をしないときは，債務者の責めに帰することができない事由によるものでない限り，損害賠償の責任を負う（同法４１５条１項）。
２ IPA・経済産業省のモデル契約
IPAと経済産業省の「情報システム・モデル取引・契約書」〈第二版〉の保守運用のモデル契約は，保守運用の業務が準委任型か請負型かを個別契約で定めることとし，準委任型では善良な管理者の注意をもって業務を行う責任に限られ，請負型では業務の結果の誤りや仕様書との不一致を修正する責任を負うとしている（１４条）。
同モデル契約は，個別契約で定める事項として，契約形態，業務内容，対象とする情報システムの範囲，甲乙の役割分担等を挙げている（３条）。
つまり，PHPの更新が保守の業務に入るかどうかは，個別契約と業務仕様書の書き方で決まる構造になっている。
第４ 前橋地裁令和５年２月１７日判決
１ 事案
前橋地裁令和５年２月１７日判決（令和２年（ワ）第１４５号）は，前橋市が，市の教育情報ネットワークのデータセンターの移管設計・構築を委託した会社に損害賠償を求めた事件である。
受託した会社は，外部と内部のファイアウォールを，それぞれ全ての通信を許可する設定のまま市に引き渡していた。
判決によれば，市が設けた委員会の検証報告書は，不正アクセスの原因を，教育資料公開サーバの脆弱性の放置とファイアウォールの設定の不備にあると判断していた。
市と会社の間には，構築の委託契約とは別に，５年間の保守契約もあった。
２ 債務の内容の決め方
判決は，ソフトウェアの開発に係る業務委託契約では，提案依頼書，提案書，要件定義書，基本設計書等をやり取りして業務の内容を確定していくものであるから，受託者が負う債務の内容は，契約書の記載だけでなく，前後にやり取りされた要件定義書や基本設計書等の内容を総合的に考慮して確定すべきであるとした。
そのうえで，提案書や基本設計書等にファイアウォールで通信を制限すると書かれていたこと等から，会社はファイアウォールを適切に設定して通信を制限する債務を負っていたと認めた。
会社は，そのような債務は契約書に明示されていない観念的抽象的なものだと主張したが，判決は採用しなかった。
３ 構築時の設定の不備は債務不履行
判決は，全ての通信を許可する設定のまま引き渡したことについて，会社自身も設定が不適切であったことを自認しており，そのように設定したまま引き渡した合理的な理由の主張もないとして，債務不履行を認めた。
また，市と会社の間にはシステムの構築等の専門性に相当の格差があるから，引渡しの時点で不適切な設定について告知・説明していたのでなければ，会社に責めに帰すべき事由がないとはいえないとした。
４ 保守契約上の修正義務は認めなかった
市は，会社が保守契約に基づいて不備を確認し，修正する債務も負っていたと主張した。
判決は，保守手引書の役割分担の表に「セキュリティ対応（脆弱性の緊急対応）」等について会社が「主」と記載されていたことを認定しつつ，市から通信制限の不備を指摘されたのに放置したという点については，保守契約や保守手引書の内容を見ても，その修正が保守契約の対象となっているか判然としないとして，債務不履行又は注意義務違反を直ちには認めなかった。
責任が認められたのは，構築時の設定の不備についてである。
５ 責任制限条項と重過失
委託契約１７条は，損害賠償を「契約金額を限度として現実に生じた通常の直接損害」に限っていた。
判決は，このような条項は，開発に関連する損害が想定外に多額に上るおそれがあることから賠償額を契約金額の範囲に制限するもので一定の合理性があるとしつつ，故意又は重過失がある場合にまで賠償義務の範囲が制限されることは「著しく衡平を害するものであり、当事者の通常の意思に合致していないというべきである」として，故意又は重過失がある場合には適用されないと解した。
重過失の当てはめでは，提案書や基本設計書等でファイアウォールによるアクセス制限を複数回にわたって確認していたのに，不適切な設定のまま引き渡したことは「単純かつ明白なミス」であり，会社が情報セキュリティについて高度な専門的知見を有していることを併せ考えると，少なくとも重過失があることは明らかであるとした。
６ 損害の範囲
判決は，インシデント対応の手順（検知，分析，初動対応と証拠保全，当局対応と情報開示，原因分析と再発防止，事後対応）に当たる対応の費用を，相当と認められる範囲で通常損害とした。
デジタルフォレンジックの委託料，保護者・教職員への通知の郵送料，職員の時間外勤務手当，端末の復旧作業の委託料，ネットワークの再構築の委託料，弁護士費用等が認められ，認容額は１億４２９８万０４４４円であった。
他方，再発防止を主眼とするセキュリティの強化や機能の追加・増強の費用は，不正アクセスの前の状態に戻すために必要なものとはいえないとして否定した。
会社の過失相殺の主張も，原告の過失を認定するに足りる証拠がないとして採用しなかった。
なお，この事件の契約は平成２７年に結ばれており，判決は平成２９年の民法改正の前の規定を適用している。
第５ 東京地裁令和５年２月２７日判決（新たな脆弱性への追従）
東京地裁令和５年２月２７日判決（平成２７年（ワ）第２２３６号ほか）は，ベネッセの顧客情報が，システムの開発・運用の業務に従事していた者によって持ち出された事件の集団訴訟である。
判決は，システムの保守・管理・運用を担う会社（シンフォーム）について，スマートフォンの通信方式の変化に応じてセキュリティソフトの設定を見直す必要がないかを確認し，適切に対応すべき立場にあったとした。
そのうえで，「技術の進歩に伴い新たに生じた脆弱性を認識し対応策を講じるには一定の期間を要するとしても」，対応するスマートフォンの発売から最初の持出しまで約１年半以上が経過していたこと等を考慮し，遅くともその時点までに設定を見直すべき注意義務があったとした。
また，行政機関等のガイドラインに記載がなかったことは，この判断を左右しないとした。
判決は，委託元のベネッセについても，委託先のセキュリティソフトの設定内容を委託先監査の対象としていなかったとして，監督を怠った過失を認め，両社に連帯して１人当たり３３００円の支払を命じた。
発注者の側も，委託先の脆弱性対応の状況を監督しなければ責任を問われ得ることを示している。
第６ 責任制限条項と重過失についてのモデル契約の考え方
IPAと経済産業省のモデル契約〈第二版〉の開発のモデル契約５３条は，損害賠償の累計総額を一定の金額に限る条項（２項）を置いたうえで，その制限は「損害賠償義務者の故意又は重大な過失に基づく場合には適用しないものとする」（３項）としている。
その解説は，故意の場合には判例上免責・責任制限の条項は無効と考えられ，重過失の場合も同様に無効とするのが支配的な考え方であると説明している。
同じモデル契約の５０条（セキュリティ）の解説は，脆弱性について重大な過失によって知らなかったといえるかについて，脆弱性が単に既知であるというだけでは十分ではなく，攻撃が頻発する等して国が広く周知活動を行う等，ベンダに広く知られるものとなっており，加えて，特別な技術や多大なコストを要しない対策が広く知られている等，結果回避が容易な場合には，重過失が認められる余地があるとしている。
もっとも，５０条は開発の契約の条項であり，納入物の検収の後は，別に契約を結ばない限り，ベンダは脆弱性の分析や対策の実施の義務を負わないとしている（５項）。
第７ PHP2Shellの場面への当てはめ
１ 保守契約にPHPの更新や脆弱性対応が含まれている場合
保守契約や業務仕様書に，ミドルウェアの更新，脆弱性情報の収集と対応等が保守の業務として明記されていれば，保守会社は，善良な管理者の注意をもって修正版を適用する義務を負うと考えられる。
今回，PHP公式は全ての利用者に直ちの更新を強く求め，米国・英国の政府機関や国内のJPCERT/CCも注意喚起をし（国家サイバー統括室も注意喚起をしたと報じられている），修正版への更新を中心に，自社の実行環境に応じた対応を検討する必要がある。
モデル契約の解説の考え方に照らすと，こうした周知の後に，正当な理由なく長期間更新を放置した場合は，重過失として責任制限条項が働かないと判断される可能性がある，と本記事では考える。
他方，サイトのテーマやプラグインとの互換性の確認に必要な時間は考慮され得るので，いつ知り，何を確認し，いつ適用したかを記録しておくことが，双方にとって重要になる。
２ 保守の範囲が曖昧な場合
前橋地裁判決は，保守手引書に脆弱性の緊急対応の役割分担が書かれていた事案でも，具体的な修正が保守契約の対象か判然としないとして，保守契約上の債務不履行を認めなかった。
「サイトの保守」「運用サポート」等と書いてあるだけで，PHPの更新まで保守会社の義務になるとは限らない。
もっとも，ベネッセの判決のように，システムの保守・運用を実際に担う会社には，契約の文言とは別に，新たな脆弱性に対応すべき注意義務が問題になる余地がある。
範囲が曖昧なまま事故が起きると，責任の所在をめぐって争いになり，対応が遅れることになる。
東京地裁令和元年１２月２０日判決（平成２９年（ワ）第６２０３号，判例秘書の判例番号 Ｌ０７４３１５５８）も，通販サイトの運営者がサイトの運用等を委託していた事案で，注文書の「サイト運用，保守管理」等の記載からはシステム全体のセキュリティ対策の業務が委託に含まれていたとは解されないとし，脆弱性への対策を講じなかったことを理由とする損害賠償請求を棄却した。
同判決は，委託の主な目的が売上げの向上等のマーケティング施策にあったことや，相見積りの見積書の記載も考慮している。
IPAの「ウェブサイト運営者のための脆弱性対応ガイド」は，外部の事業者に保守業務を委託している場合には，脆弱性対策についても契約に含め，緊急時にも円滑な対応が得られるよう，体制や費用等をあらかじめ合意しておくことが望まれるとしている（９頁）。
３ サポート終了版を使い続けている場合
8.1以前の版のPHPを使っているサイトでは，今回の修正は正式な版としては提供されない。
本記事では，制作の時点でサポート期間内だった版が，その後サポートを終えたことだけで，直ちに制作物の契約不適合になるとはいいにくいと考える。
モデル契約の解説も，検収後のOSのバージョンアップに伴う不具合は契約不適合ではないとされることもあるとし，その後の対応は保守契約で手当てする方が合理的な局面があるとしている。
サポート終了版からの移行は，テーマやプラグインの改修を伴うことがあるので，それが通常の保守の範囲に含まれるのか，別の作業として費用がかかるのかを契約で確かめておく必要がある。
発注者は，移行の要否と費用を，サポート終了の前に保守会社と協議しておくべきである。
４ レンタルサーバーのPHPの場合
共用のレンタルサーバーでは，PHPの本体をサーバー会社が管理し，利用者は管理画面で版を選ぶだけのことが多い。
その場合，修正版の配備はサーバー会社が行い，どの版を選ぶか，古い版から移行するかは利用者又は保守会社の判断になる。
誰が何をするかは，サーバー会社の利用規約と保守契約によるので，一般論で決めることはできない。
５ 障害時の受付，調査及び復旧の分担を具体化する
保守契約の実務では，障害の検知，契約先への連絡，サーバーログの確認，WordPress側の調査及び復旧後の業務機能の確認を，誰が担当するか明らかにしておきたい。
サーバー会社とWeb制作・保守会社が別である場合は，一方に問い合わせたことで他方への連絡も当然に完了するとは扱わず，窓口と引継ぎ方法を定める。
これは障害対応の手順に関する提案であり，個別の事業者にどの義務があるかを契約を確認せずに断定するものではない。
① サイト運営者の確認事項：公開サイト，管理画面及びサーバー管理画面の症状，確認時刻，直前の変更，業務への影響を整理する。
② サーバー会社への照会事項：契約サービスの障害・通信制限の有無，調査状況及び次の状況案内の見込みを確認する。
③ 制作・保守会社への照会事項：契約に含まれる調査範囲，サーバー会社との連絡担当及び復旧後のアプリケーションの確認範囲を確認する。
問い合わせの受付時間，初回回答の目標時間，復旧の目標時間及び稼働率の保証は，別々の項目として契約や案内を読む。
問い合わせ窓口の返信の目安だけから，設備の監視体制や障害対応の時間帯まで推測しない。
また，接続できないという観測結果，調査によって確認された原因及び契約上の責任の評価を区別する。
具体的な症状の整理には，WordPressが開けない・cPanelにも接続できないときの問い合わせ項目を利用できる。
第８ 契約で決めておくこと
①保守の対象（PHP本体，WordPress等のシステム，テーマ，プラグイン，サーバーの設定）と，対象外のもの
②脆弱性情報を収集する者と，重大な脆弱性が公表されたときに対応する期限
③修正版の適用の前に行う互換性の確認とバックアップの担当
④サポート終了版からの移行の扱い（通常の保守か，別の見積もりか）と，終了の何か月前に協議するか
⑤保守の作業の記録（適用した版，日時，確認の結果）を発注者に報告する方法
⑥事故が起きたときの連絡，証拠の保全，調査の費用の負担
⑦責任制限条項の金額と，故意・重過失の場合の扱い
令和８年１１月６日に決定された「サイバーセキュリティ緊急対策パッケージ」も，PHPの重大な脆弱性に見られるように運用開始後に脆弱性が発見されるリスクは常に存在する一方で，システム開発契約や運用保守契約では脆弱性対応の実施主体が明確に定められていない場合が多く，緊急の対策が必要となった際に支障が生じる事例が発生しているとして，契約で留意すべき事項の普及促進の方策を検討するとした（同パッケージ資料２・別紙１８頁）。
国家サイバー統括室の令和８年１１月５日の注意喚起は，深刻な脆弱性の公表時に保守事業者任せにせず判断できるよう，影響調査の責任者，委託先との役割分担，経営層への報告基準及び暫定対策の判断手順をあらかじめ定めることを対策例に挙げている（同注意喚起１１頁）。
両資料の概要は，国家サイバー統括室の注意喚起（令和８年１１月５日）と緊急対策パッケージで整理している。
電子公告を掲載するサイトでは，停止の決定者，緊急連絡，公告ページへの影響確認，停止・復旧時刻の記録及び付記公告を誰が担当するかも決めておくことが望ましい。
これは，保守会社が当然に会社法上の判断まで引き受けるという趣旨ではなく，契約上の役割分担を具体化するための提案である。
中断時の法的要件は，電子公告がサイト停止で中断したら―PHP脆弱性対応，救済要件と決算公告の違いを参照されたい。
更新を延期するときの判断記録も決めておく
実務上は，警告・更新提案の内容，送受信日時，対象機器・バージョン，契約上の担当，想定される影響，対応期限及び決裁者を一つの記録で追えるようにしておくとよい。直ちに更新しない場合は，互換性の検証やサービス停止の影響，代替措置，延期の理由，再判断の日及び完了確認の担当者も残す。
これらは，前記裁判例を踏まえた本記事の実務上の提案であり，この記録を作ることだけで責任がなくなるという趣旨ではない。警告が届いた事実だけで契約上の更新義務や事故との因果関係まで決まるわけでもない。契約の範囲，指摘の具体性，実施可能な措置及び実際の事故経路を分けて検討する必要がある。
更新の完了確認については，対象のシステム・版・指摘事項・対策・確認担当者・確認方法・結果を対応させることが考えられる。
これは本記事の実務上の提案であり，一律の法定手順を示すものではない。
例えば，あるWebアプリケーションの診断で見つかった問題を修正したことが，別のシステムについて過去に指摘された問題を解消した証拠になるとは限らない。
対策を完了したとの報告を受けるときには，元の指摘と同じ対象・観点について有効性を確かめたかも記録したい。
診断会社への依頼範囲，検証できなかった点及び残るリスクも区別しておくと，既存の延期判断の記録とつながる。
関連する記事として，脆弱性診断後の対策・再診断・経営報告及び情報漏えいが確認されなくても調査費用は請求できるかも参照されたい。
第９ 関連記事
①PHPの緊急セキュリティ更新とWordPress保守―法律・税理士事務所の確認，バックアップ，互換性試験及び復旧手順
②ECサイトのカード情報漏えいと加盟店の義務―割賦販売法３５条の１６，クレジットカード・セキュリティガイドライン６．１版及び開発委託先の責任
③ShopifyはWordPressより安全で速いのか―法律事務所サイトの比較と選定基準
④個人情報漏えいの慰謝料はいくらか―ベネッセ事件最高裁判決と裁判例の認容額
⑤外部委託先で個人情報が漏えいした場合の委託元の対応―報告，本人通知及び委託先監督
⑥自社サーバーが乗っ取られて他社への攻撃に使われたら―不法行為責任，裁判例，警察からの通知及び事前の備え
⑦国家サイバー統括室の注意喚起（令和８年１１月５日）と緊急対策パッケージ―事業者が確認すべき対策と法的義務の区別
第１０ 出典
１ 法令
①民法４１５条・６３２条・６４４条・６５６条（e-Gov法令検索。令和８年６月２４日施行の版。令和８年１０月２２日確認）https://laws.e-gov.go.jp/law/129AC0000000089
２ 裁判例
①前橋地裁令和５年２月１７日判決（令和２年（ワ）第１４５号）https://www.courts.go.jp/hanrei/92137/detail4/index.html
②東京地裁令和５年２月２７日判決（平成２７年（ワ）第２２３６号ほか）https://www.courts.go.jp/hanrei/91950/detail4/index.html
③東京地裁令和元年１２月２０日判決（平成２９年（ワ）第６２０３号，判例秘書の判例番号 Ｌ０７４３１５５８。裁判所ウェブサイト未掲載）
３ モデル契約とIPAのガイド
①情報処理推進機構・経済産業省「～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第二版〉」（逐条解説付き）ソフトウェア開発委託基本モデル契約書２９条・５０条・５３条，情報システム保守運用委託基本モデル契約書３条・１４条（令和８年１０月２２日確認）https://www.ipa.go.jp/digital/model/model20201222.html
②情報処理推進機構ほか「ウェブサイト運営者のための脆弱性対応ガイド」（第３版第２刷，平成２９年３月３０日）３．３（９頁）（令和８年１０月２５日確認）https://www.ipa.go.jp/security/guide/vuln/ug65p90000019by0-att/000058492.pdf
③内閣官房国家サイバー統括室「個人情報の漏えい等につながる不正アクセスへの対策について」（２０２６年１１月５日）１１頁（令和８年１１月７日確認）https://www.cyber.go.jp/pdf/press/261105_taiou.pdf
④サイバーセキュリティに関する関係閣僚会議「サイバーセキュリティ緊急対策パッケージ（案）について」（令和８年１１月６日，資料２）別紙１８頁（令和８年１１月７日確認）https://www.cas.go.jp/jp/seisaku/cybersecurity_kakuryokaigi/dai2/shiryo2.pdf
４ PHPの資料
①PHP「Supported Versions」（令和８年１０月２２日確認）https://www.php.net/supported-versions.php
②PHP「Unsupported Branches」（令和８年１０月２２日確認）https://www.php.net/eol.php
③PHP「News Archive 2026」（令和８年１０月２１日のセキュリティアドバイザリ。令和８年１０月２２日確認）https://www.php.net/archive/2026.php