これは、Evals / Evaluation Engineering について個人的に学ぶためのメモ。
業務への適用も将来的には考えたいが、まずは「自分自身がEvalsを理解すること」を目的とする。 現時点ではEvalsについて初学者であり、専門職としてのEvals Engineerを目指すと決めているわけではない。
自分はAndroidエンジニアなので、
「Android / Software Engineerとして、AI時代にEvalsの考え方をどう取り入れるか」
という観点で学びたい。
以下のイベントを視聴予定。
「Evalsエンジニア」という専門職の役割を見かけたものの、これまでEvalsに関する体系的な知識がほぼなかったため、基礎から理解したいと思った。
Evalsは、
「LLMやAI Agentの出力・行動について、感覚ではなく、一定の評価基準を使って継続的に品質を測る仕組み」
と理解している。
通常のソフトウェア開発では、期待値との完全一致をテストしやすい。
flowchart LR
Input["Input"] --> Program["Program"]
Program --> Output["Output"]
Output --> Compare{"Expected Value と比較"}
Compare --> PassFail["Pass / Fail"]
一方、LLMやAI Agentでは自然言語やコード生成など「唯一の正解」が存在しないケースが多い。そのため、複数の評価手法を組み合わせて多面的に評価する。
| 評価手法 | 内容・特徴 |
|---|---|
| Deterministic（確定的評価） | コンパイル成否、単体テスト、静的解析、正規表現マッチなど。ブレがない。 |
| Rule-based（ルールベース評価） | スキーマ検証（JSONバリデーション）、ブラックリストワード、差分行数制限など。 |
| LLM-as-a-Judge（モデル評価） | 別のLLMに採点基準（ルーブリック）を与えて成否や品質を判定させる。 |
| Human Evaluation（人手評価） | ドメインエキスパートやエンジニア自身による最終レビュー・アノテーション。 |
| Production Metrics（本番運用指標） | 採用率、ユーザー満足度、エラー率、レイテンシ、コストなどの実運用メトリクス。 |
Evalsは完全に別世界の概念というより、既存のSoftware Engineeringにかなり近いと感じている。
Android開発ではこれまで、以下のような仕組みで品質を確認してきた：
AI Agentの場合も、本質的な改善サイクルは酷似している。
flowchart TD
Dataset["Eval Dataset (タスク・要件)"] --> Agent["AI Agent"]
Agent --> Output["Output / Action (コード差分・PR)"]
Output --> Grader["Grader (Build / Test / Lint / Judge)"]
Grader --> Score["Score / 判定結果"]
Score --> Feedback{"失敗ケースの分析"}
Feedback -->|"プロンプト・モデル・ルールの改善"| Agent
Feedback -->|"エッジケースの蓄積"| Dataset
そのため、自分の中ではEvalsを
「AIをソフトウェア開発に組み込むための品質保証（QA / Testing）」
として捉えると非常に腹落ちしやすい。
今のところ、「Android EngineerからEvals Engineerへ転身する」という考え方ではない。 むしろ目指したいのは以下の掛け合わせ：
Android Engineer ＋ AI Engineering ＋ Evaluation設計
つまり、
を目指すイメージ。
一般的なChatbotの会話評価よりも、「Coding AgentのEvals」 に強く興味がある。
普段の開発では Claude Code、Codex、その他Coding Agentを使うことがあるが、その際に
「このAI、本当に良い実装をしているのか？」
を感覚ではなく定量的に判断できるようになると面白そう。
例えばAndroid Coding Agentなら、以下のように評価を二層に分解できる。
すべてをLLMに評価させる必要はなく、従来のツールをそのままGraderとして利用できる：
./gradlew assembleDebug（ビルドが通るか）./gradlew test（Unit Testが通るか）./gradlew lint / Detekt（静的解析・Lintが通るか）!!（強制アンラップ）が増えていないか個人的な学習題材としては、過去のAndroidタスク（Issue / PR） を使うのが最も手堅い。
過去のIssue
↓
Coding Agentに実装させる
↓
Build & Test & Lint & 差分検査（Grader）
↓
Human Review / LLM-as-a-Judge
↓
結果を記録
| 指標名 | 内容 | 判定方法 |
|---|---|---|
| Task Completion Rate | 要件を満たしてタスクを完遂できたか | テストパス ＋ レビュー |
| Build Success Rate | コンパイルが通るコードを出せたか | ./gradlew assemble |
| Test Pass Rate | 検証用テストおよび既存テストの通過率 | ./gradlew test |
| Scope Drift / File Count | 変更ファイル数や行数が過大でないか | git diff --stat |
| Safety Violations | !! の混入や保護ファイルの編集 |
スクリプト / 正規表現 |
| Human Edit Distance | 人間の手直しがどれくらい必要だったか | PR後の手動修正量 |
これだけでもEvalsの考え方をかなりリアルに体験できそう。
将来的には同じタスクセットを、Claude Code、Codex、Gemini系Agentなどに実行させて比較してみたい。
ただし、「どのモデルが最強か」という単一の優劣を決めたいわけではない。
といったタスク種別ごとに、「どのAgentがどういう仕事を得意とするのか」 の特性を見極めたい。
また、
を行った際に、以前解けていたタスクが解けなくなっていないかを検知する 「Regression Eval（回帰評価）」 にも大いに興味がある。
Evals界隈ではPython（各種Evalフレームワークや分析）を使うことが多いため、最低限は読める・書けるようにしておきたい。
ただし現時点では「Pythonを本格的に極めること」自体が目的ではない。
優先順位：
Evaluation設計 ≧ Software Testing > AI Agentの理解 > LLMの基本 > Python ≒ 統計・メトリクス > ML理論
特に「何を評価すべきか（テスト観点・ドメイン知識）」を設計できるソフトウェアエンジニアとしての能力の方が重要と考えている。
以下の疑問を念頭に置いてイベントを視聴する。
本学習メモから派生して作成した、他リポジトリ（Androidプロジェクト等）で即座に流用可能なサンプルツール群です。
git diff を解析し、不要な !! やスコープ逸脱、保護ファイル改変を検知するPython Graderhttps://x.com/search?q=%23Forkwell_Evals&src=typed_query&f=live