2026年、買って良いスタック・買ってはいけないスタック

2026年6月3日(水) 08:00

技術スタックは保守容易性・拡張性・可観測性・セキュリティ・コスト弾力性の5軸で加点・減点され、EBITDA倍率に加点案件1.2〜1.5倍、減点案件0.6〜0.8倍の補正がかかる。売り手は減点項目の事前改善、買い手はこのスコアリングを価格交渉の根拠にできる。

「月商1,000万円のSaaS、希望売却額は3億円です」── 同じ売上規模・同じ利益率の事業であっても、その内部で動いている技術スタックが何であるかによって、買い手側が提示するバリュエーションは数千万円から、場合によっては1億円以上の幅で動く。これは仲介現場の現実であり、財務系のDDだけを行う仲介業者には永遠に見えない領域だ。

2026年の今、何が「買って良いスタック」で、何が「買ってはいけないスタック」なのか。この問いに対する答えは、単に「新しい技術ほど価値が高い」という単純な話ではない。重要なのは、「そのスタックが買収後の運営に耐え、引き継ぎ可能で、技術的負債を増殖させない構造になっているか」という観点であり、ここを見誤ると、買い手は技術的負債を高値で買わされ、売り手は本来評価されるべき技術資産を過小評価される。

本稿では、2026年現在のM&A市場で実際に観測される加点・減点ロジックを5軸（保守容易性／拡張性／可観測性／セキュリティ／コスト弾力性）に分解した上で、加点される最新スタック群、減点される負債スタック群、そして買収後の維持・拡張可能性を定量評価するスコアリングフレームワークまで、現場目線で整理する。読み終える頃には、自社の事業（売り手側）または検討中の案件（買い手側）のスタックを、5分以内にスコアリングできるようになるはずだ。

1. なぜ技術スタックがM&Aバリュエーションを数千万円動かすのか

1-1. 「売上は引き継げてもスタックは引き継げない」という業界の盲点

M&Aの財務DDは、過去3〜5年の売上・利益・キャッシュフロー・顧客数といった「過去の数字」を精査する作業だ。しかし、その数字を生み出した技術スタックが「買収後にも動き続けるか」「人が辞めても保守可能か」「機能追加に耐えるか」という未来側のリスクは、財務諸表には表現されない。

仮に月商1,000万円のSaaSが2社あり、どちらも同じ売上・同じ顧客数だとしよう。A社はTypeScript／Next.js／PostgreSQL／コンテナ化済み／IaCで再構築可能、B社はPHP5系／生のMySQL／FTPで本番デプロイ／属人的なシェルスクリプトで運用。財務上は同じ価値の事業に見えるが、買収後5年のTCO（Total Cost of Ownership）を計算すると、B社はA社の3〜5倍のコストがかかる。これがバリュエーション差として数千万円から1億円以上の幅で表れる。

1-2. バリュエーション評価の5軸 ── 加点・減点を分解する基本フレーム

技術スタックを企業価値の観点から評価する場合、本稿では次の5軸で分解する。①保守容易性（Maintainability）、②拡張性（Scalability）、③可観測性（Observability）、④セキュリティ（Security）、⑤コスト弾力性（Cost Elasticity）。それぞれの軸で「市場標準を上回るか／下回るか」を5段階評価し、加点・減点を集計する。

5軸×5段階のスコアリングで合計25点満点、20点以上は「加点案件（プレミアム評価）」、12〜19点は「標準評価」、11点以下は「減点案件（ディスカウント評価）」という運用が、実務的に最も解像度の高い分類になる。財務的なEBITDA倍率に対して、加点案件は1.2〜1.5倍、減点案件は0.6〜0.8倍のレンジで補正がかかるという経験則がある。

1-3. 「新しい技術＝高評価」ではない ── モダンの落とし穴

誤解されやすいのは、「最新のスタックを使っていればバリュエーションが上がる」という単純な構造ではないという点だ。Rust製の高性能バックエンド、Bun／Denoランタイム、最新のEdge Computing基盤などは、技術的に魅力的でも「採用市場の薄さ」が逆にリスクとして評価される。

