AI評価エンジニア: ソフトウェアエンジニアの新領域

問いは二つに絞られる。動くのか、そして先週より悪くなっていないか

企業がAI機能を実際の製品に組み込み始めると、問いは二つに絞られる。「これは本当に動くのか、そして先週より悪くなっていないか」。この二つに数字で答える仕事が、独立したエンジニアリング職務へと分離しつつある。2026年7月、OpenAIは「Separating signal from noise in coding evaluations」を公開し、最も広く使われてきたコーディングベンチマークSWE-bench Verifiedが、設計上の欠陥と汚染によってもはや意味のある信号を出さないと診断した。オープンソースのissueやPRは元々人間の協働のために作られており、問題文・マージされたコード・単体テストが、きれいに隔離された課題として噛み合わないからだ。OpenAIは後継として推していたSWE-Bench Proの推奨さえ、問題を見つけて撤回した。

核心は、リーダーボードのスコアと「自社製品が実際に良くなったか」は別の問いだという点にある。良い評価は、ゲームしにくく、信頼でき、モデルの能力を実際に反映していなければならない。AI評価エンジニアは、この三条件を満たす評価ハーネスを組む人だ。モデルを大きくするチームとは別に、そのモデルが本番で意図どおり動くか、リリース前後で回帰していないかを証明する役割である。AI導入が速い組織ほど、この席が先に必要になる。

リーダーボードを借りてくる仕事ではない

この職務は一般的なバックエンド技能の上に評価特化のレイヤーを重ねる。第一にベンチマークとハーネスの設計。既製のリーダーボードを借りてくるのではなく、自社製品の実トラフィックを反映した評価セットを自ら作り、採点器を接続する。GeneBench-Proが既知の因果構造から問題を生成し決定論的に採点することでルーブリックのばらつきを避けたように、「何を正解とみなすか」を再現可能に固定するのが出発点だ。129問のスイートで最新モデルすら30%前後に留まる事実は、よく作られた評価がいまだにモデルをどれほど選別できるかを示す。

第二に信号と雑音の分離。エージェントベンチマークには環境ドリフト、テストのフレーク、正解リーク、方法論の不透明さ、ベンチマークと本番の乖離という構造的な罠がある。スコア0.5ポイントの差が実際の改善かノイズかを統計的信頼区間で判定し、フレークなテストを除外するのが日々の仕事だ。第三にLLM-as-judgeの較正とオフライン・オンライン評価。採点モデルの偏りと一貫性をメタ評価で再検証し、CIに回帰ゲートを組み込むオフライン評価と、実サービスのログで回すオンライン評価を併用する。AgentDojoが97課題と629のセキュリティケースで、ツールを使うエージェントの敵対的頑健性を測るように、敵対的ケースまで評価セットに入れる感覚も要る。ツールはPython評価エコシステム、トレーシング基盤、統計処理が中核だ。日本の新卒採用でも、AI組織のML基盤・信頼性チームがこの技能を急速に吸収している。

採点器一つから始め、再現可能な基準へ

ジュニアは単一タスクの採点器から始め、評価セットの構成とメトリクス定義を身につける。ここで「何を正解として数えるか」を再現可能に固定する感覚と、フレークなケースを見抜く目を養う。シニアは信号対雑音を分ける統計設計、judgeモデルの偏り較正、大規模トレース処理の性能、そしてデプロイパイプラインに回帰ゲートを埋め込む仕事を担う。リーダー段階では組織のAI品質基準を定義し、オフラインのベンチマークとオンラインの実測を一つの意思決定ループに編み、「出荷してよいか」を制度化する。

典型的な職名はAI評価エンジニア、AI信頼性エンジニア、LLM品質エンジニア、評価基盤エンジニアだ。この職務はML基盤・データエンジニアリング・セキュリティエンジニアリングと隣接し、AI機能を速く出す組織ほど、「動く証明」を担う人が先に必要になる。