運用中の施設サイトを、止めずに作り直して入れ替えたら壊れた5箇所

こんな人向けです

• 施設の公式サイトが古く、制作会社に「作り直し」を相談したら見積もりが高くて止まっている

• サイトの担当は自分だが、本業は総務・事務で、コードは書けない

• 「移行で検索順位が落ちる」「旧サイトが消える」と脅されて、踏み切れない

• AI にどこまで任せられて、どこからは人が持つのか、実例で知りたい

私は小規模施設のひとり情シスです。本業は総務で、コードは読めますが書きません。運用中の公式サイト（Xserver＋WordPress・17ページ）を、運用したまま作り直して入れ替える作業
2本目：36日で手が止まった11箇所と、その判断／3本目（完結編）：外注なら280万円・4〜6か月。自分でやって36日を、制作会社に出さず、AI（Claude Code）と二人でやりました。

結論から言うと、入れ替えは成功しました。ただし当日に5箇所壊れました。この記事はその5箇所の記録です。手順は検索すればいくらでも出てきます。出てこないのは「実際に何が壊れるか」なので、そこだけ書きます。

先に全体の数字

• 期間 — 36日（うち実際に手を動かしたのは12日。途中19日間の中断あり）

• 規模 — 17ページ・画像127件・旧 URL からの転送 287件

• 停止時間 — 約3時間（問い合わせが止まると困る時期だったので、停止中も申込フォームと電話に辿り着ける案内ページを出した。結果、停止中の問い合わせはゼロ）

• 私（人）の作業 — 4回・合計約20分（旧サイトの退避／DB 作成／キャッシュ削除／表示確認）

• 自動検証 — 109項目すべて合格。その後、人の目でウィジェットなどの見落としが見つかった

役割分担は、設計・構築・移行スクリプト・検証スクリプトが AI、判断と本番の「押す」作業が人です。AI には本番の認証情報を渡しましたが、期限付き・「読み取りは自由、変更は必ず事前に計画を出す」という条件付きです。

壊れた1：転送 287件を入れた瞬間、サイト全体が 500 になった

旧サイトと新サイトは URL の構造が違うので、旧 URL から新 URL への転送（301）を 287件、.htaccess に書いて設置しました。

設置した瞬間、サイト全体が 500 エラー。しかも、停止中に出していたメンテナンス案内ページまで消えました。.htaccess は1行でも文法が壊れると、そのディレクトリ配下の全リクエストが 500 になります。案内ページの設定も同じファイルにあったので道連れになりました。

正体は、転送の元データ 287行のうち 2行が URL の途中で改行されていたこと。これは仕様ではなく、こちらの前処理ミスです。Apache は「引数が足りない」と判断し、ファイル全体を捨てました。

抜け方は「まず 301 を外して復旧、原因究明は後」。AI は原因を探しに行こうとしましたが、「先に戻す」と決めていたので迷いませんでした。復旧してから、287行すべての引数の数を機械的に数える検査を作り、通ってから再設置しました。

正直に言うと、このとき私が一番怖かったのは原因ではなく「失敗したら元に戻るのか」でした。それでも AI に任せられたのは、二段構えで考えていたからです。今の AI なら、何かあっても私の手ではなく AI 自身の操作で戻せるだろう。こちらの指示を正確に伝えて、それでも駄目なら、サーバー側の自動バックアップから戻せる。あれはこちらの操作では消せないものなので、最後はそこに戻れる。この確信があったので、復旧は AI に任せ、短時間で済みました。

【教訓】本番の .htaccess を変えたら、直後にトップページの HTTP ステータスを見る。設定ファイルは「書いた内容が正しいか」ではなく「サーバーが受け付けたか」で確認する。

壊れた2：トップページだけ、旧サイトが返ってくる

公開直前、下層ページは予定どおり 503（メンテ中）なのに、トップページだけ旧サイトが 200 で返ってきました。

画面を見た瞬間、私は「キャッシュが残っているな」と思いました。ただ、どこのキャッシュかが分からない。

返ってきた HTML の中身を見ると、旧サイトで使っていたプラグインの署名が入っていて、サイズも 644KB。新サイトのものではないと確定できました。サーバー側のどこかに、旧サイトのトップページのキャッシュが残っていたと見ています。

抜け方は、私がサーバーパネルで高速化機能（X アクセラレータ）を OFF→ON。それで解消しました。ただし、公式マニュアルではこの機能は HTML をキャッシュしないことになっていて、本当の犯人は別のキャッシュ機能（サーバーキャッシュ設定）だった可能性があります。

