制作会社を変更するときのホームページ引き継ぎ｜権限・データ・復元の確認表

ホームページの制作会社を変更するとき、「データを受け取れば引き継げる」と考えると、公開後に必要な情報が不足することがあります。画面を表示するファイルがあっても、ドメインの更新ができない、問い合わせメールの設定が分からない、解析データを閲覧できない状態では、安心して運用を引き継げません。

引き継ぎの目標は、新しい担当者がサイトを理解し、必要な権限で管理し、不具合が起きたときにも対応できる状態を作ることです。本記事では、中小企業の経営者やWeb担当者に向けて、契約と資産の整理から、バックアップの復元、移行当日の確認までを説明します。WordPressなどの公式資料とGitLabが公開した障害報告を参照し、実務の判断に使える確認表に落とし込みます。

最初に「何を変更するのか」を分けて考える

担当会社の変更と、サーバー移転は同じではない

制作や保守を担当する会社が変わっても、必ずサーバーを移すとは限りません。現在の契約を自社で維持したまま、更新作業だけ新しい会社へ依頼する場合もあります。一方、前の制作会社が契約する共用の環境にサイトがある場合は、自社専用の契約や新しい保守環境へ移す必要が生じることもあります。まず変更の理由と、変更しなければ解決しない範囲を整理します。

「対応が遅い」という課題なら、更新の受付方法や担当体制の見直しが中心になるかもしれません。「古い環境で更新できない」という課題なら、動作環境やソフトウェアの調査が必要です。見た目の刷新、コンテンツの整理、サーバー移転まで同時に広げると、工数も確認事項も増えます。引き継ぎに必要な作業と、改善のために追加したい作業を分けて見積もりを受けます。

ドメイン、DNS、Web、メールの担当を確認する

ドメインはサイトやメールに使う名前、DNSはその名前を各サービスの接続先に結び付ける仕組みです。Webサイトとメールが同じ会社で契約されているとは限らず、請求が一括でも設定を変更する管理画面は別ということがあります。「サーバーの会社」という呼び方だけで済ませず、どのサービスをどこで管理しているかを一覧にします。

ドメインの登録管理会社を変える移管も、サイトのデータ移動とは別の手続きです。ICANNのドメイン移管に関する公式FAQでは、登録管理会社間の移管や、移管を制限する条件が説明されています。すべてのドメインに同じ条件が適用されると考えず、利用中の種類と登録事業者の案内を確認します。更新期限が近い場合は、作業順も事業者に確かめて決めましょう。

契約や設定の用語から整理したい場合は、ドメイン・サーバー・DNS・メールの基本と管理表をご確認ください。名前の登録、Webの配信、メールの利用を分け、更新期限と変更担当を調べる手順を説明しています。

窓口を一本にし、判断する人を決める

旧制作会社、新制作会社、サーバー会社、社内担当者が別々に進めると、誰かが変更したことを他の人が知らない状態になります。窓口を決め、依頼と回答を一つの記録に集めます。操作担当とは別に、費用の承認、停止時間の判断、公開への切り替えを決める人も明確にします。技術的な作業が進んでいても、社内の判断が必要な箇所で止まらないようにするためです。

予定表には、「調査完了」「新環境で確認」「切り替え」「旧環境の保管終了」を別の節目として置きます。解約日だけを先に決めると、移行が遅れた場合の余裕がなくなります。逆に旧契約を無期限に残すと費用と管理の負担が続きます。契約上の期限を確認したうえで、どの確認を終えたら終了できるかを合意する進め方が現実的です。

引き継ぎ台帳に、契約・権限・資産を集める

「不明」を消さず、確認担当と期限を付ける

最初から全項目を埋める必要はありません。重要なのは、分からない情報を分からないまま管理することです。「たぶん前の会社が持っている」と書く代わりに、「管理者未確認、旧制作会社へ確認中、回答予定日」と記録します。依頼したことと受け取ったことを区別し、添付ファイルを受領しただけで内容確認済みにしないようにします。

