---

ホームページビルダーからWordPressへ｜自社サイトを安全に移設する6ステップとClaude Code活用術

「自社サイトを直せるのは、外注先の担当者だけです」

「新しく始めたサービスが、サイトのどこにも載っていません」

「作り直したいのですが、何から手をつければよいのか分かりません」

——紙媒体とイベントを手がける会社のWeb支援の現場で、こうしたご相談を数多くいただいてきました。

総務省の令和7年通信利用動向調査報告書（企業編）によると、自社のホームページを開設している企業の割合は93.3%です。いまや、サイトを持っていること自体は珍しくありません。

一方で、同じ調査にはこんな数字もあります。ウェブアクセシビリティの規格を「知らなかった」と答えた企業が、51.2%にのぼるのです。

公開したあとも手を入れ続けている会社は、思ったほど多くありません。

つまり、多くの会社がいま抱えている課題は、サイトを持っていないことではありません。持っているサイトを、自社の判断で更新し続けられないことにあります。

本記事では、外注先がホームページビルダーで制作した自社サイトを対象に、WordPressへ安全に移設する手順を解説します。全体を6つのステップに分けました。

あわせて、Claude Codeを使って作業を効率よく進める方法もご紹介します。

---

本記事のターゲット

本記事は、次のような立場でサイトの移設を考えている方に向けて書いています。

• 紙媒体・イベントを扱う会社の経営者・企画担当の方
• 社内で自社サイトを引き取ることになった制作担当の方
• 移設をAIで効率化したいWeb担当の方

立場は違っても、移設で確認すべき順番は共通です。まず全体像をつかんでから、ご自身に関係するステップを読み進めることをおすすめします。

---

全体像：移設の6ステップ

移設は「作り直し」ではなく「引っ越し」です。荷物の中身を確かめ、新居を用意し、住所変更を届け出る

——この順番は、Webサイトでも変わりません。どれかを飛ばすと、あとから必ず戻ってくることになります。

ステップ	主な成果物	期間の目安
Phase1 現状把握	契約・アカウント一覧、制作データの所在メモ	1〜2週間
Phase2 棚卸し	ページ棚卸し表（残す／統合／廃止の判断つき）	1週間
Phase3 並行構築	検証環境のWordPress、テーマとプラグインの構成	1〜2週間
Phase4 移植	移植済みの固定ページ・投稿・画像	2〜3週間
Phase5 配線	URL対応表、フォームの送信テスト記録	1週間
Phase6 切替	公開、公開後1週間の確認記録	1週間

全体で1〜2ヶ月が目安です。

Phase1とPhase2を省くと、Phase5で必ず行き詰まります。地味な工程ですが、ここが移設の成否を決めます。

---

Phase1：現状を把握する

最初にやることは、作業ではなく確認です。「いま、自社サイトは誰の手で、何を使って作られているのか」をはっきりさせます。

外注先がホームページビルダーで作っていた、という構図

多くの会社で、いまのサイトは次のような経緯でできあがっています。

1. 数年前、自社サイトのリニューアルを制作会社や個人の外注先に依頼した
2. 外注先は、手元にあるホームページビルダーでサイトを制作した
3. できあがったHTMLファイル一式を、外注先がFTPでサーバへ転送して納品した
4. その後の更新も、同じ外注先が同じソフトで作業し、そのつど転送している

一見すると、何の問題もない流れです。ところが、この構図には見えにくい落とし穴があります。

ホームページビルダーは、編集用のプロジェクトデータと、そこから書き出される公開用のHTMLファイルが分かれています。サーバにあるのは後者だけです。

つまり、サーバからファイルを落としてきても、それは書き出された結果であって、編集の原本ではありません。原本は外注先のパソコンの中にあり、そのソフトを持っていない自社では開けないのです。

これが、「1行直すだけなのに見積もりと日数がかかる」という状態の正体です。

担当者の善意や熱意の問題ではなく、更新の手段そのものが社外にある構造だといえます。

3つのサイン

次の3つのうち2つ以上が思い当たるなら、移設を検討する時期にきています。移設は費用を削るための作業ではなく、自社の情報発信を自分たちの手に取り戻すための作業だと考えてください。

サイン	現場で起きていること
更新が止まっている	文言をひとつ直すだけでも依頼と見積もりが必要で、公開まで平均2週間ほどかかる
手段が社外にしかない	編集用の制作データも、画像の元データも、更新できるソフトも自社にはない
新しいサービスが載らない	数年前のサービス構成のままで、いま力を入れている事業がどこにも書かれていない

