Astro 7へ移行。見た目はそのまま、サイトの裏側は徹底的に作り直しました。

2026年07月29日 13時08分
2026年07月29日 13時47分

今回、KUMICODEをAstro 7へ移行しました。

サイトを開いても、以前との違いはほとんど分からないと思います。デザインもレイアウトも、大きく変わっていません。
ですが、その裏側では、この数週間にわたってサイトの構成を一から見直し、これまでで一番大きなアップデートを行いました。
今回の目的は、新しいデザインにすることではなく、表示速度・更新性・保守性を見直し、今後も長く運用できるサイトにすること。
この記事では、その移行で行ったことや、途中で苦労したことをまとめてみようと思います。

Astro 7へ移行した理由

KUMICODEはこれまでAstro 5で運用していました。

Astro 6がリリースされたときも移行は考えましたが、自分のサイトで使いたいと思えるような大きな変化は少なく、そのままAstro 5を使い続けることにしました。
一方、Astro 7では Route Cache や Vite 8 への対応など、パフォーマンスや開発体験に関わるアップデートが多く含まれていました。
特に、以前から「更新のたびに再デプロイが必要」という運用を改善したいと考えていたこともあり、今回のタイミングで本格的に移行することを決めました。
最初は、ライブラリを更新して少しコードを修正すれば終わるだろうと思っていました。
……この時は、サイトの裏側をここまで大きく作り直すことになるとは、まだ思ってもいませんでした。

軽いアップデートのつもりだった

Astro 5からAstro 7への移行は、最初はそれほど大掛かりな作業になるとは思っていませんでした。

依存関係を更新し、非推奨になった部分を少し修正すれば終わるだろう。そんな軽い気持ちで作業を始めました。ところが実際に手を動かしてみると、想像以上に修正箇所が多く、ひとつ直すと別の場所で問題が見つかる状態に。

せっかくここまで手を入れるなら、この機会に以前から気になっていた部分もまとめて改善しようと考え、レンダリング方式や画像管理、WordPressとの連携など、サイト全体の設計を見直すことにしました。

結果として、単なるAstroのアップデートではなく、サイトの裏側を一から作り直すような大規模なリファクタリングになりました。

型エラー祭りの始まり

Astro 7へ移行するため、まずは依存関係を最新の状態へ更新しました。

Astro本体だけでなく、Vite 8への対応や各ライブラリのアップデートも必要になり、いよいよ本格的な移行作業がスタートです。ところが、開発サーバーを起動した瞬間から画面いっぱいに並ぶ型エラー。

ひとつ修正すると別のエラーが現れ、それを直すとまた別のエラーが現れる…。まるで終わりの見えないもぐら叩きのような状態でした。

TypeScriptの型定義やライブラリごとの変更点を一つずつ確認しながら修正を進め、ようやくビルドが通ったと思えば、今度は実際の動作確認で新たな問題が見つかることも。

結果として、単純なバージョンアップでは済まず、その後の設計変更へとつながるスタート地点になりました。

サイトの裏側を徹底的に見直しました

全ページSSGを卒業

KUMICODEはこれまで、すべてのページをSSG（Static Site Generation）で生成していました。

SSGはブラウザで表示するべくファイルが静的に存在するため、表示速度が非常に速く、静的サイトとしては理想的な構成です。実際、表示速度だけを考えるなら、今でもSSGが最も優れた選択肢だと考えています。

一方で、ブログや作例、予約状況など更新頻度の高いページでは、ちょっとした修正でもサイト全体を再デプロイする必要があり、運用面では少し不便さも感じていました。

そこで今回のアップデートでは「すべてをSSGにする」という考え方を見直し、ページごとに最適なレンダリング方式を選ぶ構成へ変更しました。

更新の少ないページはこれまでどおりSSGを維持し、更新頻度の高いページだけSSR（Server Side Rendering）とRoute Cacheを組み合わせることで、表示速度と運用性のバランスを取っています。

「SSGかSSRか」ではなく「ページの役割に合わせて使い分ける」

今回のアップデートでは、この考え方がサイト全体の設計を大きく変えるきっかけになりました。

SSR + Route Cacheへ移行

