「サイトが重い」「更新しづらい」「使っているフレームワークが古いらしい」。この3つを並べて制作会社に相談すると、返ってくる見積もりはたいてい「全面リニューアル」です。
見積もりの金額は、デザインの作り直しとページの再構築で膨らみます。ところが元の相談は速度と更新性の話であって、デザインを変えてほしいとは一言も言っていないことがよくあります。それでも作り直しの提案になるのは、既存の中身をどこまで再利用できるかを調べる作業自体に手間がかかり、調べる前に「作り直したほうが早い」と判断されるからです。
2026年9月の Astro 公式事例で紹介された、Evil Martians が同年8月に自社サイトを Gatsby から Astro へ移した記録は、この前提を検討し直す材料になります。エンジニア1人、9日間、既存の React コンポーネントは1つも書き換えていません。
何を残して、何を替えたのか
この移行で置き換えられたのは、ページを組み立てる層とデータを取り出す層です。
Gatsby では、静的なサイトであってもコンテンツを GraphQL 経由で取り出す構造になっていました。移行後は Astro のコンテンツコレクションに置き換わり、型の付いたコンテンツと通常の非同期関数でデータを読む形になっています。サイトの見た目を作っている部分ではなく、その手前の配管を替えたという整理です。
一方、UI を構成する React のコンポーネント群はそのまま持ち込まれています。Astro のアイランドアーキテクチャでは、ページの外側は Astro が組み立て、ブラウザ上で動く必要がある部分だけを個別に指定して動かします。外側だけ替えて、中身は触らないという移し方ができるため、コンポーネントの書き換えが発生しませんでした。
数字がどう動いたか
公開されている実測値は次のとおりです。
| 指標 | 移行前 | 移行後 |
|---|---|---|
| トップページの読み込み時 JavaScript | — | 全体で61%減 |
| モバイルの Lighthouse パフォーマンス | 66 | 90 |
| トップページの重量 | 2.1MB | 1.8MB → 1.1MB |
トップページの重量が2段階で書かれているのは、意味が違うからです。1.8MB は「React コンポーネントを一切変えずに移しただけ」の数字で、1.1MB はその後にどの部分をブラウザで動かすかを見直した結果です。
つまり、移行そのものの効果と、移行後のチューニングの効果が分かれています。見積もりを読むときにこの2つが1つの行にまとまっていると、どこまでが必須でどこからが追加投資なのかが分かりません。
自社のサイトで同じことができるか
この事例をそのまま当てはめられるかどうかは、3つの条件で決まります。
1. いまのサイトがコンポーネントで組まれているか。 React や Vue でコンポーネントに分割されているなら、持ち込める資産があります。HTML テンプレートも部分的には再利用できますが、データ取得やイベント処理の依存を別途調べる必要があります。
2. デザインを変えたいのか、変えなくていいのか。 デザインを刷新したい場合、コンポーネントを残す利点は小さくなります。その場合も、データ層や一部のコンポーネントを残せるかは個別に検討できます。「速くしたい」と「見た目を変えたい」を分けて発注すると、金額の根拠がはっきりします。
3. コンテンツの管理方法を変える必要があるか。 記事や実績を CMS で管理していて、その CMS を変えないなら、移行対象は表示側だけです。CMS ごと乗り換えるなら、データ移行と編集者の操作変更を別の作業項目として見積もります。
この3つが「コンポーネントあり・デザイン維持・CMS 維持」に揃うなら、全面作り直しの見積もりが出てきた時点で、なぜ再利用しないのかを聞く価値があります。
移行先を選ぶときに見るところ
Astro を選ぶかどうかとは別に、移行先の判断で見ておくべき点があります。
更新が継続的に出ているか。 Astro は 7.3 が2026年9月3日に出ており、細かい改善が定期的に入っています。フレームワークの選定で問題になるのは新機能の多さではなく、数年後も更新が続いていて、その更新を自社の保守に組み込めるかです。
移行の手順が公式に文書化されているか。 Astro には Gatsby からの移行ガイドが公式ドキュメントとして用意されています。手順が公開されているかどうかは、見積もりの精度に直結します。手順がない移行は、調査工数が読めません。
自社で更新できる形になるか。 移行してもコンテンツの更新が制作会社経由のままなら、更新しづらさは解消しません。公開後に自社で触れる構成かどうかを、移行の要件に入れてください。
なお、フレームワークの選択そのもので迷っている段階なら、Next.js と Astro の使い分けを先に読むほうが早いはずです。
つまずきやすいところ
「9日」を自社の工数の目安にしない。 この9日は、自社サイトを自社のエンジニアが移した数字です。仕様の確認や関係者の合意に時間が要る受託の案件では、同じ作業でも日数の意味が変わります。参考にすべきは日数ではなく、コンポーネントを書き換えずに済んだという構造のほうです。
URL を維持する要件を明記する。 移行でページのURLが変わると、検索からの流入がそこで切れます。旧URLから新URLへの転送を含めるかどうかは、見積もりに明示されていないことがあります。
速度の改善は移行だけでは終わらない。 上の表のとおり、大きく効いたのは移行後の見直しの部分です。移行完了をゴールにすると、期待していた速度に届かないまま終わります。どこまでを1回目に含めるかを、着手前に決めてください。
次にやること
自社サイトのトップページで、ブラウザの開発者ツールを開いて読み込まれている JavaScript の合計サイズを確認してください。数値そのものより、その JavaScript がページ上のどの機能のために必要なのかを説明できるかどうかが判断材料になります。
説明できない読み込みが大半を占めているなら、それは作り直しではなく、組み立て方を替えるだけで軽くなる可能性があります。
既存サイトを作り直さずに移せるかどうかの調査、URL を維持したままの移行、公開後に自社で更新できる構成の設計については、グリームハブのHP制作・リニューアル相談で承っています。現在の構成と更新の体制によって進め方が変わるため、範囲は個別にお見積りします。お問い合わせからご相談ください。
