PoC失敗の原因と事例から学ぶ防止策：AI導入を仕様駆動開発（SDD）と受け入れテスト駆動開発（ATDD）で設計する

AIのPoCで、デモでは見事に動いたのに、本番導入の判断になると誰も「使える」と言い切れない。この終わり方の原因は、AI特有の性質を企画段階で扱っていないことにあります。AIの出力は同じ入力でも毎回同じとは限らず、性能は与えたデータで決まり、「精度が高い」だけでは本番に出せるかを判断できません。

本記事は、AI導入のPoCを企画する担当者とプロジェクトマネージャーに向けて、よくある失敗事例のパターンを整理したうえで、仕様駆動開発（SDD）で検証範囲を先に固定し、受け入れテスト駆動開発（ATDD）で合否の基準を着手前にテストへ変える方法を解説します。最後に、着手前に確認するチェックリストと判定表を示します。

従来のシステム開発のPoCは「作れるか」を確かめれば済むことが多く、画面が動けば検証の大半は終わりました。AIのPoCで確かめるべきなのは「どの程度の割合で、どんな誤り方をするか」です。この違いを企画に反映しないまま進めると、デモの印象だけで判断することになります。

以下の3節で、この違いが企画段階のどの見落としにつながるかを見ていきます。

生成AIは、同じ質問に対しても言い回しや内容が変わる回答を返すことがあります。そのため、デモで数件がうまく動いたことは、本番で同じ割合でうまく動くことを意味しません。デモ用に選んだ質問は、たいてい答えやすい質問です。

この性質を企画段階で扱わないと、PoCの結論は「デモを見た人がどう感じたか」に左右されます。好印象のデモで本格導入が決まり、本番で答えにくい質問が来て初めて誤りの多さに気づく、という順序になります。

対策は、評価を件数と割合で行うと企画書に書くことです。どんな質問を何件用意し、同じ質問を何回試し、何割が合格なら次に進むのか。これを着手前に決めておけば、デモは評価の代わりではなく、評価結果を説明する場になります。具体的な作り方は、後述の受け入れテスト駆動開発（ATDD）の章で扱います。

AIの性能は、モデルの選び方以上に、何のデータで試したかで決まります。PoCでよく起きるのは、手元にある整ったデータで高い成績が出て、本番の雑多なデータで下がることです。

問い合わせ対応なら、PoC用に集めた過去の問い合わせは、担当者が選んだ「よくある質問」に偏りがちです。本番には、誤字の多い質問、複数の用件が混ざった質問、社外秘の情報を尋ねる質問も来ます。検索して回答する仕組み（RAG）であれば、参照する社内文書の古さや重複も回答の質を左右します。

企画段階では、検証データについて次の3点を書きます。どこから何件取るか、本番の問い合わせとどう違う可能性があるか、答えにくいケースをどの程度含めるか。答えにくいケースを意図して入れておかないと、PoCの成績は本番の成績より高く出ます。データの取り出しや個人情報の伏せ字化にかかる工数も、この時点で予算に入れます。

「正答率90%」という結果が出ても、本番に出せるかは決まりません。残りの10%がどんな誤りかによって、業務への影響がまったく違うからです。言い回しが少し不自然な回答と、存在しない返金規定を案内する回答を、同じ1件の誤りとして数えるべきではありません。

そのため企画段階で、誤りを重さで分けておきます。たとえば「人が直せば使える誤り」「顧客に出すと問題になる誤り」「一度でも起きたら中止を検討する誤り」の3段階です。最後の段階は割合ではなく件数で基準を決めます。

精度以外にも、本番の可否を左右する条件があります。1件あたりの費用が業務の単価に見合うか、応答までの時間が業務の流れに収まるか、人が確認する工程をどこに入れるか。これらもPoCで測る項目として企画書に書いておかないと、精度は合格なのに本番に出せない、という結果になります。

ここまでの3つの性質を企画で扱わないと、PoCの失敗はおおむね次の3つの形で表に出ます。いずれも特定の企業の事例ではなく、典型的な進み方を示した想定例です。

こうした失敗の損失は、PoCの費用だけにとどまりません。評価データの準備や検証に協力した現場が「またPoCか」と感じるようになり、次のAIの企画で協力を得にくくなります。結論が出ないまま終わったPoCは、失敗したPoCより後に残るものが少ない、という点も押さえておく必要があります。中止の判断でも、何が確かめられ何が確かめられなかったかが記録に残れば、次の企画の材料になります。

