この記事の途中に、以下の記事の引用を含んでいます。
Evals as Code: CI for LLMs with Dagger
はじめに：AIエージェント開発も“CI/CD時代”へ、その裏にある評価プロセスの大革命
生成AIや大規模言語モデル（LLM）を活用したソフトウェア開発が、新たな常識となりつつあります。
しかし、AIが提供する「知性」の再現性や品質担保は、従来のテスト手法だけでは不十分でした。
この記事は、ソフトウェア開発のCI/CD文化をLLM開発にも適用する画期的な評価方法「Evals as Code」の実践知を、Daggerチームの取り組みを通して深掘りするものです。
彼らは、LLMエージェントがAPIツールを扱う開発環境において、どのように自動評価プロセス＝evalsを設計し、実装し、デバッグしたのか。
その難しさと発見、さらにevalsがもたらす効用について、豊富な実例とともに考察が展開されています。
CI文化をLLM時代にアップデート！Dagger流「Evals as Code」の要点
まず、この記事が提唱する最大のポイントは、「Evals as Code」というCI的な評価サイクルをLLM開発プロセスに組み込むアプローチです。
特に大切なのが以下の主張です。
“Evals measure the performance of an LLM for a given prompt, where ‘performance’ might mean any/all of the following:
Whether the LLM reached the desired state or produced the desired response x% of the time
How many input/output tokens it took (and how many were cached)
How many turns it took
A custom score for a task-specific metric
A score produced by another LLM grading the result
Wall clock time, though this seems lower priority than usual”
このように、evalsは「AIによるタスク遂行の正答率」「処理コスト」「工程数」「タスク個別指標」「相互評価によるスコア」など多面的な観点で性能計測を行う仕組みです。
そして、この評価機構自体を「テストコード」と同じくモジュール化・自動化し、繰り返し実行可能なもの（＝CIパイプラインの一部）として組み込める点に最大の意義があります。
なぜ「Evals as Code」が必要なのか？背景とDaggerによる問題設定
手動評価の限界──信頼できぬLLM、“フィードバックループ地獄”へ
LLMの検証には本質的に不確実性があります。
手動でプロンプトを与え、出力や挙動を一つ一つ目視チェックする従来のやり方では、コストも手間も膨大ですし、LMM出力は同じプロンプトでも毎回異なったり、思わぬ例外的な失敗パターンが後から気付くことも多々あります。
Daggerチームは、この課題を次のように端的に述べています。
“But testing LLMs by hand makes for a brutally slow feedback loop, and with how mercurial LLMs can be, running anything just once doesn’t inspire a whole lot of confidence…”
AI本流のCI/CD──すなわち「定期的な自動テスト」「複数パターンでの並列評価」「定量的な合否基準」「失敗時の迅速なフィードバック」──これらをLLM開発にも持ち込みたい。
記事はそのための解決策＝Evals as Codeの実装手法を惜しげもなく開示しています。
Daggerが挑んだLLM連携API内部の苦闘
Daggerは元々、DevOps向けのCI/CDオーケストレーションプラットフォームです。
ここにLLMエージェントを組み込み、API呼び出しやファイル操作などデリケートな業務プロセスをAI側にツールとして開放する中で、以下のように特有の難しさと格闘する必要がありました。
“The hardest part, by far, was figuring out how to express Dagger’s API to models in a form that is unambiguous and model-agnostic…
It took five iterations (just counting the attempts that led to mergeable code)…”
つまり、「どのAIプロバイダーでもブレずに正しくDagger APIを判断・操作できる抽象化設計」が一大テーマだったのです。
これはエージェント開発者やAPIデザイナーに共通する現代的課題と言えます。
Daggerの実装アプローチ：Evalsのインターフェース設計と運用術
評価（Eval）自体を“モジュール化”、「誰でも流用・拡張可能」に
DaggerのEvalモジュールは、Go言語をはじめTypeScriptやPython等SDKからでも使える構成で、Evalsの実装・拡張がしやすい設計になっています。
例えばGoの場合、最低限のインターフェースは以下のように型定義されています。
go
type Eval interface {
Name(context.Context) (string, error)
Prompt(base *dagger.LLM) *dagger.LLM
Check(ctx context.Context, prompt *dagger.LLM) error
DaggerObject
}
これは一つの評価ごとに
– 評価名取得（Name）
– LLMへの指示文＋環境設定（Prompt）
– 結果検証（Check）
という３要素で構成します。
この方式により、新たな評価パターンの追加、カスタム採点、複数モデルへの同時実施等にも柔軟に対応できる点が実用上きわめて重要です。
また、以下のような呼び出し方でCLIや他モジュール、CIパイプライン等から簡単に利用できます。
sh
dagger -m
「評価」の抽象度がAIプロジェクトの品質を制す
エージェントが「どこまで理解してくれたか」「何を間違えやすいか」などパターン把握には、人間＝新規エンジニアに課題を与えるのと非常に似た構造的難しさがつきまといます。
記事中でも
“Evals are sort of like testing an engineer’s ability to contribute to a project for the first time…”
と述べ、「仕様（Prompt, SystemPrompt）やツールのわかりやすさ」「AIモデル自身の背景知識」など、複数の変数が絡み合う“品質方程式”として捉えています。
この構造理解こそ、AIエージェント開発における根本課題と言えるでしょう。
LLM評価の“つまずきポイント”──具体例から学ぶ細やかな工夫
曖昧なプロンプトは失敗の元、「当たり前を疑え！」
プロンプト設計の甘えは、そのまま評価失敗として顕在化します。
「repoをどこにマウントする？」「作ったバイナリはどこに置く？」など人間なら空気を読んで補完できる指示も、全てのLLMが的確に理解するわけではないのです。
記事では、最初はラフな指示だったものの、曖昧さで失敗が頻発。
最終的には手順・条件を逐一具体的に明示したPromptに改良し、ようやく再現性高く合格するようになった、とのこと。
この知見は、現場感覚ではつい見過ごされがちな“アクション設計の落とし穴”を浮き彫りにしています。
Tool設計の落とし穴──人間向け出力を重視せよ
Tool呼び出し（API連携）では、「応答内容が巨大なJSON」や「名称付けの微妙な揺れ（returnやreturn_）」がAIモデルの挙動混乱を招きやすいことが実体験として語られています。
“If you can’t easily read the output, neither can the LLM. Don’t treat the LLM like a machine! Instead of having tool calls that return giant machine-readable JSON responses, return human-readable summaries.”
このような“人間っぽい可読性”の重視は、AI×API設計の新定石として非常に示唆的です。
SystemPromptの意義──モデル横断安定性のカギ
また、多様なモデルに対して挙動の一貫性を保つためにはSystemPrompt（システム命令文）の設計も重要だと説きます。
Claude 3.5 SonnetはSystemPromptなしでも合格したものの、GPT-4.1やGemini 2.0 Flashは失敗が多かったようで、プロバイダーごとのカスタムSystemPromptも有用、という定性的知見も参考になります。
並列Eval＋失敗解析の威力
評価失敗のパターン検出と改善には「一度に大量・並列」にEvalを走らせ、失敗事例を体系的に分析することが何より有効だったと述懐しています。
Gemini 2.0 Flashは精度は低かったが、とにかくレスポンスが速く数をこなせたため、問題発見→改善→再テストの“進化サイクル”が飛躍的に加速したそうです。
この発想は、LLM時代の新しい開発サイクル設計のヒントになるでしょう。
考察：Evals as Codeの本当の価値と今後の展望
再現性と成長性──「学習する評価」がもたらす持続的進化
Evals as Code最大の本質的価値は「再現性」と「進化性」の両立にあります。
手動評価は“シングルショット”で終わるが、Evalsは「繰り返すたびに課題傾向や弱点が見える」「修正→再評価→集計」が可能です。
しかも評価設計そのものもコード化（バージョン管理・CI組込）できるため、エージェントの改良サイクルが組織横断的・継続的に循環します。
これはまさにソフトウェアテストにおけるCI革命を、AIエージェントという本質的に多様・不確実な対象にも適用可能にする、という点で画期的です。
開発現場が得るもの──品質、速度、透明性
この仕組みを導入するチームにとっては
– 人に依存しない品質担保
– 改善サイクルの飛躍的短縮
– バグ分析・ナレッジ共有の容易さ
など、AI活用開発プロセスの“深部”が可視化・自動化されるインパクトは想像以上でしょう。
今後、LLMやAIエージェントを本格導入する現場には、Evals as Code型のパイプライン自動化が不可欠という時代が到来することは間違いありません。
依然として残る課題──評価軸の正当化・意味解釈
一方で、記事でも言及されている通り、
– Evalsの設計は何を正答・失敗とみなすか、評価軸自体をクリアにしなくてはならない
– LLMの非決定的挙動をどこまで“正常”と許容するか
といった、人間側の設計思想や「評価の定義」自体が依然として揺れ動きやすい部分もあります。
今後は、より高度な評価軸の標準化・品質指標の研究発展も期待されます。
結論──「評価の自動化」がAI開発をさらに前進させる
Daggerチームによる「Evals as Code」の取り組みは、AI時代の本格開発・運用ガバナンスに、“新しい型”を提案するものです。
ソフトウェアテスト文化がCI/CDによって加速したように、AIモデル開発にも評価→修正→再評価が当たり前になれば、組織はより安定的かつ迅速にナレッジを蓄積し、性能を磨き上げていけます。
これからLLMやエージェント開発を検討するすべての開発者・PM・デザイナー・MLエンジニアにとって、「Evals as Code」の思想は避けて通れません。
この記事が具体的な実装例とともに示した知見・工夫は、AI開発現場の“新・ベストプラクティス”として、強く推奨されるアプローチだと断言できます。
自分たちのプロジェクトにも、Evals as Code型の評価メカニズムを一度取り入れてみてはいかがでしょうか？
categories:[technology]
コメント