なぜ Notion を CMS にすると面倒くさいのか：Astro Content Layer の仕組みから考える

なぜこの記事？

「ブログを Astro で作るなら、CMS は Notion にしたほうが便利では？」 モバイルから書けるし、UI も直感的で、Notion AI まで使える。複数人で書きたい時にも便利そう。

…と思った。実は私もそう思った瞬間があった。

しかし Astro Content Layer の仕組みを理解した瞬間、その選択が**「便利に見えて実は技術負債を増やす」**典型例だと気付いた。本記事はその技術的根拠を整理する。

Astro Content Layer は何をやっているのか

Astro v5 で導入された Content Layer は、ブログ運用の心臓部だ。

ポイントは 「ビルド時に確定的に変換される」 こと。

• 入力（Markdown）と出力（HTML）が 1:1 対応
• 変換は テスト可能・再現可能
• frontmatter のスキーマエラーは 公開前にビルド失敗で検知

つまり、Astro は 「Markdown を投げ込めば、最適化された HTML が出てくる箱」 として完成している。

Notion を挟むと何が壊れるか

Notion を CMS にする場合、上記パイプラインの入口に変換ステップを挟むことになる。

1
Notion DB
2
   ↓ ① Notion API 取得（JSON ブロック構造）
3
Notion 独自のブロック構造
4
   ↓ ② notion-to-md 等で MD 変換 ← ⚠️ ここで損失
5
不完全な Markdown
6
   ↓ ③ Astro Content Layer に投入
7
HTML 出力

ステップ②で必ず情報損失または独自実装が発生する。理由はシンプルで、Notion のブロック構造は Markdown より表現力が広いから。

Markdown ネイティブパイプラインの本質的優位性

対照的に、Astro + Obsidian の組合せはこうなる：

全工程 Markdown で繋がっている。変換ロスゼロ、API 依存ゼロ、型安全性フル活用。

そしてこれがさらに強いのは、情報資産の上流まで Markdown で揃っている場合だ。

1
LLM Wiki（Obsidian/Markdown）
2
  └─ クライアント案件知見・concept ドキュメント・synthesis
3
   ↓ ※ 全部 Markdown
4
astro-blog スキル（情報資産 → 公開記事の変換層）
5
   ↓ ※ Markdown → Markdown
6
Fuwari（Astro Content Collections）
7
   ↓ ※ Markdown → HTML
8
公開

この 「同一フォーマットで貫通するパイプライン」 が、保守性と拡張性を最大化する。

知見の蓄積・記事の執筆・公開、すべてが同じ Markdown という形式で扱えるため、自動投稿パイプラインも自然に組める。

まとめ：CMS 選定の判断基準

Astro でブログを作るなら、次の問いを優先するべきだ。

1. 情報資産（知見・素材）はどの形式で蓄積されているか？
2. Astro Content Layer の型安全性をフル活用したいか？
3. 公開停止リスクをどう許容するか？
4. 保守コスト（バグ修正・API 追従・スキーマ変更）を払い続けられるか？

これらを冷静に問うと、多くの個人/小規模ブログでは Markdown ネイティブ運用が答え になる。Notion の便利さは魅力だが、Astro と組み合わせる時には 変換ロスのコストを直視すべきだ。

「便利そう」の裏で増える技術負債を可視化することが、CMS 選定の本質である。

関連リンク

• Astro Content Collections（公式ガイド）
• Astro Content Layer API
• notion-to-md（OSS の Notion → Markdown 変換）
• Fuwari テーマ（本ブログで採用）