PoC（実証実験）で失敗しない業者コントロール術｜成果物の定義方法

• 業者に見積もりを出してもらい、PoC（実証実験）を発注することは決めました
• ただ、契約書には「検証を実施する」としか書かれておらず、何をもって成功とするのか曖昧なままです
• 「まずはPoCから」という提案をそのまま受け入れていいのか、判断がつきません

PoCの発注そのものは、決して間違った選択ではありません。問題は、ゴールと成果物を契約前に握らないまま走り出してしまうことです。

目的や成功基準を決めずに始めると、検証は動いても評価する基準がなく、判断できないまま時間だけが過ぎていきます。AI現場ログは、中小企業のAI活用事例を継続して取材しているメディアです。

本記事は、契約前に業者と握っておくべき5つの成果物定義を整理します。実施計画書に書くべき項目と、丸投げ業者を見抜く発注前チェックリストも扱います。読み終える頃には、次にどの業者と何を確認すればいいか、具体的な質問リストを手にできる状態です。

PoCが「検証しただけ」で終わるかどうかは、技術力ではなく契約前にどこまで数字と期限を決めておくかで決まります。

PoC（実証実験）が「検証しただけ」で終わってしまう理由

PoCを発注した企業の多くが直面するのが、技術的な検証には成功したのに、本番導入の話が進まないという状況です。本章では、この現象の実態と背景を、以下の2点から確認します。

• 技術的には成功しているのに本番に進まない「PoC止まり」の実態
• 「PoC死」「PoC疲れ」という言葉が生まれた背景

技術的には成功しているのに本番に進まない「PoC止まり」の実態

「PoC止まり」とは、実証実験の技術的な検証は完了したものの、本番導入や事業成果に結びつかないまま終わる状態のことです。

BCG「Where’s the Value in AI?」(2024年10月、59カ国のCxO1,000人超対象)によると、PoCを超えて実際の価値創出に必要な能力を備えている企業は26%にとどまります。

残り74%は、AIから具体的な価値をまだ実現できていない、という結果です。

Accenture「The Art of AI Maturity」は、2021年8〜9月に、15カ国・16業種の経営幹部1,615人への調査と1,176社のデータ分析を行いました。

全体の63%が、AI活用の能力がまだ実験段階にある「AI Experimenters」に分類されています。

これは個々のPoCが停止した割合ではありませんが、技術の試行から事業成果へ進むための組織能力に課題を抱える企業が多いことを示しています。

「PoC死」「PoC疲れ」という言葉が生まれた背景

「PoC死」は、成果につながらないPoCを繰り返す問題を表す際に使われる業界用語です。

ネットコマース社の斎藤昌義氏は、2019年のコラムで「PoC貧乏」「PoC死」という表現を用いています。用語の起源は確認できないため、本記事では由来を断定しません。

一方の「PoC疲れ」は、目的が曖昧なまま複数のPoCを並行して繰り返し、コストと社内の疲弊だけが蓄積する状態を指す言葉です。いずれも経済産業省や情報処理推進機構(IPA)が公式に定義した用語ではありません。SI・ITコンサル業界のなかで自然に広まった俗語、という位置づけです。

言葉の由来を知ること自体に大きな意味はないかもしれません。ただ、多くの企業が同じ壁にぶつかってきたという事実こそ、次章で扱う「原因」を考えるうえでの手がかりになります。

PoCが失敗する本当の原因は技術ではなく「進め方」

PoC止まりの原因を技術力の不足だと考えると、対策を誤ります。実際に繰り返し指摘されているのは、以下3つの「進め方」の問題です。

• ゴール設定のすり替え：技術検証の完了そのものが目標になっていないか
• 撤退基準(No-Go基準)を決めずに走り出す進め方
• 業者への丸投げ：成果物の定義を握らないまま契約すること

ゴール設定のすり替え：技術検証の完了そのものが目標になっていないか

PoC止まりの企業に共通するのが、「動くものができたかどうか」がいつの間にか目的になってしまう現象です。本来のゴールは、本番導入するかどうかを判断できる材料をそろえること。ここが入れ替わってしまうと、検証を重ねても次に進めなくなります。

croppre「AI活用が『PoC止まり』で終わる企業の5つの共通点」は、ゴール設定の誤りに加え、業務オーナーの不在、精度への完璧主義、経営層の判断基準の欠如、ベンダーへの丸投げを共通点として挙げました。

技術検証が成功しても、次に進むための判断材料がなければ、プロジェクトは宙に浮いたままになりかねません。

撤退基準(No-Go基準)を決めずに走り出す進め方

