ホームページ制作会社を変更する時の引き継ぎ項目｜契約・データ・アカウント

ホームページ制作会社を変更する時は、解約の連絡やパスワード回収から始めるのではなく、まず「何を、誰から、どの状態で受け取るか」を一枚の引き継ぎ台帳へまとめます。確認対象は契約書だけではありません。ドメイン、DNS、サーバー、CMS、サイトデータ、計測、会社メール、外部サービスまでを分け、旧制作会社・新制作会社・自社の担当と完了条件を決める必要があります。

先に現在の契約を止めてしまうと、管理画面へ入れなくなったり、サーバー上のデータが消えたり、問い合わせメールの設定を確かめる時間がなくなったりします。反対に、アカウント情報を受け取っただけで「引き継ぎ完了」と判断すると、いざ更新や障害対応が必要になった時に、復元できない、請求先が分からない、二段階認証が旧担当者へ届く、といった問題が残ります。

大切なのは、制作会社を変えること自体ではなく、Webサイトを動かす資産と判断権限を、業務が止まらない形でつなぎ直すことです。分からない項目は推測で埋めず、「未確認」と記録し、確認先と期限を置けば進められます。以下では、変更を決めた段階から切替後の権限整理まで、実務で確認する順番に沿って整理します。

制作会社を変える前に、引き継ぎ台帳を一枚つくる

最初に用意するのは、パスワード一覧ではなく引き継ぎ台帳です。サービス名だけを並べるのではなく、「現在の契約・名義」「操作できる人」「受け取るもの」「旧社・新社・自社の担当」「確認日」「完了の証拠」を同じ行で見られる形にします。これにより、契約の話と技術作業が混ざらず、どこで止まっているかを三者で共有できます。

パスワードそのものを共有表へ書く必要はありません。ログイン情報は会社で管理するパスワード保管庫や、期限付きの安全な共有方法で渡し、台帳には保管場所と利用できる担当者だけを記録します。サービスが個別ユーザーを追加できる場合は、旧担当者のIDを共用するより、自社と新制作会社のアカウントを新しく追加した方が、後で権限を整理しやすくなります。

台帳の状態は「未確認」「依頼済み」「受領済み」「動作確認済み」「完了」のように分けます。受領済みと動作確認済みを同じにしないことがポイントです。たとえばバックアップファイルを受け取っても、新制作会社が展開できない形式なら移行には使えません。管理画面のURLが分かっても、二段階認証が旧会社の端末に残っていれば自社管理には移っていません。

制作会社変更時の引き継ぎは、契約確認から権限整理までを一続きの工程として進めます。

この流れを解約前から始めると、旧制作会社へ依頼する内容をまとめて伝えられます。新制作会社も、既存環境を引き継げるのか、作り直しが必要なのか、どの作業に時間がかかるのかを早い段階で判断できます。

解約日は「契約が終わる日」だけでなく、受取期限から逆算する

制作会社との契約を確認する時は、解約通知の期日だけでなく、契約終了後に何が使えなくなるかを見ます。保守契約、サーバー利用、独自CMS、更新代行、ライセンス提供などが一つの料金に含まれている場合、契約終了と同時に管理画面やシステムが停止することがあります。先に新制作会社へ契約内容と現状を共有し、受取・検証に必要な期間を見積もってから終了日を決める方が安全です。

契約書、申込書、利用規約、見積書、請求書、過去のメールを集め、少なくとも次の点を確認します。

• 解約を申し出る期限と方法。メールでよいのか、書面が必要なのか
• 最低契約期間、更新単位、途中解約時の費用
• 契約終了まで提供される保守・更新・障害対応の範囲
• サイトデータ、データベース、素材、設定書などの受渡条件と形式
• デザイン、文章、写真、プログラム、独自CMSを継続利用できる範囲
• 契約終了後のデータ保管期間と削除予定日
• 引き継ぎ作業や問い合わせ対応に別料金が発生するか

