こんにちは！株式会社雲海設計の技術部です。
「評価ハーネスを作れと言われたが、何を測ればいいか分からない」「Excelでスプレッドシート評価していたら、プロンプト1行変えるたびに半日溶ける」「本番リリース後にデグレが出ても、どこで壊れたか追えない」——2025年に生成AIの業務投入が一気に進んだ結果、2026年に入ってからハーネスエンジニアリング 実践に関する相談が、PoCを終えたチームから次々と入ってくるようになりました。本記事では、評価ハーネス構築から本番投入までを段階的に進めるためのハーネスエンジニアリング 実践の手順を、雲海設計の現場で実際に回しているテンプレートとともに整理します。
TL;DR
ハーネスエンジニアリング実践は「評価セット → 自動評価 → 回帰検知 → 本番投入」の4段階で組み立てる
評価セットは最低50件、理想は200件。「正常系・境界・敵対的」の3区分で揃えると壊れにくい
自動評価はルールベース＋LLM-as-a-Judge＋人手レビューのハイブリッドが2026年の主流
CIに評価ハーネスを組み込むと、プロンプト変更1回あたりの検証時間が4時間→10分に縮む
本番投入はシャドー → カナリア → 全展開の3段階。いきなり全展開はほぼ確実に事故る
なぜ2026年にハーネスエンジニアリング実践が必須スキルになったのか？
結論から言うと、LLMアプリケーションは「動くか動かないか」ではなく「品質が保てているか」で判定される時代に入ったからです。Gartnerが2025年末に公表したレポートでも、生成AI PoCのうち本番投入まで到達したのは約3割、そのうち半数が品質劣化を理由に半年以内に縮退・撤退しています。原因の多くは「評価の仕組みがなかった」ことに集約されます。
評価ハーネスがないチームで起きる典型症状
プロンプト改善が博打になる：「なんとなく良くなった気がする」で本番投入し、別のケースで壊れる
モデル乗り換えが怖くなる：新モデルが出ても比較できず、古いモデルに固定される
劣化に気付くのがユーザークレーム経由：本番でしか不具合が見つからない
「評価セットを書けないエンジニアは本番運用に入れない」——これは2026年のAIエンジニア採用基準として、すでに業界標準になりつつあります。
ハーネスエンジニアリングの基礎概念については、ハーネスエンジニアリングとは？LLM時代に必須の新常識を解説で整理していますので、未読の方はそちらを先にどうぞ。
ハーネスエンジニアリング実践の4段階フェーズ
結論として、実務で回るハーネスは以下の4段階で構築します。各段階の目的とアウトプットを明確に分けることが、頓挫しないコツです。
| フェーズ | 目的 | 主なアウトプット | 所要工数目安 |
|---|---|---|---|
| ① 評価セット設計 | 「何を成功とするか」を定義 | 評価データセット (JSON/CSV) | 3〜5人日 |
| ② 自動評価実装 | スコアを機械的に算出 | 評価スクリプト + メトリクス | 5〜10人日 |
| ③ 回帰検知 (CI連携) | 劣化を変更時点で止める | CIワークフロー + ダッシュボード | 3〜5人日 |
| ④ 本番投入・継続評価 | 運用中の品質維持 | シャドー/カナリア基盤 + ログ評価 | 10〜15人日 |
合計で約1〜1.5ヶ月。「PoCの倍くらい時間がかかる」と最初に経営層に伝えておくのが、雲海設計の現場で身についた経験則です。
フェーズ①：評価セットはどう設計すべきか？
結論から言うと、評価セットは「正常系・境界ケース・敵対的入力」の3区分で、最低50件・理想200件を揃えるのが鉄則です。少なすぎるとノイズに埋もれ、多すぎると初動で挫折します。
3区分の中身
正常系 (Happy Path)：想定ユーザーの典型クエリ。全体の50%程度
境界ケース：曖昧表現・略語・複数意図・空入力など。30%程度
敵対的入力：プロンプトインジェクション・脱獄試行・社外秘探り。20%程度
評価データの最小スキーマ
{
"id": "eval-001",
"category": "normal",
"input": "先月の関東エリアの売上トップ3を教えて",
"context_ids": ["sales_2026_04"],
"expected": {
"must_include": ["関東", "2026年4月"],
"must_not_include": ["推定", "おそらく"],
"citation_required": true
},
"weight": 1.0
}
ポイントは「完全一致を求めない」ことです。LLMの出力は揺らぐので、must_include / must_not_include / 引用必須フラグといったゆるい合格条件で書きます。これだけで運用が一気に楽になります。
評価セットの設計思想はハーネスエンジニアリング ベストプラクティスでも詳述しているので、深掘りしたい方はあわせてご覧ください。
フェーズ②：自動評価はどう組むのが正解か？
結論として、2026年現在の主流は「ルールベース判定 + LLM-as-a-Judge + 人手スポットレビュー」のハイブリッドです。単一手法ではどこかで必ず偏ります。
3層スコアリングの役割分担
| 層 | 得意領域 | 不得意領域 | 使う場面 |
|---|---|---|---|
| ルールベース | キーワード有無・引用ID・JSON構造 | 意味の妥当性 | 形式チェック全般 |
| LLM-as-a-Judge | 意味的妥当性・文脈整合 | 計算・固有数値検証 | 回答の質的評価 |
| 人手レビュー | 最終判断・ニュアンス | スケール | 差分のみサンプリング |
LLM-as-a-Judgeの注意点
判定モデルは生成モデルと別系統にする：自分で生成したものを自分で採点させるとバイアスが乗る
採点基準をルーブリック化する：「5段階の各点数の定義」を判定プロンプトに含める
判定の判定をする：人手レビューと判定LLMの一致率を月次で測定し、ズレたら判定プロンプトを直す
最小実装イメージ
def evaluate(case, response):
scores = {}
# 1. ルールベース
scores['format'] = check_must_include(response, case['expected'])
scores['citation'] = has_valid_citation(response)
# 2. LLM-as-a-Judge
scores['quality'] = judge_llm.score(
rubric=QUALITY_RUBRIC,
question=case['input'],
answer=response,
)
# 3. 加重平均
return weighted_sum(scores, weights=CONFIG['weights'])
フェーズ③：CIに組み込んで回帰検知するには？
結論として、評価ハーネスは必ずCIパイプラインに組み込むべきです。手動実行のままだと「忙しいから今回はスキップ」が発生し、3ヶ月で形骸化します。
GitHub Actions の最小例
name: eval-harness
on:
pull_request:
paths:
- 'prompts/**'
- 'src/rag/**'
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install -r requirements.txt
- run: python -m harness.run --suite regression
- run: python -m harness.compare --baseline main
# ベースラインから5%以上劣化したら fail
運用ルール
ベースライン更新は週次：mainブランチのスコアを毎週金曜にスナップショット
劣化閾値は3〜5%：これより緩いと無意味、厳しすぎると毎回赤くなる
失敗ケースの差分はPRコメントに自動投稿：レビュアーが目視で確認できる導線を作る
これだけで、プロンプト変更1回あたりの検証時間が4時間→10分に縮みます。雲海設計の社内プロジェクトでも、CI導入後にプロンプト改善のPR数が約3倍に増えました。「壊れる怖さ」が消えると、改善のスピードは段違いに上がるのです。
フェーズ④：本番投入はどう段階を踏むべきか？
結論として、本番投入は「シャドー → カナリア → 全展開」の3段階を必ず踏みます。いきなり全ユーザーに当てるのは、評価ハーネスがあっても危険です。
3段階の中身
| 段階 | トラフィック | 判定軸 | 期間目安 |
|---|---|---|---|
| シャドー | 本番リクエストを複製、出力は破棄 | レイテンシ・エラー率・スコア分布 | 1〜2週間 |
| カナリア | 1〜10%のユーザー | 業務KPI・苦情件数 | 1〜2週間 |
| 全展開 | 100% | 継続スコア監視 | 恒常運用 |
本番ログを評価データに還流させる
本番運用が始まったら、実ログから困難ケースを抽出して評価セットに追加する仕組みを必ず用意します。これをやらないと、評価ハーネスは設計時点のスナップショットに固定され、ユーザーの実際の使い方とズレていきます。
低スコアセッションを毎週サンプリング
ユーザーフィードバック (👎ボタン等) のついた応答をキューに溜める
月次で人手レビューし、評価セットに昇格させる
セキュリティ観点でのログ設計はAIセキュリティ対策実装ガイド2026で詳しく扱っているので、ログ保存方針はあわせて確認してください。
実プロジェクトでの段取り：4週間スプリント例
雲海設計の現場で実際に回している4週間スプリントの段取りを共有します。RAGアプリの本番投入を想定したミニマム構成です。
graph LR
A[Week1: 評価セット50件] --> B[Week2: 自動評価実装]
B --> C[Week3: CI連携 + シャドー開始]
C --> D[Week4: カナリア 10%]
D --> E[Week5+: 全展開 + 継続評価]
各週の必達ライン
Week 1：評価セット50件 (正常25・境界15・敵対10)
Week 2：ルールベース + LLM-as-a-Judge を実装、初回スコア取得
Week 3：CIに組み込み、シャドートラフィックを流し始める
Week 4：10%カナリア。業務KPIとスコアの両方を監視
「評価セットだけで1週間も使うのか」と最初は驚かれますが、ここで手を抜くとフェーズ②以降がすべて崩れます。評価セットの質がハーネス全体の天井を決めると覚えてください。
よくある質問
Q. 評価セットは何件あれば本番に出せますか？
A. 最低50件、理想は200件です。50件未満だとスコアのばらつきが大きく、変更の良し悪しを判定できません。ただし最初から200件を作ろうとすると挫折するので、50件で運用を始めて月次で20〜30件ずつ追加するのが現実的です。
Q. LLM-as-a-Judgeは信用できますか？
A. ルーブリックを丁寧に書けば、人手レビューとの一致率は8割前後まで上がります。ただし判定モデルと生成モデルを別系統にすること、月次で人手と突き合わせて校正することが前提です。判定LLMを盲信した結果、「自画自賛で全件高得点」という事故は2025年に複数の現場で起きています。
Q. PoCで使ったプロンプトをそのまま本番に持っていけますか？
A. ほぼ持っていけません。PoCは「動くこと」を示す段階、本番は「壊れないこと」を示す段階で、要求水準が違います。PoCのプロンプトを評価ハーネスに通すと、敵対的入力の半数以上で破綻するのが普通です。ハルシネーションを防ぐプロンプト設計10選もあわせて参照してください。
Q. ハーネスの運用は誰が担当すべきですか？
A. AIエンジニアが主担当、QAエンジニアが補助、PdMが評価セットの妥当性レビュー、という3者体制が機能しやすいです。「AIエンジニアだけで回す」と業務理解が薄くなり、「QAだけで回す」とプロンプト改善が進まなくなります。
Q. 既存のCI/CDが弱い組織でも導入できますか？
A. 可能ですが、まずCI/CD基盤の整備から入った方が結果的に早いです。手動評価で凌ぐと2〜3ヶ月で運用が破綻します。CI/CDを含めた開発基盤の見直しが必要な場合は、DXソリューション側でセットでご相談ください。
まとめ：ハーネスエンジニアリング実践は「型」を持てば怖くない
ハーネスエンジニアリング 実践のポイントを再掲します。
評価セット → 自動評価 → 回帰検知 → 本番投入の4段階で組み立てる
評価セットは正常・境界・敵対の3区分で50〜200件
自動評価はルールベース＋LLM-as-a-Judge＋人手のハイブリッド
CI連携で変更1回あたりの検証時間を1/20以下に
本番投入はシャドー → カナリア → 全展開の3段階を必ず踏む
雲海設計では、生成AI・RAG・エージェント案件で評価ハーネスの設計から本番投入までを伴走しています。「PoCは動いたが、本番化のロードマップが描けない」「評価ハーネスをゼロから作りたい」というご相談は、ITコンサルティングまたはお問い合わせからお気軽にどうぞ。現場で回るハーネスを、現場の手で作れる体制までご支援します。