AIプログラムの多くは失敗しない。停滞するだけだ。

パイロットは成功するように設計されている。プログラムはそうではない。

パイロットは統制された環境だ。範囲が定まり、意欲のあるチームがいて、リソースの時間が確保され、物事を動かす経営層の後ろ盾がある。この条件は現実を代表していない。それが示すのは技術が動くということであって、組織がそれを運用できるということを示すのは別の問題だ。

パイロットが終われば、その条件のほとんどは消える。経営層の関心は次の施策へ移る。中核チームは解散する。パイロット中は迂回していたIT部門のチケット待ち行列が、いまや依存関係になる。隔離環境で三週間だった統合が、2009年に構築された本番システムを相手にすると九か月かかる。

Deloitteの2025年 AI導入調査では、停滞したプログラムの41%が、主因としてリソースの奪い合いと優先順位の競合を挙げた。モデルの性能、コスト、規制上の摩擦はほとんど挙がらなかった。技術は動き続けていた。組織のほうが守るのをやめたのだ。

---

業務プロセスはAI向けに設計されたことがない

二つ目の停滞はより構造的で、組織的な手当てでは動かしにくい。企業の業務プロセスの大半は人が実行する前提で設計されている。曖昧さ、例外処理、各段階での判断が含まれる。それは設計意図ではなかった。人が複雑さを吸収していたので、誰もそれを明示する必要がなかっただけだ。

AIは文書化されていない複雑さを吸収できない。その中で確実に動くには、あらかじめプロセスの境界が定義されている必要がある。既存の人間向けプロセスを作り直さずにAIを差し込む組織は、人間向けの仕組みの上にAIの形をした層を重ねることになり、性能の上限は、そのAIが触れる人間設計の最も弱い工程によって決まる。

Deloitteの調査は、これを本番運用での失敗を最もよく予測する単一の要因として特定した。導入前にAI前提の運用へプロセスを再設計した組織は、そうしなかった組織を測定可能なROIで三倍上回った。この再設計は技術プロジェクトではなくプロセスアーキテクチャのプロジェクトであり、モデルが稼働する前に済ませておかなければならない。

---

本番を持つ者がいない

パイロットでは、責任範囲が限られているために所有者が明確だ。プロジェクト責任者は定められた範囲の中で権限を持つ。プログラムがその範囲を超えて拡大すると所有権が争われ、争われた所有権は停滞の確実な前触れになる。

このパターンは組織を問わず一貫している。パイロットを作ったチームには、本番運用に必要なプロセス変更を命じる権限がない。その権限を持つチームはパイロットに関与しておらず、その結果に責任を感じていない。ガバナンスが規模を想定していなかったのは、規模こそが問題になるとは誰も思っていなかったからだ。

KPMGによるCFOとCIOの意思決定に関する調査では、AI投資が停滞するかどうかを最もはっきり予測するのは、予算でも能力でもなく、本番規模での所有者が定義されていないことだった。二人の責任者がガバナンスの枠組みなしに共同責任を主張し、役割が分離されていなければ、実質的には誰も責任を負わない。パイロットは増える。何も出荷されない。

---

ROIの枠組みが事業計画の後から作られている

企業のAIプログラムの多くは、測るべきでないものを、遅れて測っている。パイロットが生むのは精度指標、レイテンシの数値、利用者満足度のスコアだ。それらはモデルが動くことを示す。予算から5,000万ドルが出ていくのを見てきたCFOに投資継続を納得させるには、別の指標が要る。

AIの拡大に成功する組織は、ROIの測定アーキテクチャを技術アーキテクチャと同時に構築する。後付けの報告作業ではなく、生きたフィードバックループとしてだ。利益率への影響、価値の高い職務から取り戻した時間、AIが関わるプロセスの誤り率を追う。そのデータこそが、成功したパイロットを予算のついたプログラムに変える。

PwCの2026年CEO調査では、本番ROIのゲートをあらかじめ定義していた組織は、事後に性能を測っていた組織に比べ、AIの拡大に成功する確率が三倍高かった。このゲートは、拡大の前に、CFOが後で問うことになる問いへ答えることをプログラムに強いる仕組みである。

---

突破する組織が違うやり方をしていること

パイロットから本番へ規模を伴って移行するプログラムは、おおむねAIそのものが上手いわけではなく、AIが動くために必要な条件を整えるのが上手い。

そうした組織はプロセスの再設計を前提条件として扱う。導入後の最適化ではない。モデルが稼働する前に、それが動くプロセスは、明示的な入力、範囲の定まった判断区分、定義されたエスカレーション経路を軸に作り直されている。AIは、迂回すべきプロセスではなく、自分のために設計されたプロセスに出会う。

パイロットが終わる前に所有者を決める。本番規模の運用、変革管理、継続的なガバナンスに責任を持つチームは、パイロットが最初の結果を出す前に指名され、人と予算がついている。パイロットの後ろ盾が去ったとき、誰がプログラムを持つのかに曖昧さはない。

財務の測定を最初から組み込む。ROIのゲートは事後検証ではなく事業計画の中で定義される。モデルの精度ではなく事業インパクトを測るためのデータ基盤は、報告作業ではなく技術要件として扱われる。

原理として難しいことは一つもない。それでも一貫して省かれるのは、パイロットが速度と統制された条件を報い、本番はまさにパイロットを遅くする組織的な基盤を報いるからだ。これを理解した組織は、技術がよくなるのを待っていない。技術がすでに必要としている条件を作っている。

---

AI投資のサイクルが減速することはない。二年前に自ら承認したパイロットに本番の成果を求める取締役会が、これから辛抱強くなることもない。多くの組織にとっての問いは、拡大するかどうかではなく、パイロットのために作ったプログラムの構造が本番環境との接触に耐えられるかどうかだ。

大半は耐えられない。それは技術の問題というより設計の問題であり、解はある。