AIプロジェクトが失敗する7つの原因｜PoC・現場利用・本番移行をPMOで点検する

AIプロジェクトの行き詰まりを改善するには、「精度が足りない」という説明を、業務目的、利用者、データ、評価、本番運用の問題へ分けて確認する必要があります。この記事では、renueが計画・進行を点検する際の観点を7つに整理し、PoCから本番へ進む判断とPMOの役割を解説します。7項目は失敗原因の統計的な順位や網羅性を示すものではありません。

原因1〜3：目的・利用者・データの前提が揃っていない

原因1：AIを使うことが目的になっている

「AIを導入する」だけでは、何を改善できれば継続するかが決まりません。対象業務、困っている人、現在の処理量・時間・品質、変更後に必要な状態を整理します。例えば入力作業を支援するなら、生成にかかった時間だけでなく、確認・修正・登録までの合計を比べます。目標値は実測した現状と制約から決め、説明用の削減率をそのまま全案件の約束にしないことが大切です。

現行手順の整理、入力形式の統一、検索やルール処理でも改善できる部分があるかを確認します。AIを選ぶ理由と、採用しない場合の手段を残すことで、比較の軸が明確になります。経営課題と対象業務の優先順位をつなぐ進め方は、AI戦略の策定とPoC・ROI・運用の接続で整理しています。

原因2：実際に使う人と、確認する人が計画に入っていない

利用者、結果を承認する人、例外対応者、データを管理する人を分けて確認します。現場の担当者にはデモを見てもらうだけでなく、実際の入力、確認、修正、次工程への受け渡しを試してもらいます。忙しい時間帯に確認作業が増える、必要な権限がない、誤りの直し方が分からない、といった問題も評価対象です。利用しない理由を抵抗感やリテラシー不足だけで説明せず、業務の条件を確かめます。

原因3：使えるデータの量・品質・権限を確認していない

「データがある」と「目的に使えるデータがある」は別です。入力形式、欠損、重複、時点、正解の定義、実際の利用場面を表す範囲を確認します。取得・利用の権限や、社外のサービスへ送信できるかも先に整理します。準備工数は必要な作業を洗い出して見積もり、PoC期間の何割と一律には決めません。足りないデータと、その不足が検証結果をどの方向へ偏らせるかを記録します。

RANDの2024年の調査概要は、経験あるデータサイエンティスト・エンジニア65人へのインタビューから、問題の理解・伝達、データ、技術の目的化、基盤、技術的限界などを挙げています。同調査は、学習済みLLMを使うだけのプロジェクトを対象に含めていません。すべての生成AI案件へ同じ失敗率を当てはめる根拠とはせず、本記事では計画を確認する参考として用います。

原因4・5：評価条件が曖昧で、一度の成功を本番の保証にしている

原因4：合格・追加検証・中止を決める条件がない

評価は、業務上の成果、出力の品質、費用・時間、運用上の制約を分けて設計します。「精度」という一語だけで判断すると、何の誤りを何件まで許容するかが曖昧になります。文書の候補抽出なら見落としと不要な抽出を分け、分類なら全体の正解割合だけでなく、重要な対象を取り逃していないかも確認します。合格値は業務への影響と後工程で確認できる範囲から決めます。

人の確認を挟めば、どの品質でも利用できるわけではありません。担当者が誤りに気付けるか、確認に必要な根拠が示されるか、処理量に対して確認時間を確保できるかを検証します。高い影響を持つ用途では、対象を限定する、操作を保留する、AIを使わない方法へ戻すという判断も必要です。一律に「80点なら十分」とはせず、許容できない誤りと、起きた場合の扱いを決めておきます。

PoC開始時には、検証する仮説、対象データ、比較対象、評価担当、費用・期間の上限と、判断日を用意します。合格した場合の次工程に加え、追加検証で何を確かめるか、その検証でも不明ならどうするかを残します。手順の具体化は、PoCの評価基準・費用と本番移行の設計を参照してください。

原因5：入力や構成の違い、実行ごとの変動を確認していない

一つの入力で良い結果が出たことは、別の入力や本番の条件でも同じ結果になる証明ではありません。使うモデル、設定、プロンプト、参照データの版と日時を記録し、通常例だけでなく、欠損・例外・境界に当たる例も評価します。生成AIの出力が変動する場合は、必要に応じて同じ条件で繰り返し、結果の違いと業務への影響を確認します。すべてのAIが常に同じ種類の変動を持つと決めないことも必要です。

評価に使ったデータへ調整を重ねたら、別に保った確認用データでも試し、見かけの改善に偏らないようにします。実験からデータ処理・検証・運用へ進む工程は、GoogleのML開発段階の解説とMLパイプラインの解説も参考になります。自らモデルを学習する工程と、外部モデルを利用するシステムの評価・構成管理を同じ作業として扱わず、自社で変更できる範囲を整理します。