ここで「サイトは自社のものだから、すべて当然に受け取れる」と決めつけないことが重要です。公開中のページを利用できても、デザインの編集データ、購入素材、テーマやプラグインのライセンス、独自システムのソースコードまで同じ条件で持ち出せるとは限りません。権利や再利用範囲は契約ごとに異なります。内容に争いがある場合は、新制作会社へ判断を丸投げせず、契約の当事者である自社が弁護士など該当分野の専門家へ確認します。

旧制作会社へ解約を伝える際は、感情的な評価と引き継ぎ依頼を混ぜず、終了希望日、依頼したい受取物、希望形式、確認窓口を事務的にまとめると進めやすくなります。解約の合意とデータ受渡しの合意は別に記録し、口頭で決まった内容もメールや議事録に残します。

ドメイン・DNS・サーバーは、名義と操作権限を分けて確認する

ホームページのURLが変わらない場合でも、ドメイン、DNS、サーバーは別々に確認します。ドメインは名称の登録、DNSはその名称をWebやメールの接続先へ案内する設定、サーバーはサイトのファイルやシステムを動かす場所です。同じ会社へ料金を払っていても、管理画面や権限が分かれていることがあります。役割の違いを先に確認したい場合は、Bämの「ドメインとサーバーの違い｜契約名義・DNS・引き継ぎを整理」で基本を整理できます。

ドメインでは、登録サービス、登録者名、登録メール、更新期限、支払方法、管理画面へ入れる人、二段階認証と復旧先を確認します。制作会社を変えるからといって、必ず別の登録サービスへ移管する必要はありません。自社が更新と承認を行える状態であれば、登録先はそのままにしてDNSの接続先だけを変える方法もあります。移管するか、現在の管理を引き継ぐかは、新制作会社の対応範囲と今後の運用体制を見て決めます。

一般的なgTLD（.comや.netなど）を登録会社間で移管する場合は、Auth-Codeと呼ばれる移管用コードや、移管ロックの解除が関わります。登録者情報を変更した直後など、一定期間移管できない条件が生じる場合もあります。ドメインの種類と登録サービスで手順が異なるため、現在の登録会社の公式案内を確認し、切替日ぎりぎりに手続きを始めないようにします。

DNSは、変更前の設定を必ず控えます。Webサイトだけでなく、会社メール、送信ドメイン認証、各種サービスの所有確認にも使われるため、Web用の設定だけを見て一括で上書きすると、メールや外部連携が止まる可能性があります。誰がDNSを変更するか、変更内容を誰が承認するか、旧設定へ戻せる記録があるかを台帳へ入れます。

サーバーでは、契約名義と請求先に加え、コントロールパネル、ファイル接続、データベース、SSL、バックアップ、定期処理、アクセス制限、CDNやWAFなどの利用状況を確認します。すべての権限を自社担当者が日常的に操作する必要はありませんが、契約更新、障害時の連絡、管理者追加、データ取得を自社が承認できる状態にしておくと、次の担当交代でも困りにくくなります。

CMS・データ・素材は「受け取った」ではなく、復元できるかで判断する

サイトデータの引き継ぎは、ファイル一式という言葉だけでは確認できません。WordPressなどのCMSは、公開ファイル、データベース、アップロード画像、テーマ、プラグイン、設定、サーバー側の処理が組み合わさって動きます。どれか一つが欠けると、画面は表示できても問い合わせフォームだけ動かない、管理画面へ入れない、過去記事の画像が欠けるといった状態になり得ます。

WordPressの標準エクスポートで作成されるWXRファイルには、投稿、固定ページ、カスタム投稿、コメント、カスタムフィールド、カテゴリー、タグなどのコンテンツが含まれます。一方で、そのファイルだけを「サイト全体の完全なバックアップ」とみなすことはできません。移行目的なら、サーバー上のファイル、データベース、アップロード、テーマ・プラグイン、設定ファイル、必要なサーバー設定も含めて受取範囲を決めます。

新制作会社には、受け取ったデータを本番とは別の検証環境で復元してもらい、表示と操作を確認します。復元できたかだけでなく、管理画面ログイン、ページ編集、フォーム送信、検索、会員機能、予約・購入、定期処理、バックアップ取得など、サイト固有の機能を試します。現状の不具合も一覧にしておくと、「移行で壊れたもの」と「以前から起きていたもの」を切り分けやすくなります。

