FAQ運用を自走化する：問い合わせログからNotionナレッジを更新するRAGワークフロー【2026年版】

## 結論 サポート品質を上げる最短ルートは、担当者教育より先に**FAQ更新フローを固定化すること**です。 本記事では、問い合わせログを毎日集約し、Notion FAQを更新候補として提案するRAGワークフローを解説します。 ## 目的 - 回答の品質差を減らす - 同じ質問への再回答工数を削減する - 新人でも同じ基準で対応できる状態を作る ## システム構成 1. 問い合わせログ（Gmail / フォーム）を日次集計 2. 類似質問クラスタを作成 3. 既存FAQとの差分を判定 4. 追加/更新候補をNotion DBへ提案 5. 承認後に公開FAQへ反映 ## 実装ポイント ### 1. 類似度しきい値を固定しない 季節要因で質問内容は変わるため、週次で閾値を調整します。 ### 2. FAQは「結論先出し」で保存 RAG参照時に短く返せるよう、先頭2文で答え切る形式に統一します。 ### 3. 参照元ログURLを必ず保持 誤回答時に追跡できるよう、根拠リンクを残します。 ## 失敗パターン 1. FAQを増やしすぎて検索性が低下 2. 廃止情報が残り、逆に誤案内が増える 3. 承認フローがないまま自動公開してしまう ## 運用設計（最小） - 日次: 候補生成（自動） - 週次: 承認会（15分） - 月次: 廃止FAQの棚卸し ## KPI - 同一質問の再発率 - 初回解決率 - 平均対応時間 ## FAQ ### Q1. RAGは大規模データが必要？ 不要です。FAQ50〜200件でも運用効果は十分出ます。 ### Q2. まず何を整えるべき？ FAQの書式統一です。構造化されていないと参照精度が落ちます。 ### Q3. 完全自動更新は可能？ 技術的には可能ですが、誤更新リスクが高いため承認ステップを推奨します。 ## 更新履歴 - 2026-04-02: 初版公開