パッチ管理台帳のテンプレート、制作会社の保守キット──列設計、月次運用表、月次報告の型、緊急パッチの判断表、告知文例、AIプロンプト

この記事は、パッチ管理台帳を中心に、保守しているサイトのPHP・フレームワーク・ライブラリの更新を、毎月同じ型で回すためのキットを扱います。

パッチの当て方、ライブラリの照合、サポート終了の棚卸しの考え方は、無料の記事で扱っています。

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

メンバーシップ「黒字化オペ室」では、これまでの有料記事を全て読めます。価格、外注、採用、給与を、一本の流れとして。

月額1,980円、単品記事2本分の金額です。合わなければ、いつでも退会できます。詳しくはプロフィールから。

更新の記録が、担当者の頭の中にしかない

「あのサイトのPHP、先月上げましたっけ」
「Laravelの版は、たしか12だったと思います」

保守の更新を、担当者の記憶とチャットの履歴で回している会社は少なくありません。
担当者が休めば止まり、辞めれば消えます。顧客に聞かれても、その場で答えられません。

本当に困るのは、深刻な弱点が公表された日です。
「うちの保守先で、その版を使っているのはどこか」を調べるだけで、半日が消えます。そのあいだ、本来の制作の仕事は止まったままです。

しかも、その半日の作業は、たいてい保守料の外で、誰にも請求されずに終わります。
記録がないことは、守りの弱さであると同時に、利益の漏れでもあるのです。

パッチ管理台帳とは、サイトごとの部品の版、サポート終了日、照合の結果、適用の履歴を一か所に残し、毎月の作業と顧客への報告の元にする表である

黒字化の外科医です。保守の更新を、担当者の記憶から台帳へ移す型を解剖します。

台帳で回すべき理由は、三つあります。

第一に、更新の対象が、サイトの数と部品の数の掛け算で増えるから。
20サイトにそれぞれ5つの部品があれば、追う対象は100行です。記憶で回せる量ではありません。

第二に、緊急の判断に、平時の記録が要るから。
深刻な弱点が公表された日に、「どのサイトがその版を使っているか」を台帳から引ければ、影響の範囲は数分でわかります。

第三に、顧客への報告は、台帳の写しで作れるから。
台帳の今月の行を抜き出せば、月次報告の大半ができあがります。報告のために別の作業をしなくて済みます。

パッチ管理台帳で追う対象：PHPだけでは足りない

台帳に載せるのは、PHPの版だけではありません。
OS、データベース、CMS、フレームワーク、Composerなどで入れたライブラリまで、サイトを支える部品をすべて1行ずつ並べます。

部品ごとに、確かめる場所も違います。
PHPなら php.net の Supported Versions、Laravelなら公式のリリースノート、ライブラリなら composer audit の照合の結果です。台帳には、日付と一緒に「どこで、いつ確かめたか」を残します。

今すぐ試せる：今の保守先から台帳の初期データを作るプロンプト

私はWeb制作会社の経営者です。保守しているサイトの情報から、パッチ管理台帳の初期データを作ってください。

【前提】
・サイトの一覧（サイト名、顧客名、サーバーの種類）：〔記載〕
・わかっている部品と版（PHP、CMS、フレームワーク、データベース、主なライブラリ）：〔記載〕
・保守契約で自社が更新を引き受けているかどうか：〔記載〕

1. 1行＝1サイトの1部品として、表に並べる。
2. 列は「サイト名、部品、今の版、更新する人、サポート終了日、確認した日」とする。
3. 版やサポート終了日がわからないものは「要確認」と書く。
4. 「更新する人」が決まっていない行を、最後にまとめて示す。

サポート終了日や版を推測で埋めないこと。

このプロンプトで、まず「わかっていないこと」の一覧が手に入ります。台帳づくりは、そこから始まります。

ここから先に、台帳の列設計、月次運用表、顧客向け月次報告の型、緊急パッチの判断表、告知文例、AIプロンプト一式を置きます。