Edge Runtimeに全乗っかりした事業の致命傷
「月間のサーバーコストは1,200円です」── 創業3年目、月商800万円のSaaS創業者がDD資料の冒頭でこう自慢する。実際、財務諸表のサーバー関連費目は驚くほど低い。Cloudflare Workers・Vercel Edge Functions・Deno Deployといったエッジランタイム上に全アプリケーションを構築し、コールドスタートゼロ、グローバル分散、自動スケーリング、無料枠の活用で、固定費としてのサーバーコストはほぼゼロに抑え込まれている。バリュエーション上は驚くほど効率的に見える事業構造だ。
しかし、買収後の事業統合期に、買い手側のインフラチームが本格的な負荷予測を行うと、別の風景が立ち上がる。月間リクエスト数が現在の10倍に増えた瞬間、リクエスト単価とCPU時間課金が線形ではなく指数的に積み上がり、当初想定の数十倍のコスト構造に化ける。さらに重要な処理はエッジランタイムの実行時間制限に阻まれ、結局バックエンドにNode.jsサーバーを別途立てる羽目になり、「エッジで全部完結する」という設計思想そのものが破綻している状態が、買収後に露呈する。
本稿では、Edge Runtimeに全面依存した事業のバリュエーション上の取り扱いを、買い手側の視点から正面から扱う。リクエスト単価のスケール非線形性、実行時間制限と機能制約による技術的負債、ベンダーロックインと移管不可能性──この3つの致命傷が、買収後の事業継続コストを当初想定の何倍にも膨らませる構造を、現場感覚で解剖する。読み終える頃には、「月間サーバーコスト1,200円」というセリフを聞いた瞬間に警戒できるようになるはずだ。
1. Edge Runtimeの普及と「最強コスト構造」神話
1-1. 2024〜2026年に起きた「とりあえずエッジ」の流行
Cloudflare Workers、Vercel Edge Functions、Deno Deploy、Netlify Edge Functions、Bun Cloud──2024年から2026年にかけて、エッジランタイム系の実行基盤が急速に普及した。これらは「リクエスト数に応じた完全従量課金」「グローバルに分散された自動スケーリング」「コールドスタートゼロ」という魅力的な特徴を持ち、MVP立ち上げや小規模SaaSにおいて圧倒的なコスト効率を実現する。
2024年以降のスタートアップ創業者の間では、「とりあえずVercelに乗せて、APIはEdge Functionsで動かす」という構成が事実上の標準になった。サーバー運用の手間を一切考えず、純粋にプロダクト開発に集中できる──この発想は、特に非エンジニア創業者や少人数チームにとって、開発スピードを劇的に向上させた。
1-2. 「サーバーコスト1,200円」という財務諸表上の魔法
Edge Runtime構成の最大の特徴は、月間サーバーコストが文字通り数百〜数千円のレンジに収まることだ。Cloudflare Workersの無料枠は1日10万リクエスト、Vercelのホビープランも一定範囲まで無料で、商用利用でも月数千円規模で全インフラがまかなえる。これは2010年代のAWS EC2インスタンス課金とは桁違いの効率性であり、「インフラ費がほぼゼロのSaaS」を成立させる構造だ。
財務諸表の上では、これは粗利率を押し上げ、EBITDA率を異常に高く見せる効果がある。月商800万円・粗利率92%・EBITDA率45%、というSaaS創業者の自慢の数字が、Edge Runtimeの恩恵によるものであるケースが2026年現在の市場では珍しくない。買い手から見れば「非常に効率的な事業」に映るが、ここに重大な落とし穴が潜む。
1-3. 「神話」が崩れる構造的境界線 ── スケール、複雑性、ベンダー依存
Edge Runtimeの効率性は、特定の条件下でのみ成立する。具体的には「リクエスト数が無料枠〜低従量課金の範囲に収まる」「処理ロジックがエッジランタイムの制約（実行時間、メモリ、ライブラリ）に収まる」「特定ベンダーへの完全依存を許容できる」の3条件だ。買収後の事業がこれら3条件のうちいずれかを超えた瞬間、コスト構造が指数的に悪化し、最強コスト構造の神話は崩壊する。
本稿で扱う3つの致命傷は、いずれもこの境界線を超えた時に発動する構造的問題だ。事業の成長に応じて自然に発動するため、買収後12〜24か月以内に顕在化することが多い。これは「いつか発動する潜在負債」であり、バリュエーション評価において必ず織り込むべき要素だ。
2. 致命傷1：リクエスト単価のスケール非線形性
2-1. 無料枠と従量課金の境界 ── 10倍スケールで100倍コスト
Edge Runtimeの課金構造は、無料枠を超えた瞬間に従量課金がフルで適用される設計になっている。Cloudflare Workersの場合、無料プランから$5/月の有料プランに移行した瞬間、リクエスト10万件以降は$0.50/100万リクエスト、CPU時間は$0.02/100万CPU msという課金が発生する。一見すると安いが、リクエスト数が増えると総コストが非線形に積み上がる。
具体的には、1日10万リクエストの事業が成長して1日100万リクエストになった場合、リクエスト単価だけで月額$15、CPU時間課金を含めると月額$50〜$200のレンジに入る。さらに1日1,000万リクエストになると、月額$500〜$2,000のレンジに化ける。「10倍にスケールしたら100倍コストになる」という体験が、Edge Runtime事業の買収後にしばしば発生する。
2-2. 隠れたCPU時間課金 ── リクエスト数だけでは予測できない
Edge Runtimeの課金で見落とされがちなのが、CPU時間課金だ。1リクエストあたりの処理が単純なルーティング・キャッシュ参照で済むなら、CPU時間は数msで完了し課金は軽い。しかし、JSONパース・データ変換・複雑な認可判定・外部API呼び出しを含むリクエストでは、1リクエストあたり100〜500msのCPU時間を消費することがある。
事業の機能が拡張され、1リクエストあたりの処理ロジックが複雑化すると、リクエスト数は変わらなくてもCPU時間課金だけが指数的に膨らむ。買収後に新機能を追加した瞬間、月額コストが3倍に化けるというケースが起きる。これはバリュエーション時のキャッシュフロー予測には絶対に反映されない、隠れたコスト因子だ。
2-3. 地理分散の代償 ── グローバル展開で発生するリージョン別課金
Edge Runtimeはグローバル分散が標準で、リクエストはユーザーに最も近いエッジロケーションで処理される。しかしVercelやCloudflareは、特定リージョン（特に北米外）からのリクエストに対して、リージョン別の追加課金やデータ転送量課金を適用するプランが増えている。
事業がグローバル展開し、アジア・欧州・南米のユーザーが増えると、リージョン別課金とデータ転送量課金が積み上がり、当初想定の3〜5倍のコスト構造に化ける。日本国内中心のSaaSであれば影響は限定的だが、グローバル展開を前提とする買収戦略では、この観点を必ずDD段階で検証する必要がある。
3. 致命傷2：実行時間制限と機能制約による技術的負債
3-1. 30秒制限の壁 ── 重い処理がエッジに乗せられない
Edge Runtimeには、1リクエストあたりの実行時間制限が設定されている。Cloudflare Workersは無料プランで10ms、有料プランで30秒、Vercel Edge Functionsは30秒、Deno Deployはプランごとに異なる制限がある。この制限を超える処理は、エッジランタイム上では実行できない。
事業が成長して機能が拡張すると、データ集計・PDF生成・大量データのインポート・複雑な検索クエリ・AI推論といった重い処理が必要になる。これらは多くの場合30秒制限を超えるため、エッジランタイムでは処理できず、結局Node.jsサーバー・サーバーレス関数（AWS Lambda等）・専用バックエンドを別途構築する必要が出る。「全部エッジで完結する」という設計思想が、機能拡張の過程で必然的に破綻する。
3-2. ライブラリ・依存の制約 ── Node.js APIの一部が使えない
Edge Runtimeは、Node.jsとの完全な互換性を保証していない。ファイルシステムアクセス、ネイティブモジュール、一部のNode.js組み込みモジュール（`fs`、`net`、`child_process`等）が使えないことがあり、特定のライブラリがEdge Runtime上では動作しない。
事業が成長し、画像処理ライブラリ・PDF生成ライブラリ・暗号化ライブラリ・ML推論ライブラリといった専門的なライブラリを導入しようとすると、これらがEdge Runtime非対応であることが判明し、別途バックエンドを立てる必要が生じる。結果として、Edge Runtimeでスタートした事業も、半年〜1年後にはハイブリッド構成（エッジ＋通常のバックエンド）に移行することになる。
3-3. デバッグ・観測性の制約 ── 障害発生時の調査困難性
Edge Runtimeは分散実行が特徴で、リクエストが世界中のどのエッジロケーションで処理されたかが事後的に分かりにくい。障害が発生した場合、ログを集約して原因を特定する作業が、通常のサーバー構成より格段に難しい。Cloudflare Workers ObservabilityやVercel Analyticsといった専用ツールはあるが、これらは追加課金対象であり、運用コストを押し上げる。
事業が成長し、SLAの担保や顧客対応の質向上が求められるフェーズに入ると、観測性の不足が深刻なボトルネックになる。「障害が起きても原因がすぐ特定できないサービス」は、企業向けSaaSとして致命的な品質欠陥であり、買収後の信頼性向上施策に膨大なコストがかかる。
4. 致命傷3：ベンダーロックインと移管不可能性
4-1. ベンダー固有APIへの依存 ── KV、Durable Objects、Edge Config
Edge Runtimeを活用する事業は、しばしばベンダー固有の拡張機能に深く依存する。Cloudflare Workersの場合、KV（Key-Value Store）、Durable Objects、R2 Storage、D1 Database、Queues、AI Gateway。Vercelの場合、Edge Config、Vercel KV、Vercel Postgres、Vercel Blob。これらは便利だが、別のベンダーには移植できない。
事業が成長して、料金体系・機能制約・SLAの観点から別のクラウドへ移行したいと考えた時に、これらのベンダー固有機能がボトルネックになる。移行を試みると、コードベースの30〜70%を書き直す必要があると判明するケースが多く、結果として「動いているから動かさない」という意思決定を強いられる。これはベンダーロックインの典型的な構造だ。
4-2. 価格改定への防御策がない ── ベンダーの裁量による事業価値毀損
Edge Runtime事業者は、過去にも何度か価格改定を行っている。Cloudflareは2024年に一部プランで無料枠を縮小し、Vercelは2025年に複数プランで従量課金単価を引き上げた。これらの価格改定は、ベンダー側の経営判断であり、利用事業者側は基本的に受け入れるしかない。
事業のコスト構造が単一ベンダーに完全依存している場合、ベンダーの価格改定が直接的に事業の利益率を毀損する。買収後、Vercel/Cloudflareが価格改定を行うリスクは、買い手側にとって完全にコントロール不可能な外部要因だ。バリュエーション時には、この不確実性を割引率に反映する必要がある。
4-3. サービス停止・撤退リスク ── スタートアップエッジベンダーの危うさ
Cloudflare・Vercelのような大手は撤退リスクが低いが、Bun Cloud・Fly.io・Deno Deployといった中小エッジベンダーは、事業継続性のリスクが相応にある。これらのベンダーが事業撤退・サービス停止・大幅な機能変更を発表した場合、利用事業者は数か月以内に移行作業を強いられる。
事業のコア機能を中小ベンダーに依存している事業は、ベンダー側の経営状況も含めた事業継続リスクを抱えており、買い手から見れば「重大なリスクファクター」として価格交渉の根拠になる。
5. バリュエーション補正の実務 ── 「コスト想定の再計算」
5-1. スケール後のコスト構造を試算する ── 10倍・100倍シナリオ
Edge Runtime事業を買収する際に必ず実施すべきは、スケール後のコスト構造の再計算だ。具体的には、現在の月間リクエスト数を10倍・100倍にしたシナリオで、リクエスト単価・CPU時間課金・データ転送量課金・ベンダー固有機能の課金を再集計する。多くの場合、現在の月額コストが100倍以上に化けることが判明する。
この試算結果を将来CFモデルに反映すると、買収時のEBITDA率は実際よりも数ポイント低下する。「月商800万円・EBITDA率45%」という現在の数字が、スケール後には「EBITDA率25〜30%」に下方修正されるのが現実的なシナリオだ。これは事業価値を3〜5割減らす要因になる。
5-2. ハイブリッド構成への移行コストを織り込む ── 「結局バックエンドが必要」
Edge Runtime事業は、買収後の機能拡張・スケール対応に伴い、通常のサーバー構成（AWS、GCP、自社サーバー）へのハイブリッド移行が必要になる確率が高い。この移行コストを事前に試算し、買収価格から差し引いて交渉する。
移行コストの内訳は、新インフラ構築（100万〜500万円）、コードベースの一部書き直し（300万〜2,000万円）、データ移行・同期メカニズム構築（200万〜1,000万円）、運用体制の構築（人件費月50万〜200万円）、合計で1,000万〜5,000万円のレンジが現実的だ。
5-3. ベンダー価格改定リスクをDCFの割引率に反映する
Edge Runtime事業のキャッシュフロー予測には、ベンダー価格改定リスクを反映した割引率の上乗せが必要だ。通常のSaaS事業のDCF（割引キャッシュフロー）モデルで用いる割引率に、ベンダーロックイン分として1〜2ポイントの追加割引率を加えることで、リスクを適切に織り込める。
これは保守的な評価方法だが、買収後にベンダーの価格改定で事業の利益率が毀損するリスクを定量化する有効な手法だ。「ベンダーが値上げしたら利益率が落ちる」という定性的な懸念を、定量的な評価補正に翻訳する──これが買い手側の技術的DDの価値だ。
結論：Edge Runtimeは「便利な毒」、スケール後の構造を直視する
Edge Runtimeは、小規模事業や初期フェーズのスタートアップにとって、まさに革命的なコスト構造を提供する。月額数千円で全インフラがまかなえる構成は、開発スピードと収益性の両面で他に類を見ない優位性を生む。しかし、この優位性は事業の成長に伴って徐々に失われ、ある境界線を超えた瞬間、致命的なコスト膨張・機能制約・ベンダーロックインとして事業価値を毀損する。
Edge Runtime事業のM&Aにおいては、現在のコスト構造の効率性に惑わされず、スケール後のシナリオを冷静に試算する技術DDが不可欠だ。売り手側は、出口戦略を見据えてハイブリッド構成への計画的な移行を進める。買い手側は、スケール後のコスト膨張・機能制約・ベンダーロックインを定量化し、買収価格に正しく織り込む。これがエッジ時代のSaaS取引における、もっとも実務的な誠実さだ。
