先週、あるクライアントから「WordPressからAstroに移行したいんですが、どのくらいかかりますか？」という質問を受けた。
よくある質問だ。問題は「答えが案件によって全然違う」という現実で、ざっくり「2ヶ月くらいです」と言うと「思ったより長い」という顔をされる。「2〜3週間でできます」という声を聞いたことがあるようで、それと比べられることもある。
正直なところ、2〜3週間でまともに移行できた案件を私は経験したことがない。かといって「半年かかります」は多すぎる。現実は6〜10週間の範囲に収まることが多い。今回はその内訳と、なぜブレるのかを整理しておこうと思う。
6〜10週間の工程分解
移行案件で繰り返してきた標準的な工程はだいたいこの流れだ。
| 工程 | 時期（目安） | 主な作業 |
|---|---|---|
| 要件整理 | Week 1〜2 | ページ棚卸し、リダイレクトマップ作成、フォーム代替の検討 |
| 設計 | Week 2〜3 | Astroプロジェクト構造、コンテントコレクション設計、デプロイパイプライン選定 |
| 実装 | Week 3〜5 | コンポーネント実装、コンテンツスキーマ確定、既存コンテンツのMDX変換 |
| コンテンツ流し込み | Week 5〜7 | 顧客によるコンテンツ確認・修正（ここが最も読めない） |
| デプロイ準備 | Week 7〜8 | 本番環境構築、DNS切替前テスト、リダイレクト確認 |
| 検収・切替 | Week 8〜10 | ステージング確認、顧客最終確認、ドメイン切替、保証期間 |
これで6〜10週間のどこに着地するかは、主に3つの要因で決まる。
6週で終わる案件と10週かかる案件の差
最大の変数は「顧客側の動き」だと考えている。
6週で終わる案件には共通した特徴がある。コンテンツ確認の担当者が明確で、レスポンスが速い。ドメイン切替の判断権限を持っている人間が最初から決まっている。「今のWordPressのコンテンツは全部移行しない。新しく整理するので一部でいい」という決断ができる。
逆に10週に近づく案件では、コンテンツ確認が社内合議になって1〜2週間動かない状況が発生する。ドメイン切替については「上の人に確認します」で止まる。古いWordPressのコンテンツを全部移行したい——でもどれが必要でどれが不要かの判断は後回し、という状態になる。
技術的な工程そのものはほとんど変わらない。工程をブレさせるのはほぼ常に「顧客側のタスク消化速度」だ。
詰まりやすい工程ベスト3
技術側で詰まりやすい箇所を、実際に時間を食った頻度順に挙げておく。
1位：リダイレクト設計
WordPressのURLは /category/post-slug/ のように階層を持つことが多い。Astroに移行するとURL構造が変わることがほとんどで、SEO的に既存のURLをできるだけ維持したいニーズと、新しい構造に整理したいニーズが衝突する。
最初にやったのは「全部の旧URLをCloudFront Functionsでリダイレクト処理する」というアプローチだった。
// CloudFront Functions でリダイレクトを処理する例
// 改善の余地あり：ルール数が増えると関数サイズ上限に近づき、管理も煩雑になる
function handler(event) {
const request = event.request;
const uri = request.uri;
const redirectMap = {
'/category/news/old-post-title/': '/news/old-post-title/',
'/about/company-profile/': '/about/',
// ... 100件以上続く
};
if (redirectMap[uri]) {
return {
statusCode: 301,
headers: { location: { value: redirectMap[uri] } },
};
}
return request;
}これ、URLが100件を超えてくると実際につらくなる。CloudFront Functionsのコードサイズ上限（10KB）に近づくうえ、変更のたびにデプロイが必要になる。後から外部のリダイレクト管理サービスを挟む方が、運用を考えると楽だったと今は思っている。
2位：画像移行
WordPressのメディアライブラリに積み上がった画像をどう扱うかは毎回少し悩む。rsyncで一括取得してAstroの public/images/ に置くのが基本だが、問題は「記事本文にハードコードされたパス」だ。
# WordPress のメディアファイルをまとめて取得する
rsync -avz --include="*.jpg" --include="*.png" --include="*.webp" \
user@wp-server:/var/www/html/wp-content/uploads/ \
./public/images/wp-uploads/
# 記事本文に埋め込まれた旧パスを洗い出す（これが思ったより多い）
grep -r "wp-content/uploads" ./src/content/news/ | wc -l/wp-content/uploads/2021/03/image.jpg のようなパスが記事本文に直接書かれているケースが多く、それを全件洗い出して新しいパスに書き換える作業が発生する。ページ数が多いと半日作業になる。
3位：フォーム代替
問い合わせフォームをどう移行するかは、選択肢が複数あって毎回選定が入る。
| 方法 | 月額コスト目安 | 実装工数 | 向くケース |
|---|---|---|---|
| Formspree等のSaaS | 0〜数千円 | 低 | シンプルな問い合わせフォーム |
| Google Apps Script | ほぼ0円 | 中 | スプレッドシート管理が好きな顧客 |
| Lambda + API Gateway | 従量課金（ほぼ0〜） | 高 | 既存のAWS構成と統合したい場合 |
運用を考えると、どれかが明らかに優れているわけではない。顧客の体制（誰がメール通知を受け取るか、問い合わせ履歴をどこで管理したいか）によって選択肢が変わる。これを最初のヒアリングで詰め切れていないと、実装途中で仕様が変わるという事態になる。
顧客側タスクの現実的な所要時間
ここが最も伝えにくい部分だが、正直に書いておく。「コンテンツ確認をお願いします」と渡してから返ってくるまでの時間は、顧客の体制によって大きく違う。
| 顧客の体制 | コンテンツ確認 | ドメイン切替判断 |
|---|---|---|
| 担当者が明確で決裁権限もある | 3〜5営業日 | 当日〜翌日 |
| 担当者はいるが別部署の確認が必要 | 1〜2週間 | 1週間程度 |
| 担当者が兼任でレスが非同期 | 2〜3週間 | 2週間以上になることも |
| 社長決裁が必要（中小企業に多い） | ケースバイケース | 社長の空き次第 |
「ドメイン切替判断」は特に軽く扱われやすいが、実際には慎重に進める必要がある。DNSのTTLを事前に下げておく作業、MXレコードの確認、切替後のモニタリング体制——「じゃあ来週月曜にやりましょう」と言われても、月曜に問題が起きれば即座に対応できる人間が顧客側に必要になる。この確認を最初にしておくかどうかで、切替直前の混乱度がかなり変わる。
振り返って
最近は最初のヒアリングで「顧客側のタスク一覧」を明示するようにしている。「こちらがやること」「御社にやっていただくこと」を並べた表を作り、後者を説明してから見積もりを出す。
それをするようになってから、「6週か10週か」の幅の説明がしやすくなった。「御社の体制が〇〇であれば6週に近づけられますが、〇〇の場合は8〜10週を見てください」という会話が最初からできる。
技術的な工程の精度は経験を積めば上がるが、顧客側の動きはコントロールできない。だから最初に「どこが自分たちの手から離れるか」を明確にしておくことが、スケジュール管理上最も重要だと今は考えている。
まだ試行錯誤中の部分も多い。リダイレクト設計の標準パターンはもう少し整理できると思っているし、フォーム代替の選定フローも毎回ゼロから考えている感覚がある。もう少し型を決められるといいのだが——というのが今の正直なところだ。
