AIワークフローが最初の週に失敗するケースの大半は、想定外ではない。予測可能だ。チームがリリース前にそれを書き出さなかっただけだ。
評価パックはその状況を変える。ワークフローが本番稼働する前に組み立てる、代表的な入力・期待出力・合否基準の構造化されたセットだ。ユニットテストスイートではない。公開データセットに対するベンチマークでもない。実際の本番環境を反映した、小規模で意図的なケースの集合だ。
構築には数時間かかる。省略すると数日のコストになる。
評価パックとは何か
ユニットテストはコードが正しく動作するかを確認する。ベンチマークは標準化されたタスクに対するパフォーマンスを測定する。評価パックはそのどちらでもない。
答える問いはひとつだ：このワークフローは、実際に受け取る入力に対して正しく動作するか？
パックには各ケースについて3つの要素が含まれる：
- 入力：ワークフローが処理する現実的なプロンプト、レコード、またはドキュメント
- 期待出力：正しい動作の定義——分類ラベル、構造化フィールド、特定の必須要素を含むサマリーなど
- 合否基準：出力が適格かどうかを判断する具体的なルール
基準はほとんどのチームが省略する部分だ。「十分に良い」は基準ではない。「アカウント名と次のステップの推奨事項を含む」が基準だ。
適切な15〜20ケースの選び方
デプロイ前のパックとして適切なサイズは15〜20ケースだ。それより少ないと実際のばらつきを見逃す。それより多いとパックの維持コストが高くなり、実行も遅くなる。
目標は、それらのケースで本番環境のばらつきの80%をカバーすることだ。見つけ方を以下に示す。
クリーンなケースから始める
必須フィールドがすべて存在し、入力が明確なケースを1〜2件用意する。これがベースラインだ。ここでワークフローが失敗するなら、他は何も意味をなさない。
エッジ入力を追加する
技術的には有効だが通常とは異なる入力だ。特殊文字を含む会社名。予期しない形式の日付フィールド。典型的なものより10倍長いフリーテキストフィールド。これらは脆弱なパースとプロンプト感度を露わにする。
フィールド欠損ケースを追加する
実際の本番データは不完全だ。欠損しやすい上位3フィールドを選び、それぞれ1ケースを作成する。それらのフィールドが欠損している場合のワークフローの動作を定義しておく必要がある——クラッシュでも、ハルシネーションされた値でもなく。
曖昧な分類を追加する
ワークフローが分類判断（業種、意図、優先度、感情など）を行う場合、カテゴリの境界に位置する入力を2〜3件見つける。これらはモデルの判断が最も重要で、ドリフトが最初に現れるケースだ。
既知の敵対的パターンを追加する
どのドメインにも存在する。アウトバウンド営業ワークフローであれば、役職が「CEO」だが従業員が2名の会社のコンタクトレコードかもしれない。ドキュメント処理であれば、関連データが表のフッターにあるPDFかもしれない。デプロイ後ではなく、デプロイ前にチームから収集する。
デプロイゲートとしてパックを実行する
評価パックは必須でなければ機能しない。任意であれば、締め切りのプレッシャー下でスキップされる——それはまさにパックが最も重要な瞬間だ。
統合はシンプルだ。ワークフローが本番環境に移行する前のチェックリスト項目として評価実行を追加する。チェックリスト項目には2つのフィールドがある：
- ベースラインスコア：初回実行でワークフローが合格したケースの割合
- 最低閾値：リリースに必要なスコア
閾値はパックを実行する前に設定する。スコアを見てから設定するのでは意味がない。
ほとんどのワークフローの合理的な開始閾値は85%だ。20ケース中17ケースが合格することを意味する。3件の失敗はドキュメント化される——必ずしも修正するわけではないが、ドキュメント化することで、チームはワークフローがまだ対応していないことを把握できる。
失敗への対処
すべての失敗がデプロイをブロックするわけではない。一部の失敗は、ワークフローが対応するよう設計されていなかったエッジケースを明らかにする。それらは既知の制限としてログに記録される。
一部の失敗は、ワークフローが対応すべきケースで誤動作していることを明らかにする。それらはデプロイをブロックする。
この区別はパック実行前に行われる。チームがどのケースがスコープ内でどれがスコープ外かを決定するときだ。その決定はパックの構築の一部であり、結果の解釈の一部ではない。
パックの再実行
パックは一度限りの成果物ではない。プロンプトの変更、モデルの更新、上流のデータスキーマ変更の後に再実行する。初回実行のベースラインスコアがフロアになる。後続の実行でスコアが低下した場合、何かがリグレッションしている。
これが、何かが変わるたびに完全な監査を必要とせず、ワークフローを長期的に安定させるフィードバックループだ。
運用上の効果
デプロイ前に評価パックを構築するチームは、本番環境の問題を数日ではなく数時間で発見する。また、ワークフローが何に対してテストされたかの具体的な記録も残る——特定のケースがなぜそのように処理されたかをステークホルダーに問われたときに役立つ。
パックは完璧なワークフローを保証しない。実際のデータに触れる前に、実際の条件に対して確認されたワークフローを保証する。
それは、ほとんどのチームが持っているものとは異なる出発点だ。
AIワークフローを構築または監査していて、評価アプローチについて第三者の視点が必要な場合は、会話を始める →