Hugging Face Blog が 2026 年 4 月 29 日に公開した 「AI evals are becoming the new compute bottleneck」 は、現場の体感を綺麗に言語化してくれました。モデル学習よりも、評価のための計算資源の方が先に枯渇するという主張で、エージェントや RAG をプロダクションに乗せた直後から実感する開発者は多いはずです。
受託で AI を組む場合、これまでは「PoC で動かす → 顧客レビュー → 本番投入」の流れで評価は終盤に押し込まれがちでした。しかし 2026 年は、評価をプロジェクト初週から設計しなければ、本番後に壊れてしまうフェーズに入っています。本記事では、受託 AI 開発で Evals を初手に組み込むための設計ステップを整理します。
なぜ評価が「新たなコンピュート」になるのか
Hugging Face の論考を要約すると、評価が律速になる構造は次のとおりです。
| 局面 | 必要な計算資源 | スケーリング要因 |
|---|---|---|
| 学習・ファインチューニング | GPU 時間 | データ量 × モデルサイズ |
| 推論（本番） | GPU 時間 | リクエスト数 |
| 評価 | GPU 時間 + 人手レビュー時間 | テストケース数 × モデルバージョン数 × プロンプトバリエーション |
評価は「モデルの数 × プロンプトの数 × テストケースの数」の掛け算で爆発するため、たとえばエージェントを毎週リリースする組織では、数週間で評価コストが推論コストを超えるのが普通です。
これは「AIベンチマークは壊れた」で扱った「公開ベンチマークが現実を反映しない」問題とは別レイヤーで、自社ドメイン専用の Evals を継続的に走らせるためのインフラ問題です。
受託 AI 開発で評価を初手に組む 4 ステップ
弊社で受託 AI 開発を組むときは、要件定義の段階で次の 4 ステップを順に決めています。
Step 1. 評価軸を業務 KPI から逆算する
「精度」だけで語らず、業務 KPI と紐付けます。たとえば顧客サポート向けの RAG なら次の構造です。
| 業務 KPI | 評価軸（モデル直近） | 計測方法 |
|---|---|---|
| 一次解決率 | 回答が顧客の質問に直接答えているか | LLM-as-a-judge + 人手 200 件サンプル |
| 誤情報率 | 引用元と矛盾しないか | 引用整合性スコア（自動） |
| 応答時間 | p95 レイテンシ | 推論ログから集計 |
「LLM-as-a-judge」だけに頼ると安定しないので、重要 KPI には人手評価を 100〜300 件混ぜるのが定石です。
Step 2. ゴールデンセットをドメインから 100〜500 件作る
ゴールデンセットは外部ベンチマークではなく、顧客のリアルなクエリログから抽出します。エッジケース（誤字・複数質問・暗黙の前提）を意図的に混ぜるのが重要で、本番リリース後に発覚する事故の 8 割はこのエッジ領域です。
# evals/golden_set.py（イメージ）
test_cases = [
{
"query": "パスワード再発行のメールが届かないんですけど",
"expected_intent": "password_reset_help",
"expected_citations": ["faq/password-reset.md"],
"tags": ["typo", "frequent"]
},
# ... 100〜500 件
]タグを付けておくと、リリース後に「typo を含むケースの精度だけ落ちた」といった切り分けが一発でできます。
Step 3. 評価パイプラインを CI に組み込む
リリースフローに評価を組み込みます。GitHub Actions + Langfuse / Phoenix / promptfoo などを使い、PR 単位で eval を走らせ、しきい値割れで自動ブロックします。
# .github/workflows/eval.yml の抜粋
name: AI Evals
on: [pull_request]
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npx promptfoo eval --config evals/config.yaml
- run: npx promptfoo eval --output evals/results.json
- name: Check thresholds
run: |
jq '.summary.passRate' evals/results.json | \
awk '{ exit ($1 < 0.85) }'Langfuse による AI 開発のオブザーバビリティ で書いたとおり、評価結果と本番ログを同じプラットフォームで突き合わせると、「評価では 88% だったのに本番では 72%」というドリフトを早期に検知できます。
Step 4. 評価コストの予算を設計時に確保する
意外に抜けがちなのが 「評価のクラウド費用」を見積に入れることです。受託案件で次のレンジを目安にしています。
| プロジェクト規模 | 月次評価コスト目安 | 内訳 |
|---|---|---|
| PoC（〜数百クエリ/日） | 月 5〜15 万円 | LLM-as-a-judge + ストレージ |
| 本番（数千〜数万クエリ/日） | 月 30〜80 万円 | 自動 eval + 人手レビュー外注 |
| エンタープライズ（数十万〜） | 月 150 万円〜 | 専用評価インフラ + アノテーター |
この費用を「ランニングの一部」として最初から請求書に積んでおかないと、本番後に「評価が回らないのでリリースできない」というデッドロックに陥ります。
フェーズの完了条件を “評価駆動” で書く
AI 案件を「PoC → 本開発 → 運用」と切るとき、各フェーズの完了条件を 「動いたこと」ではなく「合意した評価軸のしきい値を満たしたこと」 に置き換えると、フェーズの切れ目が主観論になりません。
- PoC の完了条件: Step 1 の評価軸と Step 2 のゴールデンセットが顧客と合意されていること（プロトが動くことではない）
- 本開発の完了条件: Step 3 の CI eval がしきい値を維持したままリリースできること
- 運用フェーズの成果物: 月次の評価レポートと、しきい値割れ時の改善サイクル
この書き方にすると、ゴールデンセットの件数・評価軸の本数・人手レビューの比率がそのまま作業量になるため、見積の根拠が説明できる形になります。逆に言えば、同じ「RAG 構築」でも評価軸が 3 本の案件と 12 本の案件ではまったく別物で、先に決めずに規模を語ることはできません。
「AI を入れた後にどう運用するのか？」という問いに、最初から評価駆動の運用体制を組み込むことで、発注側にも「数字で回せる AI 投資」として説明可能になります。これは MCP × AAIF ガバナンス で扱った AI ガバナンス論点と地続きで、評価とガバナンスは同じ運用基盤の上に乗せる設計が望ましい流れです。
評価ツール選定の早見表
2026 年現在、受託で使いやすい評価ツールは次の 4 つです。
| ツール | 強み | 弱み | 受託での向き |
|---|---|---|---|
| Langfuse | 本番ログと評価の統合、OSS | 学習コストやや高 | 中規模以上の本番運用 |
| Phoenix (Arize) | RAG/Agent 評価が手厚い | 商用色強め | エンタープライズ |
| promptfoo | YAML 一発、CI 連携が簡単 | 人手レビュー機能弱 | PoC〜小規模本番 |
| 自社内製 | フルカスタム可 | 開発・運用負荷 | 機密性が極端に高い案件のみ |
最初は promptfoo で CI を回し、本番拡大に合わせて Langfuse を載せるというステップアップが事故が少ないです。
まとめ ─ 評価をデフォで先に組む
「Evals を最初に組む」という考え方を受け入れるか否かは、AI 受託案件の成功率を二極化します。Hugging Face が指摘するように評価コストは構造的に逃げられない出費で、最初から見積と運用に組み込むほうが結果的に安く・速く・安全に着地します。
「PoC は動いたが本番に出すのが怖い」「運用後にモデルがドリフトしているか検知できていない」——この 2 つは、たいてい「評価軸とゴールデンセットが手元にない」ことの言い換えです。まずは既存のクエリログを見ながら、何を測れたら「出していい」と言えるのかを切り分けるところから始まります。ドメインの性質・評価軸の本数・人手レビューをどこまで許容できるかで組み方はまるごと変わるので、いま抱えている状況を お問い合わせフォーム からお聞かせください。