台帳そのものにパスワードや復旧コードを並べる必要はありません。サービス名、契約名義、管理画面の場所、権限を持つ担当、秘密情報の保管先、更新期限、受領確認の日付があれば、作業の見通しを立てられます。秘密情報は会社で決めた管理方法を使い、閲覧できる人を限定します。通常の進行表や見積もり資料と、認証情報の保管場所を分けます。

契約名義と、日常のログイン権限を区別する

管理画面に入れることと、契約を更新したり解約したりできることは同じではありません。例えば、記事を編集できるユーザーでも、サーバーの支払い情報は変更できない場合があります。逆に契約の請求を受ける人が、サイトの更新方法を知っているとは限りません。「アクセスできた」で完了せず、必要な作業ごとに実施できる担当を確認します。

会社で管理するアカウントについては、担当者の異動や休職があっても手続きが続けられるよう、連絡先と復旧方法を確認します。二要素認証が個人の端末だけに依存しているなら、サービスが認める管理方法で引き継ぎます。便利だからと既存の全員共通パスワードを配り続けるより、担当者別の権限を付与できるサービスでは、その仕組みを使う方が作業履歴を追いやすくなります。

画像や編集データは、受領と利用条件を別に確かめる

公開サイトに使われている画像を取得できても、別の広告や印刷物に再利用できるとは限りません。写真、フォント、有料テーマ、プラグイン、外部サービスなどについて、契約者、更新費用、利用先、引き継ぎの可否を確認します。制作費を支払った事実だけから、すべての素材や編集データを自由に使えると判断せず、契約書と提供条件を照合します。

デザインの編集データやビルド前のソースが今回の納品範囲に含まれるかも、旧契約を基準に確認します。提供されないものがある場合は、新制作会社がどの作業を再構築する必要があるかを見積もりに反映します。相手の落ち度と即断するのではなく、契約上の対象と、次の運用で必要なものの差を整理すると、追加の相談を具体化しやすくなります。

WordPressは、ファイルとデータベースをそろえる

記事の書き出しだけでサイト全体を復元できるとは限らない

WordPressの公式バックアップガイドは、通常のサイト全体を復元するには、データベースとファイルの両方が必要だと説明しています。投稿内容や設定を含むデータと、テーマ、プラグイン、アップロード画像などのファイルでは、保存される場所と役割が異なります。記事のエクスポートを受け取っただけで、現在の見た目や機能まで復元できるとは考えないでください。

受領リストには、何をいつ取得したかを残します。データベースだけ古く、画像は新しいといった組み合わせでは、記事と画像の対応が合わない可能性があります。移行担当に同じ時点の状態として復元できる組み合わせか確認してもらい、保存先と確認結果を記録します。実際の取得・復元は、利用中の環境に合う方法で行う必要があります。

外部機能と自動処理を一覧にする

画面を開いただけでは分からない処理も引き継ぎ対象です。問い合わせ通知、予約サービスへの連携、定期実行する処理、外部から取得する情報、会員への通知などを挙げます。プラグイン一覧だけでなく、どの業務のために何をしているかが分かる説明を付けてもらいます。名前が似た機能でも、サーバー側の設定や別サービスの契約に依存していることがあります。

用途が分からない項目の調べ方は、WordPressのプラグイン整理ガイドで説明しています。引き継いだ直後に一括削除せず、利用箇所・依存関係・保存データから判断します。

例えば問い合わせフォームなら、「フォームが表示される」「入力できる」「送信を受け付ける」「担当部署が受信する」「顧客に控えが届く」は別の確認です。新環境へのコピーで見た目が再現できても、送信先や外部認証が旧環境を前提にしていないか確認します。テスト中に実際の顧客へ通知が送られないよう、外部への動作を制御した環境を準備します。

動作環境と変更履歴を短く残す