PoCを始める企業の多くは「うまくいったら本番へ」という前提で進めますが、「うまくいかなかった場合にどうするか」を事前に決めているケースは多くないのが実情です。

GXO「PoC(概念実証)の進め方2026」は、開始前に合格基準を数値で記入し、検証後に実測値と判定結果を並べて記録する「Go/No-Go/Pivot判定シート」の運用を提案しています。

撤退基準を先に決めておけば、検証後の判断が「なんとなく続ける」に流れるのを防げるでしょう。

業者への丸投げ：成果物の定義を握らないまま契約すること

3つ目の原因は、発注時点で成果物の中身を発注者側が握っていないことです。「検証をお願いします」という依頼だけでは、発注者が期待する成果と、契約書で業者が負う義務が一致しないおそれがあります。

経済産業省・特許庁のモデル契約書(AI編・技術検証契約)は、技術検証契約を準委任契約として構成し、善管注意義務を負う一方、成果や結果の完成を保証しない例を示しています。

ただし、実際の責任範囲は個別の契約条項と事実関係によって変わります。だからこそ重要になるのが、次章で扱う「契約前に握るべき成果物定義」です。

契約前に業者と握っておくべき5つの成果物定義

PoC止まりを防ぐために有効なのが、契約前の段階で以下の5項目を業者と合意しておくことです。経済産業省・特許庁のモデル契約書や、複数のPoC支援会社の実務記事が共通して示す骨格でもあります。

• ①検証スコープ：やること・やらないことを先に決める
• ②KPI・成功基準：定量指標と定性指標を数値で決める
• ③Go/No-Go/Pivot判定基準：合格ラインを開始前に記入する
• ④成果物の細目分解：レポートだけでなくモデル・データ・コードまで
• ⑤次フェーズ移行の期限：いつまでに可否を通知するかを契約書に書く

①検証スコープ：やること・やらないことを先に決める

最初に合意すべきなのが、検証の対象範囲を先に絞り込むことです。

Sun*「PoC(概念実証)設計の進め方」は、検証対象を「営業部門におけるFAQ対応業務のうち、問い合わせ件数が多い上位20項目に限定。

全社展開や基幹システムとの本格連携は対象外」のように、対象外の業務まで書き込む方法を示しています。

範囲を絞らずに始めてしまうと、検証の途中で対象業務が広がり、期間と費用だけが膨らみやすくなるので注意が必要です。

②KPI・成功基準：定量指標と定性指標を数値で決める

成功基準は、数値で答えられる形にしておく必要があります。Sun*の同記事が示すのは、「回答精度80%以上、平均応答時間3秒以内、作業時間10%以上削減」といった定量指標と、「試験利用者の70%以上が継続利用に前向き」といった定性指標を組み合わせる、二層構造のKPI設計です。

「使い勝手がよさそうだった」のような感想だけで判断すると、本番導入の可否を経営層に説明できません。数字にしておけば、検証後の議論は「感触」ではなく「基準に達したかどうか」に変わります。

③Go/No-Go/Pivot判定基準：合格ラインを開始前に記入する

前章で触れたGXOの判定シートは、開始時点で合格ラインを記入し、検証後に実測値と判定を並べて記録する運用です。

技術KPIと業務KPIの両方が基準に達していれば「Go」、片方だけなら「Pivot」(方向転換)、両方とも未達なら「No-Go」というように、判定は後付けではなく事前に定義しておきましょう。

判定基準を先に決めておくことで、「なんとなく続ける」「なんとなくやめる」という曖昧な意思決定を避けやすくなります。

④成果物の細目分解：レポートだけでなくモデル・データ・コードまで

「成果物」を検証レポート1本にまとめてしまうと、後から権利関係でもめる原因になりかねません。

Legal GPT「AI開発委託・PoC契約の注意点」は、成果物を細目分解する必要性を指摘しています。

学習済みモデル、推論用スクリプト、前処理コード、教師データ、評価データ、評価レポート、API・UI、プロンプトテンプレートなどに分け、それぞれの権利帰属を個別に決めておきましょう。

権利帰属は一律ではありません。発注者が提供したデータ、評価データ、新たに作るモデル、基盤モデル、OSSを分け、個別契約と元のライセンスに応じて帰属、利用権、再利用条件を定めておけば、契約後の認識のずれを防ぎやすくなるでしょう。

⑤次フェーズ移行の期限：いつまでに可否を通知するかを契約書に書く

PoCが終わっても、本番移行の判断がいつまでも先送りされるケースは珍しくありません。

