なぜテストのないシステムは言語やライブラリの更新が先送りされ続けるのか

言語やライブラリの更新を先送りしたシステムの問題

回帰テストとステージング環境が無いシステムでは、互換性の無い変更を含む更新のたびに、人が機能を確認する費用と、本番で初めて不具合が判明する危険が生じます。そのため、予算や担当者の不足で一度先送りした更新は、次の機会にも先送りされやすくなります。先送りしている間に言語やライブラリの提供元によるサポートの期限を経過すると、影響のある脆弱性が公開されたとき、短期間で何年分もの更新を実施するか、遮断、停止、廃止のいずれかを選択することになります。

自社で更新が先送りされているかは後述の兆候の表で判別でき、該当した場合に最初に実施するのは、更新そのものではなく現状の調査です。ただし、悪用が確認された脆弱性が未修正のまま外部に公開されているなら、当面の対応を先に決定します。

前提となる更新と確認の手段

システムが利用する言語（PHPやJavaなど）、外部で開発されたプログラムであるライブラリ、OSには、提供元がバージョンごとに定めるサポートの期限があります。期限を経過したバージョンには、提供元からは通常のセキュリティの修正が提供されません。更新は、これらを提供元の最新のバージョンに置換する作業です。バージョンの番号の末尾の数字だけが変化するパッチ版の更新は不具合とセキュリティの修正が中心ですが、先頭か2番目の数字が変化する更新は互換性の無い変更を含む場合があり、自社のコードを変更しなくてもシステムの挙動が変化することがあります。更新の後の動作は、回帰テストとステージング環境で確認します。回帰テストは注文の金額の計算などが更新の前後で同じ結果になるかを自動で検証し、ステージング環境では利用者が利用する本番の環境に反映する前に、同じ構成で更新を試行します。

更新が先送りされる原因

更新が先送りされる原因は複数あります。予算の都合で更新の提案を採用しない場合があり、独立行政法人情報処理推進機構（IPA）は、長期間更新していないシステムでは開発時の資料やノウハウの不足、担当者の不在、保守契約の終了によって対策が困難になっている場合があると説明しています。回帰テストとステージング環境が無いことは、これらの原因と同時に存在し、先送りを長期化させる原因です。2つが無いと、互換性の無い変更を含む更新のたびに費用の見積が困難で業務を停止させる危険のある作業になるので、一度先送りした更新は、緊急の理由が無い限り再び後回しになりやすくなります。

確認の費用が更新のたびに発生する

AWS Lambdaの公式文書は、言語のメジャーバージョンの間で既存のコードがそのまま稼働することは保証できないと明記し、本番に反映する前に最新のバージョンで関数をテストするよう推奨しています。言語の提供元も同様で、PHPはバージョンを1つ更新するごとに移行ガイドを公開し、8.3から8.4のように2番目の数字が変化する更新でも互換性の無い変更や廃止予定の機能を列挙しています。

回帰テストが網羅している処理は、更新した後にテストを実行し、失敗した箇所を修正すれば確認が完了します。網羅していない処理の確認と、移行ガイドの変更のうちシステムが利用している箇所の特定は、テストがあっても人が担当します。言語の互換性チェッカー（PHPならPHPCompatibilityなど）で廃止・変更された機能の利用箇所を特定すれば、テストが無くても影響の調査の範囲を限定できますが、挙動が正確かは人が確認することになります。回帰テストが無いと全ての処理を人が操作して確認することになり、工数は機能が多いほど増加します。ステージング環境も無く、本番で旧バージョンに即時に切り戻す仕組みも無ければ、本番と同じ構成での確認は本番に反映した後になり、問題が発生すると切り戻しが完了するまで業務が停止します。

確認の手段が無いシステムではその工数が機能の数に応じて増加し、ライブラリの置換を伴わない更新では費用のうち確認の割合が増加します。システムの責任者の立場では、機能が1つも増加しない作業に多額の費用と業務の停止の危険が生じるので、緊急の理由が無ければ先送りが選択される場合が多くなります。

• 外部のサービスとの連携、請求書などの書類の出力、夜間の定期処理のように、画面の操作だけでは確認が困難な処理が多いほど、確認の工数は増加する
• 回帰テストが主要な処理を網羅しているほど、確認の多くをテストの実行に置換できる
• パッチ版の更新は挙動の変化が少ないので、確認する範囲を限定できる。ただし、テストが無いと影響の無い機能を特定する手段が限られるので、確認の範囲を限定するほど本番で不具合が発生する危険が増加する

