LLMの「聞きすぎ」を止める：ラベル付きデータで自己分析させたプロンプト改善
LayerX は、LLM が不要な確認質問を生成する「聞きすぎ」問題を解決するため、ラベル付きデータを用いて LLM に自己分析・提案させるプロンプト改善手法を実証し、実運用での精度向上に成功した。
キーポイント
LLM の過剰質問（聞きすぎ）問題の特定
顧客サポートのエスカレーション処理において、LLM が再現済み情報や内部で確認可能な情報を顧客へ不必要に確認する質問を生成し、対応リードタイムが長期化する課題が発生した。
ラベル付きデータによる自己分析アプローチ
従来のプロンプト調整ではなく、過去の実績データをラベル付けして LLM 自身に「なぜその質問が必要か」を分析・提案させる手法を採用し、不要な質問のフィルタリングを実現した。
具体的な改善事例と効果
ステージング環境での再現確認やテナント ID による内部情報取得など、実務ルールに基づいて不要な質問を排除し、調査開始までのタイムラグを大幅に短縮した。
出力質問の8割が不要であるという実証
11件の出力に含まれる46個の質問のうち、再現状況や内部情報に基づき不要なNG判定が37件（80%）を占め、特に「再現済みなのに確認を求める」ケースが半数近くを占めた。
LLMの過剰最適化と指示の欠如
LLMは不足情報を補完しようとする傾向が強いため、「何を聞くべきか」だけでなく「何を聞いてはいけないか」というネガティブな制約を明示しないと、不要な質問が生成され続ける。
LLM自身による禁止ルールの生成
人間が禁止ルールを定義するのではなく、過去のNG出力データからLLMに分析させ、自身が「聞くべきでない質問」のルールを導出させるアプローチです。
Step 2.5 の追加による過剰質問の抑制
既存のプロセスステップ間に「質問してはいけない情報の除外」ステップを追加し、内部確認済みや自明な情報を問わないことで、ボットの聞きすぎを防止します。
重要な引用
LLM が「お客様にこの時点では追加で確認しなくてよい情報」まで質問として出力してしまっていた
本記事では、この問題に対して「LLM 自身に分析・提案させる」アプローチを試し、改善した過程をまとめます
出力された質問の8割がNGでした。
「何を聞くべきか」を詳細に指示するだけでは足りませんでした。
人間が「禁止ルール」を考えるのではなく、LLMにNGパターンを分析させ、LLM自身に「自分が聞くべきでないこと」を導かせた点です
今回の記事で伝えたいのは最終的な NG 率そのものではなく、「ラベル付きデータを LLM に渡してルールを導かせる」というアプローチ自体の再現性です
影響分析・編集コメントを表示
影響分析
この記事は、LLM を実務で導入する際によく見られる『過剰な質問』や『文脈の誤認識』という課題に対し、ラベル付きデータを活用した自己分析アプローチという具体的な解決策を示しています。特に、単なるプロンプトエンジニアリングではなく、データの質と LLM の推論プロセスを組み合わせた手法は、企業内での AI 実装における標準的なプラクティスとして今後広まる可能性があります。
編集コメント
「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自身に渡して、プロンプトの改善を依頼するというアプローチをとりました。
プロセス
- ボットの実際の出力に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にとって判断しにくいことも示しました。「内部で確認できるかどうか」はシステムの知識が必要な判断であり、プロンプトに列挙できる具体例には限界があります。この点は継続的な改善課題と認識しています。
振り返って気づいたこと
データが先、ルールが後
最初からこのルールが書けたわけではありません。まずデータを集めてラベルを付け、それをLLMに渡して初めて「どういう条件のときに不要な質問が生まれるか」が言語化されました。
人間がルールを先に考えると「もれなく書かなければ」という意識が働き、かえって抽象的で使いにくいルールになりがちです。実際のNGパターンから帰納的にルールを作る順序が重要でした。今回は11件という少量のデータでも4つのパターンが出揃い、ルールの骨格を作ることができました。
ラベル付きデータをLLMに渡す
LLMに「あなたの出力のどこが問題か」を分析させることができました。その際、単に問題のある出力を見せるより、OK/NGのラベルを付けて渡す方が、LLMはパターンを把握しやすくなると考えています。
この「ラベル付きデータを渡してLLMに改善を依頼する」というアプローチは、プロンプト改善の汎用的な手順として使えると考えています。
「質問しない」という出力を定義する
改善前のプロンプトは「質問を生成する」ことを前提に設計されていたため、情報が十分に揃っている場合でも、何かしら質問を出力しようとする傾向がありました。
LLMの提案により「質問が0件のときは追加確認不要と出力する」というルールが加わったことで、質問を生成しないことも正しい出力であると明示できました。当初は想定していませんでしたが、実運用上の価値が大きいことがわかりました。
おわりに
「LLMの出力精度を上げる」というと、モデルの選択やFew-shot（プロンプトに具体例を埋め込む手法）の工夫に目が向きがちです。しかし今回の改善の核は、実際の出力データをLLM自身に分析させるというアプローチでした。
QAエンジニアとして、この流れはテスト設計の改善サイクルと近いものがあります。不具合を収集し、パターンを分析し、設計にフィードバックします。LLMのプロンプト改善も、同じ考え方で進められました。
今回解消しきれなかった「内部で確認できる情報を聞く」パターンについては、Few-shotで具体例を増やす、あるいはラベリングを継続して次のルール改善サイクルに入るといったアプローチを検討しています。改善サイクルを回し続けることが、プロンプトの精度を高める近道だと考えています。
LayerX バクラク事業部QAでは、こうした試行錯誤を一緒に楽しみながら品質に向き合える仲間を募集しています。興味のある方はぜひエントリーください。
- 【バクラク】QAエンジニア_ポテンシャル枠 / 株式会社LayerX
- 【バクラク】QAエンジニア / 株式会社LayerX
- 【バクラク】シニアQAエンジニア / 株式会社LayerX
また、カジュアル面談も行っていますので、興味のある方是非お話ししましょう！
原文を表示
はじめに
バクラクの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自身に渡して、プロンプトの改善を依頼するというアプローチをとりました。
プロセス
- ボットの実際の出力に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にとって判断しにくいことも示しました。「内部で確認できるかどうか」はシステムの知識が必要な判断であり、プロンプトに列挙できる具体例には限界があります。この点は継続的な改善課題と認識しています。
振り返って気づいたこと
データが先、ルールが後
最初からこのルールが書けたわけではありません。まずデータを集めてラベルを付け、それをLLMに渡して初めて「どういう条件のときに不要な質問が生まれるか」が言語化されました。
人間がルールを先に考えると「もれなく書かなければ」という意識が働き、かえって抽象的で使いにくいルールになりがちです。実際のNGパターンから帰納的にルールを作る順序が重要でした。今回は11件という少量のデータでも4つのパターンが出揃い、ルールの骨格を作ることができました。
ラベル付きデータをLLMに渡す
LLMに「あなたの出力のどこが問題か」を分析させることができました。その際、単に問題のある出力を見せるより、OK/NGのラベルを付けて渡す方が、LLMはパターンを把握しやすくなると考えています。
この「ラベル付きデータを渡してLLMに改善を依頼する」というアプローチは、プロンプト改善の汎用的な手順として使えると考えています。
「質問しない」という出力を定義する
改善前のプロンプトは「質問を生成する」ことを前提に設計されていたため、情報が十分に揃っている場合でも、何かしら質問を出力しようとする傾向がありました。
LLMの提案により「質問が0件のときは追加確認不要と出力する」というルールが加わったことで、質問を生成しないことも正しい出力であると明示できました。当初は想定していませんでしたが、実運用上の価値が大きいことがわかりました。
おわりに
「LLMの出力精度を上げる」というと、モデルの選択やFew-shot（プロンプトに具体例を埋め込む手法）の工夫に目が向きがちです。しかし今回の改善の核は、実際の出力データをLLM自身に分析させるというアプローチでした。
QAエンジニアとして、この流れはテスト設計の改善サイクルと近いものがあります。不具合を収集し、パターンを分析し、設計にフィードバックします。LLMのプロンプト改善も、同じ考え方で進められました。
今回解消しきれなかった「内部で確認できる情報を聞く」パターンについては、Few-shotで具体例を増やす、あるいはラベリングを継続して次のルール改善サイクルに入るといったアプローチを検討しています。改善サイクルを回し続けることが、プロンプトの精度を高める近道だと考えています。
LayerX バクラク事業部QAでは、こうした試行錯誤を一緒に楽しみながら品質に向き合える仲間を募集しています。興味のある方はぜひエントリーください。
- 【バクラク】QAエンジニア_ポテンシャル枠 / 株式会社LayerX
- 【バクラク】QAエンジニア / 株式会社LayerX
- 【バクラク】シニアQAエンジニア / 株式会社LayerX
また、カジュアル面談も行っていますので、興味のある方是非お話ししましょう！
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み