LLM Wikiの保守：ドリフト、矛盾、およびレビュー
コンパイルされた知識の信頼性を確保する
LLMウィキは、古い事実が依然として妥当に見えるようになり、矛盾が磨き上げられ、生成された要約が元々の情報源から逸脱した際に失敗します。
コンパイルされた知識システムの真の製品は、保守です。何ヶ月もの取り込み、編集、書き直し、および新しい情報源にわたってそれらを信頼できる状態に保つことに比べると、ウィキページを作成することは straightforward（簡単）です。
この記事では、LLMウィキシステムの運用面、すなわちドリフトの検出、矛盾チェック、出典の規律、リンティング、Gitレビュー、および保守ワークフローについて説明します。LLM Wiki - RAGでは置き換えられないコンパイルされた知識で説明されている基本的なパターン、つまり生データの情報源が後で人間やエージェントがクエリできるよう耐久性のあるMarkdownページにコンパイルされるという前提に立てています。静謐だが意見のある見解としては、保守のないLLMウィキは、単に見栄えの良い知識の墓場であるにすぎません。
LLMウィキの保守が異なる理由
従来のウィキは、人々が更新を止めるために腐敗します。RAGシステムは、コーパスが変化し、チャンクが古くなり、メタデータが弱くなり、検索が妥当だが古くなったフラグメントを常に発見するためにドリフトします。より深い理由は、検索と表現は異なる問題を解決するという点にあります。検索は新鮮なデータに対して再実行できますが、すでにコンパイルした表現は、積極的に誠実さを保たなければなりません。
LLMウィキは異なる失敗モードを持っています。それが間違っているときでさえ、きれいに見える可能性があります。
ページはフォーマットが整っているかもしれません。リンクは機能しているかもしれません。要約はバランスが取れているように聞こえるかもしれません。しかし、その整った表面の下で、システムは重要な事実を落とし、互換性のない概念をマージし、情報源ではなく要約を引用し、依然として適用されるかのように古い決定を保持している可能性があります。
そのため、LLMウィキの保守は構造と意味の両方をチェックする必要があります。
保守の目標
目標は、すべてのページを完璧にすることではありません。それは高すぎるコストであり、通常は放棄されたシステムにつながります。
目標は、ウィキを有用で、検査可能で、回復可能な状態に保つことです。
保守されたLLMウィキは、これらの質問に答えることを容易にするはずです。
- この主張を支持する情報源は何ですか？
- このページはいつ最後にレビューされましたか？
- この概念は変更されましたか？
- 矛盾するページはありますか？
- この要約は依然として最新ですか？
- エージェントは必要以上に書き直しをしましたか？
- 悪い更新をロールバックできますか？
- 人間は、ページがなぜそのように言っているのか理解できますか？
答えが「いいえ」である場合、問題はコンテンツの品質だけではありません。それはシステム設計の問題です。
シンプルな保守ループ
有用なLLMウィキには、反復可能なループが必要です。ループは、頻繁に実行できるほどシンプルで、目に見えなくなる前にドリフトを捕捉できるほど厳格であるべきです。
このループは華やかではありません。それがポイントです。
知識システムは、退屈な保守を通じて耐久性を得ます。情報源の保存、明示的なレビュー、予測可能な構造、そして小さく安全な更新。同じ直感が常緑ノートを駆動します。ノートやウィキページは、最初の草稿の後に腐敗させるのではなく、誰かが継続的に洗練し続ける場合にのみ価値を複利で増やします。
LLMウィキにおけるドリフトの種類
知識ドリフトは一つではありません。異なるドリフトタイプには異なるチェックが必要です。良い保守システムは、それらを明確に命名するべきです。
情報源ドリフト
情報源ドリフトは、基礎となる情報源資料が変更されたときに発生します。
例えば、ツールが新しいバージョンをリリースし、ポリシーが更新され、APIが変更され、またはベンダーが古い機能を非推奨にした場合。古いウィキページは以前のバージョンに対しては依然として正確かもしれませんが、現在の使用法に対しては間違っています。
情報源ドリフトは危険です。なぜなら、古い主張は歴史的な文脈では依然として真実である可能性があるからです。問題は、その主張が偽物であることではありません。問題は、それが現在の質問に答えなくなっていることです。
保守対応:
- 情報源の日付を記録する
- 最終レビュー日付を記録する
- バージョン固有のページを明確にマークする
- 古いページを差し替えるページにリンクする
- ラベルなしで新旧のバージョンを混同しない
概念ドリフト
概念ドリフトは、用語の意味が時間とともに変化するときに発生します。
これはAIやソフトウェアアーキテクチャで一般的です。「エージェント」、「メモリ」、「RAG」、「ワークフロー」、「ツール使用」、「構造化出力」、「コンテキストエンジニアリング」といった用語は、意味を急速に変えることがあります。
ウィキは、違いを説明せずに、同じ用語の複数の意味を偶然にも保持してしまうことがあります。それにより、一貫して聞こえるが互換性のないアイデアを組み合わせた混乱するページが作成されます。
保守対応:
- 用語集ページを維持する
- 「このウィキにおける意味」セクションを追加する
- 過負荷な概念を個別のページに分離する
- 関連する意味を明確にリンクする
- モデルが沈黙して用語をマージしないようにする
用語ドリフト
用語ドリフトは概念ドリフトよりも小さく、但仍然して有害です。
それは、ウィキが同じものに複数の名前を使用するときに発生します。「LLMウィキ」、「コンパイルされた知識ベース」、「AI保守ウィキ」、「エージェント保守ウィキ」、「Markdown知識ベース」など。
ある程度のばらつきは問題ありません。しかし、あまりにも多くのばらつきは、検索、リンク、レビューを破壊します。
保守対応:
- 標準的なページ名を定義する
- エイリアスをフロントマターまたはページメタデータに保持する
- 重複ページをリダイレクトする
- 近似重複タイトルをリンティングする
- 内部リンクで一貫したアンカーテキストを使用する
決定ドリフト
決定ドリフトは、過去の決定が文書化され続けていますが、現在のプラクティスを反映しなくなったときに発生します。
例えば、プロジェクトがすべてのドキュメント検索にベクトルRAGを使用すると述べるページがあり、一方で新しいページはLLMウィキワークフローを記述している場合。両方の声明は歴史的に真実かもしれませんが、ウィキはどちらが現在のものであるかを示す必要があります。
これはアーキテクチャノート、エンジニアリングプロセス、コンテンツ戦略、および内部ツールに重要です。同じ規律がAI駆動開発における決定記録に適用されます。決定ページは、差し替えられた選択肢が沈黙して上書きされるのではなく、差し替えられたとしてマークされている場合にのみ信頼できます。
保守対応:
- 決定を提案中、承認済み、差し替え済み、または却下済みとしてマークする
- 決定日付を保持する
- 差し替えられた決定を代替品にリンクする
- 歴史的な文脈を保存する
- 痕跡を残さずに古い決定を削除しない
引用ドリフト
引用ドリフトは、ページが情報源を引用しているが、主張が情報源が述べているものと一致しなくなったときに発生します。
これは書き直しの後に起こる可能性があります。引用はそのまま残りますが、それを取り巻く文が変更されます。ページは依然として情報源があるように見えますが、引用はもはや主張を支持していません。
これは、誤った自信を生み出すため、最も深刻なLLMウィキの失敗モードの一つです。
保守対応:
- 主張レベルの引用サポートをチェックする
- 要約のみを引用しない
- 生データの情報源を保持する
- 重要な主張には引用を必須とする
- 情報源があるが直接的なサポートがない段落にフラグを付ける
- Git差分で引用の変更をレビューする
構造ドリフト
構造ドリフトは、ウィキがゆっくりとナビゲーション性を失うときに発生します。
古いページを更新する代わりに新しいページが作成されます。インデックスページが遅れます。重複ページが出現します。孤立ページが蓄積されます。関連ページが互いにリンクしなくなります。
ウィキは依然として有用な知識を含んでいますが、それを見つけて信頼することが難しくなります。
保守対応:
- 孤立ページをリンティングする
- インデックスページを維持する
- 重複トピックを検出する
- 標準的なページにはバックリンクを必須とする
- 散らばるのではなくアーカイブする
- フォルダの役割を明確にする
核心的な保守ファイル
LLMウィキは、メモリ、雰囲気、または反復的なプロンプトに依存すべきではありません。人間やエージェントにそれをどのように保守するかを伝えるための運用ファイルが必要です。
実用的な構造は次のようになる可能性があります。
llm-wiki/
raw/
sources/
transcripts/
documents/
wiki/
index.md
concepts/
entities/
projects/
decisions/
maintenance/
review-log.md
lint-report.md
stale-pages.md
contradiction-report.md
rules/
AGENTS.md
schema.md
style-guide.md
citation-policy.md
source-policy.md
正確な名前はどうでもよいです。重要なのは役割です。
ウィキには、情報源の保存、コンパイルされたページ、レビューアーティファクト、およびセッションを超えて存続するルールが必要です。
AGENTS.md
AGENTS.mdは、エージェントがどのように動作することを許可されているかを説明するべきです。
次のような質問に答えるべきです。
- エージェントは新しいページを作成する前に既存のページを更新するべきですか？
- いつレビューを依頼するべきですか？
- どのように情報源を引用するべきですか？
- フォルダを再編成できますか？
- 古いページを書き直すことができますか？
- 矛盾に対して何をすべきですか？
- 決して削除してはいけないものは何ですか？
有用なルールは次の通りです。
広範な書き直しではなく、情報源に基づく小さな更新を優先する。
この一文は、多くの悪い保守習慣を防ぎます。また、エージェントメモリに対する有用な境界線を引きます。メモリはエージェントがその瞬間にどのように振る舞うかを形成しますが、ウィキのルールファイルは、エージェントが共有知識ベースで変更することを許可されているものを形成します。
schema.md
schema.mdは、ページ構造を定義するべきです。
例えば：
# ページタイトル
## 要約
短く、現在の要約。
## 主要な主張
- 情報源参照付きの主張。
- 情報源参照付きの主張。
## 現在のステータス
現在、歴史的、差し替え済み、ドラフト、または不確実。
## 詳細
主要なコンパイルされた説明。
## 関連ページ
内部リンク。
## 情報源
生データの情報源参照。
## レビューノート
最終レビュー日付とレビュアー。
スキーマは厳格である必要はありません。しかし、スキーマなしでは、ウィキは一貫性のないエッセイの山になります。スキーマは、エージェントが保持するべきものを提供します。
citation-policy.md
引用ポリシーは、何が情報源を必要とするかを言うべきです。最低限、次のものには引用を必須とします。
- 技術的な主張
- 比較
- 製品の動作
- バージョン固有の声明
- ベンチマーク結果
- 価格
- 法的またはコンプライアンスに関する主張
- 現在のステータスに関する主張
- 情報源からコピーまたは派生した主張
良い引用ポリシーは、何をすべきでないかも言います。コンパイルされたページを元の情報源であるかのように引用しないでください。それらが支持していない段落に引用を添付しないでください。主張を書き直した後、情報源が依然としてそれを支持しない限り、引用を保持しないでください。
引用の規律は、有用なLLMウィキと装飾的な自信との違いです。
source-policy.md
情報源ポリシーは、生データの情報源がどのように保存されるかを定義するべきです。
例えば：
- 可能な限り元のファイルを保持する
- URLとアクセス日付を保存する
- コピーされたノートを生成された要約とは別に保存する
- 情報源のタイプを記録する
- 低信頼度の情報源をマークする
- 原材料を上書きしない
- 歴史的な決定を説明する際に、差し替えられた情報源を保持する
このポリシーは、ウィキを一般的な間違いから守ります。情報源を要約し、元のを破棄し、その後その要約を証拠として扱うこと。
それは知識管理ではありません。それはロス圧縮です。
LLMウィキリンターがチェックすべきこと
リンターはまず構造をチェックするべきです。構造的な問題は自動化が容易で、しばしばより深い意味的な問題を明らかにします。
有用な構造的チェックには以下が含まれます。
- 壊れた内部リンク
- 孤立ページ
- 重複タイトル
- 情報源セクションの欠落
- レビュー日付の欠落
- バックリンクのないページ
- 空またはプレースホルダーのセクション
- セクション構造のない非常に長いページ
- インデックスからのインバウンドリンクのないページ
- 一貫性のない命名規則
- 無効なフロントマター
- レビュー閾値より古い「現在」のページ
これらのチェックは、知識が真実であることを証明するものではありません。それらは、ウィキが依然として保守可能であることを証明します。それは必要な出発点です。
意味的チェック
意味的チェックは困難ですが、より価値があります。
有用な意味的チェックには以下が含まれます。
- 直接的な情報源サポートのない主張
- 互換性のない主張を行う2つのページ
- 現在として提示されている古い決定
- 異なる名前を持つ重複概念
- 複数の意味を混在させる1つの概念ページ
- 既知の制約を省略する要約
- 基準のない「最良」または「推奨」の主張
- バージョンラベルのないバージョン固有の主張
- 新しい情報源と矛盾するページ
これらのチェックは、ウィキを自動的に書き直すべきではありません。通常、レビュー用のレポートを生成するべきです。
より安全なパターンは次の通りです。
自動的に検出する。
明確に説明する。
意図的に更新する。
リスクのある変更をレビューする。
矛盾検出
矛盾検出は、LLMに2つのページが互いに矛盾しているかどうかを問うだけではありません。
それは役立ちますが、あまりにも漠然としています。より良いアプローチは、主張を比較することです。
矛盾ワークフローは次のように見える可能性があります。
これは、多くの見かけの矛盾は実際の矛盾ではないため、より良く機能します。
1つのページはバージョン1.0を記述し、もう1つはバージョン2.0を記述しているかもしれません。1つのページは個人使用を記述し、もう1つはエンタープライズ使用を記述しているかもしれません。1つのページは設計目標を記述し、もう1つは実装の現実を記述しているかもしれません。
矛盾レポートには以下を含めるべきです。
- 矛盾する主張
- 関与するページ
- 情報源参照
- 日付またはバージョンの文脈
- 可能性のある説明
- 提案された解決策
- 人間のレビューが必要かどうか
エージェントに、両方の主張を曖昧な妥協に混ぜることで沈黙して矛盾を解決させないでください。それは滑らかな無意味を生み出します。
矛盾の解決方法
矛盾を解決する有効な方法はいくつかあります。
- 1つの主張が古い場合、それを差し替え済みとしてマークし、新しいページにリンクする。
- 両方の主張が異なる文脈で真実である場合、文脈を明確に分離する。
- 情報源が一致しない場合、不一致を保持し、それを説明する。
- ウィキページが主張を発明したり過般化したりした場合、主張を削除または狭める。
- 矛盾が実際に未解決の決定を反映している場合、決定ページを作成または更新する。
目標は、すべての緊張を除去することではありません。ある程度の緊張は有用です。良いウィキは、知識が確立されている場所と、依然として不確実な場所を示します。
古いページレビュー
すべてのコンパイルされたページには、レビューステータスが必要です。
シンプルなメタデータブロックで十分です。
status: current
last_reviewed: 2026-07-10
review_after: 2026-10-10
source_confidence: medium
急速に変化するトピックには、短いレビューウィンドウを使用します。安定した概念には、長いウィンドウを使用します。
| ページタイプ | レビュー間隔 |
|---|---|
| ツールバージョンページ | 30〜90日 |
| 価格または利用可能性ページ | 7〜30日 |
| アーキテクチャ原則 | 6〜18ヶ月 |
| 歴史的決定記録 | 差し替えられた場合のみ |
| 用語集ページ | 3〜12ヶ月 |
| 情報源要約 | 情報源が変更されたとき |
| 比較ページ | 30〜180日 |
間隔よりも重要なのは習慣です。レビュー日付のないページは、やがて静かに嘘をつくページになります。
情報源認識の更新
新しい情報源が届いたとき、エージェントは単に新しい要約ページを書くべきではありません。
それは問うべきです。
- これは既存の概念を更新しますか？
- それは前の情報源を差し替えますか？
- それは既存のページと矛盾しますか？
- それは新しいエンティティまたは用語を追加しますか？
- それは推奨事項を変更しますか？
- それはインデックスの更新を必要としますか？
- それは決定ページに影響しますか？
良い取り込みワークフローは、孤立した要約のスタックとしてではなく、グラフとしてウィキを更新します。
そのため、1つの情報源が多くのページに触れることがあります。それは普通です。保守の課題は、それらの更新を小さく、レビュー可能で、追跡可能なものにするこ
