制作会社を変えるときサイトの何を引き継ぐか｜受け取っておくべきものと、確認しないと動かなくなる箇所

ホームページの制作会社を変えるとき、「データ一式をもらえば移れる」と考えられがちです。実際には、ファイルを受け取っただけでは更新できないサイトが珍しくありません。先に結論を書きます。

引き継ぎが完了した状態とは、次の3つが同時に揃っている状態です。

1. 権限が揃っている（ドメイン・サーバー・サイト・外部サービスを、それぞれ自分の側で操作できる）
2. 実際に配信されている場所が分かっている（手元のソースを直せば表に出る、とは限りません）
3. 元に戻せる（引き継ぎ前の状態を丸ごと手元に持っている）

このうち発注側が見落としやすいのは1と2です。ファイルは形があるので必ず話題に出ますが、権限と配信経路は目に見えないため、引き継ぎの席で誰も触れないまま終わります。そして更新作業に入った初日に止まります。

弊社は名古屋でホームページの制作・運用を行っており、他社が作ったサイトの引き継ぎ、サーバー移転、ドメイン移行を実際に手掛けています。その実務で毎回確認している項目を順に書きます。

受け取るもののチェックリスト

まず全体像です。この表を先方に渡して埋めてもらうのが最短です。

分類	具体的に受け取るもの	欠けると起きること
ドメイン	ドメイン管理会社の名前・アカウント・名義・更新期限	更新切れでサイトとメールが同時に止まる。転送設定も動かせない
DNS	DNSレコードを操作できる権限	サーバーを移せない。切替当日に自分で作業できない
サーバー	サーバー会社・契約プラン・管理パネルのログイン情報	データベースの作成やSSLの設定ができない
ファイル転送	FTP／SFTPのホスト・ユーザー・パスワード・公開ディレクトリの場所	ファイルを更新できない
サイト本体	WordPress等の管理者アカウント、テーマ・プラグインの構成	記事も設定も触れない
データ	ファイル一式とデータベースの書き出し、画像の元データ	復元できない。写真の作り直しが発生する
外部サービス	解析・広告・地図の管理権限、フォームの送信先、予約システムのURL	数字が追えない。問い合わせが届かない
申し送り	独自に作り込んだ箇所、反映の手順、触ってはいけない箇所	触った瞬間に別の場所が壊れる

権限は「1つ渡せば全部触れる」ものではない

引き継ぎで最も詰まるのは、権限の粒度が想定と違うときです。

具体例を挙げます。ファイル転送用のアカウントを受け取っていても、それでサーバーの管理パネルにはログインできません。追加で発行されたファイル転送アカウントの認証情報で管理パネルへログインを試みると、「サーバーID、パスワードを再度ご確認ください」と拒否されます。契約の親アカウントと、ファイル転送用に追加発行されたアカウントは別物だからです。

これは細かい話に見えて、作業を丸ごと止めます。WordPressを新しく設置するにはデータベースの作成が必要ですが、共有レンタルサーバーではこれを管理パネルからしか行えない契約が多くあります。ファイルは全部手元にあるのに設置できない、という状態になります。引き継ぎでは「ファイルを触る権限」と「契約を触る権限」を分けて確認するのが正しい進め方です。

もう1つ、ドメイン管理会社とサーバー会社が別、というのはごく普通の構成です。ドメインとDNSはA社、サーバーはB社という案件では、切替に必要なDNSレコードの追加はA社側でしか行えません。実際にこの構成の移行では、レコード追加そのものを先方の担当者に依頼して進めています。事前に把握していれば1営業日で片付きますが、切替当日に判明すると公開のタイミングごと後ろにずれます。

手元のソースを直しても、表に出るとは限らない

引き継ぎで2番目に多い落とし穴です。ここは仕組みを知っていれば防げます。

引き継いだサイトでは、まず1ファイルだけ更新して、実際に配信されている内容を測る。これを最初の作業にしてください。理由は、ソースの置き場所と実際に配信されている場所が食い違っている構成が実在するからです。

実例です。静的なサイトを後からWordPress化した案件で、テーマの中にあるCSSファイルを正しく上書きし、サーバー上の実ファイルのハッシュ値まで一致を確認したにもかかわらず、ブラウザに配信されるCSSは旧内容のままでした。原因は、公開ディレクトリの直下に静的サイト時代のassets/フォルダが残っており、Webサーバーが物理ファイルを優先して返していたことです。テーマ内のCSSは、事実上ただの控えでした。

この構成では更新の反映先が2か所あります。片方だけ直しても表側は1ミリも変わりません。判定は次の順で行えます。

1. curl -sI でファイルのcontent-lengthとlast-modifiedを見る。アップしたファイルのサイズや時刻と食い違えば、別のファイルが配信されている
2. サーバー上の実ファイルをダウンロードしてハッシュを比較する。一致するなら「アップ失敗」ではなく「配信経路が違う」が確定する
3. 公開ディレクトリ直下を一覧し、過去の構成の残骸フォルダを探す

キャッシュを消して?v=を付け替えただけでは、反映できた証明になりません。実際に配信されているファイルのサイズを見るところまでやります。

