オープンイノベーション成功事例3選｜共創を事業化する5つの条件

結論｜オープンイノベーションの成果を読み解く5つの確認点

本記事では、共同の問い、各社の役割、検証、判断、事業化体制の5点で事例を整理します。これは事例から自社の計画を考えるための確認軸であり、5つそろえば必ず成功するという法則ではありません。

提携の発表だけでなく、顧客への提供と、その後も続ける体制まで確認します。

たとえば試作品の評価が高くても、販売や保守の担当が決まっていなければ、購入希望へ応えられません。検証で何を確認するかと、結果を誰が受け取り事業を動かすかを一緒に考えます。

5条件はチェック項目を横に並べるだけでは足りません。というのも、問いが変われば、必要な相手、提供資産、検証方法、判断基準も変わるからです。

さらに、検証結果が次段階の条件を満たしたら、営業や製造などの受け手が動ける設計まで必要です。

本稿では「成功」を一つの終点に固定しません。というのも、共同開発、需要確認、市場投入、継続販売、事業拡大は別の到達点だからです。

そのため、公開情報で確認できる到達点を示し、自社でも検証できる進め方を考えることを目的にします。

共創相手を探す前に、自社側で結果を受け取る人と投資を決める人を決めておきます。実際、大企業の新規事業関与者888名への調査では、PoC・検証から事業化・拡大へ移る際の最大の障壁として、経営層の後ろ盾不足を174名、判断基準の曖昧さを168名が選びました。

両項目の合計は342名、38.5%です。

出典：イノベーション総合研究所「新規事業の実態と意思決定に関する調査」（2026年4月、n=888、調査実施：株式会社マクロミル）

この結果を踏まえ、本記事では成功事例を「どの会社と組んだか」だけでなく、「誰が何を受け取り、次を決めたか」から読みます。例えば共同試作を始めるなら、営業は顧客の購入条件、製造は量産の条件、経営は追加投資の条件を先に示します。

相手企業の技術と、自社側の引き継ぎを一緒に設計するためです。

成功事例を見る4つの視点

まず、公式発表から確かめられる事実を読みます。次に、各社が持ち寄った資産と役割を機能で整理します。

そのうえで、何を小さく確かめ、どの組織が事業化を受け取ったかを見ます。最後に、自社へ移す最小単位を一つ決めます。

• 公開時点で確認できる到達点は何か
• 顧客課題と共同の目的は何か
• 各社が持ち寄った資産と担当機能は何か
• 自社で次の1案件へ移せる設計は何か

企業が違えば、同じ組織名や契約形式をそのまま使うことはできません。一方、顧客の事実を技術開発へ戻す反復、足りない機能を別企業が担う役割分担、投資と事業部接続を分けた基盤設計は、業界を越えて検討できます。

オープンイノベーション成功事例3選｜到達点と再現条件

成功事例を比較するときは、売上規模のような公開されにくい数値を無理にそろえません。共同の目的、補完関係、公開情報で確認できる到達点、自社へ移せる最小単位を同じ列で比べます。

3事例で確認できるのは、商品の継続展開、需要確認と商品化、共創を支える体制です。同じ利益指標を達成した事例としては扱いません。

自社と業種が近いかより、現在の案件で不足している機能に近い事例を選んでください。

表の右端を自社の設計へ置き換えます。たとえば技術はあるが顧客への接続が弱いなら、東レ×ユニクロから「顧客事実を開発へ戻す反復」を借ります。

複数社の得意分野が並ぶだけなら、Possiから「課題に対する機能別の役割」を借ります。案件数はあるが事業部へ移らないなら、三井不動産から「探索・投資・実装の分担」を借ります。

なお、事例の公開年と現在の運営状況は分けて確認します。たとえば、古い発表に書かれた計画を現在の成果として扱わず、後続の公式情報がある場合は更新します。

また、自社の事例台帳にも確認日を残すと、過去の成功イメージだけで判断するのを防げます。

東レ×ユニクロ｜オープンイノベーション成功事例に見る長期反復

東レとユニクロの協業は、単発の素材提供ではなく、素材開発と商品企画を長期で往復させる型として参考になります。ファーストリテイリングの2025年9月の公式発表によれば、両社は1999年に取引を始め、2006年に戦略的パートナーシップを締結しました。

両社は長い協業を通じて、HEATTECHやAIRismなどの商品を展開してきました。2025年の統合報告書は、Recycled DownやPUFFTECHも含めて紹介しています。

