AIエージェント・パイロットのGO／NO-GO判定を設計する

評価対象は、回答の品質だけではない

AIエージェントのパイロットでは、文章の正しさや分類精度だけを測っても運用可否は判断できません。入力の取得、判断、ツール実行、人の承認、外部システムへの反映まで含めて、業務が期待どおり完了したかを見る必要があります。

評価単位は『一つの依頼が、許可された範囲内で、確認可能な結果に到達したか』とします。途中の出力が良くても、誤った宛先への送信や二重更新が起きれば、そのケースは合格にできません。

評価ケースを、実際の業務分布から作る

正常系だけで高い成功率を出しても、パイロットの安全性は分かりません。日常的な依頼に加え、入力不足、境界値、権限外の要求、外部サービスの応答遅延など、運用中に起こり得る状態を評価ケースへ含めます。

ケースごとに、期待する最終状態、許可するアクション、禁止するアクション、人へ引き継ぐ条件を先に書きます。出力を見てから合格条件を調整すると、都合のよい評価になりやすいためです。

• 通常業務を代表するケースを、件数の多い順に含めた
• 入力不足、曖昧な指示、重複依頼などの境界ケースを含めた
• 権限外の更新や禁止された送信を拒否できるか確認した
• タイムアウト、部分成功、結果不明から安全に停止できるか確認した

必須基準と目標基準を分ける

受入基準は、すべてを一つの平均点にまとめません。重大な誤送信、権限逸脱、未承認の更新など、一度でも発生すれば運用を止める項目は必須基準として個別に判定します。

処理時間、担当者の確認工数、軽微な修正率などは目標基準として扱えます。各指標には合格値だけでなく、評価件数、測定期間、除外条件を添え、再評価しても同じ結論に近づく設計にします。

• 必須基準：禁止アクション、権限逸脱、重大な誤更新が0件
• 品質基準：業務上許容できる正確性と修正率を満たす
• 運用基準：所要時間、費用、人の確認負荷が上限内
• 回復基準：停止、状態確認、再開承認の手順が機能する

失敗時の挙動も、受入試験に含める

本番に近い評価では、意図的にツールの失敗や応答遅延を発生させます。重要なのは失敗しないことではなく、失敗を検知し、無制限に再試行せず、実行済み範囲を説明できることです。

結果が成功か失敗か確定できない場合は、自動でやり直さずSAFE_HOLDへ移します。対象システムの状態確認と再開承認が終わるまで次の更新を行わないことも、GO判定に必要な能力です。

• 失敗箇所と実行済みアクションを同じ実行IDで確認できる
• 再試行回数と待機時間に上限がある
• 結果不明を正常終了や単純な失敗と区別できる
• 停止後の確認者と再開承認者が決まっている

判定会議では、未解決事項を隠さない

GOは、必須基準をすべて満たし、決めた件数の評価を完了し、重大な結果不明が残っていない場合に限定します。目標基準に届かない項目があるなら、対象範囲や利用者数を狭めたうえで、改めて受入条件を設定します。

NO-GOはパイロットの失敗ではありません。満たしていない基準、追加する制御、再評価するケース、次の判断責任者を記録すれば、感覚的な議論を再現可能な改善計画へ変えられます。