ブログや作例など、更新頻度の高いページはSSRへ移行しました。

SSRというと、PHPやWordPressのように「アクセスのたびにサーバーでページを生成する」というイメージを持つ人も多いと思います。私自身も、最初はその印象でした。

しかし、Astro 7のRoute Cacheは少し考え方が異なります。

初回アクセス時だけサーバーでページを生成し、その結果をキャッシュとして保存。以降はキャッシュを配信するため、毎回ページを生成するわけではありません。

さらに、WordPressで記事を更新した場合も、サーバー側で更新をキャッチ、古いキャッシュをすぐに破棄して利用者に待たせるのではなく、古いキャッシュを返しながら裏側で新しいページを生成し、次回以降は新しいキャッシュを配信するという仕組みになっています。

つまり、更新性を高めながらも、利用者にはできるだけキャッシュミスを感じさせない構成を実現できるようになりました。

Route Cacheを理解するまでが一番大変でした

今回の移行で一番時間をかけたのは、実はRoute Cacheを理解することでした。

最初は「SSRなのだから、アクセスのたびにページを生成するもの」という認識でいたため、Route Cacheがどのタイミングで生成・更新されるのかがなかなか理解できませんでした。

ドキュメントを読み込み、レスポンスヘッダーを確認しながら何度も検証を繰り返す中で、ようやくRoute Cacheの動きを把握できました。

初回アクセス時はキャッシュが存在しないため MISS となり、サーバーでページが生成されます。その後は生成されたページがキャッシュされ、HIT として高速に配信されます。

さらにWordPressで記事や作例を更新すると、キャッシュは STALE の状態になります。このとき利用者には古いキャッシュを返しつつ、裏側では新しいページの生成が始まり、生成が完了すると自動的に新しいキャッシュへ切り替わります。

この仕組みを理解してからは、「更新した瞬間に全員がキャッシュミスを踏む」ような構成ではなく、利用者にはできるだけ待ち時間を感じさせず、裏側でキャッシュを更新していく設計を意識するようになりました。

Route Cacheは単なるキャッシュ機能ではなく、サイト全体の設計を考え直すきっかけになった機能だったと感じています。

server:deferに救われた

SSRへの移行を進める中で、もう一つ大きな課題がありました。

トップページやカテゴリページは更新頻度が低いため、できるだけSSGのまま運用したい。一方で、そこに表示している「最新のブログ」や「最新の作例」は、常に最新の状態を表示したいという要件もありました。

ページ全体をSSRにしてしまえば解決できますが、それではSSGのメリットを十分に活かせません。

そこで今回、本格的に導入したのが、以前からAstroに用意されていた server:defer です。

最新のブログ一覧や作例一覧だけをServer Islandとして切り出し、必要な部分だけをサーバーでレンダリングすることで、ページ本体はSSGのまま高速に配信しつつ、更新頻度の高いコンテンツだけを常に最新の状態で表示できるようになりました。

さらに server:defer は、ページの初期表示とは切り離してコンテンツを読み込めるため、ファーストビューの表示やLCPへの影響を抑えながら、動的なコンテンツだけを後から描画できます。ページ全体の表示速度を維持しつつ、必要な部分だけを別駆動で取得できるのは、大きなメリットでした。

これにより、トップページやカテゴリページを再デプロイすることなく最新情報を反映できるようになり、SSGとSSR、それぞれの長所を活かした構成を実現しています。

今回の移行では、新しい機能を採用したというよりも、以前から存在していた server:defer を本格的に導入したことで、これまで実現できなかった設計を形にすることができました。

Imageコンポーネントから脱却

AstroのImageコンポーネントは、とても便利な機能です。私自身も長い間利用してきましたし、小〜中規模のサイトであれば十分すぎるほど優れた仕組みだと思います。

しかし、KUMICODEのようにブログや作例など数千枚規模の画像を管理するようになると、少しずつ別の課題が見えてきました。

画像サイズを追加・変更すると、既存の画像も含めて新しい画像を生成し直す必要があったり、運用を続けるほど生成される画像の数も増えていきます。

もちろん、これはAstro Imageの欠点というより、静的生成だからこその仕組みです。