同報告書では、顧客から得た要望を商品企画や素材・機能の改良へ戻す仕組みも説明されています。確認したいのは、提携の年数だけでなく、販売後の反応を次の商品へ生かす方法です。

この事例から移すべきなのは、顧客の反応を次の素材・商品開発へ戻す仕組みです。 ユニクロは生活者への商品企画と販売接点を持ち、東レは素材の研究開発と供給能力を持ちます。

つまり、両社の資産は同じではなく、顧客へ届く一つの商品を作るために補完しています。

出典：ファーストリテイリング「UNIQLO and Toray Celebrate The Art and Science of LifeWear」、同社「Annual Report 2025」

長期提携を自社へ移すときの3点

第一に、双方の目的を抽象語で終わらせません。たとえば、「新しい価値を作る」ではなく、どの顧客の、どの利用場面を、どの性能や体験で変えるかを置きます。

また、顧客が選ばなかった理由も開発へ戻せるよう、販売後の情報経路を決めます。

第二に、共同開発と量産・供給を分けて考えます。というのも、試作品で性能が出ても、品質、原価、調達、供給量が成立しなければ継続的な商品にはならないからです。

そのため、検証段階から、将来の供給条件を誰が持つか確認します。

第三に、一回の成功を完成形にしません。むしろ、新しい顧客の反応、利用環境、競合、コストに合わせて、次の商品や素材へ問いを更新します。

その際、長期契約を先にまねるのではなく、まず一往復の学習が成立するかを小さく確かめてください。

向いている案件と注意点

この型は、技術と顧客接点が別企業にあり、継続的な改良で価値が高まる案件に向きます。一方、相手から完成品を受け取るだけの発注や、自社が顧客の事実を返せない関係には向きません。

最初の共同検証では、「顧客の事実→要求仕様→試作品→顧客の事実」という一往復を設計します。各工程の担当、使用できるデータ、判断日を決め、一往復で次の投資判断に必要な証拠が得られるかを確認します。

Possi｜共同開発の成果と、販売終了までの経緯から学ぶ

京セラ、ライオン、ソニーによるPossiは、顧客課題に必要な機能を複数社へ分けた事例です。2019年7月の公式発表では、子どもの仕上げ磨きを楽しくするという具体的なコンセプトのもと、音楽が聞こえる仕上げ磨き用歯ブラシを共同開発しました。

京セラは圧電セラミックの技術、ライオンはオーラルケア製品の知見を提供しました。さらに、ソニーはStartup Acceleration Programを通じて事業化の知見を提供し、デザインや音楽面でも支援しています。

このように、技術、業界知見、体験設計、事業化支援が、顧客の一つの困りごとへ結び付いています。

役割分担は会社名ではなく、顧客価値を成立させる機能で書きます。 「大企業」「スタートアップ」「大学」といった属性だけでは、会議の出席者は決まっても、誰が何を完成させるかは決まりません。

出典：ソニー「京セラ、ライオンが共同開発 仕上げ磨き専用ハブラシ『Possi』」

機能分担を設計する順番

最初に顧客の行動変化を一つ置きます。たとえばPossiの事例なら、製品カテゴリーから始めるのではなく、「子どもが嫌がる仕上げ磨きの時間を変える」という課題が軸です。

そこから、音を伝える技術、口腔ケアとしての成立性、楽しい体験、事業化の進行という必要機能を逆算できます。

次に、各機能の責任者と受け渡し条件を決めます。たとえば、技術部門が試作したものを、どの状態で商品企画へ渡すのか、業界知見を持つ側がどの品質条件を確認するのか、デザインは見た目だけでなく利用行動のどこを変えるのか、といった機能間の境界を具体化します。

需要確認の結果も公表されています。ライオンの統合報告書2020（54頁）によると、2019年のクラウドファンディングでは、支援者1,344名から2,183万8,700円が集まり、目標の2,000万円を上回りました。

顧客の反応を得た成果ですが、利益や継続購入の実績ではありません。

需要確認ができても、事業を継続する条件は別に確かめる

京セラの開発者インタビュー（2021年3月）では、クラウドファンディング後に、想定より母親の反応が多かったため売り方の再検討が必要になったと説明されています。また、移管予定の事業部門がコロナ禍の影響を受け、計画が白紙になりました。

そこで研究開発本部での事業化を経営陣に提案し、2020年10月には新しい事業推進部を設けています。

その後、京セラは2023年2月28日での販売終了を案内しました。終了告知には理由の説明がないため、採算や各社の役割を原因と決めつけることはできません。

