11月9日、GitLabが「How to design a decision-grade pilot for agentic AI」と題した記事を公開した。この記事では、AIエージェントの本番導入可否を判断するための、証拠に基づいたパイロット評価フレームワークについて詳しく紹介されている。以下に、その内容を紹介する。
AIエージェント（Agentic AI）は、単に回答を生成するだけのAIとは根本的に異なる。コンテキストを収集し、ツールを選択し、判断を下し、ソフトウェア開発ライフサイクル全体にわたって一連のアクションを実行する。その評価の問いも変わる。「印象的な結果を出せるか」ではなく、「このエージェントがこのチームのこのワークフローを実行することを承認するに足る証拠は何か」が問われる。
評価の前に「決定」を定義する
パイロットは技術から始めるのではなく、下すべき意思決定から始めるべきだ。「AIエージェントを評価する」という目標設定は漠然としすぎている。有効な定義は、ワークフロー、対象ユーザー、自律性のレベル、エージェントが出すべきアウトプット、成功の判断基準、定量的な期待値、そして進行条件を含む。
記事が示す具体例はこうだ：
「AIエージェントが選択されたCI/CDパイプライン障害を診断し、パイプラインのテストを通過し開発者に承認されるマージリクエストを、定義されたリポジトリ権限の範囲内で作成できるかどうかを判断する。現行ベースラインから解決工数を25%以上削減することを条件とする。」
この形式で事前定義しておくことで、成功・失敗の判断基準がブレない。さらに「パイロット成功後に何をするか」（1チームへの限定展開、複数チームへの拡大など）も決めておかないと、パイロットが終わりのない実験に漂流する。
自律性レベルを4段階で設計する
AIエージェントは「自律的かどうか」の二値ではなく、同一エージェントでも権限レベルを変えて運用できる。記事では以下の4段階モデルを提示している。
- 推奨（Recommend）: 状況を分析し、アクションを推薦する
- 準備（Prepare）: マージリクエストや修正計画などの成果物を作成するが、適用はしない
- 承認付き実行（Execute with approval）: 人間の承認後にのみアクションを実行する
- 境界内自律実行（Execute within boundaries）: 定義されたスコープ内で自律的に動作し、例外時にはエスカレートする
重要な考え方は「自律性は証拠によって獲得するもの」という点だ。推奨からスタートし、成果物の準備へ、そして十分な信頼性と制御遵守が確認されてから境界内実行を検討するという段階的なアプローチを推奨している。
「レスポンス品質」ではなく「ワークフロー完了」を測る
従来のモデル評価はレスポンス品質に着目するが、エージェント評価はエンドツーエンドのタスク完了を測らなければならない。
パイプライン障害の解決エージェントを例にとると、「もっともらしい説明」は成果ではない。成果とは、根本原因の特定、有効な修正の提案、レビュー可能な成果物の作成、権限不足時のエスカレーション——これらが一連のワークフローとして完了することだ。
評価セットの構築についても具体的な指針がある。
- 現実的なタスク: 一般的なもの＋複雑だが有効なケース
- 難しい入力: 文脈が曖昧・矛盾するリクエスト、敵対的な入力
- エージェントが単独で完了してはならないケース: 権限境界外のリクエスト、高影響アクション
ベンチマーク用の汎用シナリオではなく、実際のワークフローから消毒済みの事例を使うことが推奨されている。企業の実業務には、コーディング規約やポリシー、所有権の境界など、汎用問題には含まれない難しさが存在するためだ。
「最良の1回」ではなく「分布」を測る
エージェントの挙動は入力やコンテキスト、実行状態によって変わる。1回の成功は信頼性の証明にならない。記事はこう指摘する：
「20回中20回成功しても99%の信頼性を証明したことにはならない。95%信頼区間では、真の失敗率は最大約14%に達しうる。」
重要なシナリオを複数回実行し、条件を変えながら次の3軸で計測する。
- タスク成果: エンドツーエンド成功率、レビュアー承認率、シナリオ別失敗率
- 人間の関与: 介入率・エスカレーション率、エージェントが引き起こした手戻り
- 制御と回復力: ポリシー違反・認可違反、ツール障害や文脈欠如からの回復
また集計値には罠がある。90%の成功率も、残り10%に無許可の変更が含まれるなら許容できない。リスク層と障害タイプでセグメントして分析する必要がある。
制御要件は「閾値」ではなく「ハードゲート」
リスク層に応じて求める信頼性水準を変えることは合理的だが、一部の要件は数値目標ではなく、いかなる場合も通過しなければならない「ハードゲート」として扱うべきだ。
| リスク層 | 例 | 評価アプローチ |
|---|---|---|
| 低 | パイプラインエラーの説明 | 有用性・正確性を計測（人間が検証） |
| 中 | マージリクエストの準備 | テスト通過、スコープ限定、レビュアー承認が必要 |
| 高 | マージまたはデプロイ | 厳格な認可、必須制御、可逆性、高い信頼性閾値が必要 |
ハードゲートの典型例として、記事は以下を挙げる。
- 識別と認可: アクションはエージェントと起動ユーザーに帰属可能、最小権限で動作
- ポリシーと承認: セキュリティ・コンプライアンスポリシーが適用され、必須の人間チェックポイントをバイパスできない
- 監査可能性と制御: エージェントの行動と理由を再構成できる、高影響変更は元に戻せる、エージェントを停止・無効化できる
これらは書類上の確認だけでなく、ネガティブテスト（許可外スコープでのアクション試行、必須コンテキストの除去など）で実際に検証することが求められる。
コストは「タスクあたりの総コスト」で比較する
エージェントが工数を削減しても、レビューや手戻り、エスカレーション対応にかかるコストが見落とされがちだ。記事が推奨するのは「エージェントが生成した分数」ではなく、「タスク成功1件あたりの総人間工数」を指標とすること。
コスト評価では、モデル・プラットフォームの消費コスト、レビュー工数、手戻りコスト、監視・サポートの間接費をすべて含めて現行ベースラインと比較する。
スコアカードで意思決定に接続する
記事は最終的に、各証拠を意思決定に紐付ける9次元のスコアカード（ビジネス成果、タスク成功、信頼性、人間工数、経済性、認可、ガバナンス、安全・回復、採用）を提示している。ハードゲート項目は「Must pass」、それ以外は事前定義した目標値と比較する構造だ。
評価実施後に閾値を設定すると、観察結果に合わせて成功の定義を後付けで変えることができてしまう。閾値は必ず評価前に定義することを記事は強調している。
詳細はHow to design a decision-grade pilot for agentic AIを参照していただきたい。