経済産業省・特許庁のモデル契約書(AI編・技術検証契約)には、「報告書確認完了日から2か月以内に、共同研究開発契約を締結するか否かの検討結果を通知する」という期限条項の例が収録されています。

このように、検証後の判断期限そのものを契約書に書き込んでおくことが、判断を宙に浮かせないための工夫です。

PoC実施計画書に書くべき項目とテンプレート例

契約書とは別に、実務レベルで運用する「PoC実施計画書」を用意しておくと、業者との認識合わせがしやすくなります。以下の3点を押さえておきましょう。

• 実施背景・検証目的の書き方
• スケジュール例：8週間モデルで区切る
• 費用・知的財産・責任分界の書き方

実施背景・検証目的の書き方

Sun*「PoC計画書の作成方法」が示すPoC計画書の必須項目は7つ。

実施背景と検証目的、検証スコープ、検証手法・実施フロー、評価指標(KPI)と成功基準、実施体制とガバナンス、スケジュール・予算計画、撤退基準です。

実施背景と検証目的については、「なぜ今この検証をするのか」「検証を通じて何を確認したいのか」を一文で言い切れる粒度まで絞り込みたいところです。目的が長く複雑になるほど、成功基準もあいまいになりがちなので注意してください。

スケジュール例：8週間モデルで区切る

Sun*のPoC設計記事が示すスケジュール例は、1〜2週目に要件整理、3〜5週目に試作・検証、6〜7週目に評価、8週目に報告と次フェーズ判断、という8週間の区切りになっています。

期間を区切らずに進めると、検証がなし崩し的に延長され、「PoC疲れ」と呼ばれる状態に陥りやすくなるので気をつけましょう。自社の業務やデータの状態に合わせて週数は調整しつつ、区切りを設けること自体は業者と合意しておくことをおすすめします。

費用・知的財産・責任分界の書き方

費用面で決めておきたいのは、委託料を一括・分割・工数従量のどの形にするか、中止時の支払い範囲をどうするかです。知的財産については、前章で触れた成果物の細目分解と合わせて、権利の帰属先を項目ごとに明記しておく必要があります。

責任分界については、契約類型の名称だけで判断せず、完成させる対象、善管注意義務、検収条件、再実施や追加費用の扱いを条文で確認してください。実際の責任範囲は契約文言と事実関係で変わるため、重要な契約は締結前に弁護士へ確認するのが安全です。

「丸投げ業者」を見抜くための発注前チェックリスト

契約書の項目を整えても、発注先の業者選び自体を誤れば意味がありません。発注前に確認しておきたい観点を、以下の2点にまとめました。

• 良い業者と悪い業者を分ける5つの質問
• 契約書に入れるべきリーガルチェックポイント

良い業者と悪い業者を分ける5つの質問

GXOのチェックリストから、発注前にベンダーへ確認したい項目を5点に絞ると、次のとおりです。

• 開始前に成功基準を数字で決められるか
• No-Go基準もセットで定義するか
• 稟議用の判断シートやROI試算は成果物に含むか
• データ準備は発注者・ベンダーのどちらの担当か
• 本導入の概算見積もりを出してくれるか

「まずはPoCをやりましょう」と提案しながら、成功基準もGo/No-Go基準も決めようとしない業者には、注意が必要です。丸投げ型の進行になりやすいサインといえます。

契約書に入れるべきリーガルチェックポイント

Collabo Tips(弁護士監修)「技術検証(PoC)契約書のリーガルチェックポイント7点」が挙げる確認項目は、検証範囲の明確化、契約形態と成果非保証条項、委託料の設定、次段階への期限設定と追加委託料、成果物の権利帰属・利用許諾条件、秘密保持条項、並行開発(競業)の禁止範囲と期間の7つです。

契約書の細部まで自社だけで判断するのが難しい場合は、これらの項目を一覧にして、契約前に弁護士や顧問へ確認してもらう進め方も検討してみてください。

PoCの費用相場と本番移行までの流れ

最後に、費用感と公的な支援制度についても押さえておきましょう。

• PoCの費用感(一般的な業界相場の目安)
• デジタル化・AI導入補助金の活用

PoCの費用感(一般的な業界相場の目安)

PoCの費用は、対象業務の複雑さ、データ整備、外部システムとの連携、セキュリティ要件、検証期間によって大きく変わります。公的な統計に基づく一律の相場は確認できないため、具体額を先に当てはめず、同じ検証条件で複数社の見積もりを比較してください。

見積もりを受け取る際は、総額だけで高い・安いを判断してはいけません。本記事で挙げた検証スコープとKPIをそろえたうえで、成果物、追加作業の単価、中止時の精算方法まで並べて比較することをおすすめします。

