変更管理台帳の付け方｜いつ・誰が・何を変えたか残す
「この設定、いつ変えたんだっけ」 障害の原因を追っているとき、設定ファイルの日付だけが数日前になっていて、でも自分がなぜ触ったのか思い出せない。心当たりを一つずつ潰しながら、時間だけが過ぎていく。
こんな経験、ありませんか。あるいは「引き継いだシステムに、誰がいつ何をしたのか一切分からない」という人も多いと思います。
これは、あなたの記憶力が悪いからではありません。少人数で日々の対応に追われていれば、自分の変更を全部覚えていられる人なんていません。足りないのは記憶力ではなく、「変えたことを1行だけ残す場所」です。ここが一枚あるだけで、未来の自分は原因までずっと早くたどり着けます。全部を一度に整えなくてOK。今日は、次の1回の変更を1行残すところから始めましょう。
結論：変更管理台帳は「いつ・誰が・何を・なぜ・戻し方」の5つを1行で残す表です。凝ったツールはいりません。まずはスプレッドシート1枚（またはテキスト1ファイル）に、変更したその場で1行足す。これだけで、障害調査の切り分けと引き継ぎが大きく楽になります。
環境や体制（対象システムの数、チームか一人か、既存のチケット管理の有無）で最適な形は変わります。本文はあくまで一例として、自分の現場に読み替えながら、続けられる軽さを優先してください。
何が起きているか：記録がないと「切り分け」で詰まる
障害が起きたとき、最初にやるのは「最近、何か変わっていないか」の確認です。変更管理台帳がないと、この一歩でつまずきます。
- 直前のリリースや設定変更が原因か、それとも外部要因かを切り分けられない
- 「昨日まで動いていた」の"昨日"に何をしたのか、誰も正確に言えない
- 自分が変えたのか、他のメンバーやベンダーが変えたのか分からない
- 復旧しようにも「変更前の状態」が分からず、戻し方を手探りで探す
つまり、記録がないと原因の候補を絞れず、戻すこともできない。これは慎重さの問題ではなく、情報が残っていないだけの問題です。
具体例：台帳があるときと、ないとき
同じ「500エラーが出た」でも、台帳があると景色が変わります。
台帳がないとき：ログを見て、コードを見て、設定を見て……あちこち探して2時間。結局、前日にキャッシュ設定を変えていたのが原因だった。
台帳があるとき：台帳を開くと「昨日18:40、自分、Nginxのキャッシュ有効化、レスポンス改善のため、旧confは conf.bak に退避」の1行。まずここを疑って戻したら復旧。10分。
差を生んだのは技術力ではありません。「変えたことを1行残していたか」だけです。
台帳に残す5項目（これだけでいい）
最低限これだけあれば台帳として機能します。項目を増やしすぎると続かないので、まずは5つに絞ります。
- いつ：日付と時刻（
2026-07-02 18:40のように）。障害のタイムラインと突き合わせるので時刻まで残すと強い。 - 誰が：担当者名。一人でも書く。ベンダー作業なら「〇〇社」。後で問い合わせ先が分かる。
- 何を：対象と変更内容を具体的に。「サーバーA / Nginx / gzip有効化」など、対象・場所・操作が分かる粒度で。
- なぜ：目的や背景。「レスポンス改善のため」「〇〇の問い合わせ対応で暫定対応」。数か月後の自分への説明になる。
- 戻し方：元に戻す方法や退避先。「旧confは
nginx.conf.bakに退避」「1つ前のコミットに revert」。ここが復旧の命綱。
余裕があれば「影響範囲」「関連チケット番号」「確認結果（OK/NG）」を足すと、さらに調査が速くなります。ただし最初は5項目で十分です。
そのまま使えるテンプレート（1行フォーマット）
スプレッドシートなら、こんな列にします。
| 日時 | 担当 | 対象・変更内容 | 目的・背景 | 戻し方・退避先 | 確認 |
|---|---|---|---|---|---|
| 2026-07-02 18:40 | 自分 | サーバーA / Nginx / キャッシュ有効化 | レスポンス改善 | 旧confを nginx.conf.bak に退避 | OK |
テキスト1ファイルで回すなら、1行1変更でこの形でも十分です。
2026-07-02 18:40 | 自分 | サーバーA/Nginx/キャッシュ有効化 | レスポンス改善 | 旧conf→nginx.conf.bak | OK大事なのは形式のきれいさより、変更した「その場」で書けること。凝った書式にすると、忙しいときに書かなくなります。
影響：たった1行が、切り分け・復旧・引き継ぎを助ける
この1行の積み重ねが、あとで効いてきます。
- 障害調査が速くなる：まず「直近の変更」を疑える。原因候補を一気に絞れる。
- 復旧できる：戻し方が書いてあるから、慌てずに前の状態へ戻せる。
- 引き継ぎが楽になる：「このシステム、最近何した？」に台帳一枚で答えられる。属人化がほどける。
- 自分を守れる：「いつ・なぜ変えたか」が残っていれば、後から理由を問われても事実で説明できる。
記録は監査のためだけのものではありません。いちばん助かるのは、半年後・一年後の自分自身です。
続けるコツ：完璧を目指さず「その場で1行」
台帳が続かない一番の理由は、「後でまとめて書こう」として忘れることです。だから、仕組みを軽くします。
- 書く場所を一つに決める：あちこちに分散させない。台帳ファイル（またはシート）を1つに固定。
- 変更作業の"最後の手順"に組み込む：リリース手順やrunbookの末尾に「台帳に1行追記」を入れておくと、忘れにくい。
- 1行で妥協する：きれいな文章より、事実が5項目そろっていること優先。あとから追記でいい。
- 緊急対応こそ書く：焦っているときの変更ほど後で分からなくなる。落ち着いたら必ず1行だけ足す。
「完璧な台帳」より「今日から続く台帳」。空欄があってもいい。まず書き始めることが、いちばん価値があります。
明日やること
- 台帳の置き場所を1つ決める（スプレッドシート1枚 or テキスト1ファイル）
- 列（項目）を「日時／担当／対象・変更内容／目的／戻し方／確認」の6つで作る
- 次に何か設定やコードを変えたら、その場で1行足す
- 既存のリリース手順書やrunbookの末尾に「台帳へ1行追記」を追加する
今日のチェックリスト
- 変更を記録する場所を1つに決めた
- 「いつ・誰が・何を・なぜ・戻し方」の5項目を残す形にした
- 変更した「その場」で書くルールにした（後回しにしない）
- 戻し方・退避先を必ず書くようにした
- 緊急対応の変更も、落ち着いたら1行残すと決めた
- リリース手順の末尾に「台帳へ追記」を組み込んだ
最初の1行は、たぶん「今日、これを変えた」だけで十分です。その1行が、次の障害のときのあなたを助けてくれます。完璧な管理じゃなくていい。変えたことを、未来の自分に一言だけ残しておきましょう。
関連記事
保守運用の実務ヒントを、メールでお届けしています。よかったら受け取ってください。