AIエージェントPoCを社内承認へ進める12項目

承認が止まる理由は、技術不足とは限らない

AIエージェントのPoCは動いているのに、実運用の許可が下りない。よくある原因は、精度よりも『誰が、何を、どこまで承認するのか』が資料から読み取れないことです。

デモは正常系を見せれば成立します。一方、社内承認には失敗時の振る舞い、費用の上限、停止方法、実行済み範囲の確認方法まで必要です。次の12項目を、1ワークフローに限定して埋めていきます。

1—4：対象と権限を固定する

まず、AIが触る対象を曖昧な『業務』ではなく、観測できるアクションへ分解します。

• 対象ワークフローを一つに限定した
• 読み取り・生成・更新・送信を別アクションとして列挙した
• 各アクションのデータ区分と実行環境を記録した
• 自動実行、要承認、禁止の境界をアクションごとに決めた

5—8：上限と停止条件を決める

『問題が起きたら止める』では遅すぎます。問題の兆候を数値か状態で定義し、止めた後に誰が何を見るかまで決めます。

• 1回・1日・プロジェクト全体の予算上限を設定した
• 実行回数、所要時間、並列数、再試行回数に上限がある
• 緊急停止が新規実行と再試行の両方を止める
• 停止後の確認者、復旧条件、再開承認者を決めた

9—12：証跡を意思決定に変える

ログを大量に残すだけでは、承認資料になりません。入力、判断、実行、結果が追える最小限の証跡を、意思決定者が読める形に束ねます。

• 入力・判断・ツール実行・結果を同じ実行IDで追跡できる
• 部分成功と不明な副作用を正常終了から区別できる
• テスト結果と未検証項目を同じ資料に明示した
• APPROVEDまたはSAFE_HOLDを、根拠と次の条件つきで記録した

最初の会議で決めるのは、完全自動化ではない

初回の承認で目指すべきは、限定された条件のもとで安全に学べる状態です。対象を広げる判断は、最初のパイロットから得た証跡を見て行えます。

12項目のうち一つでも責任者が決まらない場合は、SAFE_HOLDが妥当です。止める判断を失敗扱いせず、次に満たす条件を残すことが、PoCを前へ進めます。