# なぜ保守契約があるのにプログラミング言語やOSの更新は別見積になるのか

アプリケーションの保守の契約は、言語やOSの更新を作業に含めていない場合があります。範囲外の作業の単価と手順も未確定なら、緊急の修正版が配布されてから作業が完了するまで、暫定の対策が無ければ、脆弱なまま稼働するか停止するかの選択になります。

## サマリ

- システムは、開発会社が開発したアプリケーションと、その下で稼働するPHPやJavaのようなプログラミング言語、OS、Webサーバーやデータベースのようなミドルウェアで構成され、後者の多くは第三者が開発して修正版を配布する
- アプリケーションの保守の契約は、言語やOSの更新を作業として記載していない場合があり、その更新は範囲外の作業として別見積になる
- **範囲外になる事情の1つは、言語やOSの保守をアプリケーションの保守とは別のサービスとして構成する契約があることで、アプリケーションの保守だけを締結し、その別紙にも更新を記載していなければ、修正版の適用を担当する契約が無い**
- もう1つは、更新の作業の量が脆弱性の公開と利用中のバージョンで月ごとに大幅に変化することで、定額に含めると開発会社がその分を保守費に予め計上する場合があり、その場合は作業の無い月にも発注者が負担する
- 情報処理推進機構（IPA）が公開しているモデル取引・契約書の条項では、開発会社は第三者のソフトに欠陥が無いことを保証しないので、納品後に発見された言語やOSの脆弱性は無償の修正の対象になるとは限らない。修正版を適用する作業は、保守の範囲に含めるか、個別の契約で依頼する
- 範囲外の作業の単価と依頼の手順も未確定なら、緊急の修正版が配布されてから更新の作業が完了するまで、攻撃の通信の遮断や接続元の制限のような暫定の対策が無ければ、脆弱なまま稼働するか停止するかの選択になる

![言語やOSの更新が範囲外で単価と手順も未確定な場合に、修正版の配布、範囲外という回答、見積と社内の承認、更新の作業の順に進行し、その間は暫定の対策が無ければ脆弱なまま稼働するか停止するかの選択になる流れの図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-overview-f7fbfcf62239.png)
*図1　言語やOSの更新が保守の範囲外で単価と手順も未確定だと、修正版の配布から更新の作業が完了するまで、暫定の対策が無ければ脆弱なまま稼働するか停止するかの選択になる*

## 言語の修正版の適用が別見積になる例

緊急の修正版が配布されると、その適用が保守の範囲に含まれるかが問題になります。
言語の例では、2026年10月に公開された、Webサイトで多く利用されるプログラミング言語PHPの[脆弱性（通称PHP2Shell）](https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html)があります。

