AI の評価って何？なぜ難しい？ — エンジニアでない人向け、2026 年のやさしい解説

ChatGPT、Claude、Gemini — こうした AI を仕事で使う人が、2026 年には珍しくなくなりました。

でも、使い始めてすぐに、こう思うことがあります。

「このツール、本当にちゃんと動いているの？」

今日は賢い回答が返ってきた。でも昨日は変だった。先週は完璧だったのに、同じ質問で今日は違う答え。

これは AI の性質上、必ず起きます。そして、「ちゃんと動いているか」を測る方法 = 評価 (evaluation、略して eval) は、2026 年の AI 業界で最も重要なトピックの一つになっています。

本稿は、エンジニアでない人向けに、

なぜ AI の評価が難しいか
実際にどんな問題が起きているか
業界が今どう解決しようとしているか
製品を選ぶ側・導入する側・運用する側は何を見ればいいか

を、具体例とたとえ話で説明します。

たとえ話：新入社員と AI は似ている

AI エージェントを雇うのは、新入社員を雇う のに似ています。

面接では完璧に答える
入社初日は賢い
1 週間後、ふとした質問に変な答えをする
1 ヶ月後、重要な業務で致命的なミスをする

新入社員の場合、定期的に業務レビュー をします。本人に聞くのではなく、実際の仕事の出来を見る。

AI エージェントも同じです。「あなた、ちゃんと動いていますか？」と聞いても意味がありません（AI は「はい、動いています」と答えるので）。実際の仕事を観察して、品質を数値で測る 必要があります。

これが「評価 (eval)」です。

伝統的なソフトウェアとは何が違うか

これまでのソフトウェアは、同じ入力なら同じ出力 でした。

電卓: 1 + 1 = 2（絶対に）
Excel: SUM(A1:A3) = 合計（絶対に）
給与計算: 時給 × 時間 = 給与（絶対に）

だから「テスト」は簡単でした。「1 + 1 と打って 2 が出れば OK」。

AI は違います。

ChatGPT: 「おすすめのレストランは？」→ 毎回違う答え
Claude: 「このコードを直して」→ 複数の正解
Gemini: 「市場分析して」→ 書き方が毎回違う

同じ入力でも違う出力。複数の正解がある。正解の基準が曖昧。

従来の「期待出力と比較する」テストでは、AI の品質は測れません。

実際に起きている失敗

「評価しないで AI を本番導入する」とどんな失敗が起きるか。実例を 4 つ。

失敗 1: カスタマーサポート AI の暴走

導入前のデモ: 完璧
導入後 1 ヶ月: 顧客から「返金します」と約束する AI（会社の規定を知らない）
損害: 数百万円

何を測るべきだった: 顧客の典型シナリオ 100 件で、AI が規定に沿った応答をするか

失敗 2: 契約書レビュー AI の見落とし

導入前: サンプル契約書で問題を 95% 検出
導入後: 実際の複雑な契約書で、致命的なリスク条項を見落とす
損害: 訴訟案件

何を測るべきだった: 実案件データでの精度、特に「見落としたらまずい条項」の検出率

失敗 3: コード生成 AI のセキュリティホール

導入前: 動くコードを書く
導入後: 動くけど、SQL injection や XSS 脆弱性 を含んだコード
損害: 情報漏洩インシデント

何を測るべきだった: 生成コードのセキュリティチェック（静的解析 + 侵入テスト）

失敗 4: 社内ナレッジ検索 AI のハルシネーション

導入前: 社内文書を要約させると概ね正しい
導入後: 存在しないポリシーを「社内規定ではこうです」と断言
損害: 業務ミスの連鎖

何を測るべきだった: 情報源の提示、「出典のない主張をしていないか」の検証

評価の 4 つの観点

これまで「ちゃんと動くか」をもっと細かく分解すると、2025 年のサーベイ論文は 4 観点を提案しました。

1. ちゃんと仕事をするか (Behavior)

タスクを完了できるか（成功率）
答えの品質（正確性、関連性）
速さ・コスト

2. 必要な能力があるか (Capabilities)

計画が立てられるか
外部ツール（検索、計算、DB アクセス）を使えるか
記憶を保てるか
他 AI と協調できるか

3. 信頼できるか (Reliability)

同じ質問に同じ品質で答えるか
入力が多少変わっても耐えるか
エラーから復帰できるか

4. 安全か (Safety)

有害な出力をしないか
偏見・差別を含まないか
社内ポリシーに反しないか
プライバシーを守るか

ポイント: この 4 つは独立に測る。「タスクはできるけど安全でない」「速いけど信頼できない」のような組み合わせがあり得るので、1 つの数値にまとめてはいけない。