WordPress標準のsrcset・sizesで一元管理

そこで今回の移行では、画像管理の考え方そのものを見直すことにしました。

そこで今回の移行では、画像の最適化をAstro側ではなく、WordPress側で一元管理する構成へ変更しました。

WordPressは画像をアップロードした時点で、複数サイズの画像を生成し、srcsetとして流用することができます。

これまではAstro側でも画像を管理していましたが、画像が増えるほど管理対象が分散し、運用も複雑になっていました。

そこで、画像に関する役割はWordPressへ集約し、Astroは表示に専念するという役割分担へ変更しました。

これにより、画像サイズの管理やレスポンシブ画像の生成はWordPressだけで完結し、Astro側で画像を再生成する必要もありません。

コンテンツが増えても運用しやすく、長く管理していける構成になったと感じています。

WordPressとの連携も一から見直しました

Astro側の設計を見直したことで、WordPressとの連携方法も大きく変わりました。

今回の移行では、単に表示側を作り直しただけではありません。データの取得方法や管理方法まで見直し、フロントエンドとWordPressそれぞれの役割を整理しながら、運用しやすい構成へ作り直しています。

必要なデータだけ取得するAPIへ

以前はWordPress REST APIをそのまま利用していました。

REST APIは非常に柔軟な仕組みですが、その分、表示には不要な情報まで取得していました。また、取得後にフロントエンド側でデータを加工する処理も多く、コードが複雑になりがちでした。

そこで今回、表示に必要な項目だけを返す専用APIへ変更しました。

タイトルやスラッグ、公開日、画像情報など、利用するデータだけを返すようにしたことで、レスポンスはシンプルになり、フロントエンド側の処理も大幅に減らすことができました。

WordPress APIを刷新

専用APIを作るだけでなく、APIの構成自体も見直しました。

以前はWordPress REST APIを中心に利用していましたが、今回の移行ではサイトの構成に合わせてAPIを整理し、それぞれの役割を明確にしています。

ブログはブログ、作例は作例、予約ページはスケジュールといったように、用途ごとに必要なデータだけを返すAPIへ分割しました。

その結果、フロントエンド側では「必要なAPIを呼び出すだけ」で目的のデータを取得できるようになり、データ加工や分岐処理も大幅に減らすことができました。

APIをWordPress標準の構造に合わせるのではなく、フロントエンドが扱いやすい形に最適化するという考え方へ切り替えたことで、コードの見通しも良くなり、今後の機能追加やメンテナンスもしやすい構成になっています。

独自プラグインを作成

今回のAPIは、WordPressのテーマ内ではなく、独自プラグインとして実装しました。

テーマから切り離すことで、デザインの変更とAPIの機能を分離でき、保守性も向上しています。

また、ブログや作例など、それぞれのAPIをクラスごとに整理し、画像処理や共通レスポンスも役割ごとに分けることで、今後機能を追加するときも影響範囲を最小限に抑えられる構成にしました。

サイトの規模が大きくなるほど、「動けば良い」という実装では管理が難しくなります。

今回の移行では、将来の運用や機能追加まで見据えて、WordPress側も一つのアプリケーションとして設計し直しました。

管理画面も使いやすく改善

フロントエンドやAPIだけでなく、WordPressの管理画面も見直しました。

今回のAstro 7への移行では、当初はフロントエンドの改善が目的で、WordPressの管理画面まで大きく手を入れる予定はありませんでした。

しかし、ブログや作例がWordPressの更新だけで公開できるようになると、「予約状況も同じように管理したい」と考えるようになりました。

そこで、スケジュール管理もWordPressへ移行し、カスタム投稿タイプとして新しく作成しました。

年月日やタイムラインなどの情報はカスタムフィールドで管理できるようになりましたが、標準の管理画面では投稿順に並ぶだけで、実際の撮影スケジュールとしては使いづらい状態でした。

そこで独自プラグインを作成し、スケジュール順に並び替える機能を追加。今日以降の予定を上から年月日順に表示し、終了したスケジュールは一覧の下部へ移動して薄く表示するようにしました。

さらに、タイムラインも時間帯ごとに色分けして表示することで、一目でその日の予定が把握できるようになっています。

