Astroの「コンテンツ駆動」とは？ Next.jsとの3つの違いから設計思想を紐解く
前提と背景
今、皆さんが見ている本サイトは、Astroというフレームワークを用いて作成している。Webサイト1つ作るにしても様々な選択肢が用意されている現代において、Astroを選ぶにあたって大きな魅力と感じた「コンテンツ駆動」について、改めて深掘りしていきたいと思う。
さて、深掘りに入っていく前に、そもそも「コンテンツ駆動」とは何か？ Astroの公式HPには「コンテンツ駆動」の章が設けられており、そこには下記のような記載がある。
Astroは、コンテンツが豊富なウェブサイトを構築するために設計されています。 これにはマーケティングサイト、出版サイト、ドキュメントサイト、ブログ、ポートフォリオ、ランディングページ、コミュニティサイト、eコマースサイトが含まれます。見せるべきコンテンツがあるなら、読者に素早く届ける必要があります。
「見せるべきコンテンツを素早く届けるために必要な機能が、Astroには用意されている」と理解した。上記はさらに下記のように続く。
これに対して、モダンなウェブフレームワークの多くは、ウェブアプリケーションを作成するために設計されています。これらのフレームワークは、ブラウザ上におけるより複雑な、アプリケーションのような体験を作成するのに適しています。
コンテンツ駆動の思想に基づいて設計されたフレームワーク「Astro」に対し、モダンなウェブフレームワークはウェブアプリケーションを作成するために設計されているという違いがあるらしいことが説明されている。しかし、この文言を読んだだけでは、Astroというフレームワークが持つ「コンテンツ駆動」の思想がいまいち飲み込めなかった。 この理解をするために、モダンなウェブフレームワークとの具体的な違いを洗い出すことが手っ取り早いのではと考えた。ウェブアプリケーションを作成するために設計されたモダンなウェブフレームワークであり、それでいて自分が業務として触れたことがあるものといえば、Next.jsしかない。 ここから先、Next.jsとAstroの差分を洗い出すという手法で、Astroのコンテンツ駆動について考えていきたい。
ウェブフレームワークについて整理
さっそく差分について話を始めたいところだが、そもそもウェブフレームワークについて知らなければ話が進めにくいことに気がついたため、その点の整理を簡単にしておきたい。ウェブフレームワークとは、ウェブアプリやサイトなどを作成をするプログラムの雛形や枠組みのことを言う。
JavaやPHPやJavaScriptといったプログラム言語を用いてコードをガリガリと書くことで、ウェブサイトをゼロから作ることは可能である。しかし複数人で同時にコードを書き進めるチーム開発において、コードを書く上でのルールを決める必要が出てくる。このルールの土台となってくれるのがフレームワークの大きなメリットの一つだ。
また、フレームワークには設計を進める上で便利で実績のある機能が用意されており、それらを駆使することで開発速度が上がることは勿論のこと、品質向上にも繋がってくる。 つまり現代の開発現場においては、作成したいウェブアプリやサイトの目的に応じて、適したフレームワークを選ぶことが求められる。そんなウェブフレームワークについて、目的や対象領域から大きく3つに分類でき、下記のような表にまとめられる。
| 分類 | 役割と特徴 | 代表例 |
|---|---|---|
| フロントエンド | ユーザーが実際に触れるブラウザの描画処理 | Vue.js, React |
| バックエンド | DB操作やAPI提供など裏側の処理 | Spring Framework, Express |
| フルスタック / メタフレームワーク | フロントとバックの両方を統合して構築 | Next.js, Nuxt, Astro |
表にも記載している通り、Astroは「フルスタック / メタフレームワーク」に分類される。つまりAstroを使うことでフロントエンドのみならず、バックエンドの構築も可能ということだ。このことも踏まえて、同じ分類に含まれるフレームワークとの違いを整理することでAstroフレームワークについて深掘りし、本記事においては特に「アプリ駆動」の代表格ともいえるNext.jsと「コンテンツ駆動」の代表格であるAstroという対照的なアプローチを持つ2つのフレームワークを見比べることで、より深い理解を目指したい。
差分整理
本章ではNext.jsとの違いとして、下記3つを説明していく。読み進めていくことで「コンテンツ駆動」の理解と同時に、「アプリ駆動」についても理解が進むようになっている。
JavaScriptの扱い
| Astro（コンテンツ駆動） | Next.js（アプリ駆動） |
|---|---|
| Zero JS by Default | Hydration & RSC |
Astro公式HPのコンポーネントの項目にて説明されている下記記述が、端的に「Zero JS by Default」を説明してくれている。
Astroコンポーネントについて最も重要な点は、クライアント側でレンダリングされないことです。HTMLへのレンダリングは、ビルド時またはオンデマンドで行われます。コンポーネントのフロントマター内にJavaScriptコードを含めることができますが、ユーザーのブラウザに送信される最終ページからはすべて削除されます。その結果、JavaScriptのフットプリントがデフォルトでゼロになり、サイトの表示速度が向上します。
レンダリングとは、データを人が目で見て分かる状態に描画することを指す。つまり我々がサイトを見ることができているのは、ブラウザがサーバーから受け取ったデータをレンダリングをしてくれるからこそHPを見ることができる。そんなデータの中にJavaScriptが含まれる場合、HTML/CSSだけのデータと比較すると明確にレンダリングに時間がかかる。そんな「サイトが重い」と評される一大要因を、フレームワークが自ら削ってくれているのだ。
つまりコンテンツの表示速度を可能な限り早くする、コンテンツ表示速度を優先した思想といえる。
Next.jsはそういったことをしていない。なぜなら基本的にブラウザ側でReactを動かすこと（Hydration）を前提としているからだ。React Server Components（RSC）の導入によりサーバー処理の割合は増えたものの、基本的には「Webアプリとしての動的なインタラクション」を支えるためのJavaScriptがクライアントに送信される。表示速度よりも画面としての動きを優先した結果だといえる。
コンテンツ管理機能
| Astro（コンテンツ駆動） | Next.js（アプリ駆動） |
|---|---|
| 標準機能で完備 | 開発者が組み上げる |
Astro公式HPのContent collectionsの項目にて、Astroで用意されているコンテンツを管理する標準機能が説明されている。原文をそのまま引用させていただいた。
Content collections are the best way to manage sets of content in any Astro project: blog posts, product descriptions, character profiles, recipes, or any structured content. Collections help to organize and query your documents, enable Intellisense and type checking in your editor, and provide automatic TypeScript type-safety for all of your content. （翻訳） コンテンツコレクションは、ブログ記事、商品説明、キャラクタープロフィール、レシピなど、あらゆる構造化データ群を Astro プロジェクトで管理するための最も優れる手法です。コレクションを活用することで、ドキュメントの整理や検索・取得（クエリ）が容易になり、エディタ上での補完機能（IntelliSense）や型チェックが有効化されるほか、すべてのコンテンツに対して自動的な TypeScript の型安全性（type-safety）が提供されます。
この説明からわかる通り、Astroはプロジェクト内にMarkdownやMDX（Markdown内でコンポーネントが使える拡張ファイル）を配置するだけで、標準で型安全に読み込んで整理・表示する仕組みが最初から組み込まれている。設定ファイルや外部ライブラリを追加で読み込むことなく、「記事ファイルを追加する」というコンテンツ作成の本来の作業にすぐ集中できる設計になっているのだ。
これに対し、Next.jsにはコンテンツ管理に特化した標準の仕組みは備わっていない。Next.jsで記事データ（Markdownなど）を扱いたい場合、next-mdx-remoteやcontentlayerといった外部ライブラリを開発者自身で選定し、ルーティングやパース処理を自分で一から構築する必要がある。
Webアプリ開発における自由度は非常に高い反面、「ブログやドキュメントを素早く公開したい」というケースにおいては、環境構築に相応の手間が発生することになる。コンテンツの更新速度を優先した結果の仕様といえる。
UIライブラリ
| Astro（コンテンツ駆動） | Next.js（アプリ駆動） |
|---|---|
| 自由な組み合わせ | Reactに完全特化 |
Astroは「BYOF（Bring Your Own Framework）」という概念を打ち出している。React、Vue、Svelte、SolidJSなど、異なるUIライブラリのコンポーネントを同一プロジェクト内で共存させて使える柔軟性を持っている。
例えば、「ブログ全体は静的なAstroで組みつつ、問い合わせフォームだけはVue、高度なインタラクティブパーツだけは使い慣れたReactで書く」といった柔軟な実装が可能だ。特定のフレームワークに囚われることなく、自分がすでに所有しているコード資産や慣れ親しんだライブラリを用いてコンテンツを作成できる。
対するNext.jsは、言わずもがな「Reactのためのメタフレームワーク」であるため、利用できるUIライブラリはReact一択となる。Reactのエコシステムをフル活用した高度なWebアプリを組むのには最適だが、「ちょっとした動的UIを作りたいだけ」という場合でもReactの作法に合わせる必要がある。
おわりに
ここまで「JavaScriptの扱い」「コンテンツ管理」「UIライブラリ」という3つの視点で、アプリ駆動の代表格であるNext.jsと比較してきた。 両者の根本的な違いは、「誰のために、何を最優先に設計されているか」という設計思想（メンタルモデル）の違いに集約される。
- アプリ駆動（Next.jsなど）： ブラウザ上での複雑な状態変化やインタラクティブな体験を最大化するため、JavaScriptとReactのエコシステムをベースに構築する。
- コンテンツ駆動（Astro）： 読者にコンテンツを1秒でも早く届けるため、不要なJSを徹底的に排除し、記事の書きやすさやUI選択の自由度を最優先に構築する。
「Webサイトにおける主役は、豪華なJavaScriptアニメーションや複雑な状態管理ロジックではなく、そこにあるコンテンツそのものである」
これこそが、Astroが掲げる「コンテンツ駆動」の本質であり、Webアプリではなく「文章や情報を届けるWebサイト」を作りたい私たちが、Astroを選ぶべき最大の理由なのだと実感した。また、Astroの根幹ともいえる「アイランドアーキテクチャ」については言及できなかった。言及するとすれば、 JavaScriptの扱いの文脈になるかと思うが、それについては別途記事を作成したい。
