LLM評価の基準の作り方。感覚の良し悪しを合否に変える

LLM評価とは、業務においては大規模言語モデルの性能を測ることではなく、AIに任せた仕事の出来を合格・不合格で判定できるようにすることです。評価指標を選ぶより先に、どこから合格かの線を人が引き、AIの判定をその線に合わせ込む作業が要ります。

僕はAIVESTという会社を経営しながら、自分でも手を動かして、AIに仕事を任せる仕組みを設計しています。この記事は、AIに任せた仕事の出来を担当者の感覚でしか判定できていない経営者・AI実践中級者に向けて書きます。

2026年9月時点で「LLM 評価」を検索すると、上位は評価指標のカタログ、ベンチマーク解説、評価ライブラリの比較です。どれも「何で測るか」の話で、「誰がどう合否を決め、判定が人とズレたらどう直すか」は書かれていません。そこを埋めます。

LLM評価とは。業務では「モデルの性能」ではなく「任せた仕事の合否」を測る

研究のLLM評価は、モデル同士を比べる評価です。共通のテスト問題（ベンチマーク）に答えさせ、賢さを点数で並べます。

業務のLLM評価は目的が違います。測るのはモデルではなく、「この1件を納品してよいか」という1件ごとの合否です。この違いを踏まえずに「評価指標を導入する」と話が進むと失敗します。手元の物差しは他社の物差しであって、自社の合格ラインではないからです。

業務のLLM評価が答えるべき3つの問い

• 何を合格とするか（自社の基準。他社のベンチマークではない）

• 誰がそれを判定するか（人か、コードか、別のAIか）

• 判定が人の感覚とズレたとき、どちらをどう直すか

3つ目が抜けているのが、いちばん多いパターンです。判定の仕組みだけ作り、その判定が正しいかを一度も確かめない。目盛りを測っていない物差しで検品しているのと同じです。

担当者の感覚で判定すると、何が起きるのか

症状1: 人によって合否が変わる。Aさんは通し、Bさんは差し戻す。基準が言語化されていないので、どちらが正しいか議論もできません。

症状2: 日によって合否が変わる。忙しい日は通り、余裕のある日は落ちる。品質ではなく担当者の残業時間が合否を決めています。

症状3: 自分の出力を自分で採点すると甘くなる。AIに書かせた原稿を同じAIに確認させると、だいたい通ります。人間も、自分が指示して出させたものは無意識に良く見えます。

評価器づくりで僕が守っている鉄則は「較正されていない判定器をゲートにしない」です。較正されていない判定器に最適化された仕組みは、もっともらしく間違った基準に収束します。生成側をいくら磨いても品質が上がらないのは、間違った物差しに合わせて磨かれているからです。

最初にやるべきは、評価ツールの選定でも指標の勉強でもありません。自分の出力を自分で審査させないことと、人の判定を先に紙に残すことです。

LLM評価指標・評価手法の3系統を、経営の言葉に翻訳する

紹介されるLLM評価方法は、大きく3系統に分かれます。「何が測れて、何が測れないか」で置き換えると、使い分けが決まります。

用語を1行で置き換えます。LLM-as-a-Judge＝AIの出力を別のAIに採点させるやり方。ベンチマーク＝モデル比較用の共通テスト問題。どちらも業務の合格ラインとは別物です。

既存の物差しをそのまま合否にしない理由

統計的指標は「正解文とどれだけ似ているか」しか見ません。禁止表現が入っていても事実が1つ間違っていても、似ていれば高得点になります。==既存の評価指標は「参考値」であって「合否」ではありません。==合否は自社で定義するものです。

合否基準を3層に分解する。形式・機械プロキシ・判断

基準を書き出したら、いきなりAIに読ませてはいけません。まず3層に仕分けます。この仕分けが評価の費用と安定性をほぼ決めます。

L1形式とL2機械プロキシ：コードで数えられるものはコードで落とす

