AI プロジェクトが失敗する理由と、原因ごとの実践的な対策

AI プロジェクトが失敗する理由：調査は何を示しているか

各種調査は、多くのプロジェクトが試験導入から本番の間で止まること、そしてその理由がモデルであることはまれだという点で一致しています。MIT NANDA は2025年7月、95%の組織が生成 AI から測定可能な損益上のリターンを得られていないと報告し、その要因として、壊れやすいワークフロー、文脈から学習しないツール、日々の業務との適合の悪さを挙げました。

BCG が2025年10月に発表した、広がる AI の価値格差に関する報告では、AI から大規模に価値を得ている企業はごく一部にとどまることが分かりました。S&P Global Market Intelligence の調査によると、2025年には AI の取り組みの大半を断念した企業の割合が増えており、その理由としてコスト、データのプライバシー、セキュリティが挙げられています。Gartner は2025年6月、エージェント型 AI プロジェクトの40%以上が、コスト、不明確な価値、リスク管理の弱さを理由に2027年末までに中止されると予測し、「エージェント・ウォッシング」にも警鐘を鳴らしました。

これらの調査結果を合わせて読むと、7つの原因が浮かび上がります。以下では、それぞれの原因を1つずつ取り上げ、当社が講じている対策とあわせて説明します。

原因1：出発点を誰も測定していなかった

導入前に業務がどのように回っていたかを誰も記録していなければ、プロジェクトは価値を示せません。Gartner の言う「不明確な価値」は、まさにこれであることが少なくありません。システムは動いているのに、比較するための導入前の数値がなく、予算の見直しの場で示せるものが何もないのです。

対策は、構築の前に測定することです。対象のワークフローについて、1件あたりの所要時間、月あたりの件数、エラーややり直しの発生率、担当者を記録します。目標も同じ単位で合意し（たとえば請求書の入力時間と修正が必要な請求書の割合）、稼働開始から毎月のレポートで比較を示します。

まだ基準値を測定できない場合は、構築に予算をつける前に2週間かけて手作業で記録してください。費用はほとんどかからず、本当のボトルネックが皆の想定とは別の場所にあると分かることもよくあります。

原因2：実際の入力でワークフローが壊れる

MIT NANDA が最初に挙げた壊れやすいワークフローは、たいていきれいなサンプルだけでテストしたことが原因です。実際の入力には、スキャンした PDF、転送が重なったメールのやり取り、途中で話題を変える電話の相手、少し違う名前ですでに CRM に登録されているレコードなどが含まれます。

対策は、正解が分かっている実際の雑多な事例から評価セットを作り、プロンプト、検索の仕組み、モデルを変更するたびに再実行することです。さらに項目単位の検証（合計が一致すること、日付が範囲内であること、ID が NetSuite や QuickBooks に存在すること）を加え、信頼度のしきい値を設けて、疑わしい項目は推測させずに人による確認キューに回します。

• 失敗例も含め、直近数か月の実際の入力から作った評価セット。
• 基幹システムに書き込むすべての項目に対する検証ルール。
• 信頼度のしきい値を下回るものはすべて人による確認キューへ。

原因3：ツールが日々の業務の外にある

MIT NANDA が3つ目に挙げた日々の業務との適合の悪さは、利用者がわざわざ開くことを覚えておかなければならない別のチャット画面やダッシュボードという形で現れます。数週間もすると誰も開かなくなり、利用はいつの間にかゼロになります。

対策は、すでに業務が行われている場所に出力を届けることです。Zendesk のチケット内の返信の下書き、HubSpot や Salesforce に入力済みのレコード、ERP で承認を待つ仕入先の請求書、チームが既存のチャンネルに投稿する要約などです。当社の事例の1つは、チャットボットをまったく使わずに同じ原則を示しています。セラピーサービスの事業者が、検証機能と請求連携を備えたガイド付きの AppSheet ポータルに臨床スタッフを移行したところ、データ入力は1日10〜15分から3分未満に減り、エラーは発生源で防がれるようになりました。

原因4：システムが文脈から学習しない

