ホームページの変更履歴を残す方法｜更新内容・担当・戻し方の記録

ホームページの変更履歴は、「いつ、誰が、どのページを直したか」だけでは不十分です。問題が起きたときに、変更の目的、変更前後、承認、確認結果、使用したバックアップ、戻す手順まで追えなければ、履歴があっても復旧や説明に使えません。複数人や外部の制作会社が更新するサイトでは、CMSのリビジョンに加えて、変更単位の台帳を一つ持つことが基本になります。

一件の変更には、実施日時、作業者、対象URL・機能、目的、変更前、変更後、承認者、バックアップ、確認結果、戻し方、関連チケットを残します。すべてを長文で書く必要はありません。重要なのは、後から別の人が見ても「何を基準に変更し、どこまで確認し、問題時に何を戻すか」が分かる並びにすることです。

変更履歴の目的は、作業を数えることではなく判断と復旧をつなぐこと

変更履歴を作るとき、最初に「更新した件数を集計する表」を思い浮かべると、日付と作業名だけの一覧になりがちです。しかし、運用で本当に困るのは、件数が分からないことより、変更の理由や影響範囲が分からず、元に戻す判断ができないことです。履歴は、作業報告の保管場所ではなく、判断と復旧をつなぐ記録として設計します。

後から履歴を開く場面は主に三つあります。一つ目は、表示崩れやフォーム不達などの問題が起き、直前の変更を確認するときです。二つ目は、担当者や制作会社が変わり、現在の仕様へ至った理由を引き継ぐときです。三つ目は、施策の反応を振り返り、どの変更と数字の動きが近いかを確かめるときです。どの場面でも、変更内容だけでなく、目的、承認、確認、復元点が必要になります。

履歴は責任追及のために作るものではありません。「誰が悪かったか」ではなく、「誰が事業上の内容を承認し、誰が作業し、誰が公開後を確認したか」を役割として分けます。役割が分かれば、問題が起きたときに次に連絡する相手と、確認すべき資料を早く特定できます。

最初に決めるのは「何を一件とするか」

変更履歴が続かない大きな原因は、記録項目の多さより「どこまでを一件として書くか」が曖昧なことです。基本は、一つの目的で実施し、同じ承認と同じ戻し方を使う変更を一件にします。別の目的、別の承認者、別の復元方法が必要なら、同じ日に作業しても分けます。

• 文章・画像の更新：お知らせ、サービス説明、料金表、スタッフ情報、実績、写真の差し替えなど
• 構造・見た目の変更：メニュー、共通ヘッダー、導線、部品、テンプレート、CSSなど
• 機能・設定の変更：フォーム、通知先、ユーザー権限、プラグイン、計測タグ、検索表示設定など
• 基盤・外部サービスの変更：サーバー、PHP、データベース、DNS、SSL、予約・決済・地図・メール連携など

たとえば、同じ料金改定に合わせてサービスページ、料金ページ、よくある質問を同時に直す場合は、承認元と公開日が同じなら一件にまとめられます。一方、料金表の文章変更と、決済サービスの税設定変更は、見た目では同じ改定に見えても、作業場所と戻し方が異なるため分けた方が安全です。

誤字一文字の修正まで毎回重い記録にすると、台帳が負担になります。同じページで同じ目的の軽微な修正をまとめる、定型更新は簡易項目にするなど、影響に応じて記録の深さを変えて構いません。ただし、料金、受付条件、個人情報、フォーム、権限、計測、外部連携、サイト全体へ影響する変更は、少なくとも承認、確認、戻し方まで残します。緊急修正で先に作業した場合も、終わった後に実施時刻と判断理由を追記します。

一件の変更に残す11項目

最小項目は、変更を特定する情報、意図と差分、承認と確認、復元に必要な情報の四つに分けると覚えやすくなります。次の表をそのまま列名にしてもよいですが、利用中の表計算やチケット管理へ合わせ、同じ意味の項目を一か所にそろえることを優先してください。

