自分だけのブログを作ってみよう

「エディタも優秀でintegrationも豊富だから、NotionをCMSにしたブログを作ってみよう」。まさにその一つの思いつきで、Notion CMSベースのブログを作りました。その過程がなかなか誇らしくて、最初の記事として残すほど熱心に取り組んだものです。

あとはブログ記事を書くだけだ！…と思っていました （現実は違いましたが）

ところが、LLM agentを毎日のように使うようになってから、大事に作り上げたブログへの気持ちが少しずつ冷めていきました。記事を一つ直して公開するだけでも面倒でした。すでに書いた記事を呼び出してLLM検索にRAGとしてつなぎたくても、Notion MCPに別のプロセスまで載せる必要がありました。Notionを選んだ理由だった「よく書けて、よく探せる」がまさにできないので、あれほど手をかけて作ったのに、結局放置してしまいました（泣）…。

決定打になったのは、書く習慣が変わったことでした。最近は会社の仕事でも個人の文章でも、一度ClaudeやChatGPTにレビューしてもらうことが多いのですが、最初にNotionを選ばせたあの豊富なintegrationが、今度は足かせになっていました。Markdownではなくnotion記法なので、LLMにそのまま渡すのがどうにも扱いづらかったのです。しかも一度文章を直すと、それをまたnotion記法に合わせて変換して入れ直さねばならず、なかなかの手間でした。

開発する立場からも、もどかしさは同じでした。Notion APIとreact-notion-xにがっちり縛られた構造のせいで、カスタマイズが困難でした。レンダリングをreact-notion-xが丸ごと担っているため、デザインを少し手直ししようとしても、CSSを一つ直すのすら一苦労でした… 自分で書いたマークアップではなく、ライブラリが吐き出すDOMにスタイルを無理やり合わせ込むしかなかったからです。データを取り出してビルドに載せる過程も、Notion APIがあまりに不親切で手間がかかり、さらに画像もprivateにしておくとURLが期限切れになるため、記事をすべてpublicで開放しておくしかありませんでした。そのうち、自分の記事なのに「他人のフォーマットに間借りしている」ような気分になっていきました。

このままNotionが突然料金プランやポリシーを変えたらどうしよう…？

こうしてNotionに縛られていると、肝心の自分の文章を整理・管理することがますます重荷になっていきました。実は最初に検討したとき、Markdownという選択肢もありました。当時はintegrationも足りず書くのも不便そうで見送ったのですが、LLMが賢くなるにつれてその心配はほとんど消えました。しかも開発やら経済やら、いろいろなテーマを勉強しているうちに、散らばった知識ベースを一箇所に集めて統合・分析したいという欲まで湧いてきました。

そうして気持ちが傾き、結局、知識ベース（Notion）とブログを丸ごと作り直すことに決めました。

Bye Notion, Welcome LLM Wiki!

作り直すと決めてから、まず新しい知識ベースが必ず満たすべき条件を書き出してみました。

LLM wikiって何ですか…？

LLM wikiはAndrej Karpathyが提唱した概念で、以前会社でも一度共有されていた内容でした。正直、当時は聞き流していました。ところがいざ「LLM agentに最適化された、自ら育つ知識ベース」が必要になってみると、改めて掘り起こさざるを得ない話だったのです。

そこで、さらっと流し読みしていたKarpathyのLLM Wikiをきちんと読み直してみたところ、今の自分の悩みに不思議なほどぴったりでした。核心は、原資料（raw）とコンパイルされた知識（wiki）を分離し、wikiは必ずrawを根拠にのみ書くというルールです。おかげですべての結論に出典が残り、新しい資料が入ってくると既存の記事が古びるのではなく、むしろより堅牢になっていきます。

しかもその間に、環境も追いついていました。GitHubのmarkdownがMermaidのようなものも勝手にレンダリングしてくれるようになり、LLMのmarkdownの腕前もぐっと上がって、かつてNotionで解決しようとしていたエディタ・integrationの悩みはほとんど意味を失っていました。これ以上先延ばしにする理由はありません。ブログと知識ベースを一気にLLM Wikiへ移すことに決めました。

LLM wikiで自分だけの知識ベースを作る

KarpathyのLLM wikiはあくまで大枠なので、自分の状況と目的に合わせて肉付けするのが鍵でした。出発点は同じでも、構造は自己流に組み立てました。

まずは大きな骨格から。主に開発を勉強していますが、最近は経済の勉強も合間にしているので、両方を一つ屋根の下に収められるよう、경제（経済）・개발（開発）・일상（日常）といった大テーマの下にsources/（原資料）とwiki/（整理版）を置く形で分けました。相場のように時間が経つと変わる資料は、混ざらないようにreports/へ基準日付きのスナップショットとして別に残すことにしました。

KNOWLEDGE_BASE/
├─ 경제/ · 개발/ · 일상/      # 대주제
│  └─ <세부주제>/            # 예: 개발/데이터베이스
│     ├─ sources/           # 원자료 (불변·출처)
│     ├─ wiki/              # 근거 기반 정리본 (kr/en/ja)
│     └─ reports/           # 시점 스냅샷 (시세 등, 해당 주제만)
├─ index.md                 # 발행 카탈로그
└─ README.md

