PoC支援会社の選び方｜支援範囲・費用・見極めポイント

相見積を3社ぶん取り寄せて、比較表を作り始めたところで手が止まる。列が揃わないのです。PoC支援の発注では、ここが最初の詰まりどころになります。技術検証だけを見ている会社、事業性の判断まで踏み込む会社、検証に協力してくれる企業を連れてくる会社。見積の内訳も各社で単位が違い、並べても比べる軸がつくれません。

揃わないのは、担当者の整理力の問題ではありません。PoCという言葉が、工程の名前ではなく目的の名前だからです。何を確かめたいのかを先に決めない限り、支援会社の側も自社の得意な工程を提案するしかないのです。

この記事では、支援範囲と費用をどこで線引きして比べるかを、発注側の手順として整理します。

PoC支援会社とは｜外部に出せる工程と、出せない工程

PoC支援会社とは、事業アイデアの検証工程を、設計から実施・評価まで外部の立場で請け負う事業者です。 そもそもPoCとは、事業化の可否を判断するために、限定した条件下で仮説を実地で確かめる工程を指します。確かめる対象は大きく3つ。技術が想定した精度で動くか、想定した顧客が本当にお金を払うか、業務プロセスに乗せてオペレーションが破綻しないか、です。この3つは検証方法も必要な人材も別物で、1社で全部を高い水準で担える事業者はほとんどありません。

外部化しやすいのは、経験の蓄積が効く作業です。検証設計の型（仮説の分解、成功基準の言語化、実験デザイン）、プロトタイプの実装、検証対象者のリクルーティング、データ分析と報告がここに入ります。

一方で、社内に残すべき工程があります。確かめたい問いの決定、判定基準の合意、既存事業との関係の整理、そして撤退か継続かの意思決定です。判定基準まで支援会社に作らせると、支援会社にとって達成しやすい基準に寄っていきます。報告書は届くのに判断だけが進まない状態は、この線引きをせずに発注したときに生まれるのです。

支援範囲で分かれる4タイプと、IT・クラウド導入前の検証プログラム

PoC支援会社は、提供する工程によって大きく4タイプに分かれます。この分類を手元に置いて提案を読むと、見積の桁が違う理由が見えてきます。

新規事業支援会社の類型論と重ねると、相手探索型は共創・マッチング型に、戦略・設計型は戦略コンサル型や伴走型に、検証運用型は伴走型や事業開発代理店型に対応します。実装型に相当する型は、支援会社の類型論では独立した位置を持たないことが多い領域です。

この4タイプとは別枠で、クラウドベンダーやSIerが自社製品の導入検討者に向けて提供する検証プログラムがあります。 業務システムやSaaSの導入前に検証環境やハンズオンを用意し、自社製品が既存環境で問題なく動くかを確かめる枠組みです。目的は製品の適合性確認であり、「その事業をやるかどうか」の可否判断は対象に入りません。導入する製品がすでに絞られていて、確かめたいのが技術的な適合性と移行の見通しだけなら、この枠組みを使うのが最短です。逆に、売れるかどうかが分からない段階でこれを選ぶと、「製品は動く」という結論だけが残り、事業判断の材料は増えません。「PoC支援」で検索して出てくる事業者の多くはこの型を指しているため、自社が探しているのがどちらなのかを先に決めておいてください。

見積の桁が違って見えるときは、積算の単位が違う提案を並べています。戦略・設計型は人月ベースのコンサルティング稼働、実装型は開発工数が主体で、数えているものが別物だからです。必要なタイプは、直前で詰まっている論点で決まります。「作れるかどうかが不明」なら実装型を選びます。「誰に売るかが不明」なら相手探索型か戦略・設計型。「現場に乗るかが不明」なら検証運用型です。組み合わせて発注するなら、統合の責任をどちらが持つかを先に決めておきます。

依頼前に社内で決める3点｜これがないと提案が比較できない

支援会社に声をかける前に社内で決めるのは、目的・判定基準・体制の3つです。これが揃った状態でRFPを出すと、各社の提案が同じ土俵に並びます。

1つ目は、このPoCで何を確かめるのか。 「新規事業の可能性を検証したい」は目的として機能しません。「地方の中堅製造業が、外注していた検査工程を内製化する動機を持つか」まで具体化すると、必要な支援タイプが絞られます。問いが3つ以上あるなら、優先順位を付けて1つに絞るか、フェーズを分けてください。

2つ目は、どうなったら次に進み、どうなったら止めるのか。 「協力企業10社中6社以上が有償トライアルに同意」のように、数と条件で書けるところまで落とします。この基準を決めるのは発注側です。設計に助言をもらうのは構いませんが、決定権は渡しません。

3つ目は、社内の稼働体制です。 関係部署への説明、社内データの提供、法務・情報システム部門との調整は発注側にしか担えません。社内側の窓口を決めずに発注すると、支援会社が待つ時間がそのまま期間の延びになります。法務のNDA審査、情報システムのセキュリティ審査、購買の取引先審査に何日かかるかも、声をかける前に確認しておきましょう。ここは支援会社側では短縮できません。

