典型的な失敗5パターン ― 原因は「発注の作法」にある
従来のシステム開発と同じ感覚でAI開発を外注すると、高い確率で次のいずれかに行き着きます。5つとも見え方は違いますが、根の原因は共通していて、いずれもベンダーの腕だけでは防げないものです。
- 動くが、使えない。デモは動くのに、実データ・実業務では精度が出ず使われない。発注側の業務知識やデータがベンダーに渡っていないことが多い。
- PoC止まり。検証は「成功」と報告されたが、本番化の予算も体制も計画されておらず、そこで終わる。PoCの「出口」を最初に決めていない。
- 保守できないブラックボックス。設計意図・プロンプト・評価方法のドキュメントがなく、誰も直せない。小さな変更のたびにベンダーへ依頼し、見積りは言い値になる。
- ベンダーロックイン。データ・プロンプト・評価資産がベンダー環境に囲い込まれ、乗り換えも内製化もできない。
- 運用費の想定漏れ。構築費だけで予算化してしまい、API利用料・監視・改善・モデル更新への追従という「運用が本体」のコストが宙に浮く。
5つの失敗は別々の事故に見えて、発注の作法という一点に原因が集約されます。課題とデータの実態を書かない、評価基準を合意しない、運用の絵を描かない ― この不備がベンダーの技術力とは無関係に失敗を生みます。
2つの失敗ケース ― いずれも分岐点は発注側にあった
構造を具体的に描くために、業界でよく見られる展開を再構成した架空のモデルケースを2つ紹介します。実在の企業・案件ではなく、時系列や数値も説明のための例示です。実話の体験談としてではなく、「こういう筋書きが起こりえる」という仮定として読んでください。
ケース1: 社内FAQボットが10ヶ月でお蔵入りする筋書き
ある企業が社内FAQボットを外注する、という筋書きを考えます。RFPは「AIチャットボットの構築」の一行と規程一覧のみで、見積りに「データ整備」や「評価」の行がない最安のベンダーに決めた ― としましょう。デモでは用意された10問に見事に回答し、経営も満足して本開発へ進みます。ところが全社公開の初週から「答えが古い」「隣の部署の規程まで見えてしまう」といった声が上がる。旧版の文書が混在したまま棚卸しがされず、権限も「全文書を全員に」開放されていた、という帰結です。修正見積りはデータ整備込みで当初費用の6割増(これも例示の数値です)となり、「なぜ最初に言わないのか」「仕様に書いていない」の水掛け論の末、予算がつかず停止する ― こうした展開が起こりえます。
この筋書きの分岐点は、すべて発注側にあります。①課題とデータの実態をRFPに書かなかった、②評価基準を合意しなかった、③最安の理由を内訳で確認しなかった、④検収の基準が「デモが動く」だった。残るのは使われないシステムと、社内に刻まれる「AIは使えない」という記憶です。
ケース2: PoCは成功、それでも誰も本番化を決めない筋書き
2つ目は、ベンダーが誠実に仕事をしても投資がゼロ回収に終わる、というモデルケースです。需要予測AIのPoCを実施し、報告書には「精度目標を達成、有効性を確認」と書かれた ― という筋書きを考えます。ここで本番化の予算を誰も確保しておらず、予測を使う側の業務(発注業務の変更)も検討されておらず、運用の担い手も未定だとしたら、プロジェクトはそこで止まります。「PoCの成功」と「事業の成功」の間には溝が残ったままです。
この溝は、ベンダーではなく発注側にしか埋められません。PoCの出口 ― すなわち本番化の判断材料と判断者を、始める前に決めておく。これが欠けていると、技術的に成功しても事業としては何も残りません。
AI開発は従来の外注と何が違うか ― 5つの観点
失敗の多くは、従来型の発注作法(要件を固めて渡し、完成品を検収する)とAI開発の性質とのミスマッチから生まれます。両者の違いを5つの観点で対比すると、なぜ同じやり方が通用しないのかが見えてきます。
| 観点 | 従来のシステム開発 | AI開発 |
|---|---|---|
| 動作 | 決定的(仕様どおり動く/動かない) | 非決定的 ― 同じ入力でも揺れ、精度は確率的 |
| 完成の定義 | 仕様書との一致で判定できる | 「精度◯%」の事前保証は原理的に難しく、評価基準の合意が要る |
| 成否の鍵 | 要件定義の質 | 発注側のデータと業務知識の質 ― ベンダーの腕だけでは決まらない |
| 納品後 | 保守(バグ修正中心) | 運用が本体 ― 評価・監視・改善・モデル更新追従が続く |
| 発注側の関与 | 要件定義と検収に集中 | 全期間 ― SMEの提供・データ整備・評価への参加が必要 |
要するに、AI開発は完成品を「買う」より、共同で「育てる」に近い調達です。この認識の差が、契約・進め方・検収のすべてに波及します。買う前提で丸投げすれば、育てるべきものが育たないまま納品日を迎えることになります。
丸投げの構造的な帰結 ― なぜ誠実な提案ほど負けるのか
要件もデータも評価もベンダー任せにする「丸投げ」は、短期的には楽です。しかし構造的に、次のような結末を招きます。
- 現場に合わないものができる。ベンダーは業務を知らないまま作るため、もっともらしいが現場では使えないものが出来上がる。
- 毎回ゼロから、毎回外注。発注側に知識が残らず、次の案件も改修も毎回外注になる。外注費は下がらず、社内の目利き力も育たない。
- 検収で揉める。評価基準がないため「精度が低い」「仕様には書いていない」の水掛け論になる。
- 説明できないシステムが動き続ける。最悪の場合、何が納品されたのか自社で説明できないシステムが顧客データを扱い続ける ― ガバナンス上の重大リスクです。
さらに厄介なのは、丸投げが誠実なベンダーの提案を負けさせることです。データ整備や評価まで含めて正直に見積もった提案は、その分だけ金額が高く見えます。整備の行が入っていない最安見積りと並べれば、発注側の準備が不十分なほど、安いほうが選ばれてしまう。これは特定のベンダーの責任ではなく、発注側の作法が生む構造的な帰結です。
発注前に社内で決めるべき4つのこと
ここまでの裏返しが、そのまま対策になります。ベンダーに会う前に、次の4つを社内で決めておくこと。これが曖昧なままだと、提案の巧拙で判断することになり、失敗パターンへ一直線です。
- 目的と成功の定義。どの業務の何を良くしたいのか、その効果をどう測るのか。ここが決まっていないと、そもそも検収の基準が作れません。
- オーナーとSME。業務オーナーは誰か。窓口を「情シスだけ」にせず、正解を定義できる業務側のSME(有識者)の稼働を確保できるか。
- データの現状。AIに使わせるデータはどこに、どんな状態であるか(棚卸し)。機微度に応じて、外部に出せる/出せないの線引きをしておく。
- 運用の担い手。納品後に誰が運用するのか(社内/ベンダー保守/併用)。運用の絵がない案件は、そもそも発注しない。
この4つが埋まっていれば、良いRFPは半分書けたも同然です。逆に4つが空欄のままベンダーに会えば、宿題を提出しないまま採点を頼むようなもの。受け取るべきは、システムと、それを運用できる自社の状態の両方です。
まとめ ― ナレッジが残る外注へ
AI開発の外注が失敗するとき、原因はベンダーの技術力ではなく、発注の作法にあります。失敗5パターンも2つのケースも、分岐点はすべて発注側にありました。AI開発は「買う」より「共同で育てる」調達であり、非決定的な動作・評価基準の合意・データと業務知識・運用が本体・全期間の関与という5つの違いを踏まえる必要があります。そのうえで発注前に目的・オーナー・データ・運用の4つを決める ― ここまでが本コラム(発注ガイドシリーズ第1弾)の範囲です。
「ナレッジが残る外注」は精神論ではなく、RFP・契約・進行・検収の各段階に仕掛けとして実装できます。次回は、その第一歩となる「RFPとベンダー選定」の具体的な進め方を解説します。