「Astroで作ろう」と決めてから構成を考えると、後で「静的生成なのに動的機能が欲しい」「記事が増えて管理が辛い」にはまります。先に用途を決め、その用途に合う静的構成を選びます。
先に結論：決める順は「目的 → 更新 → 動き → 配信 → 運用」
順番を間違えると、初期HTML、配信の単純さ、復旧しやすさという静的構成の強みを使わないまま、ページ全体をクライアント実行へ寄せてしまいます。
- 目的: 記事か、診断か、計算か、ポートフォリオか、複合か
- 更新頻度: ほぼ固定か、月数回か、毎日か
- インタラクション密度: 最小・標準・高い・実験的
- 配信: FTP静的・Cloudflare Pages・Vercel・GitHub Pages
- 運用人数: 1人か小規模チームか
この5つを決めると、Astro のどの機能（Content Collections / React Islands / SSR）を使うかが自ずと決まります。
目的別の推奨構成（BUILD ORBITからの実例）
| 目的 | 推奨構成 | 避ける構成 | 実例 |
|---|---|---|---|
| 記事・ナレッジ | Content Collections + 静的生成 | 全ページ SPA | 複数の記事サイト（30件中多数） |
| 診断・比較 | 静的HTML + 小さな Island（状態のみ） | 結果をサーバーで生成 | Local AI Compass |
| 計算ツール | 静的 + クライアント計算 Island | サーバー常時稼働 | 配信設計ラボ |
| ポートフォリオ | 静的生成 + 軽い遷移 | 重い3D/WebGL | 個人サイト群 |
| 複合 | 静的基盤 + 必要分だけ Island | 一律 React 化 | 複数サイト運営 |
Astro公式は、content-drivenなサイトをserver-firstで構成し、JavaScriptを必要なコンポーネントだけへ明示的に追加する方針を示しています（2026年9月1日確認）。
構成の採用理由を証拠へ渡す
構成を決めたら、フレームワーク名だけでなく「何を静的に残し、何を動かし、どこで公開を止めるか」を一行で記録します。あとから別のProjectと比較できる単位を先に揃えると、技術選定が好みの表明で終わりません。
| 記録する判断 | 確認するもの |
|---|---|
| 目的と更新頻度 | 記事・診断・計算・ポートフォリオのどれか、誰がいつ更新するか |
| HTMLに残す情報 | 見出し、本文、表、主要リンク、JavaScriptなしでも必要な結論 |
| Islandへ切り出す状態 | 検索、絞り込み、診断、URL状態など、操作で変化する範囲だけ |
| 配信と復旧 | 直接URL、404、sitemap、dist/とupload/の一致、戻す手順 |
| 採用しない条件 | 認証・非公開データ・決済など、静的配信では責任を持てない要件 |
この記録は、Project AtlasやAll Projectsで実例を照合し、Design Patternsで再利用できる判断へ変換します。自分の条件を当てはめるときはBuild Simulatorを使い、最後はAIサイトの公開前チェックリストで公開可否を確認します。
実例でHTMLとIslandの境界を照合する
フレームワークの機能表だけでは、どこまでを静的に残すかが決まりません。BUILD ORBITの30 Projectから、役割が異なる3例を同じ記録欄で照合します。これは利用者数や速度の比較ではなく、実装責務の比較です。
| Project | HTMLへ残すもの | 状態を持つ範囲 | 採用しない前提 |
|---|---|---|---|
| Local AI Compass | 診断の説明、開始ガイド、比較・トラブル記事 | PC条件と目的からのクライアント内診断 | PC環境を無視した一つの断定結果 |
| ToolCompass | 購入ガイド、比較表、停止条件 | 条件比較と購入前チェックの判定 | 最新在庫や口コミをサーバーで保証する構成 |
| BUILD ORBIT | Notes、Project、Pattern、品質説明 | Orbit・Simulatorなどの局所的な操作 | 全文をクライアント描画するSPA |
この表から先に決めるのは「Astroを使うか」ではなく、読者が操作しなくても受け取るべき判断材料は何かです。HTML側の結論・前提・次のリンクが定まらないままIslandを作ると、検索入口とno-JSの代替経路を同時に失います。実際の配信・同期条件は静的ホスティングでも成立するインタラクティブサイト構成へ渡します。
更新頻度が決めるもの
- ほぼ固定: ビルドを手動・CI のどちらでも可。FTP 静的配信も現実的。
- 月数回〜毎日: Content Collections で記事をデータとして扱い、build を自動化。キャッシュ戦略を決める。
更新が多いのに「毎回 FTP で手動 upload」だとヒューマンエラーが増えます。配信は更新頻度で選びます。
インタラクション密度は「動かす範囲」で決める
React Islands は「状態を持つ一部」だけをクライアント化します。密度が高いほど初期 JS が増えるため、INP（応答遅延）の予算と天秤に掛けます。
- 最小: ほぼ静的、共有ボタン程度
- 標準: フィルタ・診断・フォーム
- 高い: リアルタイム描画、複数 Island 連携
- 実験的: Canvas/SVG 多用（性能予算の検証必須）
採用後の実装境界は静的ホスティングでも成立するインタラクティブサイト構成で扱います。このNoteは「Astroを選ぶか」、リンク先は「選んだ後にHTMLと状態をどう分けるか」のownerです。
配信は「やり直しやすさ」で選ぶ
| 配信方式 | 向くケース | 注意 |
|---|---|---|
| FTP静的 | 既存サーバーへ完成ファイルを置く | upload同期・直接URL・rollback |
| マネージド静的配信 | build・preview・履歴を自動化する | provider側のbuild設定 |
| repository型配信 | 小規模な静的成果をGitから公開する | base path・公開範囲・release |
| サーバー実行 | 認証やrequestごとのデータが要る | runtime・費用・運用責任 |
BUILD ORBIT の Projectデータでは、静的配信で成立した機能が大半を占めます。SSR が本当に要るかを先に問います。
運用人数が決める「更新しやすさ」
1人なら、frontmatter の完結さ・テンプレート・自動チェックが命です。小規模チームならレビュー工程と品質ゲートを build に組み込みます。
公開前に確認すること
構成を決めたら、AIサイトの公開前チェックリスト で最終確認。特に「静的生成なのに動的機能が漏れていないか」「no-JS で本文が読めるか」を確認します。
避ける判断
「Astro が人気だから」「SPA より速いらしいから」だけでは構成を決めません。目的と更新頻度から逆算します。速さは構成の結果であり、目的ではありません。
よくある誤解
- 「静的 = 地味」：インタラクティブ表現は Island で可能
- 「Astro = ブログ専用」：診断・計算・ポートフォリオも静的で成立
- 「 Islands は何でも React で書ける」：動かす範囲を絞らないと性能が落ちる
次の行動
- 目的を1文で書く
- 更新頻度を決める
- 動かす範囲を最小に絞る
- 配信を決める
- Build Simulator で構成を試す
確認した一次情報
- Astro: Why Astro（外部サイト） — 確認 2026/9/7
- Astro: Content Collections（外部サイト） — 確認 2026/9/7
- Astro: Deploy your Astro site（外部サイト） — 確認 2026/9/7
- React: Add React to an Existing Project（外部サイト） — 確認 2026/9/7
- web.dev: Core Web Vitals（外部サイト） — 確認 2026/9/7