LLM Wikiは、一次情報から「編集済みの知識層」を継続的に育てていくためのアーキテクチャです。
しかし、明確な更新ルールを設けずにLLMエージェントによる自動更新を繰り返すと、出典の消失や記述の矛盾、再帰的要約劣化が起こりやすくなります。

本記事では、Markdown + Git 構成での個人運用から小規模チーム運用を前提に、Ingest・Lint・Repair の責務分離と、GitHub Actions で回す最小限の保守CIを整理します。

この記事の前提

Markdown + Git で管理する
raw/ は一次ソース置き場とする（不変）
Repair では本文の事実関係と意味内容を変更しない
GitHub Actions を利用して保守を自動化する

放置されたWikiが壊れる3つのパターン

LLMにWikiの更新を任せきりにすると、運用の途中で次のような破綻パターンが起きやすくなります。

鮮度の低下（Staleness）
症状：ページ間で更新日時がずれ、同一概念の説明がシステム内で矛盾し始めます。
古い情報を自動でアーカイブする仕組みがない場合、人間が気付くか、Lintによって矛盾を炙り出す必要があります。
出典の喪失と再帰的要約劣化
症状：一次ソースへのリンクが失われ、元の文書にあった例外条件や細部が欠落します。
AIが「過去に自身が生成したWikiページ」だけを根拠に要約と推敲を繰り返すことで進行し、最終的に記述の監査が不可能になります。
スケール時の処理限界（経験則）
症状：フルコンテキスト前提で運用すると、ページ数が増えるにつれて処理時間とAPIコストが急に重くなりやすくなります。
Claude CodeなどのLLMエージェントを利用する場合、ページ数が100〜200件を超えたあたりから、処理時間とコストの負担が目に見えて増えやすくなります。
少なくともフルコンテキスト前提の運用では、この規模から分割や局所処理を検討した方が回しやすくなります。

Lintで最低限チェックすべき項目と実装上の注意

Lintは、Wiki内のMarkdownファイルが運用ルールに準拠しているかを自動検査します。
実務では以下の項目をチェックしますが、実装上は誤検知（False Positive）への対策が不可欠です。

運用上の仕様：FAILとWARNの定義
本記事では、FAIL は CI を失敗させて merge を止める判定、WARN は差分レポートやPRコメントで人間レビューを促す判定として扱います。

検査項目	判定	運用の具体例	実装上の注意（地雷処理）
インライン出典の欠落	FAIL	断定文の末尾に `(raw/...#anchor)` が存在するかを必須とする。	初期段階では単純ルール優先（見出し末尾やリスト要素など）、誤検知が多い箇所だけLLM補助判定を挟む。
リンク切れ	FAIL	パスが存在するか、対象ファイル内に該当アンカーが存在するかを検証する。	パーサーによってslug生成ルール（空白の扱い等）が異なるため、ローカルの生成ルールを固定して実装する。
事実の乖離	WARN	数値・日付・固有名詞を一次ソース（`raw/`）と照合する。	自動修正は厳禁。ドリフト検知用として人間向けの差分レポート（Diff）を出力するに留める。
情報の陳腐化	WARN	`updated_at` を監視し、一定期間更新がないページを警告する。	技術タグ（30日）、基礎概念（180日）など、Frontmatterのタグやディレクトリ単位で閾値を変える。

Repairの境界条件：運用メタデータは更新可、ドメイン知識は追加不可

Lintの指摘を修復する「Repair」プロセスでは、「ドメイン知識（新しい事実）」を絶対に追加しないという原則をLLMに課します。

🟢 許可される変更（運用メタデータ・フォーマットの正常化）

updated_at の更新やFrontmatterのキー補完は、知識の追加ではなく「運用上の保守」として許可します。

# 許可：Frontmatterの補完やリンク形式の統一
---
title: RAGの基礎
+ updated_at: 2026-04-27
+ status: draft
---
- 詳細は [RAG要件](raw/rag_req.md) を参照。
+ 詳細は [RAG要件](raw/rag_req.md#L10) を参照。(行数アンカーの補完)

🔴 禁止される変更（ドメイン知識への介入）

出典がない箇所へのもっともらしい補足や、数値の推定、矛盾する記述の勝手なマージは禁止します。これらは必ず一次ソースを参照する「Ingest」側の責務です。

# 禁止：出典のない補足・丸め込みによる事実の改変
- RAGのレイテンシは実測で約3.5秒だった。(raw/log_2026.md#L10)
+ RAGのレイテンシは約4秒であり、実用にはキャッシュが必要である。

実装設計：GitHub Actionsを用いた最小のCI運用例

ページ数が増加した際のコストを抑えつつ、監査性を担保するためのCI/CD構成案です。

イベント駆動の局所Lint: PR時は、変更されたファイルと隣接リンク先（変更ファイルから1ホップ以内の内部リンク先）のみを走査する。
週次バッチの全件Lint: API課金が重い事実乖離チェック等は週次バッチで実行する。手動実行も可能にする。
Repairは自動PRまで: Repairによる修正は直接コミットせず、人間がマージ承認する。
競合の局所化: 矛盾が出た場合はセクション単位で警告ブロック（> [!warning]）を付与する。

.github/workflows/llm-wiki-ci.yml の実装例:

GitHub Actions の schedule は時刻解釈で混乱しやすいので、以下のように timezone を明示して実装します。また、raw/ の追加や scripts/ の変更時にも正しくLintが回るよう paths を指定します。
※ repair.py --create-pr は、内部で GitHub CLI（gh pr create）や GitHub API を呼び出してPRを作成する想定のため、ワークフローに permissions を明記しています。
※ この例は最小構成であり、Secrets と実行権限の管理は各リポジトリ方針に合わせて設定してください。

name: LLM Wiki CI

on:
  pull_request:
    paths:
      - 'wiki/**/*.md'
      - 'raw/**/*.md'
      - 'scripts/**'
  schedule:
    - cron: '0 11 * * 0'
      timezone: 'Asia/Tokyo'
  workflow_dispatch: # 手動実行のトリガー

permissions:
  contents: write
  pull-requests: write

jobs:
  lint-and-repair:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: PR時の局所Lint (Changed files & adjacent only)
        if: github.event_name == 'pull_request'
        run: ./scripts/lint.py --target changed_and_adjacent

      - name: 週次・手動の全件Lintと自動Repair PRの作成
        if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
        run: |
          ./scripts/lint.py --target all
          ./scripts/repair.py --create-pr
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}

まとめ

LLM Wiki を壊れにくくする最低限のルールは 3 つです。

raw/ は不変にする。
Repair では本文の知識を足さない。
重い検査は PR 時の局所Lint と週次バッチに分ける。

この3つを守るだけでも、保守の自動化と、人間による監査性・最終判断の両立はかなりしやすくなります。

この記事を書いた人✏️@YushiYamamoto
株式会社プロドウガ CEO / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。