AI に採点させる距離。遊びの合否からは AI を外し、読む仕事だけを、作った本人ではない読み手に渡す
How far to let AI grade: AI is out of pass/fail, and reading goes to a reader who isn't the author
D25-3-T49-llm-as-a-judge-distance・技術・日本語入力でプレイする仕組み
AI に初見で遊ばせたあと、その感想を作り手のセッションが読んで合否を書いていた時期がありました。同じログを二度読むと、結果が変わりえました。
いまは、遊びの合否からは AI を外して算術で数え、AI にしかできない「通して読んで粗を見つける」仕事だけを、作った本人ではない読み手に渡しています。
昨夜の T48 は、AI を遊ぶ側に座らせる話でした。今日は、AI を採点する側に座らせるときの距離の取り方です。
採点の数字が目的にすり替わる話（Goodhart 則・surrogation）は、今夜の T50 と明日の T51 に回します。
この回の位置と、前後の回#
区切り: T34〜T49 確かめ方（16 回のうち 16 回目）
先に読むとよい回: T48（AI に初見で遊ばせる）
次に読む回: T50（通じ率 23% が 100% になった日）・T51（代わりの指標を目的と取り違える）
名前 — LLM-as-a-judge#
- 正式名
- LLM-as-a-judge
- 日本語での呼び名
- LLM を採点者にする、LLM 審査
- 初出
- Lianmin Zheng, Wei-Lin Chiang, Ying Sheng ほか, "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena"（NeurIPS 2023 Datasets and Benchmarks, arXiv:2306.05685）
偏りの名前:
- self-preference bias（自己優遇の偏り）。Zheng ほか（2023）では self-enhancement bias と呼ばれています
- 関連: Arjun Panickssery, Samuel R. Bowman, Shi Feng, "LLM Evaluators Recognize and Favor Their Own Generations"（NeurIPS 2024, arXiv:2404.13076）
- 同じ論文群でよく並ぶもの: position bias（並びの位置の偏り）・verbosity bias（長い答えを好む偏り）
（どちらの論文も、書誌と要旨・要約で確かめ、本文は読んでいません。）
一般の解説 — LLM-as-a-judge#
- LLM-as-a-judge
人の評価は高く、遅く、ばらつきます。そこで、強い LLM に採点させます。
Zheng ほかは、複数回の対話の問い（MT-Bench）と、利用者が二つのモデルを見比べて投票する場（Chatbot Arena）を作り、LLM の判定役が人の好みとどれだけ一致するかを測りました。強い判定役（GPT-4）の一致は 80% を超え、人どうしの一致と同じ水準だった、という結果です。
採点の形は三つあります。
- 二つを並べてどちらが良いか（pairwise comparison）
- 一つに点を付ける（single answer grading）
- 正解の例を渡して照らす（reference-guided grading）
同じ論文が、偏りも並べています。
- position bias: 並べた順で判定が変わる。二つを入れ替えて同じ判定になった割合は、GPT-4 で 65.0%、Claude-v1 で 23.8% でした（既定の指示のとき）
- verbosity bias: 長い答えを好む
- self-enhancement bias: 自分（同じモデル）の答えを好む
- 推論の弱さ: 数学や論理の採点で、自分でも解けない問いは正しく採点できない
対処として、入れ替えて二度判定する・例を渡す・正解の手順を先に解かせる、などが挙げられています。
- self-preference bias
Panickssery ほかは、自己優遇が本当に「自分の出力だから」なのかを問いました。
要約の課題で、GPT-4 や Llama 2 は、自分の書いた要約を、他のモデルや人の要約と見分けられる。さらに、自分の出力を見分ける力を微調整で強めると、自己優遇もそれに比例して強まった。単純な交絡（長さ・読みやすさなど）では説明がつかない、という結果です。
自己評価は、報酬のモデル・自分で直す仕組み・憲法的な AI の土台なので、この偏りはそれらにも入りうる、と論じています。
うちの名前の対照表の言い方では、「判定者を分離する。能力を上げても消えない」です。
うちで起きたこと: 作り手が採点していた#
2026-08-06 まで、AI のプレイヤーが遊んだあとの文章を、作り手のセッション（Claude Code）が読み、面白さの性質ごとに PASS／WARN／FAIL を決めて、台帳へ手で書き写していました。
採点のスクリプトの頭に、こう残っています。
# **これまで6性質の判定をしていたのは Claude Code だった。** AI初見プレイヤーの文章を読み、
# PASS/WARN/FAIL を決め、それを <work>\acceptance.json へ手で書き写していた。
# 再現性が無く（同じビルドを2回評価しても結果が違う）、モデルが変われば基準も動き、
# 転記の誤りは誰も気づかない。08/06 のセッションでその型の事故が4件出ている。
# **精度が下がっても再現性 100% を取る**、というのがユーザーの決定（03 §1）。
これは LLM-as-a-judge の悪い形が二つ重なっていました。
- 判定役が、作品を作ったのと同じセッション。作品の意図も、直した所も知っている。自己優遇がいちばん入りやすい位置です
- 判定が散文で、基準が文になっていない。同じ入力に同じ判定が返る保証が無い
いま 1: 遊びの合否は算術で数える#
採点のスクリプト（Scripts/adv-judge.ps1）は、LLM を使いません。
# 仕組みは3段:
# 1. 凍結したプレイログ（AI初見プレイ 3ペルソナ・どの回かは <work>/judge.json の corpus.dir）から
# **入力列だけ**を取り出す
# 2. いまのビルド・いまのデータへ流し直す（adv-sim replay。エンジンは乱数不使用＝完全決定論）
# 3. 再生成した記録を数える（adv-sim judge。算術のみ）
#
# 同じコミットからは必ず同じ数字が出る。Claude Code は経路に一切入らない。
AI のプレイヤーが出した入力の列だけを使い、AI の感想は使いません。数えるのは、呪文のような言い直しが続いた長さ・話が進まなかった手の連なり・同じ台詞の再生・疑いを向けた相手の数などです。
今の設定ファイル（judge.json）では、これらは 26 項目すべてが計測項目（metrics）で、合否の項目はありません。設定の注記が「judge に合否の項目は無い（ERROR にならず走ることだけを見る）」と書いています。探索的テストの合否は、T48 で書いた「3 人全員がクリアしたか」だけです。
ログに出ない主観（印象に残ったか・人物の好悪・自分の推理と感じたか）は、プレイヤーの質問票で受け取ります。ここでも、申告そのものは判定しません。申告の根拠として引いた台詞が、そのプレイヤーのログに実在するかを機械で照らします。読まずに書いた答えは落ちます。この 3 件も、いまは計測項目です。
いま 2: 読む仕事だけを、読み手に渡す#
算術では見つからない粗があります。
人に遊んでもらって分かったのは、そういう粗でした。台詞の中の食い違い、「はい」と答えたのに話を忘れる返事、まだ出ていないことを知っている台詞。どれも、1 手ずつの数では見えず、通して読むと分かる粗です。
そこで、探索的テストが合格した回にだけ、通読テストを足しました（2026-10-08）。
- 合格した回の 3 本のログを、ノベル形式の確認用テキストにする（台詞と地の文を、出た順に並べる）
- 機械検査で、画面に出る文に作る側の言葉（札・フラグや意図の名前・ファイル名・置き換え忘れ）が 0 件かを見る
- 読み手 3 人（1 本に 1 人）が、頭から終わりまで読んで、決まった型の粗を本文の引用つきで書く
- 引用が本文に一字一句無い指摘は数えない
- 止める型（T1 設定・事実の食い違い／T2 事実と違う返事／T3「はい」で話を忘れる／T4 先出し／T5 作る側の言葉）が 0 件なら合格。N1〜N5 は記録だけ
- その後、作者（人）が確認する。確認の印は人だけが押し、AI は押さない
読み手の定義はこうです（写す）。
1. 読むのは、指示に書かれた確認用テキストのファイル 1 本だけです。リポジトリの他のファイル（台本・設定・世界設定・ほかの読み手の結果）は読みません。
2. 長いファイルは Read の offset と limit で区切って、**頭から終わりまで全部**読みます。読み飛ばしたら readAll を false にします。
3. 指摘は指示の表の種類に当たるものだけです。引用は本文から一字一句そのまま写します。推測で文を作りません。
4. ゲームを遊びません。直しません。結果のファイルを 1 つ Write で書き、書いた件数（種類ごと）だけを返します。
使える道具は Read と Write だけです。
指摘の照合は、スクリプトが行います（写す）。
const has = (q) => typeof q === 'string' && q.trim().length >= 2 && texts.some((t) => t.includes(q.trim()));
…
else if (!has(it.quote)) invalid = '引用が本文に無い';
else if (it.type === 'T1' && !has(it.otherQuote)) invalid = 'T1 のもう一方の引用が本文に無い';
LLM の判定役の弱点のうち、「それらしい理由を作る」には、引用の照合で答えています。読み手が本文に無い文を作れば、その指摘は数えられません。食い違い（T1）は、食い違う二か所の両方の引用を要求します。
第84回（2026-10-10）の通読の結果です。
| 区分 | 件数 |
|---|---|
| 止める指摘（T1 2・T2 6・T3 3） | 11 |
| 記録だけ（N1〜N5） | 71 |
| 引用が本文に無い指摘 | 0 |
| 機械検査の違反 | 0 |
止める指摘が 0 でないので、この回の通読テストは不合格です。記録では、第79〜84回の止める指摘は 30 → 22 → 15 → 13 → 11 → 11 と動き、11 で止まっています（2026-10-10 の引継ぎの記録）。中身には第二章以降の場面が入るので、型と数だけを書きます。
いま 3: 合否に入れない点検#
もう一つ、合否に入れない点検があります（Scripts/adv-audit.mjs）。言い換えの文を 1 つずつ見せて「プレイヤーがこの文を入力したとき、どの意図のつもりか」を選ばせ、登録してある意図と違う答えを、直す候補として拾います。
// q2: items are shuffled; q1 kept them grouped by registered intent, which leaked the target through order.
const QUESTION_VERSION = 'paraphrase-q2';
最初の版は、問いを登録した意図ごとにまとめて並べていて、並びから答えが漏れていました。いまは並びを混ぜています。一般の解説の position bias とは別の向きですが、並びが判定に入る、という同じ型です。
評価の入力（見ない組の問い golden/holdout・事件の設定のファイル case.json・プレイログの置き場）は、点検の束を作るときにパスで拒否しています（コードの注記は「Evaluation inputs must never reach the reader.」）。
作った本人に判定させない#
設計と実装を回す手順（design-cycle）には、こう書いてあります。
判定は作った本人がしない: その回の実装をしていない判定役（新しいエージェント。何を直したかは渡さない。ゴール・絵の場所・手順だけ渡す）に、場面ごとに「左に写っているもの・右に写っているもの・同じものか」を書かせてから判定させる。迷ったら低い方。実装した側は判定役の結果を写すだけで、判定を上げない。
判定させる前に、写っているもの（読んだもの）を先に書かせるのは、引用の照合と同じ考えです。判定の前に、根拠の層を機械で確かめられる形で出させる。
名前どおりでない所 — LLM-as-a-judge#
名前の対照表は、AI 初見プレイと採点のスクリプトを合わせて「playtesting ＋ LLM-as-a-judge」と呼んでいます。ソースを読むと、採点のスクリプトは LLM を使いません。LLM-as-a-judge にあたるのは、通読テストの読み手と、合否に入らない点検だけです。
その読み手も、名前どおりの使い方とは少し違います。点を付ける・二つを比べる、ではなく、決まった型の粗を引用つきで挙げさせ、合否は件数（止める型が 0 か）で機械が決めます。採点者というより、指摘を集める読み手です。
self-preference bias への対処は、「作った本人のセッションに判定させない」と「判定役の入力を確認用テキスト 1 本に絞る」です。ただし、判定役のモデルを作り手と違う系統にはしていません。読み手の定義にはモデルの指定が無く、呼び出す側の設定に従います。Panickssery ほかの結果は、自己優遇が「自分の出力を見分ける力」と結びついていることを示しているので、同じ系統のモデルなら、文脈を切っても偏りが残る余地はあります。うちは、それを引用の照合と、人の最終確認で受けています。
弱点と、採らなかった案 — LLM-as-a-judge#
- 読み手が見落とした粗は、どこにも出ません。止める指摘が 0 でも、粗が無いとは言えない
- 3 人の読み手は、それぞれ 1 本しか読みません。3 本にまたがる粗（ある道筋でだけ出る食い違い）は、その道筋を通った 1 人しか見られない
- 引用が本文にあることと、指摘が正しいことは別です。引用は正しいが、型の当てはめが違う指摘は、照合を通ります
- 1 件ずつ直すと、その箇所は次の回に出なくなりますが、違う道筋を通ると、別の場所から同じ型の粗が出ます。止める指摘が 11 で止まったのは、そのためだと記録されています
採らなかった案:
- LLM に面白さを点で付けさせて、合否に入れる。再現しない点を合否に入れると、同じ版が日によって合格したり不合格になったりする。ユーザーの決定は「精度が下がっても再現性 100%」
- 判定役に作品の設定と台本を渡す。食い違いは見つけやすくなるが、作り手と同じ知識を持つことになり、「初めて読む人に見える粗」ではなくなる
- 別の会社のモデルを判定役にする。系統を変えれば自己優遇は弱まるはずですが、運用（道具・記録・費用の管理）が二重になる。今は、同じ系統のまま距離を取る方を採っています
検索語#
LLM-as-a-judge MT-Bench Chatbot Arena
self-preference bias LLM evaluators
self-enhancement bias position bias verbosity bias
LLM evaluator self-recognition
『霧走町 流氷に眠る』の第一章は、ブラウザで無料で遊べます。AI の読み手が見落とした粗を、人の目で見つけてみてください。プロフィールのリンクから。