ナレッジ運用とレビューの進め方

運用サイクル

作成/インポート → チャットで検証 → フィードバック収集 → 改善 → レビュー済み

ナレッジ更新のトリガー

ナレッジの更新は、次の 3つのトリガー から始まります。いずれも「どこを直すべきか」を具体的に指し示すため、放置による腐敗を防ぐ起点になります。

トリガー	発生する場所	誰／何から	主な更新内容
コメント	ナレッジエディター	メンバー・レビュアー（セクションコメント）	指摘されたセクションの加筆・訂正
フィードバック	チャットアプリ	利用者（👍/👎・事実誤り・情報不足の指摘、未回答質問）	誤りの訂正・不足の補足・新規ナレッジ作成
ヘルスチェック	AI エージェント	MCP `get-knowledge` の健診・🩺 自動指摘	孤立・矛盾・クロスリファレンス欠落・陳腐化の解消

内容を直して保存すると、更新日（鮮度アンカー）が進み陳腐化は解消されます。 内容を変えずに「今のままで正しい」と確認できたときだけ 「レビュー済み」 を使います（updated_at は変えず reviewed_at だけを進める）。なお「レビュー済み」は 事実誤りなどの致命的な指摘や未対応コメントを消すものではありません — それらは内容を直して対応してください。

編集そのものも健診の起点になります。 ナレッジを編集すると、次に MCP（get-knowledge）で参照されたとき、鮮度が新しくても 1 回だけ 自動でヘルスチェックが走ります（編集直後に混入しやすい矛盾・孤立を取りこぼさないため）。これにより「編集 → 健診 → 指摘 → 修正」のループが回ります。詳しくは [No.4.15 ナレッジヘルスチェック]。

ユーザーからの通報・フィードバックとオーナー対応

チャットアプリの利用者が見つけた問題は、オーナーが利用分析で受け取り対応 します。これも鮮度・品質を保つ入口です。

利用者が見つけたもの	利用者の操作	オーナーの対応（利用分析で確認）
違法・不適切なメッセージ	通報する（→ No.5.8）	内容を確認し、誤報なら通報を削除／正当ならメッセージを削除（→ No.7.3）
正しい回答が得られなかった	フィードバックする（事実誤り・情報不足・無関係。→ No.5.8）	出典ナレッジを確認し、必要な修正を行う（→ No.4.18）

オーナーは、ユーザーからのフィードバック・通報、AI エージェントのヘルスチェック結果、メンバーからのセクションコメント を起点に、ナレッジを正しく保ち鮮度を確保します。

定期レビュー

利用分析 で低採用率・陳腐化・コメント付きナレッジを確認
古ければ ナレッジエディターで内容を更新（保存すれば鮮度が更新され陳腐化も解消。回答確認 で壁打ち → No.4.2）
見直したが内容は最新で正しく、直す必要がない ときは 「レビュー済み」 で確認済みにする（陳腐化フラグを解消）

メンバーによるレビュー

メンバーにセクションコメントでフィードバックを依頼
チャットで想定質問を試してもらう
利用分析のコメントフィルタ（bucket=comments）で未対応を確認

ヘルスチェック

MCP get-knowledge やセクションコメントの 🩺 指摘で、構造上の問題を検出できます。

MCPメンテナンス

Cursor等からMCP経由でナレッジを検索・更新・リンク管理すると、効率的にメンテナンスできます。

陳腐化（stale）への対応

需要が高い（よく参照される）のに鮮度が古い（更新日・レビュー日が古い） ナレッジは、陳腐化（stale） として 利用分析 に挙がります（鮮度 × 需要 で判定）。オーナーは次のどちらかで解消します。

ナレッジを更新する — 内容が古い場合（保存で更新日が新しくなる）
「レビュー済み」にする — 内容は最新で正しいと確認できた場合

判定の詳細・見方は No.4.19、鮮度のみで拾うヘルスチェックとの違いは No.4.15 を参照してください。

要レビューの種類

種類	意味
critical	重大な問題
stale	陳腐化（長期未レビュー）
low_adoption	低採用率（候補に出るが選ばれない）
comments	コメントが付いている