WordPress保守の月次チェックリスト|報告書と引継ぎの書き方

毎月のWordPress保守。点検・報告・引継ぎ

本記事はアフィリエイト広告を含みます。

月次保守は、更新・動作・復元準備・異常・期限を同じ順番で見て、未解決事項を次の担当へ渡す作業です。「問題なし」だけでなく、対象と日時と結果を残すと、前月から何が変わったかを判断できます。

この記事では、小規模な企業サイトや顧客サイト向けに点検表と報告の書き方をまとめます。掲載例は実在サイトの点検実績ではなく、自サイトのフォームや連携へ合わせる記入例です。

Index

月次表は「実施」と「結果確認」を分けて書く

一つの作業を一行にし、実施した操作と結果を分けて記入します。未実施、未確認、対象外を区別すれば、作業をしただけの項目を完了と取り違えずに済みます。

対象/実施・確認内容/残す証拠/状態・次の担当

更新

実施・確認内容:WP・テーマ・プラグインの変更

残す証拠:前後のバージョン、作業日

状態・次の担当:完了/保留と理由

機能

実施・確認内容:表示、入力、通知、保存

残す証拠:対象URL、確認結果

状態・次の担当:未確認項目を分ける

バックアップ

実施・確認内容:保存時点と復元範囲

残す証拠:取得日、保管先、復元手順

状態・次の担当:実行できる担当者

診断

実施・確認内容:種類、対象、日時、指摘

残す証拠:結果の記録

状態・次の担当:対応者と期限

契約

実施・確認内容:更新日、通知先、権限

残す証拠:管理者と確認日

状態・次の担当:変更が必要な項目

状態はチームで意味を揃え、保留には理由、担当、期限を付けます。「依頼中」のまま毎月コピーせず、回答待ちなのか検証待ちなのかまで分けると次の行動が決まります。

この表は月次の振り返りに使います。重大な警告やサイト停止は月末を待たず、発生時に連絡・判断してください。

更新とバックアップは結果まで残す

更新記録には、名前だけでなく変更前後の版、実施日時、作業者、確認した機能を残します。問題が起きた際に、どの変更の前まで正常だったかを追うためです。

WordPress公式は更新前のバックアップを案内しています。バックアップの有無を確認する際は、ファイルとデータベースを区別し、戻したい状態が含まれるかを見ます。WordPress公式の更新手順

フォーム更新の記入例なら、「ページ表示済み」でなく、入力エラー、送信完了、通知受信、保存まで実施した範囲を残します。実施できなかった操作は未確認として次の担当へ渡します。

検証環境でメールを送れない場合は「入力・保存は確認、通知到達は未確認」と記入します。未確認の通知テストには、本番で実施する担当と日時を付けてください。

一つの機能確認資料から、確認した部分と未確認の部分を別の札で残す図
確認できた範囲と未確認の範囲を分けます。一つの完了印だけでは違いが残りません(イメージ図)。

バックアップの「毎日取得」と「今月復元を試した」は別の欄に書きましょう。復元テストをしていなければその旨を残し、必要な時点のデータと操作権限を確かめます。

具体的な更新前後の項目は、プラグイン更新のチェック手順を基に自サイト用へ調整できます。

更新以外に、容量・リンク・権限・公開情報も見る

主要ページのリンク切れ、画像の欠落、容量やエラーログの増加、使わない管理者権限、サーバー・ドメイン・証明書の期限を点検項目に加えます。すべてを毎月変更するのではなく、異常や期限を見つけたら対応へ回すための確認です。

料金、営業時間、担当者、キャンペーンなど公開情報の期限も確認します。サイトが動いていても古い案内で問い合わせを受ける可能性があるため、システム点検と内容の更新を別の担当欄へ分けましょう。

SiteLock(GMO)PR

保守で足りない診断範囲を補う

更新と復元の担当が決まり、公開ページやファイルの診断を追加したい場合は、SiteLockの対象範囲と年額を比較できます。診断後に結果を読む担当も用意しましょう。

公式サイトで料金・利用条件を確認

利用前に標準SiteLockは診断ツールです。顧客向け報告書の作成や保守代行を含む契約とは異なります。

