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

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

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

いざ作ってみると、記事は思ったほど積み上がりませんでした。勉強そのものより、いつも整理が問題でした。学んだことをきちんと残すにはダイアグラムを描く必要があるのですが、決まってここで力尽きて諦めるのが常でした…。

執筆には主にAI agentを使っていたのですが、Notionとはこの流れがどうにも噛み合いませんでした。ClaudeやChatGPTにレビューしてもらってMarkdownで仕上げるのに、公開するときはそれをまたNotion記法に合わせて変換して入れ直さなければなりませんでした。書き溜めた記事を呼び出して質問したくても、Notion MCPの設定のような別のプロセスを載せてやっと動く始末でした（覚えているはずもないNotion API KeyとDatabase IDを毎回調べ直すのはおまけ…）。

開発する立場からも、もどかしさは同じでした。Notion API（@notionhq/client）とreact-notion-xにがっちり縛られた構造のせいで、カスタマイズが困難でした。初期の開発後にNotion APIが変わり、@notionhq/clientパッケージをアップグレードするためにロジックを全面的に直したこともありましたし、レンダリングをreact-notion-xが丸ごと担っているため、デザインを少し手直ししようとしても、CSSを一つ直すのすら容易ではありませんでした… 自分で書いたマークアップではなく、ライブラリが吐き出すDOMにスタイルを無理やり合わせ込むしかなかったからです。データを取り出してビルドで使う過程も、Notion APIがあまりに不親切で手間がかかり、さらに画像もprivateにしておくとURLが期限切れになるため、記事をすべてpublicで開放しておくしかありませんでした。

こうしてNotionを使っているうちに、当初の思惑とは裏腹に、かえって書くのも難しく、開発も難しい状況になってしまいました。

しかも、ここまでNotionに依存した構造では、Notionが料金ポリシーでも変えようものなら、そのまま致命傷でした。

実は最初にブログを作るとき、Markdownという選択肢もありました。当時はintegrationも足りず書くのも不便そうで見送ったのですが、最近改めて見てみると、その心配はほとんど消えていました。しかも開発やら経済やら、いろいろなテーマを勉強しているうちに、散らばった知識ベースを一箇所に集めて統合・分析したいという欲まで湧いてきました。この機会に、いつも力尽きていた整理の工程はAI agentに任せたいとも思いました。AIで書けば同じフォーマットとトーン＆マナーが保証されるので、私は内容が正しいかだけレビューすればいいのです。

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

Bye Notion, Welcome LLM Wiki!

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

LLM wikiって何ですか？

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

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

このように、記事の作成・修正はもちろん、いちばん頭を悩ませていたメンテナンス（古い情報の更新）まで、人の介入を最小限にしてLLM agentに任せられるというのは、無視できないほど魅力的でした。

とはいえ、LLM agentにとって読みやすい記事なだけでは意味がなく、結局は人が読みやすくなければなりません。Markdownでもダイアグラムや数式はMermaid・KaTeXで十分に表現・レンダリングできました。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に書き溜めた記事はNotion MCPを使って移行し、各記事が参照した資料はsources/に出典として紐付けました。すると記事ごとに「これはどこから来た話なのか」が自然につながり始めました。

Obsidianのグラフビューで見た知識ベース。グレーの点はsource・wikiノート、緑の点はタグ、黄色の点は画像などの添付ファイル。同じテーマのノート同士がクラスターにまとまり、ウィキリンクとタグがクラスターの間をつなぐ。

「ObsidianはIDE、LLMはプログラマー、wikiはコードベース」という言葉のとおり、実際にObsidianを開いてみると、記事同士がどうつながっているのかがグラフビューで一目でわかり、なんだか誇らしくなりました。

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

知識ベースが準備できたので、今度はブログがそれを読むように変える番でした。既存の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でも安全なようにクライアントコンポーネントで処理しました。本文中のウィキリンクは、公開済みの記事なら/blog/<slug>へ、未公開のsourceならsource_urlへつながるようにしました。

Before — Notion APIからビルド

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

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

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

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

何が良くなったのか

まず、記事を書いて公開するのが確実に楽になりました。書式やトーン＆マナーをSKILLとして登録してあるおかげで、フォーマットがばらつかず一貫して保てます（人間より上手なのではと思うほどです）。何より、ClaudeやCodexで環境を問わず知識ベースに知識を登録し、クエリできるようになったのが一番大きいです。新しい情報を入れるときにSKILLとlintルールで書式を自動検証し、矛盾する情報がないかまでチェックしてくれるのも実にありがたい点でした。最後に、Notionに縛られていた依存も消え、ポリシーが変わるかどうかで気を揉むこともなくなりました。

今登録して使っているskillは、ざっとこんな感じです。

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

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

複数の分野を一つのリポジトリに集めたのも、地味に良かった点です。RaBitQのようなベクトル量子化の論文を読んでいると、Johnson-Lindenstrauss変換のような数学の概念が飛び出してくるのですが、以前はその都度調べては忘れるという繰り返しでした。今は数学でも物理でも、とりあえずノートに残してウィキリンクでつないでおけばいい。分野が違っても知識が互いに絡み合っていきます。

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

残った思い

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

まだ手を付けられていないものもあります。

• RAGインフラ:今は資料が多くないのでLLM検索で十分ですが、量が膨大になれば別途のインフラが必要になるかもしれません。
• 資料の蓄積:まだ骨格を立てたばかりの段階なので、知識ベースが本当の力を発揮するには、地道に埋めていく必要があります。

それでも今は資料が積み重なるほどwikiが堅牢になる方向へ動くようになりました。

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

参考文献

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