2026年10月21日に[修正版が配布された](https://www.php.net/archive/2026.php)この脆弱性は、[遠隔の第三者にシステム上で不正なプログラムを実行される可能性がある](https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html)ものです。
影響する可能性があるのは[PHP 5.4以降の幅広いバージョン](https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html)で、該当するバージョンのPHPを利用するシステムは、影響の有無の確認と、修正版の適用か更新が必要になりました。
サーバーの提供元が言語の修正版を適用しない構成で、保守の範囲に言語の更新が無ければ、この適用は別見積になり、更新の作業が完了するまでは、暫定の対策が無ければ脆弱なまま稼働するか停止するかの選択になります。

別見積と回答されること自体は、開発会社の不誠実を示しません。
更新の作業は契約で保守の範囲に含めることができ、範囲外のままでも単価と手順を事前に確定すれば、作業の開始までの時間を短縮できます。

## 言語やOSの提供元とサポートの期限

以下の「言語やOS」には、ミドルウェアも含めます。
提供元は一般に、バージョンごとに定めたサポートの期限まで修正版を配布し、その適用は利用者か保守の担当が実施します（提供元が適用まで担うクラウドのサービスを除く）。
オープンソースのソフトも多く含まれます。
PHPをOSのパッケージで導入している場合、言語の修正版はOSの配布元から、OSの更新として配布されます。

![アプリケーションの下で言語、ミドルウェア、OSが稼働し、アプリケーションは開発会社、言語やOSは第三者が開発して修正版を配布することを示した図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-layers-5332485606af.png)
*図2　アプリケーションは開発会社が開発し、その下で稼働する言語やOSの多くは第三者が開発して修正版を配布する*

サポートの期限は、提供元がバージョンごとに修正版を配布する期限です。
PHPの各バージョンのサポートは、[最初の安定版から2年間は不具合とセキュリティの問題を修正し、その後の2年間は深刻なセキュリティの問題だけを修正する、合計4年](https://www.php.net/supported-versions.php)です。
期限が経過したバージョンは通常の修正版の配布の対象外です。
冒頭の例のPHP2Shellでも、期限が経過した8.1以前のバージョンには[通常の修正版は配布されず、PHPの開発チームによるソースへの最小限の修正と、Linuxの配布元などによる修正に限られました](https://www.php.net/archive/2026.php)。
OSの配布元による修正や有償の延長サポートで、期限の後も修正が提供される場合があります。

![PHPの1つのバージョンが、最初の2年は不具合とセキュリティの修正、次の2年は深刻なセキュリティの修正だけが提供され、サポートの期限の後は通常の修正版が配布されないことを示した図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-support-b3f3796ab305.png)
*図3　現行の方針では、PHPの各バージョンは4年でサポートが終了し、その後に公開された脆弱性には通常の修正版が配布されない*

## 保守の範囲から言語やOSの更新が除外される事情

### 保守の範囲は契約の別紙で定義される

保守の範囲は、契約書の本文ではなく別紙で定義される場合があります。
独立行政法人情報処理推進機構（IPA）が公開している情報システム・モデル取引・契約書（第二版の本体のWordファイル）も、[保守の作業の詳細を、個別契約に添付する業務仕様書と受託条件明細に記載する構成](https://www.ipa.go.jp/digital/model/model20201222.html)です。
同資料は、新規の開発と保守の区切りを含め、どこまでの修正が保守の対象になるかを[受託条件明細等で明確に規定しておく必要がある](https://www.ipa.go.jp/digital/model/model20201222.html)と注記しています。

### アプリケーションの保守と言語やOSの保守を別にする構成

同資料のサンプルは、ハードウェア、OS、ミドルウェアの保守を、アプリケーションの保守ではなく[運用を委託するサービスの側のサンプルに含めています](https://www.ipa.go.jp/digital/model/model20201222.html)。
一方でアプリケーションの保守のサンプルは、[動作環境が変化してもアプリケーションを利用できるように修正する作業](https://www.ipa.go.jp/digital/model/model20201222.html)を範囲に含めています。
[同資料のサンプル](https://www.ipa.go.jp/digital/model/model20201222.html)は言語の実行環境に言及していませんが、PHPのような言語はOSやミドルウェアと同様にアプリケーションの外部から提供されるので、この記事では言語もOSやミドルウェアと同じ保守の側に含めます。
ただし、言語のバージョンをアプリケーションのソースコードや、サーバーの環境を記述した設定のファイルで指定する構成では、言語の更新がアプリケーションの保守の作業になる場合があります。
この構成では、OSや言語の修正版を適用する作業は言語やOSの保守の側、適用で稼働しなくなったアプリケーションの修正はアプリケーションの保守の側に含まれ、適用後の確認をどちらが担当するかは契約で決定することになります。
言語やOSの保守の契約が無く、アプリケーションの保守の別紙にも言語やOSの更新を記載していないと、修正版の適用そのものを担当する契約がありません。

![アプリケーションの保守と言語やOSの保守が担当する作業を2つの領域に区分した図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-scope-5ffae157cbec.png)
*図5　[情報システム・モデル取引・契約書](https://www.ipa.go.jp/digital/model/model20201222.html)のサンプルはOSやミドルウェアの保守をアプリケーションの保守とは別のサービスに置く。この構成に当てはめると、修正版の適用と入れ替えは言語やOSの保守の作業になり、言語やOSの保守の契約が無ければ、アプリケーションの保守の別紙に記載しない限り担当する契約が無い*

### 定額の保守費は予測できる作業の量を前提にすることが多い

言語やOSの更新は、何も無い月がある一方で、深刻な脆弱性が公開されると短期間に作業が集中し、その量は利用中のバージョンと提供元の変更の内容で大幅に変化します。
この作業を定額に含めて量の変動を料金に反映しない契約では、開発会社が予測できない作業の量に対応する費用を保守費に予め計上することがあり、その場合は作業の無い月にも発注者がその費用を負担します。
作業の量を予測できない更新を別見積にするのは、その費用を誰がいつ負担するかを区分する方法の1つで、開発会社に固有の事情ではありません。

[情報システム・モデル取引・契約書](https://www.ipa.go.jp/digital/model/model20201222.html)のアプリケーション保守の業務仕様書のサンプルは、受託条件明細に記載した業務量を基準に作業を実施する形です。
この記事の見方では、業務量は問い合わせや障害の件数のように実績から予測しやすい作業を基準にすると設定しやすく、脆弱性の公開に左右される更新は、枠や条件を別に定めない限り記載の外になりやすくなります。

作業時間に応じて対価が発生する形の準委任の保守で、月あたりの作業時間の枠を設定し、対象の作業に言語やOSの更新も記載していれば、枠の中で更新を実施できるので、作業ごとの見積は不要です。
枠を超過した分だけを精算することと、枠を超過する場合の作業時間か金額の上限（見積なしで作業を開始してよい上限）を、保守の委託先が提示してシステムの責任者が事前に合意していれば、緊急の更新でも見積の作成の前に作業を開始できます。

![言語やOSの更新の費用を、月額に含める形、作業時間の枠の中で実施する形、別料金にする形の3つに区分し、それぞれの負担と作業の開始を比較した図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-pricing-941e7c57007e.png)
*図4　言語やOSの更新の費用は月額、作業時間の枠、別料金で負担し（作業ごとに組み合わせてもよい）、別料金で見積なしの上限が未定だと見積と承認の後に作業を開始する*

### 言語やOSの更新の作業は適用、確認、改修で量が異なる

言語やOSの更新は、修正版を適用する作業、適用した後に機能が従来どおり稼働するかを確認する作業、稼働しなくなった箇所を改修する作業で構成されます。

![修正版の適用、機能の確認、稼働しない箇所がある場合の改修の3段階を矢印で接続した図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-steps-99b9bdd9600f.png)
*図6　更新の作業は適用、確認、改修の順で、改修は稼働しない箇所がある場合だけ発生する*

PHPの場合、サポート中の同じバージョンの系列の修正版は[報告された不具合とセキュリティの問題を修正するもの](https://www.php.net/supported-versions.php)です。
修正の範囲が限定的でも稼働への影響は確認する必要があるので、費用は適用そのものより、確認する機能の数と改修の有無で変化します。
サポートの期限が経過したバージョンでは、修正版のあるバージョンまで更新する間に、互換性の無い変更で稼働しなくなる箇所があれば改修が追加になり、その量はアプリケーションの改修に近くなる場合があります。

保守契約に「OSの更新に対応する」と1行だけ記載されていても、適用だけを含むのか、確認と改修まで含むのかは、その1行からは判別できません。

### モデル契約では言語やOSの欠陥を開発会社が保証しない

別見積と回答されると、欠陥なら無償で修正すべきではないかという疑問が生じる場合があります。
[情報システム・モデル取引・契約書](https://www.ipa.go.jp/digital/model/model20201222.html)の開発の契約書は、開発会社の提案か発注者の指示で第三者のソフトやオープンソースのソフトをシステムに採用する場合、提案の時点で欠陥を認識しながら、または重大な過失で認識せずに説明しなかった場合を除き、それらに契約不適合（契約で合意した内容に適合しない欠陥）が無いことを開発会社は保証しないとする条項があります。
同資料はセキュリティについても、開発会社の義務を合意したセキュリティの仕様に従った対策に限定し、セキュリティの問題が発生しないことは保証しないとしています。

そのうえで同資料は、引き渡しの翌日から新たな脆弱性が発見される可能性は払拭できないので、[セキュリティの対応を含むサポートの契約などの予防的な措置を協議・検討することが望ましい](https://www.ipa.go.jp/digital/model/model20201222.html)としています。
納品した後に公開された言語やOSの脆弱性は、開発会社の契約不適合責任で無償の修正を求められる場合に該当するとは限らず、修正の作業は保守か個別の契約の対象であることが前提です。

### 言語はオープンソースだから保守の対象外という回答

開発会社から、PHPのような言語は誰でも無償で利用できるオープンソースのソフトなので保守の範囲外と回答される場合があります。
開発会社が開発していないソフトの欠陥を保証しないことは、[情報システム・モデル取引・契約書](https://www.ipa.go.jp/digital/model/model20201222.html)の考え方と一致します。
ただし、欠陥の責任を負わないことは、修正版を適用して確認する作業まで受託しない理由にはならず、その作業は契約で保守の範囲に含めることができます。
範囲外と回答されたら、それが欠陥の保証なのか、更新の作業なのかを区別して質問します。

![言語やOSの欠陥の保証は原則として開発会社が負わないが、修正版を適用して確認する作業は契約で保守の範囲に含められることを対比した図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-warranty-59c46d90351f.png)
*図7　言語やOSの欠陥を開発会社が保証しないことと、修正版を適用して確認する作業を保守に含めることは別の事柄*

## 別紙を確認していないと範囲外と判明するのは修正版の配布の後

保守の別紙を確認していなければ、更新が範囲外であることは、緊急の修正版が配布されて更新を依頼した時点で判明します。
その後に範囲の確認、見積、社内の承認、開発会社の作業の日程の調整があり、範囲外の作業の単価と手順が未確定なら、修正版の配布から作業の完了までの期間は、並行して実施できない分だけ延長されます。

社内で保守している場合も、言語やOSの更新が誰の業務でもなければ、他の業務との調整と停止を伴う作業の承認に同様に時間が必要です。

![修正版の配布から更新の作業の完了までを、単価と手順が未定の場合と、単価と見積なしの上限を事前に決定した場合で比較した図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-timeline-c974447e9c01.png)
*図8　単価と手順が未定だと範囲の確認、見積、承認、日程の調整の分だけ更新の完了が遅れ、暫定の対策が無ければ脆弱なまま稼働する期間が延長される*

範囲の確認から社内の承認までに1週間以上を要するなら、手続が完了する前に悪用が開始される場合があります。
修正の公開から1週間以内に悪用される脆弱性もあり、2023年に修正の公開後に悪用が確認された脆弱性41件のうち、[29%は修正の公開から1週間以内に悪用されていました](https://cloud.google.com/blog/topics/threat-intelligence/time-to-exploit-trends-2023)。
冒頭の例のPHP2Shellは、修正版の配布から5日後の10月26日に、米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が[悪用が確認された脆弱性の一覧（KEVカタログ）に登録](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching)しました。

同じ言語やOSの同じバージョンの系列を利用する顧客が多い開発会社では、例えば同じ脆弱性が多くの顧客に同時に影響して依頼が集中し、限られた人員で対応する開発会社が範囲内の顧客を先に対応すると、範囲外の依頼は作業の開始が遅延する場合があります。

## 自社の保守契約が言語やOSの更新を含んでいるかの手がかり

| 更新が保守に含まれていない可能性を示す手がかり | 記載を確認する資料 | 確認の担当 |
|---|---|---|
| 保守の作業を定めた別紙（業務仕様書、受託条件明細、サービスの仕様書など）が自社に無く、契約書の本文にも更新の記載が無い | 保守の契約書一式 | システムの責任者 |
| 別紙の作業の一覧に、OS、言語、ミドルウェアの更新が記載されておらず、サーバーの提供元や別の保守の契約も更新を担当していない | 別紙の作業の一覧と、対象外の作業の一覧、サーバーの契約 | システムの責任者 |
| 更新が記載されていても、適用、確認、改修のどこまでを含むかが区別されていない | 別紙の更新の項目 | システムの責任者 |
| 更新が範囲外の場合に、範囲外の作業の単価や算定の方法と、緊急時に作業を開始するまでの手順が未確定 | 別紙、個別契約書、過去の追加の見積 | システムの責任者 |
| 社内で保守していて、言語やOSの更新を担当する人、時期、担当者の不在時に代わりに適用する手順が未確定 | 運用の手順書、担当者の業務の分担 | システムの責任者 |

![適用から改修までが月額か作業時間の枠に含まれるか、範囲外の単価と見積なしの上限の事前承認があるかの2つで、見積なしで更新を依頼できるかを判定し、どちらかに該当すれば見積なしで依頼でき、どちらにも該当しなければ見積と承認が必要になる図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-decision-26a14a6c00c6.png)
*図9　外部に委託している場合、更新が範囲外でも範囲外の単価と見積なしの上限を事前に承認していれば、上限まで見積なしで依頼できる*

表のいずれかに該当すれば、修正版の配布の後に見積と承認が必要になる可能性があります。

契約とは別に、利用している言語やOSとバージョンを把握しているかと、サポートの期限が経過したバージョンを利用していないかも確認します。
期限が経過したバージョンは、更新が保守の範囲に含まれていても[通常の修正版が配布されない](https://www.php.net/supported-versions.php)ので、契約とは別に更新の計画が必要です。
互換性の無い変更の改修が必要なら工数が増加し、月額や作業時間の枠を超過する場合があるので、図9で見積なしと判定しても、改修の規模を別に確認します。

## 言語やOSの更新が遅延した場合の危険

サポート中で修正版が配布されたバージョンなら、別見積でも作業は修正版の適用と確認が中心で、改修は適用で稼働しなくなる箇所がある場合に限られます。
通常の修正版が配布されないバージョンでは、OSの配布元による修正や延長サポートが無ければ、修正版のあるバージョンまで更新することになり、既存の機能が稼働しなくなる互換性の無い変更の影響があれば改修が追加になり、見積の金額と期間が増加します。
修正が提供されないバージョンでは、更新するまで外部からの接続を停止する判断も必要になります。
冒頭のPHP2Shellの例では、[CISA](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching)は、すぐに更新できない組織や修正版の無い8.1以前を利用し続ける組織に、[更新するまでPHPを利用するシステムをオフラインにする](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching)よう求めています。

![上段で、利用中のバージョンに修正版があれば適用と確認、無ければ修正版のあるバージョンまでの更新になり期間が長くなることを示し、下段で、作業が完了するまでの間は停止、暫定の対策を導入した稼働、そのままの稼働から選択し、稼働を継続して不正アクセスで個人データの漏えいのおそれがあれば報告と本人への通知が必要になることを示した図](https://media.marketing.kdotdev-tunnel.org/guide-platform-update-outside-maintenance-risk-3eee2ec4f791.png)
*図10　更新の完了までは停止、暫定の対策を導入した稼働、そのままの稼働から選択し、修正版の無いバージョンは更新の完了までの期間が長くなる。不正アクセスで個人データの漏えいのおそれがあれば報告と本人への通知が必要になる*

通販サイトや予約サイトのように売上や受付をシステムが担当しているなら、停止の期間はそのまま業務の停止になります。

停止せずに稼働を継続し、外部からの不正なアクセスで顧客の氏名や連絡先などの個人データが漏えいしたおそれがあるときは、[不正アクセスによる漏えいとして個人情報保護法の報告の要件（不正の目的による漏えいのおそれ）に該当し、本人の数が少なくても個人情報保護委員会への報告の対象](https://www.ppc.go.jp/personalinfo/legal/leakAction/)になり、[本人への通知も原則として必要です](https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/)。

会員のクレジットカード番号や、決済のできるサービスのIDとパスワードを保管しているシステムでは、カードの不正利用や不正な送金の被害に発展するおそれがあり、漏えいの影響はさらに増大します。

## 言語やOSの更新を保守に含めるには

契約の更新の時期より前に、利用中のバージョンとサポートの期限、範囲外の作業の単価を委託先に確認し、次の契約の更新では保守の別紙に言語やOSの更新を記載して、適用、確認、改修をそれぞれ月額、作業時間の枠、別料金のどれで負担するかを決定します。
別料金にする作業は、適用と確認までを対象に、保守の委託先が単価と見積なしで作業を開始できる上限を提示してシステムの責任者が合意し、その上限までの支出をシステムの責任者が社内の決裁者から事前に承認を得ておくと、修正版の配布から作業の開始までの手続が短縮されます。
社内で保守しているなら、利用している言語やOSとバージョンを一覧にして、期限が経過したものが無いかを確認し、担当者の業務に更新を含め、担当者の不在時に代わりに適用する手順と、停止を伴う作業の承認者を決定します。

すでに範囲外と回答されているなら、見積と並行して、利用中のバージョンに修正版が配布されているかと、作業の完了までの暫定の対策を、開発会社か、サーバーやネットワークを管理する会社に確認します。
範囲外の作業なら、この確認も有償になる場合があります。
暫定の対策には、攻撃の通信を遮断するWAFのルールの追加、接続元の制限、該当する機能の停止などがあり、[CISAはWAFが更新までの一定の防御になり得る](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching)としています。

## 言語やOSの更新を保守に含めなくてよい場合

次の場合は、言語やOSの更新を保守契約の作業にしなくても、修正版の配布の後に見積と承認で更新が停滞しにくいか、停滞する間の危険が限定的です。
ただし更新そのものは必要なので、サポートの期限が経過する前に担当を決定して実施します。

- 言語やOSの更新を提供元が担当すると利用規約で明記されたレンタルサーバーやクラウドのサービスを、改造せずに利用している。更新を提供元が実施するので、開発会社の見積は不要（言語のバージョンの廃止では利用者の更新が必要になる場合がある）
- 社内で更新の担当者、時期、不在時の手順が確定していて、外部に委託する保守はアプリケーションの範囲に限定している。更新を社内の担当者が実施するので、見積は不要
- 社外のネットワークから到達できず、個人情報も、カード番号や決済のできるサービスのIDとパスワードも保管していない。更新の完了までの間に外部から攻撃され、漏えいする危険が限定的（VPN機器などを経由した内部からの攻撃は別に検討する）
- 廃止や再開発の時期が確定していて、脆弱性が公開された場合の遮断や停止の手順を決定している。更新の完了までの間はシステムを遮断して攻撃を阻止する