「セキュリティ整備まで終わった。これでプロジェクトは回るはず。」先月、ある製造大手のDX部門長がコーヒーを片手に語った言葉です。実際その会社は半年かけて、監査ログ・PIIマスキング・権限分離をすべて整えていました。ところが上半期レビューで、プロジェクトは「一旦保留」という結論に至りました。
理由は一つではありません。データは依然として散在し、PoCではうまくいっていたケースが実ユーザートラフィックでは崩れ、リリース2ヶ月目には誰もダッシュボードを開かなくなっていた。正確に言えば、セキュリティは通過条件であって成功条件ではなかったのです。シリーズ第6回でセキュリティ・ガバナンスを整理したのなら、今回はその次に立ちはだかる壁の話です。
MIT Project NANDAが2025年7月に発表した調査では、生成AIのパイロットを走らせた組織の95%が、測定可能なP&Lへの影響を得られなかったと回答しています。RANDのエンタープライズAI分析では80.3%が約束されたビジネス価値を出せず、そのうち33.8%は本番投入前にすでに廃棄されました。数字だけ見ると絶望的ですが、失敗の仕方は驚くほど繰り返し的です。複数のプロジェクトを間近で見てきた経験からすると、結局5つのパターンに収束します。
1. データ未整備 — 散在した文書の上にRAGを載せた瞬間
ある初回ミーティングで、部門長は「社内文書はSharePointにあります」と答えました。開いてみると、フォルダ34個、重複文書1,200件、最新マニュアルと3年前のバージョンが同じ名前で共存していました。この状態でRAGインデクシングを回すと何が起きるか。ユーザーが「返品規定」を尋ねたとき、2022年版と2025年版が混ざった答えが返ってきます。しかも、いかにも正しそうに。
失敗プロジェクトの85%がデータ品質を根本原因として指摘した、という業界調査があります。データがAIアプリケーションを支えられるレベルにある組織はわずか12%。つまり残る88%は「今のデータで一旦始めよう」の罠に足を踏み入れているわけです。
- 原本文書の最新性・重複・バージョン状態を最低3週間かけて点検
- PII・機密等級を文書単位でタグ付け
- RAGインデクシング前に「ゴールドセット100件のクエリ」で正答率を事前測定
- 正答率が70%未満ならデータ整備を先に完了させる
2. PoCの罠 — デモでうまくいったものが実トラフィックで崩れる
S&P Globalの調査では、AI PoCの46%が本番到達前に廃棄されました。この数字を初めて見たときは「そんなにか」と思いましたが、いくつか事例を経験すると腑に落ちます。
PoCデモは大体こう進みます。用意された20件のクエリでデモ、参加者から拍手、「本格開発に進みましょう」。ところが実ユーザーは予想外のことを尋ねます。誤字・タメ口・俗語・重複質問・3つの質問を一つに詰め込むケース。PoC精度92%が本番精度61%まで落ちます。原因は明確で、デモ設定が「理想的なユーザー」を前提としていたからです。実ユーザーは理想的ではありません。
- PoC段階から実ユーザーログ(匿名化)で評価する
- 「意図的にぎこちないクエリ50件」をストレスセットとして維持
- PoC成功基準を「デモ通過」ではなく「実運用精度X%以上」で明文化
3. 運用不在 — リリース2ヶ月目には誰もダッシュボードを開かない
正直、このパターンが一番よく見かけます。リリースはイベントです。運用は習慣です。ほとんどの組織はイベントまでしか予算を組んでいません。
リリース後に必要な仕事は明白です。週次の精度指標チェック、失敗ケースのレビュー、プロンプト改善のPR、モデル更新への対応、利用状況レポート。これを担当する人がいなければ、3ヶ月後にはツールはそのまま、ユーザーだけ消えます。ごく自然な結末です。
Gartnerが2026年4月に発表した資料では、AIインフラプロジェクトのうち約束されたROIを達成したのは28%でした。未達グループの多くが運用リソース不在を挙げています。うまく作ることと、長く使われることは、別のゲームです。ROI指標の設計そのものはシリーズ第3回で扱いました。そのとき定義したKPIを実際に「毎週誰が見るのか」が、運用の成否を分けます。
- リリース前に運用担当者と週次指標レビュー会議をカレンダーに登録
- プロンプト・データ更新のPRを月2件以上のリズムで維持
- 利用量が落ちた際のアラートと対応プロセスを文書化
4. 過剰な期待 — 「AIが全部やってくれる」という前提の代償
このパターンは決裁者よりも導入スポンサー側でよく現れます。「従業員の代わりにAIに処理させよう」という絵です。最初は魅力的ですが、人間のチェックポイントを外した自動実行は事故につながります。
2026年、エージェンティックシステム失敗の最も一般的な原因が「human-in-the-loopチェックポイントの欠如」だったという報告があります。自律性を過信すると、誤った判断が人間の介入なしにそのまま実行されます。カスタマー対応での誤った返金承認、文書自動生成での事実誤認のそのまま配信。一度事故が起きれば、組織内の信頼は崩れ、プロジェクト自体が中止に追い込まれます。
- 自動実行アクションは「金額・範囲・重要度」を基準に人間の承認ステップを定義
- 初期3ヶ月は全アクションを「提案モード」で運用し、レビューログを蓄積
- 信頼指標(承認率・修正率)を確認した上で段階的に自動化
5. セキュリティの後回し — 監査・法務レビュー段階でロールバックされるパターン
前回で扱ったテーマですが、「セキュリティは後で」という判断がプロジェクト後半にどう返ってくるか、短く触れておきます。
ある事例。サービス開発90%完了、社内デモ成功。ところが法務レビューで「監査ログが個人情報の原文をそのまま保存している」との指摘。リファクタリング規模が大きく、結局4ヶ月のロールバック。当初予算の40%が追加で投じられました。62%の組織がデータガバナンスで困難を抱えているという調査がありますが、こうした後半のロールバックがその統計の実体です。
コスト観点の爆発はシリーズ第5回で整理しました。セキュリティを後手に回すことで生じる予算超過が、あの回のケースと正確に噛み合います。
- アーキテクチャ設計段階から監査・法務担当者をレビュアーに指定
- PII・監査ログ・権限分離はMVPスコープに含める
- サービスリリース前の「法務サインオフ」をスプリント完了条件として登録
まとめ — 失敗の共通点は「作ること」ではなく「続けること」
5つを並べてみると、共通点が一つあります。すべて「作ること」ではなく「続けること」の問題だという点です。失敗の大半は技術選定ではなく、組織・プロセス設計で決まります。5years+で進める自社LLMプロジェクトの初回ミーティングの半分以上は、この5つのうちどのリスクが最も大きいかを一緒に確認する時間に使っています。検討中でしたら、お気軽にプロジェクトリスク無料点検から現況を共有いただけたらと思います。
次回はシリーズ最終の実行編です。診断→PoC→運用・追加開発までの段階別実行プランを整理します。今回の5つのパターンを避けながら、実際にプロジェクトを回すためのカレンダー・役割・マイルストーンの視点の話です。