Possiから学べるのは、共同開発と初期の需要確認ができても、事業化の担当、販売方法、継続提供の条件は別に整える必要があることです。既存部門へ渡す方法だけでなく、新しいチームで担う選択肢も考えます。

自社で使うなら役割表を1枚にする

役割表には、会社名だけでなく、提供物、利用条件、期限、受け手、完了条件を書きます。たとえば「A社：技術提供」ではなく、「A社の担当者が試験環境で動く試作品を作り、B社の品質担当が評価できる記録とともに指定日までに渡す」とします。

各社の期待も書いてください。たとえば、大企業は新しい顧客価値を求め、スタートアップは市場機会や実証環境を求め、大学は研究成果と社会実装の両立を求める場合があります。

というのも、期待を隠したまま作業だけを分けると、成果の評価や権利の交渉で止まるからです。

三井不動産｜オープンイノベーション成功事例に見る共創基盤

三井不動産の31VENTURESは、個別の共同開発だけでなく、複数の案件を生み、育て、既存事業や新規事業へつなぐ基盤の事例です。同社の公式サイトは、CVC、ワークスペース、コミュニティの3つの機能を通じ、スタートアップとの共創、既存事業の強化、新規事業開発へ取り組むと説明しています。

2025年10月には、150億円と50億円の2つのCVCファンド、合計200億円の新設を発表しました。同時に、事業領域別チームを設け、必要に応じて担当を柔軟に組み合わせながら、企画・投資・実装を一体で進める方針を示しています。

200億円はファンドの規模であり、協業から生まれた売上や利益ではありません。

共創基盤は案件を集める入口だけでなく、事業部へ渡す出口まで設計します。 面談会、コンテスト、アクセラレーターを実施しても、顧客、販売、設備、データを扱う担当と予算が決まらなければ、実装は進めにくくなります。

既存部門が受け取るか、新チームが担うかを決めます。

出典：三井不動産「イノベーション推進本部」、同社「総額200億円のCVCを新設」

CVC・場・コミュニティを目的で分ける

CVCは資金と投資判断、ワークスペースは活動の場所、コミュニティは出会いと知見の循環を支えます。ただし、三つをそろえること自体が目的ではありません。

むしろ、自社の共創で詰まっている機能を特定し、それを補う仕組みを置きます。

案件の数が少ないなら探索の入口が必要です。一方、候補はあるが共同検証へ進まないなら、問いと資産を整理する伴走が必要です。

そして、PoCは終わるが事業化しないなら、事業部の受入責任者、追加予算、品質や法務の確認時期が必要です。

専任組織と既存部門を二重化しない

共創の専任組織は、外部探索、候補評価、契約、検証進行の専門性を持ちます。しかし、事業部が持つ顧客課題や運用条件を代替する組織ではありません。

専任組織だけが詳しくなり、事業部が最後に審査する構造では、引き渡し時に前提が崩れます。

検証の初期から、事業部の受入責任者を一人置きます。毎回の会議へ全員を参加させる必要はありませんが、どの証拠が得られたら次段階を受け取るか、追加資源を誰が申請するか、受け取れない条件は何かを決めます。

5つの確認点を、共同検証の合意シートにまとめる

成功事例の5条件を実務へ移すには、一枚の「共同検証の合意シート」にします。これは、複数社の間で受け渡す問い、資産、証拠、判断、権利、次の行動をまとめた設計表です。

共同検証の合意シートを使い、契約・検証・事業化の担当が、同じ前提で判断できるようにします。 共同検証で使う資産と評価基準が、次の権利処理や事業部移管までつながります。

共同の問いは一文にします。たとえば、「新しいサービスを共創する」ではなく、「対象顧客が特定の場面でこの方法を使い、現在の作業を減らせるか」のように、観察できる変化を書きます。

もし問いが複数ある場合は、主判断と補助判断を分けます。

提供資産には、実際に使える範囲を書きます。たとえば、「顧客基盤を提供」だけでは、顧客名を共有できるのか、面談を設定できるのか、検証場所を使えるのかが分かりません。

同様に、データも、項目、匿名化、利用環境、保存期間、削除責任まで決めます。

知財と契約は出口から逆算する

契約は、共同検証を始めるための手続だけではありません。既に各社が持つ背景知財、共同で生まれる成果、利用できる領域、独占・非独占、第三者への利用、終了後の扱いを、事業化の選択肢と一緒に考えます。

特許庁のオープンイノベーションポータルでは、秘密保持、PoC、共同研究開発、ライセンスなど、段階別のモデル契約書が公開されています。ひな形をそのまま埋めるのではなく、今回の問い、提供資産、成果の使い方に合わせて専門家と調整してください。

