0004: LLM-Wiki生成エンジンにllm-wiki-compilerを採用
背景
decisions/0002で、専用エージェント（Goose土台、vpsprofile、モデルは OpenCode Go）の用途を「情報収集アシスト」と「LLM-Wiki生成」に限定したが、 LLM-Wiki生成そのものを行うエンジンは未定だった。
atomicstrata/llm-wiki-compiler （npm: llm-wiki-compiler、CLIコマンドllmwiki）は、Andrej Karpathyが提唱した “LLM Wiki” パターン（生データを都度読み直すのではなく、コンパイル時に一度だけ構造化 して蓄積する）をそのまま実装したOSSで、名前・設計思想ともpaper-civic-kitの LLM-Wikiの狙いと高い親和性がある。
決定
- LLM-Wiki生成エンジンとして
llm-wiki-compiler（llmwiki）を採用する。 paper-civic-kit独自のLLM-Wikiコンパイラは新たに作らない。 - モデルプロバイダは
LLMWIKI_PROVIDER=openaiを指定し、OPENAI_API_KEY/OPENAI_BASE_URLをdecisions/0002で確定したOpenCode GoのAPI key/エンドポイント に向ける。Anthropic/Claude Agent SDKプロバイダは使わない。 - 専用エージェント（Goose、0002）からは、
llmwiki serve --root <wiki project>が 立てるMCPサーバーをMCPクライアントとして接続する形で使う。paper-civic-kit側で ingest/compile/query/lint用の薄いラッパーは作ってよいが、compile/query/lintの ロジック自体はllmwikiにそのまま任せる。 - Gooseと
llmwikiの役割分担は次の通り: Goose（専用エージェント）は RSS/DuckDuckGo/e-Govを横断する探索・ingest判断のループだけを担当し、判断結果 をllmwikiのingestツール/CLIに渡す。compile/queryはGooseを経由せず、llmwiki自身がdecisions/0002で確定したOpenCode Goプロバイダ設定で直接LLMを 呼び出す（cron等でllmwiki compileを単独実行してもよい）。Gooseは情報収集の 自律ループにのみ必要で、LLM-Wiki生成そのものには不要（0002参照）。 - 生成される
wiki/concepts/・wiki/queries/・.llmwiki/というllmwiki側の ディレクトリ構造は、そのままLLM-Wikiの実体として受け入れる。Paper-Wiki/Law-Wiki/ Data-Wikiとの命名・frontmatter整合は別タスクで設計する（下記「未決定事項」）。
理由
llmwikiは生成した段落・主張にソースファイルと行範囲の引用を持たせ、llmwiki lintでリンク切れを検証する。AGENTS.mdの「LLM-Wikiの内容は地図であり、 根拠はPaper-Wiki、Law-Wiki、Data-Wikiの出典リンクへ戻す」という制約とそのまま 一致する。- 生成ページは信頼度・矛盾・スキーマ逸脱があると自動的にレビュー待ちになる （review policy、fail-closed config）。「取得結果は候補であり、解釈や論証として 生成しない」という方針と設計思想が合う。
- MCPサーバー（
llmwiki serve）とTypeScript SDK（createWiki()）を標準で持ち、 専用エージェント（Goose）からMCP経由で薄く接続するだけで済む。AGENTS.mdの 「既存OSSを使える場合は薄い接着層を優先する」に沿う。 - プロバイダがコード内で環境変数切り替え式になっており（Anthropic / Claude Agent SDK / OpenAI互換 / Ollama / GitHub Copilot）、
LLMWIKI_PROVIDER=openaiとOPENAI_BASE_URLの組み合わせで、decision 0002で確定したOpenCode Go（OpenAI互換エンドポイント）にそのまま接続できる。Claudeを使わない方針 （decision 0002）と矛盾しない。 - MITライセンス、直近コミットが確認時点から10日ほど前、v0.7.0〜v0.12.0まで タグが継続的に打たれており、実働しているプロジェクトと判断できる。
影響
docs/architecture.mdの技術スタック表に、LLM-Wiki生成エンジンとしてllm-wiki-compilerを追記する。llmwikiはNode.js 24以上を要求する。専用エージェント実行profile（vps、 decision 0002）のNodeバージョンをこれに合わせる必要がある。wiki/concepts/・wiki/queries/・.llmwiki/というディレクトリ名は、 AGENTS.mdの「実データはdata/、storage/、paper-wiki/、news-wiki/等の Git管理外に置く」というGit管理外ディレクトリの列挙に、LLM-Wiki用の置き場所 （例:llm-wiki/配下にllmwikiのプロジェクトルートを置く）を追加する形で 対応する。具体名は実装タスク側で決める。
未決定事項
llmwikiが生成するconcept/entity/comparison/overviewページと、 Paper-Wiki/Law-Wiki/Data-Wiki側のfrontmatter・wikilink規約をどう整合させるかは 未確定。llmwikiは自らを「まだ初期段階のソフトウェア」と説明しており、単一組織 （atomicstrata）によるメンテナンスでバス因子がある。バージョン追従方針はhouki-egov-mcp（decision 0002）と同様、継続的に確認する。- Open Knowledge Format（OKF）によるPaper-Wiki/Law-Wiki/Data-Wikiとの相互運用を 使うかどうかは未確定。OKF自体がGoogle Cloud主導の新しい仕様で、まだ安定して いない可能性がある。
LLM-Wiki生成に使う既定モデル→ 5モデル比較の結果、mimo-v2.5-proを既定に 確定（次点glm-5.2。minimax-m2.7はソースにない事実の補筆で除外、kimi-k2.6/ minimax-m3はconcept抽出の信頼性不足）。比較手順と根拠は tasks/0006。
検証結果（2026-07-05、tasks/0002）
llm-wiki-compiler@0.11.0をNode 26（micromamba envnode24）で導入し、OpenCode Go （OPENAI_BASE_URL=https://opencode.ai/zen/go/v1）でcompile/queryのend-to-end 動作を確認した。queryはwikilink付きの出典遡上可能な回答を返した。- llmwikiはOpenAIの構造化出力（
response_format: json_schema）と強制tool call （tool_choice: required）の両方を使う。OpenCode Goのモデル別対応を実測した 結果、両対応はkimi-k2.6 / minimax-m3 / minimax-m2.7 / glm-5.2 / mimo-v2.5-pro。 deepseek-v4-proはjson_schema非対応、qwen系とkimi-k2.7-codeはtool_choice required非対応で、llmwikiには使えない。 - OpenCode Goは
/embeddingsエンドポイントを提供しない（404）。llmwikiはembeddings なしでも語彙検索フォールバックで動作することを確認した（採用時の想定どおり）。 - kimi-k2.6は推論の前置き（英語）を生成ページ本文に混入させることがある。既定 モデルの選定では、この混入が起きにくいモデルを優先する。
- 実データの配置はユーザーの
knowledge/ディレクトリ（Git管理外）:knowledge/llm-wiki/projects/main-wiki/をllmwikiプロジェクトルートとし、 Obsidian vault（knowledge/obsidian-vaults/main/）からはLLM-Wiki -> ../../llm-wiki/projects/main-wiki/wikiのsymlinkで閲覧する。
追記: 廃止（2026-07-15）
LLM-Wikiは廃止する。0008で既に「後段」に格下げしていたが、実運用でほぼ 使われなかったため、生成そのものをやめる。
- 既存45ページはR2
archive/llm-wiki-20260715/へ退避済み（4.4MiB、検証済み）。 削除はしていない（可逆性を優先）。 - Obsidian vault側の
LLM-Wikiシンボリックリンクは削除済み。 llm-wiki-compiler自体のアンインストールは行わない（低コストで放置可能な ため、必要になれば再導入は容易）。- 理由: 抽出（Hyper-Extract→Obsidian）が知識表現の主軸として機能しており、 生成レイヤーの追加価値が実際には低かった。「抽出は生成に優先する」という 0008の原則を徹底する形。