見出し画像

AI時代のGTM戦略（前編）― 高NRRを生む「自律的EXPAND」3つの型

Mayu Kudo | 工藤 真由 | Globis Capital Partners

はじめに：原価が重いAIは、人を増やさずGTMを伸ばせるのか

5月30日、LegalOn Technologies CEO 角田望さんが下記の投稿をされていました。

私の解釈では、この投稿が指摘していたのは、SaaSのAIネイティブ化は高粗利を捨てる“SaaSの自殺”になりうる、という論点です。それに見合う成長率とPLG型GTMをセットで設計できないなら、SaaSとAIカンパニーは別物と割り切り、ドメインごとにビジネスモデルを選ぶべきではないか。見落とされがちですが、非常に重要な問いだと思います。

従来のSaaSからの転換という切り口で投稿されていましたが、AIカンパニーが自社の戦略を考えるうえでも検討せざるをえない論点だと思います。

SaaSモデルなら粗利率が高いので、GTMに先行投資してSales Ledで事業を立ち上げられます。けれど原価が重くなるAIカンパニーの場合、GTMに投資できる予算はより限定される。したがって、Product LedのGTMモデルを確立できないかぎり、戦略の時点で破綻する可能性が高い、というわけです。

一方で、そもそもB2Bソフトウェア、特にエンタープライズ向けで、PLG（Product-Led Growth）が成立する領域はかなり限られている、というのが私のこれまでの実感です。PLG的な伸び方をしたのは、その多くが開発者向けソフトウェア（か、そこを起点に対象を広げていったプロダクト）くらいではないか。むしろ、AIは業務を代替しにいくゆえにより深いナレッジとカスタマイズが必要、といった特徴から、従来のSaaSよりも導入コストはむしろ高まっていく印象でした。

だとすると、原価が重いAIカンパニーは、人員ではなくプロダクトに成長を駆動させるGTMを、いったいどう実現すれば良いのか。エンタープライズの現場で、それは本当に成立しているのか。今回はこの問いを、グローバルのAIアプリケーションレイヤーの実例をたどりながら掘り下げてみたいと思います。結論を先取りすれば、鍵は「LAND（獲得）」ではなく「EXPAND（拡大）」をどう自律化するかにあります。

つまり本稿で言いたいのは、「エンタープライズAIでもPLGが成立する」という単純な話ではありません。ハイタッチでLANDした後に、利用・データ・ワークフロー・社内資産がプロダクト内で自己増殖し、EXPANDだけが自律化していく構造は成立しつつある。ここに、エンタープライズAIにおける“product-led”の現実的な姿がある、というのが本稿の主張です。

第1章：B2Bソフトウェアで、PLGが効く領域は限られている

PLGが成立する3つの条件

そもそもPLGという言葉は、もともとVC・OpenViewのKyle Poyarらが広めた概念です。プロダクト自体が獲得・教育・拡大のエンジンになるGTMモデルを指します。無料枠やフリーミアム、セルフサーブのサインアップ、プロダクト内のバイラルな広がり——Slack、Zoom、Figma、Notionあたりが代表例として語られてきました。

ただ、PLGはどんなプロダクトでも効くわけではありません。各所で言われている条件を総合すると、クラシックなPLGが機能するには、おおむね次の3条件が揃っている必要があると考えます。

第一に、Time to Valueが即時であること。サインアップして数分のうちに「お、これは便利だ」と価値を体感できること。設定に何週間もかかったり、他システムとの統合が前提だったりするプロダクトでは、無料ユーザーは価値を感じる前に離脱してしまいます。

第二に、使うこと自体が他者を巻き込む動機になること（バイラリティ）。ドキュメントを共有する、デザインを一緒に編集する、チャンネルに招待する——プロダクトを使う行為そのものが、新しいユーザーを連れてくる構造になっていること。

第三に、一人で購買判断ができること。個人やチームのリーダーが、稟議や情報システム部門の承認を経ずに、クレジットカード一枚で導入を決められること。

