LLMの「聞きすぎ」を止める：ラベル付きデータで自己分析させたプロンプト改善

はじめに

バクラクのQAエンジニアをしているteyamaguです。

バクラクでは、カスタマーサポート担当者やカスタマーサクセス担当者が開発チームへ問い合わせをエスカレーションする際、QAエンジニアが一次対応を担当しています。一次対応の中では、調査開始時点では追加確認が必要になるケースがありました。このような場合、不足情報を確認するために担当者がお客様へ連絡し、回答が返ってくるまで調査が止まっていました。このタイムラグが積み重なると、対応リードタイムの長期化につながっていました。

そこで、LLMを使って不足情報を自動検出し、「お客様へ確認すべき質問」を生成するボットを社内に構築し、試行しています。担当者がエスカレーションとして問い合わせ入力をSlackに入力すると、その入力をボットが検知し、Slack上に確認すべき質問が出力される仕組みです。

このボットを運用し始めてすぐ、想定外の問題に直面しました。LLMが「お客様にこの時点では追加で確認しなくてよい情報」まで質問として出力してしまっていたのです。

本記事では、この問題に対して「LLM自身に分析・提案させる」アプローチを試し、改善した過程をまとめます。

何が起きていたか

ボットが生成する質問を実際に確認したところ、調査に不要と判断できる出力が含まれていることがわかりました。

ケース1: 再現済みなのに継続確認を求める

問い合わせ内容（抜粋）:
- 再現環境: ステージング環境にて再現確認済み
- 再現手順・スクリーンショット: 提供済み

ボットの出力:
「現在も本番環境で同様の事象が発生しているか確認してください」
「事象発生日時（日時と可能であれば時刻）をご教示ください」

ステージング環境で再現済みで、手順もスクリーンショットも提供済みなのに、発生日時や本番環境でも継続して発生しているかの確認を求めています。再現確認と手順が揃っているため、調査の開始にあたってはこれらの情報は不要でした。

ケース2: 内部で確認できる情報を聞く

問い合わせ内容（抜粋）:
- テナントID: 提供済み
- 問い合わせ種別: 仕様確認（ステータスを元に戻せるか）

ボットの出力:
「ご利用中の連携先サービス名および連携設定状況をご教示ください」
「ご契約情報をご教示ください」

仕様確認の問い合わせに対して、テナントIDがあれば内部で確認できる情報を質問しています。弊社のシステムでは、お客様の環境ごとにテナントIDが割り当てられており、そのIDがあれば一定の情報を取得でき、お客様に聞く必要がありません。

データで見る問題の規模

実際の11件の出力に含まれる46個の質問項目に、OK/NGラベルを付けて分類しました。

評価	件数	割合
OK（適切な質問）	9個	20%
NG（不要な質問）	37個	80%

出力された質問の8割がNGでした。

NGをパターン別に分類すると、以下のようになります。

パターン	件数	割合
再現状況から判断すると不要（再現済みなのに継続確認を求める等）	18個	49%
内部で確認できる情報を聞いている	13個	35%
問題の性質に合わない情報を聞いている（仕様確認に環境情報など）	4個	11%
問い合わせ文から自明な情報を再確認している	2個	5%

最多は「再現状況から判断すると不要」で、半数近くを占めていました。

なぜ起きていたのか

プロンプトの初期設計を振り返ると、「何を聞くべきか」は詳細に書いていましたが、「何を聞いてはいけないか」は書いていませんでした。

LLMは「不足情報を見つけて質問を生成する」という指示に対して、忠実に、ときに過剰に最適化します。つまり、あらゆる不足情報を質問として出力しようとします。「内部で確認できるか」「再現済みで不要か」といった判断は、明示的に指示しないと、安定しにくい傾向があります。

「何を聞くべきか」を詳細に指示するだけでは足りませんでした。では、「何を聞いてはならないか」と書けばよいのでしょうか。それを人間が網羅的に考えるのは容易ではありません。

そこで、ラベル付きデータをLLM自身に渡して、プロンプトの改善を依頼するというアプローチをとりました。

解決策: LLM自身に出力を分析・提案させる

プロセス

