社内検索AIの質問ログの見方：失敗の型から資料整備の優先順位を決める
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。
結論から言うと、質問ログは「どの質問が悪かったか」ではなく「なぜ答えられなかったか」で仕分けます。仕分けの軸は、失敗の原因を資料の不足、表記ゆれ、古さ・矛盾、分かりにくい構造、権限・索引漏れ、質問側の曖昧さ、生成側の誤りに分けることです。そのうえで、同じ型の質問の件数、業務への影響、直す手間を掛け合わせて順番を決めます。モデルの入れ替えを検討するのは、資料側の型を潰したあとで構いません。 この記事では、記録すべきログ項目（個人情報への配慮を含む）と、失敗パターン別の改善バックログ分類を示します。表や依頼文の例はすべて説明用で、実際のシステムで計測した結果ではありません。
この記事の目次
見る順番は「資料にあるか→検索に出たか→回答が正しいか」
不正解の回答を見たとき、最初に「回答文が悪い」と考えると、プロンプトやモデルの調整に偏ります。次の順に確認すると、原因の切り分けが早くなります。
- その質問に答えられる資料は、そもそも社内にあるか（人が探して確認する）
- あるなら、検索結果の上位に出ていたか
- 出ていたなら、内容は最新で、他の資料と矛盾していないか
- すべて問題ないのに回答がずれたなら、生成側の問題か
MicrosoftのRAG評価フェーズの解説では、回答の根拠付けや完全性などを評価し、結果に応じてデータの追加、チャンク方法、プロンプトなどを見直す考え方が示されています。この記事の仕分けは、その評価の考え方を社内検索の運用向けに表へ落としたものです。
記録するログ項目と個人情報への配慮
後から原因を切り分けるには、回答だけでなく「何が検索されたか」まで残す必要があります。評価結果を継続的に記録する方法は、運用に合わせて決めてください。
- 基本、項目：ログID、日時、目的・注意点：追跡用
- 質問、項目：質問原文（マスク処理後）、目的・注意点：表記ゆれの発見。氏名・社員番号・顧客名などは保存前に置換
- 質問、項目：検索に使われたクエリ（書き換えがある場合）、目的・注意点：質問と検索語のずれの確認
- 利用者、項目：仮名化した利用者ID、部署区分、目的・注意点：個人でなく部署別の傾向を見る。氏名やメールアドレスは保存しない
- 検索、項目：上位k件の文書ID、版・最終更新日、順位、目的・注意点：古い資料や重複版が上位に来ていないかの確認
- 回答、項目：回答文、引用した文書ID、目的・注意点：引用が検索結果と合っているかの確認
- 回答、項目：状態（回答／「見つからない」／拒否）、目的・注意点：未回答の件数把握
- 反応、項目：評価ボタン、言い換えての再質問、自由記述、目的・注意点：不満の兆候。自由記述にもマスクを適用
- 運用、項目：インデックス更新日、プロンプト版、モデル名、目的・注意点：変更前後の比較
- 人手、項目：失敗の型、担当、対応状況、目的・注意点：バックログ化
個人情報の扱いは、ログ設計の段階で決めておきます。質問には「〇〇さんの休暇残日数は」のように、個人を識別できる情報が入り得ます。個人情報保護委員会の個人情報保護法ガイドライン（通則編）は、利用目的の特定、安全管理、従業者の監督などを扱っています。ログの利用目的（品質改善など）、保存期間、閲覧できる人の範囲を社内ルールとして定めるときは、最新の本文と自社の規程を確認してください。個別の適法性は、この記事では判断できません。
実務上の方針は次の三つです。
- 保存前にマスクする。後から消すより、最初から持たないほうが安全です
- 閲覧権限を分ける。全文を見られる人は分析担当に絞り、他の人は集計だけを見ます
- 保存期間を決める。分析に必要な期間を過ぎたら削除します
パスワードやAPIキーが質問に含まれる可能性もあるため、保存前に検出・除去する方法を検討してください。
失敗の型と改善バックログの分類
仕分けた型ごとに、直す場所が変わります。下の表をそのままバックログの分類に使えます。型名は編集上の提案で、公式の用語ではありません。
- A 資料なし、ログでの見え方：「見つからない」が多い。人が探しても資料がない、直す場所：資料の新規作成、改善タスクの例：担当部署を決めて手順書・FAQを作る
- B 表記ゆれ、ログでの見え方：同じ内容を別の言葉で聞くと当たらない（例：「出張精算」と「旅費精算」）、直す場所：用語・見出し、改善タスクの例：別名を本文や見出しに追記、用語集を作る
- C 古い・版重複、ログでの見え方：上位に旧版や廃止資料が出る、直す場所：資料の管理、改善タスクの例：旧版の廃止、更新日・有効期限の付与
- D 矛盾、ログでの見え方：資料同士で内容が違う、直す場所：正本の決定、改善タスクの例：正とする資料を決め、他は修正または削除
- E 構造が悪い、ログでの見え方：資料はあるが答えが表や添付に埋もれ、複数文書に分散している、直す場所：文書の構成、改善タスクの例：結論を冒頭に置く、FAQ形式に分ける
- F 索引・権限漏れ、ログでの見え方：資料はあるのに一度も検索に出ない、直す場所：索引設定、改善タスクの例：取り込み対象の追加、権限の見直し
- G 質問が曖昧、ログでの見え方：「申請はどうやる？」のように対象が不明、直す場所：画面設計、改善タスクの例：聞き返し、質問例の提示
- H 生成側の誤り、ログでの見え方：上位資料は正しいのに回答がずれる、直す場所：プロンプト・モデル、改善タスクの例：回答ルールの修正、必要ならモデル比較
- I 範囲外、ログでの見え方：資料化すべきでない質問（個人の査定など）、直す場所：案内、改善タスクの例：担当窓口への誘導文
A〜Fは資料や索引の問題で、Hだけが生成側です。ログを見ると、HよりA〜Fが多いというのはよく聞く話ですが、自社の割合は仕分けてみないと分かりません。
AIにログの仕分けを手伝わせる
ログの一次仕分けは、AIに任せると速くなります。ただし、最終的なラベルと優先順位は人が決めます。依頼文は次のとおりです。
あなたは社内検索AIの品質改善を支援する分析担当です。
以下の質問ログ1件について、失敗の型をA〜Iから1つ選び、
根拠を一文で述べてください。判断できないときは「要確認」としてください。
型の定義:
A 資料なし／B 表記ゆれ／C 古い・版重複／D 資料間の矛盾／
E 構造が悪い／F 索引・権限漏れ／G 質問が曖昧／H 生成側の誤り／I 範囲外
ルール:
- 推測で資料の中身を補わない。ログに書かれた情報だけで判断する
- 人が確認すべき点を「確認事項」に書く
出力形式: 型 | 根拠 | 確認事項 | 直す候補
【ログ】入力例（説明用の架空ログ）は次のとおりです。
質問: 旅費精算の締め日はいつですか
状態: 「見つかりませんでした」
上位3件: 出張規程_2021版(更新2021-04) / 経費精算マニュアル(更新2024-09) / 交通費申請FAQ
人の確認メモ: 経費精算マニュアルに「出張費の精算期限」の記載あり。「旅費」の語は無いこの例なら、AIは「B 表記ゆれ」と判定し、「出張費」と「旅費」を同じ意味で扱う別名の追記を候補に挙げるはずです。ただし、これは想定される出力であり、実際に実行して確認した結果ではありません。
人が確認するのは、(1)ラベルが合っているか、(2)直す候補が資料の実態に沿っているか、の二点です。最初の数十件は全件を人が見て、AIの判定とずれる傾向を把握してからサンプリングに切り替えると安全です。社外のAIサービスへログを渡す場合は、マスク済みであること、契約上の取り扱い、社内の持ち出しルールを先に確認してください。学習に使われない設定と秘密保持は別の話です。
優先順位は「件数×影響÷手間」で決める
型ごとの集計ができたら、バックログを並べます。次の簡易スコアは編集上の提案です。
- 件数：直近の一定期間で、同じ型・同じトピックの質問が何件あったか
- 影響：1（軽い手間）、2（業務が止まる）、3（誤案内が損害につながり得る）
- 手間：1（追記だけ）、2（資料の改訂）、3（部署をまたぐ調整）
スコア＝件数×影響÷手間。以下は数字を仮置きした説明用の例です。
- 「旅費」の別名を精算マニュアルに追記、型：B、件数：18、影響：2、手間：1、スコア：36
- 休暇申請の旧版を廃止、型：C、件数：9、影響：3、手間：1、スコア：27
- リモート勤務の手順書を新規作成、型：A、件数：12、影響：2、手間：3、スコア：8
手間が小さいBとCから始まるため、成果が早く出ます。一方、スコアが低くても影響3の誤案内リスクは先に人が確認する、という例外を置いておきましょう。
週次の回し方
- 前週のログから、「見つからない」と低評価、再質問の多い質問を抽出する
- AIで一次仕分けし、人が型を確定する
- 型ごとに集計し、スコアで上位を決める
- 資料を直す。直した日とインデックス更新日を記録する
- 同じ質問を再実行して、改善したか確認する
資料も質問も時間とともに変わります。定期的に同じ質問で再評価し、資料や検索の問題を確認したうえで、必要に応じてプロンプトやモデルの比較に進みます。
