AIチャットボットのログをFAQ更新に戻せているか — 小さな会社の“ナレッジ反映メモ”

「ログは見ています。ただ、FAQは3か月前のままです」。AIチャットボットを置いた会社から、よく聞く話です。

答えられなかった会話に気づくところまでは進む。それでもFAQも社内資料も直らない。結局、同じ質問が毎週人に戻ってきます。

では、ログで見つけた問題を、どこに、どう戻せばいいのでしょうか。

ログを見た日に、直す先まで決まっているか

会話ログを見る作業と、ナレッジを直す作業は別物です。前者は気づきで終わります。後者は誰かの手が動いて初めて終わります。ここが切れていると、毎月ログを開いても状況が変わりません。

先行するサポート向けSaaSの公式ドキュメントを見ると、ログの扱い方が少し違います。Zendeskのautomation potential reportの説明では、AIエージェントが回答できる質問やknowledge gapsを示し、ヘルプセンター記事の作成・強化の候補につなげると書かれています。ログを読み物ではなく、更新候補の一覧として扱う考え方です。

小さな会社でも、この向きだけ真似できます。ログを開く日は、「今週どれを直すか」を1件決める日にします。

ログの見方そのものは月1回ログで見る3つのサインで扱いました。ここから先は、見つけたあとの話です。

まず4つに分ける — 未回答・古い回答・矛盾・人に戻った会話

ログの問題を全部まとめて「精度が悪い」と扱うと、直す先が決まりません。分け方は細かくしなくて大丈夫です。小さな会社なら4つで足ります。

Intercomの公式ヘルプでは、Finの改善材料としてcontent gaps、duplicates、contradictions、担当者が対応した会話（teammate-handled responses）を挙げています。呼び方は違っても、現場で拾える形にすると次の4つになります。

4つのうち、いちばん取りこぼしやすいのが最後です。人に戻った会話は「失敗」に見えるので、そのまま閉じられます。担当者が書いた説明文は、すでに現場の言葉で完成した回答文です。捨てるにはもったいない材料です。

FAQに戻す前に、会話のどこを消すか

会話ログには氏名、電話番号、契約番号、相談の中身が混ざります。そのまま社内チャットに貼る、そのまま外部のAIに投げて要約させる。この2つは避けます。

やることは単純です。FAQに戻したいのは「質問の型」だけなので、誰の話かは落とします。「◯◯様の来週の予約変更について」は、「予約変更は何日前まで可能か」に置き換えます。これで更新作業には十分です。

伏せ方の詳細は会話ログの伏せ字メモ、残す期間の決め方は保存・削除ルールにまとめています。反映メモを作る前に、ここを先に通します。

ナレッジ反映メモは5項目でいい

ここまで来たら、書くのは1行です。スプレッドシートでもメモアプリでも構いません。列を増やすほど誰も書かなくなるので、5項目に絞ります。

たとえば、こう書きます。「当日予約はできるか／未回答／FAQ『予約について』に1枚追加／店長／『今日の15時、空いていますか』」。これで、直す人が迷う余地が消えます。

Zendeskのknowledge copilot（早期アクセス段階のEAPとして案内されている機能）の説明では、content gapsや更新の必要な記事、チケットデータからの記事下書き、記事のcoverage・freshness・AI readabilityを扱うと書かれています。仕組みで支える方向は各社が進めていますが、小さな会社が先に手をつけるのは、誰が何を直すかを1行にする方です。

直したあと、テスト質問と変更履歴に戻す

メモの5項目めに再テストの質問文を入れたのは、この工程のためです。FAQを直したら、その一文をそのままチャットボットに投げます。答えが変わっていなければ、直した場所が違うか、古い資料がもう1つ残っています。

確認できたら、変更履歴に1行残します。誰が、いつ、どの資料を、なぜ直したか。この記録がないと、半年後に「なぜこの回答になっているのか」を誰も説明できません。

テスト質問の作り方は公開前のテスト質問表、履歴の残し方は変更履歴メモで扱っています。公開前に作った質問表があるなら、そこに1問足すだけで済みます。

NIST・OWASPを、小さな会社の言葉に直すと

AIの運用ルールを調べると、NISTのAI Risk Management FrameworkやGenerative AI Profile、OWASPのTop 10 for LLM Applications（2026 releaseとして公開）といった資料に行き当たります。どれも大きな枠組みで、中小企業がそのまま全部を実施する前提のものではありません。

ナレッジ更新の文脈で持ち帰るなら、3つで足ります。NISTの枠組みが繰り返し置いているのは「一度決めて終わりにせず、継続的に見直す」という姿勢です。OWASPのGen AI Security Projectが整理しているリスクのうち、更新作業に関係するのはPrompt Injectionと情報漏えいのあたりです。

ログから拾った文章を、そのまま指示文として登録しない。これが実務上いちばん近い注意点です。お客様の入力に「これまでの指示は無視して」といった文が混ざっていたとき、確認せずに登録すると、その一文もAIが読む材料になります。

PromnyAIなら、どこに戻すのか

PromnyAIでは、AI学習データにテキストやファイルで自社情報を登録します。カテゴリはサービス、ブログ、コンセプト、メンバー、その他などに分かれています。反映メモの「直す先」には、このカテゴリ名か、元になったPDF・ページ名を書きます。

チームで運用する場合は、ユーザー管理と権限設定、利用ログの画面があります。直せる人を絞ったうえで、更新が1人に偏っていないかを見る材料になります。

更新候補をAIが自動で出す、といった話ではありません。何を直すかの判断は人が持ったままです。最初は、未回答だった質問を1件だけ選び、メモの5項目を埋めて、再テストまで通してみてください。1件通ると、2件目からの手数が読めるようになります。

まとめ：ログは、次に直す1行に変える

• check_circleログを開く日は、今週直す1件を決める日にします。
• check_circle未回答、古い回答、矛盾、人に戻った会話の4つに分けます。
• check_circleメモに写す前に、誰の話かが分かる部分を落とします。
• check_circle反映メモは、質問・分類・直す先・担当・再テスト文の5項目だけにします。
• check_circle直したら同じ質問で再テストし、変更履歴に1行残して閉じます。

「ログは見ています」で止まっている会社と、FAQが毎月1枚ずつ増えている会社の差は、才能でも規模でもありません。見つけた会話を、直す先と担当が書かれた1行に変えているかどうか。小さな会社の改善は、その1行から動き出します。