Astroでサイトを作るとき、「コンテンツ管理をどうするか」は避けて通れない設計判断です。しかしこの判断は技術的な優劣では決まりません。
この記事では、チーム構成・コスト・リアルタイム性の3軸からアーキテクチャを選定する方法を整理します。
この記事の概要
作成日 | 2026年4月6日 |
|---|---|
主題 | Content Collectionsの仕組みを理解したうえでの構成選定 |
判断軸 | チーム構成 / コスト / リアルタイム性 |
整理したパターン | 5つ |
結論：3つの問いで決まる
編集者にエンジニア以外がいるか？
├─ No → Astroのみ（MDファイル＋Git）
└─ Yes
↓
即時反映が必要か？
├─ Yes → ライブコレクション＋SSR
│ （インフラコスト増を許容）
└─ No（数分のタイムラグを許容）
↓
コストを抑えたいか？
├─ Yes → ヘッドレスCMS＋Webhook＋Astro静的ビルド ← 現実解
└─ UX重視 → 有料ヘッドレスCMS＋Astro多くのケースは2つのパターンに落ち着きます。迷ったらシンプルな方を選び、必要になった時点でスケールアップするほうが失敗しにくくなります。
Content Collections の要点
Astroが提供する、コンテンツファイルを型安全に管理・取得するための仕組みです。
- Zodによるスキーマ定義で、フロントマターの型チェック・バリデーションが効く
getCollection()/getEntry()などの専用APIで取得する- ローカルファイルだけでなく、外部CMS・APIからのデータも同じAPIで扱える
最後の点が重要です。ここが単なる「Markdownブログ機能」との違いで、外部データソースも統一的に扱えるためCMS連携の構成選定に直結します。
ビルド時コレクションとライブコレクション
ビルド時コレクション | ライブコレクション | |
|---|---|---|
データ取得タイミング | ビルド時 | リクエスト時 |
設定ファイル |
|
|
主なAPI |
|
|
パフォーマンス | 高い（静的HTML） | リクエストごとに取得 |
即時反映 | 不可（ビルドが必要） | 可能 |
MDX・画像最適化 | 対応 | 非対応 |
向いているケース | ブログ・ドキュメント・LP | 在庫・株価・リアルタイムデータ |
基本方針：ビルド時コレクションを優先し、リアルタイム性が必要な場合のみライブコレクションを使う。
大半のWebサイトはビルド時で十分です。ライブコレクションはパフォーマンスとインフラコストのトレードオフを伴うため、本当に必要なケースに限定します。
見落としやすいのがMDXと画像最適化が非対応という点です。リアルタイム性と引き換えに失うものがあります。
5つの構成パターン
パターンA：エンジニアのみのチーム
MDファイル（Git管理） → Astro → 静的HTML → VPS公開- CMSは不要、Astroだけで完結
- 記事はMarkdownで書いてGitにコミットするだけ
- コストが最も低い
- 非エンジニアには不向き
個人ブログや技術ドキュメントサイトなら、まずこれを検討します。
パターンB：非エンジニアの編集者がいる（推奨）
CMS（管理画面専用・外部非公開）
↓ 公開ボタン → Webhook発火
CIでAstroビルド実行
↓ CMSのREST APIから記事取得
デプロイ → 一般ユーザが閲覧- 編集者は管理画面だけ触ればよい
- ライセンスコストなし（サーバ代のみ）
- 公開から反映まで数分のタイムラグあり（運用ルールとして許容する）
- 最もバランスが良い現実解
パターンC：GitベースのGUI
編集者がブラウザ上の専用GUIで記事作成
↓ 実態はGitへのコミット
Push → 自動ビルドトリガー → デプロイ追加のCMSサーバが不要でコストが安い一方、Gitホスティングのアカウント管理が必要になります。
パターンD：有料ヘッドレスCMS
- 専用の編集GUIが洗練されており使いやすい
- エントリ数・APIコール数で課金されるためコストが膨らみやすい
- 小〜中規模では過剰投資になりがち
パターンE：ライブコレクション × SSR
即時反映が必要な場合の選択肢です。サーバを常時稼働させる必要があり、インフラ管理コストが増えます。在庫・価格など頻繁に変わるデータ向けです。
推奨構成の役割分担
パターンBが現実解とされる理由を、役割分担で見ると明確になります。
CMS側（管理画面専用） | Astro側（公開サイト） | |
|---|---|---|
役割 | 記事データの置き場所 | 表示・デザインすべて |
担当 | 記事作成・編集／カテゴリ・タグ管理／画像アップロード | 静的ページ／記事ページ／統一されたデザイン・UX |
CMSは「裏方のデータ管理ツール」、Astroは「それを使って自由に表現するフロントエンド」という分離です。
この分離により、CMSのテーマやプラグインに縛られず、Astro側で完全にデザインをコントロールできます。CMSはあくまで「編集者が使い慣れた管理画面」として活用します。
誤解しやすい：公開ボタンの挙動
ヘッドレス構成でよくある誤解です。
- 公開ボタンを押すと、CMSとしての公開とWebhook発火が同時に起きる
- 「どちらか一方」を選ぶ操作は標準機能にはない
- CMSのフロントエンドURLを外部公開しないことで、実質的に「Astroサイトだけが見える」状態を作る
外部に見せない方法は2つあります。
- Basic認証をかける
- プライベートネットワークに閉じて、AstroからのAPIアクセスのみ許可する
なおWebhookの発火にはプラグインが必要で、「記事ステータスがpublishになったら指定URLへPOSTする」という設定を入れます。
画像の扱いは初期に決める
後回しにしがちですが、サイト規模が大きくなると確実にボトルネックになります。
規模 | 方針 |
|---|---|
小規模 | CMSの画像URLを直接参照しても問題ない |
本格運用 | 外部ストレージに逃がすプラグインを使う |
パフォーマンス重視 | ビルド時に画像をダウンロードしてAstro側で最適化する |
ヘッドレス構成では、記事内の画像がCMSサーバに置かれたままになります。初期設計の段階で方針を決めておくのが望ましい部分です。
よくある質問
どの構成を選べばよいですか？
3つの問いで決まります。編集者にエンジニア以外がいるか、即時反映が必要か、コストを抑えたいか。多くのケースは「Astroのみ」か「ヘッドレスCMS + Webhook + 静的ビルド」に落ち着きます。
ライブコレクションを使うべきですか？
リアルタイム性が本当に必要な場合に限定してください。パフォーマンスとインフラコストのトレードオフに加え、MDXと画像最適化が使えなくなります。
ヘッドレス構成でCMSを外部に見せたくないのですが
Basic認証をかけるか、プライベートネットワークに閉じてAstroからのAPIアクセスのみ許可します。公開ボタンはCMS公開とWebhook発火が同時に起きるため、URLを見せない設計で対応します。
画像はどう扱いますか？
規模によります。小規模ならCMSのURLを直接参照、本格運用なら外部ストレージ、パフォーマンス重視ならビルド時にダウンロードして最適化します。初期に方針を決めておくべき部分です。
まとめ
- 構成選定はチーム体制・コスト・リアルタイム性の3軸で決まる
- Content Collectionsは外部CMS・APIも同じAPIで扱える点が本質
- ビルド時コレクションを優先し、ライブは本当に必要な場合だけ——MDXと画像最適化が使えなくなる
- 現実解はヘッドレスCMS + Webhook + 静的ビルド。数分のタイムラグを運用で許容する
- 役割分担はCMSがデータの置き場所、Astroが表示のすべて
- 公開ボタンは「CMS公開」と「Webhook発火」が同時に起きる。URLを見せない設計で対応する
- 画像の方針は初期設計で決める。後から必ずボトルネックになる
アーキテクチャの選定は、技術的な優劣より「誰が更新するか」で決まります。迷ったらシンプルな方から始めて、必要になってから足すほうが失敗しにくくなります。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のWeb構築とAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。