診断通知は未解決のまま埋もれさせない

診断通知は対象と内容を照合し、同じ問題の再通知なら一つの記録へ追記します。検知、判断、修正、再確認をつなげることで、通知だけ読んで未解決の問題を見失うのを防げます。

記録例/書く内容

指摘

書く内容:診断日時、種類、対象URL・ファイル

判断

書く内容:対応が必要か、追加調査が必要か

作業

書く内容:更新、設定変更、確認依頼など

再確認

書く内容:診断結果と主要機能の確認

残件

書く内容:未解決の理由、担当、次回確認日

SiteLockの標準サービスでは、利用者が診断結果を確認して運用します。正式な書面報告やスタッフによる報告会を標準契約に含む前提で、顧客への納品物を約束しないようにします。SiteLockの公式FAQ

ツールの出力を添付するときは、実施日と対象範囲も見てください。実行待ちや対象外ページを説明する欄があれば、結果の読み違いを防げます。

SiteLockの操作と結果の区別は、診断結果の読み方で確認できます。

月次・更新直後・緊急時で確認頻度を分ける

月次表は定期的な棚卸しです。フォームを変更した直後はその動作を、重大な脆弱性や改ざんの兆候があるときは影響範囲を、その時点で調べます。全項目を月末まで待つ運用にはしません。

自分で原因と戻し方を説明できない変更は、保守担当へ相談する対象です。外注する場合は更新作業、動作確認、緊急対応、報告、契約外費用を分けて見積もりを取り、「保守一式」の言葉だけで依頼範囲を決めないようにします。

顧客へ出す報告書に整理する

報告の先頭は、業務への影響、対応したこと、残る問題、判断してほしいことの順にします。版番号やログは後へ置き、顧客が承認や対応を決める材料を先に示します。

たとえば、次のような形式にできます。

今月の変更
・対象プラグインを更新。作業日とバージョンは別表に記載。

確認した機能
・記事表示、メニュー移動、問い合わせ入力を確認。
・通知メールは未確認。次回確認日と担当を記載。

残っている作業
・診断の指摘について、対象機能の対応方法を調査中。

判断を依頼すること
・修正作業の実施時間と、受付を止める必要の有無。

記入例を使う際も、実際に行っていない作業や確認していない結果を実績欄へ移してはいけません。

顧客に伝える表現は「確認した範囲では指摘なし」のように、範囲と結果を合わせます。「完全に安全」といった言い切りや、スキャン結果だけを根拠にした復旧完了の断定は避けます。

認証情報や個人情報をそのまま報告書へ貼らず、必要な内容に絞って共有先を決めることも、月次作業の一部です。

翌月へ渡す項目を決める

翌月は新しい点検の前に前月の未解決行を読みます。期限が来た項目を再確認し、保留が続くなら理由と次回日を更新することで、報告を実際の対応へつなげます。

警告が届かなかった月も、ただ「異常なし」とは書きません。確認した範囲と日時を示し、未確認箇所は担当者と期限を付けて翌月へ渡します。解決済みの指摘には再確認日を添えましょう。

まずは更新と復元準備を継続し、そのうえで足りない範囲が見えたら外部診断を検討します。

保守の役割を見直すときは予防・検知・復旧の役割整理、国内プランの対象と費用を比べるときはSiteLockの料金表へ進めます。

引継ぎでは、未解決事項に加えて、契約更新日・通知先・復元権限を確認します。担当者が変わった後も通知を受け、必要なバックアップへアクセスできることまで確かめます。

前月の資料から、担当札の付いた未解決カードを次の月の資料へ渡す図
未解決の項目は、理由・担当・次の確認を付けて翌月へ引き継ぎます(イメージ図)。
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

個人でWordPressブログを運営しています。WordPress歴7年。実際に契約・利用しているConoHa WINGとSWELLを中心に、ブログの開設、表示・編集環境の改善、SEO、アフィリエイト、AIを使った制作効率化を検証しています。

公式情報を確認するだけでなく、実機で試した結果、うまくいかなかった点、向かないケースも含めて共有します。読者が遠回りせず、自分のブログで次の一手を選べる情報を届けることが目標です。

Index