買収後にエンジニアを採用しようとした時に、市場に該当スキル保持者が著しく少ないスタックは、属人化リスクの代表例だ。「技術的に正しい」と「事業として承継可能」は、しばしば一致しない。これがバリュエーション評価における最大の罠であり、純粋なエンジニア視点では見落とされがちな観点になる。

2. 加点される最新スタック群 ── プレミアム評価につながる10カテゴリ

2-1. 言語・ランタイム ── TypeScript / Goが「採用市場の厚さ」で勝つ

2026年時点で、バックエンドとフロントエンドの両方で安定的に加点されるのはTypeScriptだ。型安全性・採用市場の厚さ・周辺エコシステムの成熟度の3点で、引き継ぎ可能性が圧倒的に高い。バックエンド単体で見ればGoも強い加点要素で、シンプルな言語仕様・並行処理の堅牢性・コンパイル済みバイナリの運用容易性が評価される。

Pythonは依然として強い選択肢だが、用途依存になりつつある。データ処理・機械学習用途では加点、Webバックエンド用途では中立〜やや減点（パフォーマンスと保守容易性の観点）という傾向だ。Ruby on Railsは2026年現在「中立〜やや減点」のゾーンに移動しており、特に新規採用市場の縮小がボディブローのように効いている。

2-2. フレームワーク ── Next.js / Nuxt / Astroが安定加点

フロントエンド／フルスタックフレームワークでは、Next.js（React）、Nuxt（Vue）、Astroが安定的に加点される。これらはサーバーサイドレンダリング・静的サイト生成・エッジ実行のいずれも選択可能で、買収後にビジネス要件が変わっても柔軟に対応できる。SvelteKitとSolidStartは「技術的に優れているが採用市場が薄い」ゾーンで、加点幅が限定的だ。

バックエンドフレームワークでは、NestJS（TypeScript）、FastAPI（Python）、Echo／Gin（Go）が加点ゾーン。ExpressやFlaskといった「軽量だが構造化が弱い」フレームワークは、大規模化に伴うコードベース崩壊リスクとして「中規模を超えた事業では減点要素」として評価されることが増えている。

2-3. データベース ── PostgreSQL / Redis / S3互換ストレージの三位一体

RDBはPostgreSQLが2026年時点で圧倒的なデファクトだ。JSONBサポート・拡張機能の豊富さ・運用ノウハウの蓄積量で他を引き離している。MySQLも依然として通用するが、新規案件での採用率はPostgreSQLに対して劣後しつつある。SQL Serverを使っている事業は2026年において即座に減点対象で、ライセンスコストとクラウドネイティブ運用との相性の悪さが理由だ。

キャッシュ層はRedisが標準、オブジェクトストレージはS3互換（AWS S3／Cloudflare R2／Backblaze B2）が標準。これら3点が揃っている事業は、データ層の引き継ぎ容易性で加点される。MongoDBは「使いどころを選ぶ」ゾーンで、ECサイト・コンテンツ管理など特定領域では加点、汎用RDBの代替として乱用されている場合は減点という二極化が進んでいる。

2-4. インフラ ── コンテナ化 + IaC + マネージドサービスの三点セット

インフラ層で最も強い加点ロジックは、①Docker等によるコンテナ化、②Terraform／PulumiによるIaC（Infrastructure as Code）、③クラウドプロバイダーのマネージドサービス活用、の三点セットだ。これが揃っている事業は、買収後のクラウドアカウント移管・人員入れ替え・スケーリング対応がすべて「コード化された手順」として再現可能になる。

逆に、本番サーバーにSSHで入って直接編集している運用、シェルスクリプトと手作業デプロイで成立している運用、Excelで構成管理されている運用は、2026年現在において即座に「重度の減点対象」となる。これらの運用が混在している事業は、買収後3か月以内に運用が破綻するリスクが高いという経験則がある。

3. 減点される負債スタック群 ── ディスカウント評価につながる7カテゴリ

3-1. レガシー言語・フレームワーク ── PHP5系 / Perl / 旧Railsは買収後の地雷

2026年時点で明確な減点要素となるレガシー言語・フレームワークは、PHP5系（特にサポート切れバージョン）、Perl／CGIによるWebアプリ、Rails 4.x以前、CakePHP 2.x、CodeIgniter 2.xなどだ。これらは「動いてはいるが、改修できる人材が市場にほぼいない」状態で、買収後の機能追加コストが青天井になる。

