【社内チャットボット フィードバック 改善】回答精度90%超へ。ユーザーの声（ログ）を「学習データ」に変えるPDCAの回し方

なぜ「フィードバック」が最強の学習データなのか

生成AI（RAG型）におけるフィードバックは、単なる「感想」ではありません。
AIの回答に対する「Good（正解）/ Bad（不正解）」の判定データは、検索アルゴリズムの精度を測るための「正解ラベル（アノテーション）」そのものです。
Good: その質問に対し、参照したマニュアルが正しかったという証明。

Bad: 参照したマニュアルが間違っていた、あるいは情報が古かったという警告。

このシグナルを無視することは、AIの成長機会を捨てているのと同じです。DX担当者は、フィードバックを「システムチューニングのための重要指標」と捉え直す必要があります。

技術的根拠：インフラ品質のAIはどう「改善」しているか（阪急電鉄事例）

「フィードバックをどう分析すればいいのか？」
そのヒントとなるのが、阪急電鉄様での運用事例です。

ログ分析による「サイレント・クレーム」の解消

鉄道の案内AIでは、利用者が「期待した回答が得られなかった場合」、何も言わずに離脱することが多々あります。
阪急電鉄様では、明示的なフィードバックだけでなく、「再質問（言い直し）」のログも分析対象としています。
「鉄道特有の内容をご案内する必要がありましたが、貴社のノウハウを活かしてスムーズに対応していただけたと感じています」
例えば、「定期券 払い戻し」で回答が出ず、直後に「定期 解約」と入力し直しているログがあれば、「『払い戻し』と『解約』を同義語として辞書登録する必要がある」という改善点が明確になります。
このように、ユーザーの挙動（ログ）すべてをフィードバックとして扱い、辞書やデータを更新し続けることで、インフラ品質の回答精度を維持しているのです。

【実践編】質の高いフィードバックを集める3つのUI設計

ユーザーに負担をかけず、かつ分析に使えるデータを集めるためのUI設計です。
「役に立ちましたか？」ボタン（Good/Bad）

回答の直下に配置。1タップで済むようにし、Badの場合のみ「回答が間違っている」「古い」「長い」などの選択肢を表示します。

フリーコメント欄の設置

Bad評価時、「正解はこちら（URL）」などをユーザー（詳しい社員）に入力してもらうことで、ナレッジの修正ソースとして活用します。

セッション終了後のNPS（推奨度）計測

一連の会話が終わった後に「解決しましたか？」と聞き、解決率（解決数 / 全セッション数）をKPIとして計測します。

改善の道筋：集めた声（ログ）をRAGに反映するアクションプラン

収集したデータを元に、実際にAIをチューニングする手順です。

① 「Bad評価」のトリガー分析

Badがついた回答の「参照元ドキュメント（Source）」を確認します。
原因A: 参照元のマニュアル自体が古かった。

→ 対策: 最新のPDFに差し替える。

原因B: 参照元は合っているが、AIの要約が下手だった。

→ 対策: システムプロンプトを修正し、「箇条書きで答えて」などの指示を追加する。

② 「0件ヒット」のナレッジ追加

「回答できませんでした（No Match）」のログは、社内にナレッジが存在しない（AIに教えていない）ことを意味します。
対策: 該当するFAQやマニュアルを新規作成し、RAGデータベースに追加（学習）させます。これが最も直接的に解決率を上げます。

③ プロンプト（指示文）の微調整

「回答が長すぎる」「口調が冷たい」といった定性的なフィードバックに対しては、システムプロンプト（AIへの役割指示）を調整します。
対策: 「あなたは親切な社内ヘルプデスクです。専門用語を使わず、中学生でも分かるように300文字以内で回答してください」といった具体的な制約を加えます。

まとめ：AIは「運用」で完成する

社内チャットボットの導入はゴールではなく、「全社員でAIを育てるプロジェクト」のスタートです。
フィードバック機能は、現場の社員がDXに参加するための「投票箱」です。
阪急電鉄様の事例のように、ユーザーの声（ログ）を真摯に分析し、週次・月次でデータを更新し続けること。この地道なPDCAサイクルこそが、回答精度90%超えを実現する唯一の近道です。
まずは、管理画面から「先週のBad評価ログ」をダウンロードし、その原因を1つ特定することから始めてみませんか？
▼【DX・AI推進担当向け】チャットボット改善・分析ガイド