評価システムに欠陥ありも利用を推奨 — AI Engineer

AI エージェント開発における「評価システム」の真実：欠陥があるからこそ、今こそ使うべき理由

AI エージェントの開発現場では、「評価（Evals）」が完璧な指標であるかのように扱われる一方で、実は多くの欠陥を抱えているという現実があります。しかし、その欠陥を理由に評価を放棄するのではなく、むしろ「改善のためのツール」として再定義し、実社会での信頼性を担保するための具体的な手法へシフトすべき時です。

本記事では、AI エンジニアが語る「評価システムは破綻しているが、それでも使うべき」という一見矛盾する主張の核心を整理します。単なる数値競争や直感に頼る姿勢からの脱却方法と、実用的な AI を構築するための「ヒルクライミング」戦略を解説します。

評価に対する2つの極端な誤解

現在の AI エンジニアリング界隈では、評価システムに対して二つの極端な誤解が蔓延しています。どちらの立場も、真の価値を見失う危険性があります。

1. 「数値指標への盲信」

多くの開発者が、ベンチマークで出たスコアを絶対的な事実として受け取ります。「GPT-5.4 のスコアと Gemini 3.1 Pro のスコアが同じなら、性能も同等だ」と考えるのは危険です。モデル発表時に提示される数字は、特定のベンチマークに最適化された「近似値」に過ぎないことが多く、実世界での複雑なタスクでは全く機能しないケースが多発しています。

「多くのモデルが似た数値で登場しますが、ある時点でこれらの数値はすべて偽物だと気づきます。これは完全にインチキです。」

2. 「直感や雰囲気への過度な依存」

反対に、「評価なんて意味がない。すべては雰囲気で決まる」と考える立場も同様に誤りです。「オペラが好きなのは、雰囲気が良いから」という回答が正解ではないように、AI の性能を「なんとなく良さそう」という感覚だけで判断することは、再現性のない非科学的なアプローチです。

真実はこの二つの極端の間にあります。評価は「全てを決定する魔法の杖」でもなければ、「全く無意味なもの」でもありません。使い方を間違えれば危険ですが、正しく使えば強力な改善ツールとなります。

既存ベンチマークの限界と「実世界再現」の重要性

現在の主流である標準化されたベンチマークは、すでに時代遅れになりつつあります。OpenAI のブログ記事でも明言されている通り、これらのテストはもはや最先端のコーディング能力や、複雑なインフラトラブルを正しく測定できていません。

例えば、単純なフィボナッチ数列の計算や行列演算では高スコアを出せるモデルでも、実際のソフトウェアエンジニアリングで直面する「MCP サーバーの設定ミス」や「競合状態（デッドロック）」といった問題には対応できないケースが後を絶ちません。これらは、既存のベンチマークが想定していない「文脈」を含む課題です。

「ベンチマークはもはや最先端のコーディング能力を測定していない。現実のソフトウェアエンジニアリングには適用されないからです。」

したがって、開発者が直面する実際の複雑な問題を再現した独自の評価セット（Evaluation Harness）の構築が不可欠となります。これは単なるテスト問題の追加ではなく、ユーザーの実利用データを収集・クリーニングし、ターミナルベースでの自動実行テストを可能にするインフラ整備までを含んだ作業です。

独自評価セットの構築：Terminal Bench の活用

実世界の問題を再現した評価を行うための具体的な手法として、「Terminal Bench」のようなツールが注目されています。これは、89 のコーディング問題を含む評価スイートで、実際の開発環境（仮想マシンやコンテナ）を隔離して実行する仕組みです。

独自評価セット構築のステップ：

1. データ収集とクリーニング: ユーザーとの利用データを取得し、実際のプログラミング課題を抽出します。単なる「猫の指の本数」のようなワンショットの質問ではなく、「新しい MCP サーバーが動いていないので設定して」といった、ファイル読み込み、ドキュメント検索、環境インストール、スクリプト実行を含む一連のタスクに焦点を当てます。
2. 隔離環境での実行: Docker や仮想マシンを用いて、各タスクを独立した環境で実行します。これにより、エージェントがシステムに悪影響を与えずにテストできます。
3. 並列処理とボトルネック特定: Harbor などのツールを活用し、89 のタスクを並列実行してスコアを取得します。失敗したケース（例：50 件中 10 件）を分析し、なぜ失敗したのか（プロンプトの欠陥か、ツールのバグか、モデルの限界か）を特定します。

このプロセスを通じて、「テスト」は単なる採点ではなく、AI エージェントを劇的に改善するための「レバー」として機能します。どの部分を修正すればスコアが上がるのか、その小さな調整ポイントを発見できるのです。

過学習（ハルシニング）を避ける「ヒルクライミング」戦略

評価システムを構築し、スコアを向上させるプロセスにおいて最も重要なのが、「ヒルクライミング（Hill Climbing）」の考え方です。これは、スコアを最大化するためにプロンプトや設定を微調整する継続的な改善プロセスですが、同時に「過学習（ハッキング）」という罠に陥らないよう注意が必要です。

評価結果の分析では、主に3つの改善ゾーンが存在します。

• 明確な欠陥の修正: ハーンネス自体のバグやレート制限など、技術的な問題です。これは即座に修正すべき領域です。
• ニュアンスの改善: モデルごとの特性（例：特定のモデルファミリーには有効なプロンプトが他では無効）に応じた微調整です。プロンプトの長さを変えたり、思考プロセスを指示したりすることで、実用性を高める段階です。
• 危険領域（過学習）: 最高スコアを得るために、テスト問題に特化した不正な設定や、数値だけを追求する行為です。これらは「バイブチェック（直感的な検証）」を通さず、実社会では機能しない AI を生み出します。

「評価指標は完璧なものではなく、改善のためのツールとして捉えるべきです。単に良い数字を得て満足してはいけない。バイブチェックも通さなければなりません。」

開発者は、スコアを上げることと、実用性を担保することのバランスを取る必要があります。数値が向上しても、実際のユーザー体験やシステム全体の安定性が損なわれていては意味がありません。

まとめ：評価を「改善の羅針盤」へ

AI エージェント開発において、評価システムには明らかな欠陥があります。しかし、だからといってそれを捨てるのは非生産的です。重要なのは、既存のベンチマークに盲従せず、実世界の問題を再現した独自の評価セットを構築し、過学習を避けながら継続的に改善する「ヒルクライミング」アプローチを採用することです。

数値だけを追い求める競争から脱却し、評価を「真に実用的で堅牢な AI システムを構築するための羅針盤」として再定義することが、開発者一人ひとりに求められている課題なのです。