特にPHP5系は、PHP 8.x以降へのバージョンアップに伴う非互換変更が多く、コードベース全体の書き換えに匹敵する工数がかかる。「動いているから問題ない」と言いながら、内部的にはバージョンアップ不可能な状態に陥っている事業は、買収後に予期せぬ大規模リファクタリング費用が発生する。これがバリュエーションの大幅減点に直結する。

3-2. オンプレ・物理サーバー依存 ── データセンター契約が承継できない罠

クラウドではなく自社のデータセンター・コロケーション・物理サーバーで運用している事業は、買収時に「データセンター契約の名義変更が必要」「移転コストが発生する」「移転に伴うダウンタイムが発生する」という追加コストが避けられない。

2010年代後半以降に立ち上がった事業でオンプレ運用を選択しているケースは稀だが、2000年代から続く老舗事業ではいまだに少なくない。バリュエーション評価では「クラウド移行コスト」として億単位の負債を計上することがあり、これは事業価値そのものを大きく毀損する。

3-3. 属人化したシェルスクリプト・cron運用 ── ドキュメントなき定期処理

本番サーバー上にひっそりと存在する、誰が書いたかも分からないシェルスクリプト群とcronジョブ群は、買収後の地雷原だ。これらが「月次の売上集計」「メールマガジン配信」「在庫同期」「請求書発行」といった事業の根幹を支えていることがある。

属人的な運用は、書いた本人が退職または引き継ぎを拒否した瞬間に事業の連続性が崩壊する。買収交渉中に「creator固有の知識」を開示資料に含めない売り手は、買い手から大きな減点を受ける。これは別記事で詳述する。

3-4. 観測性ゼロのブラックボックス運用 ── 障害時に「何が起きているか分からない」

2026年現在、Datadog・New Relic・Sentry・Grafana・Cloudflare Analyticsなど、可観測性ツールは多様化している。これらを一切導入していない事業は、障害時に「何が起きているか分からない」状態であり、買収後の信頼性向上施策に著しいコストがかかる。

逆に、APM（Application Performance Monitoring）、ログ集約基盤、エラートラッキング、ビジネスメトリクスダッシュボードの4点が揃っている事業は、運用品質の高さがそのまま加点要素になる。可観測性は2026年において「あって当然」のラインに来ており、これがゼロの事業は「現代の事業として最低限の運用品質を満たしていない」と評価される。

4. 中立〜ケース次第のスタック群 ── AIエコシステム依存・ノーコード・マイクロサービス

4-1. 生成AI API依存型サービス ── 加点と減点の両面性

OpenAI／Anthropic／Google／Bedrockなどの生成AI APIを中核機能に組み込んだサービスは、2026年現在「中立〜ケース次第」のゾーンにある。加点要素は「市場の旬な領域で立ち上がりが速いこと」「ユーザー体験の先進性」「データ蓄積に伴う差別化可能性」。減点要素は「API依存度の高さ」「価格改定・サービス停止リスク」「単純なラッパーであれば模倣容易性」だ。

評価の分水嶺は、「LLM APIを抜いた状態で事業が成立するか」「複数LLMへの切替が可能な抽象化レイヤーがあるか」「独自データ蓄積・ファインチューニング・RAG構成で差別化されているか」の3点だ。これらが整っている事業は加点、単純なAPIラッパーであれば減点という二極化が起きている。詳細は連載の別記事で深掘りする。

4-2. ノーコード・ローコード基盤依存 ── Bubble / Webflow / STUDIOの評価

Bubble・Webflow・STUDIO・Adalo・Glideといったノーコード基盤で構築された事業は、2026年現在「ケース次第」のゾーンだ。加点要素は「開発スピード」「非エンジニアでも保守可能」「初期投資の小ささ」。減点要素は「プラットフォーム移管不可能性」「スケール時のパフォーマンス限界」「プラットフォーム側の料金改定・サービス停止リスク」。

ノーコード事業のバリュエーションは、コード資産の評価がほぼゼロに近づくため、「事業モデルそのもの」「顧客リスト」「ブランド」に評価が集中する。これは別記事で深掘り予定だが、「コード資産が無くてもキャッシュフローが回る」事業として割り切って評価する必要がある。

