Obsidian AIを捨て、2150件を自動化

Obsidian AIでは、私のナレッジ管理は救われませんでした。

2026年の初めごろ、Obsidianと類似のAIプラグインで「全部のメモを横断検索できる未来」に本気で期待していました。半年後、Obsidianのフォルダは下書きで埋まり、検索で引っかかるのは3割もありませんでした。原因は私の継続力でした。

見切りをつけて、自分で作ることにしました。SQLiteとPythonとCLIだけの、地味なナレッジDBです。名前は context-forge。書籍『実践Claude Code』の第13章で設計を公開しています。

2026年2月に本を書いた時点では「300件超」と書きました。9ヶ月後の今日、SELECT COUNT(*) FROM files を叩いたら 2,150件 まで膨らんでいました。この間に私が手動で登録したのは、たぶん50件もありません。

Obsidian AIで溜まらなかった4つの理由

Obsidian自体に欠陥があったわけではありません。合う人は普通に合います。私の作業習慣では、次の4つで詰まりました。

症状	中身
手動登録が続かない	ブックマークしても、あとで読み返さない
検索が弱い	「あのへんの話」がキーワードでは出てこない
AIから参照できない	NotionやObsidianの中身を、Claude Codeに毎回手で渡すのが面倒
信頼性を区別できない	1万いいねの投稿も、個人の感想も、同じ重みで並ぶ

4番目が私にはとくに刺さりました。Xで流れてきた「12個のプロンプトでGoldman Sachs級の金融モデル」みたいな投稿と、Anthropic公式ブログを同じ棚に並べてしまうと、あとで記事を書くときに判断を間違えます。

context-forgeの4戦略

context-forgeは、コンテキストエンジニアリングの4戦略 (Write / Select / Compress / Isolate) をそのまま個人運用に落とした設計になっています。

戦略	実装
Write	SQLiteで永続化 (忘れない)
Select	カテゴリ・キーワード検索 (ノイズを減らす)
Compress	要約ファイル (トークンを節約する)
Isolate	ディレクトリ分離 + `.memory/` (混線を防ぐ)

細かい実装は書籍の第13章で書きました。この記事の要点は、登録の主体を人間からClaude Codeに渡した 設計変更のほうです。

「登録する側」を人間からAIに渡しました

Obsidian時代、私が止まっていたのはここでした。

X(Twitter)で面白いポストを見ます。「あとで整理する」と思います。整理しません。3日後には何を見たのか忘れています。この連鎖が、半年で下書きフォルダを下書きの墓場に変えます。

context-forgeに切り替えてからは、URLをClaude Codeに渡すだけになりました。

「このURLの内容をcontext-forgeに登録して」
→ https://x.com/someone/status/123456789

あとは全部Claude Codeが回します。

URLの内容をフェッチ
要約を生成
信頼性を1-10で判定 (書籍執筆時の5段階から現在は細分化)
カテゴリを自動で分類
MDファイルを docs/knowledge/ に生成
SQLiteに登録
Gitにコミット

7工程のうち、私が意志を使うのは1だけです。あとは待っているだけでいい。だから続きました。

300件が2,150件になった速度

書籍を書いたのが2026-02、現時点が2026-11。約9ヶ月で300件から2,150件なので、月あたり200件強のペースで増えています。手動時代のObsidianでは、月20件もいきませんでした。

内訳を軽く見ると、こうなっていました。

source_type	件数
web	1,421
x_post	200
article	114
その他	415

Web一次ソースが中心で、Xは副次。いちばん信頼性スコアの高いレーン (75-95点の高精度レーン) には41件しか入っておらず、残りは中程度と低程度に分かれます。当然、全部が参照に値する情報ではありません。むしろ 「ゴミも含めて、ゴミ判定つきで溜めておく」 のが大事です。

2,150件がどこで効いているか

溜めただけでは意味がありません。使えるようになってはじめて価値になります。

いちばん効いたのは ブログ記事の下書き段階 でした。たとえば「Claude Codeのコスト構造について書くか」と思いついた瞬間、manager.py list --category "Claude Code" を叩くと、信頼度スコアつきで関連ナレッジが並びます。信頼度の高いものだけ引用元に使い、低いものは「そういう主張もあるが未検証」と注記する。

この判断を手でやっていた時代は、2時間かかっていました。いまは5分です。

次に効いたのは、「あのへんの話」が引けるようになったこと。Obsidianでは検索しても出なかった過去の投稿が、context-forgeではカテゴリとタグで引っかかります。「AIエージェントの収益化、だれかが書いてたよな」と思ったら、「AI」カテゴリから関連する候補が引っかかります。あとは要約を読んで、必要なら元URLに飛ぶ。

関連記事として ChatGPT Codex vs Claude Code: 3.4x Cost Gap のコスト比較もナレッジ化してあるので、「2つのAIエージェントを使い分けるべきか」の意思決定が3分で済むようになりました。

最小構成で始めるなら

context-forgeをそのまま真似する必要はありません。むしろ最初は作りすぎないほうがいいです。

my-knowledge/
├── CLAUDE.md       # 「このフォルダはナレッジDBです」と書く
├── knowledge/      # MDファイルを放り込む
└── README.md       # カテゴリ一覧

SQLiteすら要りません。フォルダにMDファイルを溜めるだけで、Claude Codeは find と grep で読めます。私も最初はこの形でした。10件、20件と溜まってきて「あ、これ前に調べたな」が引き出せたタイミングで、SQLiteへの移行を考えればいいです。

大事なのは 始めること で、始めた直後は、むしろ道具が貧弱なほうが「もっと欲しい」という動機が残ります。最初から立派なシステムを立ち上げると、たいてい更新が止まる。これはObsidianで私がやったミスそのものです。

まとめ

時期	件数	登録の主体
Obsidian AI時代 (〜2025末)	~50件	人間 (ken) — 続かない
context-forge 初期 (2026-02)	300件超	Claude Code — 書籍化
context-forge 現在 (2026-11)	2,150件	Claude Code — 月+200件ペース

Obsidianで溜まらなかったのは、Obsidianのせいではありません。「人間が登録する前提のツール」を、継続力の弱い人間が使っていたからです。Claude Codeを登録する側に置いたら、ツールの好みに関係なく溜まるようになりました。

もし同じように「ブックマークが墓場になっている」自覚があるなら、設計を変えるべきなのは、ツールよりも登録の主体のほうかもしれません。

より深く学ぶ

Claude Codeを使い込むための設計思想とCLAUDE.md実践パターン、context-forgeの全体設計 (本記事は要約のみ) は、実践Claude Code にまとめました。