目次
「AIに判定させたら、だいたい合っているけれど時々おかしい」——LLMを業務に組み込むと、多くの会社がここで止まります。精度が9割に届いていても、残りの1割が重要な案件だと使えません。
そこで起きがちなのが、「例をもっと書こう」「モデルを上位のものに変えよう」という対処です。ところが私たちの経験では、判定のぶれは基準の曖昧さが原因であることがほとんどで、例示やモデルを変える前に直すべき箇所があります。
この記事では、社内で使っているメール返信漏れ検出の誤判定を追いかけたときの実例をもとに、判定基準をどう設計すればぶれが止まるのかを整理します。
この記事の結論
- LLMの判定ぶれは、モデルではなく基準の曖昧さが原因
- 判定軸は「ボールが今どちら側にあるか」の一本に統一する
- 例示を足すのは、軸を決めた後にする
何が起きたか：メール返信漏れ検出での誤判定
RENOYでは、社内のメールを読んで「これは返信が必要か」をLLMに判定させる仕組みを使っています。運用していると、返信が必要なのに拾えなかった見逃しと、返信不要なのに拾ってしまった誤分類が出ました。
まずやったのは、誤判定を1件ずつ開いて「なぜAIはそう判断し得たのか」を追うことです。ここで「AIが間違えた」で終わらせると改善は進みません。人間が読んでも解釈が割れる文章だったのかを確認します。
結果、見逃しも誤分類も、原因は同じでした。プロンプトに書いてあった判定基準が、どちらの解釈も許す書き方になっていたのです。
LLMの判定がぶれる原因は「基準の曖昧さ」
具体的には、次のようなグレーゾーンで判断が揺れていました。
| ぶれたケース | 人が曖昧にしていた点 |
|---|---|
| 御礼・返礼のメール | 用件が終わっているように見えるが、相手は反応を待っている |
| 「追って進捗を報告します」と自分が書いた件 | 相手からの依頼文はないが、次に動くのは自分 |
| すぐ対応する必要のない案件 | 急ぎでないことと、相手の返事待ちであることを混同していた |
いずれも、急ぎかどうかや用件が終わったかという感覚的な物差しで書かれていたために、LLMがもっともらしく別の結論を出せてしまう状態でした。人間の担当者なら暗黙に補える部分を、プロンプトに書いていなかったということです。
言い換えると、これはAIの性能の問題ではなく、業務ルールが言語化されていないという、よくあるDXの課題そのものです。
対策：「ボールは誰にあるか」で軸を一本にする
そこで、判定基準を感覚ではなく行動で定義し直しました。軸はひとつだけです。
いま、次に動く義務があるのはどちら側か。自分側にボールがあるなら要返信、相手側にあるなら対応不要。これだけです。
その上で、ぶれていた3つのグレーゾーンについて、プロンプトに明記しました。
- 御礼や返礼のメールでも、相手が反応を待っている状態なら要返信とする
- 自分が進捗を報告すると約束した件は、相手からの質問がなくても要返信とする
- すぐ対応する必要がないことは、相手待ちの理由にならない
この追記だけで、見逃しも誤分類も、1回の修正でまとめて解消しました。個別に例外処理を足したのではなく、軸を一本にそろえたら全部が同じ側に落ちたというのが実際の感覚です。
プロンプト改善の進め方：例示を足す前に軸を決める
誤判定が出たとき、多くの現場でまず行われるのは「正解の例を追加する」ことです。しかしこれは順番が逆になりがちです。
軸が決まっていない状態で例示を増やすと、例同士がぶつかります。「このメールは要返信、でも似たこのメールは不要」という例が並ぶと、LLMは境界線を読み取れず、かえって不安定になります。人が後から読んでも、なぜそう分けたのか説明できません。
おすすめの順番は次のとおりです。
- 誤判定を1件ずつ追う：件数を集計するより、なぜそう判断し得たかを読む方が早く原因に届きます
- 判定軸を一本に決める：複数の軸が混ざっていないかを疑います。急ぎ度と要返信は別の軸です
- 軸を明文化する：業務用語ではなく、誰が次に動くかという行動の言葉で書きます
- 残る例外だけ例示で補う：軸で説明しきれないものだけを例に足します
判断のコツ：誤判定が複数あるとき、それらが別々の問題に見えても、たいてい根は1つです。個別対処に走る前に「共通する曖昧さ」を探すほうが、修正回数が減ります。
判定軸のつくり方：業務用語ではなく行動で書く
この考え方は、メール判定に限りません。LLMに分類や判定をさせる業務では、同じ失敗が起きます。
| 曖昧になりやすい書き方 | 行動で言い直した書き方 |
|---|---|
| 重要な問い合わせ | 当社が回答しないと相手が次に進めない問い合わせ |
| 対応済みの案件 | 相手に返答を返し、こちらの作業が残っていない案件 |
| 急ぎの依頼 | 期限が明示され、その期限が今週内のもの |
左側は人間なら文脈で補えますが、LLMは補いません。主語と動作が入っているかどうかが、そのまま判定の安定性に効きます。
社内の業務ルールを言葉にする作業は、AI導入の準備というより、業務そのものの整理です。ここが曖昧なままだと、AIを入れても人が最終確認を外せず、効果が出ません。逆に言えば、軸を1つ決めるだけで使えるようになる仕組みは少なくありません。
なお、LLMの挙動はモデルの更新でも変わります。判定基準を明文化しておくと、モデルを入れ替えたときの検証もしやすくなります。各サービスの仕様は変わるため、最新の条件は公式で確認してください。
よくある質問
Q. LLMの判定がぶれるときは、まず何を直せばいいですか？ 例示やモデル変更より先に、判定基準の軸を一本に決めてください。多くのぶれは「どちらとも解釈できる基準」が原因です。軸を明文化すると、複数の誤判定がまとめて解消することがあります。
Q. プロンプトに例示を増やせば精度は上がりますか？ 軸が曖昧なままでは効果が薄く、例示同士が矛盾して悪化することもあります。先に判定軸を決め、その軸で説明しきれない例外だけを例示で補うのが順番です。
Q. 「ボールは誰にあるか」という基準は他の業務にも使えますか？ 使えます。問い合わせの一次対応要否、タスクの棚卸し、案件ステータスの整理など、次に誰が動くかで分かれる業務なら同じ軸が有効です。業務用語ではなく行動で定義するのがコツです。
まとめ
- LLMの判定ぶれは、モデル性能ではなく基準の曖昧さから起きることが多い
- メール返信判定では、軸を「ボールが今どちら側にあるか」に統一して解消した
- 御礼メールや自分から約束した報告も、相手が待っているなら要返信と明記する
- 改善の順番は、誤判定を1件ずつ追う → 軸を決める → 明文化する → 例外を例示で補う
RENOYでは、生成AIを業務に組み込む際の判定基準の設計から、運用に乗るまでの伴走を行っています。「AIに任せてみたが、精度が安定せず結局人が全部確認している」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。