この3条件を、AIネイティブの文脈に翻訳したのが、GTMコンサルタントSachin Jha氏の「Why I Stopped Recommending PLG to Early-Stage AI Startups」という論考です。彼の主張はシンプルで、AIプロダクトの多くは導入時に設定・既存システムとの統合・信頼の獲得（パイロットや参照顧客の積み上げ）を必要とするため、上記の3条件をことごとく外す、というものです。価値を体感するまでに準備期間が要り、現場の一存では決められず、勝手に広がる仕掛けも持たない。だからこそ、ある程度以上の価格帯のプロダクトを売るには、結局なんらかの営業・導入支援の動きが避けられない、と彼は言います。

エンタープライズほどPLGは効きにくい

特にエンタープライズ向けでは、この3条件はほぼ揃いません。とりわけACV 1,000万円を超えるような契約では、数ヶ月にわたる実装、情報システム・法務・調達を巻き込む購買プロセスが前提になります。「一人で、数分で、勝手に広がる」とは対極の世界です。

Jha氏は具体例を挙げています。クラウドセキュリティのWizは、エンタープライズ先行・営業主導で18ヶ月で100M ARRに到達し、後に320億ドルで買収されました。セルフサーブで始めたClayも、2023年秋・ARR数百万ドルの段階でエンタープライズ営業へ移行しました。彼の観察で印象的なのは、「SLGから純粋PLGへ移った企業は皆無で、転換はすべて逆方向だった」という一文です。

唯一の例外として彼が名指しするのが、まさに開発者起点のプロダクトです。設定や人の介在なしに数分で価値が出て、本質的にバイラルな場合だけ、PLGは早期から効く。その証明がCursor（Anysphere）です。ただし、そのCursorですら、Fortune 1000を取りにいくためにハイタッチなエンタープライズ営業を後から追加しています。

AI時代の「PLGの勝者」も、やっぱり偏っている

これは現在のAIアプリケーションレイヤーを見ても裏付けられます。「AI時代のPLGで爆発的に伸びた」と語られる顔ぶれは、見事に偏っているのです。

「高い成長率を記録しているPLG企業」として代表例に挙がるのは、Lovable、Cursor、Gamma、Perplexityあたりでしょうか。Cursorは2025年半ばに500M ARR、2026年2月には2B ARRに到達し、200Mを超えるまでエンタープライズ営業担当をほぼ雇わなかったといわれています。Lovableは公開ローンチから約12ヶ月で200M ARR。Bolt.newはわずか2ヶ月でゼロから20M ARRを達成しており、Gammaは2026年1月時点で従業員約50名で100M ARRに達し、7,000万ユーザーに利用されているといいます（SaaStr調べ）。

けれど、ここで名を連ねるのは、あくまで「触ればすぐ分かる」種類のものばかり。つまり、クラシックなPLG＝獲得モーションとしてのPLG（無料×バイラル×セルフサーブ）は、AI時代になっても、その大半が開発者・プロシューマー領域に限定されているということです。

第2章：それでも、AI時代のGTMは全企業の問題である

ここまでPLG（獲得モーション）の限界を見てきました。ではなぜ、それでも「人員ではなくプロダクトに成長を駆動させるGTM」を、誰もが考えざるをえないのか。理由は、原価構造の変化にあります。

今後、推論コストという新しい原価が、AI企業のマージン構造を変えていくことは避けられません。ICONIQの2026年1月のレポートによれば、スケール段階のAI B2B企業では、推論コストが平均で売上の23%を占めます。SaaStrのJason Lemkinはこれを「AI税」と呼び、かつて85%粗利を誇ったSaaS企業が今や60〜70%への調整を迫られている、と指摘しています。Bessemerの調査でもAIネイティブ企業の粗利は概ね60〜65%にとどまり、過去10年のクラウドを定義した80〜90%を大きく下回ります。

粗利が下がれば、S&Mに回せる「額」が減ります。すると、高コストなSLGを今までの規模では維持できなくなる。だからこそ、人員に売上を比例させないGTM＝広い意味でのproduct-ledな経済構造を、誰もが模索せざるを得ないのです。

