llm-wiki-agent レビュー: raw/ に置いた資料を coding agent が wiki に変える仕組み
A personal knowledge base that builds and maintains itself. Drop in sources — Claude (or Codex/Gemini) reads them, extracts knowledge, and maintains a persistent interlinked wiki. Works with Claude Code, Codex, OpenCode, Gemini CLI. No API key needed.
ひと目でわかる
- これは何？
- llm-wiki-agent は、コーディングエージェントのスキルとして動く個人向け知識ベースだ。資料を raw/ に置いて ingest と指示すると、markdown の相互リンク wiki と知識グラフを生成する。API キーも Python のセットアップも不要と README は述べている。
- 誰に向いている？
- 採用を検討すべきなのは、Claude Code や Codex などのエージェントをすでに日常使いしていて、論文や議事録を raw/ に溜め込む習慣がある個人だ。逆に、API キーなしで完全に再現可能なバッチ処理を求めている場合や、複数人で wiki を共有したいチームには向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰の何を解決するのか: 検索させる側から書かせる側への反転
多くのノートツールは、利用者に自分のメモを検索させる。llm-wiki-agent の発想はその逆で、README は「読んだものを読み込み、時間とともに厚みを増す構造化 wiki を書く」と説明している。入力は raw/ に置いた資料、出力は wiki/ 配下の markdown 群だ。
対象は、論文や記事、議事録、書籍の章を継続的に溜めている個人である。README のユースケースには研究、読書、個人の知識管理、業務・チームの情報整理、競合分析が並ぶ。共通するのは、資料を読む量が増えるほど相互参照の維持コストが跳ね上がるという問題で、このツールはその維持作業をエージェントに寄せる。
ここで注意したいのは、これは単体のアプリではないという点だ。README は冒頭で「コーディングエージェントのスキル」と明記しており、動かす主体は Claude Code、Codex、OpenCode、Gemini CLI のいずれかになる。Python が主言語として記載されているが、利用者側が Python 環境を構築する必要はないと README は述べている。
wiki/ と graph/ の分離: 生成物がどこに積まれるか
README が示すディレクトリ構成は、知識の種類ごとに出力先を分けている。wiki/index.md は全ページの目録で、ingest のたびに更新される。wiki/log.md は全操作を追記のみで記録する。wiki/overview.md は全ソースをまたぐ統合で、これも ingest ごとに改訂される。
ページ種別は sources、entities、concepts、syntheses の4つだ。sources は資料1件につき1ページの要約、entities は人物・企業・プロジェクト、concepts はアイデアやフレームワーク、syntheses は query の回答を wiki ページとして保存したものになる。entities と concepts は自動生成され、新しい資料が既存の項目に触れるたびに更新される。
グラフは wiki/ とは別に graph/ に置かれる。graph/graph.json がノードとエッジの永続データで、SHA256 によるキャッシュを持つ。graph/graph.html は vis.js による可視化で、ブラウザで開く形式だと README は説明している。エッジは [[wikilink]] に対応し、それとは別にエージェントが推論した暗黙の関係が点線で描かれる。コミュニティ検出によって関連トピックがクラスタリングされる。
この分離には実務上の意味がある。wiki/ は人が読む markdown で、graph/ は機械が読む JSON とブラウザ表示だ。生成物を Git で管理するなら、差分が読みやすいのは前者、再生成の単位が大きいのは後者になる。
ingest の裏側で起きていること: 変換、抽出、矛盾の検出
ingest は README によれば単一のコマンドではなく、エージェントが解釈するトリガーだ。ingest raw/papers/my-paper.md のようにパスを渡すと、エージェントが資料を読み、知識を抽出し、wiki を更新する。
対応形式は markdown、PDF、DOCX、PPTX、XLSX、HTML、TXT、CSV、JSON、XML、RST、EPUB など。markdown 以外は ingest 時に markitdown で自動変換される。README は「別ステップは不要」と書いており、変換は前処理として利用者の手から隠れている。ここは賛否が分かれる設計だ。便利である一方、変換結果を利用者が確認しないまま wiki に取り込まれることになる。表や数式の多い PDF を扱うなら、変換の品質が wiki の品質をそのまま決める。
矛盾の検出は ingest 時に行われると README は述べている。新しい資料が既存の主張と衝突する場合、query の時点まで埋もれさせず、取り込み時点でフラグを立てる。これは設計上の判断として評価できる。矛盾は後から探すより、入り口で気づく方が修正コストが低い。
ただし、この仕組みが機能するかどうかはエージェントの読解に依存する。決定論的なパーサではなく、LLM が「矛盾している」と判断したものがフラグになる。README は判定基準や閾値について何も述べていない。
導入手順: clone してエージェントを起動するだけ
README のインストール手順は短い。前提として Claude Code、Codex、Gemini CLI、または設定ファイルを読む任意のエージェントが必要とされる。
git clone https://github.com/SamurAIGPT/llm-wiki-agent.git を実行し、cd llm-wiki-agent で移動する。その後、使うエージェントに応じて claude、codex、opencode、gemini のいずれかを起動する。README は「API キーも Python のセットアップも不要」と明記している。
エージェントごとに読む設定ファイルが異なる。Claude Code は CLAUDE.md と .claude/commands/ を読み、codex と opencode は AGENTS.md、gemini は GEMINI.md を読む。Claude Code では /wiki-ingest、/wiki-query、/wiki-lint、/wiki-graph がスラッシュコマンドとして使える。README はこれらを Claude Code 固有と位置づけ、他のエージェントでは自然言語トリガーを使うと説明している。自然言語側の挙動は同一だとされている。
操作は ingest、query、lint、build graph の4系統だ。ingest は単一ファイルでも batch でもよく、ingest slides.pptx notes.docx のように混在形式を並べられる。query は wiki ページから回答を合成し、lint は孤立ページ、矛盾、欠落を探す。build graph は全 wikilink から graph.html を生成する。自然言語でも「Ingest this paper: raw/papers/llama2.md」のような指示が通ると README は述べている。
エージェント非依存に見えて、実際はホスト依存である
README は4つのエージェントへの対応を掲げ、自然言語トリガーは同一に動くと説明する。だが、設定ファイルが CLAUDE.md、AGENTS.md、GEMINI.md に分かれていること自体が、挙動の差がゼロではないことを示唆する。スラッシュコマンドが Claude Code 限定である点も同じだ。
より本質的なのは、このツールが自前のランタイムを持たないことだ。ingest の抽出精度、矛盾判定、暗黙エッジの推論は、すべてホストのエージェントの能力とコンテキスト長に依存する。つまり llm-wiki-agent の品質は、モデルを差し替えた瞬間に変わる。README はこの依存関係を明示していない。
再現性を求める用途では、これが弱点になる。同じ raw/ を同じ順序で ingest しても、抽出される entity や concept の粒度が毎回一致する保証は README には書かれていない。wiki/log.md が追記専用であることは、逆に言えば「何がどう変わったか」を後から追う前提の設計だとも読める。
もう一点、README は「No API key needed」を売り文句にしている。これはエージェント側の認証に乗るという意味であり、無料で無制限という意味ではない。ホストの利用枠を消費する点は理解しておく必要がある。
Obsidian や RAG パイプラインとの違いはどこにあるか
比較対象として分かりやすいのは Obsidian だ。README の topics にも obsidian が挙がっている。Obsidian は markdown の保管と [[wikilink]] の解決、グラフ表示を担うが、ページを書くのは人間である。llm-wiki-agent は逆で、書き手をエージェントに置き、人間は raw/ に資料を落とすだけにする。生成物が markdown である以上、wiki/ を Obsidian の vault として開くことは技術的に可能だが、README にその手順は記載されていない。
RAG パイプラインとの差はもっと明確だ。典型的な RAG は、資料をチャンクに分割してベクトル化し、質問時に類似チャンクを検索して回答を組み立てる。成果物は回答であり、索引は再利用のたびに引かれる。llm-wiki-agent は検索の代わりに書き込みを行う。ingest の時点で entity と concept のページを作り、相互リンクを張り、overview.md を改訂する。query の答えも syntheses/ にページとして残る。
この違いは、資料が増えたときの挙動に現れる。RAG は索引を再構築すれば済むが、wiki は既存ページの書き換えが発生する。README が「Every new source makes the wiki richer」と表現するのはこの蓄積を指す。裏返せば、誤った抽出が混ざると後続の ingest がその誤りを参照しながら育つ。lint が孤立ページや欠落を報告するのは、この累積に対する安全弁だと読める。
向かない場面と、試す前に見ておくべきファイル
第一に、複数人での共同編集には向かない。wiki/log.md は追記専用の操作記録であり、誰がどのページを承認したかを管理する仕組みは README に登場しない。チームの議事録を扱う用例は紹介されているが、それは1人が取り込んで query する使い方だ。
第二に、監査や法務のように出典の完全なトレーサビリティが要る用途には向かない。抽出も矛盾判定もエージェントの判断であり、判定基準は README に記述がない。sources/ に資料ごとの要約ページが残るため出典には遡れるが、どの記述がどの行に由来するかまでは保証されない。
第三に、PDF の変換品質が重要な資料。markitdown を経由する以上、レイアウトの複雑な文書では情報が落ちる可能性がある。README は変換精度に触れていない。
ライセンスは MIT で、リポジトリに LICENSE ファイルがある。MIT は商用利用や改変、再配布を許容する寛容なライセンスだが、無保証である点は他の MIT プロジェクトと同じだ。ここから先は法的助言ではないが、同梱物や依存のライセンスは自分で確認する必要がある。
導入前に見るべきファイルは3つ。wiki/log.md で操作がどう記録されるか、graph/graph.json で SHA256 キャッシュがどの粒度で更新されるか、そして markitdown が自分の手持ちの PDF をどこまで保持できるか。この3点は README だけでは判断できない。
編集部の結論
採用を検討すべきなのは、Claude Code や Codex などのエージェントをすでに日常使いしていて、論文や議事録を raw/ に溜め込む習慣がある個人だ。逆に、API キーなしで完全に再現可能なバッチ処理を求めている場合や、複数人で wiki を共有したいチームには向かない。試す前に確認すべきは、wiki/log.md に何が追記されるか、graph/graph.json の SHA256 キャッシュがどの単位で更新されるか、そして markitdown が自分の PDF をどの程度保持できるかの3点である。
コミュニティノート