私が目にしてきた中で最も教訓に富むAIプロジェクトの失敗事例は、決して混沌としたものではなかった。計画は徹底しており、マイルストーンも達成された。システムは当初設定された期日に稼働を開始した。しかしその6カ月後、システムを利用する者はほとんどおらず、モデルの出力内容は本来貢献すべきビジネスの実態から乖離してしまっていた。プロジェクトは極めて規律正しく運営されていた。ただ、その規律自体が間違っていたのだ。
以前の記事で私は、AIイニシアチブは資金を投じる前に準備状況を見極めるテストを受けるべきだと論じた。本稿は、実行にゴーサインを出した後に何が起きるかについてである。多くの組織では、承認されたAIイニシアチブは、ソフトウェア導入で用いられるデリバリー（実行）の仕組み、すなわち「固定された要件」「マイルストーン計画」「本番稼働日」「ローンチと同時に解散するチーム」によって管理されている。しかし、その仕組みはあらかじめ答えがわかっている問題に対処するために作られたものだ。AIの導入プロセスはこれとは異なる。
AIプロジェクトが異なる理由
ベンダーの組み込みAI機能を有効にしたり、ルールベースのタスクを自動化したりするなど、より従来型に近く、従来の管理手法が通用するAIプロジェクトもある。しかし、多くのAIプロジェクトはむしろ実験としての性質を強く持っている。
・開始時の要件は「AIツールが特定の課題解決にどのように役立つか」という仮説である。
・出力は確率的であり、多くは正しいが間違うこともある。そのため、間違った場合の設計が必要となる。
・単にシステムが稼働するだけでなく、人々の働き方を具体的に変化させることで初めて価値をもたらす。
・データ、ユーザーの行動、規制などの変化に伴い、稼働後もシステムは変化し続ける。
従来のプロジェクト管理は、既知のスコープを納期通りかつ予算内で実現することに最適化されている。これを実験的なAIプロジェクトに適用すると、「期日通りに完成したものの誰も使わない成果物」か、「終わりのない実証実験（パイロット）」のどちらかを生み出すことになる。より優れたアプローチは、タイムラインよりも不確実性に焦点を当てることだ。
自社のAIプロジェクトにどちらのアプローチが最適かを知るには、次の問いを立てるべきである。
1. プロジェクトの要件は開始時点で固定できるか。
2. 出力は決定論的か、それとも確率的か。
多くの大規模な取り組みはハイブリッド型であり、統合やインフラについては従来のガバナンスを、モデルやワークフローの変更については「エビデンス・ゲート（証拠に基づく関門）」を適用するというように、切り分けることができる。実験的なAIプロジェクトにおいては、以下の4つのシフトを推奨する。
シフト1：要件から仮説へ
現在進行中のすべてのAIプロジェクトの要件を「仮説」として書き直し、それが「誰の」「どのような意思決定」を変えるのか、そしてプロジェクトが成功したと「どのように判断するのか」を明確に定義する。このように定義できないプロジェクトは、継続する準備ができていない。
したがって、「モデルは95%の精度を達成しなければならない」と言う代わりに、次のような検証可能な仮説を設定する。「カスタマーサービス担当者が定型的な問い合わせを開く前に返信案を受け取れば、その問い合わせの平均処理時間は、顧客満足度スコアを低下させることなく、1四半期以内に8分から5分に短縮される」。仮説には、誰が出力を受け取るのか、業務のどの時点で受け取るのか、どの指標が動くべきなのか、どの程度、いつまでに動くべきなのかを明記すべきである。
仮説が成り立つには精度が必要だが、精度が重要なのは、それが望ましい事業成果を生み出す範囲においてのみである。95%の精度を持ちながら担当者の働き方を何も変えないモデルは、その仮説に失敗している。85%の精度で処理時間を短縮するモデルは、仮説を満たしている。私は、精度目標を達成したにもかかわらず意思決定を何も変えなかったモデルも、精度目標を下回りながらも、周辺のワークフローが適切に設計されていたために成果を改善したモデルも見てきた。構築を始める前に仮説を書くべきである。
シフト2：日付ベースのマイルストーンからエビデンス・ゲートへ
日付が測るのは経過時間である。しかし本来測るべきなのは、チームがどれだけ不確実性を取り除いたかだ。すなわち、「データがモデルを支えられるか」「モデルが重要なビジネス成果を変えられるか」「関係者がそれを使うか」という不確実性である。イニシアチブへの資金提供は3つのゲートに分け、前のゲートを通過したことを示す証拠がある場合にのみ予算を解放する。
1. 実現可能性（Feasibility）：データが存在し、アクセス可能で利用できる状態にあり、限定的なサンプルにおいて仮説の妥当性が示されていること。
2. 価値（Value）：仮説で挙げた指標が開始時点よりも改善し、単に1週間だけ調子がよかったということではなく、複数のサイクルにわたって改善を続けていること。たとえば、パイロット運用の開始前に平均8分だった対応時間が、特定のチームの1週間だけでなく、2つのチームにおいて4週連続で短縮されている状態である。
3. 定着（Adoption）：対象となる担当者が日々の業務でシステムを使用しており、運用フェーズの責任者（オーナー）と予算が確定していること。
各ゲートには、書面による「通過基準」と「中止基準」、そして最大1回までの延長制限を設ける必要がある。2回目の目標未達は、プロジェクトの中止を意味する。チームが明確な基準に抵抗することは滅多にない。彼らが抵抗するのは、「継続するのに十分な状態」が曖昧であることに対してだ。
シフト3：デリバリーから定着へ
「機能している」ことと「使われている」ことは異なる状態であり、そのギャップにおいてAIの価値の大部分が失われる。このギャップを埋めるということは、ワークフローの変更をプロジェクトのスコープに含めることを意味する。すべての計画において、ローンチ後に誰の働き方が変わるのか、モデルが誤った判断をした際に最終決定権を持つのは誰か、そしてそのためにどのような権限とトレーニングが必要かを明記することを義務付けるべきだ。
シフト4：本番稼働からライフサイクルへ
従来のソフトウェアは、稼働後もその価値をほぼ維持する。誰かが変更するまで、300日目にも初日と同じことをする。しかし、AIシステムはそうではない。モデルが学習のベースとしたデータや顧客の行動、ビジネス環境が変化し続ける一方で、モデル自体は静止しているため、稼働したその日から性能の劣化が始まる。
稼働を開始する前に、プロジェクトの責任者、監視のルーティン、再学習を実行するトリガー、および運用予算を定義したライフサイクル計画の策定を義務付ける必要がある。これらは連動して3つの役割を果たす。第1に、顧客や規制当局に指摘される前に、モデルの性能低下を誰かが確実に察知できるようにすること。第2に、時間のある人に任せるのではなく、予算とルールを明確にした上でモデルの再学習や廃止を実行すること。そして第3に、監査人からシステムの挙動に対する責任者について問われた際、組織として一貫した明確な回答を用意できるようにすることだ。
監査人として私が実稼働中のAIにおいて最も頻繁に目にする問題は、モデル自体の質の低さではなく、責任者が不在であることだ。ライフサイクル計画がないのであれば、稼働させるべきではない。
次に取るべきアクション
自社のAIイニシアチブにおいてこれら4つのシフトを実行したら、状況報告書を書き換えよう。「どの不確実性を軽減できたか」と「どのような兆候があればプロジェクトを中止するか」という2つの項目を追加し、まずはその問いに答えるのだ。
従来のプロジェクトは、既知の目的地に至る道のりを管理する。一方、AIプロジェクトはまず目的地を見つけ出し、さらに難しい仕事である「人々をそこへ連れて行く」というプロセスに取り組まなければならないのだ。
