先に要点
- Content Collections（コンテンツコレクション）は、Astro で記事などのコンテンツをまとめて、型安全に管理する仕組みです。ブログやドキュメントを作るときの土台になります。
- 設定ファイル（
src/content.config.ts）に Zod でスキーマ（各項目の型と検証ルール）を定義すると、frontmatter の書き間違いをビルド時に検出できます。 - 取り出すときは
getCollection()などを使い、CollectionEntry型で補完が効くので、タイトルや日付を安全に扱えます。 - Content Layer API により、Markdown/MDX のローカルファイルだけでなく、外部のCMSなども同じ作法で読み込めます（loader の仕組み）。
- 要は「バラバラのMarkdownを、型で守りながら扱う」ための機能。記事が増えるほど、事故を防ぐ効果が大きくなります。
記事のMarkdownが増えてきて、日付の書式ミスやタイトル抜けで表示が崩れる ── コンテンツサイトで必ず起きる悩みです。AstroのContent Collectionsは、これを型と検証で防ぐための仕組みです。
この記事では、Content Collections が何を解決するのか、スキーマと型安全の考え方、Content Layer API、取り出し方までを整理します。Astro全体像はAstroとは？を参照してください。
何を解決する仕組みか
素のMarkdownは自由に書ける反面、「この記事だけ日付が文字列」「タイトルを書き忘れた」「タグの綴りがバラバラ」といったミスが起きがちです。しかも、こうしたミスは公開してから気づくことが多く厄介です。
Content Collections は、コンテンツに“決まった形”を定義し、その形に合っているかをビルド時に検証します。ルールに反していればビルドで止まるので、壊れたページを公開する前に気づけます。
スキーマ（型と検証）を最初に決める
中心になるのが、設定ファイル src/content.config.ts に書くスキーマです。Zod というライブラリで、「タイトルは文字列」「公開日は日付」「下書きフラグは真偽値」などのルールを宣言します。
この「最初に型を固める」ひと手間が、記事が増えたときの安心につながります。Astroとは？でも触れているとおり、型運用を先に固めると後がとても楽になります。
取り出し方（getCollection）
定義したコレクションは、getCollection('blog') のように取得します。返ってくる各エントリは CollectionEntry 型を持つため、entry.data.title のようにアクセスするとエディタの補完と型チェックが効きます。存在しない項目名や型違いは、書いている最中に気づけます。
本文は、Markdown/MDXならレンダリング用の仕組みでHTMLとして描画できます。一覧ページ（記事リスト）や個別ページ（各記事）を、型で守られたデータから安全に組み立てられるのが利点です。
Content Layer API：ソースをまたいで同じ作法で
Astro 5以降の Content Layer API により、コンテンツの読み込みが「loader」で統一されました。ローカルの Markdown/MDX を読む glob ローダー、単一ファイルを読む file ローダーのほか、外部のヘッドレスCMSやAPIから読み込むローダーも同じ枠組みで扱えます。
ローカルファイル
glob ローダーで、フォルダ内の Markdown/MDX をまとめてコレクション化。ブログやドキュメントの定番。
外部CMS・API
ヘッドレスCMSなどからも、同じスキーマ・同じ取得方法で扱える。ソースが変わっても作法が揃う。
型安全は共通
どのソースでも、Zodスキーマによる検証と型付けは共通。取り出し側のコードを揃えやすい。
Live Content Collections
Astro 6以降では、実行時に取得する動的なコンテンツにも対応が広がっている（用途に応じて選ぶ）。
向いている場面
Content Collections が効くのは、同じ形のコンテンツがたくさん集まるサイトです。ブログ記事、ドキュメントのページ、製品情報、お知らせ一覧など、「決まった項目を持つデータが並ぶ」ものはすべて対象になります。
逆に、1枚だけの静的ページ（会社概要など）は、無理にコレクションにする必要はありません。数が多く、型で守る価値があるものから使うのが自然です。
Content Collections に関するよくある質問
Content Collections は必須ですか？
必須ではありません。単純なサイトなら、通常のページやMarkdownだけでも作れます。ただし記事のように同じ形のデータが増えるなら、型安全と検証の恩恵が大きいので、ブログやドキュメントでは使うのが定番です。
frontmatter のミスはどう防げるのですか？
スキーマ（Zod）で各項目の型や必須ルールを宣言しておくと、条件に合わないコンテンツがあったときにビルドがエラーで止まります。日付の書式違いやタイトル抜けなどを、公開前に検出できます。
MarkdownとMDXのどちらでも使えますか？
どちらでも使えます。Content Collections は Markdown・MDX を扱え、MDXなら本文中にコンポーネントも埋め込めます。MDXの詳細はMDXとは（Markdown＋JSX）を参照してください。
外部のCMSと組み合わせられますか？
できます。Content Layer API の loader を使えば、ヘッドレスCMSやAPIのデータも、ローカルファイルと同じ作法・同じスキーマで扱えます。編集はCMS、表示はAstro、という構成に向いています。
getCollection で取ると何がうれしいのですか？
取得したエントリに CollectionEntry 型が付くため、data.title のようなアクセスで補完と型チェックが効きます。存在しない項目や型違いを書いた時点で気づけるので、記事が増えても崩れにくくなります。
まとめ
Content Collections は、Astroで記事などのコンテンツを型安全に管理する仕組みです。src/content.config.ts に Zodでスキーマを定義して frontmatter をビルド時に検証し、getCollection() でCollectionEntry 型として安全に取り出せます。Content Layer API により、ローカルの Markdown/MDX も外部CMSも同じ作法で扱え、Astro 6以降では実行時の動的コンテンツにも対応が広がっています。「バラバラのコンテンツを型で守る」機能なので、ブログやドキュメントのように同じ形のデータが増えるサイトほど効果的です。
参考リンク
- 関連記事: Astroとは？ / アイランドアーキテクチャとは / MDXとは（Markdown＋JSX）
- 用語集: Content Collections / Astro / Markdown
- 公式: Astro Docs: Content collections