これは以前の記事でも書いた「AI駆動のGTM（社内のAI活用）」とも地続きの話です。米国では、AIを単なる「活用」ではなく、業務そのものの「オートパイロット化」へと進めています。セールスやマーケティングのオペレーションをAIエージェントが肩代わりすることで、少人数でGTMを回す。つまり「売る側のオペレーションをAIで圧縮する」（＝AI駆動GTM）と、「ビジネスモデルそのものをproduct-ledに作り替える」（＝本稿のテーマ）は、コインの裏表なのです。粗利が下がる世界では、両方をやらなければ生き残れません。

▼▼AI駆動GTMについて米国最前線の取り組みをまとめた記事はこちら▼▼
米国AI駆動GTMの最前線 ー SaaStr AI 2026から見えた成長への渇望

第3章：「PLG」の二つの意味——獲得か、経済構造か

ここで、本稿の前提になる大事な概念を整理しておきます。

「PLG」と言っても二つの射程が混在しています。
そもそもPLGは、2016年ごろにOpenViewのBlake Bartlettが提唱し、後にKyle Poyarらによって広く普及した概念です。

よく用いられる意味合いは、

(A) 獲得モーションとしてのPLG——無料枠・バイラル・セルフサーブで顧客を「獲得」する手法

を指すことが多いと思います。私もPLGと聞いて普段第一想起するのはこちらの意味合いです。第1章で見た『PLGは開発者・プロシューマーに限られる』という議論も、この狭義の(A)を指しています。

しかしながら、OpenViewは当初から、PLGを「プロダクト自体が獲得・リテンション・拡大の主たるドライバーになる成長戦略」と広く定義していました。この本来の定義に立ち返れば、PLGの重心はむしろ

(B) 経済構造としてのProduct-Led——売上を伸ばすのに人員を比例して増やさねばならないSLGに対し、獲得・教育・拡大をプロダクト自体に担わせ、人を成長のボトルネックから外す

にある、と私は考えています。

売上の伸びと人員の伸びを切り離し、S&Mレバレッジを効かせる構造、すなわち「粗利低下を埋めるためにGTMをProduct Led化せよ」と言うときに参照すべきは、明らかに(B)なのです。

ここで前章まで私が考えていたフレームが効いてきます。エンタープライズAIの勝ち筋は、

「ハイタッチでLANDし、プロダクトが自律的にEXPANDして、高いNRR（Net Revenue Retention）を実現する」

という形に集約されるのです。獲得は人手でも、拡大はプロダクトの利用が担う。これこそが、エンタープライズで成立しうる「経済構造としてのproduct-led」の、最も現実的な姿なのです。

参考までに指標で言い換えておくと、(B)が効いているかどうかは次の3点で測れます。①S&M効率（magic numberやCAC payback）、②利用ベースの自動拡大（NRR）、③revenue per employee（従業員一人あたり収益）。繰り返しになりますが、「拡大に人手が要らないか」が本質になるのです。

そして、ここからが本稿の核心です。「拡大をプロダクトが担う」と一言で言っても、その"自律的なEXPAND"が、いったいどんなメカニズムで起きているのかを分けて見ないと、「で、具体的にどう作るのか」には答えられません。その自己増殖のメカニズムは、大きく3つの型に分かれます。次章で見ていきましょう。

第4章：自律的EXPANDの「3つの型」

では、主要な米国AIアプリケーションレイヤー企業はどのように自律的EXPANDを実現しているのか。「EXPANDを強く駆動しているプロダクト内・顧客内メカニズム」という分類軸で各社の工夫を3つの型に分けて見ていきたいと思います。そして、そのEXPANDを売上に変換するための受け皿としてどのようなマネタイズモデルに帰着することが多いのかも分析しました。

なお、これは企業をMECEに分類するための表ではありません。実際には複数の型を併せ持つ企業が多く、ここでは各社のEXPANDを最も強く駆動している主メカニズムに着目しています。

