AI PoCはなぜ大半が死ぬのか — 中小企業の失敗パターン分類と前提設計の処方箋
概念実証で止まる経験を繰り返す中小企業のAI推進担当へ、過去のPoC失敗を6類型で分類し、症状ではなく構造原因に処方する前提設計を提示。スコープ・撤退基準・本格運用への移行設計まで、稟議に通る粒度で体系化。
このホワイトペーパーで分かること
- 中小企業のAI PoCが本格運用に進まない構造的な原因と、その分類の枠組み
- PoC失敗の6類型と、症状ではなく構造原因に処方する読み解き方
- スコープ3軸（業務×組織×データ）で組み直す「前提設計」の具体
- 撤退基準を事前に書面合意するための5項目テンプレート
- PoCを続けるか、Pilotから入るか、本番直行にするかを選ぶ3択フレーム
- 役員会で承認が出る稟議用1ページサマリーの構成と書き方
対象読者
- 製造業（従業員200名規模）／SaaS／卸・小売／専門商社／士業／人材／不動産／BtoB専門サービス等の中小企業で、PoCを1〜2件経験して本格運用に進めず止まったAI推進・DX担当
- 従業員50〜300名規模で、情シス専任が0〜2名、または兼任のみの組織体制でAI導入を任されている事業責任者
- 経営企画・情報システム責任者・AX担当のいずれかを兼任し、役員会で「結局、PoCで何が分かったのか」に答えに詰まった経験のあるマネージャー〜部長
- ベンダー提案でPoCを提案されるたびに「また同じ結末ではないか」と疑念を持ちつつ、別の進め方が見えていない意思決定者
- 撤退の判断基準が事前に合意されておらず、サンクコストに引きずられて惰性で延命しているPoCを抱えている経営者
このWPの結論（Executive Summary）
課題と緊急性
中小企業のAI関連プロジェクトでは、概念実証（PoC）後に本格運用に進めない事例が後を絶たない。経済産業省「DXレポート2.2」および国内ベンダー各社の調査でも、PoC後に本番運用へ進めない比率の高さが繰り返し指摘されてきた。
2026年現在、主要SaaSがAI機能を標準搭載し、技術検証としてのPoCの意義そのものが薄れている。それでも従来型のPoC設計に走り、本格運用に届かないまま投資ロスを積み上げる中小企業は多い。
アプローチ
本WPは、PoC失敗を6類型に分解する。目的曖昧型／KPI不在型／データ不足型／現場巻き込み不足型／ベンダー丸投げ型／過剰期待型、の6つである。
症状の羅列で終わらせず、構造原因の層まで掘り下げる。その上で、PoC開始前に決めておく「前提設計」を提示する。スコープ3軸、撤退基準の事前合意、PoCから本格運用への移行設計までを、稟議に通る粒度で体系化する。
主要発見
- PoCが死ぬ一次原因は技術ではなく、成功条件と撤退条件が事前に合意されていないこと
- 6類型の失敗パターンは独立していない。1社で複数を同時に起こしているケースが大半
- 「PoC不要論」は半分正しい。技術検証としてのPoCは不要だが、業務適合検証と組織受け入れ検証は別形態で必要
- PoCから本格運用への移行で詰まる一次関門は予算追加申請ではなく、運用オーナーの指名
- 役員会で通る稟議はROI試算より、撤退ライン明示と同規模事例と中間チェックの3点セット
目次
- PoCが死ぬとは何が起きているのか — 失敗の3つのコスト
- PoC失敗の6類型 — 症状ではなく構造原因で分類する
- 6類型の構造原因 — なぜその死因が中小企業で再生産されるか
- 「前提設計」を変える処方箋 — スコープ3軸の設計
- 撤退基準の事前合意 — PoCを始める前に書く5項目
- PoCから本格運用への移行設計 — 運用オーナー指名と移行期の観察
- 「PoC不要論」との対話 — やるべきか・飛ばすべきか・別形態か
- 同規模の中小企業事例 — 失敗から再起動した3社の構造
- 稟議用1ページサマリー — 投資根拠と撤退ラインの4点セット
- 次のアクション — 30分で書ける「前提設計シート」
1. PoCが死ぬとは何が起きているのか — 失敗の3つのコスト
PoCの失敗は、単なる投資ロスではない。経営に効くコストは3層に分かれており、直接コスト・時間コスト・組織コストが同時に蓄積する。3層を分けて捉えないと、次の意思決定でも同じ判断ミスを繰り返す。
直接コストはPoCの予算と人件費だが、これは目に見える分まだ扱いやすい。問題は時間コストである。経営判断が3〜6ヶ月単位で遅延し、その間に競合がAI前提の業務再設計に進んでいると、復元できない差が生まれる。
組織コストは最も見えにくく、最も重い。PoC失敗の蓄積は「AIでやっても無理」という諦観を社内に残し、次の意思決定を停滞させる。一度失敗を経験した組織は次に慎重になり、結果的に意思決定が遅れる。
ベンダー費用と社内工数の合計。中小企業でも経営の打ち手の選択肢を狭めるだけの規模になることが多く、複数回累積すると次の予算稟議が通りにくくなる。
PoC設計から報告会までの3〜6ヶ月の間、本格的なAI業務適用の意思決定が止まる。その間に競合がAI前提で業務を再設計していると、差が広がる。
失敗の蓄積が次の意思決定を萎縮させる。AI推進担当の発言力が落ち、役員会で次の予算が通りにくくなる。最も復元しづらいコスト。
FULLFACTの相談事例でも、PoCを過去2年で3件実施した従業員200名規模の製造業の事業責任者が「今後はAI関連の予算稟議が通りづらくなった」と語った例がある。直接コストの絶対額もさることながら、回復不能なのは社内の諦観のほうである。
経済産業省「DXレポート2.2」では、DX関連プロジェクトの中で本番稼働に至る比率が低水準で推移している実態が指摘されてきた。中小企業ではこの傾向がより強く、PoC1回の失敗が次の挑戦の停止につながりやすい。
3コストを並列で見ると、PoC失敗は単独の事象ではなく、組織の意思決定速度を落とす連鎖の起点であることが分かる。次章では、その死因を6類型に分解する。
2. PoC失敗の6類型 — 症状ではなく構造原因で分類する
PoC失敗は、現場の言葉で語られる限り「うちは特殊だった」という個別事情に見える。だが俯瞰すると、症状は6類型に集約できる。重要なのは症状の名前ではなく、構造原因に処方する読み解き方を持つことである。
6類型は、目的曖昧型／KPI不在型／データ不足型／現場巻き込み不足型／ベンダー丸投げ型／過剰期待型に分かれる。各類型は独立して起きるのではなく、1社で複数が同時発症するのが通常である。
「とりあえずAIで何かやろう」で始まり、ベンダーが提案した検証を流す。目的も社内オーナーも曖昧なまま、報告会で「精度は出た」で終わる。
社内主導だが目的が手段（生成AIを使う）に置かれている。現場の業務工程に接続されず、検証は動くが運用に渡らない。
業務改善という大義はあるが、KPIが事前に決まっていない。手元データの整備度を確認せずに始め、検証中にデータ不足が発覚して停止する。
「大幅な業務削減」を期待値として持ち、KPIは事後に取り繕う。現実の改善率が期待を下回り、本格運用判断が下りない。
4象限に乗らない2類型として、データ不足型（手元データが検証の前提に届かない）と過剰期待型（経営層の期待値が現場の改善幅と乖離する）がある。両者は単独でも発症するが、上記4象限のいずれかと連動して悪化することが多い。
症状名で分類している限り、PoC失敗は何度でも再生産される。次章では、6類型を構造原因のレベルに集約し直す。
3. 6類型の構造原因 — なぜその死因が中小企業で再生産されるか
6類型は表層では別物に見えるが、構造原因のレベルでは4つの根本要因に収斂する。意思決定者の責務不在／KPIと業務指標の断絶／データ整備の前工程飛ばし／現場業務との接続不在、の4つである。
1社で複数類型を同時発症するのは、この根本要因の共通性が理由である。表層症状は別物でも、根本要因が同じなら、処方も共通化できる。
意思決定者の責務不在は、PoC開始時に「成功条件と撤退条件を文書で合意する責務」を持つ人が社内に立っていない状態を指す。中小企業では役職の兼任が多く、PoCのオーナーが情シス兼任の事業責任者に丸投げされやすい。
KPIと業務指標の断絶は、PoCのKPI（精度や処理時間）と、業務側の指標（受注率や対応件数）が紐づいていない状態を指す。検証は成功しても、業務側の数字が動かないため、本格運用の意思決定が下りない。
PoCの成功条件と撤退条件を文書で合意する責務を持つ人が社内に立たない。情シス兼任の事業責任者に丸投げされ、判断が宙に浮く。目的曖昧型・ベンダー丸投げ型の構造原因。
PoCのKPIが精度や処理時間に閉じ、業務側の指標（受注率・対応件数・処理工数）と紐づいていない。検証は成功しても本格運用判断が下りない。KPI不在型・過剰期待型の構造原因。
手元データの整備度を確認せずにPoCを始め、検証中にデータ不足が発覚する。データクレンジングや業務SOPの整備が前工程として必要だったと、後から分かる。データ不足型の構造原因。
PoC環境が本番の業務動線から切り離されている。現場担当者は検証に呼ばれず、報告会で初めて知る。本格運用に渡す段階で、業務SOPの書き直しが必要になり止まる。現場巻き込み不足型の構造原因。
データ整備の前工程飛ばしは、データ不足型の直接原因である。多くの中小企業では、顧客マスタや業務ログがExcel単位で散在している。
PoC用に統合データセットを切り出す工程が予測以上に重い。検証中にこれが露呈し、PoCが事実上のデータ整備プロジェクトに変質して時間切れになる。
現場業務との接続不在は、現場巻き込み不足型の構造原因である。PoCの検証環境は本番のデータ流から切り離されており、現場担当者は検証に呼ばれない。
報告会で初めて知った現場は、本格運用に渡す段階で業務SOPの書き直しを要求する。ここで停止する。
FULLFACTの相談事例で、卸事業者のAI推進担当が「うちのPoCはデータ不足型と現場巻き込み不足型の同時発症だった」と類型診断を受けた例がある。診断を受けて初めて、過去の失敗を社内で言語化できた。症状を見ている限り、再発する。根本要因に処方する必要がある。
4. 「前提設計」を変える処方箋 — スコープ3軸の設計
PoC失敗の大半は、開始前のスコープ設定で防げる。スコープは業務軸・組織軸・データ軸の3軸で設計する必要があり、1軸でも欠けると死因に直結する。逆に3軸が揃っていれば、6類型のほとんどは未然に防げる。
業務軸は、どの業務のどの工程かを業務工程の粒度まで落とす作業である。「営業の効率化」では粗すぎる。「議事録要約から提案書ドラフト生成まで」のように、業務工程の入口と出口を特定する。
業務軸が粗いままデータも散在。多くのPoCがここで開始し、データ整備に時間を取られて検証本体に進めない。
業務工程まで落ちており、データも統合済み。議事録要約・請求書OCR仕訳・問い合わせ自動分類などの定型業務が該当。Pilot運用への移行候補。
業務軸も粗くデータも散在。PoCを設計しても死ぬ。データ整備の前工程プロジェクトを先行させる判断が必要。
データは整っているが業務軸が粗い。「業務改善」レベルの目標で始めると、検証結果を業務指標に接続できず止まる。業務軸の粒度を上げてから着手。
組織軸は、業務オーナーと運用引継ぎ先を事前に指名する作業である。検証段階のオーナーと本格運用のオーナーを別人で設計する場合は、移行時の引継ぎ条件まで合意する。中小企業では同一人物が兼任することが多いが、それでも文書で明示する。
データ軸は、既存データで検証が成立するか、整備が必要かを事前に判定する作業である。データ整備が必要な場合は、整備工程をPoCに含めるか、別プロジェクトとして先行させるかを意思決定する。
業務軸の固有名詞例として、議事録要約・請求書OCR仕訳・在庫補充の発注判断・問い合わせ自動分類・採用書類選考の一次振り分けなどが、業務工程の粒度として典型的である。「営業を効率化する」ではなく、これらの工程レベルにスコープを落とす。
PoC開始前に3軸それぞれに対して「この問いに答えられるか」を確認する3つの質問を、社内で書面化する。業務軸では「入口と出口の業務工程は何か」、組織軸では「検証と運用のオーナーは誰か」、データ軸では「検証に必要なデータは手元にあるか」を問う。
5. 撤退基準の事前合意 — PoCを始める前に書く5項目
撤退基準をPoC開始前に書面で合意することは、サンクコストに引きずられない最大のレバーになる。途中で撤退判断を下せる組織は少数で、ほとんどの中小企業ではPoCが惰性で延命する。延命の原因は、撤退基準が事前にないことに尽きる。
撤退基準は5項目で構成される。KPI未達閾値・期間上限・データ整備条件・主要担当者変更時の見直し・本格運用への移行Go/No-Go基準、の5つである。各項目は数値か条件文で書き、解釈の余地を残さない。
業務側の指標で何％未達なら撤退かを数値で書く。「精度70%未達」ではなく「対応工数の削減率が20%未達なら撤退」のように、業務指標で書く。
検証の期間上限を月数で書く。延長条件を別途定義する場合は、延長判断の責任者と上限回数も同時に書く。「最大3ヶ月、1回まで1ヶ月延長可」のような明文化。
データ整備が事前見積もりを超えて必要だった場合の判断ルールを書く。「データ整備工数が当初見積もりの2倍を超えたら、検証本体から切り離して別プロジェクト化」のように、分岐条件を事前合意。
業務オーナーや運用引継ぎ先の主要担当者が異動・退職した場合の見直しトリガーを書く。「主要担当者の変更が発生したら、30日以内に継続可否を再判断」のような条件文。
検証終了時に本格運用に進むかの判断基準を書く。KPI達成だけでなく、運用オーナー指名・SOP整備状況・データ流接続の3点が揃っているかを確認する。
実際に役員会で承認された撤退基準の文例として、ある専門商社のAI推進担当が書いた条文がある。「対応工数の削減率が25%未達、または検証期間が4ヶ月を超えた時点で、業務オーナーと事業責任者が継続可否を再判断する」という文面である。
検証2ヶ月目に削減率の進捗が芳しくないと判明した時点で、撤退判断が動いた。事前に書いた条件文が、惰性延命を止めるトリガーになった例である。
撤退基準を書面化する作業自体が、PoCの前提条件を浮き彫りにする効果を持つ。「対応工数の削減率」を撤退基準に書こうとした瞬間に、現状の対応工数が測定されていないことに気づく。データ整備を前工程に組み込む判断につながる例は多い。
撤退基準は経営層が承認する。AI推進担当だけで合意しても、役員会で「もう少しやってみよう」と覆される。事前承認を取りつけることが、惰性延命を防ぐ最後の防波堤になる。
6. PoCから本格運用への移行設計 — 運用オーナー指名と移行期の観察
PoCから本格運用への移行で詰まる一次関門は、予算追加申請ではない。運用オーナーの指名である。技術的にうまく動いた検証でも、本格運用の責任主体が決まっていなければ拡張できない。多くの中小企業がここで止まる。
移行設計は3フェーズで進める。検証末期・移行期・本格運用初月、の3段階で観察ポイントと意思決定タスクが変わる。移行期間の典型値は3〜6ヶ月の幅で見るのが現実的だが、業務特性によって変動する。
検証終了の1〜2ヶ月前から、本格運用に進むかの観察を始める。KPI達成・運用オーナー候補の特定・現場SOPの初期版作成・データ流接続の確認、の4点を意思決定材料として揃える。
本格運用の責任主体を1名指名し、業務SOPを書き下ろす。検証環境のデータ流を本番に接続し直し、運用負荷を見積もる。この段階で運用オーナーの稼働時間を業務として確保する社内合意が必要。
本格運用の初月は、運用負荷の実測と業務指標のモニタリングに集中する。検証時の数字と本格運用の数字に乖離が出るのが通常で、ここでチューニングする。月次の改善ループを開始。
運用オーナーの指名で頻発する失敗が、AI推進担当本人を運用オーナーに据えてしまうケースである。AI推進担当は次のPoCや別領域の検証に進むべき役割で、運用オーナーは業務側に置く必要がある。同一人物の兼任は短期的には回るが、次のAI業務展開を止める。
ROI試算は金額の絶対値ではなく、時間削減レンジと業務頻度で表現する。たとえば「議事録要約で1件あたり20〜30分の削減、月50件なら月17〜25時間の削減」のような書き方である。
業務指標から金額に換算する作業は別途行う。本WPでは金額換算の手順自体は扱わない。稟議で重要なのは絶対値より、業務指標で測れる削減レンジを揃えておくことである。
移行期に最も重要な観察ポイントは、現場担当者の業務負荷である。検証時は推進担当が手を動かしていた工程を、本格運用では現場が担う。現場側の負荷見積もりを甘く見積もると、本格運用が始まって1ヶ月で運用停止に追い込まれる。
7. 「PoC不要論」との対話 — やるべきか・飛ばすべきか・別形態か
「PoC不要論」は、半分正しい。技術検証としてのPoCは、2026年時点で多くの業務領域で不要になった。主要SaaSがAI機能を標準搭載し、技術側の不確実性はSaaSベンダーが検証済みだからである。一方で、業務適合検証と組織受け入れ検証は別形態で必要になる。
読者が選ぶべきは、3つの進め方のうちどれかを判断する作業である。PoC型・Pilot型・本番直行型の3択で、業務領域の不確実性がどこに残っているかで選び分ける。
新規技術が業務で動くかの検証から始める。中小企業の現場では2026年時点では希少なケース。主要SaaSの標準機能で対応できない、独自データに依存する業務などが該当。検証期間は3〜6ヶ月で組み、撤退基準を最も厳密に書く必要がある。
技術検証は不要だが、業務工程との接続と現場受け入れを検証する。本番のデータ流で小規模に動かし、SOPと運用負荷を実測する。多くの中小企業の現実解。検証ではなく「小規模本番」に近い性格を持つ。
業務適合まで既知で、SOPと組織受け入れ設計だけ詰める。同業他社で運用実績がある業務工程（請求書OCR・議事録要約・問い合わせ自動分類など）が該当。SOP整備と運用オーナー指名にリソースを集中させる。
3択の判断軸は、技術／業務／組織のうちどこに不確実性が残るかで決める。3軸すべてに不確実性があればPoC型、業務と組織の2軸ならPilot型、組織だけなら本番直行型を選ぶ。
判断のための3条件として、次を社内で確認する。技術的に同業他社での運用実績があるか／業務工程の入口と出口が定義できているか／運用オーナーを社内で指名できるか、の3つである。3つすべてYesなら本番直行型、2つYesならPilot型、それ以下ならPoC型を検討する。
実装手順は本WPの範囲外で、Pilot型で進む場合の具体ロードマップは別WP「PoCはやめろ：IT人材ゼロの中小企業が既存SaaSと生成AIで即日AXを回す実装ロードマップ」を参照されたい。本WPは3択の判断フレームを提示する戦略レイヤーに留まる。
3択を選んだら、選んだ進め方ごとに本WPの章4〜6で示した前提設計・撤退基準・移行設計を適用する。PoC型を選ぶ場合は本WPの設計が直接適用でき、Pilot型・本番直行型では撤退基準と運用オーナー指名が重点になる。
8. 同規模の中小企業事例 — 失敗から再起動した3社の構造
PoC失敗から再起動した中小企業の事例を3社、FULLFACTの相談事例から匿名で紹介する。3社はいずれも、失敗パターンの言語化・前提設計のやり直し・撤退基準の事前合意、の同じ順序を辿った。業種は異なるが、再起動の構造は共通している。
1社目は従業員200名規模の製造業のAI推進担当者の事例である。最初のPoCは目的曖昧型とベンダー丸投げ型の同時発症で、ベンダー提案の生成AIチャットボットを情シス兼任の事業責任者が受けた。
業務オーナーが立たないまま検証が宙に浮いた状態だったが、再起動時には対象業務を「問い合わせ一次対応の自動分類」に絞った。業務オーナーをカスタマーサポートの責任者に指名し直し、撤退基準は対応工数の削減率で書面化された。
2社目は専門商社のAI推進担当者の事例である。最初のPoCはKPI不在型とデータ不足型の同時発症で、「営業効率化」という粗い目的設定のまま開始した。検証中に顧客マスタの整備不足が発覚した。
再起動時には、業務軸を「議事録要約から提案書ドラフト生成まで」に落とし、データ整備を前工程プロジェクトとして先行させた。検証本体は2ヶ月で完了した。
3社目はBtoB SaaSのAI推進担当者の事例である。最初のPoCは現場巻き込み不足型と過剰期待型の同時発症で、経営層の期待値が高く、PoCの精度報告だけが先行し、現場の運用準備が遅れた。
再起動時には、現場担当者をPoC開始から検証メンバーに組み込み、期待値を「現場の対応時間が25%圧縮できるか」の数値に再設定した。期待値の言語化と現場巻き込みが、再起動の鍵になった。
3社に共通するのは、再起動時に「失敗類型の言語化」を最初に行ったことである。症状で語ると「うちのPoCは特殊だった」で終わるが、6類型のラベルを当てると「同じ構造原因を持つ他社が複数ある」と分かり、社内の心理的ハードルが下がる。
3社のいずれも、再起動の前提設計を書面化する段階で、過去のPoCが「業務オーナー指名なし／撤退基準なし／データ整備の前工程飛ばし」のいずれかに該当していたことを社内で確認した。再起動時の前提設計シートには、過去PoCの失敗類型診断結果を冒頭に明記する欄を設けている。
事例3社のいずれも、再起動後のPoCまたはPilotは本格運用に到達した。前提設計を変えただけで、技術選定や予算規模は最初のPoCと大きく変わっていない。失敗の原因は技術ではなく前提設計にあった、というのが3社の共通結論である。
9. 稟議用1ページサマリー — 投資根拠と撤退ラインの4点セット
役員会で承認が出る稟議は、ROI試算より「課題整理＋打ち手＋撤退ライン＋同規模事例」の4点セットで構成される。本章は、そのまま印刷して稟議添付資料として使える1ページサマリーの構成を示す。
稟議サマリーは6セクションで構成する。①現状の課題（過去PoC失敗類型整理）／②打ち手（前提設計の5項目）／③見込み改善レンジ（時間削減と業務頻度）／④同規模事例（章8の3社）／⑤撤退ライン（章5の5項目）／⑥次のアクション、の6つである。
| セクション | 記載内容 | 文字数の目安 |
|---|---|---|
| ①現状の課題 | 過去PoCの失敗類型を1〜2類型で明示。「目的曖昧型とベンダー丸投げ型の同時発症だった」のように、症状ではなく類型で書く | 100〜150字 |
| ②打ち手 | スコープ3軸（業務軸・組織軸・データ軸）の設計内容を箇条で。業務工程の粒度、業務オーナー名、データ整備の前工程要否を明記 | 150〜200字 |
| ③見込み改善レンジ | 業務工数の削減レンジを時間と業務頻度で。金額換算は別資料に分離 | 80〜120字 |
| ④同規模事例 | 同業または同規模の中小企業事例を1〜2件。出典またはFULLFACT相談事例の匿名化 | 100〜150字 |
| ⑤撤退ライン | KPI未達閾値・期間上限・データ整備条件・主要担当者変更時・本格運用Go/No-Goの5項目を数値か条件文で | 150〜200字 |
| ⑥次のアクション | 業務オーナー指名、前提設計シートの作成、撤退基準の役員会承認の3点を具体的な期限つきで | 80〜120字 |
稟議サマリーの作成手順は、章8の事例構造と章5の撤退基準を組み合わせる作業に等しい。AI推進担当が単独で書くのではなく、業務オーナー候補と一緒に書くと、業務指標の解像度が上がる。
役員会で承認が下りた後は、稟議サマリーをPoCの公式文書として保管する。検証期間中に撤退ラインの議論が再燃した際、稟議時点の文書に戻る運用が機能する。事後に「撤退ラインは目安だった」と解釈変更されることを防げる。
このサマリーは本格運用への移行時にも参照される。本格運用申請の稟議は、PoC稟議サマリーに対する達成度報告で構成される。稟議サマリーを最初に丁寧に書くことが、移行段階での意思決定速度を上げる。
10. 次のアクション — 30分で書ける「前提設計シート」
本WPの読者が今日から取れる最短の一歩は、30分で書ける「前提設計シート」の作成である。スコープ3軸＋撤退基準5項目をA4・1枚に書き出し、業務オーナー候補と読み合わせる作業が、PoC開始前の合意形成を一段進める。
前提設計シートの記入は3ステップで進む。業務オーナーの仮指名／スコープ3軸の記入／撤退基準5項目の起草、の順である。30分の時間枠で粗く書き、後日役員会で詰めるサイクルが現実的である。
PoCの検証段階と本格運用段階のオーナー候補を、それぞれ社内で1名仮指名する。同一人物の兼任でも明文化する。仮指名の段階で人選の違和感が出れば、それ自体が貴重な発見である。
業務軸（業務工程の入口と出口）・組織軸（業務オーナーと運用引継ぎ先）・データ軸（既存データで足りるか）を、各3〜5行で書く。粒度が粗いと感じる箇所は、その場で書き直す。
KPI未達閾値・期間上限・データ整備条件・主要担当者変更時・本格運用Go/No-Goの5項目を、数値または条件文で書く。書面化の段階で前提条件の欠落が露呈する。
30分の作業が終わったら、次に取れる選択肢が3つある。読者の社内の温度感と関心度合いに応じて、次の一歩を選ぶことができる。
階層1は情報を継続的に受け取る選択肢である。本WPの第10章の前提設計シートをA4・1枚のPDF版として配布している。スコープ3軸と撤退基準5項目の記入欄付きで、メールアドレス登録のみで即時受け取れる。社内文書化の初動を最短で進めたい場合の出発点になる。
階層2は、自社の過去PoCを6類型で診断する30分のミニセッション（無料・オンライン）である。業務診断パッケージ（B01・1ヶ月）の入口として位置付けている。
本WPの6類型を申込企業の過去PoCに当てはめて、構造原因を1つ言語化する形式で進める。次回PoCの前提設計を社内で言語化する材料が持ち帰れる。
階層3は、PoC死を構造的に解くAI導入戦略の伴走を相談する選択肢である。AI導入戦略／ロードマップ（D02・1〜2ヶ月）で、事業全体のAI適用順序から見直したい層向けに、6類型診断・前提設計・撤退基準・移行設計を統合的に伴走する。
業務領域に絞った診断から入りたい場合は業務診断パッケージ（B01・1ヶ月）の併用も検討余地がある。階層2のミニセッションから階層3に進む経路が、最も典型的な相談導線となる。
まとめ
本WPで提示した、PoC死から抜けるための行動指針を5つに整理する。
- PoC失敗の構造原因は4つに収斂する。意思決定者の責務不在・KPIと業務指標の断絶・データ整備の前工程飛ばし・現場業務との接続不在の4要因に処方せよ
- PoC失敗の症状を6類型で言語化することが、再起動の最初の一歩になる。「うちは特殊だった」と語る限り再発する
- スコープは3軸で設計する。業務軸（業務工程の粒度）・組織軸（業務オーナー指名）・データ軸（既存データの整備度）の1軸でも欠けると死因に直結する
- 撤退基準は5項目をPoC開始前に書面合意する。KPI未達閾値・期間上限・データ整備条件・主要担当者変更時・本格運用Go/No-Goの5つを、数値か条件文で書く
- PoCから本格運用への移行で詰まる一次関門は、予算追加申請ではなく運用オーナーの指名である。AI推進担当を運用オーナーに兼任させない
PoC死は、技術の問題ではなく前提設計の問題である。2026年現在、技術検証としてのPoCの意義は薄れたが、業務適合検証と組織受け入れ検証は別形態で必要になる。本WPの読者が、次のPoC開始前に前提設計を書面化し、撤退基準を役員会で承認させる最初の意思決定者になることを期待したい。
次のステップ：AI導入戦略／ロードマップ（D02・1〜2ヶ月）で、6類型診断・前提設計・撤退基準・移行設計を統合的に伴走する。業務領域に絞った診断から入りたい場合は業務診断パッケージ（B01・1ヶ月）の併用も検討余地がある。前提設計シート（A4・1枚）をまず受け取って社内で読み合わせる選択肢から始めることもできる。