ボットの実際の出力にOK/NGラベルを付けてデータ化する
そのデータをLLMに渡し、プロンプトの改善案を提示するよう依頼する
LLMが提案した改善内容をプロンプトに組み込む

ポイントは、人間が「禁止ルール」を考えるのではなく、LLMにNGパターンを分析させ、LLM自身に「自分が聞くべきでないこと」を導かせた点です。LLMの提案内容は、人間がレビューした上でプロンプトに組み込みました。

LLMへの依頼はシンプルで、改善案の提示を求めるものでした。禁止ルールという形式はLLM自身が提案したものです。

LLMが導いた禁止ルール

元のプロンプトは、以下の5つのStepで処理を行うものでした。

問い合わせ内容の分類
提供済み情報の確認
プロダクト別不足情報の特定
事象固有の追加確認項目
優先順位・出力ルール

これらのStepに、LLM自身がStep 2.5として追加ステップを提案しました。Step 3〜4で候補に挙がる質問のうち「聞くべきでないもの」をあらかじめ定義することで、過剰な質問生成を抑制します。

LLMが提案した内容を整理・確認し、プロンプトに追加しました。以下にそのステップを示します。

### Step 2.5: 質問してはいけない情報の除外

Step 3〜4で候補に挙がった質問について、
以下に該当するものは必ず除外してください。

■ 内部確認可能なため聞かない
  - 連携先サービス名および連携設定状況
  - 契約情報
  - 対象データの現在のステータスや操作日時
  - ユーザーIDが提供済みの場合の関連データ（社内で確認できる情報）
  - 調査用IDが提供済みの場合の発生日時（IDをもとに社内で特定できる場合）

■ 再現状況に基づいて聞かない
  - 再現済みと明記されている場合
    →「現在も継続して発生しているか」「本番でも発生するか」は不要
  - 再現手順・スクリーンショットが提供済みの場合
    → 発生日時は確認不要

■ 問題の性質に基づいて聞かない
  - 仕様確認の場合 → 環境情報・継続確認は原則不要
  - サーバー側処理が原因の事象 → ブラウザ・OS・アプリバージョンは不要
  - データ処理・計算ロジックの問題 → ブラウザ・OS情報は不要

■ 問い合わせ文から自明な場合は聞かない
  - 期待結果が問い合わせに明記されている場合 → 期待結果を再確認しない
  - 事象の対象が特定されている場合 → 同じ情報を別の呼び方で再度聞かない

あわせて、除外後に質問が0件になった場合の出力も定義しました。

【追加確認は不要です】
調査に必要な情報は揃っています。
このまま開発チームへ共有・調査を進めてください。

結果

禁止ルール追加後の出力についても同様にOK/NGラベルを付けて集計したところ、NG率は改善前の80%から約61%に低下しました。ただし、今回の集計は改善前11件・改善後13件という限られたサンプルに基づいており、統計的な有意性は保証できません。傾向の把握を目的とした参考データとしてご覧ください。また、61%はまだ高い数値です。今回この記事で伝えたいのは最終的なNG率そのものではなく、「ラベル付きデータをLLMに渡してルールを導かせる」というアプローチ自体の再現性です。数値はあくまで手法の有効性を示す参考指標として読んでいただければと思います。

NGパターン別の内訳比較

以下の割合はNG全体に占めるパターン別の比率を示しています。

パターン	改善前（NG内訳）	改善後（NG内訳）
再現状況から判断すると不要	49%	40%
内部で確認できる情報を聞いている	35%	50%
問題の性質に合わない情報を聞いている	11%	0%
問い合わせ文から自明な情報を再確認している	5%	10%

「問題の性質に合わない情報を聞く」パターンが完全に消えました。 仕様確認なのに環境情報を聞く、計算ロジックの問題なのに連携先サービスを聞く、といった出力がゼロになりました。「再現状況から判断すると不要」なパターンも減少しました。

一方、「内部で確認できる情報を聞く」パターンは残存し、むしろ割合が増えました。 NG全体の数が減った結果として相対的に目立つようになった面もありますが、このカテゴリの禁止ルールがLLMにとって判断しにくいことも示しました。「内部で確認できるかどうか」はシステムの知識が必要な判断であり、プロンプトに列挙できる具体例には限界があります。この点は継続的な改善課題と認識しています。