1. 評価・テスト設計とは——「正しさを測る基準」を作る技術
評価・テスト設計とは、LLMの出力が目的にかなっているかを、感覚ではなく定義された基準で測り、品質を継続的に監視する仕組みを作ることです。生成AIは同じ入力でも表現がゆらぎ、正解が一意に定まりません。だからこそ「何をもって良い出力とするか」を先に決めておかないと、良し悪しを議論できません。
FDEにとってこれが重要なのは、顧客に納品するのが「動くデモ」ではなく「業務で信頼して使えるシステム」だからです。RAG実装やプロンプトエンジニアリングの良し悪しも、結局は評価で測って初めて改善できます。評価はすべての技術スキルの「答え合わせ」であり、これが無いと改善は当てずっぽうになります。
2. FDEの現場でどう使うか——「なんとなく良さそう」を許さない
FDEの案件でPoCが本番に進めない典型が、「デモは盛り上がったのに、品質を聞かれて答えられない」ケースです。現場で問われるのは次の点です。
①正解データ（評価セット）を用意する
顧客の実際の業務データから、「この入力にはこの回答が望ましい」という例を数十〜数百件集めます。これが評価の物差しになります。完璧な正解が無い業務でも、「含むべき情報」「触れてはいけない事項」をチェックリスト化すれば測れます。
②指標を決めて測る
用途に応じて、事実に合っているか（正確性）、必要な情報を漏れなく含むか（網羅性）、禁止事項に触れていないか（安全性）などを指標にします。人手評価に加え、LLMに採点させるLLM-as-a-judgeを併用すると、大量の出力を効率的に測れます。数値で示せると、顧客の意思決定者にも品質を説明できます。
③回帰テストで「悪化」を検知する
プロンプトを直す、モデルを更新する——こうした変更で、直したはずが別の部分が悪化することは頻繁に起きます。評価セットを使った回帰テストを回し、変更のたびに品質が下がっていないか確認します。これがあると、安心して改善を続けられます。
「作れる」だけでなく品質を担保して運用に載せることは、ヒアリングから運用まで一気通貫を担うFDEの職務そのものです（Findyの求人特集・Sansan公式テックブログ。出典は末尾）。
3. 今どうやって身につけるか——「測る」を習慣にする
評価スキルは、小さくてもいいので「自分のAIの品質を数値で測った」経験で身につきます。
Step 1: 自作アプリに評価セットを作る
RAGなどの小さなアプリを作ったら、必ず10〜30件の「入力と望ましい回答」のペアを用意し、正確性・網羅性を自分で採点してみます。ここで初めて「思ったより間違えている」現実が見えます。
Step 2: LLM-as-a-judgeを試す
採点用のプロンプト（「以下の回答が事実に合っているかを0〜2で採点し理由を述べよ」等）を作り、LLMに評価させてみます。人手評価とどれくらい一致するかを確かめると、自動評価の限界と使いどころがわかります。
Step 3: 変更前後を比較する癖をつける
プロンプトやモデルを変えたら、必ず評価セットで前後のスコアを比べます。「良くなった気がする」ではなく「正確性が72%→81%」と言えるようにする——この習慣が、本番運用でそのまま回帰テストになります。まとめた評価設計はポートフォリオの強い題材になります。学習順序は未経験からのロードマップを参照してください。
4. FDE Outlook——評価スキルの現在地と見立て
今見えていること: モデルの性能が上がるほど、差がつくのは「品質を証明できるか」に移っています。FDEスキルマップでは技術基盤の一部として評価・テスト設計を位置づけました。PoC設計の評価指標とも地続きで、成功基準を決める力と品質を測る力はセットです。
今後の見立て: AIの導入が広がるほど、「そのAIは信頼できるのか」を問う社会・行政の目線は厳しくなります。評価の一部（採点の自動化・テストの生成）はAI自身が肩代わりしていく一方で、その業務で「何を正しさとするか」を顧客と合意して定義する仕事は人に残ると見ています。測る技術より、測る基準を決める判断——ここがFDEの評価スキルの本丸になっていくはずです（求人要件の変化は求人ウォッチで観測を続けます）。目指し方はFDEになるにはをご覧ください。