3つとも、原因は実装ではなく企画段階の空欄です。次章からの仕様駆動開発（SDD）と受け入れテスト駆動開発（ATDD）は、この空欄を着手前に埋めるための進め方です。

仕様駆動開発（SDD）は、実装の前に仕様を文書として書き、その仕様を開発の起点かつ正本として扱う進め方です。AIのコーディング支援が広がるにつれて改めて注目されており、GitHubが公開している「Spec Kit」や、AWSの開発環境「Kiro」のように、仕様・設計・作業分解の文書を先に作ってから実装に進む道具も出ています。

PoCでSDDが効くのは、PoCの失敗の多くが「何を確かめるのか」の揺れから始まるためです。仕様書に検証の問い・入力・期待する出力・制約・対象外を書いておけば、途中で出た要望が仕様の範囲内かどうかを文書で判断できます。

もう一つの理由は、PoCの実装そのものをAIに書かせる場面が増えていることです。AIに作らせると動くものはすぐにできますが、仕様がなければ、できたものが何を満たしているのかを誰も説明できません。仕様書を先に置けば、AIに渡す指示も、できたものの点検も、同じ文書を基準にできます。

PoCの仕様書は、本開発の仕様書ほど詳しくなくてかまいません。ただし、次の項目は着手前に必ず埋めます。

仕様書は関係者で読み合わせ、変更したときは変更日と理由を残します。PoCの途中で仕様を変えることは悪くありませんが、変えたことが記録に残っていないと、終了時に何を確かめたのかがわからなくなります。PoCの基本的な進め方はPoC開発とは？概念実証の基本から費用・進め方・失敗しない外注先選びまでで整理しています。

受け入れテスト駆動開発（ATDD）は、実装を始める前に、業務側・開発側・テスト担当が一緒に受け入れ基準を決め、それを実行できるテストとして書いておく進め方です。基準は「前提・操作・期待結果」（Given/When/Then）の形で書くことが多く、実装はそのテストに合格することを目標に進みます。

AIのPoCでは、この受け入れテストが評価データセットと合格条件の組になります。「こういう問い合わせが来たら、こういう回答を返すべき」というケースを集め、どの条件を満たせば合格かを決めておく。そうすれば、PoCの終わりに「うまくいった気がする」ではなく「何件中何件が合格した」で判断できます。

大事なのは、受け入れテストを作るのが開発側だけではないことです。何が正しい回答かを知っているのは業務側です。業務側が合格の条件を決め、開発側がそれを自動で測れる形にする。この分担を企画書に書いておきます。

評価データセットは、ケースの種類ごとに作ると抜けが減ります。問い合わせ一次回答の例で示すと、次のようになります。

ケースは業務側が実際の問い合わせから選び、正解の回答か、満たすべき条件を書きます。AIの回答は言い回しが毎回変わるため、完全一致ではなく「手順が合っている」「金額を断定していない」のような条件で判定します。答えてはいけない質問と根拠がない質問は、よくある質問より先に揃えます。PoCで見落とされやすく、本番で問題になるのはこちらです。

件数に決まった目安はありません。まず種類を網羅し、そのうえで合否の線の近くで結果が揺れたら件数を足します。分類や数値予測のように出力の形が決まっているモデルなら、正解ラベル付きのデータで正答率や誤差を測る従来の方法がそのまま受け入れテストになり、文章を返す生成AIでは上の表のような条件判定が中心になります。

評価データセットができたら、合格の線を着手前に決めます。結果を見てから線を引くと、結果に合わせた線になるためです。線は1本ではなく、次の4種類を組み合わせます。表の数値は書き方を示すための想定例で、実際の値は業務の単価や許容できる誤りから決めます。

出力が毎回変わるため、同じケースを複数回実行し、そのうち何回合格したかで判定する方法もあります。何回実行し、何回合格すればそのケースを合格とみなすかも、この時点で決めておきます。指標の設計手順はAI 導入の PoC 設計ガイドでも扱っています。

AIのPoCでは、プロンプト・参照する文書・モデルを何度も変えます。変えるたびに人が全ケースを確かめていては、評価が追いつきません。受け入れテストは、変更のたびに同じ評価データセットで自動的に再実行できる形にしておきます。

自動判定には、条件を機械的に確かめる方法と、別のAIに採点させる方法があります。「金額を断定していない」「特定の文書名を挙げている」のような条件は機械的に確かめられます。回答のわかりやすさのように機械的に判定しにくい条件は、別のAIに採点させることもできますが、採点するAI自体も誤るため、一部のケースを人が採点して結果が一致するかを確かめます。

