オウンドメディアを2年も続けると、記事は自然に数百本になります。そして、あるときから誤字をひとつ直すだけの修正でも、公開されるまで十数分待たされるようになります。中身は1ページしか変わっていないのに、静的サイトジェネレータは全ページを作り直しているからです。
これは体感の問題では済みません。修正が反映されるまで待つ時間は、そのまま「気づいたけど後回しにする」の理由になります。記事の数が増えるほどメディアの価値は上がるのに、同じ理由でメンテナンスの腰が重くなるという逆行が起きます。
このサイト自体も Astro で作られていて、記事数は700本を超えています。全ページを毎回生成する構造のまま記事を積み上げると、いずれどこかで運用が詰まるのは避けられません。
Astro 7.2 が削りにいったのは「生成」の工程
2026年8月6日に公開された Astro 7.2 は、実験的機能として増分静的ビルドを導入しました。これまで Astro は、何も変わっていないページであってもビルドのたびに再レンダリングしていました。増分静的ビルドは、その部分をまるごと飛ばします。
有効化は experimental.incrementalBuild フラグで行います。そのうえで、各ルートが getStaticPaths() からパスごとの cacheKey を返すことで対象になります。
// astro.config.mjs
export default defineConfig({
experimental: {
incrementalBuild: true,
},
});// src/pages/media/[slug].astro
export async function getStaticPaths() {
const posts = await getCollection('media');
return posts.map((post) => ({
params: { slug: post.slug },
props: { post },
// データが変わったら値が変わるものを返す
cacheKey: post.data.date.toISOString() + post.body.length,
}));
}cacheKey は、そのパスのレンダリングに使ったデータが変わったときに値が変わるものを返します。ここは開発側の責任範囲です。一方でコード側の変更は Astro が面倒を見ます。ビルド中に各ルートのモジュールグラフ全体をハッシュ化するので、テンプレート・レイアウト・コンポーネント・読み込んだアセット、さらにそれらが依存するパッケージのコードまでが対象になります。レイアウトを1行直せば、そのレイアウトを使う全ページが再生成される、という判定が自動で効くということです。
CI で効かせるにはキャッシュを持ち越す必要がある
ここが実務上の落とし穴です。増分ビルドは、前回のビルド結果を持っていることが前提になります。Astro は毎回出力ディレクトリを空にし、スキップしたページをキャッシュディレクトリから復元します。つまりキャッシュが消えていれば、増分ビルドを有効にしていても全ページ生成に戻ります。
CI は基本的に毎回まっさらな環境で走るので、既定の構成なら node_modules/.astro/ をビルド前後でキャッシュ・復元する必要があります。ローカルでは速くなったのに CI では変わらない、という報告が出るとしたら、まずここを疑うことになります。
自社の配信基盤がどうなっているかで手当ての場所が変わります。GitHub Actions ならキャッシュアクションを挟む、Cloud Build なら成果物バケットを経由する、といった形です。この工程を入れずに「増分ビルドを入れたのに速くならない」と結論を出すのは早すぎます。
7.2 に入った残り3つ
増分ビルド以外にも、運用側に効く変更が入っています。
- セッションサポートのオプトアウト — セッションを使わない静的サイトで、不要な機構を外せるようになりました
astro previewのバックグラウンドモード — プレビューサーバーをバックグラウンドで動かせるようになり、確認作業とほかの作業を並行させやすくなります- 相対パスでのロガー指定 — カスタムロガーの指定方法が簡素になりました
いずれも派手ではありませんが、日々の作業のうち「待っている時間」を削る方向で揃っているのが 7.2 の性格です。
増分ビルドで解決しないこと
ビルド時間が伸びる原因は、ページの生成だけではありません。画像の最適化、全文検索インデックスの生成、外部APIからのデータ取得は、いずれも増分ビルドの守備範囲外です。数百本規模のメディアで「ビルドが遅い」と感じるとき、実際の内訳は生成以外に寄っていることもあります。
ですので、フラグを入れる前にどの工程に何秒かかっているかを一度測るほうが確実です。生成が支配的でないなら、増分ビルドの効果は期待より小さくなります。
Astro 7 系そのものへの移行をまだ済ませていない場合は、先にそちらが前提になります。移行時の注意点はAstro 7.0 アップグレードの勘所に、コーポレートサイトの基盤として Astro を選ぶかどうかの判断材料はコーポレートサイトの基盤にAstroを選ぶ前ににまとめています。静的サイト生成という構成そのものの向き不向きはJamstackという選択肢を参照してください。
なお、増分ビルドは執筆時点で実験的機能です。本番の配信パイプラインへ即座に入れる性質のものではありません。まずステージング環境で有効にして、キャッシュを持ち越したときと消したときの両方でビルド時間を測る、という順序が現実的です。
次にやること
いまのメディアで、記事を1本だけ修正したときのビルド時間を測ってみてください。その時間が5分を超えているなら、修正の腰が重くなる水準に入っています。そのうえで、内訳のうち生成工程が何割かを見れば、増分ビルドで解決する問題かどうかが判断できます。
記事数の増加に耐える構成への作り替えや、公開までのフローの見直しを相談したい場合は、グリームハブのHP制作・リニューアル相談で承っています。記事数・画像量・配信先によって適切な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