実際にご支援した会社では、自社サイトの小さな修正1件につき数万円、年間では数十万円ほどの外注費がかかっていました。金額そのものより、依頼が面倒で更新を諦めてしまうことのほうが、事業への影響は大きいといえます。

移設前に必ず押さえる6つの所在

移設を始める前に、次の6つが「誰の名義で、どこにあるのか」を確かめます。ここが空欄のまま進むと、Phase6の切替当日に手が止まります。

確認する対象	具体的に確かめること	よくある落とし穴
ドメイン	登録者名義、管理画面のIDとパスワード、更新期限	名義が外注先のままで、自社では設定を変更できない
サーバ	契約者名義、管理画面、FTPの接続情報	契約者が外注先で、解約されるとサイトごと消える
公開ファイル	サーバ上のHTML・画像・CSSの一式	使われていない古いファイルが大量に混ざっている
制作データ	ホームページビルダーのプロジェクトデータ	外注先のPCにしかなく、返却してもらう交渉が必要
画像の元データ	ロゴ、写真、印刷用データ	Web用に圧縮された小さい画像しか残っていない
メール	独自ドメインのメールがどこで動いているか	サーバ移転でメールまで止まる（Phase5で詳述）

⚠️ 制作データの返却は、依頼すれば応じてもらえることが多い一方、契約上の取り決めがないと難しい場合もあります。返してもらえない前提でも移設は進められますので、交渉が長引くようなら公開中のHTMLを起点に進めてください。

---

Phase2：ページを棚卸しする

現状が分かったら、次はページを1行ずつ並べます。全部を移すのではなく、移す価値のあるものだけを選ぶ工程です。

手元にサイトの写しをつくる

まず、公開中のサイトを丸ごと手元にコピーします。FTPでダウンロードできるならそれが確実です。接続情報が分からない場合は、公開されているページを取得する方法もあります。

作業は必ずコピーに対して行います。この時点から公開後まで、本番サーバのファイルは一切触らないと決めておくと、事故が起きません。

Claude Codeで棚卸し表をつくる

ページ数が数十を超えると、手作業の一覧づくりは現実的ではありません。ここがClaude Codeの出番です。手元にコピーしたフォルダを指定して、次のように頼みます。

old-site/ 配下の .html ファイルをすべて読んで、次の列を持つCSVを
inventory.csv として書き出してください。

  ファイルパス / <title> / 最初のh1 / 本文の文字数 / 画像の点数 /
  formタグの有無 / 最終更新日

本文の文字数は、ナビゲーションとフッターを除いた本文領域で数えてください。
ファイルの中身は変更しないでください。

数百ページあっても数分で一覧ができます。ここで「本文が100文字に満たないページ」「同じ内容が複数のURLにあるページ」が浮かび上がります。

残す・まとめる・やめるを決める

出てきた一覧に、判断の列を足していきます。判断はできるだけ機械的な基準で行うと、迷いが減ります。

判断	目安となる基準	移設での扱い
残す	検索やSNSから流入がある／営業で使っている／会社の基本情報	そのまま移植し、旧URLから新URLへ転送する
まとめる	内容が重複している／1ページが薄く単独では成立しない	移設先で1ページに統合し、転送先をそろえる
やめる	数年アクセスがない／終了したキャンペーン／情報が古い	移植しない。ただし転送先は必ず決めておく

Google アナリティクスやSearch Consoleを使っていれば、直近1年の流入数を突き合わせるのが最も確実です。計測を入れていない場合は、営業とサービス担当に「使っているページ」を聞いて判断します。

---

Phase3：WordPressを並行で構築する

移設先の準備は、公開中のサイトを止めずに進めます。いま動いているサイトはそのままに、別の場所で新しいサイトを組み立てるかたちです。

本番と切り離した場所で作る

作る場所は、次のいずれかを選びます。

構築場所	向いているケース	注意点
自分のパソコン（ローカル）	少人数で作り込み、Claude Codeを併用したい	社内の他メンバーに見せるには画面共有が必要
仮ドメインの検証環境	複数人で確認しながら進めたい	検索エンジンに拾われないよう非公開設定にする
本番サーバのサブディレクトリ	追加費用をかけたくない	設定を誤ると公開中のサイトに影響が出る

社内で確認しながら進めるなら、仮ドメインの検証環境が扱いやすいでしょう。いずれの場合も、検索避けの設定を必ず有効にすることを忘れないでください。二重に公開された状態は、検索評価にとって不利にはたらきます。