L1形式は、存在・字数・禁止語・必須項目・重複といった、機械が数えれば分かる項目。L2機械プロキシは、人の違和感を機械が測れる量に置き換えたものです。「見出しが少なくて読みにくい」を「見出し3本未満なら不合格」に翻訳する作業がこれにあたります。

このブログの記事も公開前に必ずコードの検査を通ります。2026年9月時点で機械が判定しているのは、タイトル32字以内、抜粋80〜120字、本文2,500字以上、見出し3本以上、よくある質問か手順ブロック1つ以上、内部リンク1本以上、画像2〜5枚かつ全画像URLが実際に200を返すこと、許可外ドメインへのリンクがないこと、危険なコード片7種が混入していないことです。判定はすべてコードで、人が読んで判断する余地はありません。

判断層に回す前に落とせるものを落とすと、AIに読ませる件数が減ります。僕のX運用側の判定器では、コードで先に決着した組が7組、AIに渡ったのは57組でした（2026年9月2日時点の較正ログ）。

L3判断：どうしてもAIか人にしか分からないもの

残ったのが判断層です。訴求がズレていないか、文体が自社の声と合っているか。ここだけをAIに読ませます。基準の書き方は3つ。二値で書く（0〜10点の採点は甘くなり、ブレます）。証拠の逐語引用を必須にする（引用できない合格は認めない）。総合判定はAIに出させない（事実認定までがAIの仕事で、合否の集計はコードがやる）。

人のラベルを先に作る。ブラインドで「正解セット」を用意する手順

基準は願望からではなく、観測から作ります。実際の出力を10件以上集め、AIの判定を見ずに、人が1件ずつ合格・不合格と一言の理由を付ける。この人手のラベル一式が「正解セット」（gold set＝評価器を較正するための人間の正解データ）です。

• ブラインドで付ける。AIの判定を先に見ると人の判断が引っ張られ、較正の意味が消えます

• 過去の事故を必ず入れる。差し戻した実物を「絶対に落とすべき例」として収録します。これが再発防止の資産になります

• 一言の理由を書く。この理由文の集合が、そのまま判定基準表の原文になります。ラベルに由来しない基準を後から発明しない

実データが1件もない立ち上げ期は、良品と「既知の欠陥を1種類だけ埋め込んだ不良品」のペアを最低6組作り、その段階のAI判定は参考値として人の判断を併走させます。僕のX運用の判定器では正解セットが91組あり、うち66組は過去に僕が没にした実物から作った「落ちるべき例」です。

基準を較正する。人の判定との一致率・見逃し率が合格ラインに届くまで直す

正解セットができたら、AIの判定を走らせて人のラベルと突き合わせます。ここで初めて「この判定器は使えるのか」が数字になります。

僕が既定にしている合格ラインは、一致率0.9以上・見逃し0件・判定のブレ0です。見逃しをゼロに置くのは、公開や送信のゲートでは「不良を通す」誤りが致命的だからです。

実測値：91組で一致率0.99・見逃し0件

2026年9月2日に測ったX運用の判定器の結果です。正解セット91組のうち64組で調整し、残り27組は調整に使わない「見せていない問題」として取っておきました。

• 全体の一致率 0.99（91組中90組が人と一致）／κ 0.98

• 見逃し（人が不合格としたのにAIが通した件）0件

• 見せていない27組は27組中27組が一致、判定のブレも0件

• 不一致は1件のみ。提示順を入れ替えると判定が入れ替わる近接ペアだった

ここまで測って初めて「この判定器の判断は僕の判断とほぼ同じだ」と言えます。

見逃しと過剰不合格、どちらのコストを取りますか

判定器は完璧にはならないので、どちらの誤りを許すかを先に決めます。

• 見逃し（false-pass）＝不良を通す誤り。公開・送信・請求・顧客提出のゲートでは致命傷になります

• 過剰不合格（false-fail）＝良品を落とす誤り。量産の途中工程では、手戻りだらけで仕組みが止まります