開発時の資料も担当者も無いシステムでは、何が正確な挙動かを確認する前にその定義から調査する必要があるので、費用はさらに増加します。

数字の変更だけで更新は完了しない

更新の見積を確認したシステムの責任者が疑問視しやすいのは、設定のバージョンの数字を変更するだけの作業に、なぜそれだけの費用が必要なのかという点です。数字の変更は数分で終了し、費用の大半はその後の作業で発生します。

• 移行ガイドに列挙された廃止と変更のうち、システムが利用している箇所の特定
• 最新のバージョンに対応していないライブラリの更新と、開発が終了したライブラリの置換
• 挙動が変化した箇所の修正
• 全ての機能の動作の確認

ライブラリの更新は連鎖します。言語を更新すると旧バージョンのライブラリが最新の言語に対応していない場合があり、ライブラリにも互換性の無い変更を含む更新が必要になります。そのライブラリの更新で別の挙動も変化するので、確認の対象はさらに拡大します。

更新を運用の範囲の軽微な作業と認識して開始したところ、互換性の無い部分の再開発が必要と判明し、数か月にわたる改修になる場合もあります。

回帰テストが無いシステムでは人の確認が挙動の変化を発見する主な方法になるので、更新の見積では影響の調査と確認の工数が増加します。見積の確認の工数がテストの実行やテストの追加ではなく、人が画面を操作する確認だけで構成されているなら、確認を人の操作に依存していると推定できます。

先送りしている間にバージョンの遅れが拡大する

PHPの場合は1つのバージョンを最初の安定版から2年間は報告された不具合とセキュリティの問題を修正し、その後の2年間は重大なセキュリティの問題だけを修正し、合計4年でサポートを終了します。開発の時点で最新のバージョンを採用したシステムでも、4年間更新しなければサポートの対象外になります。

遅れは更新するバージョンの数で拡大します。PHPの5.6から、2028年末までセキュリティの修正が提供される8.4へ更新する場合を例にします。5.6から7.0、7.0から7.1と順に連続する移行ガイドは合計10あり、サポートが終了したバージョンの一覧とサポート中のバージョンの一覧に掲載されています。その全てに記載された変更のうち、システムが利用している箇所が対象になります。毎年1つずつ更新していれば1回あたりの対象は1つの移行ガイドで、確認も1回分の変更に限定できます。

一度に更新すると変更の数だけでなく、問題が発生したときに、どの変更が原因かを特定する作業も増加します。

一度に更新する工数は、更新していないバージョンの数と、次の条件で増減します。

• 遅れの期間に、互換性の無い変更が多い更新を経由するか。PHPなら7.0や8.0への更新が該当する
• 利用しているライブラリやフレームワークの開発が終了しているか。終了していれば更新ではなく置換になり、置換した部分には再開発に近い範囲の確認が必要になる場合がある
• 提供元が想定していない使用方法や、ライブラリを独自に改造した箇所がどれだけあるか

置換が必要な部分がシステムの大半に及ぶ場合や、業務の変化に対応して再開発したい部分が多い場合は、更新を継続するより再開発したほうが安価になる場合があり、後述の現状の調査で両方を比較します。

更新が先送りされている兆候

最初の1つは該当するだけで調査の対象にします。2つ目は先送りが判断として記録されていないことを、3〜5つ目は確認の手段が無いことを、6つ目は更新を担当する人や契約が無いことを示し、最初の1つと同時に該当するなら、それが先送りの理由になっている可能性が高くなります。

兆候	確認の方法	確認する人
言語、フレームワーク、OSのいずれかがサポートの期限を経過している	利用しているバージョンの一覧を作成し、提供元の公式サイトで期限を確認する。OSに同梱された言語なら、OSの期限も確認する	開発の担当者
開発の担当者から更新の提案があったが、理由と再検討の時期を記録せずに採用しなかった	過去の提案のメールや議事録を確認する	システムの責任者
本番とは別に更新を試行する環境が無い、または本番と構成が異なる	更新を本番に反映する前にどこで試行しているかを確認する	開発の担当者
動作の確認を人が画面を操作して実施している	直近の改修で動作の確認をどのように実施したかを確認する	開発の担当者
改修の見積の確認の工数が、人が画面を操作する確認だけで構成されている	直近の3件の見積で確認の工数の内訳を確認する	システムの責任者
定期的な作業にOS、言語、ライブラリの更新が含まれていない。外部に保守を委託しているなら保守契約に記載が無い	運用の手順書か、保守契約の作業範囲の条項を確認する	システムの責任者