筆者作成

なお、いずれの型も「現場に深く入り込む実装支援」を伴うハイタッチなLANDが前提になっています。この実装支援は、近年FDE（Forward Deployed Engineer）と呼ばれる職種が担うことが多くなっています。重いLANDは共通。違うのは、その後のEXPANDがどう自走するか、です。

型1：AI業務移管型——AIが担える業務範囲が広がる

最初に、EXPANDが最も直接的に売上へ連動する型から始めます。この型では、既存業務のうちAIが担える範囲・解決件数・処理件数が増えることによってEXPANDが起きます。プロダクトが解ける業務範囲を広げ、その増加分が成果・処理量・診療件数・アクション単位で売上に変換されるため、3つの型のなかでも売上化の自律性が最も直接的なのが特徴です。

では、何がAIへの業務移管率を上げているのか。型1の自律的EXPANDは、「AIの"能力"が上がること」に乗っています。 そして、その能力向上を駆動しているのは、主に2つです。

ひとつは、利用が利用を賢くするデータループ。SOP・過去の対話・業務ポリシー・顧客データを取り込み、実際の対話から失敗やエスカレーションを評価・改善することで、対応範囲と解決率を高めていく。もうひとつは、ベンダー自身のモデル・アルゴリズムの改善。専用の検索・再ランキングモデルや、エージェントを監督する仕組みを磨くことで、蓄積データの量とは独立に解決率が上がっていく。 

ここで強調しておきたいのは、型1で積み上がるデータは、あくまで「AIをより賢くするための燃料」だという点です。後で見る型2・型3の資産は、顧客に繰り返し参照・再利用されるものです。これに対し、型1のデータは顧客が直接再利用する資産というより、AIを賢くするための燃料として使われます。価値は「AIが処理した結果」として顧客に届く。だから課金も、保有データの量ではなく、AIが処理・解決した量に乗ります。営業がアップセルを売り込まなくても、プロダクトが賢くなって担える業務範囲が広がるほど、課金対象も自律的に広がっていく——これが型1の自己増殖です。

Sierraが象徴的です。プラグ&プレイのベンダーではなく、各社のブランドボイス、ポリシー、ワークフローに合わせたカスタムエージェントを共同構築する「戦略パートナー」としてLANDします。重要なのは、SierraのEXPANDが問い合わせ総量ではなく、「AIが人間の代わりに解決した業務量」の拡大に乗っていることです。

Sierraが解決率を上げる仕組みは、まさに前述の2つのドライバーの組み合わせです。Ghostwriterによる業務知識のエージェント化、解決した対話からの根拠付きナレッジの自動生成、そして専用の検索・再ランキングモデルや監督エージェントの改善。Sierra自身も、専用モデルが市販モデルを上回り、解決率を最大16ポイント改善したと公表しています。データのループとモデルの改善が両輪で回り、AIが解決できる範囲を継続的に押し上げているわけです。

もっとも、型1である以上、Sierraは「COGS（売上原価）の罠」と隣り合わせです。AIが対応できる業務範囲が広がるほど売上は伸びますが、同時に推論・実行・監視コストも増える。だからこそ型1の勝負どころは、AIに移管できる範囲を広げるだけでなく、解決率を高め、1件あたりのコストをどこまで下げられるかにあります。この罠の構造と抜け方は、後編で詳しく述べます。

▼▼Sierraの戦略詳細についてまとめた記事はこちら▼▼
創業2年でデカコーン、米国AIスタートアップの代名詞「Sierra」の戦略を徹底解剖

Decagonも同型です。座席数ではなく、AIが処理・解決した量に課金するため、EXPANDは問い合わせ総量ではなく、AIが担うチャネルやワークフローの拡張に乗ります。肝になるのは、Agent Operating Procedures（AOPs）という、自然言語でAIエージェントの業務手順を定義する仕組みです。返金、予約変更、本人確認といった顧客対応ワークフローを追加し、voice / chat / emailへ横展開し、Testing & QAやInsightsで挙動を改善する。つまりDecagonの業務移管率を上げているのは、AOPsによるワークフロー追加と、チャネル横断の展開・改善ループです。

