SERIES ｜ AIと"第二の脳"を作る #2
前回（#1）で、AIが編集者として常駐するWiki（第二の脳）の器ができた。読むたび厚くなる。理屈の上では、完璧だった。
関連記事 ｜ 前回 #1【AIと“第二の脳”を作る #1】なぜ“普通のメモアプリ”は続かないのか──8つのPKM挫折と「LLM Wiki」という解
→
でも、毎日使っていると、ひとつの壁にぶつかった。いちばん思考が生まれる場所から、Wikiに書けないのだ。賢いWikiを作ったのに、それは孤島だった。この記事は、その孤島に橋を架けて——「どこでAIと話していても、同じWikiに同じように触れる」状態を作った日の記録だ。シリーズ最初の山場になる。[1]
01最も思考が生まれる場所から、切り離されていた
私がAIと作業する時間のほとんどは、どこにあるか。Wikiを開いた専用の作業場——ではない。普通のチャットと、開発で今まさにハマっている別スレッドだ。
- 開発中の「ここが動かない」議論 → 別プロジェクトの対話。
- ふとした学び・気づき → 何気ないチャット。
- 仕様の検討 → また別のスレッド。
ここがいちばん知識が生まれる現場だ。なのに「この学びをWikiに入れたい」と思った瞬間、当時はこうするしかなかった——①スレッドを切り替え、②Wikiを開いた専用の場所に移り、③同じことをもう一度言い直して書く。
この断絶が、地味に効く。ひと手間あるだけで、人は「書いてから残す」より「残さない」を選んでしまう。結果、せっかくのWikiは、最も思考が生まれる場所から切り離された"宝箱"になっていた。鍵のかかった宝箱に、知識は貯まらない。
02伏線回収：汎用基盤だから、入口を増やせる
ここで、#1の地味な判断が効いてくる。私はWikiを特定のAIツール専用にせず、ただのMarkdown＋汎用基盤にしておいた。
もし最初から一つのツール専用に作り込んでいたら、この先の拡張は不可能だった。だが土台が汎用だったから、いくらでも"入口"を後付けできる。やることは決まった——Claudeが話せるあらゆる場所から、同じWikiに触れられる「共通の通り道」を作る。それが達成できれば、宝箱は「どこでも呼び出せる第二の脳」に変わる。
設計の自由は、たいてい"過去の自分が何を専用化しなかったか"で決まる。
03解き方：MCP＋プラグインの2本立て
通り道の正体は、いま注目されているMCP（Model Context Protocol）——AIに外部のツールや知識を繋ぐ標準的な仕組みだ。これを使って、Wikiを「AIが呼べる道具一式」として公開する。
ただし、一手段では全部はカバーできない。そこで2本立てにした。
- MCPサーバー：開発用CLIから、どのフォルダで起動しても同じWikiに触れる。
- プラグイン：別の対話スレッドや共同作業環境から、その場でWikiをマウントして触れる。
そして道具は「読む」と「書く」を明確に分けた。スキーマ取得・ページ読取・横断検索・健全性チェック（読む）と、ソース追加・ページ作成更新・索引更新・ログ追記（書く）。こう分けると、AIが自然に「まず読んで→判断して→書く」という安全な手順を踏める。書き込み系は、想定外の場所に書かないよう経路を正規化して守る。
046つの地雷①：サンドボックスに、ローカルのパスは届かない
ここからが山場——深夜の地雷6連発だ。最初のひとつが、最大の難所だった。
プラグインの接続設定に、自分のPC上の絶対パスを書いた。動かない。MCPサーバーが永遠に"接続中"のまま、道具が一つも出てこない。
原因は、プラグインは隔離された別環境（サンドボックス）の中で動くこと。そこから私のPCのファイルは見えない。当然だった。腑に落ちた瞬間、設計が一気に決まった——「パスで参照する」のをやめ、サーバーのコードそのものをプラグインに同梱する。"持っていく"のだ、参照するのではなく。この「プラグイン＝コード同梱が原則」が分かると、残りの地雷も筋が通った。
056つの地雷②：61MB→1.1MB と、起動タイミングのズレ
同梱と決めたら、次の壁。依存ライブラリ込みの素直な同梱は61MB。プラグインとしては非現実的だ。
- 解決＝バンドル：ビルドツールで全依存を1ファイルに固める。61MB → 1.1MB（圧縮で約190KB）。配って一瞬で動く軽さになった。
もうひとつ、厄介な"時間差"の罠があった。
- 起動とマウントのズレ：サーバーは「インストール直後（=まだWiki未接続）」に起動し、Wikiの場所を一度だけ覚え込んでいた。その後ユーザーがWikiを繋いでも、古い場所を握ったまま。
- 解決＝遅延解決（Lazy Resolution）：場所を起動時に固定せず、道具を呼ぶたびに毎回チェックして解決し直す。マウントの前後どちらで起動しても正しく繋がる。サンドボックスはマウント先が毎回変わるので、優先順位つきの自動探索も足した。
残りの地雷も同種だった——設定に書いても黙って無視される項目、エディタ側の自動バックアップとの競合。どれも"力技"ではなく、環境の性質を理解して設計で抜けた。[2]
06「一過性の消耗品」を、止めた瞬間
そして、繋がった。開発CLIから、別の対話スレッドから、何気ないチャットから——どこにいても、同じWikiが同じように触れる。
これは単なる機能追加の嬉しさではなかった。毎日AIと交わす膨大なやり取りが、その場で消えていくことへの慢性的なモヤモヤ。その答えが、ここにあった。
日々の作業が、一過性の消耗品ではなく、Wikiに知見として積み上がっていく——この感覚は、ずっと探していたものだった。
「その場の作業 → 消耗」から「その場の作業 → 蓄積」へ。#1で触れた「リンク置き場にしかならない」問題の、もっと深い層での解決だった。
07正直な発見：触れるだけでは、足りなかった
ここで、格好をつけずに書いておきたい正直な気づきがある。
入口は揃った。でも運用してみると、私自身が「ゼロからWikiページを書く」という行為は、ほとんどしていなかった。触れる経路ができたことと、実際に書き込まれる量は、別の話だったのだ。
本当に必要だったのは、「私が書く」ための入口ではなく、私の周りで生まれる思考の断片を、勝手に捕まえてくれる仕組みだった。気づいたこと、保存した記事に添えた一言、AIとの共創の過程——そういう"こぼれ落ちる思考"を自動で拾う層。
これが、次回以降の伏線になる。入口を作った（#2）→ その入口に"思考の断片"を自動で流し込む仕組みへ（#3）。第二の脳は、触れるだけでは育たない。流し込まれて、育つ。
08締め：孤島に、橋が架かった
賢いWikiを作っても、それが孤島なら使われない。いちばん思考が生まれる場所から、ワンタッチで触れる——この一点が、第二の脳を「死蔵される宝箱」と「日々育つ器」に分けた。
そして、それを可能にしたのは魔法ではなく、過去の自分が"専用化しなかった"判断と、環境の性質を理解して地雷を一つずつ設計で抜いた地道さだ。次回#3は、いよいよ「思考の断片を自動で流し込む」——入口に、知識を運ぶ水路を引く話だ。
関連記事 ｜ 次回 #3【AIと“第二の脳”を作る #3】つぶやくだけで、自分知になる──“思考の断片”を自動で流し込む水路を引く
→
「これ、自分の環境のどこからでも呼べたらな」と思った仕組み。まず、言葉にしてみてほしい。
切り離された宝箱 vs どこでも繋がる第二の脳。要点を一枚に。
| 観点 | 孤島Wiki（切り離された宝箱） | どこでも繋がる第二の脳（MCP化） |
|---|---|---|
| アクセス | 専用の場所からのみ | CLI・チャット・共同作業環境、どこからでも |
| 書き残し | 断絶があり「残さない」を選びがち | その場で書ける＝断絶ゼロ |
| 接続の正体 | ツール内に閉じる | MCP（標準プロトコル）で共通化 |
| 配布 | 環境ごとに手作業 | 軽量プラグイン1つで復元（61MB→1.1MB） |
| 設計の前提 | 専用化＝拡張不能 | 汎用基盤＝入口を後付けできる |
| 知識の流量 | 消耗（その場で消える） | 蓄積（積み上がる） |
※ 本記事は筆者個人のナレッジ基盤づくりの実記録。固有のパス・識別子・内部設定は伏せた匿名ケーススタディ。
脚注
- 本シリーズ「AIと“第二の脳”を作る」は、AIを編集者として常駐させる個人ナレッジ基盤を1から作り、育てていく実記録。#1で器を作り、本稿#2で"どこからでも触れる"通り道を作った。
- MCPサーバー／プラグイン開発で実際に踏んだ落とし穴は、サンドボックスのファイルアクセス・依存バンドル・起動と設定確定のタイミング差・設定スキーマの非対応フィールド・エディタ拡張との競合など。いずれも環境の性質を理解した設計で回避した。
「自分のあらゆる環境から、ひとつの場所に繋ぎたい」を、言葉にしてください。
その仕組み、AIと1から作れます。まずは相談から——問い合わせは、AIがその場でお応えします。
無料で相談する →