僕の運用では、公開ゲートは見逃し0件が絶対条件です。較正で見逃しが1件でも出たら、一致率がいくら高くてもゲートには昇格させません。

書き手と検査役を分ける。二層検査の実物

==同じAIに書かせて同じAIに検査させると、必ず甘くなります。==僕がこのブログでやっているのは二層の検査です。

第一層は決定論ゲート、つまりコードによる検査。前述の字数・見出し数・内部リンク・画像・危険なコード片といった項目を機械が数え、1つでも外れたら投稿処理そのものが止まります。裁量はなく、基準の緩和も禁止しています。

第二層が読んで判断する検査で、書き手とは別のAI、あるいは僕自身が担当します。正直に書くと、このブログの記事品質を判定するAIはまだ較正が済んでいません。較正できていない判定器はゲートにしないという自分のルールに従い、現時点の最終判断は僕の公開判断が担っています。僕が没にした理由が3件溜まったら、それを正解セットにして較正する段取りです。

別系統のAIを併走させる

判断層をAIに任せる場合、僕は系統の違うAIを2つ併走させ、どちらか一方でも重大な指摘を出したら差し戻しにしています。同じ系統のAIは同じ見落とし方をするので、2体走らせても意味が薄いからです。

コードの検査を後から足すときも同じです。2026年8月11日に「狙ったキーワードがタイトルと見出しに入っているか」の機械検査を追加したとき、既存の記事34本にさかのぼって走らせました。結果は31本が合格、2本がタイトルにキーワード欠落で不合格、1本が失敗したランの残骸で正当な不合格。検査を足すたびに過去分へ当てて、何本落ちるかを見る。厳しすぎるのか甘すぎるのかが、それで分かります。

記事に限定した品質ゲートの中身はAI記事の品質ゲートの記事に、事実関係の裏取りはハルシネーション対策の記事にまとめてあります。

基準を凍結し、誰が改定するかを決める

評価器は作った瞬間から古びはじめます。やることは3つ。

1. 合格ラインを凍結し、改定できる人を1人に決める。僕の運用では、合格ラインの設定ファイルに「これはrenだけが変える」と書いてあります。AIも自動処理もこの線には触れません

2. 差し戻しを正解セットに追記する。人がAIの判定をひっくり返したら、判定を直すのではなく正解データを増やして測り直します

3. 基準・判定文・使用モデルのどれかを変えたら、正解セットを全部走らせ直す。これが評価器自身の回帰テストです

前述の較正でも、既定ラインでは1件のブレが残り、コードの判定は「較正不足」で終わりました。合格ラインを見直すかどうかは僕が決めて記録に残しました。基準を緩める判断そのものを禁止する必要はありません。禁止すべきは、誰がいつ緩めたか分からない状態です。

指示側で完了条件をどう書くかはAIへの指示設計の記事に、文章の校正だけを切り出した3層運用は次の記事にまとめています。

関連記事AI校正を業務に入れる設計。社内文書のルールを人の修正で育てるAI校正を業務に入れる設計は、禁止語や表記をコードで検査し、読みやすさだけAIに判断させ、人が直した差分を校正ルールに昇格させる3層です。全記事が公開前に通る自社の機械検査と添削記録の実数で解説します。→

明日から始める。最初の2週間の進め方

いきなり全社の評価制度を作ろうとすると止まります。1つの業務、1つの成果物に絞ってください。

2週間で完璧な評価器はできません。できるのは、「担当者の感覚」を「測定できる基準」に置き換えた最初の1本です。効果そのものの測り方はAI効果測定の設計で別に整理しています。

LLM評価のよくある質問

まとめ

LLM評価の基準づくりは、評価指標を選ぶ作業ではありません。合否の線を人が先に引き、AIの判定をその線に突き合わせて較正し、ズレたら正解データを増やして測り直す運用を作る作業です。この順番を守れば、担当者の感覚は「誰が見ても同じ合否」に変わります。