LLMに採点させるなら、いきなり総合点を聞くべきではない（プロンプトテンプレート・スキルあり）

大量の文章の品質チェックをLLMに任せたい場面が増えています。LLM生成による要約のレビュー、外部から届いた原稿のチェック、蓄積された社内ドキュメントの棚卸し。1本ずつ人が読むには多すぎるテキストを前に、採点をAIに任せる判断は自然な流れです。

ところが、いざ運用してみると不思議なことが起こります。改善のために点数をつけているのに、返ってくるスコアは4点や5点ばかり。たとえば、レビューに流した要約の1本に、原文にないURLと発言者の取り違えが紛れ込んでいたとします。人間が読めば数十秒で気づく誤りです。それでも自動採点は満点。スコアを信じてそのまま公開するわけにはいきません。

そんな中、聞き方を変えるだけでこの状況が大きく変わる、という検証結果が報告されています。しかも採点できる対象は、AIが書いた文章に限りません。本記事では、実際の方法と、それがなぜ機能するのか、そしてどこまで頼れるのかを紹介します。

一発の総合採点が行き詰まる理由

文章の品質を数値で測ることは、自然言語処理の積年の課題です。人手評価は正確ですが遅くて高くつきます。ROUGEやBLEUのような単語の重なりを数える従来指標は、意味の正しさや事実性を捉えられません。そこで近年主流になったのが、LLMを採点者に据えるアプローチです。

ただ、ここにも壁があります。「この要約は1〜5点で何点か」と丸ごと聞く方式では、返ってくるのが1つの数字だけで、低評価の理由が事実誤認なのか、構成の乱れなのか、情報の欠落なのか判別できません。

プロンプトやモデルを比較しながら改善を回す場面で求められるのは、正確なだけでなく、どこが悪いかを教えてくれる評価です。

評価基準をYes/No質問の束に分解する

今回取り上げる方式の手順はシンプルです。

まず、生成タスクの指示文を評価用のLLMに渡し、要件のリストに整理させます。要約タスクなら「原文の主要な出来事を含む」「事実に反する記述がない」といった粒度です。全体像を先に掴ませてから細分化することで、次のステップでの取りこぼしを減らす狙いがあります。

次に、各要件をYes/No質問に変換させます。Yesと答えられれば要件を満たす、という向きに統一し、複数の確認事項を含む要件は質問を分けます。あわせて、Noになる場合の違反例も添えさせると、判定の基準がぶれにくくなります。生成された質問は、一貫性や流暢さといった評価軸ごとに整理しておきます。

評価の本番では、採点対象の文章1本ごとに、各質問を独立に答えさせます。判定と一緒に理由の説明文も出させるのがポイントで、後から採点根拠を追える形になります。最後にYesの割合を軸ごとに集計すればスコアが得られます。0〜1の値になるため、既存の1〜5点方式と比べたければ単純な換算で揃えられます。

見逃せないのが、採点される側に縛りがない点です。仕組みとして決まっているのは、入力と出力のペア（原文と要約、会話履歴と応答、指示文と完成文など）に質問を当てるという形だけで、その文章を誰が書いたかは問われません。LLMの出力はもちろん、別方式の生成システムの出力でも、人間が書いた文章でも、同じ質問セットでそのまま採点できます。

質問を作らせるためのメタプロンプト（プロンプトを生成するためのプロンプト）もタスクをまたいで共通で、要約でも対話でも指示遵守でも同じものが使えます。評価用のモデルを追加学習させる必要もありません。

上記の手順は、プロンプトに落とせます。タスク指示文を渡すと質問セットを返すメタプロンプトと、入力・出力・質問を渡すとYes/Noと理由を返す評価器の2つを用意すれば、最小構成の評価が回ります。以下は論文の手順を再構成したテンプレートです。JSON出力に統一してあり、集計まで機械的につなげられます。

二値質問の生成（メタプロンプト）

あなたは、生成タスクの品質評価基準を設計する専門家です。
以下のタスク指示文を分析し、出力の品質を検証するための二値質問（Yes/No質問）を生成してください。

【評価対象のタスク指示文】
{TASK_DESCRIPTION}

【任意：評価軸の指定】
{DIMENSIONS}
（指定がなければ、タスク指示文から適切な評価軸を自分で導出してください。
　例：一貫性、事実整合性、流暢さ、関連性）

【手順】
ステップ1：要件の抽出
上記のタスク指示文を、満たすべき要件のリストに分解してください。
各要件は、互いに独立した1つの評価観点を表すようにします。
（例：特定の情報が含まれているか、指定された書式を守っているか）