固定されたプロンプトから回答するシステムは同じ誤りを繰り返します。文脈から学習しないツールが MIT NANDA のリストに入っているのはそのためです。方針は変わり、価格表は更新され、スタッフは毎週同じ誤りを修正しているのに何も改善しません。

対策は2つあります。1つ目は、出典付きの検索によって最新の社内文書に基づいて回答させることです。そうすれば SharePoint や Google Drive のファイルを更新するだけで回答も更新され、確認担当者は根拠を確認できます。2つ目は、改善のループを閉じることです。確認キューで行われた修正はすべて記録して評価セットに加え、定期的にプロンプトやルールの調整に活用します。

ボイスエージェントでは、同じ考え方を通話記録に当てはめます。エージェントが転送した通話、聞き違えた通話、相手が途中で離脱した通話こそが、次のプロンプトと振り分けの改善にとって最良の材料になります。

原因5：価値よりも速くコストが増える

コストは、S&P Global と Gartner の両方の調査結果に登場する理由です。モデルのトークンや通話時間の従量課金は処理量に応じて増え、ループにはまったエージェントは、そのタスクの価値を上回る金額を半日で使ってしまうこともあります。

対策は、予算をシステムに組み込んで設計することです。タスクごとにコスト上限を設けて上限に達したら処理を止めて担当者に通知し、最初のテストからタスクごとのトークン数と通話時間を記録し、単純な分類は小さなモデルに回して大きなモデルは本当に推論が必要な処理に使い、毎月タスクあたりのコストとタスクあたりの価値を比較します。追跡すべき運用コストの内訳は、当社の AI 導入費用ガイドにまとめています。

原因6：プライバシーとセキュリティの懸念で展開が止まる

データのプライバシーとセキュリティは、S&P Global の調査で挙げられたもう1つの理由です。これらは、法務や IT が初めて設計を目にする終盤になって表面化することがよくあります。個人向けのチャットアカウントで作った試験導入版は、顧客や患者のデータを扱う本番環境には移行できません。

対策は、最初の数週間でデータの取り扱いを確定させることです。自社のデータに合った利用条件の API またはエンタープライズ向けプランを使い、保護対象の医療情報に触れるすべてのベンダーと業務提携契約（BAA）を締結し、システムには必要最小限のアクセス権だけを与え、すべてのプロンプトと出力を記録します。アカウントはお客様が所有するため、データはお客様が管理する契約のもとにとどまります。

IT と法務は、構築の後ではなく、構築前のレビューの段階から参加してもらいましょう。どのシステムを読み取り、どのシステムに書き込み、どのベンダーがデータを扱い、ログをどこに保存するかを示した1枚のデータフロー図があれば、彼らの疑問の大半に早い段階で答えられます。

原因7：十分な管理がないままエージェントが動く

リスク管理の弱さは、Gartner の中止予測で挙げられた3つ目の理由です。エージェントは文章を書くだけでなく実際に操作を行うため、リスクはさらに高まります。エージェント・ウォッシングも問題を大きくしています。自律型エージェントとして販売されていながら実際は単純なスクリプトにすぎない製品や、購入者が想定していたよりもはるかに自由に動く製品のことです。

対策は、エージェントにできることに枠をはめることです。使えるツールを明示し、各ツールに最小限の権限を与え、金銭の移動、顧客への連絡、規制対象の記録の変更には人による承認を必須とし、エージェントを停止して業務を人に戻せるロールバック手段を用意しておきます。ベンダーを評価する際は、最終的な回答だけでなく、実際の実行時のツール呼び出しとログを見せてもらってください。

社内で構築すべきか、専門パートナーと構築すべきか

MIT NANDA は、専門パートナーから購入した、あるいは専門パートナーと構築したプロジェクトのほうが、社内構築よりも成功率が高かったと報告しています。同じ調査では、予算は営業やマーケティングに偏っていたにもかかわらず、最大のリターンはバックオフィスの自動化から生まれていたことも分かりました。

どちらの道を選んでも、重要なのは上で挙げた対策です。当社は無料レビューで各プロジェクトの範囲を定め、固定価格の構築としてお見積もりし、お客様のチームが運用できるようコード、プロンプト、アカウントをお渡しします。導入の各段階の順序は、当社の AI 導入の手順ガイドで解説しています。