Parloaはコンタクトセンター音声に特化したドイツ発のプレイヤーです。ここでのEXPANDも、単に会話量が増えることではなく、AIが代替するオペレーション範囲が広がることです。AI Agent Management Platform上でエージェントをDesign、Test、Scale、Optimizeし、音声から他チャネルへ、単一言語から多言語へ、単純応答から本人確認・請求・返品・予約変更のような業務アクションへと広げていく。BPOや人間のコンタクトセンターが担っていた業務を、段階的にAIへ移管することで拡大する型です。

Abridgeは医療AIスクライブの代表格です。臨床医創業という信頼性を武器に、90日パイロットで病院システムにLANDします。最初は診療記録作成から入り、EHR内の既存ワークフローに深く統合することで、「ノート作成→オーダー→診断コーディング→請求文書」へとAIが担う業務工程を広げていく。課金は診療件数に連動するため、AIに移管される診療関連業務が増えるほどEXPANDが進む構造です。さらに、診療内容を保険請求につなげるレベニューサイクル領域へ広がれば、病院にとってはコスト削減だけでなく売上回収に直結する。なお、Abridgeは診療会話やノートが蓄積され再利用される点で型2的な性格も帯びますが、課金も拡大の主軸もあくまで「AIが処理した診療件数」にあり、本質は型1です。蓄積データは型2のように"参照される基盤"そのものが拡大を駆動するのではなく、型1のSierraと同じく「AIを賢くする燃料」として効いている、と捉えるのが正確でしょう。 

これら4社は、課金の建て付けこそ違いますが、いずれも「AIが担える業務範囲をプロダクト内で広げ、その増加分を処理・解決の量で売上に変換する」という点で同じ型1に分類できます。鍵はAIへの業務移管率の上昇であり、それを駆動するのは、データのループ、モデルの改善、そして業務ワークフローへの深い統合です。

ここから見る型2・型3でも、問いは同じです。営業によるアップセル・クロスセルではなく、プロダクトのどの部分が拡大を駆動しているのか。型2では蓄積されたデータ基盤が次のユースケースを呼び込み、型3ではユーザーが新規に作った業務資産が組織内で再利用されます。

型2：データ堆積型——蓄積されたデータ基盤の上に、次のユースケースが載る

型1が「AIの能力が上がること」で拡大したのに対し、型2は「蓄積されたデータそのものが、再利用可能な基盤になること」で拡大します。型1のデータが「AIを賢くする燃料」として消費されるのに対し、型2のデータはそれ自体が繰り返し参照・再利用される基盤になる。だから拡大の限界コストが低く、ストック的な性格を持ちます。