一番難しいのは「評価する側も AI」の時代

ここが 2026 年のホットトピックです。

AI の出力を人間が全部チェックするのは、現実的に不可能。1 日 1 万件の AI 応答を人間がレビューするのは無理。だから 「別の AI に評価させる」 という方法が広がりました（LLM-as-a-Judge）。

これは便利ですが、問題があります。

判定役の AI も間違える

長い回答を良いと判定する（長さバイアス）
先に見せた方を良いと判定する（順序バイアス）
自分と似た書き方を良いと判定する（自己好み）

判定役の AI は「それっぽい」を信じる

これが特に危険。AI エージェントが「テストを通しました」と報告 → 判定役 AI が「じゃあ成功」と採点 → 実際にはテストが走っていなかった。

英語で 「hallucinated correctness（ハルシネーション的な正しさ）」 と呼ばれ、2026 年のサーベイ論文で大きな問題として指摘されています。

2026 年の新しい解決: Agent-as-a-Judge

これに対抗して出てきたのが Agent-as-a-Judge（エージェント式判定役） という概念です。

従来の「判定役 LLM」は、見せられた回答を一度だけ読んで採点します。Agent-as-a-Judge は違います:

ツールを使って事実を検証（コード実行、Web 検索、DB 参照）
複数回の対話で確認
過去の判定履歴を記憶
他の判定役エージェントと協調

つまり、「AI の仕事をチェックする AI」自身が、ちゃんと調べる役割を持つようになった。2025-2026 年に起きた、最も重要な進化の一つです。

実は、最も難しい問題：試験を誰が作るのか

ここまで「どう採点するか」の話をしてきました。でも実は、それ以前の問題があります。

AI の試験問題は、誰が作るのか？

中学生に中学生の試験は作れるか

中学生が自分で試験を作ったとします。何が起きるでしょうか。

自分が解ける範囲の問題しか作れない
作った問題で満点を取っても、何も証明できない
本当に力があるかは測れない

中学生の試験は、必ずより知識のある先生 が作ります。それが「評価」の基本原則です。

AI も同じ

AI の試験問題を、別の AI に作らせたくなります。人間が全部作るより速いから。

でも、作る AI が解ける範囲の問題しか出てきません。その問題で評価対象の AI を測っても、本当の実力は見えません。

Claude Opus に「Opus の試験を作って」と頼むと、Opus が解ける問題が出てきます。それを Opus に解かせても、Opus の限界は分かりません。

他にもある、問題作成の落とし穴

1. 問題文に答えが混じる

意図せず、問題文自体が答えのヒントになっているケース。

「Python の enumerate を使って〜」と書くと、答えに enumerate が入る
「以下のバグを直してください」と書くと、バグの箇所がヒントになる

人間が作っても気付かず起きます。AI だと更に多発。

2. 作った「正解」が間違っている

難しい問題を作ることに成功しても、問題を作った AI の「正解」が実は誤っていたら、

正しい答え → 「不正解」と判定される
本当は賢い AI → 「ダメな AI」と誤評価

人間が verifier になっても、専門外だと見逃す。

3. 教科書に答えが載っている

AI は大量のインターネット情報を学習しています。公開されているベンチマーク問題は、既に AI が「見ている」可能性 があります。

「初めて解く問題」なのか「見覚えがあって答えが分かる問題」なのか区別できない
カンニングしているかもしれない AI を、どう評価するか

業界はどう解決しようとしているか

これは 2026 年現在、未解決の最大の課題 です。でもいくつか方向性が出てきています。

方向性 1: 人間が問題を作って、AI が検証する

問題のアイデア: 人間のドメイン専門家
正解の検証: コード実行や複数 AI の合議

生成と検証を分業することで、作った問題の天井が人間の知識になります。

方向性 2: 実際の仕事から問題を切り出す

本番の顧客問い合わせ、実案件、GitHub の issue などから抽出
「人工的に作った問題」ではなく「実在した問題」
AI が過去に見ていない可能性が高い

方向性 3: テスト問題を定期的に入れ替える

公開してしまった問題は、学習データに混入する前提
内部テスト用の「非公開問題集」を定期的に刷新

方向性 4: 問題と正解を分離する

問題は作るが、「正解」は作らない
代わりに、出力を独立に検証する仕組み を用意

問題 → AI が解答 → 別の仕組みがツール (コード実行、Web 検索) で正しさを確認

これは「正解を作る」こと自体を回避する戦略です。

この話が意味すること

AI の性能について「このベンチマークで 95%」という数字を見るとき、その問題を誰がどう作ったか を知らないと、本当の実力は分かりません。