最初に決める5つのこと

決めること	判断の目安
サーバとドメイン	既存のサーバがPHPとデータベースに対応しているかを確認する。対応していなければ移転する
常時SSL（https）	必須。無料の証明書で問題ありません
テーマ	自社で更新し続けることが前提なので、日本語の情報が多く、更新が続いているものを選ぶ
プラグイン	フォーム、バックアップ、セキュリティ、SEOの4種類から始める。増やしすぎない
サイト構成	Phase2の棚卸し表をもとに、階層を先に紙で描いてから作る

プラグインは、あとから足すのは簡単ですが、減らすのは難しいものです。最初は必要最小限にとどめるほうが、長く運用できます。

Claude Codeの使いどころ

この段階では、テーマの調整でClaude Codeが役に立ちます。

theme/ 配下のstyle.cssとheader.phpを読んで、
現在のヘッダーの構造を説明してください。
そのうえで、スマートフォン表示のときだけロゴを中央寄せにする変更案を、
差分の形で提示してください。まだファイルは変更しないでください。

「まだ変更しないでください」と付け加えるのが要点です。提案を読んでから適用を判断すれば、意図しない変更が積み重なることを防げます。

---

Phase4：Claude Codeでコンテンツを移植する

移設のなかで最も手数がかかるのが、この工程です。ホームページビルダーが書き出したHTMLは、見た目を保つためのタグが幾重にも重なっています。そのままWordPressに貼ると、表示が崩れます。

移植の4ステップ

旧HTML（表組みレイアウト・古いタグ・インライン指定）
  → Claude Codeで本文だけを抜き出し、整った形に直す
  → WordPressの固定ページ・投稿に流し込む
  → 実機で表示・スマホ・リンクを確認する

本文を抜き出して整える

1ページずつ手で貼り直すより、まとめて変換してしまうほうが確実です。

old-site/company.html を読んで、本文領域だけを抜き出してください。

条件：
- 文章の文言は一字も変更しないでください。誤字もそのままにしてください
- レイアウト目的のtableタグは、見出しと段落に置き換えてください
- fontタグ、色や余白のインライン指定は削除してください
- 画像は <img> のパスと alt を保持したまま残してください

結果を converted/company.html として保存してください。

変換後は、元のページと並べて差分を確認します。この確認だけは人の目で必ず行ってください。

画像を整理する

古いサイトでは、画像のファイル名が img001.jpg のように内容と無関係なことがよくあります。移設は、ここを直す好機です。

old-site/images/ 配下の画像を、参照元のHTMLと突き合わせて
次の一覧をCSVにしてください。

  画像ファイル名 / 参照しているページ / alt属性の内容 / 参照されていない場合は「未使用」

altが空欄のものには、参照元ページの文脈から適切なalt文の案を添えてください。
案であることが分かるように、末尾に「（案）」と付けてください。

未使用の画像は移設しません。alt文の案は、そのまま使わず担当者が目を通してから採用します。

人が担当する範囲を決めておく

工程	Claude Codeに任せてよい	人が必ず担当する
本文の抽出・整形	◎	元原稿との差分確認
古いHTMLの整理	◎	表示崩れの最終確認
画像の棚卸し・alt案	◎	alt文の採否判断
URL対応表の下書き	◎	対応先の妥当性チェック
文章の中身・事実関係	✕	執筆と校正
公開の判断	✕	責任者の確認

紙媒体を扱ってきた会社には、校正の文化がすでにあります。その校正の目を、そのままWebにも持ち込むのが、いちばん確実な品質の担保になります。

---

Phase5：URL・フォーム・メールを配線する

デザインが仕上がっていても、移設が失敗するのはたいていこの工程です。不具合が見た目に現れないため、つい確認を省きたくなります。

しかし、移設で最も危険な3つの地雷は、すべてここに埋まっています。

地雷	起きること	対策
URLが変わる	検索結果とブックマーク、名刺のQRコードからの導線が404になる	旧URLから新URLへ301リダイレクトを1本ずつ設定する
フォームが届かない	見た目は送信できるのに、社内に通知が届かない	本番と同じ環境で実際に送信し、受信を確認する
メールが止まる	サーバを移した瞬間、独自ドメインのメールが受け取れなくなる	サイトとメールの契約を切り分け、MXレコードを確認する

URL対応表をつくる

ホームページビルダー製のサイトは /company.html のような拡張子つきのURLが中心です。WordPressの標準的なURLとは形が変わります。