原因6・7：本番への移行条件と、運用の責任が決まっていない

原因6：PoC後に必要な実装と運用費用を見積もっていない

PoCで確認できたのが出力品質だけなら、権限管理、既存システムとの接続、処理量、応答時間、障害時の扱いは未検証かもしれません。本番へ進むために何が残るかを分け、必要な環境、データの受け渡し、契約、審査、担当者、費用と依存関係を整理します。検証用アカウントで動くことと、業務利用の条件を満たすことは別です。未決事項を隠さず、誰がいつ判断するかまで計画に含めます。

Googleの本番化の解説は、計算資源、ログ・監視・通知、展開の承認、失敗時の対応やロールバック等を挙げています。本番の評価では、品質だけでなく遅延、停止、利用量、データの変化を確認します。正解がすぐ判明しない業務なら、代理指標と後からの確認を組み合わせ、何を観測できていないかも残します。自動更新や毎日の再学習を、すべてのAIシステムに必要な前提とはしません。

原因7：利用・承認・変更・停止の担当が曖昧になっている

業務の責任者、技術の責任者、データ管理者、運用窓口が誰かを確認します。小規模なら兼務する場合もありますが、担当名だけでなく、判断できる範囲、代行者、異常時の連絡先を決めます。外部パートナーへ依頼する場合も、成果物、受入条件、保守、情報へのアクセス、引継ぎ資料を合意し、社内側で判断する事項を明確にします。研修の受講だけで、運用の責任が整ったとは考えません。

再試行の設計も、処理に合わせて行います。回答の生成をやり直す場合と、発注・送信・登録など外部に影響する操作を再実行する場合では、重複の影響が違います。回数・費用の上限、実行済みを確認する方法、承認、途中で止める条件を用意します。エラーが出たらすべて自動リトライする、という共通手順にはしないようにしてください。実行結果が不明な場合も、状態を確認してから次の操作を判断します。

NIST AI RMF Playbookは、Govern・Map・Measure・Manageに沿った提案を示す任意利用の資料です。全項目を順番どおりに実行するチェックリストではなく、現時点ではAI RMFの改訂後にPlaybookも更新する旨が掲載されています。日本の一律の法的義務や、採用すれば安全性が保証される仕組みと捉えず、用途とリスクに合う責任・評価・対応を検討する参考にします。

PMOが整えること：判断の記録と、次の行動への接続

PMOは、進捗表を更新することに加え、目的と検証結果、残る課題、次の判断を関係者が共有できる状態を整えます。確認頻度は、判断が必要になる速さと影響に合わせて決めます。すべての案件で週次が遅すぎる、毎朝の通知が必須、と決める必要はありません。期限超過や依存作業の遅れを通知する場合も、受け取る人が何を判断・実行すればよいかを結び付けます。

確認する項目	残しておく内容
目的と成果	対象業務、現状値、目標、比較条件、評価結果
課題と依存関係	確認した事実、未確認事項、影響、担当、期限
移行・変更の判断	承認者、条件、検証の証拠、残課題と次の行動
運用と引継ぎ	監視対象、異常時の連絡・停止・復旧、担当と資料

中止や範囲縮小も、検証で分かったことを次の判断へ使えれば意味があります。反対に、合格基準を後から動かし続けたり、費用を追加する理由が「精度向上」の一言だけになったりすると、判断が難しくなります。継続する場合は、何が不明で、次の検証でその不明点を解消できる見込みがあるかを説明します。結果だけでなく、採用しなかった案とその理由も記録し、同じ前提の検証を繰り返さないようにします。

効果の評価では、AIの処理時間に加えて、人の確認・修正、利用料、連携・保守、教育、例外対応を含めます。時間を金額換算した効果と、実際の支出減少を分け、処理量や品質条件を揃えて比較します。計算と評価の方法は、費用対効果・ROIとAI施策の評価で整理しています。数値が良く見えることより、どの前提なら利用を続けられるかを説明できることが重要です。

議事録、タスク、決定事項が分散して判断の経緯を追いにくい場合は、renueのPMOエージェントで、プロジェクト概況、タスク・サブタスク、定例会議、議事録等の管理を相談できます。取り込む情報と正本、更新・確認の担当、重要な判断での承認を決めて進めます。既存ツールとの連携はAPI、権限、データ形式等を確認し、会議の録音・録画は事前の周知と同意を含む運用を整えます。

業務への接続や個別システムの設計・実装が残る場合は、FDEによる要件整理から実装・運用までの支援へつなげられます。ツールで情報を整理する課題と、AIを業務の中で動かす実装課題を確認し、必要な範囲を具体化します。renueでは、分かった事実と残る不確実性を共有し、判断する人と実行する人を結ぶことが、プロジェクトを前へ進める土台になると考えます。