その代表例がGlean（エンタープライズ検索）です。GleanのEXPANDを担っているのは、単なる検索UIではなく、全社アプリを横断してデータ、権限、人物、業務文脈をつなぐEnterprise Graphです。Gleanは100超のアプリに接続し、Slack、Google Drive、Jira、Salesforceなどに散らばる情報を、権限を保ったまま検索・要約・推論できる状態にします。
ここで重要なのは、一度Enterprise Graphが構築されると、その上に次のユースケースを載せるコストが大きく下がることです。最初は「社内検索」や「質問応答」から始まっても、その同じデータ・権限・文脈の上で、Glean Assistantが要約や回答を行い、Glean Agentsが申請、調査、更新、レポート作成のようなワークフローを実行できるようになる。営業が追加モジュールを都度売り込まなくても、ユーザーが「このデータはもうつながっているから、この業務にも使える」と利用範囲を広げていく。これが型2の自己増殖です。課金面でも、Gleanは席課金の上に「FlexCredits」という組織単位の従量メーターを載せ、エージェント実行やAI処理＝「つながったデータの上でAIがこなした仕事量」を売上に変換する受け皿を持っています。
Harvey（リーガルAI）も、少なくとも現在の拡大ドライバーを見る限り、データ堆積型として理解すると見通しがよいプレイヤーです。一見すると、Harveyは「1部門の成功が他部門に伝播して席が増える」席拡大型に見えます。実際その側面はあり、弁護士の高い時給にアンカーされた席数課金モデルをとっており、席増には営業・CSの働きかけも相当程度介在していると思われます。
けれど、Harveyの粘着性と拡大を本質的に支えているのは、Vault/Memoryに蓄積される案件ナレッジ——判例、契約書、過去案件、ドキュメント分析、リサーチ結果——という、法務に特化したデータ基盤です。一度この基盤が溜まると、その同じデータの上でリサーチもドラフトもレビューも回せるようになり、隣のプラクティスグループがその資産を使おうとすると自分たちの席も必要になる。弁護士がHarveyから離れられないのは、案件データと業務文脈がHarveyに蓄積されているからです。
Gleanが「全社の汎用データを横断接続する」のに対し、Harveyは「法務という一領域に特化したデータを深く堆積させる」——同じ型2の、汎用と特化の対比だと捉えると分かりやすいでしょう。
なお、型2で積み上がる資産は、顧客の既存データ（社内に散らばる文書や、投入された案件ファイル）を、ベンダー側がクロール・構造化し、権限や業務文脈と結びつけて再利用可能な基盤にする点に特徴があります。次に見る型3が「ユーザー自身がゼロから新規制作する資産」であるのに対し、型2は「もともと存在したデータを集約・構造化して生まれる基盤」です。最初の全社データ接続や案件データの投入は管理者・現場の関与を要しますが、いったん基盤が出来れば、その上に用途が自律的に載っていくのが型2の自己増殖です。

型3：ユーザー資産型——ユーザーが業務資産を新規制作し、それが共有・再利用される

3つめは、ユーザー自身が業務知識を資産として新たに作り込み、それが組織内で共有・再利用されることで拡大する型です。型2が「もともとあったデータを集約・構造化する」のに対し、型3は「それまで存在しなかった業務資産を、現場ユーザーが新規に創造する」点が決定的に違います。型2が「ベンダーが繋いで生成する受動的なストック」だとすれば、型3は「現場ユーザーが自ら作り込む能動的なストック」。ベンダーは「作らせる場（プラットフォーム）」を提供し、価値の制作と拡散はユーザーが担う。本来のPLGの自己増殖に最も近い構造であり、ユーザーが作業を肩代わりするぶん、ベンダーの限界コストも低くなります。

Writerがこの型の代表です。WriterのEXPANDを担っているのは、ユーザーが業務知識を再利用可能な資産として作り、共有できる仕組みです。Skillsは、チームの方法論、品質基準、意思決定の型をエンコードした再利用可能なブロック。Playbook builderは、それらのSkillsを組み合わせて、非技術者でも自然言語でワークフローやエージェント能力を作れるようにする。さらにKnowledge Graphが全社データと接続することで、ユーザーが作ったSkillやPlaybookは、単なるテンプレートではなく、企業固有の文脈に接続された業務資産になります（このデータ接続は型2的な下地ですが、Writerの拡大の主役はあくまでユーザーが作るSkillの側にあります）。

この型の自己増殖は、誰かが作った優れたSkillやPlaybookが組織内で共有され、他のメンバーやチームに再利用されることで起きます。たとえば、マーケティングチームが作った競合分析のSkillが営業資料や経営会議でも使われ、法務や人事が作ったレビュー手順が他部門のワークフローに組み込まれていく。価値の制作も拡散もユーザーが担うため、ベンダーが毎回個別に実装・販売しなくても、プロダクト内に資産が増えていく。WriterのNRRは160%、初期契約20〜30万ドルから約100万ドルへ拡大する顧客もいるといいます。