ステップ2：二値質問への変換
各要件を1つ以上のYes/No質問に変換してください。次のルールに従います。
- 「Yes」がその要件を満たしている状態、「No」が違反している状態を指すよう向きを統一する
- 1つの要件が複数の確認事項を含む場合は、質問を分ける
- 各質問に、「No」に該当する具体的な違反例を1つ添える
- 各質問を、いずれかの評価軸に割り当てる

【良い質問の条件】
- 1つの検証可能な性質だけを問う。複数の観点を1問に詰め込まない
- 判定がぶれにくい具体的な問いにする
  （悪い例：「事実整合性を高く保っているか」／良い例：「すべての固有名詞が原文どおりに表記されているか」）
- 同じ軸の質問どうしが、なるべく別々の失敗を拾うようにする
  （例：綴りを見る質問と句読点を見る質問は、重ならないよう独立させる）

【出力形式】
以下のJSONのみを出力してください。前置きや解説は不要です。
{
  "requirements": [
    {"id": "R1", "dimension": "評価軸名", "description": "要件の内容"}
  ],
  "questions": [
    {
      "id": "Q1",
      "dimension": "評価軸名",
      "source_requirement": "R1",
      "question": "Yes/Noで答えられる質問文",
      "violation_example": "Noに該当する具体例"
    }
  ]
}

二値評価（評価器）

あなたは、生成された出力を検証する評価者です。
以下の入力と出力を読み、与えられた各質問に独立に答えてください。

【入力（原文・文脈・指示など）】
{SOURCE_INPUT}

【評価対象の出力】
{OUTPUT}

【質問リスト】
{QUESTIONS}

【回答のルール】
- 各質問には、他の質問と切り離し、その質問だけを見て答える
- 判定は Yes（1）または No（0）のいずれか
- 各判定に、そう判断した理由を1文で添える
- 推測で補わず、入力と出力に実際に書かれている内容に基づいて判定する
- 出力に情報が「無い」ことと、出力の内容が「間違っている」ことを区別する
  （原文にある情報を省略しただけなら、事実の誤りとはしない。
　　出力に書かれていて根拠がない、または矛盾する記述だけを違反とする）

【出力形式】
以下のJSONのみを出力してください。
{
  "verdicts": [
    {"id": "Q1", "answer": 1, "explanation": "この判定にした理由（1文）"}
  ]
}

それらしい文章につく満点を防げる

分解が何を変えるのか、報告されている事例で見てみます。

軍用機の接近事案を報じた記事の要約に、3つの誤りが含まれていました。発言主体の取り違え、原文に存在しないURL、当事者双方の主張の混同です。文面そのものは自然で、登場する機体名も正確でした。

オープンソースモデル（gpt-oss-120b）で動かした一発採点の方式は、この要約に5点満点をつけました。見た目がそれらしければ通ってしまう挙動です。一方、質問分解方式では7問中4問がNoとなり、換算スコアは1.57。人間の評価2.0にかなり近づきました。Noがついた質問を見れば、発言主体の誤り、URLの捏造、主張の混同がそれぞれどこで検出されたのか分かります。

逆方向の事例もあります。要点を突いた1文だけの短い要約に対し、一発採点は「短すぎる」として最低点をつけました。人間は情報が少ない点だけを差し引いた中間的な評価をしています。質問分解では、話題の一致や冗長性のなさは満たす一方で網羅性の質問だけ落とす、という部分点のつき方になり、人間の評価に沿いました。

一発採点は満点か最低点かの両極に振れやすく、部分的な欠点と致命的な欠陥を区別できません。分解方式は、満たした項目と落とした項目の比率で中間の評価を出せます。

人間が書いた文章も同じ枠組みで採点できた

体系的な比較でも同じ傾向が確認されています。要約の定番ベンチマーク（SummEval）を使った検証では、人間の評価との順位相関で主要な既存手法を上回りました。採点対象は、対話型LLMが普及する前に作られた16種類の要約モデルの出力1,600本で、それぞれに人手評価がついています。順位相関は、人間がつけた良し悪しの順番と手法の順番がどれだけ一致するかを表す指標で、1に近いほど人間の判断に沿っています。

伸びが大きかったのは事実整合性の軸です。要約が原文の事実に忠実かだけを問うハルシネーション検出用のデータセット（QAGS）を使った比較でも最高の順位相関（0.620）を記録し、単一のYes/No質問しか使わない方式や一発採点を引き離しました。事実の誤りは、どの記述がどう間違っているかを特定できるため、細かいチェックへの分解と相性が良いと分析されています。

対話応答の評価（Topical-Chat）でも平均相関は最高で、自然さや面白さといった主観寄りの軸ほど差がつきました。注目したいのは採点対象の中身です。この比較には対話モデルの応答に加えて、もともとの正解として用意された人間の応答と、新たに人間が書き下ろした応答が含まれており、人手のテキストが同じ質問セットでそのまま採点されています。採点する側がLLMというだけで、採点される側の書き手は問われないことを示す構成です。生成AIの出力チェックに限らず、人が書いた原稿の一次レビューのような場面にも同じ設計を持ち込める根拠になります。

