llmwiki を採用する前に読む: MCP と Claude Routine で回す個人 Wiki の実像

llmwiki が埋めようとしている穴は「読んだ事実」ではなく「読んだときの思考」

多くのノートツールは、クリップした記事を保存するところで仕事を終える。llmwiki が狙うのはその先で、README は「クリッパーがハイライトと余白のコメントをソースと一緒に取り込むため、Wiki は何を読んだかの記録ではなく、それについて何を考えたかの記録になる」と説明している。つまり保存対象は文書そのものではなく、文書に対する自分の反応である。想定読者は README が 3 つのスケールとして挙げている。個人の読書履歴、LLM に自分の思考モデルを渡すためのコンテキスト層、そして組織の institutional memory である。3 つ目については README 自身が「組織の多くは制度記憶が貧弱だ。ノウハウは一般に人の頭の中に住んでいる」と書いたうえで、企業がこのモデルを採用することを望むと述べるにとどまり、組織向けの機能が別途用意されているわけではない。まず個人用途の道具として読むのが正確だ。

ソースは動かさない。生成物だけを同じフォルダに置く

設計の要は「元ファイルに触らない」という一点にある。README によれば、指定したフォルダはローカル検索インデックスに取り込まれ、アプリ上に現れ、Claude が読めるようになる。ファイルを移動も変更もアップロードもしない。追加されるのは生成ページ用の `wiki/` フォルダと、隠しディレクトリの `.llmwiki/` インデックスだけである。この分離は運用上かなり効く。既に資料が入っているフォルダをそのまま指定できるので、専用の保管場所を作り直す必要がない。取り込み経路は 2 つある。Web アプリへのドラッグ&ドロップ、あるいはワークスペースフォルダへの直接投入で、後者の場合はバックグラウンドの watcher が拾ってインデックスする。もう一つが Chrome 拡張で、Web ページと PDF を読みながらクリップし、ハイライトとコメントを付ける。この 2 経路が合流して、Claude が MCP 越しに読める素材になる。

MCP はワークスペース 1 つにつき 1 エントリ。ここが最初のつまずきどころ

Claude に読み書きさせる経路は MCP サーバーである。`./llmwiki mcp-config ~/research`（Windows は `python llmwiki mcp-config C:\Users\you\research`）を実行すると JSON が出力され、それを `claude_desktop_config.json`（Claude Desktop）または `.claude/settings.json`（Claude Code）に貼る。README が明示している重要な制約は「1 ワークスペースが 1 MCP サーバーエントリ」という点で、フォルダを増やすたびにエントリも増える。研究用と仕事用を分けて運用したい人には自然な設計だが、設定ファイルが肥大することを受け入れる必要がある。接続後に投げる指示の例も README に載っている。ガイドを読ませたうえでソースを取り込み、Wiki の構築を始めさせる、という流れだ。MCP 対応アプリは Claude.ai、Claude Cowork、Claude Code、Codex、その他 MCP 互換アプリと列挙されている。

「自己メンテナンス」の実体は Claude Routine という外部スケジューラへの依存

このプロジェクトの目玉は夜間の自動更新だが、その機構は llmwiki の中にはない。README が示すのは Claude Routine、つまりスケジュールされたプロンプトを外部で走らせる仕組みである。推奨プロンプトはこうだ。ガイドを読み、前回の実行以降にワークスペースへ追加されたもの（新規ソース、クリップ、ハイライト）を探し、それぞれについて Wiki を更新し、必要なら新規ページを書き、既存ページへ新素材を織り込み、影響を受ける相互参照と引用を直す。これを毎晩走らせる。実行先は 2 通りあり、Claude Code Routines は Anthropic のクラウド上で固定のケイデンスで動くためノート PC を閉じていても実行される。Desktop scheduled task は同じプロンプトを自分のマシン上で動かす。ここから読み取れる帰結は明確で、llmwiki 単体では自律更新は成立しない。Claude 側のスケジューリング機能とアカウントが前提条件になる。

セットアップで実際に打つコマンドと、静かに効いてくる依存関係

要件は Python 3.11 以上、Node.js 20 以上。任意で LibreOffice（Word と PowerPoint の抽出に使う）と `MISTRAL_API_KEY`（PDF の OCR 品質を上げる）が挙げられている。手順は README のとおりで、`git clone` のあと venv を作り、`pip install -r api/requirements.txt -r mcp/requirements.txt`、続いて `cd web && npm install`。Windows では PowerShell 版のコマンドが別に用意され、実行ポリシーで activate が弾かれる場合は `Set-ExecutionPolicy -Scope CurrentUser RemoteSigned` を一度実行するか、activate を諦めて `.venv\Scripts\python` を直接使う。起動は `./llmwiki open ~/research` で、ワークスペース初期化、インデックス作成、API と Web アプリの起動、localhost:3000 のオープンまでを一度に行う。任意の LibreOffice と MISTRAL_API_KEY は、Office 文書やスキャン PDF を扱うなら事実上必須になる。ここを軽く見て導入すると、後から抽出品質の差に気づくことになる。