この3点を文書化すれば、そのままRFPの中身になります。

費用の見方｜金額ではなく、何が含まれるかで比べる

PoC支援の費用は、単一の相場では表せません。支援範囲が4タイプに分かれる以上、「何にいくら払っているか」を分解してからでないと比較が成立しないのです。見積を受け取ったら、次の7要素に割り当てて各社を並べ直してください。

1. 設計工数：仮説整理、検証計画、評価設計にかかる人日
2. 実施工数：実験の運用、対象者との調整、データ取得
3. 開発費：プロトタイプやシステムの構築。ここだけ工数の性質が違う
4. 外部コスト：協力者への謝礼、広告費、ツール利用料、機材
5. 分析・報告：データ分析、報告書、社内報告会への同席
6. 期間中の定例稼働：週次ミーティングやレポーティングの固定費
7. 検収時期：いつ検収でき、単年度予算の年度内に完了するか

割り当ててみると、金額差の理由はほぼ見えます。安く見えた提案が設計工数を薄く見積もっているだけ、というケースは珍しくありません。外部コストの扱いも事業者によって分かれ、協力者謝礼や広告費を含めない見積では、予算枠の外に追加費用が出ます。内訳が「一式」でしか示されない見積は、そこを確認するまで比較対象にしないでください。

見極めポイント｜初回商談で聞く7問と、社内審査で先に確認する3点

PoC支援会社の力量は、実績の数ではなく初回商談での質問の質に表れます。良い支援会社は、自社サービスの説明より先に、こちらの前提を崩しにきます。発注側から確認するのは次の7問です。

1. 提案者と実行者は同じか。着手後に交代する体制では、検証設計の意図が引き継がれない
2. うまくいかなかった検証を具体的に語れるか。失敗を発注側の事情としてしか説明しない相手は、自社の検証設計を振り返る習慣がない
3. どこからが自社の担当外か。「何でもやります」より、境界を先に引く相手のほうが期間内に着地する
4. 検証相手をどう確保するのか。手段と、想定した層に届かなかった場合に誰がどう動くかまで詰める
5. 中間で計画を変える手続きがあるか。仮説が早期に否定されたとき、契約上も設計を組み替えられるか
6. 成果物は何が納品されるか。報告書だけか、実験に使った素材やデータも引き渡されるのか
7. 終了後にデータと知見はどちらに残るか。分析ロジックと対象者リストの帰属を契約前に確認する

とくに4番目は、事業性を確かめるPoCで最も軽視されがちな論点です。技術検証は社内環境で完結しますが、顧客の実在性を確かめる検証では「誰に会えるか」が結果の質をそのまま決めます。手段が「既存顧客への声かけ」だけなら、会いやすい相手にだけ話を聞いて、想定顧客とずれた結論が出てしまうのです。

力量とは別に、社内審査を通すために先に確認しておく項目が3つあります。社内に上げたときに差し戻される論点は、ここに集まります。

1. 再委託の有無と実行メンバーの所属。提案書の体制図にいる人が支援会社の社員なのか、社外への再委託なのか
2. 情報セキュリティ審査と社内データの取扱い。自社のチェックシートに回答できるか、持ち出せるデータと個人情報の範囲はどこまでか
3. 稟議金額に合わせた分割発注と中断条項。フェーズを切って発注できるか、途中で止めた場合の精算をどう書くか

契約形態と成果物の定義｜責任範囲はどこで変わるか

PoC支援の契約は、どの類型で結ぶかによって責任の所在が変わります。民法は請負を、当事者の一方が仕事を完成することを約し、相手方がその結果に対して報酬を支払う契約と定めています（民法第632条）。 一方の準委任には委任の規定が準用され、事務の処理そのものが目的になります（第643条・第656条）。

経済産業省が2018年6月に策定した「AI・データの利用に関する契約ガイドライン」は、AI開発をアセスメント・PoC・開発・追加学習の段階に分け、PoC段階については準委任型の契約を基本とする整理を示しています（経済産業省、2019年12月に改訂版1.1が公表）。 自社の案件でどちらの類型を選ぶかは契約の内容と社内規程によるため、法務部門または弁護士等の有資格者に確認のうえ判断してください。

発注側が先に詰めておくべきは、類型の名前より成果物の定義です。検証レポートの粒度、生データの引き渡し範囲、プロトタイプのソースコードと著作権、検証対象者の情報の取り扱い。これらを契約書の別紙に列挙しておかないと、終了時に「報告書は出したので完了」という主張と噛み合わなくなります。

「PoC疲れ」を生むのは支援会社ではなく発注側の設計

検証を何本も回したのに、事業が一つも立ち上がらない——この状態の原因は、支援会社の能力不足より発注側の設計にあることが多いのです。判定基準がないまま検証を始めれば、どんな結果が出ても、次に進む理由も止める理由もつくれません。典型的な構造は4つあります。