知財担当や法務担当を最後の承認者にすると、検証後に利用範囲や権利条件が合わず、事業化が止まることがあります。扱う技術・データが決まる時点、顧客へ提供する時点、範囲を広げる時点で参加してもらいます。

判断日と次段階条件を先に置く

共同検証の会議日程だけでなく、投資判断の日を決めます。そのうえで、判断日に必要な証拠、選べる選択肢、各社の承認者を対応させます。

また、結果が基準を満たさない場合の修正・終了も、開始前に置きます。

PoCから事業化へ進む方法では、検証後に顧客、収益、運用、体制を引き継ぐ方法を整理しています。共同検証の合意シートの次段階欄を、この移行計画へつないでください。

事例を自社の実行計画へ移す5ステップ

他社事例を自社へ移すときは、事例の施策を丸ごとコピーしません。現在の案件で詰まっている意思決定を特定し、その判断を動かす最小単位だけを借ります。

事例調査の成果物は事例集ではなく、次の共同検証を始められる実行計画です。 次の5ステップで、調べる活動を、担当と期限のある計画へ変えます。

この順番で進めると、調査の途中でも「次の判断に使わない情報」を止められます。各ステップの成果物を一枚の共同検証の合意シートへ集約し、更新した箇所と判断理由を残してください。

ステップ1｜先に判断テーマを決める

「成功事例を調べる」では、調査範囲が広がります。そのため、相手候補を選ぶのか、PoCへ進むのか、事業部へ移管するのか、追加投資するのかを先に決めます。

こうして判断テーマが決まれば、必要な事例と情報も絞れます。

判断者へ、事例の説明を何ページ用意すべきか聞く必要はありません。むしろ、どの選択肢で迷っているか、決めるために足りない証拠は何かを確認します。

そのうえで、事例は、その証拠の取り方や条件設計を検討する材料にします。

ステップ2｜不足機能が近い事例を選ぶ

自社と同業の事例だけを探すと、商品や規制の違いに目が向き、構造を見落とします。顧客接点がない、技術がない、事業化人材がいない、意思決定が遅い、既存部門へ渡らないなど、不足機能を一つ選びます。

最初は2〜3件を目安にし、判断に必要な情報が足りなければ追加します。一つの企業だけで一般化せず、共通の列で比べ、各事例から借りる最小単位を一行で書きます。

ステップ3｜事実・解釈・自社設計を分ける

公式発表に書かれた事実と、記事や社内での解釈を同じ欄に置かないでください。「共同開発した」は事実でも、「強い信頼関係が成功理由だった」は公開情報だけでは判断できない場合があります。

事例台帳では、資料名、発行主体、発行日、確認日、到達点を記録します。そして、その右に、自社が読み取る条件と、自社で試す設計を別々に書きます。

こうすることで、有名企業の名前を根拠にした企画ではなく、自社の条件に基づく検証になります。

ステップ4｜自社の制約へ置き換える

たとえば、自社の顧客へアクセスできるのは誰か、試作品を本番環境へ入れる審査に何日かかるか、データを社外へ出せるか、追加予算を誰が決裁するか、といった事例にはない自社固有の制約を共同検証の合意シートへ追加します。

うまく進んだ企業のスピードだけを目標にすると、承認や品質の条件を飛ばしやすくなります。そのため、必要な審査を減らすのではなく、いつ、何を持って審査するかを早く決めます。

あわせて、回答期限と差し戻し時の担当も置きます。

ステップ5｜次の一往復だけを実行する

全面提携や長期契約を最初の成果にしません。代わりに、一人の顧客、一つの利用場面、一つの技術条件など、次の判断に必要な最小単位へ絞ります。

そして、期間ではなく、何を確かめたら終わるかを決めます。

検証後は、成功・失敗という感想ではなく、次の選択肢を決めます。事業化へ進む、条件を変えて再検証する、対象を縮小する、終了するのいずれでも、担当、資源、期限、次回判断日を残します。

終了を選んでも、事前に決めた基準に沿って投資を止め、知見を次へ残せれば共同検証は機能しています。成果を過大に見せるために基準を変えず、判断時点の証拠と理由を残してください。

停滞した共創を立て直す方法

すでに協業候補との面談、PoC、共同開発が始まっていても、すぐに相手を替える必要はありません。5条件のどこが切れているかを見つけ、共同の問いと次の判断を最小単位へ戻します。

