ノーコード事業に値段はついても、移管できない
「月商400万円、開発費ほぼゼロ、運用は私一人。Bubbleで作ったので保守も簡単です」── ノーコードで構築されたサービスのM&Aは、財務的には魅力的に見える。売上があり、利益率が高く、運用負荷も小さい。仲介の査定も「EBITDAの何倍」で素直に値段がつく。しかし買い手のエンジニアが最初に問うのは、「そのBubbleアプリ、買収後に私たちが独立して所有・改変・拡張できますか」だ。多くの場合、答えは「いいえ」になる。
ノーコード事業の本質的な論点は、「値段はつくが、移管できない」という非対称性にある。財務指標は事業の収益力を正しく映すが、その収益を生んでいる「資産」が、Bubble・STUDIO・Webflowといった特定プラットフォームの内部に閉じ込められており、買い手がプラットフォームから切り離して独立に所有することができない。これは、本連載で扱ったVibe Codingの「資産価値ゼロ」とは別種の、プラットフォーム依存に起因する移管不能性の問題だ。
本稿では、ノーコード事業がなぜ移管できないのか、プラットフォームごとのロックインの実態、移管不能性を前提としたバリュエーションの組み立て方、そしてノーコードでも価値が成立する条件を、買い手・売り手双方の視点で整理する。
1. 「値段はつくが移管できない」という非対称性
1-1. 収益は本物、資産はプラットフォームの中
ノーコード事業の収益は本物だ。実際に顧客が金を払い、サービスが価値を提供している。この収益力に財務的な値段がつくのは正当だ。問題は、その収益を生み出している仕組み ── アプリのロジック、データモデル、UI、ワークフロー ── が、プラットフォームの独自形式で記述され、その内部にしか存在しないことだ。
通常のコードであれば、リポジトリを引き継げば別の環境で動かせる。しかしノーコードで作られたロジックは、ソースコードとして取り出せない。エクスポートしても、それは別の環境で動くものではない。買い手が手にできるのは「プラットフォームのアカウントへのアクセス権」であって、「独立して動かせる資産」ではない。この非対称性が、ノーコード事業の評価を難しくする。
1-2. 所有権の実態 ── プラットフォームが事業を握る
ノーコード事業では、プラットフォーマーが事業の存続を実質的に握る。プラットフォームが価格を上げれば原価が上がり、機能を廃止すれば事業が壊れ、サービスを終了すれば事業そのものが消滅する。買い手は事業を「買った」つもりでも、その事業はプラットフォームの提供が続く限りにおいてのみ存在する。
これは本連載のEdge Runtime依存（#39）やLLM依存（#41）と同じ構造だが、ノーコードはさらに深い。コードがあれば最悪は移植できるが、ノーコードはロジックそのものがプラットフォーム固有で、移植には「別の基盤で一から作り直す」しかない。ノーコード事業の所有権は、プラットフォームへの従属を前提とした、条件付きの所有権だ。
2. プラットフォーム別ロックインの実態
2-1. Bubble ── ロジックとデータが閉じた世界
Bubbleは、データベース・ワークフロー・UIをビジュアルに構築できる強力なプラットフォームだが、構築したものはBubbleの中でしか動かない。アプリのロジックはBubble独自のワークフロー形式で記述され、ソースコードとしてエクスポートできない。データはCSV等で取り出せるが、それはデータであってアプリではない。
Bubble上のアプリを別環境に移すには、要件を読み解いて別の技術スタックで再実装するしかない。これは新規開発と同等の工数だ。「Bubbleで作ったから簡単」という認識は、作るのが簡単であることと、移すのが簡単であることを混同している。Bubble事業の移管は、実質的に再構築を意味する。
2-2. Webflow ── 静的部分は出せても動的部分は残る
Webflowは、デザインとマークアップをエクスポートできる点でBubbleより開かれている。HTMLとCSSを書き出せるため、見た目は別環境に移植可能だ。しかし、CMSのコンテンツ管理、フォームの送信処理、会員機能、Eコマース、各種インタラクションのバックエンドは、エクスポートしたHTMLには含まれない。
つまり、Webflowで作ったサイトの「見た目」は移せても、「動き」と「データ管理」はWebflowに残る。動的機能に依存している事業ほど、エクスポートの価値は限定的になる。「Webflowはエクスポートできるから安心」という説明は、何がエクスポートでき、何ができないかを正確に区別していない。
2-3. STUDIO・国産ノーコード ── 言語と契約のローカル性
STUDIOをはじめとする国産ノーコードは、日本語UIとサポートで普及しているが、エクスポート性やAPI連携の自由度はプラットフォームごとに大きく異なる。海外大手と比べて利用者コミュニティや移行ノウハウの蓄積が薄い場合、移管時に頼れる情報が少ない。
また、プラットフォームの事業継続性 ── 運営会社の財務的安定性、サービス継続のコミットメント ── も評価対象になる。規模の小さいプラットフォームに依存した事業は、プラットフォーム自体の存続リスクを、事業のテールリスクとして抱える。本連載のEdge Runtime回で扱った「小規模ベンダーのexitリスク」と同じ論点が、ノーコードにも当てはまる。
3. 移管不能性を前提としたバリュエーション
3-1. 再構築コストを減点として織り込む
ノーコード事業の評価では、「プラットフォームから独立したい場合の再構築コスト」を見積もり、これを減点要因として織り込む。事業の規模・複雑度に応じて、別スタックで同等機能を構築する工数と期間を試算する。この再構築コストが大きいほど、プラットフォームへの従属度が高く、移管不能性のリスクが大きい。
ただし、買い手が「プラットフォームに乗ったまま運営し続ける」前提であれば、再構築コストは顕在化しない。重要なのは、プラットフォーム継続を前提とした価値と、独立性を求めた場合の価値を、分けて評価することだ。後者を求めるなら、再構築コストとプラットフォーム退出計画を価格に反映する。
3-2. 価値の重心を「ビルド」から「顧客・ブランド・データ」へ移す
ノーコード事業では、技術的な「ビルド（構築物）」に資産価値を置くのではなく、価値の重心を顧客基盤・ブランド・蓄積データに移して評価するのが現実的だ。これは本連載のVibe Coding回（#37）と共通する考え方だ。ビルドが移管できなくても、顧客リスト、ドメイン、ブランド認知、蓄積データは引き継げる。
この観点では、ノーコード事業の価値は「作り直せる程度のビルド＋移管可能な顧客・ブランド・データ」として再定義される。ビルドの再現が容易（ノーコードなら作り直しも比較的速い）であることは、見方を変えれば、ビルドに固有価値が少ないということでもある。価値は、プラットフォームに依存しない部分に宿る。
4. ノーコードでも価値が成立する条件
4-1. プラットフォーム依存が許容できる事業特性
ノーコードが減点一辺倒というわけではない。事業の性質によっては、プラットフォーム依存が合理的な選択であり、価値も毀損しない。マーケティングサイト、ランディングページ、小規模な業務ツール、検証段階のMVPなど、スケール要件や独自性の要求が低い領域では、ノーコードの開発速度とコストの優位が、移管不能性のリスクを上回る。
重要なのは、事業の中核ロジックがノーコードに乗っているか、それとも周辺機能だけかだ。中核がノーコードに乗っている事業は移管不能性のリスクが高く、周辺だけなら影響は限定的だ。DDでは、どの機能がどのプラットフォームに依存しているかを切り分けて評価する。
4-2. アカウント移管とプラグイン依存の確認
プラットフォームに乗ったまま運営を続ける前提でも、アカウントの所有権移管は必須だ。プラットフォームのアカウント名義、プラン、カスタムドメイン、決済連携が旧オーナーに紐づいたままでは、買い手は運営を引き継げない。プラットフォームごとにアカウント移管の可否と手順を確認する。
また、ノーコードに追加されたカスタムコードやプラグイン（外部連携、独自スクリプト）は、それ自体が依存とブラックボックスになり得る。「ノーコードだから中身がシンプル」とは限らず、プラグインやカスタムコードで複雑化している事業もある。これらの棚卸しもDDに含める。
5. バリュエーションとチェックリスト
5-1. 移管可能性とプラットフォームリスクの評価
ノーコード事業の評価軸は、①中核機能のプラットフォーム依存度、②独立を求めた場合の再構築コスト、③プラットフォーム自体の事業継続性と価格改定リスク、④アカウント移管の可否、⑤顧客・ブランド・データという移管可能な価値の大きさ、だ。これらを総合し、プラットフォーム継続前提の価値と、独立志向の価値を分けて提示する。
移管不能性は、必ずしも「価値ゼロ」を意味しない。プラットフォームが安定し、事業がそれに乗り続ける合理性があるなら、収益力に応じた価値は成立する。問われるのは、移管できないという事実を認識した上で、その従属リスクを価格に正しく織り込んでいるかだ。
5-2. 買い手・売り手のチェックリスト
買い手は、①使用ノーコードプラットフォームと中核機能の依存マップ、②アカウント移管の可否と手順、③再構築コストの試算、④プラットフォームの財務安定性と価格改定履歴、⑤顧客・データのエクスポート可否、⑥プラグイン/カスタムコードの棚卸し、を確認する。
売り手は、アカウントを法人名義で整理し、データのエクスポート手順を整え、顧客基盤・ブランド・データという移管可能な価値を明示し、プラットフォーム依存の範囲を正直に開示する。「移管できない部分」と「引き継げる価値」を切り分けて提示できる売り手は、買い手の不確実性を減らし、現実的な合意に到達しやすい。
結論：移管できないものに、移管できる価値をどう見出すか
ノーコード事業は、財務的には正当に値段がつく。しかしその収益を生む仕組みは、プラットフォームの内部に閉じ込められ、買い手が独立して所有することはできない。「値段はつくが移管できない」という非対称性こそが、ノーコード事業の評価の核心だ。この非対称性を無視して財務指標だけで価格をつければ、買い手はプラットフォームへの従属リスクを見えないまま引き継ぐことになる。
買い手にとっては、プラットフォーム継続前提の価値と独立志向の価値を分け、再構築コストと従属リスクを価格に織り込むことが要諦になる。売り手にとっては、移管できないビルドと、引き継げる顧客・ブランド・データを切り分けて提示することが、現実的な評価への道になる。技術的DDの本質は、こうした「動いているが移せない」資産の性質を見極め、移管可能な価値を正しく抽出することにある。ノーコードは、その判断力が最も問われる領域の一つだ。
