Astroとは？静的サイトに向く理由と選ぶ前に知りたい特徴

Webサイトを作る方法には、CMS、静的サイトジェネレーター、Webアプリケーション向けのフレームワークなどがあります。Astroはその中でも、ブログ、ドキュメント、ポートフォリオ、企業サイトといった、コンテンツを読んでもらうことが中心のサイトを想定したWebフレームワークです。

ただし、Astroを使えばすべてのサイトが簡単になるわけではありません。静的なページが中心か、利用者ごとに内容を変える必要があるかによって、適した構成は変わります。この記事では、機能の多さではなく、どのような用途で選びやすいかを整理します。

Astroはコンテンツ中心のWebフレームワーク

Astroでは、HTMLに近い記法の.astroファイルを使ってページや部品を作れます。公式ドキュメントでは、ブログ、マーケティングサイト、ドキュメントサイトなど、情報を届けることが中心のサイトを主な用途として挙げています。

標準ではページをビルド時にHTMLへ変換します。公開先は生成されたHTML、CSS、画像などを配信できればよく、ページを表示するたびにサーバーでHTMLを組み立てる構成を必須としません。

一方、必要に応じて公開環境に対応するサーバーアダプターを追加し、対象ルートをオンデマンドレンダリングに設定すれば、アクセス時にページを生成する構成も選べます。個別のルートで設定する方法と、サイト全体の標準をサーバーレンダリングへ切り替える方法があります。「Astroは静的ページしか作れない」のではなく、静的生成を標準にしながら、要件に合わせて動的な処理を追加できる仕組みです。

必要な場所だけブラウザーで動かす

Webページに検索フォーム、メニュー、料金計算などの操作がある場合、ブラウザー上でJavaScriptを動かすことがあります。一般的なサイトでは、ページ全体を一つのアプリケーションとして動かす方法もあります。

Astroは、基本となる内容をHTMLとして出力し、操作が必要な部品だけをブラウザーで動かす「アイランド」という考え方を採用しています。React、Vue、Svelteなどは、対応するインテグレーションを追加することで、UIコンポーネントを必要な部分へ組み込めます。

ただし、JavaScriptが少なくなるかどうかは実装次第です。多くの部品をクライアント側で動かせば、配信するJavaScriptも増えます。Astroを選ぶだけで速度が保証されるのではなく、どの機能をブラウザーで動かすかを設計する必要があります。

Markdownの記事を構造化して管理できる

記事中心のサイトでは、本文をMarkdownファイルとして管理できます。見出しや文章はMarkdownに書き、タイトル、公開日、カテゴリなどはfrontmatterに分ける構成です。

AstroのContent Collectionsを使うと、同じ種類のコンテンツをまとめて取得し、frontmatterの項目をスキーマで検証できます。たとえば、公開日の書き忘れや、定義されていないカテゴリの指定をビルド前に見つけやすくなります。

Markdownは記事管理の選択肢の一つであり、必須ではありません。執筆者が管理画面から更新したい場合は、外部CMSやAPIからデータを取得する方法も検討できます。更新する人と更新方法から、保存先を決めることが大切です。

このサイトで採用している構成

「エンジニアの選択ノート」もAstroで静的に生成しています。現在のリポジトリでは、次の構成を採用しています。

• 記事本文をMarkdownファイルで管理する
• タイトル、説明、カテゴリ、公開日、参考情報をfrontmatterに記録する
• Content Collectionsのスキーマで必須項目やカテゴリを検証する
• ビルド時に記事ページ、一覧、カテゴリページを生成する
• 公開記事から関連記事、sitemap、RSSを生成する

この構成では、記事を追加してビルドすると関連するページもまとめて更新できます。その代わり、記事を公開または修正するたびに、再ビルドと生成物の再配置が必要です。ブラウザー上の管理画面から即時公開したい運用とは、必要な仕組みが異なります。

Astroが向いている場面

次の条件が多い場合は、Astroを候補にしやすくなります。

• 記事、製品説明、事例、ドキュメントなど、読むコンテンツが中心
• ページの大部分を同じ内容で全員へ配信する
• 更新のたびにビルドして公開する運用を組める
• 一部にだけ検索、フォーム、表示切り替えなどの操作が必要
• Markdown、CMS、APIなどからコンテンツを取得したい

ブログやポートフォリオでも、コメント、会員機能、検索などを外部サービスと組み合わせる場合があります。サイト全体を動的にする必要があるか、一部の機能だけを追加すればよいかを分けると判断しやすくなります。

慎重に選びたい場面

ログイン後の管理画面、共同編集、利用者ごとに変わる情報、リアルタイム更新などが中心なら、静的生成だけでは要件を満たせません。Astroでもアクセス時のレンダリングやAPIエンドポイントは利用できますが、サーバー実行環境、認証、データベース、キャッシュなどの設計が加わります。

画面の大部分が継続的に状態を持ち、ブラウザー上の操作で変化するアプリケーションでは、別のフレームワークを含めて比較した方がよい場合があります。Astroで実現できるかだけでなく、チームが保守しやすい構成かを確認します。

導入前に確認したいこと

フレームワークを決める前に、次の条件を書き出します。

1. 主役は読むコンテンツか、利用者の操作か
2. 内容は全員に共通か、利用者ごとに変わるか
3. 更新のたびにビルドと公開を実行できるか
4. 記事を誰が、どの画面やファイルから更新するか
5. JavaScriptが必要な機能はページのどこにあるか
6. 公開先でサーバー処理やアダプターを利用できるか

静的なページが多く、一部だけに操作を加えるサイトなら、Astroの標準構成と合わせやすいでしょう。反対に、動的な処理がサイトの中心なら、その処理を先に設計してからフレームワークを比較します。

Astroは、コンテンツ中心のサイトを静的なHTMLから始め、必要な部分に機能を追加していくための選択肢です。流行や機能数だけで決めず、サイトの主役、更新方法、公開環境に合うかを基準に選びます。