投稿日：2026.09.05 最終更新日：2026.09.25
PoC（概念実証）の成功率は？計算例と判断の進め方
「PoCの成功率は、何％ならよいのか？」
PoC（概念実証）は、本格的な開発や導入の前に、技術やアイデアが実現できるかを小さく試す取り組みです。成功率を出すには、何を成功と呼び、どの案件を集計するかを決める必要があります。検証で条件を満たすことと、事業化へ進むことは別です。「技術は動いたが、買い手や予算が決まらない」案件まで一つの率で評価すると、次に直すべき点が見えません。この記事では、一次情報を踏まえて評価の違いを整理し、10件の架空例で計算方法を示します。自社のPoCを、結果の報告から継続・修正・中止の判断へつなげるための実務ガイドです。
この記事のポイント
- PoC（概念実証）の成功率は、成功条件と集計対象をそろえて計算する
- 条件を満たした割合と、判断が済んだ割合、次段階へ進んだ割合を分ける
- 未判定や中止を消さず、件数と理由を残して数字を読む
- 次の検証では、測る条件・判断者・期限・受け入れ先を先に決める
目次
PoC（概念実証）の成功率は、何を成功とするかで変わる
PoCの成功率を「何％が普通か」と聞く前に、何の達成を数えるかを確認します。技術が動いた割合、本番導入できた割合、収益が出た割合では、同じ案件でも結果が変わるからです。
一つの成功率に、技術の達成と事業化を混ぜない
AWSのAmazon Redshift向けPoCガイドでは、業務上・機能上の要件から逆算し、処理時間などの具体的な目標を成功条件にする進め方を示しています。対象はデータ分析基盤の検証ですが、「何を測り、どの水準なら条件を満たすか」を先に決める考え方は、ほかのPoCを設計する際にも参考になります。出典：AWS「Conduct a proof of concept (POC) for Amazon Redshift」。
イノベーション総研では、その検証結果と、結果を受けた事業上の判断を分けて記録することを勧めています。処理速度の目標を達成しても、導入費用を負担する部門が決まらなければ、本番導入には進めません。反対に、目標を満たさなかった結果から、追加投資をやめる判断ができる場合もあります。
「条件を満たしたか」と「次に何をすると決めたか」は、別の欄で管理します。成功率を一つにまとめるより、検証と事業化のどちらで止まっているのかが分かります。
他社の数字を、そのまま自社の目標にしない
比較に使う数字は、対象領域、成功の定義、分母、追跡した期間をそろえて読む必要があります。既存システムを別環境へ移す検証と、需要があるかも分からない新サービスの検証を、同じ目標で評価するのは適切ではありません。
また、「PoC段階にいる企業の割合」は、その時点の状況を表す数字です。PoCを始めた案件のうち何件が成功したかを追った数字とは異なります。自社の目標を置くなら、まず似た目的の過去案件を同じ基準で集計し、未判定になった理由や判断までの期間を確認してください。
PoCそのものの意味や進め方から確認したい場合は、PoCとは何か、MVPとの違いと実施手順を先に読むと、本記事の計算を当てはめやすくなります。
成功条件は、技術・顧客価値・事業性・運用に分ける
成功条件は、検証したい前提に合わせて設定します。技術の性能だけを測ったPoCから、顧客が購入することや、継続的に利益を出せることまで確認済みとは言えません。
応用地質の事例では、技術と顧客への価値を分けて確かめた
IPAが2022年に公開した応用地質へのインタビューでは、地中可視化サービスの開発にあたり、技術的な検証と、顧客にどれほどの価値を提供できるかの検証を区別したと説明されています。対象顧客、市場、収益化、必要なデータの精度なども整理したという内容です。出典：IPA DX SQUARE「『100人のニーズを集めて失敗』からのスタート 応用地質の新規事業開発としてのDX」。
この事例からイノベーション総研が重視するのは、技術の検証結果を、事業全体の合格証にしないことです。技術だけを確かめるPoCにも意味はあります。ただし、その場合は顧客価値や購入条件を「今回の対象外」として残し、次の検証につなげます。
自社案件では、次のように「確かめる問い」と「必要な証拠」を対応させます。一度のPoCですべてを調べるのではなく、今回の投資判断を変え得る前提から選んでください。
| 検証の観点 | 確かめる問い | 判断に使う証拠の例 |
|---|---|---|
| 技術 | 想定する環境で、必要な品質や速度を出せるか | 実際に近いデータ・負荷で測った精度、処理時間、障害時の動作 |
| 顧客価値 | 対象者の仕事や困りごとは改善するか | 導入前後の作業時間、使い直した行動、利用をやめた理由 |
| 事業性 | 誰が費用を負担し、提供を続けられるか | 価格条件への反応、決裁の条件、提供原価と支援工数 |
| 運用・導入 | 本番環境へ導入し、現場で維持できるか | データ利用や接続の条件、運用部門の受け入れ、保守体制 |
たとえば利用者が好意的でも、費用を負担する人の承認がなければ、購入条件は未確認です。一つの観点で得た良い結果を、別の観点の未確認事項の代わりにしないことが、過大評価を防ぎます。
「好評だった」を、対象と測り方が分かる条件に変える
「使いやすければ成功」では、人によって判定が変わります。「対象業務を初めて操作する担当者が、補助なしで完了できるか」のように、誰が、どの場面で、何をできるかへ分解します。そのうえで、必要な完了率や時間、許容できない誤りを関係者で決める流れです。
測る前の状態も記録しておけば、改善幅を説明できます。試作品を使ったときだけの作業時間では、以前より速くなったのか、検証者が手伝ったために速かったのかを区別できません。対象者や手順をそろえ、補助した場合はその条件を残します。
PoC成功率の計算例：10件の結果を3つの率で読む
ここでは、イノベーション総研が勧める管理例として、「条件達成率」「判断到達率」「次段階移行率」を分けます。業界共通の公式指標ではなく、自社で何を改善するかを見分けるための整理です。
以下は計算方法を説明する架空例です。同じ月に判断期限を迎えた10件のPoCを、月末の状態で集計したとします。各案件には、開始前に合意した成功条件があります。
| 検証結果 | 件数 | 月末までの判断・対応 |
|---|---|---|
| 成功条件を満たした | 6件 | 4件は次段階を開始。1件は事業方針の変更で中止。1件は予算の判断待ち |
| 成功条件を満たさなかった | 2件 | 2件とも、結果を根拠に現方式への追加投資を中止 |
| 材料不足で判定できなかった | 2件 | 1件は追加の証拠・担当者・期限・予算を決めて再検証。1件は対応未定 |
この10件について、検証の結果、判断の進み具合、次段階への移行を別々に計算します。下の3つの率は異なる問いへの答えなので、足し合わせたり、平均して一つの成功率にしたりはしません。
1. 条件達成率は、判定できた案件のうち条件を満たした割合
条件達成率＝成功条件を満たした件数 ÷ 成否を判定できた件数 × 100
この例では、6 ÷ 8 × 100＝75％です。分母は、条件を満たした6件と満たさなかった2件。材料不足の2件はこの分母から外し、「判定可能8件／対象10件、未判定2件」と併記します。75％だけを示すと、対象全体を評価できたように見えるためです。
全10件に対して条件を満たした割合を見たいなら、6 ÷ 10 × 100＝60％です。こちらは「期限到来案件全体に対する達成割合」と明記します。どちらかだけが正解なのではなく、分母が違えば答える問いも変わります。
2. 判断到達率は、根拠をもとに次の対応が決まった割合
判断到達率＝対応を決めた件数 ÷ 判断期限を迎えた件数 × 100
この例では、次段階を開始した4件、中止した3件、条件を定めて再検証する1件の計8件が対象です。8 ÷ 10 × 100＝80％となります。予算待ちの1件と対応未定の1件は含めません。
再検証を含めるのは、追加で確かめること、担当者、期限、予算が合意されている場合です。「もう少し調べる」という先送りまで判断済みにすると、問題を隠してしまいます。また、判断が速いことだけで、その内容が妥当だったとは評価できません。
3. 次段階移行率は、決めた次の活動が実際に始まった割合
次段階移行率＝次段階を開始した件数 ÷ 判断期限を迎えた件数 × 100
この例では、4 ÷ 10 × 100＝40％です。「次段階」は、本番導入、有償での試行、事業計画に基づく開発など、集計前に決めた活動を指します。社内承認だけを数えるのか、予算・責任者がそろって活動を始めた状態を数えるのかも統一してください。本例は後者です。
検証結果が良くても移行しない案件では、追加の性能検証より、予算や受け入れ体制の確認が先になることがあります。集計表から個別案件へ戻り、止まっている理由を確かめるところまでが分析です。
分母と判定時点をそろえる4つの集計ルール
同じ計算式でも、対象の選び方が変われば率は変わります。月次や部門間で比較するときは、次のルールを短い集計メモに残し、集計担当者が変わっても再現できるようにします。
1. 開始時期か判断期限か、集計対象を固定する
検証運営の遅れを把握したいなら、「今月に判断期限を迎えた案件」を集計する方法があります。一方、「ある年度に始めた案件が、その後どうなったか」を知りたいなら、開始案件を分母にして、開始から一定期間を追う方法が適しています。
開始案件を分母にすること自体は誤りではありません。ただし、始まったばかりの案件と十分な検証期間があった案件を混ぜると、早期の案件ほど不利になります。集計する目的に合わせて、観察する期間をそろえてください。
2. 未判定と未判断を分け、どちらも件数を残す
未判定は、検証の成否を決める材料が足りない状態。未判断は、成否が分かっている場合も含め、次の対応が決まっていない状態です。先ほどの予算待ちは「成功条件を満たしたが未判断」、対応未定の案件は「未判定かつ未判断」に当たります。
二つは重なることがあるため、合計して対象件数にしません。率を出す際は、どちらを分母に含めたかを明示します。未判定案件だけが増えているなら、技術を改善する前に、測定やデータ確保の段取りを点検する必要があります。
3. 成功条件や期限を変えたら、変更前も残す
新しい事実が分かり、検証範囲を変えることはあります。その際は、変更前の条件、変更理由、承認者、日付を残してください。結果を見てから基準を緩め、その変更を記録しない運用では、改善したかどうかが分からなくなります。
期限の延期も同様です。期限到来案件を集計する場合、当初の予定を消して翌月へ移すだけでは、遅れている案件が集計から見えなくなります。当初期限と最新期限を両方持ち、締め日時点の遅延として確認します。
4. 案件の難しさが違う集団を、一つの率で順位付けしない
既存技術の横展開と、初めての顧客・用途を探す案件では、不確実さが異なります。部門ごとの成功率に差があっても、担当者の能力差ではなく、扱った案件の違いかもしれません。まず目的や段階ごとに分け、その中で傾向を見ます。
各部門の率を単純平均するのも避けます。全体値が必要なら、定義が同じグループについて、分子の合計を分母の合計で割ります。定義や観察期間が違うグループは、無理にまとめず別々に表示する方が判断に役立ちます。
PoCの結果から判断できないとき、どこを見直すか
近い状態を開くと、確認項目と記事内の説明・関連支援が分かります。
NEXT STEP
次のステップ
集計の問題か、検証設計の問題かを整理する
結果は出ているのに判断が進まない場合は、新規事業のリスクを診断し、必要に応じて仮説整理・検証設計・事業化準備の支援を検討できます。
PoC成功率を改善する前に整える5つのこと
改善の目的は、数字を良く見せることではなく、必要な前提を確かめ、投資の判断につなげることです。次のPoCを始める際は、以下の順に計画を点検します。
1. 結果によって変わる判断を、一つに絞る
「新技術を試す」だけでは、どこまで調べれば十分かが決まりません。「限定した業務へ導入するか」「有償での試行に進むか」のように、結果を受けて決めることを先に置きます。その判断を変える最も大きな不確実性が、今回の検証対象です。
基礎的な技術探索なら、すぐに事業化を決めない場合もあります。そのときは「どの方式を次の研究対象として残すか」を判断にすればよく、売上や契約を無理に今回の成功条件へ入れる必要はありません。
2. 成功条件と、判定できない場合の扱いを合意する
測る指標だけでなく、対象者、使用環境、必要なデータ、測定期間を決めます。条件を満たさなかった場合と、データ不足で判定できなかった場合の対応も分けておけば、終了時の議論が混乱しにくくなります。
実施後に新しい論点が出ることは避けられません。最初に決めた条件へ固執するのではなく、変更が必要なら、理由を残して関係者で合意し直す運用にします。
3. 必要な証拠を得られる、最小限の検証を選ぶ
機能を作り込んでも、知りたいことを観察できなければ判断材料は増えません。購入条件を知りたい段階なら、まず価格を示して費用負担者に確認する方が、試作品への機能追加より有効な場合があります。性能が不明な段階では、対象を絞った試験から始める方法もあります。
この順序は、顧客の意見だけで技術や安全性の確認を省くという意味ではありません。次の判断に必要な証拠と、その証拠を得る方法を一対一で対応させる、という考え方です。
4. 判断者と、次段階を引き受ける部門を先に決める
終了時に初めて経営層や運用部門へ説明すると、必要な条件が後から増えることがあります。開始前に、誰が結果を評価し、誰が予算を判断し、誰が導入後の運営を担うかを確認します。
判断者には、完成品の説明だけでなく「どの結果なら、何を承認してほしいか」を示してください。PoCの出口は報告書の提出日ではなく、結果を受けて次の対応を決める場です。
5. 結果・判断・次の担当を、一つの記録につなげる
技術報告書と会議の議事録が別々だと、どの証拠がどの判断につながったかを追えません。案件ごとに、成功条件、観察した事実、成否、判断理由、次の担当者と期限を対応させます。
月次会議では、率の説明だけで終えず、未判定・未判断の案件を開き、次に足す証拠か、決めるべき条件を一つ特定します。検証のやり直しが多い場合は、PoCの失敗パターンと立て直し方も点検材料になります。
継続・修正・中止は、PoCの結果と事業条件で選ぶ
成功率は、案件の状態を把握するための入口です。個々の案件を進めるかどうかは、確認できた事実、残る不確実性、次に必要な費用や人員を並べて判断します。
継続は、次に使う予算と責任者まで具体化する
条件を満たしたら、次の活動の範囲、予算、責任者、開始時期を決めます。検証環境では動いたとしても、本番データとの接続や保守体制は別に確認が必要なことがあります。残る不確実性を明示したうえで、どこまで進めるかを判断します。
「成功したので本格展開」と一足飛びに決めず、限定導入や有償試行を挟む選択肢もあります。移行時の仕事を具体化したい場合は、PoCから事業化へ進むための移行設計で確認できます。
修正は、変える条件と次の判定日を決める
結果が想定と違っても、対象顧客や提供方法を変えれば、別の可能性が残ることがあります。ただし、追加検証は「続けたいから」ではなく、結論を変え得る証拠を得られる場合に限って検討します。
たとえば、利用価値は確認できたが現行の接続方法では導入できないなら、接続方式を変えた限定検証が候補です。対象、追加費用、担当者、判定日を決め、同じ問いを無期限に調べ続けないようにします。
中止は、検証で分かったことまで失敗扱いしない
中止には、成功条件を満たさなかった場合も、技術は成立したが事業方針や費用の条件が合わなかった場合もあります。中止という行動だけで、検証結果を一律に「不成功」へ書き換えないでください。
重要な前提が成立しないと分かれば、大きな投資の前に止める根拠になります。一方で、止めたことだけを良い判断と評価するのも早計です。判断に使った証拠と、代替案を比較した理由を残しておきます。
終了時には、検証データ、確認できた制約、顧客との合意範囲、再利用できる成果物を整理します。同じ前提を別のチームが再び調べる手間を減らすことも、PoCで得た価値の一つです。
PoC成功率についてよくある質問
目標設定や集計で迷いやすい点を補足します。社内で決めた定義と違う例が出たときは、結果を消さず、扱いを明文化してから集計してください。
まとめ：成功率と、次に進めない理由を一緒に見る
PoCの成功率は、成功条件と分母が分からなければ評価できません。条件を満たした割合を確認したうえで、判断が済んだか、次段階を始められたかを分けると、検証と事業化のどちらに課題があるかを調べやすくなります。
まずは、直近で判断期限を迎えた案件を一つ開いてください。「何を確かめたか」「何が分かったか」「何をすると決めたか」「誰がいつまでに動くか」を、同じ記録から説明できるでしょうか。空欄になっている箇所が、次の会議で埋めるべき項目です。
CONTACT
お問い合わせ
次のPoCで、何を決めるかを具体化する
今回確かめたい前提、手元の証拠、判断が止まっている理由をお聞かせください。検証する範囲と、結果を受けて進める仕事を一緒に整理します。