一方で、要約の話題選択が適切かを見る関連性の軸だけは、一発採点のGPT-4版が上回りました。全体の要旨を掴めているかという判断は、細かい質問への分解が難しい領域として残っています。

もう1つの発見はスコアの分布です。既存の方式には高得点側に張り付く傾向（天井効果）があり、まずまずの文章と明確に問題のある文章を区別できていませんでした。質問分解方式の分布は人間の採点分布に近く、中間帯の判別力を保っていたと報告されています。

なお、採点役のモデルの地力も結果を左右します。同じ質問セットでも、gpt-oss-120bで動かすと相関は全体に下がりました。それでも同一モデル同士の比較では一発採点より質問分解が上であり、分解は有効な設計である一方、採点役の読解力を代替するものではないと言えます。

質問を分けると内部で何が起きているのか

3つの仕組みが働いていると分析されています。

1つ目は、判断の単純化です。

「事実整合性を1〜5点で採点せよ」より「固有名詞はすべて原文どおりか」の方が、答えやすく、ぶれにくい質問です。複雑な課題を小さな部分課題に割ると精度が上がるという、プロンプト設計で知られてきた知見の評価版と言えます。

2つ目は、平均によるノイズの打ち消しです。

互いにあまり相関しない判定を複数集めて平均すると、個々の判定の揺らぎが相殺されます。生成された質問同士の相関を測ったところ、多くの軸で質問ペアの相関が低く、それぞれ別の側面を見ていることが確認されました。

3つ目は、チェック観点の明示による見落とし防止です。

たとえば流暢さの軸では、綴りの誤りを見る質問と句読点を見る質問がほぼ無相関で、拾える失敗が重なっていませんでした。総合判断では埋もれる小さな欠陥を、列挙されたチェック項目が個別に拾います。

運用面では、生成された質問セットの品質を事前に点検できる利点もあります。Yes率が質問間で散らばっているか、質問同士の相関が高すぎないかを見れば、分解がうまく機能しそうな軸と、質問を作り直すべき軸をあらかじめ見分けられます。

落ちた質問の記録がプロンプト改善の材料になる

分解のもう1つの価値は、評価結果をそのまま改善ループの入力に使える点です。手順を追います。

まず、現行のプロンプトで出力を生成し、評価器にかけて、Noがついた質問と理由の説明文を集めます。次に、記録係のLLMに失敗事例を分析させ、一般化できる教訓を抽出させます。意味の重なる教訓は統合して10件程度に絞ります。最後に、更新係のLLMが現行プロンプト内の該当箇所を特定し、教訓を反映した文面に書き換えます。失敗がなくなるか、上限回数に達したら終了です。

強いモデルを手本にする使い方もあります。基準となるモデルと改善対象のモデルに同じ質問セットを解かせ、判定が食い違った質問だけを教訓抽出の材料にします。総合点の差と違って、どの基準の解釈がずれているかを質問単位で特定できるため、直すべき箇所が明確になります。モデルを別系統へ移行する際に、プロンプトを新モデル向けへ調整する用途にも応用できます。

要約評価のプロンプトをこのループで改善した検証では、4軸中3軸で人間との相関が向上しました。象徴的なのは、強いモデルを手本にした場合の事実整合性の伸びです。改善対象のモデルは「原文の情報を省略した要約」を事実誤認として減点していました。手本との食い違い分析から「省略は矛盾ではない。要約に書かれていて根拠のない記述だけを減点する」という教訓が抽出され、プロンプトに反映された結果、相関は0.501から0.637まで改善しています。総合点の比較だけでは、この種の概念レベルの誤解にはたどり着きにくかったと分析されています。

改善の大半は最初の1〜2周で得られ、回しすぎると教訓同士が競合してかえって劣化する傾向も観察されています。

この改善ループも3つのプロンプトで組めます。失敗事例から教訓を抽出するもの、重複する教訓を統合するもの、教訓をプロンプトの該当箇所に反映するもの。順に回せば、評価器や生成側のプロンプトを自動で磨けます。ただし次のセクションで述べるとおり、効く失敗と効かない失敗があります。

教訓の抽出（改善ループ）

あなたは、評価の失敗事例を分析し、改善の教訓を抽出する分析者です。
以下の事例について、なぜ判定を誤ったのか、どう修正すべきかを、
今後の他のケースにも適用できる一般化された教訓の形で抽出してください。

【入力】
{SOURCE_INPUT}

【出力】
{OUTPUT}

【失敗・不一致の記録】
{FAILURES}
（各項目：質問ID、その質問への判定、期待される判定または基準モデルの判定、理由）