関連して、渡されたソース一式が本番と一致していないこともあります。引き継いだ案件で手元のビルド成果物を確認したところ、本番との間に約2か月ぶんの乖離がありました。引き継ぎ直後はサーバー上の実ファイルを正として扱い、渡されたソースは参考資料の位置づけにしておくのが安全です。

近年は、記事の入力はWordPress、表示は静的ファイル、という構成も増えています。この場合は「管理画面で保存しても即座には反映されない」のが正常な仕様です。故障と紛らわしいので、どこを直すと何分後に表に出るのかを引き継ぎ時に必ず聞いてください。

ドメインと転送は「保有しているあいだ」しか効かない

ドメインを新しいものに変える引き継ぎでは、旧アドレスからの転送設定が要になります。

実例として、表記を正すために新ドメインへ移した案件では、旧々ドメイン→旧ドメイン→新ドメインという多段の転送を組み、全経路でページが正しく表示されること、パスとクエリ（URLの後ろに付く情報）がそのまま引き継がれることを1本ずつ確認しています。過去のリンクやブックマークからの流入を落とさないための作業です。

ただしこの転送は、旧ドメインを保有しているあいだしか成立しません。解約した瞬間に転送も消え、旧アドレスからの流入は途切れます。検索エンジンの評価が新ドメインへ移りきるまで数か月かかるため、旧ドメインは移行後もしばらく維持する前提で費用を見ておきます。引き継ぎ時に更新期限と名義を必ず確認するのは、このためです。

もう1つ、判断を誤りやすい点があります。DNSの向き先を変えただけでは、旧サイトは消えていません。共有サーバーはリクエストに含まれるドメイン名を見て振り分けるため、IPアドレスを直接指定してアクセスすると、DNSを経由せずに旧サイトが応答します。実際に、使っていないつもりの環境が到達可能なまま生きていた例を確認しています。旧環境を閉じるなら、公開ディレクトリからファイルを退避するところまでやって初めて閉鎖です。

引き継いだサイトは「前の作業の残骸」がある前提で点検する

他社から引き継いだサイトには、過去の作業で置かれたまま撤去されていないものが残っていることがあります。

実例では、引き継いだドメインの公開ディレクトリ直下に、認証なしでデータベースを操作できるツールが1年以上、誰でもアクセスできる状態で置かれていました。過去のURL一括置換作業で設置され、作業後に撤去されなかったものと考えられます。サイト自体は正常に動いていたため、画面を見ているだけでは分かりません。

引き継ぎ直後に点検する項目は次のとおりです。

• WordPress本体とプラグインのバージョン（更新が止まっている場合、バージョンを固定する設定が入っていることがあります）
• 使っていないテーマ・プラグイン（動いていなくても侵入の入口になります）
• 公開ディレクトリ直下の見慣れないフォルダ
• 管理者ユーザーの一覧（退職者や前任者のアカウントが残っていないか）
• .htaccessの中身（転送ルールが二重に書かれていることがあります）

「動いているから触らない」で先送りすると、更新できない理由に気づかないまま古い状態で残り続けます。引き継ぎのタイミングは、この棚卸しを費用に含めて一度やりきる好機です。

引き継ぎ当日の手順

順番に意味があります。上から実行してください。

1. 引き継ぎ前の状態を記録する。sitemap.xmlや一覧ページから全ページのURLを取り、表示を確認しておく。あとで「移行で消えた」と言われたときの基準になります
2. ファイル一式とデータベースを自分の手元に取る。相手のサーバー上にあるバックアップは、契約が切れると一緒に消えます
3. 権限の棚卸し表を埋め、欠けを1回でまとめて質問する。小出しに聞くと引き継ぎ期間が延び、その間は誰も更新できません
4. 1ファイルだけ更新して、実配信を測る。前章の手順です
5. 外に出る導線を1つずつ通す。フォーム送信、電話リンク、予約リンク、地図。ここは画面の表示確認だけでは分かりません
6. 前任者の環境に依存している処理の有無を聞く。定期的に動く自動処理が個人のパソコンやアカウントで動いていた場合、引き継いだ瞬間に静かに止まります

依頼する側が先に用意しておくと早いもの

発注者側で先に手元へ集めておくと、引き継ぎは目に見えて早くなります。

• 契約書とドメインの名義。誰の名義で契約されているかは、制作会社ではなく発注者しか調べられないことがあります
• ログイン情報の棚卸し。過去にもらったメールを探して1か所にまとめておく
• 触ってはいけない箇所の申し送り。「ここは前の会社が特別に作った」という情報は、引き継ぎ後の事故を確実に減らします

まとめ

制作会社の変更でつまずくのは、技術的な難しさではなく、権限と配信経路という目に見えない部分の確認漏れです。

• 受け取るのはファイルではなく、権限・配信経路・復元できる状態の3点セット
• ファイル転送の権限と契約の権限は別物。ドメイン管理会社とサーバー会社も別のことが多い
• ソースを直しても表に出ない構成は実在する。引き継ぎ初日に実配信を1回測る
• 旧ドメインからの転送は保有しているあいだだけ。DNSを外しただけでは閉鎖にならない
• 引き継いだサイトには前の作業の残骸がある前提で、初回に棚卸しをする

引き継ぎの相談は、移る前の段階でお話しいただくほうが確実です。何を先方に依頼すべきかが決まっていれば、更新が止まる期間をほぼゼロにできます。