旧URLと新URLの対応表を作り、1本ずつ転送を設定していきます。この対応表は、Phase2の棚卸し表がそのまま元になります。

inventory.csv の「ファイルパス」列を旧URL、
「移設後URL」列を新URLとして、
Apache用の301リダイレクト設定を .htaccess の形式で書き出してください。

- 旧URLが同じ行が重複していないか先に確認し、あれば指摘してください
- 移設後URLが空欄の行は、リダイレクト先が未定として別に一覧にしてください

「未定の行を別に出して」と頼むのが要点です。転送先が決まっていないページを見落とさないための仕掛けです。

転送は、機械的に検算する

設定を終えたら、思い込みではなく実測で確かめます。切替後にも同じ手順で確認します。

url-map.csv の旧URLを1件ずつ
curl -o /dev/null -s -w "%{http_code} %{redirect_url}" で確認して、
301で意図した新URLに転送されていない行だけを一覧にしてください。

数百ページでも数分で終わります。ただし、出てきた一覧は必ず自分の目で確認してください。ここは自動化してよい工程ですが、結果の判断まで任せてよい工程ではありません。

フォームとメールは「実際に送って」確かめる

フォームは、設置しただけでは動作を確認したことになりません。次の4点を、記名で確認します。

• 実際にフォームから送信し、指定した宛先すべてに届いた
• 送信者への自動返信が、迷惑メールに入らず届いた
• 添付ファイルや長文を送っても、文字化けせずに届いた
• 送信後の完了ページが正しく表示された

メールは、さらに注意が必要です。

独自ドメインのメールを同じサーバで運用している場合、サイトを移すつもりが、メールまで一緒に止まることがあります。切替の前に、メールがどこで動いているかを必ず確認してください。

---

Phase6：切り替えと、公開後1週間の確認

いよいよ公開です。作業自体は数十分で終わりますが、大切なのはそのあとの1週間です。

切替当日の手順

順番	作業	確認すること
1	旧サイトを丸ごとバックアップする	別の場所に保存し、いつでも戻せる状態にする
2	新サイトの検索避け設定を解除する	解除を忘れると、いつまでも検索に載りません
3	公開する（DNS切替、または公開設定）	反映まで時間差があることを見込む
4	301リダイレクトを有効にする	前節の方法で全ページを機械的に検算する
5	フォームから実際に送信する	本番環境でもう一度、届くことを確かめる
6	サイトマップをSearch Consoleへ送信する	併せてインデックス登録をリクエストする

切替は、週の後半や連休前を避けてください。何かあったときに、対応できる人がいる日を選ぶのが鉄則です。

公開後1週間で見るところ

確認する場所	見るもの	対応
Search Console	404エラーの発生、インデックス登録の状況	転送漏れがあれば当日中に追加する
フォームの受信箱	問い合わせが平常どおり届いているか	途絶えていれば設定を疑う
アクセス解析	流入数が極端に落ちていないか	落ちていればURLの転送を再確認する
サイト表示	スマートフォンでの表示崩れ	実機で主要ページを一通り開く

旧サイトのファイルは、すぐには消さないでください。1〜3ヶ月は保管しておけば、あとから「あのページの文章はどこへ行ったのか」と探すことになっても戻れます。

---

Claude Codeを安全に使うための4つのルール

移設作業でClaude Codeを使うと、棚卸しや変換にかかる時間は大きく縮みます。

ただし、使い方を誤ると、取り返しのつかない事故につながります。次の4つを、作業を始める前にチームで共有してください。

ルール	理由
本番のサーバには触らせない	作業は必ず手元のコピーと検証環境で行います。本番への反映は人の手で行います
作業前にバックアップを取る	変換や一括置換は、間違えたときの影響範囲が広くなります
生成物は人が検算する	リダイレクト表とフォームは、特に間違いが表に出にくい部分です
文言は書き換えさせない	指示に「文言は変更しないでください」と毎回明記します

もうひとつ、扱う情報にも注意が必要です。

顧客名簿や見積書など、公開を前提としないファイルを作業フォルダに置かないようにしてください。移設で扱うのは、あくまで公開中のサイトの中身だけです。

---

移設後の運用：更新を止めない体制をつくる

移設が終わったあと、いちばん避けたいのは「WordPressになったけれど、結局また特定の1人しか触れない」という状態です。ホームページビルダー時代と同じ構図に戻ってしまいます。

触れる人を2人にする

ご支援した会社では、デザイナー2名で運用を始めました。1人だけだと、休みや異動でそのまま更新が止まります。2人いれば、互いの作業を確認し合う関係も自然にできます。