デジタル化・AI導入補助金の活用

「デジタル化・AI導入補助金2026」の通常枠は、中小企業・小規模事業者等による登録ITツールの導入を支援する制度です。

公式案内では、補助率は原則1/2以内で、所定の賃金要件を満たす場合は2/3以内です。補助額は対象となる業務プロセス数により、5万円以上150万円未満、または150万円以上450万円以下と示されています。

PoC段階の費用がこの補助金の対象経費に含まれるかどうかは、案件ごとに公募要領の確認が必要です。活用を検討するなら、契約前の段階で業者にも補助金申請の実務経験があるかを聞いておくと、手続きがスムーズに進むでしょう。

PoCの業者コントロールについてよくある質問

ここまでの内容に関連して、よく寄せられる疑問を8つにまとめました。

• PoC(実証実験)と本番導入は何が違う?
• PoCの費用相場はいくら?中小企業でも発注できる?
• 契約書にどんな項目を入れておけば「成果物なし」を防げる?
• PoCの成功基準(KPI)はどう決めればいい?
• 撤退基準(No-Go基準)は誰がいつ決めるべき?
• 検証は成功したのに本番導入に進まないのはなぜ?
• PoCの成果物として契約前に何を明記すべき?
• デジタル化・AI導入補助金はPoC費用に使える?

PoC(実証実験)と本番導入は何が違う?

PoCは、AIが自社の業務で効果を出せるかを小さい範囲で確認する段階です。本番導入は、その確認結果をもとに、実際の業務へ組み込んで継続運用する段階を指します。PoCの目的は、あくまで効果が見込めるかどうかの判断材料をそろえることにあります。

PoCの費用相場はいくら?中小企業でも発注できる?

対象業務、データの状態、連携先、セキュリティ要件によって大きく変わるため、一律の相場は示せません。複数社から見積もりを取り、検証スコープ、成果物、追加費用の条件をそろえたうえで比較することをおすすめします。

契約書にどんな項目を入れておけば「成果物なし」を防げる?

検証スコープ、KPIと成功基準、Go/No-Go/Pivot判定基準、成果物の細目分解、次フェーズ移行の期限という5項目を、契約前に業者と合意しておきましょう。特に成果物を「レポート1本」にまとめず、モデルやデータまで細目分解しておくことが、後のトラブルを防ぐ鍵になります。

PoCの成功基準(KPI)はどう決めればいい?

「回答精度80%以上」のような定量指標と、「利用者の70%以上が継続利用に前向き」のような定性指標を組み合わせて決めるのがおすすめです。感想レベルの評価だけに頼ると、本番導入の可否を経営層に説明しづらくなってしまいます。

撤退基準(No-Go基準)は誰がいつ決めるべき?

撤退基準は、PoCを開始する前に、発注者側の担当者が業者と合意して決めておくべきものです。検証が始まってから決めようとすると、途中経過に引きずられて判断が甘くなりがちなので気をつけましょう。

検証は成功したのに本番導入に進まないのはなぜ?

技術的な検証の完了そのものが目的になってしまい、本番導入を判断するための基準が最初から用意されていないことが主な原因です。検証開始前に、何を確認できれば本番導入に進むのかを数値で決めておくと、この状態を避けやすくなります。

PoCの成果物として契約前に何を明記すべき?

検証結果をまとめたレポートだけでなく、学習済みモデル、推論用のスクリプトやコード、教師データ、評価データまで、項目ごとに分けて明記しておきたいところです。それぞれの権利がどちらに帰属するかも、あわせて決めておく必要があります。

デジタル化・AI導入補助金はPoC費用に使える?

制度の対象経費にPoC段階の費用が含まれるかどうかは、案件ごとに公募要領の確認が必要です。活用を検討するなら、契約前の段階で業者に補助金申請の実務経験があるかを聞いておくと手続きがスムーズになるでしょう。

まとめ｜PoCを「検証しただけ」で終わらせないために

PoCが「検証しただけ」で終わるかどうかは、技術力ではなく、契約前にどこまで数字と期限を決めておくかで決まります。ここまでの内容を5点に整理しました。

• PoC止まりは技術の失敗ではなく進め方の失敗
• 検証スコープとKPIを数値で決めておく
• Go/No-Go/Pivot判定基準は開始前に記入しておく
• 成果物は細目分解し権利の帰属先まで決める
• 次フェーズ移行の期限を契約書に書き込む

まずは、次に発注を検討している業者に、本記事のチェックリストを一つずつ確認してみてください。