項目	残す内容	記入の要点
実施日時・公開日時	作業を行った時刻と公開した時刻	予約公開や段階公開では両方を分ける
作業者	実際に変更した人・会社	共有アカウント名だけで終わらせない
対象URL・機能	ページ、共通部品、設定、外部サービス	URLがない設定変更も特定できる名称を書く
目的・理由	何を解決し、何を変えないか	依頼文の転記だけでなく判断理由を短く残す
変更前	以前の文言、設定、表示、版	削除前の情報を消さず、比較できる形にする
変更後	公開した文言、設定、表示、版	予定ではなく実際に反映した内容を書く
承認者・承認日時	事業上の内容を公開可とした人・時刻	作業者の自己判断と区別する
バックアップ・復元点	取得時刻、範囲、保管場所、識別子	「バックアップあり」だけで終わらせない
確認者・確認結果	表示、動作、受信、計測などの確認	確認端末や未確認範囲も分けて書く
戻し方	戻す対象、手順、判断者、連絡先	全体復元か部分修正かを明記する
関連チケット	依頼、障害、問い合わせ、承認資料へのリンク	会話や証拠を探し直さず追えるようにする

「重要度」「次回確認日」「公開状態」などは、運用に必要なら追加します。ただし、最初から列を増やしすぎると未入力が増えます。まず11項目で三件ほど試し、毎回空欄になる項目は入力方法を簡単にし、問題時に探した情報があれば追加する方が実用的です。

対象はURL・画面・設定の三層で特定する

対象欄へURLだけを書くと、文章更新には使えても、共通部品や管理画面の設定変更を追えません。対象は「公開先」「変更した場所」「技術的な識別子」の三層で書くと、非技術担当者と制作会社のどちらも同じ変更を探しやすくなります。すべての変更で三層を埋める必要はありませんが、URLだけで場所が一意に決まらないときは補います。

• 公開先：/contact/、全ページ、特定のキャンペーンページなど、利用者が見る範囲
• 変更した場所：問い合わせフォーム、ヘッダー共通部品、通知設定、テーマ、計測設定など
• 技術的な識別子：テンプレート名、フォームID、設定画面名、ファイル名、コミットやチケット番号など

記入例は「/contact/｜問い合わせフォーム｜通知先設定」「全ページ｜ヘッダー共通部品｜電話ボタン」「計測全体｜アクセス解析｜フォーム送信イベント」のようになります。担当者が専門用語を知らない場合は、管理画面の画面名とスクリーンショットでも構いません。制作会社側は必要に応じてファイル名や設定IDを追記します。

外部サービスを記録するときは、サービス名、対象アカウント、変更した設定名までにとどめ、パスワード、秘密鍵、個人情報、決済情報を台帳へ直接書かないでください。認証情報は事業で決めた安全な保管場所へ置き、変更履歴からは保管場所の名称や管理担当だけを参照します。

変更前後は、全文ではなく差分と確認材料を残す

変更前と変更後は、長いページ全文を二つ貼り付けることが目的ではありません。後から「どこが変わったか」を特定できる最小の差分と、その差分を確かめる材料を残します。文言なら旧文と新文、画像なら旧ファイル名と新ファイル名、設定なら変更前の値と変更後の値、コードなら版やコミットを対応させます。

スクリーンショットは見た目の確認に便利ですが、画像だけでは検索しにくく、画面外の設定や動作も分かりません。「料金表の見出しを変更」「フォームの通知先を引き継ぎ用の配信先へ変更」のような短い要約を必ず添え、必要な場合に変更前後の画像や承認原稿へリンクします。画像には取得日時と対象URLが分かる名前を付けると、後から並べやすくなります。

目的欄には「依頼されたため」ではなく、判断の背景を一文で書きます。たとえば「担当交代後も問い合わせを受け取れるようにする」「サービス名の確定に合わせ、検索結果とページ内表記を統一する」です。変更しなかった範囲も重要で、「送信項目と自動返信文は変更しない」と残せば、次の確認者が不要な範囲まで疑わずに済みます。

料金や受付条件など適用日がある情報は、公開した日と条件が有効になる日を分けます。公開前に告知する場合、変更後の内容だけを書いても「いつからの条件か」が分かりません。変更履歴には、公開日時、適用日、旧条件を残す期限を対応させます。

作業者・承認者・確認者を分ける

