--- published_at: '2026-09-20T04:00:00+09:00' issue_date: '2026-09-20' title: AIに作らせた案を、その場で採点させない。見落としを減らす評価の分け方 source_record_ids: - 01M193BD5E1BMWAN5M3XBM47RM eyecatch: keyword: AI Evaluation brand: default default_reason: 特定製品ではなく、AI生成物を作成側と切り離して評価する方法が主題のため。 distributions: - name: note url: https://note.com/naru_kijima/n/n2f20009384fa - name: Substack (Japanese) url: https://narukijima.substack.com/p/ai-1d8 - name: X Share (Japanese) url: https://x.com/narukijima/status/2101378102928769514 - name: Threads (Japanese) url: https://www.threads.com/@naru_kijima/post/DdeqVeCAcrX - name: Bluesky (Japanese) url: https://bsky.app/profile/narukijima.bsky.social/post/3mvvd6qxwrk2k - name: Facebook (Japanese) url: https://www.facebook.com/permalink.php?story_fbid=pfbid08UXhems6DB18n1vdVXkkXi4UUtTDSTvMA46MMx8afh8y3AxbjAZSr39LPjZeNowbl&id=100063878600682 id: '2026-09-20' source: visibility: private source_id: private:daily:2026-09-20 transformation: ai-edited-secondary image_path: /images/daily/2026-09-20.png content_sha256: b2f6dd31dba649102702e1814b45ba730a190ca8e66db68ef132e3c7e6d2cc2d content_length_bytes: 10662 rights: license: CC BY-NC-ND 4.0 license_url: https://creativecommons.org/licenses/by-nc-nd/4.0/ terms: https://narukijima.ai/terms/ attribution: Naru Kijima / narukijima.ai — usage: ai_input: allowed search: allowed quotation: allowed-with-attribution ai_training: reserved-subject-to-existing-rights commercial: requires-separate-permission redistribution: allowed-under-CC-BY-NC-ND-4.0 dataset_inclusion: reserved-subject-to-existing-rights impersonation: prohibited scope: Existing CC license grants and applicable statutory exceptions take precedence. These signals do not record assent or enforce access control. --- AIに案を作らせたら、評価は別の会話に分け、合格条件だけ先に渡すと、作り手の思い込みを引きずりにくくなります。 AIに企画書を書かせた。コードも直してもらった。最後に同じ会話で「これで問題ない？」と聞く。AIは丁寧に見直して、「大きな問題はありません」と返す。そこで安心して次へ進んだら、あとで条件漏れが見つかる。 この流れは手軽ですが、作る役と採点する役が混ざっています。見落とした条件や、途中で置いた前提まで同じ会話が引き継ぐので、確認が「別の目」になりにくい。間違えたときに失うのが数分なら気にしなくていい。でも、公開、発注、実装、採用判断のように、やり直しが時間・お金・信用に響く仕事では、評価だけ切り離す価値があります。 この記事で伝えたいのは、AIを信用しないという話ではありません。AIに作らせる仕事が増えたからこそ、「作る」「評価する」「採用を決める」を分けると、何が確認済みで、何がまだ不明なのかを見失いにくくなる、という話です。 --- ## AIに相談する人が増えるほど、「誰が評価するか」が重要になる 2026年9月10日に公表されたAwarefyの調査では、対話型生成AIの利用経験者約1,000人を対象にした調査で、「アイデアを出してほしい」は69.5%、「相談にのってほしい」は46.4%でした。「相談にのってほしい」は2025年8月の33.0%から13.4ポイント増えています。週1回以上使う人も90.6%、毎日使う人は36.8%でした。 これは「AIの案を別のAIで評価すべきだ」と直接示した調査ではありません。分かるのは、AIが検索だけでなく、相談やアイデア出しの相手としてかなり使われていることです。 相談相手が答えを作るだけなら、そこで終わることもあります。ところが、AIが企画、文章、コード、比較表、研究計画まで作るようになると、次に出てくるのは「この成果物は使っていいのか」という問題です。 ここで、作ったAI自身にそのまま採点まで任せると、便利さと引き換えに役割が一つに固まります。人間でも、自分で書いた文章の誤字を見落としたり、自分で立てた計画の弱点を後から気づいたりします。AIでも、評価を別工程にした方がいい場面があります。 --- ## 僕は「全部通った」を、そのまま採用の根拠にしなくなった 2026年9月、僕はAIエージェントの仕組みを研究していました。実装側では、事前に決めた工学的な確認項目を修正し、最終版で68個の固定チェックが68個とも通りました。 ここだけを見ると、「では次の本番実験へ進もう」と言いたくなります。 でも、その68個を通したのは、修正した側と同じ実装工程の検証です。僕はこれを「独立した受入評価」とは扱いませんでした。成果物を凍結し、別の会話・別の評価工程へ渡しました。 その評価では、工学修正そのものは限定的に受け入れられました。一方、本番相当の実験を始めてよい、とはなりませんでした。実験用の子プロセスを外部通信や書込先から隔離できている証拠が不足していたからです。結論は「修正は受入、ただし正式実験はまだ許可しない」。次の作業も、実験開始ではなく、隔離をどう証明するかの確認へ変わりました。 ここで大事なのは、68/68が間違いだったということではありません。その68個が答えていた問いと、「本番へ進んでよいか」という問いが違っていたことです。 固定チェックは、「決めた条件を満たしたか」を見ます。独立評価は、「その条件だけで次へ進んでよいか」「確認していない前提が残っていないか」を見ます。両方を同じ合格という言葉でまとめると、確認済みの範囲が膨らんで見えます。 別の研究でも、16試行を終えたあと、比較した二つの方法はいずれも8/8で処理を完了しました。しかし独立評価では、方法の差を識別できるだけの証拠にはならないと判断し、実務の標準手順へ昇格させませんでした。 「動いた」と「良いと分かった」と「採用してよい」は、別です。 --- ## まず成果物を凍結してから、評価へ渡す 僕が今いちばん重要だと思っているのは、評価を始める前に成果物を固定することです。 同じ会話で「採点して、悪ければ直して」と頼むと、評価中に成果物が変わります。最初の案が何点だったのか、何を直したから通ったのか、そもそも同じものを評価しているのかが曖昧になります。 そこで、まず「これを評価対象にする」という版を決めます。文章なら完成稿、コードならコミットやファイル一式、企画なら提案書の版を固定する。評価側には、その成果物と評価条件を渡します。 僕なら、評価条件は四つに絞ります。 一つ目は、何を満たせば合格なのか。二つ目は、何が一つでもあれば不合格なのか。三つ目は、証拠が足りないときに「不明」を許すこと。四つ目は、評価後に誰が採用を決めるのかです。 この四つがないと、AIは親切に穴を埋めてしまいます。情報が足りないのに推測で「おそらく問題ない」とまとめたり、評価しながら改善案を混ぜたりする。改善案は役に立ちますが、合否判定と混ざると、元の成果物が通ったのか、修正案なら通るのかが分からなくなります。 --- ## 「別の会話」にするだけで完全に独立するわけではない ここは誤解しやすいところです。 新しい会話を開けば、科学的に完全な独立評価になるわけではありません。同じモデルを使えば、似た知識や癖を共有します。評価基準そのものが間違っていれば、会話を分けても同じ方向へ誤ります。 それでも、会話を分ける意味はあります。制作中の言い訳、途中で捨てた案、作り手自身の「ここは大丈夫だろう」という前提を、そのまま評価側へ持ち込まずに済むからです。 研究でも、LLMを採点者として使うときの偏りは確認されています。2026年のEACL論文では、コード評価を行う複数のLLMで、変数名やコメント、見た目の複雑さなど、本来の正しさとは別の表面的な違いによって評価が上下する現象が報告されました。 別の2026年の研究では、誰が作ったかを伏せた評価では自己ひいきが大きく弱まる一方、「自分の出力」「他者の出力」というラベルを付けるだけで点数が動く結果が示されています。 だから、比較するときは、必要がなければ作者名やモデル名を評価側へ見せない。A案・B案のようにラベルを中立にする。順番で評価が変わりそうなら、A→BだけでなくB→Aでも見る。こうした小さな分離でも、余計な情報に引っ張られる余地を減らせます。 --- ## どこまで分ければいいかは、失敗したときの損失で決める 何でも別AI、別モデル、別の人間に回せばいいわけではありません。 SNSの一文を少し整える。自分だけが使うメモを要約する。失敗してもすぐ戻せる。こういう仕事なら、同じ会話で作って見直して終わる方が速いです。 分ける価値が大きいのは、間違えた後の修正費が高い仕事です。公開記事、顧客へ出す資料、長く使う自動化、課金が発生する実験、権限を扱う処理、採用・投資・契約に関わる判断などです。 僕なら、三段階にします。 低リスクなら、同じ会話で自己点検する。中リスクなら、成果物を固定して新しい会話で評価する。高リスクなら、別会話だけでなく別モデル、実測、公式資料、人間の確認のどれかを追加する。 このとき、AIの評価を人間の反応へ読み替えないことも重要です。「この文章は読みやすい」とAIが判定しても、実読者が最後まで読むとは限りません。「この漫画は面白い」とAIが説明できても、人が笑った証拠にはなりません。 評価者を分けても、測っていないものは測ったことになりません。 --- ## 作るAIより、評価の入口を先に決める AIを使うと、作る速度はかなり上がります。案を10個出す、コードを直す、文章を一気に書く。ここは分かりやすく速くなります。 その結果、これから詰まりやすくなるのは制作より評価だと思っています。成果物が一日に何十個も出てくるのに、「どれを使っていいか」の判定が同じ速度で整っていないからです。 僕自身の研究でも、実装が通ったあとに独立評価を置いたことで、「修正できた」と「正式実験へ進める」を分けられました。別の比較では、両方が動いたのに差を証明できなかったので、採用を見送りました。もし全部を「成功」でまとめていたら、次の判断は変わっていたはずです。 AIに何かを作らせる前に、最後に誰が、何を根拠に、どの条件で通すのかを決めておく。 作るAIを増やすより先に、この評価の入口を一つ作る。その方が、速く作れる時代には効いてくると思います。 --- ## 参考にした公開資料 - [Awarefy「AIと人との関係性 推移調査 2026年8月」](https://prtimes.jp/main/html/rd/p/000000125.000057374.html) - [Moon et al., “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation”](https://aclanthology.org/2026.findings-eacl.70/) - [Chae et al., “Self- and Other-Labels Induce Bidirectional Bias in LLM Judges”](https://arxiv.org/abs/2608.18091) --- © Naru Kijima — CC BY-NC-ND 4.0. 利用前に利用規約（https://narukijima.ai/terms/）を確認してください。検索・AIへの入力・出典付き引用を認めます。AI学習・データセット収録には権利を留保し、追加の許諾は行いません。既存のCC BY-NC-ND 4.0による許諾と法定例外は妨げません。なりすましは禁止です。出典表記: Naru Kijima / narukijima.ai — 。検証: https://narukijima.ai/verify/。取得だけで同意を記録する仕組みではありません。 Review the Terms (https://narukijima.ai/terms/) before use. Search, AI input, and attributed quotation are permitted. Rights are reserved for AI training and dataset inclusion; no additional permission is granted for these purposes. Existing CC BY-NC-ND 4.0 grants and statutory exceptions remain unaffected. Impersonation is prohibited. Attribution: Naru Kijima / narukijima.ai — . Verification: https://narukijima.ai/verify/. Fetching alone does not record assent.