判定基準が事後に作られる。 検証を終えてからデータを見て基準を決めると、出た数字を肯定する基準に寄ります。「一定の手応えを得た」という報告だけが積み上がっていきます。

目的が社内向けの実績づくりにすり替わる。 年度内のPoC実施本数が評価指標になっている組織では、確かめたい問いがないまま案件が発注されます。

確かめる対象が大きすぎる。 「新規事業の市場性」を1回で確かめようとすると設計が総花的になり、どの仮説も浅くしか検証できません。

外部に丸ごと預けて、社内に知見が残らない。 報告書は残っても、なぜその設計にしたのか、どの判断がどのデータに基づいたのかが蓄積されません。

いずれも、支援会社を替えても解決しません。発注前に、確かめる問いを1つに絞り、判定基準を先に書き、検証に立ち会う社内メンバーを決めてください。この3つが対策のすべてです。

Spreadyの検証支援が向く場合・向かない場合

Spreadyは、PoC支援会社の4タイプ（戦略・設計型／実装型／検証運用型／相手探索型）のうち、相手探索型を中心とした検証支援を提供しています。現在の提供メニューでは、技術的なプロトタイプ開発やシステム実装を伴う実証実験の運用は扱っていません。

向いているのは、確かめたい相手が社外にいて、まだ接点がない場合です。事業テーマと会いたい相手の条件を登録すると、社外のコラボレーター（各社の実務者）とつながり、仮説を確かめる対話を設定できます。「想定した課題が本当に存在するのか」「誰が予算を持っているのか」を、検討の初期に実在の相手から確かめる用途に寄った設計です。

向いていないのは次の場合です。技術的実現性の検証が主目的なら、開発会社系の支援を選んだほうが早く進みます。実店舗や現場オペレーションでの実地検証が必要な場合も、運用を担える事業者のほうが適しています。すでに顧客候補が社内に十分いて、接点づくりが課題でないなら、外部のマッチングを挟む意味は薄いでしょう。業務の運用そのものを外部で回す必要がある場合は、検証支援とは別のメニュー（BPaaS）での相談になります。

判断の起点は、いま詰まっているのが「作れるか」なのか「求められているか」なのか、その切り分けにあります。

よくある質問

Q. PoC支援会社に丸ごと任せることはできますか。 検証の設計・実施・分析までは外部化できますが、確かめたい問いの決定と、次に進むか止めるかの判定基準の設定は発注側に残ります。判定基準まで支援会社に委ねると、達成しやすい基準に寄る構造が生まれるためです。社内データの提供や法務・情報システム部門との調整も外部では代われないため、社内側の窓口を決めずに発注すると、支援会社の待ち時間がそのまま期間の延びになります。

Q. 見積の金額差が大きいとき、何を確認すればよいですか。 支援範囲のタイプが違う可能性が高いため、設計工数・実施工数・開発費・外部コスト・分析報告・定例稼働・検収時期の7要素に分解して並べ直してください。協力者謝礼や広告費といった外部コストが見積に含まれるかどうかは、事業者によって扱いが分かれます。「一式」表記の見積は、内訳を確認するまで比較対象にしないほうが確実です。

Q. 開発会社とマッチング系を組み合わせて発注してもよいですか。 組み合わせる発注は現実に多くありますが、統合の責任をどちらが持つかを発注時に決める必要があります。決めないまま並行させると、実装会社が作ったプロトタイプを誰も検証に使わないまま期間が終わります。窓口を発注側が持つのか、いずれかの支援会社に元請として持たせるのかを、契約前に書き分けてください。

まとめ｜比較表を作る前に支援範囲を線引きする

PoC支援会社の選定は、比較表を作る前の線引きでほぼ決まります。実務で押さえる要点は次の5つです。

1. 外部化できるのは検証の設計・実施・分析まで。確かめる問いの決定と判定基準は社内に残す
2. 支援会社は戦略・設計型／実装型／検証運用型／相手探索型に分かれる。製品導入前の検証プログラムは別の枠組みで、事業の可否判断は対象外
3. 見積は7要素に分解して比べる。外部コストの扱いと、年度内に検収できるかを必ず確認する
4. 初回商談では実績数ではなく、失敗の説明と担当範囲の明示、検証相手の確保手段を確認する。再委託・セキュリティ審査・分割発注は社内審査で必ず問われる
5. 契約類型の名前より成果物の定義。生データ・ソースコード・対象者情報の帰属を別紙に書く

会うべき相手の条件から相談する

「作れるか」で詰まっているのか、「求められているか」で詰まっているのか。切り分けが済んでいない段階でも構いません。確かめたい問いの絞り込みは論点の叩き台までお出しし、判定基準の決定は御社に残す前提で進めます。最初に一緒に詰めるのは、会うべき相手の条件です。

［ 検証支援について相談する ］