他社制作ホームページの保守を引き継ぐ前に確認したいこと
他社が制作したホームページの保守を引き継ぐとき、最初に必要なのは「管理画面のIDとパスワード」だけではありません。誰が何を所有し、どのサービスが連携し、障害時にどこから復旧できるのか。見えていない前提を一つずつ確認することが、安全な運用の出発点です。
引き継ぐのは、サイトを動かす関係全体です
ドメイン、DNS、メール、サーバー、CMS、ソースコード、外部サービス、契約、計測、問い合わせ通知は互いにつながっています。アクセス情報、所有者、依存関係、復旧手段、保守の境界を同じ一覧で確認すると、急な停止や更新時の行き違いを減らしやすくなります。
1. 「保守の引き継ぎ」と「移行・再構築」を分ける
現在の環境を維持しながら更新や監視を引き継ぐのか、別のサーバーへ移すのか、CMSやテーマを作り直すのかで、必要な調査とリスクは異なります。現状調査の結果、古い実行環境、権利不明の素材、更新できない部品などが見つかれば、保守だけではなく移行や段階的な再構築を検討することもあります。最初から同じ作業だと決めつけず、目的と変更範囲を分けて扱います。
2. 所有者と契約名義を一覧にする
ログインできることと、自社が契約・管理できることは同じではありません。更新や解約、担当変更、障害連絡が必要になったときに動けるよう、次の項目を確認します。パスワードそのものを共有表に書くのではなく、安全な受け渡し方法と保管先を別に決めます。
| 確認対象 | 記録しておきたい内容 |
|---|---|
| ドメイン・DNS | 登録事業者、契約名義、更新日、管理できる担当、メールなどへの影響 |
| サーバー・CDN | 契約主体、プラン、請求、実行環境、管理窓口、停止時の連絡先 |
| CMS・ソース | 管理権限、リポジトリや原本の所在、公開方法、独自機能の担当 |
| 素材・ライセンス | 写真、書体、プラグイン、外部コードの利用条件と更新主体 |
| 外部サービス | フォーム、メール配信、予約、決済、地図、解析などの契約と連携先 |
3. サイトの依存関係を見えるようにする
一つの設定変更が、思わぬ場所に影響することがあります。DNSの変更がメールに、プラグイン更新がフォームに、Cookie設定が計測に影響する例です。サービス名だけでなく、「何のために使うか」「止まると何が起きるか」「誰が判断できるか」を簡単な構成図や台帳にします。分からない項目は、推測で埋めず未確認として残すことが大切です。
4. バックアップを「ある」から「戻せる」へ
バックアップの保存先、対象、頻度、保持期間だけでなく、誰が復元を実行できるか、復元すると問い合わせや注文などの新しいデータを失わないかを確認します。可能であれば、本番へ影響しない方法で復元手順を確かめます。すべてのサイトに同じ復旧方法が使えるわけではないため、構成に合わせた判断条件を残します。
5. アクセス権を安全に受け渡す
共通アカウントを増やすより、必要に応じて個別アカウントを発行し、役割に合う権限を設定します。元担当者や制作会社の権限をいつ変更するか、二要素認証や復旧先を誰が管理するかも確認します。引き継ぎ完了後は、不要になった権限と古い連絡先を整理します。
6. 問い合わせと計測を実際に試す
画面が表示されるだけでは、サイトが機能しているとは限りません。問い合わせを送信し、通知の到着、返信先、迷惑メール対策、同意文、完了画面を確認します。電話リンク、予約、決済、資料ダウンロードがあれば同じように試します。解析とSearch Consoleは、閲覧と検索の異なる側面を見るため、設定や管理者を分けて記録します。
7. 「ホームページ保守に何を含むか」を合意する
保守という言葉には、更新、監視、バックアップ、軽微な修正、原稿作成、SEO、問い合わせ対応などが混ざりやすくなります。対象、頻度、連絡方法、対応時間の考え方、別途判断になる作業を具体的にします。調査前に対応可否を断定できない項目がある場合は、その確認手順も合意しておくと、運用後の認識差を抑えられます。
| 保守項目 | 決めておくこと |
|---|---|
| 更新・監視 | 対象、頻度、確認方法、問題時の判断者 |
| バックアップ・復旧 | 対象データ、保存先、復旧条件、復旧時のデータ扱い |
| コンテンツ変更 | 依頼方法、原稿・素材の担当、確認者、公開手順 |
| 障害・緊急連絡 | 連絡窓口、優先度、初動の範囲、第三者サービスへの連絡主体 |
| 改善・追加開発 | 保守内で扱う範囲と、別途調査・提案になる条件 |
引き継ぎ開始時のチェックリスト
- 保守、移行、再構築のどれを想定しているかを分けた
- ドメイン、DNS、サーバー、CMS、外部サービスの所有者を確認した
- ソース、素材、ライセンスと利用条件を確認した
- 依存関係と、停止時に影響する機能を記録した
- バックアップの対象と復元方法を確認した
- 個別アカウント、権限、二要素認証、復旧先を整理した
- 問い合わせ、通知、主要な導線を実際にテストした
- 保守に含む範囲、確認方法、別途判断になる作業を合意した
サーバーやURLも変更する場合
保守の担当変更とサイト移行を同時に行うと、原因の切り分けが難しくなることがあります。URL、リダイレクト、検索流入、フォーム、公開判断を含む移行計画は、別の作業として確認してください。
START WITH WHAT IS KNOWN
資料がそろっていなくても、分かる範囲から整理できます。
サイトごとに構成や権利、対応可否、必要な調査は異なります。現在分かっている契約や困りごとを起点に、保守引き継ぎの確認事項を整理します。
確認日・参考情報
2026年8月20日確認。権限設計の基礎としてWordPress公式のRoles and Capabilitiesを参照しています。サイトの構成と契約条件によって必要な確認は異なるため、本記事は個別環境の安全性や復旧を保証するものではありません。