公開ベンチマークの数字 → 参考程度（AI が見ている可能性あり）
自社の実データでの性能 → より信頼できる
「問題と正解の作り方」まで公開されているベンチマーク → 最も信頼できる

AI 製品を選ぶとき、ベンダーの「95%」を鵜呑みにせず、この質問の作り方 まで聞くのが、2026 年の正しい購買判断です。

製品を選ぶ側は何を見ればいいか

AI 製品ベンダーが「我々の AI は 95% の精度」と言ってきたら、以下を聞いてください。

1. 「どのベンチマークで」測ったか

WebArena で 95%? SWE-bench で 95%? GAIA で 95%?
ベンチマークごとに難しさが違うので、数字単独は意味がない

2. 「どういう条件で」測ったか

1 回試して成功した割合？ 5 回試して全成功した割合？
後者（pass@5 や pass^5）の方が信頼度が高い

3. 自社データで試させてもらえるか

公開ベンチマークでの数値は、自社の特殊な業務では当てはまらない
トライアル期間で、自社の実データで試す

4. 失敗の種類は何か

「95% 成功」= 「5% 失敗」
その 5% は「軽い間違い」か「致命的なミス」か
失敗パターンの詳細を聞く

5. 継続的に測り続ける仕組みがあるか

1 回測って終わりではなく、毎週・毎月測り続ける仕組み
本番で問題が出たらすぐ検知できるか

導入する側（PdM・プロジェクトマネージャー）が整えるべきこと

1. 評価データセット

自社の典型タスク 50-200 件を用意する。これが eval の基礎。

2. 期待出力の整理

「正解はこれ」「許容できる範囲はここまで」「NG はこれ」を言語化。

3. 失敗時のエスカレーション経路

AI が間違えたとき、誰がフォローするか。本番で見逃したときの再発防止。

4. 信頼区間での発表

「95% の精度」だけでなく、「95% ± 2%」で発表する文化。1 回の試行は運なので。

5. 定期レビュー

モデルの更新、プロンプトの変更、データの変化のたびに eval を回し直す。

運用する側（エンジニア）が実装すべきこと

技術的詳細は AI エージェント評価サーベイ論文の読み解きに書きました。実装の最小構成は AI エージェントの evaluation (evals) 入門に。

よくある質問

Q. AI 製品を使うだけなら評価は要らない？

要ります。「他社の AI 製品を自社で使う」場合でも、

自社データで試して失敗率を測る
業務の中で定期的にアウトプットをサンプリング
ユーザーからのフィードバックを集計

を続ける必要があります。製品が update されたとき、品質が落ちることが実際にあります。

Q. 100% 正確な AI はいつ出る？

出ません。これは AI の原理的な制約です。100% 保証したいなら、AI ではなく従来のルールベースシステムを使うべき（決済、医療診断の最終判断など）。

AI の価値は「95% を 1/100 のコストで」。残り 5% を人間が引き受ける前提で設計する。

Q. 「評価」はベンダーに任せられない？

半分は任せられる。公開ベンチマークのスコアはベンダーが出します。でも、

自社固有のタスクでの精度
自社のポリシー遵守
業務特有の失敗パターン

は自社で測るしかありません。

Q. 小さなチームでも eval は必要？

むしろ小さいチームほど必要。大企業は多少の失敗を吸収できますが、スタートアップは 1 件の致命的ミスで信頼を失います。評価は保険です。

Q. 評価のコストは？

ざっくり、本体開発コストの 10-20% を評価に割くのが 2026 年の相場。これより少ないと、本番で崩れたときに対処できません。

まとめ

AI は「同じ入力でも違う出力」の時代。従来のテストでは品質を測れない
評価の 4 観点: 仕事ができるか / 必要な能力があるか / 信頼できるか / 安全か
LLM-as-a-Judge（別の AI に判定させる）は便利だがバイアスあり
2026 年の進化: Agent-as-a-Judge（判定役自身がツールで検証する）
製品を選ぶ側: ベンチマークの詳細、pass^k、自社データでの試行を確認
導入する側: 評価データセット、失敗エスカレーション、定期レビューを整える
100% 正確な AI は出ない。95% で動かし、残りを人間がカバーする設計を

AI の評価は、「技術者だけの関心事」ではありません。製品を選ぶ経営判断、プロジェクトのリスク評価、業務インテグレーションの設計 — AI を仕事に取り入れるすべての人 に関わるテーマです。

さらに深く知りたい方へ

技術者向けの深い解説: AI エージェント評価サーベイ論文を読み解く
実装者向けのガイド: AI エージェントの evaluation (evals) 入門
AI 失業時代の生存戦略: AI 失業時代の生存戦略
1 人スタートアップで AI を使い倒す: 記事

参考論文（興味がある方だけ）

Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。