社内ナレッジをRAGで形式知化したいときは、まず検索精度より運用設計を先に決めた方が失敗しにくいです。2026年8月時点のMicrosoft Learnでは、agentic retrieval で引用追跡や query activity log を使い、必要なチャンクだけを返す考え方が整理されています。つまり実務で重要なのは、文書を入れること自体ではなく、『どの質問に、どの根拠を添えて、誰が更新するか』を再現できる状態にすることです。
Google Cloud でも Agent Platform 上の RAG Engine と Vector Search を、私有データを安全につなぎ回答精度を高める要素として位置付けています。RAG を導入しても現場に定着しないケースの多くは、埋め込みモデルやベクトルDBの選定ミスより、対象業務が広すぎる、原本が古い、質問ログが残らない、出典表示が曖昧という運用面の欠陥です。
RAGで形式知化するとき最初に決める3つの対象
最初から全社文書を一括投入しない方が安全です。優先すべきは、1) 同じ質問が繰り返し発生する業務、2) 原本と更新責任者が明確な文書、3) 根拠表示が求められる領域の3つです。たとえば情シスFAQ、就業規則、見積や提案の定型文、監査対応の手順書のように、質問頻度と責任範囲が見えやすい領域から始めると、回答品質だけでなく運用の合意形成も進めやすくなります。
質問ログを集めると検索設計より早く精度が上がる
RAG の改善で効きやすいのは、追加学習よりも質問ログの整備です。最低でも『質問文』『参照した出典』『返答の成否』『有人修正の有無』『未回答だった理由』を残してください。Microsoft が示す query activity log の発想と同じで、どんな検索が走り、どのチャンクが使われたかを見える化すると、曖昧クエリや不足文書がすぐ分かります。20件から50件でも代表質問セットを作れば、毎週の改善サイクルを回せます。
更新フローは『誰が直すか』まで決めて初めて回る
更新設計は『何日おきに再学習するか』より『誰が差分を取り込むか』を先に決めるべきです。Microsoft Learn の update strategies でも、定期更新だけでなく trigger-based updates で変更箇所だけ再インデックスする考え方が示されています。実務では、毎日: FAQ差分確認、毎週: 高頻度質問の反映、毎月: 古い原本の棚卸し、の3層に分けると回しやすいです。現場が原本更新、情報システムやDX推進が品質確認、部門責任者が公開範囲を判断する形にすると属人化を抑えられます。
根拠表示は『引用あり』だけでなく出典粒度が重要
根拠表示は文書名だけでは不十分です。回答に添える出典は、少なくとも文書名、更新日、該当箇所、閲覧権限の条件まで返せる形が望ましいです。Microsoft Learn でも citation tracking は provenance を示す要素として扱われています。社内利用では『正しい答えか』だけでなく『その答えを誰が信じてよいか』が重要なので、出典粒度を粗くしすぎると信頼を落とします。検索結果のスニペットだけでなく、原本への遷移や差し戻し導線もセットで設計すると現場利用が進みます.
導入前に確認したいチェックリスト
確認したいポイントは5つです。1) 対象業務が狭く定義されているか。2) 原本と更新責任者が明確か。3) 質問ログと検索ログを保存できるか。4) 引用の粒度と見せ方を決めているか。5) 権限外文書を検索から除外できるか。これらが曖昧だと、PoC では便利でも本番で回答事故や更新停止が起きやすくなります。
よくある質問
Q. まず全社ポータルを丸ごと入れるべきですか。A. いいえ。更新責任者が曖昧な文書を増やすほど古い回答が残ります。Q. どの指標を追えばよいですか。A. 正答率だけでなく、再質問率、有人エスカレーション率、根拠提示率、未回答理由の内訳を並べて見ると改善の優先順位が付きます。Q. どの程度の自動更新が必要ですか。A. 頻繁に変わる規程やFAQは trigger-based、変化が緩い規程集は週次や月次の定期更新で十分です。
社内ナレッジのRAG化を進めるなら、まずは対象業務を絞った小さな運用設計から始めるのがおすすめです。 AI・Claude研修のご相談はこちら 。