4-3. マイクロサービス／モノリス ── 規模と組織で評価が反転する

マイクロサービス構成は、2010年代後半は「モダンで加点要素」とされていたが、2026年現在は「規模と組織能力次第」という評価になっている。年商10億円規模未満の事業がマイクロサービス化されている場合、運用負荷が事業規模に対して過大であり、しばしば減点される。

逆に、年商数十億円規模を超え、複数チームが並行開発する事業ではマイクロサービス構成が加点要素になる。「適切な規模で適切な構成を選んでいるか」という判断が問われる領域であり、ここに技術的DDの本質がある。

5. 評価フレームワーク ── 5分でできるスタック・スコアリング

5-1. 5軸×5段階の評価マトリクス

実務で使えるスコアリングは、5軸×5段階の単純な評価マトリクスだ。①保守容易性、②拡張性、③可観測性、④セキュリティ、⑤コスト弾力性のそれぞれを、5（業界トップクラス）、4（標準を上回る）、3（標準）、2（標準を下回る）、1（深刻な負債）で評価する。合計25点満点で20点以上は加点案件、12〜19点は標準評価、11点以下は減点案件と分類する。

このスコアリングをDDの初期段階で行うことで、案件の優先順位付けと、財務評価への補正幅の試算が可能になる。「同じ売上規模の案件のうち、どれを優先的に深掘りするか」「価格交渉でどの程度の補正を提案するか」という判断が、定量的な根拠付きで行えるようになる。

5-2. 加点・減点を金額に翻訳する ── EBITDA倍率の補正幅

スコアリング結果をバリュエーションに翻訳する際の経験則は、加点案件（20点以上）はEBITDA倍率に1.2〜1.5倍、標準評価（12〜19点）は1.0倍、減点案件（11点以下）は0.6〜0.8倍の補正を加える、という運用だ。月商1,000万円・年間EBITDA3,000万円の事業を例に取ると、加点案件は1.8億〜2.25億円、標準は1.5億円、減点案件は0.9億〜1.2億円という幅になる。

この幅は単なる経験則だが、技術DDの実務において「価格交渉の根拠付け」として機能する。財務系の仲介業者が「相場ですから」と一律のEBITDA倍率を当てはめてくる現場に対して、技術DD側から「このスタック構成では1.5倍の補正が妥当です」と数字を提示できる体制が、買い手側にとっても売り手側にとっても価値を生む。

5-3. スコアリング結果をどう交渉材料にするか ── 売り手・買い手双方の戦略

売り手側がこのスコアリングを活用する場合、まず自社事業を5軸で自己採点し、減点項目を洗い出してから売却交渉に臨むことが重要だ。減点項目の中で「短期間で改善可能なもの」（IaC化、可観測性ツール導入、ドキュメント整備など）は、売却前の数か月で対応することで、バリュエーションを数百万〜数千万円押し上げられる可能性がある。

買い手側は、財務DDの結果に加えて技術DDのスコアリング結果を提示し、価格交渉の根拠とする。「相場より安く買う」のではなく、「技術的負債のコストを正当に価格に織り込んで買う」という姿勢が、買収後のトラブル発生率を大きく下げる。これがM&Aの後悔率を下げる最も実務的なアプローチだ。

結論：技術スタックは「過去の選択」が「未来の値段」を決める

事業の技術スタックは、創業期の意思決定が10年後の売却額を決める。当時は「動けばいい」「早く出せばいい」と選んだ言語・フレームワーク・インフラ構成が、買収交渉のテーブルで数千万円から1億円以上の差を生む。これは技術者にとって冷酷な現実であり、経営者にとっては見過ごしてきた経営判断の結果だ。

逆に言えば、いま事業を運営している経営者・エンジニアにとって、技術スタックの選択は単なる「技術的好み」ではなく、将来の事業価値そのものを左右する経営判断だということになる。本稿の5軸スコアリングを自社事業に当てはめ、減点項目を一つずつ潰していくことが、出口戦略における最も確実な企業価値向上策の一つだ。M&A仲介の現場で「数字に載らない技術資産」を翻訳する作業は、こうした地道なスコアリングの積み重ねの上にしか成立しない。