その結果、単なる入力画面ではなく、KUMICODEの撮影スケジュールを確認するための管理画面としても活用できるようになりました。

更新しやすく、運用しやすいサイトになりました

サイトを長く運営していく中で感じていた「更新のしづらさ」や「運用の手間」を一つずつ見直した結果、以前よりもはるかに管理しやすい構成になりました。

ブログや作例はWordPressを更新するだけで公開できるようになり、画像管理もWordPressへ集約。さらに、独自APIや管理画面の改善によって、更新作業そのものもシンプルになっています。

サイトは完成した瞬間よりも、その後何年も運用し続ける時間の方が圧倒的に長くなります。だからこそ、日々の更新や保守を無理なく続けられることを、今回のアップデートでは特に重視しました。

再デプロイなしで更新できるようになりました

今回の移行で、一番大きく変わったのは運用方法かもしれません。

これまでは、ブログや作例を1件更新するだけでもサイト全体を再デプロイする必要がありました。コンテンツの内容は数分で修正できても、その後にビルドやデプロイが完了するまで待たなければ公開できませんでした。

今回、ブログ・作例・スケジュールをSSRとRoute Cacheを利用した構成へ変更したことで、WordPressで更新するだけですぐに反映できるようになりました。

「更新したい」と思ったタイミングで、そのまま公開できる。この違いは想像以上に大きく、日々の運用がとてもスムーズになっています。

更新のたびにデプロイを意識する必要がなくなったことで、コンテンツを追加・修正する心理的なハードルも下がり、以前より気軽にサイトを育てられる環境になりました。

デプロイ時間も大幅に短縮

今回の移行では、デプロイ時間も大きく改善しました。

以前は、ブログや作例を含めた多くのページをビルドしていたことに加え、画像生成もAstro側で行っていたため、デプロイには約10分ほどかかることもありました。

しかし、更新頻度の高いページをSSRへ移行し、画像管理もWordPressへ集約したことで、ビルド対象が大幅に減少。現在では、環境にもよりますが約30秒ほどでデプロイが完了するようになっています。

もちろん、デプロイ時間を短くすること自体が目的ではありません。

ビルドを待つ時間が短くなったことで、細かな修正やデザインの調整も気軽に繰り返せるようになり、開発全体のテンポも大きく向上しました。

ようやく本番リリース

数週間にわたるAstro 7への移行を終え、ようやく本番環境へリリースすることができました。

当初は「Astro 7へアップデートするだけ」のつもりでしたが、作業を進めるうちに、レンダリング方式やキャッシュ戦略、画像管理、WordPressとの連携、管理画面まで見直す大きなプロジェクトになっていました。

検証と試行錯誤を繰り返した結果、一つひとつの仕組みを理解しながら改善できたことは、とても大きな収穫だったと感じています。

見た目は以前と大きく変わっていません。しかし、サイトの裏側は以前とはまったく別物と言えるほど作り直すことができました。

ここからは、今回の移行を通して得られたことと、今後さらに取り組んでいきたいことについて紹介します。

今回の移行で得られたこと

今回の移行で得られたものは、Astro 7へのアップデートだけではありませんでした。

Route Cacheやserver:deferを実際に設計へ取り入れ、検証を繰り返す中で、「SSGとSSRはどちらが優れているかではなく、それぞれの特性を活かして使い分けることが大切」という考え方を、以前より深く理解できるようになりました。

検証を重ねる中で、Route CacheとPrefetchの組み合わせが実運用ではとても相性が良いことにも気付きました。Prefetchに対応したブラウザでは、利用者がリンクをクリックする前にページの取得が始まるため、Route Cacheが事前に温まり、初回アクセスでもMISSを減らせる可能性があります。こうした挙動は、実際に検証を繰り返したからこそ得られた発見でした。

そして何より大きかったのは、「更新頻度の高いものは動的に、変わらないものは静的に」という考え方を軸に、サイト全体を設計できるようになったことです。

表示速度だけでなく、保守性や更新性、そして将来の拡張性まで含めて考えられるようになったことが、今回の移行で得られた一番の成果だったと感じています。