Q.Studioからの移管先として名前が挙がるAstroとは、どんなフレームワークですか？

Studioから離れたいけれど、WordPressのようにプラグインやサーバーの手入れまで抱えるのは避けたい。そう考えたときに候補に上がりやすいのがAstroです。Astroは、ブログや会社紹介、マーケティングサイトのように、読ませる内容が中心のサイトを作るためのフレームワークとして設計されています。Studioで作ったコーポレートサイトや採用ページは、この使い方によく重なりますね。

HTMLはサーバー側で組み立て、ブラウザで動くJavaScriptは必要な部分だけに絞ります。メニューの開閉やスライダーなど、動きが要る所にだけスクリプトを足すので、ページ全体が重くなりにくいでしょう。

もうひとつの理由は、コンテンツの管理方法を自分たちで選べる点です。AstroはMarkdownファイルの整理や内容の検証を行う機能を備えており、記事データを手元のファイルとして管理する運用が組み立てられます。

とはいえ、Studioはデザインやページ情報、ソースコード、Studio CMSのデータを書き出す機能を提供していません。フォーム回答のCSV出力は用意されているものの、ページの外観や記事本文は移行先で改めて組み立て直す作業になります。そうであれば、次は自分で仕組みを選べる形にしたい、という理由でAstroが残ります。AstroはMITライセンスのオープンソースで（Astroの公式リポジトリ）、公開先も複数のサービスから選べます。

ビルド時にすべてのHTMLを作成しておくのが静的出力で、利用者がアクセスした瞬間にサーバーでページを組み立てるのがSSR（サーバーサイドレンダリング）です。Astroの既定であるoutput: 'static'では、ビルドの時点で全ページのHTMLを作っておき、訪問者にはできあがったファイルを返します。一方、output: 'server'にすると各ページの初期値がSSRに切り替わります。

設定をどちらか一方に固定する必要はありません。静的出力の構成を選んだ場合でも、配信先の実行環境に合わせたアダプターを導入し、対象のページファイル内でexport const prerender = falseを宣言すれば、特定のページだけをSSRで動かせます。逆に全体をserver設定にした場合でも、prerender = trueを指定したページは事前生成が可能です。

また、純粋な静的サイトであれば生成済みのファイルをそのまま静的サーバーに配置するだけで済みますが、SSRを動かすにはCloudflare WorkersやNetlify Functionsといったサーバー処理の実行環境と連携するアダプターが欠かせません。

SSRを利用すると、ログインした利用者ごとの画面切り替えや、刻々と変わる最新情報の表示に対応でき、コンテンツ更新のたびにサイト全体を再ビルドする手間を省けます。ただし、外部データの取得待ちが発生するとページの描画が止まる場面もあるため、表示の軽快さや更新の速さは配信環境のキャッシュ設定にも左右されますね。

Astroは、大半のページで要求時の生成が必要だとわかるまではstaticモードから始めるよう勧めています。

Studioからの移行を検討するとき、AstroとNext.jsのどちらを選ぶべきでしょうか。どちらを選ぶかは、どんなサイトを作るかで決まります。Astroはブログ、マーケティングサイト、ランディングページ、ドキュメントなど、読み物に重きを置いたWebサイトを素早く届ける目的で作られました。初期状態ではブラウザー側へJavaScriptを送信しない設計を採用しており、ボタンの開閉や検索窓といった操作が必要な部品にだけ、部分的にスクリプトを読み込ませる仕組みになっています。JavaScriptが使えないという意味ではありません。

Next.jsはReactを前提にしたフレームワークです。App Routerでは、ページとレイアウトは既定でServer Componentsとしてサーバー側で描画され、クリックや入力に反応させたい部分にClient Componentsを使います。全画面をブラウザだけで描く仕組みではなく、サーバー側の描画とブラウザ側の操作を組み合わせる作りです。

複数の画面部品で複雑に状態を共有する会員制の管理画面や、リアルタイムの共同編集機能、細かい権限チェックが絡むWebサービスを開発するなら、Next.jsのような仕組みが力を発揮するでしょう。会員ページが1つあるだけでNext.jsが必須になるわけではありません。画面の中でどんな操作が必要で、部品同士がどれだけ状態を共有するのかを見て決めます。

なお、ホスティング基盤として知られるVercelはNext.jsの開発元ですが、Astroのホスティングにも対応しています。配信サーバーの選択肢だけでフレームワークを決めるのではなく、サイトにどのような操作機能を持たせたいかを見極めて選ぶのが自然です。

たとえばStudioで/aboutとして公開していたページを、移行後に/about/で返すと、検索エンジンからは別のURLに見えます。旧URLは、Studioの/sitemap.xmlで一覧を確かめられます。サイトマップの生成をオンにして公開している場合に有効で、モーダルとnoindexを設定したページは含まれません（Studioのサイトマップの案内）。

Astroでは、設定ファイルのtrailingSlashという項目で末尾スラッシュの扱いを指定できます。公式の仕様では初期値が'ignore'となっており、スラッシュの有無に関係なく一致します。明示的に末尾スラッシュを揃えたいときは、常に付ける'always'か、常に省く'never'を指定。この設定は開発環境やオンデマンド描画のページで機能し、本番のオンデマンド描画では設定と合わないURLへのアクセスが正規の形へ転送されます。

事前生成したページの末尾スラッシュは、公開先のサービスが処理します。たとえばCloudflare Pagesでは、出力ファイルが/contact.htmlなら「/contact」へ転送され、/about/index.htmlという配置なら「/about/」へ転送される仕様です（Cloudflare Pagesの配信の仕様）。Astroの設定どおりにならない場合がある、ということですね。

そこで、build.formatは既定が'directory'でページごとにindex.htmlを作り、'file'はページ名.htmlを作ります。設定リファレンスでは、directoryならalways、fileならneverの組み合わせが開発時のずれを防ぐとされています。旧URLに末尾スラッシュがなければfileとneverです。

canonicalとサイトマップにも、同じ形のURLを書きます。公開後に両方の形でアクセスし、どちらへ転送されるかまで確かめてください。

マウス操作で直感的に余白や配置を決めるStudioの画面編集に対し、AstroとTailwind CSSの組み合わせでは、再利用しやすいコードとして画面の枠組みを組み立てていきます。StudioはサイトのHTMLを外部に書き出せないため、公開中のページを横に開いて、見比べながら組み直す作業になります。

最初に作るのは、全ページで使う部品です。共通のレイアウトファイルでヘッダー、ナビゲーション、フッターといった共通要素をまとめ、各ページ独自の内容を流し込むスロット（slot）を定義。ページごとに同じHTMLを書く必要がなくなり、コードの見通しが良くなりますね。

次に、Tailwind CSS v4では、スタイルシート内の@themeディレクティブを使って、ブランドカラー、フォントサイズ、余白のルールを変数として定義できます。Studioで使っていたブランドカラーや見出しのサイズを先にここへ書き写しておけば、ページごとに同じ数値を打ち直さずに済みます。v3の設定ファイルを使う書き方とは手順が違うので、参考記事のバージョンには注意してください。

Studio CMSで作っていた記事ページは、動的ルートで置き換えます。microCMSとAstroの実装例では、記事詳細のページでgetStaticPathsを使い、記事IDをparams、記事データをpropsとして返しています。ビルドのたびに、記事の数だけ詳細ページが生成される形です。