05 運用と更新 — Source Watchとバッチ運用
作って終わりではない。元文書が更新された時にwikiをどう追従させ、どう活用し続けるかの運用方針。
更新の3段階と自動化の範囲
| 段階 | 自動？ | 対応 |
|---|---|---|
| SSOT元文書の更新 | —（日常作業） | 日報・決定ログを普段どおり更新 |
元文書 → raw/sources/ への再コピー |
手動 | wikiに置いたのは「コピー」なので、元を更新したら再コピーが必要 |
| raw/sources の変更 → 再ingest | 自動 | Source Watchが検出して再生成 |
⚠ 定期自動syncは未構築。テーマを継続的に育てるなら、同期スクリプト+定期実行の追加を検討する。
Source Watchの挙動
raw/sources/へのファイル追加・変更・削除を自動検出- Importボタンを押さなくてもingestが始まる（実測）
- 失敗タスクは最大3回自動リトライ
クラッシュ・エラー時の復旧
- 生成中にアプリが無言で落ちても、生成済みページは保存されている
- 再起動するとSource Watchが再開する（queueの状態は
.llm-wiki/配下で確認） - 反復失敗の大半はモデル選定の問題 → 第2章へ戻る
活用の仕方
生成したwikiは、次の3つの入り口で使う。
- チャット: アプリ内で質問 → 関連ページと出典付きで回答
- 検索: wiki内をキーワード+ベクトル検索
- 相互リンク辿り: conceptページからrelatedを辿って文脈を掴む
使い分けの再確認: 正確な原文はSSOT側（grep・意味検索）で引き、まとまった物語・語り口はllm_wikiで引く。
バッチ運用の考え方
大規模テーマは、参照頻度の高い中核を第1バッチにして検収し、活用を見てから第2バッチを判断する。運用ログ系（面談記録・日次の振り返り）は、引き出し百科の目的には合わないため対象外とするのが無難。
セットアップ記録の所在
このガイドの実運用記録（失敗15件の分析・プロバイダ切替判断・検収データ）は、プロジェクト内の決定ログに保存している。同じ問題に当たった時は、まず「思考モデルかどうか」を疑ってから原因を掘ると早い。