評価結果は、変更の内容と一緒に記録します。「どの変更で合格率が何件上がり、どのケースが新たに落ちたか」が残っていれば、PoCの終わりに、何が効いたのか、本番でも同じ設定を使えるのかを説明できます。この記録は、本開発に進んだ後の回帰テストの土台にもなります。

ここまでの内容を、着手前に確認できる項目にまとめたのが次の表です。右端の「書面に残すもの」が仕様書・企画書・別紙のいずれかにあれば、その項目は確認済みとみなせます。

空欄のまま着手してよい項目はありません。埋められない項目があれば、それ自体がPoCの前に解くべき課題です。

受け入れ基準を決めても、それで判断する人が決まっていなければPoCは止まります。役割は少なくとも4つに分けます。受け入れ基準を決める業務側の担当、評価を回す開発側の担当、結果を報告する評価担当、進むか止めるかを決める判断者です。判断者と評価担当は別の人にします。結果を評価した人がそのまま判断すると、続けたいという心理が評価に入りやすいためです。

実行中は、2週間から1か月ごとなど間隔を決めて定期レビューを開き、判断者も出席します。見るのは、受け入れテストの最新の結果と前回からの差、仕様の変更履歴、対象外の作業が紛れ込んでいないか、の3点です。受け入れテストが自動で回っていれば、レビューは結果の説明ではなく次の手の判断に時間を使えます。

判断は成功か失敗かの二択ではなく、次の3段階で行います。判定の条件は受け入れ基準から作ります。

条件付き継続で変える条件を1つに限るのは、複数を同時に変えると、何が効いたのかが評価結果から読めなくなるためです。

仕様駆動開発と受け入れテスト駆動開発をPoCに取り入れるときに、企画担当者が迷いやすい3つの問いに答えます。

途中からでも、次の順で立て直せます。

1. いま作っているものが何を確かめようとしているかを、検証の問いとして1文で書き、判断者に確認する。
2. 対象外を書き出し、進行中の作業のうち対象外に当たるものを止める。
3. 業務側の担当者と、ケースの種類ごとに評価データを揃える。まずは答えてはいけない質問と根拠がない質問から。
4. 結果を見る前に、合格率と重大な誤りの基準を決めて記録する。
5. 現時点の仕組みで評価データを一通り実行し、以後の変更はすべてこの結果と比べる。

4を5より先に行うのが要点です。結果を見てから基準を決めると、結果に合わせた基準になります。

期間そのものより、期間が延びた理由が問題です。

仕様の対象外に当たる要望を受け入れて延びたのなら、終わらないPoCの入口にいます。受け入れテストの結果を見て、条件を1つ変えた再評価のために延ばしたのなら、判断に必要な延長です。延長するときは、延ばす理由、延長後の判断日、延長しても基準に届かなければ中止すること、の3点を判断者と合意して記録します。

何を再利用するかで答えが変わります。

仕様書と評価データセットは、そのまま引き継ぐ価値が最も高いものです。仕様書は本開発の仕様の出発点になり、評価データセットと受け入れ基準は、本開発での回帰テストとして使い続けられます。PoCで最も残すべき成果物はこの2つです。

プロンプトや参照文書の整え方、モデルの設定は、受け入れテストの記録と一緒に残っていれば再利用できます。どの設定でどの結果が出たかがわからないものは、本番で同じ結果が出る保証がありません。

PoCのコードは、作り直す前提で考えるのが安全です。PoCは速く確かめることを優先して作るため、認証・権限・障害時の扱い・監視といった本番に必要な作りが省かれていることが多いからです。再利用するなら、本開発の仕様書に照らして不足を洗い出してからにします。

AIのPoCが結論を出せずに終わるのは、出力が一定しない・性能がデータで決まる・精度だけでは本番の可否が決まらない、というAI特有の性質を企画段階で扱わないためです。仕様駆動開発（SDD）で確かめる範囲を文書に固定し、受け入れテスト駆動開発（ATDD）で合否の基準を評価データセットと合格の線として着手前に作る。この2つがあれば、PoCの終わりに「何件中何件が合格したか」で判断できます。

まずは手元のPoC企画書に、検証の問い、対象外、答えてはいけない質問を含む評価データ、重大な誤りの基準の4つがあるかを確認してください。どれかが空欄なら、そこが最初に埋める行です。