利用中のWordPress、PHP、データベース、主要プラグインなどの情報は、新環境での動作確認に必要です。独自に変更している箇所があるなら、変更したファイルや理由、更新時の注意点も受け取ります。ただし、公開された一般的な手順をそのまま当てはめて、一斉に最新版へ変更することは引き継ぎと別の作業です。互換性を調べる範囲と費用を明確にします。

古いPHP環境から更新する必要がある場合は、PHP更新のバージョン選び・検証・復旧判断を参照してください。引き継ぎの完了と、環境更新の完了を別々に確認できます。

WordPressの公式移行ガイドでも、移行条件に応じてファイルやデータベース、URLなどの扱いが変わります。新しい会社には、現状を再現して引き継ぐのか、環境の更新も含むのかを確認しましょう。変更履歴は長大な報告書でなくても、「どこを」「なぜ」「いつ」変えたかが分かるだけで、後の調査の手がかりになります。

GitLabの公開障害報告から、復元確認の意味を考える

バックアップの仕組みがあっても、復旧は別の問題だった

GitLabは、2017年1月31日に起きたデータベース障害について、同年2月10日付の事後分析を公開しています。報告では、主データベースのディレクトリを誤って削除したこと、通常のバックアップ処理が機能していなかったことなどが説明されています。復旧には別環境のデータを利用し、一定期間のデータベース上の変更が失われました。GitリポジトリとWikiは別に保存され、削除されなかったと区別して報告されています。

同報告は、バックアップ手順を定期的にテストする責任者がいなかったことも原因分析に挙げています。これはWordPressの移行事故でも、制作会社の交代で起きた事故でもありません。規模や構成も企業サイトとは異なります。ただし、復元手順を確認し、その担当を決める必要性を考える材料になります。ここから先の引き継ぎへの応用は、本記事の整理です。

引き継ぎでは「保存済み」を「復元できた」に進める

受け取った圧縮ファイルが開くことは、最初の確認にすぎません。実際に別の環境へ復元し、代表的なページ、画像、管理画面、主要機能を確かめると、何が不足しているかを具体的に見つけられます。本番を上書きする復元テストではなく、外部への通知や検索公開を制御した検証環境を使います。バックアップ内に含まれる情報に合わせ、アクセスも限定します。

結果は「問題なし」だけでなく、「取得日時」「復元した環境」「確認した機能」「不足した情報」「確認者」を残します。例えばトップページは表示できても、予約データやメール連携を確認していなければ、その範囲は未確認です。バックアップを持つ担当と、復旧を判断する担当が別なら、障害時に誰へ連絡するかも明記します。

どこまで戻せるかを、業務の言葉で決める

「毎日バックアップする」だけでは、障害が起きたときにどこまで業務を戻せるかは分かりません。前日の記事なら再入力できても、その後の予約や問い合わせを失うと困る事業もあります。更新頻度と、別の場所に記録が残る情報を整理し、どの時点までのデータを復旧したいか、どれだけの停止を許容できるかを新しい保守担当と話し合います。

この確認は、特定の高価な仕組みを必ず導入するという意味ではありません。会社案内中心のサイトと、受注や予約を受けるサイトでは必要な備えが違います。保守費を比較するときには、取得頻度、保存期間、復元作業の費用、連絡を受け付ける時間、緊急時の作業範囲まで確認すると、自社の業務に合うかを判断しやすくなります。

検索・解析・メールを取り残さない

Search Consoleの所有者と確認方法を引き継ぐ

サイトの制作データとは別に、Search Consoleの管理権限も確認します。自社の担当者が必要な情報を見られる状態を作ってから、不要になる権限を整理します。Googleは所有権確認トークンの管理に関する公式案内で、以前の確認済み所有者を削除する際には、その所有権確認に使われたトークンも取り除くよう説明しています。

ただし、サイト上の確認ファイルやDNSの設定を一律に削除するのは避けます。どの担当者やサービスに使われているかを確認し、自社の管理を維持したうえで整理する必要があります。新制作会社への依頼には、「所有者を追加して終わり」ではなく、「現在の確認方法を記録し、終了する担当の権限を必要な範囲で整理する」と書くと、確認漏れを減らせます。

