Q.Studioから移るとき、AstroとmicroCMSを連携させるにはどうしますか？

開発を始める前提として、作業端末にはNode.jsとnpmが導入されている環境が必要です。あらかじめmicroCMS側でサービスを作成し、記事を配信するためのAPIとフィールドを定義しておきます。次に、npm create astro@latestでAstroのプロジェクトを作ります。

microCMSとの通信には公式ライブラリのmicrocms-js-sdkを利用するため、プロジェクト内へパッケージを追加しましょう。プログラム内では、SDKが提供するcreateClient関数にサービスドメインとAPIキーを渡し、データ取得用のクライアントを生成します。

接続情報の設定では、プロジェクトのルート階層にある.envファイルへ環境変数を書き込みます。設定する項目は、サービスドメインとAPIキーの2つ。サービスドメインには、管理画面URLの先頭部分のみを指定します。管理画面のアドレスが「my-blog.microcms.io」なら、値は「my-blog」。APIキーも管理画面で確認できます。

Astroでは、ブラウザ側のコードに露出させない機密情報と、クライアントに渡すPUBLIC_で始まる変数が明確に区別される仕組みです。そのため、APIキーのような認証情報は接頭辞を付けずに管理し、サーバーやビルドの処理でのみimport.meta.env経由で呼び出します。

記事を取得するメソッドは、APIの形式で使い分けます。ブログのように記事が並ぶリスト形式ならgetList、1件だけを持つオブジェクト形式ならgetObjectです。公式の入門例はgetObjectで書かれています。だから、記事一覧にそのまま当てはめても動きません。

静的生成を行う詳細ページを設ける場合は、動的ルートのファイルからgetStaticPathsをエクスポートし、生成対象となる各記事のパラメータを返します。表示を確認したら、管理画面で変更・公開した内容が開発サーバーに反映されるかを見てください。最後にnpm run buildが通れば、初期導入は完了です。流れ全体はmicroCMS公式のAstro導入手順にまとまっています。

たとえばStudioで「/posts/hello-world」という記事を公開していたとしましょう。Studio側の動的ページは固定パスとSlugによって構成されており、Slugは作成時の自動発行値だけでなく、手動で変更された固有文字列も登録されています。同じモデルの中で重複はできません。「/posts」の部分はサイトごとに違うので、自分のサイトの実際のパスに合わせてください。

URLの変更を避けるための第一歩は、過去に公開した全記事のパスを正確に洗い出す作業。サイトマップ単体で全件が揃う保証はありません。Studioの記事一覧やアクセスログからもURLを拾い、漏れを防ぎましょう。

静的生成では、getStaticPaths()が返すオブジェクトのparamsによって、書き出すURLが決まります。ファイル名の角括弧で囲んだ識別子とparamsのキー名を一致させることで、Studio時代と同じURLで静的HTMLが出力されます。

ちなみに、microCMS側へデータを移す際は、Studioで使っていたSlugをそのままコンテンツIDとして割り当てる方法が分かりやすい選択肢。ただし、IDにはAPIごとに形式の決まりがあります。ID変更、PUT API、ID指定付きのCSVインポートで形式に合わない値を入れると、エラーになります（コンテンツIDの形式）。記号の多いSlugを使っていたなら、本番の取り込み前に1件だけ試してみてください。

作成したAstroとmicroCMSのプロジェクトは、どのような手順を踏めばCloudflare Pagesへ配置し、入稿と同時に自動更新される環境を整えられるでしょうか。最初に進める作業は、Astroのソースコードを管理しているGitHubリポジトリとCloudflare Pagesの連携です。Cloudflareの管理画面にあるPagesのメニューから対象リポジトリを選択すると、初期設定の入力欄が現れます。フレームワークのプリセットはAstro、ビルドコマンドはnpm run build、出力先はdistです（Cloudflare PagesのAstro向け手順）。Git連携にしておけば、新しいコミットをプッシュするたびに自動でビルドされ、公開まで進みますね。

AstroとmicroCMSの構成では、ビルドの最中に記事を取りに行きます。このため、ビルド時にもmicroCMSの接続情報を読める状態にしておく必要があります。microCMSの実装例に合わせるなら、変数名はMICROCMS_SERVICE_DOMAINとMICROCMS_API_KEYです。サービスドメインの値には.microcms.ioを付けません。

もうひとつ決めておきたいのが、記事を更新したときの流れです。コードの変更はGitのプッシュで反映されますが、microCMSで記事を公開しただけではサイトは作り直されません。Cloudflare Pagesの管理画面でデプロイフックのURLを発行したあと、microCMSの管理画面へ移動します。各APIの「API設定」から「Webhook」を開き、通知先としてCloudflare Pagesを選択して取得したURLを登録。microCMSの操作をきっかけにビルドが始まります。

通知するタイミングも設定で選べます。記事の公開時だけにビルドを走らせれば、下書きを保存するたびに作り直されることはありませんね。Gitからの更新とmicroCMSからの更新は入口が別です。記事が反映されないときは、Webhookの側から確かめてください。

Webサイトを制作する際、コンテンツ中心の配信を目指すAstroと、機能豊富なWebアプリケーションを作るNext.jsやNuxtとでは、設計思想や向いている用途が大きく異なります。Studioから移ってくるサイトの多くは、ブログやお知らせ、会社案内といった読ませるページが中心です。Astroは、ブログやマーケティング向けのサイトのような、コンテンツが主役のサイトを作るためのフレームワーク。

対照的にNext.jsは、ReactをベースにしたフルスタックのWebアプリケーション構築を得意としています。また、Vueを基盤とするNuxtも同様にフルスタックのWebアプリケーションを構築できる枠組みです。会員向けの機能や入力内容の処理など、アプリに近い動きを今後増やしていくなら、この2つが候補に入ります。

JavaScript SDKはNext.jsでもAstroでも使え、Nuxt向けにも連携用のSDKが用意されています（microCMSのSDK一覧）。つまり、どのフレームワークを採用してもコンテンツの受け渡し自体に支障はありません。

そうなると、チームがすでに触れている技術で決めるのが現実的でしょう。Reactを書ける人がいればNext.js、Vueに慣れているならNuxtです。Nuxtの公式チュートリアルも、Vueに不慣れな人には先にVueの基礎を学ぶよう勧めています。

どちらにもなじみがなく、記事をきれいに表示できれば十分というサイトもありますね。その場合は、コンテンツ中心のサイト向けに作られたAstroが、いちばん目的に近いと感じます。