覚える順番は、次のとおりです。難しいところから入る必要はありません。

1. WordPressの管理画面で、既存ページの文言を直す
2. ブロックエディタで、新しいページを1枚作る
3. 完成イメージ（印刷データ、写真、ラフ）を画像として用意する
4. Claude CodeにHTMLの初稿を作らせ、WordPressに組み込む
5. バックアップの取り方と、戻し方を覚える

コードを一から書けるようになる必要はありません。書かれているものを読んで、どこを直したいか指示できれば十分です。

公開前には以下の過去記事も参考に品質チェックすることもお勧めします。

Webサイト公開前チェックリスト10選｜失敗しないリリース手順

Webサイト公開前に必須の確認項目10選を解説。誤字脱字チェック、SEO対策、デバイス対応確認など、Web制作者が押さえるべきポイントをチェックリスト形式でまとめました。リリース前のチェックにぜひご利用ください

wanilablog.com

2025.05.29

月に一度の保守

項目	頻度	内容
WordPress本体・テーマ・プラグインの更新	月1回	更新前にバックアップを取る
バックアップの動作確認	月1回	取れているだけでなく、戻せるかを確かめる
管理者アカウントの点検	四半期	退職者のアカウント削除、2段階認証の有効化
不要プラグインの削除	四半期	停止中のプラグインも脆弱性の対象になります

---

移設が終わったら、新しいサービスをサイトに載せる

サイトを自社で更新できるようになると、いちばん大きく変わるのは速度です。思いついた週に試せるようになります。この身軽さを、いま伸ばしたい事業に向けます。

一般社団法人日本イベント産業振興協会（JACE）の2024年イベント産業規模推計を見てみます。イベント産業全体の規模は2兆8,535億円で、前年比108.3%と伸びています。

なかでもコンベンション分野は2019年比144.3%、レンタル・ディスプレイ分野は同152.2%です。展示会まわりの回復が、はっきり数字に出ています。

紙媒体を手がけてきた会社にとって、展示会出展支援は自然な延長線上にあります。パネル、カタログ、名刺は必ず付いてくるからです。問題は、その事実がサイトのどこにも書かれていないことでした。

まず直す3か所

直す対象	いまの状態	移設後にすること
構成	「事業内容」の下層に全サービスが並んでいる	紙媒体・イベント・展示会支援を、トップの第1階層に並べる
言葉	「トータルプロデュース」など社内の言い回し	「展示会 ブース 制作」など、お客様が実際に検索する言葉に書き換える
導線	問い合わせフォームがサイトに1つだけ	サービスごとに相談窓口と資料ダウンロードを用意する

認知は4段階で広げる

広告から始めたくなりますが、順番があります。受け皿のないまま集客しても、問い合わせにはつながりません。

1. 受け皿をつくる — サービスページ、事例3本、専用の相談フォーム
2. 既存のお客様に伝える — 納品物にQRコード付きの案内を同封し、営業が一言添える
3. 検索から拾う — 業務で使われる言葉でページを作り、Googleビジネスプロフィールにも掲載する
4. 露出を広げる — 事例が10本ほどたまってから、SNSと広告に着手する

---

まとめ

最後に、移設を安全に進めるための要点を5つに整理します。

1. まず現状を確かめる — ドメイン、サーバ、公開ファイル、制作データ、画像、メールの6つが誰の手にあるかを確認します。更新が止まる原因は、担当者ではなく手段の所在にあります
2. ページを1行ずつ棚卸しする — 残す・まとめる・やめるを機械的な基準で決めます。Claude Codeを使えば、数百ページでも数分で一覧になります
3. 本番を止めずに並行で作る — 検証環境で組み立て、検索避けを有効にしておきます。プラグインは最初から増やしすぎないことが肝心です
4. 移植はAI、確認は人 — 本文の抽出と古いHTMLの整理は任せられますが、文言の一致と公開の判断は人が担います
5. 配線と1週間の確認まででワンセット — 301リダイレクト、フォームの実送信、メールの継続の3つを検算するまでが移設です。公開した瞬間が終わりではありません

移設は、見た目を新しくする作業ではありません。自社の情報発信を、自分たちの判断で動かせる状態に戻す作業です。

まずは、いまのサイトの契約とデータが誰の手にあるかを確かめるところから始めてみてください。それだけで、移設が「いつかやりたいこと」なのか「いま決められること」なのかが見えてきます。

---

よくある質問