- DX
- 生成AI
AI導入が失敗する7パターン|つまずきの構造と、止まってからの立て直し方

AI導入は、始めれば必ず成果が出るというものではありません。検証は終わったのに次へ進めない、作ったものが現場で使われない、続けるべきかどうかも判断できない。よくある失敗には、いくつかの決まった型があります。そして原因の多くは技術そのものではなく、進め方のどこかで判断を飛ばしたことにあります。
そこでこの記事では、AI導入でよくある課題を7つのパターンに整理し、症状から原因を特定する方法と、そこからの立て直しの手順を解説します。これから始める方にとっては、どこでつまずきやすいかを事前に把握できる内容です。すでに止まっている案件についても、ゼロからやり直しになる例は多くありません。再開のための具体的な手順も紹介します。
目次
AI導入が失敗する7パターン|まず自社がどれかを見極める
AI導入の失敗は、それぞれ違って見えて、実際には限られた型に収まります。まず一覧で原因の例を示します。自社に当てはまる行から読んでください。
| パターン | 症状 | 本当の原因 |
|---|---|---|
| ① PoC止まり | 検証は終わったが本開発に進めない | 合格ラインを決めずに始めた |
| ② データ不足 | 思ったより精度が出ない | 着手前にデータの状態を確認していない |
| ③ 現場が使わない | 作ったが利用が伸びない | 設計に使う人が入っていない |
| ④ 温度差 | 経営は急ぐが現場が動かない | 目的が「AIを導入すること」になっている |
| ⑤ 効果不明 | 続けるべきか判断できない | 導入前の数字を記録していない |
| ⑥ 情報が古くなる | 回答の精度が落ちたように見える | 参照文書の更新担当を決めていない |
| ⑦ 担い手の消失 | 異動を機に止まった | 判断の経緯が個人の記憶にしかない |
右端の列を見てください。今回挙げた7つのパターンでは、AIそのものの性能だけでなく、進め方や体制に原因があるケースが多くあります。だからこそ、導入後でも立て直せる余地があります。
「期待どおりではない」状態が最も多い
日本情報システム・ユーザー協会(JUAS)の「企業IT動向調査2025」によると、言語系生成AIを導入した企業の導入効果について、「期待値には至っていないが一定の効果はあった」が36.1%で最も多い回答でした。「概ね想定どおりの効果であった」は33.1%、「期待を大きく超える効果があった」は4.0%です。
つまり最も多いのは、失敗でも成功でもない「なんとなく使えてはいるが、期待には届いていない」という状態です。この層は問題が表面化しにくく、そのまま放置されがちです。
同調査では、効果測定の方法について「効果測定を行っていない」が59.8%と最多でした。期待に届いているかどうかを測っていないのだから、何を直せばいいかも分からない。これが多くの企業の実態です。
この記事は止まってしまった案件の立て直しを主眼にしていますが、これから始める方にとっても、どこでつまずきやすいかを先に知る材料になります。着手の手順そのものはAI導入の進め方で解説しています。
① PoC止まり症候群|なぜ検証で終わるのか
最も多く、最も費用が無駄になりやすいのがこれです。数百万円をかけて検証したのに、本開発に進む判断ができないまま数ヶ月が過ぎます。
構造は3段階で決まっている
1. 合格ラインを決めずに始める
「まずやってみましょう」で着手すると、結果が出たあとで評価基準を議論することになります。精度80%という数字が高いのか低いのかは、業務によって違います。現状の人力の精度が95%なら足りませんし、人手が追いつかず未処理が溜まっている業務なら60%でも価値があります。
2. 判断する人が決まっていない
結果を見て「進む・止める」を決める人が曖昧だと、関係者の意見が割れたまま止まります。ここから先は技術ではなく社内政治の話になり、時間だけが過ぎます。
3. 止められない力学が働く
ここまでの費用が惜しい、経営に報告済みで引っ込みがつかない、関係者に説明しづらい。この状態になると、進むことも止まることもできなくなります。
立て直す手順
すでに止まっている案件でも、やり直しになるとは限りません。検証結果を捨てないでください。次の順で整理し直すと再開できます。
- 何が分かったかを書き出す — 「精度が◯%だった」だけでなく、どんな入力で成功し、どんな入力で失敗したかまで
- 何が分からなかったかを書き出す — 検証していない範囲を明示する。ここが次の検証範囲になります
- いま合格ラインを決める — 後付けでも構いません。数値と判断者を決めてください
- その基準に照らして判定する — 満たしていれば進む、満たしていなければ止める。止める判断も成果です
4つ目に抵抗があるかもしれませんが、数百万円の本開発に進む前に止められたなら、それはPoCが機能したということです。判断を先送りするより損失は小さくなります。
次回のための予防
検証を始める前に、次の4つを紙に書いて関係者で合意してください。「何を確かめるのか」「どうなったら合格か(数値で)」「誰が判断するのか」「いつまでにやるのか」。この4行があるだけで、PoC止まりのほとんどは防げます。
費用の考え方についてはAI導入の費用相場で、段階ごとに区切って発注する方法を整理しています。
② データが足りない問題|着手してから気づく
「思ったより精度が出ない」の原因は、モデルではなくデータにあることがほとんどです。そしてこの問題は、着手してから発覚します。
「データがない」には4種類ある
| 状態 | 具体例 | 必要な作業 |
|---|---|---|
| 存在しない | そもそも記録を取っていない | 記録の仕組みづくりから。数ヶ月〜 |
| 紙のまま | 帳票やメモが紙で保管されている | データ化。件数次第で数週間〜 |
| 散在している | 部署ごと・個人ごとにファイルが分かれている | 集約と重複の整理 |
| 形式が揃っていない | 同じ項目の書き方が担当者ごとに違う | 正規化のルール決めと変換 |
4つのうち上2つは、AI導入ではなくその前段の作業です。ここを見落とすと、計画より数ヶ月遅れます。
着手前に確認すべき3点
- どこにあるか — システム内か、共有フォルダか、個人のPCか、紙か
- どれだけあるか — 件数と期間。直近3ヶ月分で足りるのか、数年分が必要なのか
- 使える状態か — 形式が揃っているか、欠損がどれくらいあるか
この3点は、見積もりを依頼する前に自社で確認してください。情報が揃っていない部分は、見積もる側がリスクとして金額に上乗せせざるを得ません。「データがどこにどれだけあるか分からない」という状態では、正確な見積もりは出せないためです。
データが足りないと分かったら
選択肢は3つあります。
1. 対象業務を変える — データが揃っている別の業務から始める。最も現実的です
2. 整備してから進む — 効果が大きい業務なら、整備そのものに投資する価値があります。ただし期間と費用を計画に含めてください
3. データが要らない方法に切り替える — 既製の生成AIツールは、自社データがなくても文章作成や要約に使えます。まずここから始めて、社内の理解を得るという進め方もあります
3つ目については生成AIの導入で、社内文書を使う場合と使わない場合の違いを整理しています。
整備に投資すべきかの判断
データ整備は地味な作業で、成果も見えにくいため、社内の合意が取りにくい部分です。判断の目安は次のとおりです。
- その業務でしか使わないデータなら、整備は最小限に — AI導入のためだけに大規模な整備をすると、投資対効果が合いません
- 他の業務でも使うデータなら、投資する価値がある — 顧客情報、案件履歴、製品マスタなど。AI以外の場面でも効いてきます
- 整備の過程で業務が見直せるなら、それ自体が成果 — 使っていない項目、重複した記録、形式のばらつき。整理すると業務が軽くなることがあります
③ 現場が使わない問題|最も静かに失敗する
技術的には完成しているのに、利用が伸びない。誰も文句を言わないまま、静かに使われなくなります。
使われない理由は、たいてい設計の前にある
設計に使う人が入っていない
企画部門と外部の会社だけで進めた仕組みは、現場の運用と噛み合いません。実際の手順には、資料に書かれていない例外や慣習が多く含まれています。
目的の説明を省いた
「業務を効率化する」と伝えると、現場は「自分の仕事が減らされる」と受け取ります。人を減らすためではなく、時間のかかっている作業を減らすためだと明示しないと、ヒアリングの段階から正確な情報が集まりません。
完成してから通知した
開発中の状況を共有せず、完成後に「これを使ってください」と渡す。この進め方が最も抵抗を生みます。便利かどうか以前に、勝手に決められたという感情が先に立ちます。
例外対応の手順がないと、元に戻る
見落とされやすいのがこれです。AIが処理できないパターンに出会ったとき、どうすればいいかが決まっていないと、人は慣れた方法に戻ります。
例外時の手順を用意し、その発生件数を記録してください。件数が多ければ、それは改善すべき対象が見えたということです。記録がなければ、なぜ使われないのかも分かりません。
立て直す手順
- 使っている人に話を聞く — 利用率が低くても、必ず使っている人がいます。その人が何に使っているかが、横展開のヒントになります
- 使っていない人にも聞く — 責める形にしないこと。「使いにくい点はどこか」ではなく「どういう場面で思い出さなかったか」と聞くと、本音が出ます
- 対象業務を絞り直す — 全社展開をいったん止め、1業務・1部署に戻す。範囲を狭めるほど改善が速くなります
- 使い方を共有する — うまくいった指示の出し方をテンプレートにして配る。個人技のままだと、使える人と使えない人の差が開きます
どの業務なら定着しやすいかは、AIによる業務効率化で工程の性質から整理しています。
④ 経営と現場の温度差|どちらが正しいわけでもない
経営層は「早くAIを導入しろ」と言い、現場は「今の仕事で手一杯」と答える。この構図はほぼどの企業でも起きます。
すれ違いの正体
経営層が見ているのは、競合の動向や人手不足といった数年単位の話です。現場が見ているのは、今月の締切や目の前の顧客対応という今日明日の話です。どちらも間違っていません。時間軸が違うだけです。
問題は、この差が「AIを導入すること」という曖昧な目標のまま放置されることです。総務省『令和7年版情報通信白書』によると、生成AI導入に際しての懸念事項として日本企業が最も多く挙げたのは「効果的な活用方法がわからない」でした。経営層も現場も、実は同じところで止まっています。
埋める方法は、対象業務を1つ決めること
抽象的な「AI導入」を、具体的な「この業務のこの工程」に翻訳すると、両者の会話が成立します。
- 経営層にとっては、投資対効果が計算できる対象になる
- 現場にとっては、自分の作業がどう変わるかが見える
選ぶ業務は、現場が「これが一番つらい」と言っているものを優先してください。効果の大きさで選ぶより定着します。経営層から見て非効率でも、現場が困っていない業務は、仕組みを作っても使われません。
「AIでなくてもいい」という結論を許容する
検討の結果、手順を見直すだけで解決する、既存システムの設定変更で足りる、その業務自体をやめられる、という結論に至ることがあります。
これは失敗ではなく、正しい成果です。ただし「AI導入」が目標として掲げられていると、この判断ができなくなります。目標を「AIの導入」ではなく「この業務課題の解決」に置き換えておくことが、実は最大の予防策です。
推進役を1人置く
温度差が埋まらない企業に共通するのは、両者をつなぐ人がいないことです。専任である必要はありませんが、業務を理解していて、経営に報告でき、月に一定の時間を確保できる人が要ります。
この役割が空席のまま外部に依頼すると、支援会社は誰と話せばいいか分からないまま進めることになります。AI導入支援の記事で、社内に必要な体制について整理しています。
⑤⑥⑦は、稼働してから効いてくる
残る3パターンは、導入直後には表面化しません。半年ほど経ってから、静かに進行します。
⑤ 効果が説明できない
前述のとおり、効果測定を行っていない企業が59.8%にのぼります。測っていないと、翌年度の予算を通す根拠が作れず、「なんとなく続けている」状態になります。そして予算削減の対象になったとき、守る材料がありません。
対処は1つだけで、導入前に対象業務の数字を記録しておくことです。月間件数、1件あたりの時間、担当者数。これは導入後には取れません。すでに稼働している場合は、今からでも現在値を記録し、以降の変化を追ってください。
⑥ 参照する情報が古くなる
社内文書を読ませる仕組みで必ず起きます。就業規則が改定された、商品情報が変わった、業務手順が更新された。このときAI側に反映されていないと、回答が古くなります。
利用者から見ると「AIの精度が落ちた」ように見えるため、一度この評価がつくと信頼は戻りません。更新の担当と頻度を、導入時に決めてください。後から決めようとすると、誰も引き受けません。
⑦ 担い手がいなくなる
推進していた担当者の異動を機に止まる例は多くあります。なぜこの設定なのか、なぜこの業務は対象外なのかが分からなくなると、誰も触れなくなります。
この3つは、いずれも導入時の10分の作業で防げるものです。数字を記録する、更新担当を決める、判断の経緯を書き残す。稼働してから対処しようとすると、何倍もの手間がかかります。
失敗から立て直した事例|当社自身の話も含めて
ここでは当社自身の経験を書きます。支援する側も失敗しています。
AIエージェントに実装を任せたら、意図と違うものが出てきた
当社では自社の開発業務にAIを取り入れており、蓄積したドキュメントをAIに読み込ませて、要件定義書や仕様書、工数見積を生成させる取り組みを進めています。
その過程で、AIエージェントに実装そのものを任せたことがありました。結果は、意図と異なる実装です。ドキュメントは渡していたにもかかわらず、想定していなかった箇所まで編集されていました。
原因は情報量ではなく粒度でした。「何を実装してほしいか」は伝わっていても、「どこまでを対象とし、どこには触れないか」が伝わっていなかった。人に依頼するときは暗黙に共有されている範囲の感覚が、AIには通じません。
ここから得た教訓はひとつです。指示の粒度は、人に頼むとき以上に明示が必要になります。ドキュメントを整備すれば伝わる、というものではありませんでした。
上流工程では、思ったほど速くならなかった
もうひとつ、期待と違った点があります。要件定義やデザインといった上流工程では、AIによる時間短縮の効果が相対的に小さい傾向がありました。
理由は、確認のやり取りの回数が増えるためです。生成そのものは速くても、それが意図に合っているかを確かめる往復が発生します。判断が固まっていない段階では、この往復が短縮分を相殺します。
現時点の実感としては、AIが効くのは判断が固まったあとの展開作業です。何を作るかを決める工程ではなく、決まったものを形にする工程に効きます。
その前に、ドキュメント運用そのものの失敗があった
時系列としては、これがもっと前の話です。ある会員制アプリの開発案件で、複数のエンジニアが入れ替わりながら1年以上進める体制を取っていました。
途中で「仕様書を正として作業し、議論した内容を都度そこへ反映できていれば、後戻りを減らせたはずだ」という反省がありました。会話で決まったまま、どこにも書かれていない仕様が積み重なっていたためです。
そこから運用を変え、打ち合わせで決めたことは必ずドキュメントへ反映するようにしました。結果として、新しく参加したメンバーが人に聞かずに経緯まで追える状態になり、担当が入れ替わっても大きな停滞なく継続できるようになりました。
正直に書いておくと、この取り組みの前後で工数を計測しておらず、削減率として示せる数字がありません。現場の手応えとしての話です。数字で語れないことは反省点で、現在は計測を始めています。
3つの経験に共通するのは、失敗の原因が技術ではなく、伝え方と記録の運用にあったことです。これは冒頭の7パターンの右端の列と同じ構造です。支援会社を選ぶとき、この種の「効かなかった話」を具体的に語れるかどうかは、ひとつの判断材料になります。成功事例しか出てこない場合、実際に手を動かした量が少ない可能性があります。
他社の公表事例についてはAI導入事例で業種別に整理しています。
立て直しチェックリスト|止まっている案件に当てる
いま止まっている案件に、上から順に当ててください。最初に「いいえ」が出たところが、詰まっている場所です。
目的と対象
- 解決したい業務課題を、1つの文で言えるか
- 対象業務の月間件数と、1件あたりの時間を答えられるか
- その業務は、処理量が多く・判断基準が言語化でき・間違えても取り返しがつくか
検証と判断
- PoCの合格ラインが、数値で決まっているか
- 進む・止めるを決める人が、1人に決まっているか
- 「止める」という選択肢が、実際に取れる状態か
データ
- 使うデータがどこに、どれだけ、どんな形式であるかを把握しているか
- データの整備が必要な場合、その工数が計画に入っているか
現場
- 設計に、実際に使う人が1人以上入っているか
- 導入の目的を、現場に説明したか(人を減らすためではないと明示したか)
- AIが対応できない例外が出たときの手順が決まっているか
運用
- 導入前の数字を記録してあるか
- 参照する文書を更新する担当と頻度が決まっているか
- 判断の経緯が、個人の記憶ではなく文書に残っているか
「いいえ」が3つ以上なら、いったん戻る
該当が多い場合、前に進むより対象業務を絞り直すところまで戻ったほうが速いことがほとんどです。範囲を狭めると、判断すべきことが減り、詰まっていた箇所が自然に解けます。
逆に「いいえ」が1〜2個なら、その項目だけを埋めれば再開できます。全体をやり直す必要はありません。
止まってからの相談は、珍しくありません
着手前の相談と同じくらい、PoCで止まった案件や、導入したが使われていない案件のご相談をいただきます。検証結果を捨てずに整理し直すところから再開できることが多く、ゼロからやり直しになる例はまれです。
自社がどのパターンに当てはまるか、どこから立て直すべきかを一緒に整理します。相談の結果、AIではなく既存の仕組みの見直しで解決するという結論になることもあります。
ドコドア やまだ
このブログでは、日々の制作現場で得た気づきやノウハウをを発信しています。
【主な技術スタック】 PHP / HTML / CSS / SCSS / JavaScript / WordPress / Shopify
また、SNSでもWeb制作に関する情報を発信中です。
Instagram : https://www.instagram.com/docodoor_yamada/