PoCまでは進んだのに、なぜ多くの協業は事業化の一歩手前で止まるのか。原因はアイデアの質より「フェーズの設計」にあると考えられます。誰が・何を・どの成功条件で・どこまでの費用で進めるのかを、最初のフェーズで言語化しておくことが、後半の壁を越える鍵になります。
新規事業開発やオープンイノベーションの現場では、スタートアップとの技術検証（PoC）まではむしろ順調に進むケースが少なくないと考えられます。技術は動いた、デモは好評だった、社内報告も通った——にもかかわらず、そこから先の本格導入・事業化へ移る段になると急に足が止まる。この「PoCの谷」は、担当者個人の努力不足ではなく、協業の設計そのものに構造的な原因が潜んでいることが多いと考えます。失敗の型についてはPoCが事業化しない理由で構造を分解していますが、本記事では「ではどう設計すれば越えられるのか」という前向きな側面に焦点を当てます。
背景には、日本の製造業・物流業が直面する構造的な人手不足と技能継承の問題があります。熟練者の目視検査や属人的な現場判断を、いつまでも人に依存し続けるわけにはいかない——この危機感が、大手企業を外部スタートアップとの協業へ向かわせています。ただし、危機感が強いほど「何かすぐ成果が欲しい」という圧力も高まり、腰を据えたフェーズ設計が後回しにされやすいという逆説もあると考えられます。
見落とされがちなのは、PoCの成功条件と事業化の成功条件がまったく違う軸で測られている、という点です。PoCでは「技術的に可能か」が問われますが、事業化では「量産要件を満たすか」「現場が運用できるか」「投資に見合うか」が問われます。前者をクリアしても後者は別途クリアする必要があり、しかもその評価者（意思決定者）も予算の出どころも変わります。この評価軸と主体の交代を最初に想定していないと、PoC成功が次に自動的につながる、という誤った期待が生まれてしまうと考えます。
つまり課題は「良い技術を見つけること」ではなく、「良い技術を、評価軸と予算主体が入れ替わる複数のフェーズを越えて、事業として着地させる道筋を設計すること」だと考えられます。ここからは、その道筋をフェーズという単位で解きほぐしていきます。
フェーズ設計に入る前に、そもそも大手企業側とスタートアップ側で前提がズレやすい論点を整理しておくと、後の設計が具体的になります。Nsight自身もスタートアップとして大手企業や商社との協業・共同出展・オフラインの勉強会を実践する立場から、両面の事情に触れておきます。
大手側の意思決定は、稟議・予算年度・部門調整のサイクルで動きます。一方スタートアップは資金のランウェイ（手元資金で活動できる期間）の中で動いており、数ヶ月の意思決定の遅れが事業の存続に直結することもあります。この時間軸の非対称性を理解せずに「じっくり検討したい」と伝えると、スタートアップ側は静かにリソースを別案件へ振り向けてしまう可能性があると考えられます。
「まずは無償で試してほしい」という依頼は珍しくありませんが、スタートアップにとってエンジニアの工数はほぼ唯一の資産です。無償PoCが積み重なると本業が回らなくなる。逆に大手側も、成果が不確実な段階で高額を投じる決裁は通しにくい。だからこそ、フェーズごとに「この検証にはこの範囲の費用を、こう分担する」と切り分ける発想が、双方にとって現実的だと考えます。費用を一括で考えるほど交渉は膠着しやすくなります。
新規事業部門が旗を振って始めた協業も、事業化の段では製造現場・品質保証・情報システムといった実運用部門へ引き継がれます。ここで初めて「うちの現場ではその置き方は無理」「既存ラインのタクトに合わない」「量産では別の照度条件が必要」といった要件が後出しで現れます。これは現場が意地悪なのではなく、検証フェーズに現場が同席していなかったことの当然の帰結だと考えられます。この3つのズレ——意思決定者・現場・量産要件——を、次章のフェーズ設計で先回りして吸収していきます。
協業を一枚岩の「プロジェクト」として扱うのではなく、性質の異なる5つのフェーズの連なりとして設計する。これが移行の壁を越えるための基本的な発想だと考えます。ここで提示する5フェーズは、あくまで整理のための一つの型であり、案件によって統合・分割してよいものです。
第1にNDA・構想合意フェーズ。秘密保持契約を結び、そもそも何を一緒に目指すのか、成功したらどこへ向かうのかの絵姿をすり合わせます。第2に技術検証（PoC）フェーズ。技術的に成立するかを、限定されたサンプルや条件で確かめます。ここは検証フェーズの実務そのものであり、進め方はAI検査PoCの進め方で具体化しています。
第3に現場実証フェーズ。ラボではなく実際の現場・実物・実際の環境（照明・振動・粉塵・タクト）で成立するかを確かめます。第4に限定導入フェーズ。一つのラインや一つの拠点に絞って実運用を回し、現場の運用負荷や例外対応を洗い出します。第5に事業化・量産展開フェーズ。横展開・量産要件・保守体制・収益モデルを固めます。この本番移行の実際はPoCから本番システムへでも扱っています。
重要なのは、フェーズを分けること自体が目的ではなく、フェーズの「継ぎ目」に注意を集められることに価値がある、という点です。プロジェクトが止まるのはフェーズの内部ではなく、ほとんど常に継ぎ目——次のフェーズへ移る瞬間だと考えられます。フェーズを明示的に区切ることで、その継ぎ目に何が必要かを事前に議論できるようになります。
各フェーズに着手する前に、最低限3つを言語化しておくことを推奨します。「成功条件（何をもって次へ進むか）」「費用分担（誰がどこまで負担するか）」「意思決定者（誰のGOで次へ行くか）」です。この3点セットを曖昧なまま走り出すと、フェーズ末で「これは成功なのか失敗なのか」の解釈が割れ、協業が宙吊りになると考えます。
成功条件は「良い感じに動く」ではなく、可能な限り測定可能な形で決めます。たとえば外観検査であれば、対象・不良の種類・許容できる見逃しと過検出のバランス・判定にかけられる時間などを、事前に合否ラインとして合意しておく。ここで注意したいのは、この段階で示せる数値はあくまでモデル前提・一例であり、実際の性能は現物・現場での検証を経て初めて確からしくなる、という点です。着手前に「本番の数値」を約束し合うと、後で必ず食い違いが生じると考えられます。約束するのは「数値そのもの」ではなく「どう測るか」の方だと考えます。
費用は協業全体で一括に考えるのではなく、フェーズごとに区切って合意し直す方が現実的だと考えます。初期の技術検証は双方が自社工数を持ち寄る、現場実証からは実費や機材費を発注側が負担する、限定導入からは正式な契約に基づく、といった段階的な移行です。段階を刻むことで、大手側は「不確実な段階で大きく賭けない」を、スタートアップ側は「工数の持ち出しが青天井にならない」を、同時に満たしやすくなると考えられます。契約・費用の具体的な取り決めは案件ごとに大きく異なるため、法務・契約の専門家や最新の公式情報の確認を推奨します。
「会社として前向きです」は意思決定者を特定していません。各フェーズのGOを出せるのが具体的に誰か——部長なのか、事業部の投資委員会なのか、現場の品質責任者なのか——を実名レベルで把握し、できればそのキーパーソンを早い段階でフェーズに巻き込んでおくことが、後半の壁を低くする効果があると考えます。特に事業化フェーズの意思決定者（多くは現場・品質・情シス側）を、現場実証フェーズの時点で当事者として参加させておくと、量産要件の後出しをかなり防げると考えられます。
フェーズを設計しても、継ぎ目で人が入れ替わり文脈が失われれば、また振り出しに戻ってしまいます。移行を滑らかにするための、実務的な仕掛けをいくつか挙げます。
最大の壁である「新規事業部門→現場部門」の引き継ぎは、引き継ぐ瞬間ではなく、その一つ前のフェーズで現場を当事者化しておくことで緩和できると考えます。現場実証の設計に品質保証や製造現場の担当者を入れ、彼ら自身の言葉で要件を出してもらう。そうすると、事業化フェーズで「聞いていない」が起きにくくなります。現場が「自分たちが決めた要件」だと感じられるかどうかが、導入の当事者意識を左右すると考えられます。
量産要件の後出しは、多くの場合「量産のことを検証フェーズで誰も聞かなかった」ことに起因します。技術検証の段階から、あえて「もしこれを100ライン・24時間・複数拠点で回すとしたら、何がボトルネックになりそうか」を仮の問いとして立てておく。実際にそこまでやらないとしても、量産の視点を早期に会話へ入れておくだけで、設計判断が変わることがあると考えます。実運用を支える基盤として、たとえばエッジAI製品のような、現場の閉域環境・オフライン運用・複数台展開を前提とした構成を早めに想定しておくことも、量産段階の手戻りを減らす一助になりうると考えられます。
日本の大手企業では数年で担当者が異動します。協業の文脈が個人の頭の中にしかないと、キーパーソンの異動で一気に推進力を失う。各フェーズの合意事項・成功条件・判断の理由を、口頭ではなくドキュメントとして残し、後任がゼロから理解し直さずに済む状態をつくっておくことが、地味ですが効果の大きい仕掛けだと考えます。検証から導入までを外部の伴走者が並走するPoC伴走支援のような形も、この文脈保持の役割を担いうると考えられます。
最後に、フェーズ設計をしていてもなお陥りやすい落とし穴を、正直に挙げておきます。これらは「やってみないと分からない」部分も含みますが、あらかじめ知っておくだけで避けやすくなると考えます。
ここまで5フェーズと移行の設計を述べてきましたが、いきなり壮大なロードマップを描くことを勧めているわけではありません。むしろ逆で、出発点は徹底的に小さくてよいと考えます。まず一つ、「これが成立しなければ事業として成り立たない」という外せない要件を特定し、それを現物・現場で確かめる。ここから始めるのが、遠回りに見えて最短だと考えられます。
具体的には、（1）客観的な現状把握——今の課題は本当にAI・自動化で解くべきものか、対象と不良や判定の性質を言語化する。（2）最も不確実な一点を選び、限定条件で技術検証する。（3）その一点が現場の実環境でも崩れないかを、実物で確かめる。（4）ここまでの結果を踏まえて、初めて限定導入と事業化のフェーズ設計を具体化する。この順序を守ることで、各フェーズの成功条件・費用分担・意思決定者を、実感を伴って定義できるようになると考えます。
Nsightは、元キーエンス画像処理事業部の現場知見に、VLM・Jetsonエッジ・産業用カメラ・現場ライティングを組み合わせて、この「小さく確かめる最初の一歩」から量産・事業化フェーズまでを段階的に伴走する立場です。協業のどのフェーズで、何を、どんな成功条件で確かめるべきか——その設計自体を一緒に描くところからご相談いただけます。まずは現状の課題を整理する対話から始めることを推奨します。詳しくは相談するからお問い合わせください。
技術の是非より、フェーズの継ぎ目の設計を見直すことを推奨します。PoCの成功条件と事業化の成功条件は評価軸も予算主体も異なるため、成功が自動的につながるわけではないと考えられます。特に現場部門・量産要件・意思決定者が次フェーズで交代する点を、着手前に想定できていたかを点検すると突破口が見えることがあります。
全体を一括で決めるより、フェーズごとに区切って合意し直す方が現実的だと考えます。初期検証は双方が工数を持ち寄り、現場実証以降は発注側が実費を負担し、限定導入から正式契約へ、という段階的な移行が双方の負担を釣り合わせやすいと考えられます。契約や費用の取り決めは案件差が大きいため、法務・契約の専門家や最新の公式情報の確認を推奨します。
量産の視点を検証フェーズの早い段階から会話へ入れておくことが有効だと考えます。実際に量産をやらない段階でも「もし複数拠点・24時間で回すとしたら何がボトルネックか」を仮の問いとして立て、現場・品質・情シスの担当者を実証フェーズから当事者として巻き込むと、後出しの要件が現れにくくなると考えられます。
相手の時間軸と資産への配慮だと考えます。スタートアップは手元資金で活動できる期間の中で動いており、意思決定の遅れや無償検証の積み重ねが存続に直結しうると考えられます。フェーズごとに費用と成功条件を明確にし、意思決定者を早期に特定して巻き込むことが、協業を継続させる前提になりうると考えます。
新規事業やPoCを対象とする公的な支援制度は複数存在すると考えられますが、対象要件・金額・申請時期・適用範囲は制度や年度で大きく変わります。本記事では一般的な位置づけの説明に留めますので、実際の活用可否や条件は所管省庁の最新の公表資料でご確認いただくことを推奨します。制度前提でフェーズ設計を固めすぎず、採否に左右されない検証計画を併走させておくと安全だと考えます。
壮大な構想ではなく、「これが成立しなければ始まらない」という一点を、現物・現場で小さく確かめるところから始めます。元キーエンス画像処理事業部の現場知見とVLM・エッジ技術で、検証から量産・事業化までの道筋を段階的に伴走します。
協業のフェーズ設計について相談する