解析データを引き継ぐ目的を明確にする

解析サービスでは、どのアカウントと対象サイトを使っているか、誰が権限を持つか、何を問い合わせとして数えているかを確認します。単にグラフが表示されるだけでは、以前と同じ条件で比較できるとは限りません。設定を新しく作り直す必要がある場合は、過去と新しい計測で何が変わるかを記録します。引き継ぎ前後の数字の差を、そのままサイト改善の成果にしないためです。

広告を出しているなら、広告アカウント、リンク先、計測タグ、完了ページも担当者間で確認します。制作会社が広告運用を行っていない場合でも、サイト側の変更が影響する箇所は共有が必要です。移行のための内部アクセスやテスト送信を、成果の件数として誤解しないように扱います。計測が動くことと、実際の問い合わせが増えたことを分けて確認しましょう。

メールは送受信と過去データの両方を確かめる

Webサイトを別のサーバーへ移しても、メールは現在のサービスに残す計画かもしれません。その場合でも、DNSや旧契約の解約がメールへ影響しないかを担当者に確認します。メールも移すなら、新しいメールボックスだけでなく、必要な過去メール、共有アドレス、転送、各端末の設定が対象になります。Webの表示確認だけで完了としないことが重要です。

確認表には、代表アドレスへの外部からの受信、外部への送信、フォームからの通知、共有担当者の閲覧を分けて書きます。テスト相手と予定を決め、送信できた表示だけでなく受信側でも確認します。独自ドメインのメールが止まると、サイトの引き継ぎに関する連絡まで受け取れなくなる可能性があるため、当日は別の連絡方法も共有しておきます。

切り替え当日は、開始条件と戻す条件を決める

更新を止める時間と、追加データの扱いを合意する

検証環境を作った後にも、本番サイトでは記事や問い合わせが増えることがあります。古いコピーをそのまま公開すると、その差分を取り残す可能性があります。切り替え前に、誰がいつまで更新できるか、最後のデータをいつ取得するか、受付を継続する機能の情報をどう扱うかを決めます。停止できない業務があれば、事前の設計に反映しなければなりません。

例えば、会社のお知らせを一時的に更新しないことと、予約の受付を停止することでは影響が違います。「更新停止」と一括りにせず、記事編集、顧客の入力、外部サービスとの同期など、発生する変更ごとに確認します。新旧の両方にデータが入る可能性がある場合は、切り替え後の照合も計画に含めます。担当者が当日に判断する項目を減らすことが目的です。

確認順序は、主要業務から代表ページへ広げる

切り替え後は、トップページの表示だけで完了としません。まず事業に直結する問い合わせや予約、メールを確認し、その後にサービスページ、ブログ、画像、資料、スマートフォンのメニューなどを確認します。旧URLを変える場合は、重要な旧ページから意図した新ページに到達できるかも対象です。検索に公開するページへ、検証用の公開制限が残っていないかも確認します。

確認者は、管理者としてログインした状態だけでなく、一般の訪問者としても見ます。管理者だけが表示できる内容や、キャッシュの違いを見落とさないためです。作業の直後に見えた画面と、別の端末から後で確認した画面が違う場合は、すぐに追加変更を重ねるのではなく、どの環境で何を確認したかを整理して原因を調べます。

問題が出たら戻せる範囲を、先に具体化する

「何かあれば元に戻す」という約束だけでは、実際に戻せるか分かりません。旧環境をどこまで残すか、設定変更前の情報をどこに保存するか、誰が戻す判断をするかを決めます。さらに、新環境で受け付けた問い合わせや予約を、戻した後にどう扱うかも必要です。画面を以前の状態に戻すことと、その間の業務データを保つことは別の課題です。