【抽出のルール】
- 個別事例そのものではなく、他のケースにも通用する原則として書く
- 「何を、どう判定すべきか」を具体的に述べる
- 1つの教訓につき1〜2文にまとめる

【出力形式】
{
  "lessons": ["教訓1", "教訓2"]
}

教訓の重複統合（改善ループ）

あなたは、教訓リストの重複を整理する編集者です。
新しい教訓が、既存の教訓のいずれかと意味的に同じか判断してください。
同じであれば統合した1文を、異なれば新規として扱ってください。

【新しい教訓】
{NEW_LESSON}

【既存の教訓リスト】
{EXISTING_LESSONS}

【出力形式】
{
  "is_duplicate": true または false,
  "merge_index": 統合対象の既存教訓の番号（重複時のみ、0始まり）,
  "merged_lesson": "統合後の1文（重複時のみ）"
}

プロンプトの書き換え（改善ループ）

あなたは、教訓に基づいて評価プロンプトを改訂する編集者です。
以下の現行プロンプトの中から、この教訓を反映すべき箇所を1つ特定し、
教訓を織り込んだ改訂版に書き換えてください。

【現行プロンプト】
{CURRENT_PROMPT}

【反映すべき教訓】
{LESSON}

【書き換えのルール】
- 現行プロンプトから、置き換える対象の一節をそのまま抜き出す
- その一節を、教訓を反映した改訂版に書き換える
- プロンプト全体ではなく、変更する一節だけを対象にする

【出力形式】
{
  "target_substring": "現行プロンプトから抜き出した、置き換える一節",
  "revised_substring": "教訓を反映した改訂版の一節"
}

指示で直る失敗と直らない失敗がある

ただし、この改善ループには明確な守備範囲があります。

失敗例の1つが関連性の軸です。採点が甘すぎるという診断自体は正しかったものの、抽出された教訓が「登場人物、動機、背景の出来事をすべて網羅しているか個別に確認せよ」という過剰に細かいチェックに落ち、人間より厳しすぎる採点者ができあがりました。相関は0.505から0.357へ、改善どころか大きく悪化しています。人間が全体の印象で下す種類の判断を無理に分解すると、かえって人間から離れるという教訓です。

もう1つの検証が、指示遵守ベンチマーク（IFBench）での生成プロンプト改善です。ここでは失敗の種類による明暗がくっきり分かれました。

形式や文構造の指定は、明確な指示を与えれば守れる種類の失敗で、それぞれ17ポイント改善しました。一方、カウントや比率の維持は、生成しながら数を正確に数える能力そのものが足りていない失敗です。「内部でカウンターを維持せよ」といった教訓は、診断としては正しくても、指示された側に実行する力がありません。

さらに深刻なのは副作用です。実行できない指示が蓄積した結果、プロンプトは22文字から4周で6,248文字まで膨張し、以前は守れていた形式指定まで崩れて全体の精度が落ちました。プロンプトによる改善には積載量の上限があり、超えると正しい指示まで機能しなくなる、という観察です。

改善ループを回す前に、失敗の原因が指示の不足なのか能力の不足なのかを切り分ける。この一手間が、プロンプト肥大化の泥沼を避ける分かれ目になります。

導入コストと前提条件

質問分解方式は、効率を診断力と引き換えにしています。1本の文章を評価するたびに、質問の数だけモデル呼び出しと処理テキストが増えます。質問の生成は一度作れば使い回せるため、繰り返し発生するのは質問ごとの評価コストです。評価対象が大量にある場面では、呼び出し回数と料金の見積もりが導入判断の材料になります。

スコアの信頼性は質問セットの品質に依存します。大事な基準が質問に含まれていなければ、その欠陥は最後まで検出されません。また、満たした質問の割合が品質に比例するという前提を置いているため、1つの致命的な誤りが全体を台無しにするタスクでは、集計方法の工夫が別途求められます。採点者としてのLLMが持つ偏りも引き継がれるため、影響の大きい用途では人間の確認と組み合わせる運用が推奨されています。

まとめ

文章の評価を、1つの総合点から検証可能な質問の束に組み替える。それだけで人間の判断との一致度が上がり、スコアの根拠が読めるようになり、失敗の記録がプロンプト改善の材料に変わります。事実整合性のように誤りを特定できる基準ほど強みが出て、全体の印象で決まる基準や、モデルの能力不足による失敗には限界が残る。採点される文章の書き手がAIか人間かを問わない設計のため、生成AIの品質管理に限らず、委託原稿の検収や蓄積コンテンツの品質棚卸しといった場面にも持ち込めると考えられます。守備範囲ごと理解して使えば、テキスト評価の診断力を1段引き上げる、今日から取り入れられる考え方です。

スキル

本記事の関連研究