該当した項目は、後述の現状の調査の出発点にします。環境の構築方法とテストを整備する範囲は、調査の結果に基づいて決定します。

更新の提案を採用しなかったことがある場合は、その日付、理由、決定者、再検討の時期を記録し、提案した開発の担当者と共有します。採用しないことも経営の判断として成立しますが、記録が無いと脆弱性が悪用された時点で、誰がリスクを承知して決定したのかが不明になり、外部に委託している場合は委託先との対立の原因にもなります。

更新の先送りを放置した場合の危険

先送りした更新は、脆弱性の公開や、サーバーやクラウドの提供終了を機に期限付きの作業になり、その時期は自社で選択できません。

脆弱性の公開で更新の期限が確定する

2026年10月21日（米国時間）に公開されたPHPの脆弱性（通称PHP2Shell）は、遠隔の第三者に任意のコードを実行される可能性があるものです。脆弱性の調査に関与したWiz社は、PHP 5.4以降の幅広いバージョンが影響の対象になると報告しています。修正版が提供されたのは8.2、8.3、8.4、8.5の各バージョンだけで、サポートが終了した8.1以前には提供元からの修正版がありません。米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、10月26日にこの脆弱性を悪用が確認された脆弱性の一覧（KEVカタログ）に登録しました。そのうえで、すぐに更新できない組織や8.1以前を利用し続ける組織に、更新するまでPHPを利用するシステムをオフラインにするよう求めています。オフラインとは、システムを停止するかネットワークから遮断することです。

サポート中のバージョンを利用しているシステムなら、修正版への更新はパッチ版の更新で完了します。サポートが終了したバージョンを利用しているシステムは、提供元以外の会社による有償の延長サポートを利用しない限り、修正版が提供されたバージョンまでの間の全てのバージョンの変更に対応する更新が必要になります。

このときシステムの責任者はすぐの修正と業務の継続を両方求めます。しかし、サポートが終了したバージョンを利用し、テストとステージング環境も無いシステムで選択できる次の対応は、いずれも業務の停止、不具合、追加の費用のどれかを伴います。

• システムを停止し、更新と確認が完了するまでメンテナンス中にする
• 確認が不十分なまま更新し、不具合は本番で発見して修正する
• WAFや接続元のIPアドレスの制限で一時的に攻撃を遮断し、その間に更新する。正規の利用者を遮断する場合がある
• 有償の延長サポートで修正を入手し、その間に更新する
• 更新を断念し、別の製品やサービスに移行するか、システムの公開を終了する

IPAは、有効な暫定対策が困難な場合は外部からのアクセスの遮断やサービスの一時停止が必要か判断するよう求めています。更新した後の維持管理の体制を確保できない場合は、公開の終了やシステムの廃止も含めて検討するよう求めています。

停止の影響は業種によって異なります。ネットで受注している事業なら、停止している間の注文を電話などで受注しない限り、その売上が減少します。予約や申込みの受付に利用するシステムなら、停止している間の受付を電話や紙で代替する人手が必要になります。会員の氏名や住所、クレジットカードの番号を保管するシステムなら、停止も遮断もせずに公開を継続すると、それらが流出する危険があります。

サーバーやクラウドの提供終了で更新の期限が確定する

脆弱性が無くても、システムを稼働させている環境の側が旧バージョンの言語やOSの提供を終了します。レンタルサーバーで旧バージョンのPHPの提供が終了したり、自社で管理するサーバーのOSがサポートの期限に到達したりすると、システムの稼働を継続するには言語やOSの更新が必要になります。

クラウドのAWS Lambdaは、言語のバージョンのサポートを終了する少なくとも180日前に通知します。終了した後はセキュリティの修正を適用しない場合があり、終了から30日以上後には新規の作成を、60日以上後には既存のプログラムの更新も停止します。更新が停止された後は旧バージョンのままではコードを変更できず、障害を修正するにも先にサポート中のバージョンへ更新する必要があります。

