2026 年 5 月 25 日、Zenn に 社内の知見を AI が漏らさず拾う唯一の設計思想 ─ Karpathy 氏の LLM Wiki を実践して分かったこと が公開されました。記事は Andrej Karpathy 氏が提唱する「LLM Wiki」の設計思想（1 トピック 1 ファイル / 自己完結 / リンクで関係性表現 / LLM が読み下しやすい平易な記述）を、実プロジェクトで実践し検証したものです。結論は 「Notion / Confluence の階層構造は LLM 取り出しに不向き / フラット + 高密度の Wiki が組織 RAG の品質を決める」でした。Stack Overflow の Q&A 利用が衰退し (Stack Overflow 衰退 → 社内ナレッジ Q&A 置換受託 参照)、社内の暗黙知 / 設計判断 / ポストモーテムが AI で再利用可能な形で残るかが、組織の生産性を左右する時代になりました。
受託で中堅企業の 社内知識基盤 / 組織 RAGを設計する立場では、これは 「Notion を大量に書いても AI が拾わない」という典型課題に、Karpathy 型 LLM Wiki 設計 + 組織 RAG パイプライン + 運用文化醸成を一体で実装する受託機会を意味します。これまで プライベート MCP サーバ実装受託 で扱った 社内 MCP 基盤、マルチモーダル Embedding + Reranker エンタープライズ RAG 受託 で扱った RAG 検索品質、Cloudflare エージェントメモリ業務システム受託 で扱った エージェントメモリを 「上流のナレッジ構造そのもの」から設計し直す受託テーマです。
なぜ「LLM Wiki 設計が分水嶺」なのか
| 観点 | 既存 Notion / Confluence | Karpathy 型 LLM Wiki |
|---|---|---|
| 構造 | 階層 / ツリー | フラット + 双方向リンク |
| 粒度 | 数千字の長文 / 大ページ | 1 トピック 1 ファイル / 短文 |
| 自己完結性 | 親ページに依存 | 各ファイル単独で読める |
| 冗長性 | 重複を嫌う | 必要なら重複も許す |
| LLM 取り出し成功率 | 30〜55% | 70〜85% |
| 更新文化 | 担当者の善意頼み | 仕事の一部に組込み |
| 検索粒度 | ページ単位 | チャンク単位 + 自己完結 |
| 暗黙知の表現 | 言外 / 図 / 雑談に分散 | 明示的に書き起こす |
つまり LLM Wiki 設計は 「人間が読めば分かる Notion」から 「AI が拾える / 人間も読める Wiki」へ、ナレッジの一次形式を変える設計判断です。
受託案件で活きる 3 つの構造変化
構造 1: 「ナレッジは Notion に書いてあるはず」から「AI 取り出し前提の Wiki」へ
中堅企業の Notion / Confluence は 5,000〜30,000 ページ規模に膨張し、「あるはずだが見つからない」「書いてあるが古い」状態が常態化しています。LLM Wiki への 再構造化 + 移行ガイドラインを提供する受託は、「既存ナレッジ資産を AI 時代に再活用」するための入口になります。
構造 2: 「RAG はベクトル検索チューニング」から「ナレッジ構造の設計」へ
組織 RAG の品質改善は 「Embedding モデル変える / Reranker 入れる / チャンクサイズ変える」といった 検索側のチューニングで語られがちですが、Karpathy 流が示すのは 「源泉のドキュメント構造を変えるほうが効果的」という事実です。これは マルチモーダル Embedding + Reranker エンタープライズ RAG 受託 や Ettin Reranker RAG 最適化受託 の 下流チューニングを補完する 上流設計受託です。
構造 3: 「ナレッジマネジメントは情シス / 総務管轄」から「業務の標準動作」へ
「ドキュメントを書く文化」は 担当者の善意に頼ってきましたが、AI で再利用可能にするには **「業務完了時の Wiki 更新」を 標準動作に組み込む必要があります。これは Anthropic XML プロンプト構造受託 で扱った プロンプト資産化と同じく、「個人技から組織資産へ」**の文化変容です。
受託で提供する「Karpathy 型 LLM Wiki + 組織 RAG」5 フェーズ
フェーズ 1: 現状診断（2〜3 週間）
- 既存ナレッジ棚卸し（Notion / Confluence / Slack / ファイル）
- LLM 取り出し成功率測定（代表 30 クエリ）
- ナレッジ更新頻度 / 著者分布
- 業務プロセスとナレッジの紐付け
- LLM Wiki 化候補領域の優先順位付け
フェーズ 2: Wiki 設計（2〜3 週間）
- LLM Wiki スキーマ定義（トピック粒度 / リンク規約）
- 命名規約 / メタデータ標準
- 移行ガイドライン（既存 Notion → LLM Wiki）
- セキュリティ / アクセス制御設計
- 更新トリガー設計（業務完了 / PR マージ / 障害対応後）
フェーズ 3: パイロット移行（3〜4 週間）
- 1〜2 部署で LLM Wiki 試験運用
- 既存ナレッジの 100〜300 トピック移行
- RAG パイプライン構築（ベクトル DB / Reranker）
- 検索成功率 A/B 評価
- 利用者ヒアリング + 改善
フェーズ 4: 全社展開（4〜8 週間）
- 部署別段階展開
- RAG 検索 UI / Slack 統合 / IDE 統合
- 更新文化醸成（オンボーディング / KPI）
- 品質メトリクス（成功率 / 鮮度 / 重複）
- ガバナンス（公開範囲 / 機密区分）
フェーズ 5: 月次運用レビュー（継続）
- LLM 取り出し成功率モニタリング
- 古いトピック / 重複検出
- 新規業務領域の Wiki 化追加
- RAG パイプライン進化追従
- 利用状況 / ユーザー満足度
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| Wiki ホスト | Git + Markdown / Outline / Logseq | Notion + 規約強化 |
| ベクトル DB | Vectorize / Qdrant / Weaviate | pgvector |
| Embedding | OpenAI / Cohere / Granite multilingual | E5 / BGE |
| Reranker | Ettin / Cohere Rerank / Voyage | Custom |
| RAG オーケストレーション | LlamaIndex / LangChain / Mastra | 自作 |
| 検索 UI | Glean / 自作 + Slackbot | Microsoft Search |
| アクセス制御 | OIDC + ABAC | LDAP / SAML |
| 可観測性 | Langfuse / Phoenix | Datadog |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| Notion / Confluence が 5,000 ページ超 | ドキュメント 100 ページ未満 |
| 社員 50 名以上 | 数名規模 |
| 業務プロセスが文書依存 | 全業務が口頭 / 直接連携 |
| 退職 / 異動でナレッジが失われやすい | 全員が長期在籍 |
| AI 検索 / アシスタント導入を計画中 | 検索ニーズなし |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象ナレッジ範囲 | 部署 / プロセス / 機密区分 | コンプライアンス適合 |
| Wiki スキーマ知財 | スキーマ仕様 + ガイドラインの帰属 | 二次利用条件 |
| 検索品質 SLA | 取り出し成功率 / 鮮度 | 業務 KPI 連動 |
| 更新文化醸成 | オンボーディング / トレーニング | 体制整備 |
| アクセス制御 | 公開 / 機密区分の運用 | 法令 / 顧客契約適合 |
| 退場時引き渡し | Wiki + RAG + 評価セット | 自社運用継続性 |
価格モデル — Karpathy 型 LLM Wiki + 組織 RAG パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 180 万円〜（6 週間） | 棚卸し + 1 部署パイロット | レポート + ロードマップ |
| Lite | 60 万円〜 / 月 | 社員 50〜150 名 | 月次レビュー + 改善 |
| Standard | 130 万円〜 / 月 | 社員 150〜400 名 | + 更新文化醸成 + ガバナンス |
| Enterprise | 260 万円〜 / 月 | 社員 400 超 / 全社展開 | + 専任ナレッジエンジニア |
| 初期構築 | 460 万円〜（一括） | Wiki + RAG + 検索 UI 構築 | 全プラン共通オプション |
顧客側 ROI 試算（社員 200 名 / Notion 12,000 ページ / 既存 RAG 検索成功率 40% 想定）
| 項目 | 既存（Notion + RAG） | LLM Wiki 移行後 | 差分 |
|---|---|---|---|
| LLM 取り出し成功率 | 40% | 78% | +38pt |
| ナレッジ検索工数（月） | 600h | 220h | -380h |
| 新人オンボーディング期間 | 3 ヶ月 | 1.5 ヶ月 | -1.5 ヶ月 |
| 退職 / 異動時の知識ロス | 大（属人化） | 限定（Wiki に残る） | リスク低減 |
| 同じ問題の再発生件数 | 月 18 件 | 月 5 件 | -13 件 / 月 |
| 年間効果 | — | — | 約 3,650 万円相当 + 組織レジリエンス向上 |
時給 8,000 円換算で 年間 3,650 万円超の工数削減 + 退職リスク低減。Standard プラン（年額 1,560 万円）でも 6 ヶ月以内で回収可能です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 「全 Notion を Wiki 化」で完了主義
12,000 ページを一気に移行しようとすると、疲弊して頓挫します。頻出 / 業務クリティカル領域から 300 トピック単位で段階移行します。
落とし穴 2: 階層を残したまま Wiki 化
「フラット + リンク」が原則なのに 既存階層をそのまま残すと、LLM の取り出し成功率が伸びません。スキーマ設計時に 階層撤廃 + リンク補強を徹底します。
落とし穴 3: 更新文化醸成を後回し
「ツールを入れれば書く」と思って 書く動機設計を省くと、3 ヶ月後に古いナレッジだらけになります。業務完了テンプレ + KPI 反映を初期に設計します。
落とし穴 4: アクセス制御を後付け
「全員に開放」で 機密情報が混在すると、法務 / 顧客契約で問題化します。公開 / 部内 / 限定の 3 区分を 初期スキーマに組み込みます。
落とし穴 5: RAG のチューニングだけで解決しようとする
「Reranker を入れれば成功率が上がる」と 検索側だけ強化しても、源泉が古い / 重複 / 階層依存なら限界があります。Wiki 側の設計と並走します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | ナレッジ棚卸し + 取り出し成功率測定 |
| Week 3〜4 | LLM Wiki スキーマ設計 + 移行ガイド |
| Week 5〜7 | パイロット部署で 300 トピック移行 |
| Week 8〜9 | RAG パイプライン構築 + A/B 評価 |
| Week 10 | 全社展開計画 + オンボーディング設計 |
| Week 11 | Slack / IDE 統合 |
| Week 12〜13 | 月次レビュー定例化 + KPI 反映 |
まとめ — 「Notion に書いてあるはず」から「AI が拾える Wiki」へ
Karpathy 型 LLM Wiki は、**「ナレッジは書けば伝わる」前提を覆し、「AI 取り出しを前提に書く」**という新しいドキュメント文化を提示しました。受託で中堅企業の社内知識基盤を支える立場では、Wiki スキーマ設計 + 段階移行 + RAG 構築 + 更新文化醸成 + 月次運用を一体で提供する 「Karpathy 型 LLM Wiki + 組織 RAG」が、新しい主力サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「Notion はあるが AI が拾えない」「退職で知識が失われる」「RAG チューニングが頭打ち」というご相談は お問い合わせフォーム からお気軽にどうぞ。
