LLM Wikiが社内ナレッジ基盤を変える
RAGの前に、AIが読める社内Wikiを作る
前回の記事では、社内の過去資産をAIで呼び出すには、ファイル検索だけでは足りず、RAGとメタデータ管理が必要だと書きました。
では、次に問題になるのは何でしょうか。
それは、社内にある情報がそのままではAIに扱いにくい、ということです。
提案書、最終報告書、議事録、体制表、見積、契約スコープ、振り返り資料。どれも重要な資産ですが、多くの場合、ファイル名、フォルダ、作成者、日付、版数、表記がばらばらです。
この状態でRAGを作っても、AIは「それっぽい資料」を拾うことはできますが、「会社の知識」として安定して使うのは難しくなります。
そこで必要になるのが、LLM Wikiという考え方です。
この発想の元になっているのは、Andrej Karpathyが公開したLLM Wikiのパターンです。
Karpathyの考え方は、資料をその場限りで検索して終わらせるのではなく、LLMにソースを読ませ、要約、関連ページ、索引、ログを更新させながら、MarkdownベースのWikiとして知識を蓄積していくものです。質問への良い回答も、チャット履歴に流して終わりではなく、Wikiに戻して知識として育てていきます。
本稿ではこの発想を、個人の知識管理ではなく、企業内の過去案件、顧客情報、成果物、メンバー知見を扱う社内ナレッジ基盤に応用して考えます。
LLM Wikiとは何か
LLM Wikiとは、社内資料をAIが読みやすく、人間も確認しやすい形に再整理したナレッジ層です。
通常のWikiは、人間が読むためにページを作ります。
LLM Wikiは、それに加えて、AIが検索、比較、要約、再利用しやすいように、情報を構造化します。
ポイントは、元資料を捨てることではありません。
元資料は根拠として残します。その上に、AIと人間が使いやすい要約ページ、案件ページ、顧客ページ、論点ページを作ります。
たとえば、1つの過去案件に対して、次のようなページを作ります。
| ページ | 内容 |
|---|---|
| 案件ページ | 顧客、業種、期間、スコープ、成果物、体制、結果 |
| 顧客ページ | 顧客概要、過去接点、主要テーマ、注意点 |
| 業界論点ページ | 業界共通課題、提案で使える論点、規制や市場変化 |
| 成果物ページ | 提案書、報告書、テンプレート、再利用可否 |
| 人・経験ページ | 誰がどの案件を経験したか、どのテーマに詳しいか |
これらは、SharePointやConfluenceのような人間向けWikiでもよいですし、ナレッジDBや検索インデックス上に作る形でも構いません。
重要なのは、AIが使いやすい単位で知識を切り出すことです。
なぜRAGだけでは足りないのか
RAGは、質問に関連する情報を探し、その情報をAIに渡して回答させる仕組みです。
しかし、RAGは魔法ではありません。
検索対象が散らかっていれば、回答も散らかります。
たとえば、過去案件の資料に次のような問題があるとします。
- 顧客名の表記が統一されていない
- 案件名が正式名、略称、社内呼称で混在している
- 業種や規模が資料本文に明記されていない
- スコープが提案書の各所に分散している
- 最終的な成果や失敗要因が振り返り資料にしかない
- メンバー情報が体制表にしかない
- 機密情報がそのまま残っている
この状態で「似た案件を探して」と聞いても、AIは十分な判断材料を持てません。
RAGの前に、資料をAIが使える知識単位へ変換する必要があります。
その変換層がLLM Wikiです。
LLM Wikiが解決すること
LLM Wikiは、社内ナレッジ活用の問題をいくつかに分けて解決します。
| 問題 | LLM Wikiでの解決 |
|---|---|
| 資料が多すぎる | 案件ページや論点ページに要約する |
| 表記がばらばら | 顧客名、業種、スコープを標準化する |
| 資料に埋もれている | 重要情報をメタデータとして抽出する |
| 機密情報が混ざる | マスキング済み版や閲覧権限を分ける |
| 根拠が見えない | 元資料へのリンクを残す |
| 再利用しにくい | 提案論点、成果物、注意点として整理する |
| 誰が詳しいかわからない | 経験者や関係メンバーを紐づける |
つまりLLM Wikiは、単なる要約集ではありません。
過去資料を、AIが検索し、人間が確認し、現場が再利用できる社内知識に変える仕組みです。
LLMでメタデータを作る
LLM Wikiの大きな利点は、メタデータ作成をLLMで支援できることです。
人間がすべての過去案件に対して、顧客、業種、期間、スコープ、成果物、体制、論点を手入力するのは現実的ではありません。
しかしLLMを使えば、提案書や報告書から下書きを作れます。
たとえば、次のような情報を抽出できます。
| メタデータ | 抽出の考え方 |
|---|---|
| 顧客名 | 資料内の正式名称、略称を抽出 |
| 業種 | 資料本文や顧客説明から分類 |
| 案件期間 | 日付、フェーズ、スケジュール表から抽出 |
| スコープ | 提案範囲、作業範囲、成果物から整理 |
| 成果物 | 提案書、報告書、ロードマップ、業務フローなど |
| 体制 | PM、担当者、専門家、顧客側メンバー |
| 顧客課題 | 背景、課題、目的から要約 |
| 再利用論点 | 次の提案で使える示唆を抽出 |
| 注意点 | 制約、失敗要因、リスクを整理 |
ただし、LLMに完全自動で確定させるべきではありません。
実務では、LLMが下書きを作り、人間が確認して確定する形が現実的です。
特に、顧客名、金額、契約範囲、プロジェクト結果、メンバー名は、誤ると影響が大きい情報です。
LLMは入力担当者ではなく、下書き担当者として使うべきです。
LLMでマスキングする
社内ナレッジを広く使うには、機密情報の扱いも避けて通れません。
過去案件資料には、顧客名、個人名、単価、契約条件、未公開情報、顧客固有の事情が含まれます。
このまま全社検索にかけるのは危険です。
LLM Wikiでは、元資料とは別に、マスキング済みの知識ページを作る考え方が有効です。
たとえば、次のように置き換えます。
| 元の情報 | Wiki上の表現 |
|---|---|
| 株式会社ABC | 国内大手製造業A社 |
| 山田太郎 | 担当PM |
| 単価120万円 | 単価情報は非公開 |
| ERP刷新の失敗 | 基幹システム刷新における移行リスク |
| 特定工場名 | 国内主要拠点 |
ここでも、LLMは候補抽出に向いています。
ただし、マスキングも完全自動にはしないほうがよいです。
メールアドレス、電話番号、ID、住所のようなものはルール処理が向いています。顧客固有事情や再識別リスクは、LLMと人間レビューを組み合わせる必要があります。
LLM Wikiの基本構造
LLM Wikiは、ページを作れば終わりではありません。
使える知識基盤にするには、最低限次の構造が必要です。
| 要素 | 役割 |
|---|---|
| 元資料 | 提案書、報告書、議事録、体制表などの根拠 |
| Wikiページ | AIと人間が読みやすい要約・整理ページ |
| メタデータ | 顧客、業種、規模、期間、スコープ、成果物など |
| 権限 | 誰がどの情報を見てよいか |
| マスキング | 機密情報を用途に応じて伏せる |
| 根拠リンク | Wikiページから元資料へ戻れる導線 |
| レビュー状態 | LLM生成、確認済み、公開可、要修正など |
| 更新日 | 情報の鮮度を判断するための項目 |
この構造があると、RAGはただの全文検索ではなくなります。
「製造業」「3か月以内」「構想策定」「AI活用」「再利用可能な成果物あり」といった条件で絞り込み、そのうえでAIに回答させることができます。
どのような質問に強くなるか
LLM Wikiがあると、ユーザーは次のような聞き方ができます。
金融業向けのAI活用案件で、初期構想フェーズだけを対象にした事例を探して。顧客名は伏せて、提案に使える論点と注意点を整理して。
この質問には、検索、権限、マスキング、要約がすべて含まれています。
通常のファイル検索だけでは難しいですが、LLM Wikiがあれば処理しやすくなります。
AIはまず、メタデータで対象案件を絞ります。
次に、関連するWikiページを読みます。
そのうえで、必要なら元資料への根拠リンクを示します。
最後に、顧客名を伏せた形で、提案に使える論点を整理します。
これが、社内ナレッジ活用として目指したい体験です。
作り方は小さく始める
LLM Wikiは、最初から全社規模で作る必要はありません。
むしろ、最初は小さく始めるべきです。
おすすめは、次の順番です。
- 対象テーマを1つ選ぶ
- 過去案件を20件程度集める
- 各案件の元資料を整理する
- LLMで案件ページの下書きを作る
- メタデータを抽出する
- 機密情報のマスキング候補を作る
- シニアメンバーがレビューする
- RAGで検索・回答できるようにする
- 実際の提案活動で使う
この小さな単位で検証すると、どのメタデータが本当に必要か、どの資料が役に立つか、どこで人間レビューが必要かが見えてきます。
管理職・経営層が見るべきポイント
LLM Wikiは、単なるAIツール導入ではありません。
会社の過去資産を、再利用できる形に変える取り組みです。
管理職や経営層が見るべきポイントは、技術選定だけではありません。
- どの知識を会社の資産として残すのか
- 誰が知識の品質に責任を持つのか
- どの情報は全社共有し、どの情報は制限するのか
- 顧客名や機密情報をどうマスキングするのか
- LLM生成の下書きを誰が承認するのか
- 現場がナレッジ登録を続けられる運用にできるか
- 提案活動やデリバリー品質にどのように効かせるのか
特に重要なのは、LLM Wikiを「資料置き場」にしないことです。
資料を集めるだけでは、過去資産は使える知識になりません。
案件、顧客、業界、成果物、人、論点をつなげて初めて、AIが実務で使える知識として呼び出せるようになります。
補足: Karpathyについて
Andrej Karpathyは、現代のAI実装やAI教育に大きな影響を与えてきた研究者・エンジニアです。
OpenAIの創業メンバーの一人であり、その後TeslaでAI部門を率いてAutopilotのコンピュータビジョン領域に関わりました。2024年にはAI教育に取り組むEureka Labsを立ち上げ、2026年にはAnthropicに参加しています。
Karpathyの発信が注目されるのは、最先端のAI研究だけでなく、LLMを実際の開発、学習、知識管理にどう使うかを、非常に実務的な形で言語化しているからです。
LLM Wikiの考え方もその延長にあります。単なる検索ツールではなく、LLMに知識を読み、整理し、更新し、再利用できる形に育てさせる。その発想を企業内ナレッジに応用すると、過去案件や成果物の扱い方も大きく変わります。
まとめ
RAGは、社内の過去資産を呼び出すための重要な仕組みです。
しかし、RAGの品質は、検索対象となる知識の品質に大きく左右されます。
散らかった資料をそのまま検索させても、安定した回答は得られません。
LLM Wikiは、過去資料をAIが扱いやすい知識単位に変換するための中間層です。
LLMでメタデータを下書きし、マスキング候補を作り、人間が確認し、元資料への根拠リンクを残す。
この流れを作ることで、社内の過去資産は「探せないファイル」から「呼び出せる知識」に変わります。
RAGを成功させるには、まずAIに読ませる社内知識を整える必要があります。
そのための現実的な方法が、LLM Wikiです。
© 2026 Keith Chen. All rights reserved.