通知から期限までの期間は数か月ありますが、影響の調査に時間を要するので、通知の直後に開始しないと期限までに完了しない場合があります。通知は主に契約の連絡先のメールアドレスに送信され、管理画面にも表示されます。連絡先が退職者や以前の担当者のメールアドレスだと通知の確認が遅延するか通知を受信できないので、契約の名義と連絡先が現在の担当者になっているかを確認しておきます。

当面の対応と現状の調査

悪用された脆弱性の影響があるなら現状の調査より先に当面の対応をする

悪用が確認された脆弱性の影響がある未修正のバージョンを外部に公開しているなら、調査の完了より先に当面の対応を決定します。決定するのは、接続元の制限やWAFで攻撃を遮断できるか、遮断できないならいつまで停止するかです。悪用が確認された脆弱性の影響があるソフトウェアは優先して更新し、できなければ外部から遮断します。

現状を調査する

遅れの程度と、テストとステージング環境の整備の範囲が不明な段階では見積の精度が低いので、最初は作業ではなく現状の調査だけを実施します。調査では次の項目を明らかにします。

• 言語、フレームワーク、主要なライブラリ、OSのバージョンと、それぞれのサポートの期限
• サポート中の最新のバージョンまでの遅れと、更新に必要な作業の概算
• 開発が終了していて置換が必要なライブラリ
• 既存のテストの有無と、整備する場合に優先する範囲
• ステージング環境の有無と、構築する方法
• 更新を継続する場合と、再開発する場合と、別の製品やサービスに移行する場合の比較

調査は、日常の保守の合間の作業ではなく、期間と成果物を決定した作業として実施します。期間と成果物を決定しないと完了の基準が無く、日常の保守の作業が発生するたびに中断されやすいためです。社内に担当できる人がいなければ外部の会社に依頼し、保守を委託している会社に依頼する場合も、保守の範囲の無償の対応ではなく個別の作業として発注します。

調査の結果に基づいて、テストとステージング環境の整備と更新を、1回の大規模な作業ではなく複数の作業に分割して実施し、1回ごとに変更の範囲を限定して、問題が発生したときに原因を特定しやすくします。整備した後は、更新の提案を自動で作成するツール（RenovateやDependabot）で小規模な更新を継続して適用するか、年に1回など時期を固定して実施すると、遅れの再発を防止できます。保守を外部に委託しているなら、保守契約の作業範囲に更新を含めます。

調査の費用と期間が増減する条件

• 言語、フレームワーク、ライブラリの数と、それぞれの遅れ
• 画面、機能、外部のサービスとの連携の数
• 設計書や、本番と同じ環境を構築する手順が存在するか
• システムを開発した人や会社が調査に協力するか

外部の会社に依頼し、複数の会社から調査の見積を取得する場合は、調査の範囲と報告の項目が前の節の一覧と一致しているかを確認してから金額を比較します。

テストとステージング環境を整備しなくてよい場合

整備すると更新のたびに人が確認する工数を削減できるので、テストとステージング環境の整備は、更新の回数が多いほど費用を回収しやすい投資です。調査の結果が次のいずれかに該当するなら、整備しない選択も成立します。

• 画面と機能が少なく、全ての機能を人が確認しても1日程度で終了するなら、整備せずに更新のたびに人が確認する
• 1〜2年以内に廃止や再開発を決定しているなら、その時点まで更新を延期できる。外部に公開し続けるなら、脆弱性が公開された時点の遮断や停止の手順を事前に決定しておく
• 社内の限られた人だけが利用し、外部から接続できず、個人情報や決済の情報も保管していないなら、更新を延期できる
• 提供元が運用するクラウドのサービスを改造せずに利用しているなら、更新と確認は提供元が担当する
• 変更を小規模に分割して頻繁に本番へ反映し、旧バージョンを並行して稼働させたまま一部の利用者から順に移行し、問題があれば即時に切り戻せる運用をしているなら、ステージング環境は無くてもよい。回帰テストは必要になる

自社のサーバーで稼働させるパッケージや改造したパッケージは、更新の適用と改造した部分の確認はシステムの責任者の側の担当になります。