一件の変更には、少なくとも三つの役割があります。作業者は管理画面やファイルを変更する人、承認者は事業内容や公開可否を判断する人、確認者は公開後の表示や動作を確かめる人です。小さな組織では一人が兼ねても構いませんが、「同じ人が三役を兼任」と記録すれば、役割が存在しない状態と区別できます。

外注先が作業する場合も、制作会社名だけで終わらせず、依頼側の承認者と、実際の確認者を残します。制作会社が技術的に正常と確認しても、料金、対象地域、営業時間などの事業情報が正しいかは依頼側の判断が必要です。反対に、依頼側が見た目を確認しても、フォーム受信やキャッシュ、計測、サーバー設定まで確認したことにはなりません。

更新体制や必要な権限そのものが整理できていない場合は、先にWordPressでホームページを依頼する前に決めること｜更新・権限・保守の整理表で、日常更新、設定変更、技術保守の担当範囲を分けると、変更履歴へ誰の名前を残すか決めやすくなります。

バックアップと戻し方はセットで書く

「作業前にバックアップ済み」という記録だけでは、実際に戻せるか判断できません。バックアップ欄には、取得時刻、対象範囲、保管場所、識別子、保存期限を残します。戻し方欄には、何をどの状態へ戻すのか、誰が判断し、誰が実行するのか、最初に止める作業や連絡先まで書きます。

WordPressでは、サイトを構成するファイルとデータベースが別に保存されています。WordPress公式のバックアップ案内も、ファイルとデータベースの両方が必要であることを説明しています。プラグイン更新やテーマ変更のように両方へ影響し得る作業では、「ファイル一式」「データベース」「取得時刻」を一つのバックアップセットとして識別できるようにします。

一方、文章一か所の誤りなら、サイト全体を復元するよりCMSのリビジョンから該当ページだけ戻す方が安全な場合があります。全体復元をすると、バックアップ取得後に届いた問い合わせ、追加された注文、公開した記事などまで以前の状態へ戻る可能性があります。戻し方には「ページの本文だけを一つ前へ戻す」「フォーム設定だけを旧値へ戻す」「サイト全体の復元は制作会社判断」のように範囲を書きます。

バックアップの保存に成功したことと、復元できることは同じではありません。少なくとも保管場所へのアクセス、対象ファイルの存在、復元手順の担当者は定期的に確認します。重要な変更では、公開前にテスト環境へ戻せるかを確かめる、または利用中の保守会社へ復元方法と所要条件を確認しておくと、緊急時の判断が早くなります。

CMSのリビジョンと変更台帳は役割を分ける

CMSのリビジョンは、変更台帳の代わりではなく、台帳へ結びつける復元材料です。WordPress公式のリビジョン案内では、投稿や固定ページの保存履歴を比較し、以前の版へ復元できることが説明されています。WordPressが標準で追うのは投稿単位のタイトル、作成者、本文、抜粋などで、フォーム通知先、テーマ、プラグイン、DNS、外部サービス、変更理由や承認まで一件の業務記録としてまとめる機能ではありません。

他のCMSにも更新履歴やアクティビティーログがありますが、保存対象、保持数、復元範囲は製品や契約によって異なります。自動記録がある場合は、日時、利用者、版番号を台帳へ転記するのではなく、該当履歴へのリンクや識別子を残します。台帳には、自動ログが持ちにくい目的、承認、公開後確認、戻す判断を記録します。

使い分けは単純です。本文や画像の差分を見たいときはCMSのリビジョン、変更の背景と影響範囲を知りたいときは変更台帳、サイト全体を戻す必要があるときはバックアップを見ます。この三つを同じ変更IDで結べば、目的を確認してから適切な復元手段を選べます。

障害・問い合わせ・分析を変更履歴に結びつける

表示崩れやフォーム不達が起きたときは、発生時刻に近い変更を探します。ただし、時間が近いだけで原因と断定しないことが大切です。対象URL、機能、変更前後、確認結果を見て、再現条件と一致するかを確かめます。別の障害、外部サービスの停止、端末やキャッシュの影響もあり得るため、「関連の可能性」と「原因確定」を分けて記録します。

