【AIと​“第二の​脳”を​作る​ #1】なぜ"普通の​メモアプリ"は​続かないのか──8つの​PKM挫折と​「LLM Wiki」と​いう​解

SERIES ｜ AIと"第二の脳"を作る #1

「今度こそ、知識がちゃんと積み上がるはずだ」——そう思って、私はこれまで8つのツールを試しては、静かに手放してきた。Pocket、Evernote、Notion、Obsidian……どれも評判は本物で、UIも美しい。なのに数ヶ月も経つと、決まって同じ場所に行き着く。情報が溜まっているだけで、何も生まれていない。

個人知の集約は、私にとって長らく"永遠のテーマ"だった。辿り着けない。けれど、ある一本の記事をきっかけに、その諦めが崩れた。鍵は「もっと良いメモアプリ」ではなく、「AIが編集者として常駐するWiki」という発想の転換にあった。これは、その第二の脳をAIと1から作り始めた連載の第1話だ。^[1]

01全部、​"リンク置き場"で​終わった

まず、私の墓標を正直に表に並べる。

ツール	行き着いた末路
Pocket / Read It Later	「後で読む」が、永遠に後回しのまま積まれていく
Evernote	書いたノートが、そのまま死蔵する
Raindrop	ブックマークが増えるだけ
Notion	データベースは綺麗だが、こちらが入力しないと何も生まれない
Recall	AIが要約は出すが、積み上がっていかない
Fabric	収集は速いが、思考が育たない
Obsidian（素の状態）	ノードとグラフは美しい。でも、自分で書かない限り増えない

共通点は明白だった。どれも「リンク置き場」にしかならず、「何かが生まれる場所」にはならなかった。保存は一瞬、活用はゼロ。集めることと、考えが育つことは、まったく別の問題だったのだ。

痛いのは、失ったのが各ツールの月額料金ではないことだ。「保存したから大丈夫」という安心感と引き換えに、考える機会そのものを失っていた。読んだ記事を保存した瞬間、脳は「処理済み」のラベルを貼って忘れる。それが8ツール×数年ぶん。保存という行為が、皮肉にも「考えないための儀式」になっていた。乗り換えのたびに移行ツールでデータを引っ越したが、引っ越していたのは知識ではなく、読み返されないファイルの山だった。

02RAGでもなかった​：​「再発見」と​「蓄積」は​違う

「AIに繋げばいいのでは」とも思った。いわゆるRAG——必要なときに保存物を検索して、AIに答えさせる方式だ。だが、これも本質的にはリンク置き場の高級版でしかない。

RAGがやるのは「再発見」だ。聞かれたときに、倉庫から該当箇所を引っ張ってくる。倉庫の中身そのものは、いつまでも増えも整理もされない。私が欲しかったのは検索性能ではなく、「蓄積」——読むたびに知識同士が繋がり、要約され、書き換えられて、勝手に厚くなっていく仕組みだった。倉庫番がほしいのではない。住み込みの編集者がほしかった。

誤解のないように書くと、RAG自体は優れた技術だ。社内文書の検索やサポートの自動応答には、むしろ最適だと思う。問題は個人の知的生産という用途との相性だ。個人知で価値があるのは「あのとき読んだAと、今日読んだBが、実は同じ話だった」という接続の発見であって、それは問い合わせ時の検索では起きない。倉庫に入れた瞬間に誰かが棚を整理し、関連する棚と通路を繋いでくれて、初めて起きる。その「誰か」が、いなかった。

03出会い​：Obsidianは​エディタ、​LLMは​プログラマ

転機は、Xで流れてきた一本の投稿だった。元OpenAIの著名なエンジニアが、個人ナレッジの集約に手を動かしている——その事実そのものが、「これは取り組む価値のあるテーマだ」という証明に見えた。彼が提唱していたのが「LLM Wiki」というパターンだ。^[2]

Obsidianはエディタ、LLMはプログラマ、Wikiはコードベース。

役割分担が、一瞬で腑に落ちた。従来のツールは「自分が書かないと増えない」のが致命傷だった。でもこのモデルでは、人間は集める・問う・探索するに専念し、要約・相互リンク・整理・記録はLLMが受け持つ。書く主体がAIに移る。つまり「自分で書かないと増えない」という構造的な欠陥が、設計レベルで消える。8つの失敗を抱えていたからこそ、この1記事は刺さる準備が完全にできていた。偶然ではなく、必然の邂逅だった。

04何を​作ったか​：壊れない​3層アーキテクチャ

その日のうちに、自分のWikiを立ち上げた。土台はシンプルな3層だ。

• 生ソース（raw）：クリップした記事やメモを、加工せず置く層。不変。
• Wiki本体：LLMが読んで統合・要約・相互リンクして育てる層。中身は全部ただのMarkdownファイル。
• Schema（指示書）：LLMに「このWikiはこう運用する」と教える永続ルール。

ポイントは、特別なデータベースもAPIも使わないこと。プレーンなMarkdownのフラットファイルにした理由は3つ。①LLMとの相性が最高（そのまま読ませられる）、②grepで検索できる、③フォルダごと持ち運べてGit管理も自然。そして「指示書」を1枚に固定したことで、チャット履歴に依存せず、セッションが変わっても同じルールでAIが動く。会話を閉じても、運用ルールは消えない。

Schemaには、たとえばこういうことを書いてある。「新しい情報はまず既存ページとの重複を確認してから統合する」「ページには必ず関連ページへのリンクを張る」「分類に迷ったら新ページを乱造せず既存に追記する」。人間の編集部で言う"編集方針"そのものだ。これがチャットの中ではなくファイルとして存在するから、明日のAIも、来月のAIも、同じ方針で編集してくれる。AIの記憶ではなく、ルールを永続化する——後から振り返ると、この一手が運用の安定を支えていた。

