デモは終わったのに、誰もデプロイを承認できません

AIは顧客からの問い合わせをかなりうまく分類しています。発表画面でも結果は良く、現場の反応も悪くありません。ところがプロダクションへのデプロイを話し始めると、質問が次々に出てきます。どの程度の誤りまで許容されるのか、顧客データにアクセスしてよいのか、事故が起きたら誰が停止するのか。決まった答えがありません。

この段階でモデルをさらにチューニングしても、問題は解決しません。プロダクションへ進むための基準を、パイロット前に書いていなかったからです。VellumのAI変革プレイブックが示す実践的な変化もここにあります。戦略、チーム、ツール、パイロット、組織展開の順に進めつつ、KPI・責任・データアクセス・承認条件は最初の段階から一緒に設計するということです。

NIST AI RMFも、GOVERNを最後の確認段階ではなく、MAP・MEASURE・MANAGEを横断する機能として位置付けています。ガバナンスはデプロイ直前にもらう承認印ではなく、何を作り、誰がどの条件で止めるかを継続して決める運用のあり方に近いものです。

まず「95%が死ぬ」という数字を手放す必要があります

Vellumの原文はMIT NANDAを引用し、企業の生成AIパイロットの95%が測定可能なROIを生み出せていないと紹介しています。 しかし、この文章を「95%がプロダクションへのデプロイに失敗した」、または「残りの5%は初期ガバナンスのおかげで生き残った」と言い換える根拠は確認できていません。

現在確認できるMIT NANDAの公式ページは、研究グループと研究の方向性を紹介し、当該レポートについては別のアクセス経路を案内しています。 公開されている公式原文で、標本構成、ROIの定義、95%の算出方法を直接確認できていないため、この数値を普遍的な失敗率として使うべきではありません。

持ち帰るべきなのは95%への恐怖ではなく、デプロイ判断の順序です。 Vellumの5段階はベンダーが提案するプレイブックであり、成功企業と失敗企業を統制比較した研究ではありません。したがって、特定の成功確率を約束するのではなく、自社パイロットの昇格条件を作るために使うべきです。

パイロット前に1ページで決めるべきことは7つです

ツール比較表より先に必要な文書は、「何がどれだけ改善すべきか、どのようなリスクが生じたら止めるか」を結び付けた1ページの運用合意です。少なくとも次の7項目を一か所にまとめる必要があります。

項目記載すべき内容空欄の場合に起きる問題
KPIベースライン現在の処理時間・コスト・エラー率改善したか比較できない
目標と期間いつまでにどの水準を達成するかパイロットが終わりなく続く
KPI責任者業務成果を最終判断する人良いデモがそのまま成功と見なされる
データ合意出所・所有者・アクセス・保持条件実データ接続の段階で止まる
権限分離構築者・承認者・デプロイ担当者作った人が自らリスクを承認する
エラー予算許容エラーと即時中止すべき事故問題が起きても継続判断ができない
ロールバック経路既存業務へ戻す方法と権限者デプロイ後に安全に止められない

この文書は長いポリシー集である必要はありません。NIST AI RMFも、特定の組織図や製品を義務付けない、自発的で成果重視のフレームワークです。組織の利用文脈とリスク許容度に合わせて、GOVERN・MAP・MEASURE・MANAGEの行動を選べるよう設計されています。 生成AIを扱うなら、固有または増幅されるリスクに対応したNISTの生成AIプロファイルを補助資料として使えます。

最初のパイロットは実際の行動をオフにして始めてください

初日からAIに返金承認や顧客への送信を実行させる必要はありません。Vellumは、提案結果をレビューキューに送るシャドー実行から始め、SOPとゴールデンセットを比較し、その後に小規模なユーザーグループ向けの補助モードと限定的な自動行動へ範囲を広げる方法を提案しています。

AI RMF 1.0の現在・目標プロファイルの概念で状態を整理し、NIST AI RMF Playbookから必要な行動を選んだうえで、以下の順で一つの業務を準備してみてください。

  1. すでにベースラインを把握している業務を一つ選びます。 処理時間・コスト・エラー率のうち少なくとも一つを、現在記録している必要があります。ベースラインがなければ、AIを接続する前に今週から同じ基準で記録してください。
  2. 価値仮説と中止条件を一文に入れます。 たとえば「90日間、担当者承認型の返金分類により、中央値の処理時間を12分から9分以下に下げつつ、全体の誤分類率は現在の4%を超えない」といった形で、対象・期間・目標・安全条件をまとめて書きます。90日と数値は例であり、組織の業務サイクルに合わせて決める必要があります。
  3. 人とデータに関する権限を分離します。 データの出所と所有者、許可されたアクセス方法を記録し、構築者・業務承認者・プライバシー確認者・デプロイ担当者を指定してください。一人が複数の役割を担う場合でも、どの権限で判断したかは区別しなければなりません。
  4. 行動をオフにしたシャドー実行を行います。 通常ケースと代表的な失敗ケースでゴールデンセットを作り、AIの結果は顧客に送らずレビューキューに蓄積します。SOPに対する合格率とエラーの種類を記録してください。
  5. すべてのゲートを通過した場合にのみ補助モードを開放します。 評価しきい値、エラー予算、データ統制、所有者の承認をすべて満たしたら、小規模なユーザーグループに提案機能のみを提供します。範囲を広げる際にも、同じゲートを再確認します。

対象業務: ______
ベースライン / 目標 / 期間: ______
KPI責任者: ______
データの出所・所有者・アクセス条件: ______
構築者 / 承認者 / デプロイ担当者: ______
合格しきい値とエラー予算: ______
即時中止条件: ______
ロールバック方法と権限者: ______

最初の成功は自動化率ではありません。 この文書とシャドー実行の結果を見て、責任者が「この条件であれば小規模な補助モードを開放してよい」と承認できる状態が、最初の運用成果です。ベースライン、データ権限、失敗ケース、ログまたはロールバック機能のいずれか一つでも確認できていなければ、モデル改善より先にその空欄を解決すべきです。

さらに深く知りたい場合

Complete 2026 AI Business Transformation Playbook 戦略から組織展開まで続く5段階と、シャドー実行・昇格ゲートの例を確認できます。ベンダーの推奨であるという限界を踏まえ、実務チェックリストとして読むのがよいでしょう。 vellum.ai

Artificial Intelligence Risk Management Framework (AI RMF 1.0) GOVERNがライフサイクル全体を横断する理由と、MAP・MEASURE・MANAGEとの関係を原文で確認できます。 nist.gov

NIST AI RMF Playbook 組織の利用文脈に合わせて選べる具体的な行動を確認できます。 nist.gov