緊急アップデートを支えた、平常時の準備

2026年10月、利用しているソフトウェアの重大な脆弱性への対応が必要になりました。開発・保守を支援しているサービスでも、10月22日に修正版へ更新しました。僕が行った基盤の更新手順と、それまでに進めていた準備をまとめます。

重大な脆弱性や情報漏洩の公表が重なったこの時期は、海外の一部の報道で「Black October（ブラックオクトーバー）」とも呼ばれていました。

基盤をどう更新したか

1. 動いているバージョンと、更新先を確認する

まず、本番のWebアプリとバッチで使っている実行環境を確認します。今回は、利用中の系統を変えずに修正版へ更新しました。10月21日に公開された修正版を確認し、次の点をそろえました。

OSのパッケージやレンタルサーバーを使っている場合は、提供元の修正状況と更新方法を確認します。古いバージョンに修正を取り込んで提供する場合もあるため、見かけのバージョン番号だけでは判断できません。

2. 基盤の指定を変えて、再ビルドする

今回は、実行環境とWebサーバーをまとめて構築する形でした。以下は、共通の構築元を修正版へ切り替えるときの考え方です。利用中の系統に対応する修正版を指定します。

構築元の指定：利用中の版 → 修正済みの版

実行環境だけでなく、WebサーバーやOSの組み合わせも元の構成に合わせ、既存の拡張機能やアプリの構築手順も保ちます。構築元を識別子で固定している場合は、その識別子も修正版のものへ更新します。

今回の構成では共通の構築元を使っていたため、先にその実行環境を更新して再ビルドし、アプリ側が参照する識別子も差し替えました。アプリ側の依存関係の指定を変えるだけでは、実行環境そのものは更新されません。

既存の構築手順を使って再ビルドし、完成した環境のバージョンと拡張機能を確認します。以下は、このときの確認の順番です。

修正版を指定して再ビルド
完成した環境のバージョンを確認
必要な拡張機能がそろっていることを確認

ここまではローカルでの構築と確認です。既存の実行環境を再起動するだけでは、再構築した環境への切り替えにはなりません。

3. 動作を確かめて、本番へ反映する

今回は予防的にサービスを一時停止し、本番のデータや認証情報を持ち込まない環境で修正版を検証しました。失敗したテストは更新前の環境でも比較し、既存テストの不整合を修正。更新後に単体・機能テスト328件が通ることを確認しました。

ステージングでログインや管理画面の表示・操作などを運営側と確認してから本番へ反映しました。本番のWebアプリとバッチの両方で、実行環境のバージョンも確認しました。

それまでに用意していたこと

7月から基盤の更新を進め、8月には実行環境を新しい系統へ移行し、フレームワークや画面側のライブラリも更新・検証していました。そのため、緊急対応では基盤の修正更新と検証に作業を絞りました。

ログイン、管理画面、権限に応じたデータの表示、バッチ処理など、更新後も守るべき動作を確認項目やテストにまとめていました。共通の構築元を用意してバージョンを固定し、更新前後の変更範囲を追えるようにしました。

保守は、次の改善への投資

修正版が公開されても、それを適用して動作を確かめられる準備がなければ、すぐには更新できません。緊急時に基盤の移行やテストの整備から始めるとなると、対応の負担は大きくなります。その負担が、サービスを続けるかどうかの判断につながることもあります。

AIを使って実装を進めても、動作を確かめ、本番へ反映できる状態が整っていなければ、利用者へ届けるところで止まってしまいます。だから、日頃から基盤を更新し、変更後の動作を確かめる手順も整えておきます。

AI時代の保守は、サービスを続け、次の改善へ進むための投資だと思っています。今回も、事前に整えた基盤とテストを使い、影響を確認しながら更新と本番反映を進めました。

基盤のアップデートや、既存システムの保守・改善でお困りの方は、ウルフアプリケーションへご相談ください。