戻す条件には、主要機能が使えない、受付の確認が取れない、重要情報が欠落しているなど、事業への影響を基準にします。軽微な表示調整と同じ扱いにはしません。判断までの時間と連絡手段を合意し、作業担当者が一人で営業上の影響まで決めなくてよい状態にします。切り替え作業の担当範囲に、復旧まで含まれるかも確認しておきましょう。

移行後に権限と旧契約を整理する

旧環境の解約は、完了条件を満たしてから進める

公開確認が終わっても、旧環境にしか残っていない資料やメールがないかを確認します。新しい保守担当が更新できること、バックアップを取得できること、必要な連絡先が引き継がれたことも確認対象です。保管期間は契約や業務の事情に合わせて決め、終了予定日と担当を台帳に残します。何となく残すのではなく、必要な期間を決めて管理します。

旧制作会社へは、引き継ぎ完了の範囲と未完了の項目を具体的に共有します。追加対応が必要なら、内容と費用を確認して依頼します。すべての問題を過去の担当へまとめて返すのではなく、もともとの仕様、移行で生じた変更、今回新しく求める改善を分けると、相談が進めやすくなります。業務上の記録は、次の担当が経緯を追える場所に保管します。

不要な権限を減らし、運用手順を短く試す

引き継ぎのために一時的に追加したアカウントや共有リンクは、役割が終わったら整理します。ただし、外部連携や定期処理に使われるアカウントを確認せずに削除すると、機能が止まることがあります。用途と依存関係を確認し、必要な移し替えを済ませてから終了します。いつ、誰が、何を整理したかを残しておくと、後の調査にも役立ちます。

最後に、社内担当者が実際の更新手順を一度試します。お知らせの下書き、プレビュー、公開の依頼、誤りがあった場合の連絡など、自社で行う作業を確認します。手順書があることと、担当者が迷わず使えることは違います。担当が変わったときにも理解できる短い説明と、困ったときの窓口がそろえば、引き継ぎの成果を日常の運用に結び付けられます。

引き継ぎを相談するときに用意したいもの

分かる情報から共有し、不足調査を見積もりに含める

相談の初期段階では、現在のURL、変更したい理由、分かっている契約先、現在の担当窓口、希望時期を用意します。管理情報が不明なら、そのことを伝え、調査から依頼できるか確認します。最初から認証情報を広く送るのではなく、調査の範囲と共有方法を決めてから必要なアクセスを渡します。旧会社への確認が必要な場合は、依頼内容を具体化してもらうと進めやすくなります。

見積もりは、現状調査、データ受領、復元検証、切り替え、公開確認、引き継ぎ後の保守に分けて見ると、何が含まれるかを確認できます。現状が不明な段階で総額を固定できない場合には、調査後に確定する項目と、その判断時点を明記してもらいます。追加料金が発生する条件が見える方が、安い一式表示だけで判断するより社内の予算調整をしやすくなります。

制作会社を変えた後に、どんな状態を目指すか

担当会社の変更は、過去の不満を解消する機会であると同時に、今後の運用方法を決め直す機会です。更新依頼の回答期限、修正の確認方法、緊急連絡、定期点検、費用の見直し時期を話し合います。必要な範囲を言葉にしておかないと、会社が変わっても「そこまで含まれていると思っていた」という行き違いが続きます。

Acquaへのホームページの引き継ぎ相談では、現在のサイトと、分かる範囲の管理状況を共有してください。大切なのは、データを受け取って終えることではなく、新しい担当が何を管理でき、何が未確認で、困ったときにどう復旧するかを明確にすることです。デザインの刷新も予定する場合は、引き継ぎと改善の範囲を整理したうえで、ホームページ制作と合わせて検討できます。

出典の確認日：2026年9月9日。GitLabの事例は同社の2017年の公開報告に基づきます。本文の引き継ぎ手順はその事例の再現手順ではなく、企業サイトの運用に向けた整理です。契約や各サービスの条件は、利用中の契約と公式案内で個別に確認してください。