#ai#agents#compliance#testing#platform
エージェントSDK時代の実務設計: 安全性評価と運用統制のプレイブック
エージェントSDKの機能強化は続いています。ツール呼び出し、計画、ガードレールの実装は以前より簡単になりました。一方で、企業導入で問題になるのは「できるか」ではなく「安全に繰り返せるか」です。
この視点に切り替えないと、デモは成功しても本番で止まります。
モデル評価からシステム評価へ
本番の品質は、モデル単体の正答率では決まりません。最低でも3層評価が必要です。
- 能力評価: タスク完了率、品質、応答時間
- 安全評価: ポリシー逸脱、危険なツール操作、機密露出
- 耐障害評価: 外部API失敗時の復旧、再試行、劣化挙動
この3層が揃って初めて、リリース可否を説明できます。
単一プロンプト検証をやめる
企業運用で必要なのは、再現可能な「シナリオライブラリ」です。
- 実データに近い入力分布
- プロンプトインジェクションや矛盾指示などの対抗ケース
- 複数ツール連携と途中失敗
- 正解だけでなく、許容される回復挙動の定義
毎リリース同じシナリオを回し、差分で劣化を検出します。これがないと、改善と改悪を区別できません。
アクション影響度で統制を分ける
全タスクを同じ強度で管理すると、現場は必ず回らなくなります。影響度でクラス分けします。
- Class A（参照系）: 検索、要約、分類
- Class B（内部更新）: チケット更新、ドラフト生成
- Class C（外部副作用）: 顧客送信、課金、不可逆更新
クラスごとに以下を対応させます。
- 承認ゲートの有無
- ログ粒度と保存期間
- 許可ツールセット
- 実行しきい値（信頼度、検証結果）
この設計で、過剰統制と統制不足の両方を避けられます。
デモ承認ではなく証跡承認へ
エージェントのリリース承認は、デモ動画では不十分です。次の「証跡パケット」を必須にします。
- 評価シナリオの合否サマリー
- 主要失敗カテゴリの推移
- ポリシー拒否率と理由分布
- 未解決リスクのオーナーと期限
承認者は「見た目」ではなく、再現性のある証跡で判断します。
SREとして運用する
エージェント運用は、SREの枠で管理すると安定します。
- クラス別SLO（成功率、遅延、ポリシー準拠率）
- エラーバジェット運用
- バジェット枯渇時の自動停止
- プロンプト/ツール/ポリシーのロールバック経路
ここまで設計されて初めて「速く安全に回す」が成立します。
導入段階モデル
段階1: 社内コパイロット
低リスク業務で計測基盤を整える。
段階2: 支援実行
提案は自動、外部副作用は人手承認。
段階3: 条件付き自律
限定クラスのみ自律実行、厳格ポリシーを適用。
段階4: 継続最適化
テレメトリと事後分析で週次改善を回す。
経営向けKPI
現場だけでなく経営判断にも使えるKPIが必要です。
- クラス別タスク完了率
- ポリシー違反試行率
- 人手介入率
- 成果単位コスト
- 顧客影響インシデント件数
製品・リスク・コストを同時に見ないと、拡大判断は歪みます。
まとめ
SDKの進化は導入の入口を広げますが、継続運用を決めるのは評価設計と統制設計です。シナリオベース評価、影響度別ガバナンス、証跡に基づく承認プロセスを標準化できる組織が、エージェント導入を安定して拡大できます。
