コンテンツ重視のWebサイトを高速に構築できるフレームワークとして人気を集めてきたAstroが、2026年6月22日にメジャーバージョンとなるAstro 7.0を正式リリースしました。今回の目玉は、フレームワークの心臓部であるコンパイラをRust製へ刷新し、あわせてビルド基盤をVite 8と新しいバンドラRolldownへ移行した点にあります。これによりビルド時間が大きく短縮され、静的サイト開発の生産性がさらに引き上げられました。
本記事では、フロントエンド開発者や静的サイトジェネレータに関心のあるエンジニア向けに、Astro 7.0で何が変わったのか、なぜRustとRolldownが採用されたのか、そして実際のアップグレード手順やRagateでの運用観点までを、公式情報を軸に整理して解説します。
Astro 7.0で何が変わったのか
Astroは、必要な場所にだけJavaScriptを届ける設計思想と、複数のUIフレームワークを同居できる柔軟さで、ドキュメントサイトやブログ、マーケティングサイトの構築に広く使われてきました。Astro 7.0はその路線を維持しつつ、これまで積み重ねてきた高速化の取り組みを一段先へ進めたリリースです。
変更の中心は大きく3つあります。1つ目は、Astroの独自コンポーネントである.astroファイルを解析するコンパイラをRust製へ置き換えたことです。2つ目は、開発サーバーと本番ビルドの両方をVite 8へ更新し、新しいバンドラRolldownを採用したことです。3つ目は、Markdown/MDXの処理をRust製の新しいプロセッサへ切り替える流れを既定化したことです。いずれもネイティブコードによる高速化という一貫した方向性を持っています。
公式ブログによると、これらの刷新によってビルド時間は多くのサイトで15%から最大61%短縮され、一部のサイトでは2倍以上速くなったと報告されています。単なる機能追加ではなく、基盤そのものを作り替えたバージョンだと言えます。
心臓部を刷新したRust製コンパイラ
Astro 7.0の最大の変化は、.astroファイルをHTMLとJavaScriptへ変換するコンパイラがRust製になったことです。従来のコンパイラはGo言語で書かれていましたが、Rust製の新コンパイラが実験的な位置づけから既定へと昇格し、旧コンパイラは置き換えられました。この新コンパイラはAstro 6の段階で実験的なフラグとして先行導入されており、実運用での検証を経て7.0で標準になった経緯があります。
Rust化のメリットは速度だけではありません。新しいコンパイラはエラー報告がより正確になり、問題のあるファイルと行を明確に指し示します。一方で、挙動はより厳格になりました。これまで暗黙のうちに補正されていた無効なマークアップ、たとえば閉じられていないタグや終端されていない属性は、自動修正ではなくビルドエラーとして扱われます。あいまいな状態を許さず、早い段階で不具合に気づける設計へと変わったわけです。
あわせて、Markdown/MDXの処理にもRust製の新しいプロセッサが導入されました。CommonMarkの解析やMDX式の処理をネイティブコードで一貫して行う設計で、変換のオーバーヘッドを抑えます。ただし、このネイティブなパイプラインは従来のremarkやrehypeといったJavaScript製プラグインをそのまま実行できないという制約があります。プラグインに依存している場合は、従来のプロセッサを引き続き選べる余地が残されているため、移行時には自分の構成を確認することが大切です。
Vite 8とRolldownがもたらすバンドラの統一
Astro 7.0はビルド基盤をVite 8へ更新し、その中核として新しいバンドラRolldownを採用しました。これはAstroだけの話ではなく、Viteエコシステム全体の大きな転換点でもあります。
これまでのViteは、開発時にはesbuild、本番ビルド時にはRollupという2つの異なるツールを使い分けていました。この二重構成は、それぞれの得意分野を活かせる反面、2つのプラグインシステムを橋渡しするための接着コードが増え、開発時と本番時で挙動が微妙に食い違う原因にもなっていました。Rolldownは、この2つの役割を1つのパイプラインへ統一することを狙って作られたバンドラです。
Rolldownを開発しているのは、ViteやVue.jsの作者であるEvan You氏が設立したVoidZeroです。RolldownはRust製で、esbuildに匹敵する処理速度を持ちながら、Rollupと互換性のあるプラグインAPIを備えている点が大きな特徴です。内部ではOxcと呼ばれるRust製の言語処理ツールチェーンを活用し、解析や最適化を高速に行います。RollupのプラグインAPIとの互換性が保たれているため、多くのAstroプロジェクトは設定を変えることなくVite 8へ移行できるとされています。速度と互換性を両立させ、これまで別々だった開発と本番の体験を1本のラインへまとめた点に、この移行の本質があります。
ビルド速度はどこまで改善したのか
気になるのは実際にどれだけ速くなるのかという点です。Astroの公式ブログでは、自社が運用する実在のサイトを対象にした計測結果が公開されています。
たとえばAstroのドキュメントサイトは114.54秒から73.53秒へ、Astroの公式サイトは62.70秒から24.24秒へと短縮されました。大規模なサイトであるCloudflareの開発者向けドキュメントは386.89秒から261.94秒へ、Tauriのサイトは86.12秒から55.33秒へと改善しています。全体としては15%から最大61%の短縮であり、規模の大きいサイトほど恩恵が見えやすい傾向がうかがえます。
なお、リリースにあわせて「60%以上の高速化」といった表現も見られますが、公式が示す一次的な数値はあくまで15%から61%という範囲です。数値を引用する際は、計測対象や条件によって差が出る点を踏まえ、上限値を一般化しすぎないよう注意すると安心です。ここで紹介した値も、いずれもAstro側が特定のサイトで計測した結果である前提で受け止めるのがよいでしょう。
Astro 7.0へのアップグレード手順と注意点
既存のAstroプロジェクトを7.0へ引き上げる手順は、公式のアップグレードガイドに沿って進めるのが確実です。基本的な流れは次のとおりです。
まず前提として、Astro 7.0が要求する新しいNode.jsのバージョンへ更新します。要求される最小バージョンはリリースごとに変わるため、公式のアップグレードガイドで最新の値を確認してください。ローカル環境だけでなく、CIやホスティング先の実行環境もあわせて確認しておくと、後段のトラブルを避けられます。次に、公式が提供するアップグレードコマンドを実行します。
npx @astrojs/upgradeこのコマンドは、Astro本体と公式インテグレーションを互換性のあるバージョンへまとめて更新してくれます。もしpackage.jsonのoverridesやresolutionsでViteを7系に固定している場合は、8系へ更新する必要があります。更新後にローカルでビルドを実行し、新しいRustコンパイラが厳格化によって指摘する無効なマークアップを、エラーが示すファイルと行に従って修正していきます。
あわせて、Markdown/MDXでremarkやrehypeのプラグインを使っている場合は、既定のRust製プロセッサでは動作しないため、従来のプロセッサを明示的に選ぶか代替手段を検討します。破壊的変更はいずれも移行ガイドに整理されているため、一度に本番へ反映せず、まずは検証環境で挙動を確認してから進めることをおすすめします。
RagateのAWS運用と静的サイトの相性
Astroで生成した静的サイトは、成果物が純粋なHTMLやCSS、必要最小限のJavaScriptで構成されるため、クラウド上での配信と非常に相性が良い点も見逃せません。Ragateが取り組んでいるAWSやAWS CDKを用いたインフラ構築の観点から見ても、Astroの出力はそのままAmazon S3へ配置し、Amazon CloudFrontから配信するという定番の静的ホスティング構成にきれいに収まります。
ビルドが速くなることは、こうした運用面にも効いてきます。CIの中でビルドにかかる時間が短くなれば、プルリクエストごとのプレビュー生成やデプロイのリードタイムが縮まり、コンテンツの更新サイクルを回しやすくなります。AWS CodeBuildなどのビルド環境でNode.jsのバージョンをAstro 7.0が要求する水準にそろえておけば、Astro 7.0の高速なビルドをそのままパイプラインへ取り込めます。インフラをコードで管理しつつ、フロントエンドのビルドも高速化できる組み合わせは、静的サイトを継続的に運用するチームにとって扱いやすい選択肢になるはずです。
Astro 7.0は、コンパイラとバンドラという足回りをネイティブコードで作り替え、静的サイト開発の速度と快適さを一段引き上げたリリースです。既存プロジェクトの移行は厳格化への対応が必要になる場面もありますが、得られるビルド高速化のメリットは大きく、これから静的サイトを構築するチームにとっても有力な選択肢であり続けるでしょう。まずは検証環境でアップグレードを試し、自分のプロジェクトでどれだけ速くなるかを確かめてみてください。
