「AIエージェントを試しに導入してみたが、いつまでも社内ツールの域を出ない」という声は珍しくない。複数の調査で、AIエージェントのパイロットのうち本番稼働まで到達するのは1〜3割程度にとどまるとされる。原因はモデルの性能ではなく、権限設計・エスカレーションルール・監査体制といった「地味な準備」の欠如にあることが多い。本記事ではオーストラリアの銀行が実際に直面した炎上事例を手がかりに、パイロットを本番に乗せるための実務チェックリストを整理する。
パイロットの9割は本番に届かない
ある業界レポートは、企業の79%が何らかの形でAIエージェントを導入済みと回答した一方、実際に本番運用まで進んでいるのはわずか31%にとどまると報告している。88%のパイロットが本番化前に頓挫する理由は、モデルの精度不足ではなく「スコープ設定」と「ガバナンス」の欠如だという。あわせて、MIT NANDAの調査など複数の独立調査は、企業の生成AI導入の実に約95%が損益計算書に測定可能な影響を与えられていないと警鐘を鳴らしている。
一方で、ガバナンスを整えたうえで本番稼働にこぎつけた企業は平均171%（米国企業では192%）のROIを実現しているという報告もある。つまり差を分けているのは「モデルの賢さ」ではなく「導入前の設計」であるという点は、実務担当者にとって重要な示唆だ。
失敗の実例：コモンウェルス銀行のAIボイスボット
2025年7月、オーストラリア最大手のCommonwealth Bank of Australia（CBA）は、コールセンターの担当者45名をAI音声ボットに置き換えると発表した。しかし導入後、ボットは複雑な問い合わせに対応しきれず、かえって入電数と待ち時間が増加。管理職が電話対応に回る事態となり、わずか1カ月後にCBAは「削減した役割は実際には不要ではなかった」と誤りを認め、解雇した従業員に復職を打診する事態となった（ABC News）。
金融労組（FSU）は「CBAの失敗はAIが機能しないことの証明ではなく、人を置き去りにしたAI導入が機能しないことの証明だ」と指摘している。業務の一部を完全自動化する前に、実際の問い合わせ分布や例外処理の頻度を検証していなかったことが根本原因とみられる。
なぜ本番稼働まで届かないのか
2026年のMIT Sloan CIOシンポジウムでも、同種の課題が指摘されている。MIT Sloanの研究者George Westerman氏は「エージェントは多くの組織でまだ実戦投入に耐えられる段階にない」と述べ、「エージェント」という言葉が実態以上に高度なものであるかのように使われている点にも警鐘を鳴らした。また別の登壇者は、ヒューマン・イン・ザ・ループ（HITL）の形骸化を指摘している。承認依頼が高速で大量に飛んでくると、担当者は内容を精査せずに機械的に承認してしまい、「人の目によるチェック」が名目だけのものになるという問題だ。
調査会社Kiteworksの2026年調査によれば、企業の41〜44%はエージェントに対する基本的なガバナンス（HITLの監督体制を含む）を未整備のまま運用しており、55〜63%は用途制限（パーパスバインディング）・キルスイッチ・ネットワーク分離のいずれも導入していないという。つまり多くの現場は「動くから使っている」段階にとどまり、「止め方」「例外の扱い方」を事前に設計していない。
本番化前に確認したいチェックリスト
| フェーズ | 入口条件 | 主なチェック項目 |
|---|---|---|
| 1. スコープ確定 | 対象業務の問い合わせ分布・例外パターンを実データで把握 | 成功指標（KPI）とROI目標を事前定義／対象外にする業務を明文化 |
| 2. 権限設計 | エージェントが読み書きできるデータ・システムの一覧化 | 最小権限の原則／個人情報・決済情報へのアクセス制限 |
| 3. エスカレーション設計 | 自動処理してよい範囲と人へ回す範囲の線引き | リスク別の4段階分類（自動実行／通知のみ／承認待ち／人が対応）／承認担当者の実質的な精査時間の確保 |
| 4. ガバナンス整備 | 監査ログ・キルスイッチ・ネットワーク分離の実装 | 異常時に誰がどう止めるかの手順書／EUなど該当地域の規制要件の確認 |
| 5. 限定本番運用 | ガバナンス審査の通過・モニタリング稼働 | 小規模から段階的に対象範囲を拡大／週次で誤対応率と人による差し戻し率を確認 |
明日からできる実務Tips
- 小さく始めて、数字で語る：全業務を一気に置き換えず、問い合わせ全体の一部（例：定型FAQのみ）から始め、対応時間・エラー率・顧客満足度の変化を数字で追う。
- 「止める練習」を先にする：エージェントを稼働させる前に、異常時にどう止めるか、誰が判断するかを訓練しておく。CBAの事例のように、稼働後に慌てて元に戻す事態は避けたい。
- 承認は「精査できる量」に絞る：承認依頼が多すぎるとHITLが形骸化する。本当に人の判断が必要な高リスクケースだけをエスカレーションする設計にする。
- 例外処理の設計に時間をかける：定型ケースのデモは簡単だが、実務の難しさは例外対応にある。想定外の問い合わせが来た時に「わかりません」と正直に人へ引き継げる設計を優先する。
- 現場の声を早期に巻き込む：実際に業務を担当してきた担当者は、想定外のケースやボトルネックを一番よく知っている。設計段階から巻き込むことで手戻りを減らせる。
主な情報源
- Commonwealth Bank backtracks on AI job cuts, apologises for ‘error’ as call volumes rise – ABC News
- Did a bank have to rehire fired employees after their AI replacement was bad at the job? – GovTech
- Agentic AI Implementation Guide 2026: From Pilot to Production – TechStoriess
- Enterprise AI Rollout Failures: Causes and Case Studies – IntuitionLabs
- Agentic AI: What Leaders Wish They Knew Sooner – MIT Sloan Management Review
各ツールは提供元の規約に従ってご利用ください。情報は各情報源の公開時点のものです。収集・要約はAI、公開判断は人。