バグなら落ちます。「これで良いのか」は落ちません。
専門外の分野をAIエージェントに作らせると、良し悪しを判定できないまま完成品が手元に残ります。判定できる人を用意しないと、平均が出荷される。
そのための3つの型と、6分野・指示80件で測った効き目です。実例として3Dの背景を使いますが、話の軸は3Dではなく「専門外のものをどう評価するか」です。
結論
- 専門外では出力を評価できない。これは構造的な問題で、気をつけても直らない
- 「AIに評価させる」は循環する。評価者が正しいかを評価できない
- 判定を 真偽（機械化できる） と 良否（人間しか決められない） に分ける
- 良否は、質問を出させて選ぶ／候補を並べて比べる／選んだ理由を1行言わせるの3つで、作りながら育つ
- 実測では、6分野すべてで2〜11日で「原因を名指しした指摘」が出せるようになった（ただし観測窓は13日）
1. 評価できない人が発注すると、平均が返ってくる
自分で作れないものを人に頼むことは、昔からできました。ただし受け取ったものを検分できる範囲でしか、頼めなかった。
Kruger & Dunning (1999) が冒頭で書いているとおりです。
In short, the same knowledge that underlies the ability to produce correct judgment is also the knowledge that underlies the ability to recognize correct judgment. To lack the former is to be deficient in the latter.
正しい判断を産み出す知識と、それを見分ける知識は同じところから来る。片方を欠けば、もう片方も欠ける。
以前は壁の越え方が学習しかなく、その数か月〜数年が参入を止めていました。エージェントが外したのは制作の側だけで、判定の側は外していません。
実例 — 私は3Dで止まった
サウンドノベルの背景。同じ場所の360°パノラマを、12日で6回作り直しています。素材は KitBash3D、レンダリングは Blender。どちらも専門外でした。
左上が最初、右下が完成版。並べれば違いは分かります。1枚ずつ出てきたときに言えるかが問題でした。
2. 「評価もAIにやらせる」は循環する
採点もエージェントにやらせればいい。そう考えてやってみました。回りませんでした。採点は返ってきますが、その採点が甘いのか辛いのか、こちらに判定できない。
第4版のコミットメッセージには「全方位を密なスラム建物で囲む閉塞感」と書いてあります。エージェントが書いた文で、やったことと合っています。床が一面のっぺりしていることは、書いてありません。 自己申告は、指示に答えた部分しか報告しません。
自分の感覚も当てにならない
METRの実測（平均5年の経験を持つ開発者16人、自分が熟知したリポジトリで246タスク）。
| 値 | |
|---|---|
| 事前の予測 | AI利用で24%速くなる |
| 終了後の自己評価 | 20%速くなった |
| 実測 | 19%遅くなっていた |
熟知した領域で、この幅です。
Microsoft Research + CMU の CHI '25 論文（ナレッジワーカー319人、一次事例936件）も添えておきます。
higher confidence in GenAI is associated with less critical thinking, while higher self-confidence is associated with more critical thinking
自己申告のサーベイなので因果は言えませんが、検証の量を決めているのが出力の中身ではなく使う側の自信の所在だった、という向きは読めます。
判定を2つに割る
| 真偽 — 正しいか | 良否 — 良いか | |
|---|---|---|
| 問い | 指定したものを使ったか／参照先は実在するか／数字は出典と一致するか | これは狙ったものになっているか |
| 決めるもの | 外部の事実 | 人間 |
| 機械化 | できる | できない |
| 門外漢の対処 | スクリプトに落として毎回走らせる | 自分を育てるしかない |
真偽を機械に出さないと、良否を見る余力が残りません。以下は良否だけを扱います。
3. 判定はできないが、選ぶことはできる
足場は1つだけです。「AとBなら、Bのほうが自分の頭の中にあるものに近い」は、外の基準を必要としません。
型1. 決めるべきことを、列挙させる
何を決めるべきかを知らないので、良い質問は書けません。質問ごと出させます。
この作業で私が決めないといけないことを、重要な順に5つ挙げて。
それぞれ選択肢と、選択が結果に与える違いも書いて。
返ってくる一覧が、その分野の評価軸のリストになります。背景でやると「視点の高さ」「霧の量」「光源の色温度」「素材の密度」が並びます。第1版のときにこれを見ていたら、「暗い」以外の語が4つ、目の前にありました。
型2. 候補を並べて、差を見る
2案出して。案ごとに「何を狙って、どこを変えたか」を1行で書いて。
1つでは判定できませんが、2つの差なら判定できます。差分がそのまま評価軸になる。 3案までにします。5案出すと選べなくなり、「おまかせで」に倒れます。
| 第3版 | 第6版 | |
|---|---|---|
| 狙い | 明るさを優先 | 密度を優先 |
| 見た目 | 建物は見えるが床が空 | 暗いが物が詰まっている |
| 明るさ | 79.4 | 19.2 |
| 密度 | 4.11 | 4.47 |
型3. 真偽は、機械に検算させる
指定したものを使ったか、参照先は実在するか、出力の仕様は合っているか。ここを目で見ている限り、良否を見る余力は残りません。
3つに共通する条件 — 選んだ理由を1行言わせる
私がその案を選んだ理由を、私の言葉で1行にして。
その文が次の依頼文になります。借り物の言葉で構いません。私の場合、同じ語を3回ほど使ったあたりで、調べ直さずに書けるようになりました。
13日間で打った指示は80件、1日6件です。多くありません。効いたのは回数ではなく、1周の待ち時間が数時間から数分になったことでした。
4. 効き目を測る
効いたかどうかは、自分の指示が変わったかで見ます。
入ってきた順は、状態だけ、部位、理由、原因の用語。
最初の語彙は、1本の軸しか持っていなかった
from PIL import Image
import numpy as np
def metrics(path):
a = np.asarray(Image.open(path).convert("L").resize((1280, 640)), dtype=np.float32)
lum = float(a.mean())
lo, hi = np.percentile(a, 1), np.percentile(a, 99) # 明るさの影響を外す
b = np.clip((a - lo) / (hi - lo) * 255, 0, 255)
detail = float((np.abs(np.diff(b, axis=1)).mean()
+ np.abs(np.diff(b, axis=0)).mean()) / 2)
return lum, detail
# 既知の正解でassertを置く（集計スクリプトは平気で嘘をつく）
flat = np.full((64, 64), 100.0, dtype=np.float32)
assert float(np.abs(np.diff(flat, axis=1)).mean()) == 0.0, "無地の輪郭量は0のはず"
第1版と第6版は明るさがほぼ同じ（23.5 と 19.2）で、密度は 1.73 と 4.47 で2.6倍違う。第1版が暗いのは何も置かれていないから、第6版が暗いのは物で埋まったうえで光を落としてあるからです。最初に打った「背景が真っ黒」は、この2つを区別しない語でした。
密度も万能ではありません。第3版は4.11、第6版は4.47で、数字はほとんど同じなのに見た目は別物です。2軸でも足りない。
3Dだけの話ではなかった
Claude Code は ~/.claude/projects/<プロジェクト>/<セッションUUID>.jsonl に全会話を残しています。ここから自分が実際に打った文だけを抜きます。ツール結果や、コンテキスト圧縮時に自動挿入される要約が混ざるので除外が必要です。
import json, glob, os
AUTO = "This session is being continued from a previous conversation"
rows = []
for f in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
with open(f, encoding="utf-8", errors="ignore") as fh:
for line in fh:
try:
o = json.loads(line)
except Exception:
continue
if o.get("type") != "user" or o.get("isMeta"):
continue
c = (o.get("message") or {}).get("content")
if isinstance(c, list): # text ブロックだけ拾う
t = "\n".join(x.get("text", "") for x in c
if isinstance(x, dict) and x.get("type") == "text")
else:
t = c if isinstance(c, str) else ""
t = (t or "").strip()
# ツール結果・system-reminder は "<" 始まり、圧縮要約は AUTO を含む
if not t or t.startswith("<") or AUTO in t:
continue
rows.append((o.get("timestamp", ""), t))
rows.sort()
assert any("真っ黒" in t for _, t in rows), "既知の1件が拾えていない"
print(len(rows))
80件を手作業で分類しました。
| 分類 | 定義 | 件数 |
|---|---|---|
| 新規依頼 | これから作るものの指定。評価ではない | 35 |
| 感想型 | 直してほしい状態だけを書いた指摘 | 19 |
| 診断型 | 原因・部位・パラメータ・設定の矛盾を名指しした指摘 | 21 |
| 催促・別件 | 「続けて」など | 5 |
最短2日、最長11日。ただしログは13日分しかないので、2週間以上かかった分野があってもこの図には出ません。 作曲は7月20日開始で観測窓が3日しかなく、「2日」が短いのは期間が短いせいでもあります。
原因を名指しした指摘の割合は、前半14%から後半73%へ。
この数字が言えないこと
- 分類は筆者の手作業で、境界は主観です。判断材料になるよう、元の文は原文のまま図に載せました
- 指摘は前半14件・後半26件で、後半のほうが指摘そのものが多い。作業量の偏りで診断型が増えて見えている可能性は排除できていません。言えるのは「割合が入れ替わった」まで。前半の14%は実体としてたった2件です
- n=1 の事例です。一般化された主張ではありません
5. チェックリスト
- 最初の1問は「何を決めるべきか5つ挙げて」。いきなり作らせない
- 選ぶ。選んだ理由を1行書かせる
- 出力は2〜3案まで。案ごとに狙いと変更点を書かせる
- 真偽の検査はスクリプトへ。人間は良否だけを見る
- 毎回1つ、覚えた用語を使って自分から指摘する。 私は、使わなかった語をひとつも覚えていません
- 完成させて、公開する。 公開して初めて、自分の判定が当たっていたか分かりました
効いた実感があるのは5と6です。ただし比較していないので、1〜4を抜いたらどうなったかは分かりません。
落とし穴
| やってしまうこと | 何が起きるか |
|---|---|
| 「おまかせで」と答える | 軸の一覧をもらって、見ずに捨てている |
| 候補を5案以上出させる | 選べなくなり、結局おまかせに倒れる。3案まで |
| AIに採点させて終わりにする | 循環する。採点は下読み、決定は自分 |
| 状態だけを言い続ける | 方向が伝わらないので直らない。毎回「どこが」を1つ足す |
| 1回で見切る | 第3版で止めていたら、あの床のまま出していた |
質問も、候補出しも、検算も出せます。出せないのはどれを選ぶかと、違うと認めることの2つでした。
成果物と出典
6枚目の背景は、『正解の外側』第2話の廃棄層で360°見回せます（インストール不要・ブラウザ完結）
https://yuichi916.github.io/seikai.html
図つきの完全版
https://yuichi916.github.io/method/mongaikan-no-mekiki.html
参照した調査
- Justin Kruger & David Dunning, "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments", 1999
- Hao-Ping Lee et al., "The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers", CHI '25, 2025
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", arXiv:2507.09089, 2025