Cloudflareで公開研究ノートを育てる

Second Brain LabのMVPでは、まず公開研究ノートとして読める場所を作ることを優先しています。最初から大きな自動化を組むのではなく、AstroとMarkdownで記事を置き、Cloudflare Pagesで高速に公開する。小さく始めて、運用しながら仕組みを育てる方針です。

これは、サイト制作というよりも「学びを公開可能な形へ変える実験台」を作る作業です。Obsidianに残した学習メモが、記事になり、カテゴリに分かれ、あとで読み返せる資産になる。そのための土台を先に用意します。

静的サイトを選ぶ理由

公開研究ノートは、重い管理画面よりも、書き続けやすさと読みやすさが大切です。AstroとMarkdownの構成なら、記事はファイルとして管理できます。Gitで差分を追えるので、どの学びがいつ公開記事になったのかも残ります。

Cloudflare Pagesに置けば、表示は速く、構成もシンプルです。将来的に独自ドメイン、GitHub連携、自動デプロイへ広げやすい。さらにCloudflare WorkersやR2を使えば、OGP画像生成や素材管理なども後から追加できます。

MVPで大事なのは、完成されたシステムではありません。あとから育てられる骨格があることです。

最終的には、Obsidianから記事下書きを作り、GitHubへ反映し、Cloudflare Pagesへ自動公開する流れを目指します。

ただし、最初に自動化だけを作ると、何を自動化すべきかが曖昧になります。先に必要なのは、記事の型、カテゴリ、sourceRefsの扱い、公開前チェック、OGP画像の置き方です。

このMVPでは、記事本文と元ノートを混ぜない二層モデルにしています。記事は公開用のMarkdownとして置き、元ノートへの参照はfrontmatterのsourceRefsに残す。これにより、Obsidian VaultをそのままWebへ流すのではなく、公開できる理解だけをサイトへ出せます。

Buildでは、Second Brain Labを育てるために実際に作ったものを記録します。Astroのページ追加、Cloudflare Pagesの設定、OGP生成、記事公開前チェック、将来のWorkersやR2連携などです。

ここで残すのは、単なる設定手順だけではありません。なぜその構成にしたのか。どこで詰まったのか。次に自動化するならどこから始めるのか。そうした判断の記録が、後から似たプロジェクトを作るときの資産になります。

小さく作り、使いながら直し、学びをまた記事へ戻す。Second Brain LabのBuildは、その循環を支える作業ログです。