制作素材も、公開画像だけでなく今後の更新に必要な単位で棚卸しします。ロゴの正式データ、写真の元画像、図版、動画、文章原稿、デザインデータ、コード管理場所、フォーム項目一覧、リダイレクト設定、サイトマップ、更新マニュアルなどが対象です。購入写真、Webフォント、有料テーマ、プラグイン、外部ライブラリは、ファイルが手元にあっても契約終了後に利用できるとは限らないため、契約者と利用条件を確認します。

独自CMSや制作会社専用の仕組みで動いている場合は、データをそのまま別環境へ移せないことがあります。その場合は、無理に同じシステムを再現するより、文章・画像・URL・検索評価に必要な情報を取り出し、新しいCMSで作り直す範囲を決めます。「移管できるか」だけでなく、「今後、自社と新制作会社が安全に保守できるか」までを判断基準にします。

GA4・Search Consoleなどは、新規作成より既存権限の引き継ぎを優先する

アクセス解析や検索管理のアカウントは、サイトファイルとは別の資産です。GA4で新しいプロパティを作ると、既存の履歴や設定とは別になります。Search Consoleは同じサイトを新担当者側で確認できても、旧所有者の権限や確認トークンは別に整理が必要です。まず現在使っているアカウント、プロパティ、測定ID、管理者を確認し、自社と新制作会社へ必要な権限を追加します。

Google Analyticsでは、アカウントとプロパティのどちらで権限を付与されているかを確認します。新しい担当者がレポートを見られるだけでよいのか、設定変更やユーザー管理まで必要なのかで権限が変わります。アクセスできたら、データストリーム、イベント、キーイベント、内部トラフィック除外、参照元除外、他サービス連携など、現在の設定を記録します。旧制作会社の権限を先に削除せず、新しい担当者が必要な画面と設定を確認してから整理します。

Search Consoleでは、プロパティの種類、確認済み所有者、委任された所有者、一般ユーザー、所有権確認に使っているDNS・HTMLファイル・タグなどを確認します。Googleの公式案内でも、不要になった利用者の権限を変更または削除し、以前の所有者が残した確認トークンを点検することが勧められています。新しい所有者の確認が済んだ後で、旧担当者の権限と不要な確認方法を整理します。

同じ考え方はGoogle Tag Manager、広告アカウント、Googleビジネスプロフィール、Merchant Center、SNS広告のピクセル、ヒートマップにも当てはまります。サービスを作り直す前に、現在の所有者、請求、管理者、連携先を確認します。基本の順番は「新しい権限を追加する」「実際に操作・計測できるか確かめる」「旧権限を削除する」です。共有パスワードを渡すだけで終わらせず、担当会社ごとのユーザーを分けると、次回の変更でも履歴を残せます。

メールと外部サービスは、サイト切替より先に影響範囲を洗い出す

制作会社変更で見落とされやすいのが会社メールです。Webサイトと同じサーバー契約に見えても、実際のメール提供元が別サービスになっていることがあります。DNSを変更した時に、Web用の設定は合っていてもメール用の設定が抜けると、送受信できなくなる可能性があります。サイト公開の確認だけでなく、普段使うメールアドレスと問い合わせ通知の流れを先に図にします。

確認するのは、メールボックス、エイリアス、転送、メーリングリスト、自動返信、迷惑メール設定、保存容量、利用端末、Webメール、送信認証、復旧用連絡先です。問い合わせフォームが外部SMTPやメール配信サービスを使っている場合は、その契約者、APIキー、送信ドメイン認証、通知先も確認します。古い担当者だけに届く転送設定や、停止予定のメールアドレスが管理者アカウントの復旧先になっていないかも見ます。

ホームページにつながる外部サービスは、予約、決済、EC、会員管理、CRM、チャット、フォーム、メールマガジン、地図、動画、求人、在庫、配送、セキュリティ、reCAPTCHAなど多岐にわたります。画面に埋め込まれているものだけでなく、フォーム送信後にデータを渡すWebhookやAPI連携、定期実行、通知先も対象です。管理画面へ入れるか、契約名義は誰か、料金はどこから支払われているか、切替時に設定変更が必要かを一つずつ確認します。