問い合わせ、障害管理、制作会社への依頼、チャットの承認が別のツールにある場合は、変更履歴へURLや番号を残します。長い会話をすべて貼る必要はありません。「問い合わせで旧料金の表示を指摘」「監視でフォーム送信エラーを検知」「承認チケットで新しい受付条件を確定」のように関係を一行で要約し、詳細へ移動できるようにします。

アクセス解析と照らす場合は、変更日だけでなく、計測設定を変えたかどうかも残します。フォーム送信数が増減していても、ページの改善による変化なのか、計測イベントの変更なのかを分けられなければ評価できません。施策の目的、公開日、計測変更、振り返る時期を結ぶと、数字を見たときの解釈が安定します。成果を保証するためではなく、同じ条件で比較するための記録です。

架空の記入例

項目	記入例
実施・対象	2026年8月11日14時／問い合わせページ／フォーム通知設定
目的	担当交代後も問い合わせを受信できる状態へ切り替える
変更前後	旧配信先から新しい共有配信先へ変更。入力項目と自動返信文は変更なし
承認・作業・確認	総務責任者が承認、制作会社が作業、Web担当者がテスト送信と受信を確認
バックアップ	作業前のデータベースとフォーム設定画面を同じ変更IDで保管
戻し方	受信できない場合は旧配信先へ戻し、原因調査中は電話窓口を案内
関連記録	担当交代の依頼チケット、テスト送信結果、障害があれば障害番号を追加

この例では、実際のメールアドレスや認証情報を台帳に書かず、何を変えたかと、どの条件で戻すかだけを追えるようにしています。作業後に問題がなければ確認結果を確定し、未確認の端末や残課題があれば「問題なし」にまとめず別に残します。

続けられる管理場所と運用ルールを決める

変更履歴の管理場所は、表計算、プロジェクト管理ツール、チケット管理、コードのリポジトリなど、現在の体制に合うもので構いません。重要なのは、同じ種類の変更がメール、個人メモ、チャット、表計算へ分散しないことです。正式な台帳を一つ決め、他のツールには詳細を置いて、台帳から参照します。

入力は作業前と作業後の二回に分けると無理がありません。作業前に目的、対象、承認、バックアップ、想定する戻し方を入れ、作業後に実際の変更内容、公開時刻、確認結果、関連記録を確定します。作業前だけで終わると予定表になり、作業後だけで書くと承認や復元点が抜けやすくなります。

1. 最近行った更新を三件だけ選び、どの情報を探し直したか確認する
2. 一件の単位と11項目を、現在使っている管理ツールへ作る
3. 次の三件を実際に記録し、入力に迷った項目を修正する
4. 制作会社や社内担当と、承認・確認・復元の担当を共有する
5. 障害や担当変更が起きたときに台帳から追えたかを見直す

定型更新では、担当者、対象、確認方法をテンプレート化できます。反対に、重要な設定変更は、承認者と戻し方を必須入力にします。すべての変更へ同じ重さを課すのではなく、影響範囲に応じて必須項目を増減させると、記録を省略せず運用しやすくなります。

台帳そのものも定期的に見直します。担当者名が古い、リンク先のチケットへアクセスできない、バックアップの保存期限が切れている、復元担当が不在といった状態では、記録が残っていても使えません。担当交代、保守会社変更、CMSやサーバー移行のタイミングでは、台帳の保管場所と権限、過去履歴の引き継ぎを確認します。

まとめ｜変更ごとに、理由から戻し方まで一つにつなぐ

ホームページの変更履歴は、日時と作業名の一覧ではなく、変更の判断と復旧を支える台帳です。一件ごとに、作業者、対象URL・機能、目的、変更前後、承認者、バックアップ、確認結果、戻し方、関連チケットを結びます。URLがない設定や外部サービスも対象にし、CMSのリビジョン、変更台帳、バックアップを役割分担させます。

最初から完璧な仕組みにする必要はありません。次の三件を同じ書式で記録し、問題時に探した情報と、毎回入力しにくい項目を見直してください。別の担当者が履歴を開き、「なぜ変えたか」「どこまで確認したか」「どこへ戻せばよいか」を判断できれば、変更履歴は運用に使える状態です。