【教訓】「移行したのにトップだけ変わらない」ときは、まずサーバー側のキャッシュを全部疑って破棄する。破棄の方法は、当日ではなく準備段階で確かめておく。

壊れた3：「Access denied」の原因が、権限ではなく大文字小文字だった

新しい WordPress のデータベース接続で Access denied が出ました。普通は権限不足を疑います。

正体は、私の契約環境では、MySQL のユーザー名が小文字に変換されて作られていたこと。私の控えには大文字を含む名前が書いてありましたが、実際に作られたのは全部小文字でした。

一時的に詳細なエラーを出す設定にして、データベース接続の生のエラーメッセージ（Access denied for user '...'）を読み、書かれているユーザー名を控えと突き合わせて特定しました。

【教訓】「Access denied」は、権限不足ではなく名前の不一致のことがある。サーバー側の命名規則は、当日ではなく準備段階で試しておく。

壊れた4：写真 127件のうち 12件が、名前を変えられて消えた

画像は旧サイトから 127件を移しました。ドメインを新しいものに置換すれば表示されるはず、と思っていたら、12件だけ表示されない。

WordPress は大きな画像をアップロードすると -scaled.jpg という名前の縮小版を自分で作ります。そのため、アップロードされるファイル名の末尾に -scaled が付いていると、私の環境では同名ファイルが無くても -scaled-1.jpg のように番号が付いて保存されました（WordPress 側の名前衝突回避の挙動です）。ドメインだけ置換しても、この 12件はファイル名が変わっているので見つかりません。

抜け方は、置換の順序を変えること。まず「ファイル名まで含めた完全一致」で 12件を置換し、その後に残りをドメイン置換しました。

もう1つ、画像の説明文（alt）が 127件すべて空のまま登録されていました。どちらも、移行ツールの「成功」表示では分からず、件数を数える検査（本番に 127件ちょうどあるか、説明文が移行元と同じ数あるか）で初めて見つかりました。

【教訓】移行ツールの「成功」は、移行の成功を意味しない。件数を数える検査を別に持つ。

壊れた5：誰も置いていないウィジェットが、サイドバーに並んでいた

自動検証 109項目をすべて通した後、運営側の人間が画面を見て「これ、なに？」となりました。サイドバーに「アーカイブ」「カテゴリー」「最近のコメント」が並んでいたのです。

新規インストールの WordPress は、サイドバーのあるクラシックテーマだと、既定のウィジェットを自動で置きます。設計図にはそんなものは無いので、「設計図どおりか」を確かめる検証では永遠に検出されません。

抜け方は、検証をもう1本作ること。「設計図どおりか」とは別に、「テストサイトと本番が同じに見えるか」を突き合わせる検査を追加しました。128項目を通ったサイトでも、人の目でないと見つからないものが残っていました。

【教訓】検証は2本立てにする。「設計図どおりか」と「同じに見えるか」は別物。そして、人の目は最後の検証工程であって、省略できない。

5箇所に共通していたこと

振り返ると、1つ目はこちらの前処理ミス、残り4つはサーバーと WordPress の側の挙動を、こちらが知らなかったことが原因でした。そして 5つのうち 4つ（転送ファイルの機械検査・キャッシュの破棄・MySQL の命名規則・既定ウィジェット）は、準備段階で試しておけば当日に踏まなくて済んだものです。当日に初めて本番サーバーの仕様を知る、という進め方が一番の反省点です。

もう1つ、この記事で詳しく書かなかったことがあります。当日の朝、新しい WordPress を「簡単インストール」で入れようとしたら、旧 WordPress が残っているせいで弾かれました。最短の解決策は、旧 WordPress をアンインストールすること。でも私たちはそれを選びませんでした。その理由と、そこで決めた判断のルールが、壊れた1の「先に戻す」につながっています。詳しくは次の記事で書きます。

この先の記事

この記事は「何が壊れたか」までです。次の記事（有料 500円・準備中）は、なぜそこで詰まり、どう判断して抜けたかを 11箇所分まとめます。今回の 5箇所に加えて、

• 原稿の「正」がどれか分からない（現サイト・パンフ・Excel が食い違う）

• 移行対象が多すぎてチェックリストが機能しなくなった

• 私が AI に「認証情報を渡してあるのに、なぜ私の作業が多いのか」と言った

• メンテナンス案内の除外条件は 2種類書かないと無限ループする

• 自動検証で 20件不合格が出たが、ほとんど検証側の欠陥だった（87→109項目に厳密化。その後、見落とし2件を足して128に）

• 簡単インストールを弾かれたとき、最短の手段を捨てた理由

の 6つです。その次に、制作会社の見積もりと自分でやった日数を工程別に並べた記事を書きます。