個人情報や注文情報を扱うサービスでは、移行用データを誰が取得し、どこへ保存し、いつ削除するかも決めます。旧制作会社が業務上必要だったアクセスは、切替確認後に停止します。ただし、障害時の切り戻しに旧環境が必要な期間は、期限を明示したうえで残し、無期限に権限を放置しない運用にします。

切替日は、公開作業よりも確認項目と戻し方を決める

切替日は「新しいサーバーを公開する日」ではなく、業務への影響を監視し、問題があれば戻す判断をする日です。DNSやキャッシュの影響で、利用者によって新旧どちらの環境が見えるかが一時的に分かれることもあります。大きな更新やキャンペーンと同じ日に重ねず、自社の確認担当と新制作会社が対応できる時間帯を選びます。

切替前には、更新を一時停止する範囲と時刻を決め、直前のデータをバックアップします。ニュース更新だけなら短時間の停止で済みますが、注文、予約、会員登録、問い合わせが増え続けるサイトでは、移行中に発生したデータをどちらへ反映するかを決めなければなりません。旧環境の最終バックアップ時刻、新環境へ反映した時刻、切替後に追加されたデータの扱いを記録します。

公開後の確認項目は、トップページが見えるかだけでは足りません。主要ページ、スマートフォン表示、SSL、画像、内部リンク、リダイレクト、404ページ、フォーム送信と自動返信、会社メール、ログイン、検索、予約・購入、計測、外部連携、バックアップ、エラーログまで、サイトにある機能から必要なものを選びます。誰がどの端末で確認し、何をもって合格とするかを先に決めます。

戻し方も作業前に決めます。たとえば、問い合わせが届かない、決済できない、管理画面へ入れないなど、事業への影響が大きい不具合は切り戻す条件にします。旧環境へ戻すために必要なDNS設定、バックアップ、担当者、判断期限を記録し、新環境だけが唯一のコピーになる状態を避けます。問題がないことを確認してから、旧サーバーの解約、旧バックアップの削除、旧制作会社のアクセス停止へ進みます。

旧社・新社・自社の役割は、作業名ではなく完了条件まで書く

引き継ぎが停滞する原因は、担当がいないことより、「誰かがやると思っていた」作業が残ることです。「ドメイン移管：新制作会社」のように作業名だけを書くと、移管コードを依頼する人、承認メールを受ける人、費用を支払う人、完了を確認する人が分かりません。台帳には、実行担当、情報提供者、承認者、完了条件を分けて書きます。

三者の連絡先も一本化します。旧社と新社が直接技術確認をする場合でも、自社を外して決定しないよう、質問・回答・変更内容を同じ記録へ残します。連絡窓口が複数になる場合は、契約、技術、業務確認の責任者を分け、最終承認者を一人決めます。

引き継ぎ完了は、新制作会社がサイトを更新できた時点ではありません。次の状態まで確認できているかで判断します。

• 契約終了日、データ削除日、旧環境の停止日が確定している
• ドメイン、DNS、サーバー、CMSの更新・復旧を自社が承認できる
• サイトのファイルとデータベースが保管され、別環境で復元確認できている
• 写真、原稿、デザイン、コード、ライセンスの利用範囲が記録されている
• GA4、Search Console、タグ管理などへ自社と新社が必要な権限で入れる
• 会社メール、フォーム通知、予約・決済など業務に必要な連携が動く
• 切替後の主要ページ・機能・計測を確認し、問題時の戻し方が残っている
• 旧制作会社や退職者の不要なアカウント、復旧先、確認トークンが整理されている
• 日常の更新、バックアップ、障害時連絡、契約更新の担当が決まっている
• 未解決事項が「誰が・いつまでに・何を確認するか」の形で残っている

すべてを一度に自社管理へ戻す必要はありません。新制作会社へ運用を任せる場合でも、契約と承認の所在、復旧に必要な連絡先、受け取れるデータ、終了時の手順が分かれば、管理の見通しは大きく変わります。制作会社変更を、単なる業者の入れ替えではなく、Web資産の持ち方と運用責任を整え直す機会として進めることが、次の引き継ぎを難しくしない方法です。