型2(Glean/Harvey)が「既存データを集約して基盤化する」のに対し、型3(Writer)は「ユーザーが新しい業務資産を創造する」。同じ"積み上がるストック"でも、それが既存物の集約なのか新規の創造なのか、そして積み上げる主体がベンダー側のエンジンなのか現場ユーザー自身なのか——この2点で、型2と型3は明確に分かれます。

3つの型を、自己増殖メカニズムで貫く

ここまでの3つを、もう一度「何が積み上がって拡大を駆動するのか」で並べると、違いが鮮明になります。型1（業務移管）で積み上がるのは、AIを賢くする燃料としてのデータ——それは消費され、価値はAIが処理した結果として届く。型2（データ堆積）で積み上がるのは、繰り返し参照される基盤データ——もともと社内にあったデータを、ベンダー側のエンジンが集約・構造化する（Gleanは全社横断、Harveyは法務特化）。型3（ユーザー資産）で積み上がるのは、ユーザー自身がゼロから新規制作する業務資産——現場が作り、組織内で再利用される。

「AIが賢くなって担える範囲が広がる（型1）」のか、「蓄積したデータ基盤の上に用途が載る（型2）」のか、「ユーザーが新しく作った資産が再利用される（型3）」のか。同じ"自律的EXPAND"でも、その駆動源はこれだけ異なります。そして、この駆動源の違いが、次に見る課金モデルの違いと、後編で扱う「粗利の運命」を規定していきます。

第5章：AI時代は、product-ledなEXPANDを「加速」させる——ただし諸刃の剣として

ここで一歩引いて、大きな問いを置きたいと思います。そもそもproduct-ledなEXPANDは、SaaS時代よりAI時代のほうが起こしやすいのか。 私の見立ては「Yes、構造的に加速しやすい」です。ただし、その加速はそのまま喜べるものではない、という留保つきで。

なぜ加速するのか。理由は3つあります。

第一に、拡大が「人の増員」を介さなくなったこと。SaaS時代のproduct-ledなEXPANDは、突き詰めれば「使う人を増やす（席を増やす）」ことが中心でした。FigmaもSlackも、拡大とはユーザー数の増加であり、その上限は「顧客側で何人が使うか」に縛られていた。AI時代は、EXPANDの単位が「人」から「AIが担う業務範囲・処理量」へ移った（型1）。人を増やさなくても、AIが担える業務が広がれば拡大する。人数という天井が外れたぶん、理論上の拡大余地が一気に広がりました。

第二に、「使われること自体がプロダクトを強くする」フィードバックループを持てること。SaaS時代のプロダクトは作った時点の機能のままで、改善はベンダーが人手で足すしかなかった。AI時代は違います。型1では使われるほどデータが評価・改善に回って解決率が上がり、型2では接続・利用が進むほどデータ基盤の価値が高まり、型3では作られた資産が増えるほど再利用が起きる。3つの型すべてに通底するこの自己強化ループが、使われることをそのままEXPANDへ変える加速装置になっています。 

第三に、価値を「作る側」のハードルが劇的に下がったこと。SaaS時代、プロダクト内に高度なワークフローやアプリを作るには専門知識が要りました。AI時代は、自然言語で非技術者がエージェントやSkillを作れる（型3）。価値の制作主体が、ベンダーや一部の上級ユーザーから現場の全員へ広がった。型3の自己増殖が速いのは、作り手の裾野がAIで一気に広がったからです。

つまりAI時代は、product-ledなEXPANDのアクセルが、SaaS時代より何本も増えている。これは間違いなく追い風です。
ただし、推論COGSの加速を伴う点には気を付けなければなりません。特に型1のように、処理量・解決件数に連動して伸びるモデルでは、伸びるほどトークンや実行コストを消費します。SaaS時代のproduct-led EXPANDは、追加利用に伴う限界コストが相対的に低く、席や利用が増えるほど高粗利に効きやすい構造でした。AI時代は、EXPANDの加速エンジンそのものが原価を連れてくる。「加速しやすくなったが、その加速が粗利を削りうる」——これがAI時代の「COGSの罠」です。