活動量を増やす前に、次の判断を止めている条件と、その確認担当を特定します。 面談数、提案件数、会議回数を増やす前に、次の表で症状と修正箇所を対応させてください。

最も近い症状を一つ選び、右端の修正だけを次の会議で決めます。複数の問題を一度に直すより、次の判断を止めている接続から順番に解消する方が、役割と期限を明確にできます。

問いがないとき

次の会議で、対象顧客、課題、確かめる事実を一つに絞ります。そのうえで、現在の活動を、その問いへ必要なものと止めるものへ分けます。

なお、候補企業の比較表は、問いが固まってから作り直します。

相手へ期待するだけになっているとき

自社が出せる資産を具体化します。たとえば、顧客紹介なら人数や条件、設備なら利用日時と責任者、データなら項目と利用環境まで書きます。

そして、相手が自社と組む理由が一文で説明できなければ、協業条件を見直します。

PoCが終わらないとき

結果を評価しないままPoCを延長せず、判断に足りない事実を特定します。再現性を確かめるため同じ試験を繰り返す場合も、目的と必要な回数を決めます。

そのうえで、新しい問い、方法、費用上限、終了基準、判断日を持つ追加検証として切り分けます。なお、PoC後の停滞要因はオープンイノベーションの失敗事例も参照してください。

事業化を担う部門が決まらないとき

事業化に最も必要な部門を一つ選び、次の検証の受け手として参加してもらいます。協力を善意に依存させず、受け取る成果物、回答期限、必要工数、部門側の目的を合意します。

開始前と各判断日に確認する

次のチェックは、担当者だけでなく、相手側の責任者、社内の受入部門、判断者と共有します。Yes・Noだけで終わらせず、根拠になる文書、担当者、期限を記入してください。

チェックの結果、複数の不足が見つかっても、一度に全面改定しません。むしろ、次の判断を最も妨げている条件から直します。

たとえば、問いが曖昧なら契約の詳細化より問いを先にし、本体の受け手がいないならPoCの追加機能より移管条件を先にします。

顧客への販売経路まで含めて見直す場合は、新規事業の販売チャネルも参照してください。共同開発した価値を、誰がどのチャネルで届け、顧客の反応を誰が次の改良へ戻すかまで決めます。

オープンイノベーション成功事例に関するよくある質問

成功事例を探す範囲、成果の判断、大学やスタートアップとの役割分担など、実務で迷いやすい点を整理します。

Q. オープンイノベーションの成功は何で判断しますか

A. 提携数やPoC数だけでなく、共同の問いに答える証拠が得られ、Go・修正・終了を判断でき、次の担当と資源が動いたかで判断します。共同開発、市場投入、継続販売、拡大は別の到達点として記録してください。

Q. 成功事例は何件調べれば十分ですか

A. 一つの判断テーマにつき2〜3件を目安にします。件数より比較軸が重要です。問い、提供資産、小さな検証、判断、事業化体制を同じ列で比べ、自社へ移す設計を一つずつ決めます。

Q. 自社と同業の成功事例を選ぶべきですか

A. 同業事例は規制や商流を理解するのに役立ちますが、不足機能が近い異業種事例も有効です。顧客接点、技術、事業化人材、意思決定、販売など、現在の案件で不足する機能を基準に選んでください。

Q. 大学とのオープンイノベーションにも5条件を使えますか

A. 使えます。ただし研究と事業では目的、時間軸、成果の扱いが異なります。共同の問い、研究成果を受け取る事業部、背景知財と成果知財、発表、利用権、判断時期を早い段階で具体化します。

Q. スタートアップ側から見た成功条件も同じですか

A. 基本は同じです。事業会社は顧客、設備、販路、品質条件、判断周期を示し、スタートアップは技術、速度、人員、資金、提供できない範囲を示します。一方だけが相手へ適応を求めず、双方の利点と制約を共同検証の合意シートへ書きます。

まとめ｜オープンイノベーション成功事例を自社の条件へ変える

オープンイノベーション成功事例から移すのは、企業名や提携形式ではありません。共同の問い、補完資産、小さな検証、判断の共有、事業化体制という5条件です。

最初の一歩は、次の案件について「誰の何を共同で確かめ、各社が何を出し、いつ誰が判断するか」を一枚にすることです。 その一枚を事業部、法務・知財、相手側の責任者と確認し、次の一往復だけを実行します。

成功事例を調べる目的を「説明材料の収集」から「自社の次の判断」へ変えると、事例は行動へつながります。進行中の共創が止まっている場合も、5条件のどこが切れているかを見つけ、問いと次段階条件から接続し直してください。