パッチ適用の手順を「本番でそのまま更新」で済ませない──検証環境、バックアップ、戻し方、顧客への告知までの本番反映フロー

この記事は、パッチ適用の手順、つまりPHPやライブラリ、フレームワークの修正を、検証してから本番に反映するまでの流れを扱います。

金曜の夕方、本番で更新して帰った

「小さな修正の版だから大丈夫だろう」
そう思って、本番のサーバーで更新の命令を打ち、そのまま帰った。

月曜の朝、顧客から電話が来ます。週末のあいだ、問い合わせフォームの送信が失敗していた、と。
パッチそのものより、当て方の手順がないことのほうが、事故を生みます。

パッチ適用の手順とは、本番と同じ条件の場所で確かめ、戻せる状態を作ってから本番に反映し、結果を記録して知らせる、決まった順番のことである

黒字化の外科医です。パッチを当てる日の流れを、順番として解剖します。

手順を固定すべき理由は、三つあります。

第一に、パッチの影響は、当ててみるまでわからないから。
修正が中心の更新でも、拡張機能や独自の設定との組み合わせで、思わぬところが動かなくなることがあります。

第二に、戻せない更新は、更新しないより危ないから。
直前のバックアップと、元の版に戻す手順がなければ、失敗したときに止まる時間が延びます。

第三に、顧客は「何もなかった」ことを知らないから。
いつ、何を、なぜ更新したかを伝えて初めて、保守の作業が価値として見えます。

パッチ適用の流れ：7つの段階

① 対象を決める：何を、どの版から、どの版へ
② 検証環境で当てる：本番と同じ版の組み合わせで
③ 確かめる：決めた画面と機能を、決めた順に
④ 本番の直前にバックアップを取る：ファイルとデータベースの両方
⑤ 本番に反映する：告知した時間帯に
⑥ 本番で確かめる：③と同じ項目を、短く
⑦ 記録して知らせる：月次報告、または個別の連絡

Composerで入れたライブラリなら、②で更新した composer.lock を確かめ、⑤では本番で composer install を使って同じ版を入れます。本番で composer update は打ちません。

▶ Composerの脆弱性管理、納品時のvendorのまま止めない──composer auditの位置づけ、lockファイル、更新の方針

バックアップは「取っている」だけでなく、戻せることを確かめておく必要があります。

▶ バックアップは「取っている」だけでは保守にならない──復旧テストを年に何回、何時間でやるかを決め、保守の商品と報告に組み込む方法と計算例

戻し方は、反映の前に書いておく

【戻し方のメモ（反映の前に書く）】
対象：〔PHP 8.3.〇 → 8.3.〇／ライブラリ名 〇.〇 → 〇.〇〕
戻す判断の基準：〔③の項目のどれかが動かない〕
戻す方法：〔前の版に戻す命令／前の lockファイル／バックアップから復元〕
戻すまでの目安の時間：〔〇分〕
戻すと決める人：〔担当者名〕

レンタルサーバーで、パッチを事業者が当てる場合は、この流れの②〜⑤を自社で動かせません。
その場合は、事業者のお知らせを見て、反映後に⑥の確認だけを行います。

▶ PHPのパッチは「8.3のまま、末尾の数字を上げる」更新──同じ系列のセキュリティ修正の当て方と頻度、レンタルサーバーとVPSで違う責任の線

今すぐ試せる：サイトごとの確認項目を作るプロンプト

私はWeb制作会社の経営者です。パッチ適用の後に確かめる項目を、サイトごとに作ってください。

【前提】
・サイトの種類（コーポレート、EC、予約、会員制など）：〔記載〕
・主な機能（フォーム、決済、ログイン、検索、メール送信など）：〔記載〕
・外部との連携（決済、地図、メール配信など）：〔記載〕
・確認に使える時間：〔例：15分〕

1. 止まると顧客の売上や問い合わせに響く機能を、上から順に並べる。
2. 各機能について、実際に操作して確かめる手順を1〜2行で書く。
3. 決めた時間に収まるように、項目を絞る。
4. 本番で確かめるときの注意（テストの送信の扱いなど）を添える。

項目は、機能の名前ではなく、操作の手順で書くこと。

本番反映工場：告知の型と、1回あたりの工数

顧客への事前の告知（時間帯を決めて反映するとき）

件名：〔サイト名〕定期のセキュリティ更新のお知らせ（〇月〇日）

〇〇様

いつもお世話になっております。〇〇の〇〇です。

〇月〇日（〇）〇時〜〇時に、サイトを動かすソフトの更新を行います。
弱点の修正を含む更新で、事前に別の環境で動作を確かめています。

作業中、数分ほど表示が遅くなる場合があります。
終了後、フォームなど主な機能の動作を確かめ、ご報告します。

計算例：1回の適用にかかる時間

例：検証環境での適用と確認　1時間
　　バックアップと本番の反映　0.5時間
　　本番での確認　　　　　　 0.5時間
　　記録と報告　　　　　　　 0.25時間
　　合計 1 ＋ 0.5 ＋ 0.5 ＋ 0.25 ＝ 2.25時間

時間単価 8,000円（例）
　　2.25時間 × 8,000円 ＝ 18,000円（1回あたり）

月次の定期作業に含める回数と、緊急で当てる場合の扱いを、保守の契約に書いておきます。

構造的なリスク

逆説を指摘しておきます。

手順を厳しくするほど、1回の適用が重くなり、「次の月にまとめよう」と先送りが増えます。
先送りは、手順がないのと同じ結果を生みます。

だから、手順は2段階にします。外から悪用される弱点の修正は、検証を絞って早く当てる。それ以外は、月次で丁寧に当てる。どちらにあたるかの判断の表は、パッチ管理台帳キットに入れました。

よくあるQ&A

Q. 検証環境を用意する余裕がない。

本番の複製を、別のディレクトリやサブドメインに置くだけでも、何もないよりは安全です。用意にかかる時間を、保守料の見積もりに入れてください。

Q. 告知は、毎回必要か？

表示が止まる可能性がある作業だけで構いません。それ以外は、月次の報告にまとめます。

Q. 戻したあと、顧客にどう伝えるか？

「更新後に不具合を確認したため、元の状態に戻しました。原因を調べ、改めて日程をご連絡します」と、事実と次の予定だけを伝えます。

最後に

パッチの事故の多くは、パッチではなく、当て方の手順がないことから起きます。

確かめ、戻せる状態を作り、記録して知らせる順番を固定した会社だけが、更新を「怖い作業」から、毎月の保守の価値に変えられるのです。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #パッチ適用 #セキュリティ更新 #ステージング #バックアップ #保守契約 #制作会社経営 #中小企業 #本番反映 #脆弱性対策