05独自拡張：​「棚卸し」と​「振り返り」

参考にしたパターンに、私は2つの操作を足した。日常の流れに噛み合わせるためだ。

• Scan（棚卸し）：スマホやPCからワンタップで何でも生ソース層に放り込んでおき、後でまとめてAIが棚卸しして、どれをWikiに統合すべきか仕分ける。
• Reflect（振り返り）：ひとつの取り組みが終わったら、そこで得た学びをAIが抽出し、再利用できる形に合成する。

「とりあえず全部rawに放り込む→あとで棚卸し」という流れが、初日から手応えがあった。inboxではなくraw——「生もの・加工前」という温度感がちょうどよかった。集めるハードルを限界まで下げ、整える仕事はAIに回す。人間の仕事を「集める・問う」に絞るための設計だ。

初日の棚卸しは、こうだった。日中に放り込んだ記事の切り抜きと走り書きのメモ、合わせて十数件。夜に「棚卸しして」と一言頼むと、AIがそれぞれを読み、「これは統合する価値あり」「これは一過性のニュースなので raw 置きのまま」と仕分けし、統合分はWikiの該当ページに織り込んでいった。自分でやれば1時間の整理が、頼んで数分。何より「整理しなきゃ」という心理的負債が消えたのが大きかった。負債が無いから、翌日もまた気軽に放り込める。続く仕組みとは、意志力ではなく、負債が溜まらない構造のことだった。

06最初の​設計判断が、​すべてを​決めた

振り返って、初日に一番効いた判断はこれだ——このWikiを、特定のAIツール専用にしなかったこと。

便利なAIコーディング環境に紐づけて作る選択肢もあった。だが私はあえて、ただのMarkdown＋汎用エディタという素朴な基盤にした。理由は単純で、私がAIと作業する時間のほとんどは、普通のチャットや別の対話環境だからだ。もしWikiを一つのツール専用にしていたら、最も知識が生まれる現場から切り離された"宝箱"になってしまう。鍵のかかった宝箱に、知識は貯まらない。

どこで話していても、同じWikiに繋がる。これがこのシステムの肝だった。

この「汎用基盤にしておく」という地味な一手が、後にあらゆる対話環境からWikiへ書き込めるようにする拡張を可能にした。——その"宝箱を解く"話は、次回（#2）に書く。

07使い続けて、​どうなったか

結論から言うと、初めて「知識が複利で増える」感覚を得た。1つ読むたびにWikiが厚くなる。しかも厚くなるのはリンクの本数ではなく、繋がりと要約だ。同じテーマを2回触れば、AIが過去のページに追記し、矛盾があれば指摘してくる。

「複利」の感覚を、もう少し具体に書く。あるテーマの記事を初めて保存したとき、AIは新しいページを1枚作った。数日後、関連する別の記事を保存すると、新ページを作らずさっきのページに追記し、両者の違いを一行で要約した。さらに後日、私が雑談のなかでそのテーマに触れたら、「以前読んだ2つの記事では、こういう論点がありました」と返ってきた。読む→繋がる→次に読むときの土台になる。単利（保存の数）ではなく複利（繋がりの厚み）で増えるとは、こういうことだった。

正直、初日に見落としもあった。「自分の声を重ねる層」を作らなかったことだ。記事を保存しても、「なぜ保存したか」「どう使いたいか」という意思が記録されない。これは後日、保存時に一言コメントを残す仕組みを足して解決した。情報収集システムを作るなら、最初から"自分の声を重ねる場所"を設計すべき——これは高い授業料で得た教訓だ。

08これは、​始まりに​すぎない

「もっと良いメモアプリを探す」のは、もうやめた。必要だったのはアプリではなく、AIを編集者として住まわせる構造だった。集める・問うは人間、育てるはAI。役割を分けた瞬間に、長年抜け出せなかったループから出られた。8回の乗り換えで探していたのは「もっと良い器」だったが、答えは器の外——器に住む編集者のほうにあった。同じ袋小路にいる人は、たぶん少なくないと思う。

このシリーズ「AIと“第二の脳”を作る」では、この第二の脳がどう育ち、どこでつまずき、どんな設計原則に行き着いたかを、実装の判断ごと開示していく。次回#2は、「切り離された宝箱を解く」——どこで対話していても同じWikiに繋がるようにした、いちばんの山場だ。

関連記事 ｜ 次回 #2【AIと“第二の脳”を作る #2】切り離された宝箱を解く──“どこで話しても同じWikiに繋がる”を作った日 →

「これ、自分用に作れたらな」と思ったツール。まず、言葉にしてみてほしい。言語化できるものは、もう自分の手でAIと作れる時代になった。この連載が、その小さな証明になればうれしい。

従来のPKM vs LLM Wiki。「集める」だけと「育つ」の違いを、一枚に。

観点	従来のPKM（リンク置き場）	LLM Wiki（生成し続ける場）
書く主体	自分（書かないと増えない）	AIが編集者として常駐
情報の扱い	保存して終わり	統合・要約・相互リンクで育つ
AIの役割	検索（再発見）止まり	蓄積（読むたび厚くなる）
土台	専用DB／専用アプリに依存	ただのMarkdown＋汎用エディタ
持ち運び	エクスポートに難	フォルダごと可搬・Git管理
続くか	死蔵しがち	複利で増える実感

※ 本記事は筆者個人のナレッジ基盤づくりの実記録。固有のパス・識別子・シークレットは伏せた匿名ケーススタディ。