骨格を立てたら、その上に実際の知識を詰め込みました。勉強していた経済資料を入れ、既存のNotion記事もすべてmarkdownに移しながら、各記事が参照した資料をsources/に出典として紐付けました。すると記事ごとに「これはどこから来た話なのか」が自然につながり始めました。

Obsidianのグラフビューで見た知識ベース — 中央のハブを中心にsource・wikiノートが蜘蛛の巣のようにつながっている。

純粋なmarkdownなので、Obsidianのようなツールでこうしてグラフまで眺められるのは思いがけないおまけでした。動画の要約一つが複数のwikiドキュメントへ枝分かれしていく様子が一目でわかります。

ブログも丸ごと作り直した

知識ベースが準備できたので、今度はブログがそれを読むように変える番でした。既存のr3gardless.devはビルド時にNotion DBからメタデータを取得し、本文はreact-notion-xでレンダリングする構造で、データソースとレンダラーがNotionにがっちり縛られていました。この依存を取り除くことが作業の核心でした。

真っ先にNotion APIへの依存をビルドパイプラインから丸ごと取り外しました。 代わりに知識リポジトリのKNOWLEDGE_BASEを取り込み、publish: trueの記事と必要なassetだけをcontent/posts/へ選んでコピーし、ブログはその成果物だけを読むようにしました。非公開ノートやraw sourceは、そもそも成果物に紛れ込めないようにしたのです。

レンダラーはreact-notion-xを捨てて、remark/rehypeパイプラインで新しく組みました。GFMのテーブル・チェックリスト・打ち消し線・脚注はもちろん、コードブロック・KaTeX・Mermaid・GitHub alertまでサポートし、Mermaidは静的exportでも安全なようにクライアントコンポーネントで処理しました。

Before — Notion APIからビルド

After — ローカルMarkdownからビルド

意外にも一番神経を使ったのはリンクでした。本文中のウィキリンクを、公開済みの記事なら/blog/<slug>へ、未公開のsourceでもsource_urlがあれば元のURLへ変換し、どちらでもなければ単なるテキストとして落とすようにしました。参考文献も、同じURLが重複カードとして表示されないように整理しました。

最後は崩れた見た目を蘇らせる作業でした。Notionレンダラーを取り外した途端、タイポグラフィ・余白・引用・コードのスタイルが軒並み壊れたので、markdown.cssを新しく書きながら、Pretendardの本文と既存のトーン、ライト・ダークモードまで改めて整えました。カテゴリ・タグをクリックすると検索フィルターに飛ぶ動作も復活させました。

さらに以前よりずっと堅牢なCIも新しく敷きました。 型チェック・lint・テストからコンテンツビルド・Nextビルド、そして実際のout/のHTMLに必要なマーカーが埋め込まれているかを見るsmokeテストまで一度に検証し、PRごとに自動で回るようにしました。大きなマイグレーションは別ブランチで進め、細かなフォローアップ作業もmain基準で分割し、それぞれCIを通してからマージしました。

こうして知識ベースとブログが一本の流れでつながりました。記事が書かれて公開されるまで、私が組んだ全体のフローを一枚にまとめると、こうなります。

何が良くなったのか

まず、記事を書いて公開するのが確実に楽になり、フォーマットもばらつかず一貫して保たれます。何より、ClaudeやCodexに「このテーマ、知識ベースに何かある？」とすぐ聞けるようになったのが一番大きいです。Notionに縛られていた依存も消え、ポリシーが変わるかどうかで気を揉むこともなくなりました。

しかもMarkdownベースの構造は、多言語（i18n）展開でこそ真価を発揮しました。実はこれは、LLMがあってこそ可能になったことです。

以前のNotion構造で多言語をやろうとしたら、どうだったでしょうか。言語ごとにページを別に立て、ブロックを一つひとつコピー・翻訳したうえで、原文が変わるたびにどこが違うのかを目で見比べながら三つのページを手で揃えなければならなかったはずです。考えるだけでぞっとします。

一方、今は韓国語の原文一つを直せば、LLM agentがコード・表・ウィキリンクといった構造はそのままに、英語・日本語のドキュメントを自ら再生成してくれます。Git diffで変わった部分だけを拾って再翻訳するので、同期も正確です。今読んでいるこの記事も、そうやって韓国語の原文を基準に英語・日本語の翻訳版を一緒に管理しています。

結局、NotionとLLM Wikiがどう分かれるのかを一目で整理すると、こうなります。

残った思い

苦労して組み込んだNotion連携を自分の手で再び剥がすのは、正直簡単な決断ではありませんでした。それでも、これほどLLM agentと共に生きる時代なら、いつか一度は通らなければならない道だったと思います。

まだ資料が多くないため、LLM検索の限界を大きく感じてはいません。ただ、量が膨大になればRAGのような別途のインフラが必要になり得ることは、常に念頭に置いています。それでも確かなことが一つあります。今は資料が積み重なるほど散らかるのではなく、積み重なるほどwikiがより堅牢になる方向へ動くようになった、ということです。

今度こそ本当にブログ開発をやり遂げたのか…？

参考文献

• Karpathy — LLM wiki (gist)gist.github.com
• Notion CMS ブログを自作する — 企画からデプロイまで4ヶ月の記録r3gardless.dev