そして、罠は型1だけのものではありません。シート課金を収益の柱に持つ型2・型3には、別種のリスクが潜みます。AIが顧客側の業務を肩代わりするほど、顧客は人員＝席を減らしうる。席に売上が紐づいていると、拡大どころか縮小に転じかねない——これが「AIシートリスク」です。型2・型3が、シート課金の上に従量メーター（FlexCredits等）やユーザー資産を重ねようとするのは、売上を「人数」から「蓄積された基盤・資産の利用」へ移し、このリスクを和らげるためでもあると捉えられます。

第6章：結論（前編）——自律的EXPANDは「3つの型」で実現されている

ここまでを、もう一度、最初の問いに戻して締めくくります。

「Product LedのGTMモデルを確立できないかぎり破綻する」という、原価が圧迫されたAIカンパニーに突きつけられる命題。ただし、その「Product Led」は(A)獲得のPLGではなく、(B)経済構造としてのproduct-ledを指すと読むべきです。そして(B)は、エンタープライズにおいては「ハイタッチにLANDし、プロダクトが自律的にEXPANDして、高NRRを実現する」という形で、現に成立しています。本稿で見た3つの型——AI業務移管型（型1）、データ堆積型（型2）、ユーザー資産型（型3）——が、その自律的EXPANDの具体的な実現方法です。

つまり、私の最初の引っかかり——「エンタープライズ向けソフトウェアで、人ではなくプロダクトに成長を駆動させるGTMをどう実現するのか」——への答えはこうなります。獲得モーションとしてのPLGは、確かに開発者・プロシューマー領域に偏在し続けている。けれど、経済構造としてのproduct-ledは、3つの自己増殖メカニズムを通じて、エンタープライズにも静かに浸透しつつある。しかもAI時代、その拡大はSaaS時代より加速しやすい。

とはいえ、(B)の鍵である「高NRR」は、額面通りには受け取れません。前章で触れたとおり、二つの落とし穴がそれを脅かすからです。一つは型1のように処理量・解決件数で伸びるモデルに潜む「COGS連動の罠」——拡大そのものが推論コストを連れてきて、粗利をむしろ削りうる。もう一つは、シート課金を柱とする型2・型3に潜む「AIシートリスク」——顧客がAIで人員を減らせば、席に紐づいた売上は縮みうる。同じ「NRR130%」でも、それが粗利を増やす拡大なのか、削る拡大なのか、そして持続する拡大なのかは、まったく別物です。

もっとも、本稿で見た3つの型には、いずれもこの落とし穴を和らげる方向性が見え始めています。型1は解決率を上げて1件あたりのCOGSを下げにいき、型2・型3は売上の重心を「人数」から「蓄積された基盤・ユーザー資産の利用」へ移そうとしている。共通するのは、拡大を“流れ続けて消えていくもの”（処理量・人数）だけに乗せず、“積み上がって残る資産”（参照されるデータ、ユーザーが作る業務資産）にも乗せ替えようとしていることです。

後編では、この「COGS連動の罠」と「AIシートリスク」の正体を数字で解剖したうえで、NRRの「質」——それが粗利を増やし持続する拡大なのか——をどう見分けるか、そして拡大を「流れて消えるもの」から「積み上がって残る資産」へ乗せ替えるとは具体的に何をすることなのかを、掘り下げます。

補注：本稿で参照した主なソース

粗利圧縮の経済構造

PLG成立条件と懐疑論

各社の自己増殖・課金モデル

NRRベンチマーク

  • FE International、Prospeo（2026年初頭の公開SaaS中央値NDR約108%、エンタープライズ中央値118%、トップクオータイル130%超）

注：本記事に記載の数値・日付・ファクトは、2026年6月8日時点で確認できた公開情報に基づきます。本記事の執筆にはAIを活用していますが、最終的な編集および事実確認は筆者が行っています。本記事は筆者個人の見解・分析であり、筆者が所属する企業・団体の公式見解を示すものではありません。また、特定の投資判断や事業判断を推奨するものではありません。


いいなと思ったら応援しよう！