ローカルモードは loopback 専用。チーム共有基盤としては設計されていない

最もはっきりした制約はネットワーク面にある。README は「ローカルモードは意図的に loopback 専用で、API は 127.0.0.1 で待ち受け、LAN やリモートへのバインドをサポートしない」と書いている。つまり同じワークスペースを複数人で同時に開く使い方は、少なくともローカルモードの想定外である。組織の知識層という 3 つ目のスケールは README が希望として述べているもので、そのための共有機構や権限管理がここで説明されているわけではない。リモートアプリのセルフホストという選択肢は提示されているが、その構成の詳細は与えられた資料からは確認できない。次に、Claude アカウントが必須である点も見落としやすい。MCP 接続も Routine も Claude 側の機能に乗るため、モデルやプロバイダを差し替えたい場合にどこまで代替が効くかは、この資料からは判断できない。

RAG ツールや Obsidian との違いは「書く側を AI に渡しているか」

比較対象として分かりやすいのは、検索拡張生成のパイプラインや、リンクを手で張るタイプのノートアプリである。典型的な RAG は、質問が来た時点で関連チャンクを検索してモデルに渡す。索引はその場で消費され、人間が読める形では残らない。llmwiki は逆で、取り込んだ時点で Claude にページを書かせ、`wiki/` に永続的な成果物として残す。ページ間の相互リンクと、根拠となったソースへの逆リンクが生成され、グラフビューアで概念と実体の関係を見られる。Mermaid 図や SVG を含む可視化も生成物に含まれる。手動ノートとの違いはもっと単純で、リンクを張る作業と更新の判断を人間がやるか AI に渡すかである。ただしこの違いは諸刃で、生成されたページの正しさを保証する仕組みは資料からは読み取れない。引用が付くという記述はあるが、引用が内容の正確さを意味するわけではない。

Apache-2.0 で配布されていること、そして最初に確認すべきこと

ライセンスは Apache-2.0 で、リポジトリのバッジもこれを示している。特許条項を含む寛容なライセンスなので、社内ツールへの組み込みや改変のハードルは低い。ただし本記事は法的助言ではないし、依存する Claude、MCP、Supabase といった外部サービスの利用条件は llmwiki のライセンスとは別に確認する必要がある。リポジトリのトピックに supabase が含まれているが、与えられた README の中に Supabase の設定手順やスキーマの説明は見当たらない。リモートモードで何をホストするのかは、この資料だけでは判断できない部分である。同様に、リリースノートは取得されておらず、バージョン番号や破壊的変更の履歴も不明である。導入検討の第一歩は、自分の資料フォルダを 1 つ決めて `./llmwiki open` を通し、`wiki/` と `.llmwiki/` が期待どおりの場所に作られるかを確認することになる。そのうえで `./llmwiki mcp-config` の出力を Claude 側の設定ファイルに貼り、Routine を組む前に一度手動で「前回以降の差分を取り込んで Wiki を更新して」と指示し、生成ページの引用が元ソースを正しく指しているかを目で確かめる。ここで納得できなければ、夜間の自動実行を組んでも検証できない成果物が毎晩増えていくだけである。

編集部の結論

自分が読んだ資料とその周辺メモを数年単位で蓄積したい個人、そして Claude Code の Routine を既に回している開発者には向いている。逆に、チーム全員が同じ Wiki を同時編集する用途や、LAN 内の他端末から API にアクセスさせたい構成には向かない。ローカルモードは 127.0.0.1 に固定されており、リモートバインドをサポートしないと README が明記しているためだ。導入前に確認すべきは 3 点で、第一に `./llmwiki open <フォルダ>` を実行した対象ディレクトリに `wiki/` と `.llmwiki/` が作られること、第二に Word や PowerPoint の抽出に LibreOffice、PDF の高精度 OCR に MISTRAL_API_KEY が要ること、第三に `./llmwiki mcp-config <フォルダ>` の出力を claude_desktop_config.json か .claude/settings.json に貼る際、ワークスペース 1 つにつき MCP サーバーエントリが 1 つ増えることである。この 3 点を自分の運用に当てはめて問題がないと判断できたときだけ、最初のフォルダを指定してほしい。

公式情報源

1. Issues
2. License: Apache-2.0
3. lucasastorian/llmwiki on GitHub
4. Project website
5. README