Cursorは2024年に2ヶ月ごとにARRを倍増させた。最初のユーザーはほぼ全員、個人の開発者だった。社内稟議も調達担当者も関係なく、「使いたいから使う」という理由だけで広がった製品が、年末には$400MのARRに達したと報じられている。
FigmaもNotionもLinearも、同じ道を辿っている。個人→チーム→全社という転換は、偶然起きるものではなく、設計できる。
この記事では、その転換を再現する4ステップを説明します。対応するケーススタディ「Cursorが2ヶ月ごとにARRを倍増させた構造」と合わせて読むと、なぜこの設計が機能するかがより深く理解できます。
個人ユーザーが増えても法人契約にならない本当の理由
多くのPLG(プロダクト主導型成長)SaaSが直面するのは同じパターンだ。MAUは伸びている。ユーザーの口コミも悪くない。でも法人契約がほぼゼロ。
原因は、障壁の場所を誤解していることにある。エンタープライズ転換を阻む壁は3つある。購買権限(誰が決裁するか)、セキュリティ(データはどこに行くか)、運用(管理者は誰が担うか)。この3つを順番に解消しないまま「エンタープライズプランを追加しました」と言っても、購買担当者は動かない。
Cursorが採った戦略はシンプルだった。個人開発者に深く刺さる製品を作る。チームで使われ始めたシグナルを検知する。そのタイミングで摩擦を一つずつ取り除く仕組みを仕込む。稟議が通る状態を、製品側から整えておく。
この転換設計に必要な前提条件
4ステップが機能するには、いくつかの条件が揃っている必要がある。
まず、個人で毎日使われる製品であること。週1回しか開かないツールは組織に浸透しない。次に、ドメイン単位でユーザーを把握できること。同じ会社の複数人が使い始めたことを検知できなければ、転換のトリガーを引けない。
技術面では、SSO対応が最低ラインだ。「SSOがないと社内展開できない」という反論は必ずくる。これを事前に解消しておかないと、どれだけ使われていても稟議が進まない。
人員は、プロダクトエンジニア1名とカスタマーサクセス1名で動き出せる。大規模な営業チームは設計が機能し始めてから採用すれば十分だ。
Step 1:同一ドメインのチームクラスタを検知する
何をするか。MixpanelかAmplitudeで、同一メールドメインのユーザーが3名以上いる「チームクラスタ」を自動検知するダッシュボードを作る。クラスタが発生したら即座にCSへSlack通知が届く状態にする。
なぜこれが最初か。エンタープライズ転換の開始点は、営業が作るのではなく製品側が検知するからだ。同じ会社から3人使っているなら4人目・5人目は近い。そのタイミングに乗れるかどうかが転換率を大きく変える。乗り遅れると、競合製品に全社契約を取られることも珍しくない。
どのくらいかかるか。Mixpanelの設定とSlack連携なら、エンジニア1名で1〜2週間で動く。
クラスタを検知したら放置しない。自動でチームプランへの招待メールを送るか、CSが直接連絡する。「3名いるのに個人プランのままですね」という一言で十分なことが多い。この接触の速さが、チームプラン転換率に直結する。
Step 2:チームプランで利用習慣を固め、管理者を味方にする
チームで使われ始めたら、管理者向け機能を一気に整備する。使用量レポート(誰が何回使ったか)、シートの一括管理、請求書払いへの切り替えの3点が最優先だ。
よくある失敗は、製品を改善し続けながら管理機能を後回しにすること。でも法人担当者が稟議を通すには「上司に見せられる管理画面」が要る。ROIを可視化できるレポート機能は、決裁者が「投資する価値がある」と判断するための材料になる。
Notionはここを徹底した。チームダッシュボードで「このメンバーが週何ページ作成したか」をひと目で確認できるようにした。管理者が稟議に添付できる資料を、製品が自動生成する形にした。決裁者が確認したいのは「このツールで業務が変わったか」という一点に尽きる。数字で見せられるかどうかで、稟議の通りやすさが変わる。
チームプラン移行から3〜6ヶ月で日常的な利用が根付いていれば、Step 3に進む準備ができている。
Step 3:セキュリティと管理の壁を事前に崩す
IT部門やセキュリティチームが稟議に入ってきたとき、必ず出る質問は3つだ。「SSOは使えますか」「データはどこに保存されますか」「SOC2は取得していますか」。これに即答できないと稟議が止まる。数ヶ月止まることもある。
SSOはWorkOSかAuth0で対応する。WorkOSはエンタープライズSSO(Okta・Azure AD・Google Workspace連携)に特化しており、数週間で実装できる。既にAuth0で認証を実装しているなら、Auth0のEnterprise Connectionsを追加するほうが移行コストがかからない。
SOC2取得にはDrataかVantaを使う。従来のポリシー文書手動整備では6〜18ヶ月かかる。これらのツールを使えば継続的な監査対応が自動化され、SOC2 Type IIを3〜6ヶ月で取得できる。費用は年間数百万円規模だが、エンタープライズ1件の年間契約単価を考えれば、先行投資として合理的な範囲だ。
Linearはこの準備を早期に終えていたことで、シリーズBの段階から年間5万ドル超の契約を複数獲得している。セキュリティ障壁への答えを先に用意しておく。それだけで、稟議が通るスピードが変わる。
Step 4:エンタープライズSKUを正式なラインとして設計する
ここまで来たら、エンタープライズプランを「高い個人プラン」にしてはいけない。独自の構造が要る。
有効な設計は「使用量ベース+固定の二段階」だ。使用量ベース(APIコール数・シート数・処理量など)で成長に応じた収益を確保しながら、固定の年間契約でコミットメントを得る。Cursorは開発者あたりの月額固定料金と、エンタープライズカスタム契約を分けることで、スタートアップから大企業まで同一製品で取り込んだ。
価格の提示方法も設計のうちだ。「お問い合わせください」だけのエンタープライズプランは、購買担当者の心理的ハードルを上げる。Pricing Tableに「年間50名以上のチーム向け。セキュリティ審査・SLA対応・専任サポート含む。目安:月額○万円〜」という形で概算を見せると、稟議に持ち込む前の社内合意形成が早くなる。数字が見えないと、担当者が「いくらかかるか分からないもの」を上に持ち込めない。
また、エンタープライズ専用の特典は「管理系」に集中させると刺さりやすい。シングルサインオン・監査ログ・優先サポートSLA・カスタムデータ保持ポリシー。これらは個人ユーザーには不要だが、IT担当者には必須の要件だ。
ツールの選び方と代替案
メイン構成はこうだ。プロダクト分析にAmplitude(Account-level分析とコホート機能が強い)、SSO/SCIMにWorkOS(エンタープライズSSO専用で初期コストが低い)、セキュリティ対応にVanta(UIがシンプルで小規模チームでも扱いやすい)。
代替はこうなる。分析はMixpanel(BtoCユーザーが多い場合)、SSOはAuth0(既存認証基盤がAuth0なら移行コストゼロ)、セキュリティはDrata(大規模組織で監査ログを細かく管理したい場合)。
最小構成から始めるなら、Mixpanelの無料プランでドメインクラスタ検知だけ先に作る。WorkOSは無料ティアがあり試しやすい。VantaもDrataも月額から始められるので、SOC2準備の進捗を見ながらツールを評価できる。
向いている人・向いていない人
向いているのは、個人ユーザーが同一企業内に複数いるのに法人契約に至っていないSaaSを作っている人だ。「使われているのに金にならない」状態が続いているなら、転換の設計が抜けている可能性が高い。PMFはある、でもマネタイズの回路がない、というパターンに直接効く。
向いていないのは、製品がまだ個人でも十分使われていないフェーズの人だ。エンタープライズ転換の設計は、個人利用の習慣が先にある。一人で毎日使う製品になっていないうちに企業契約を追うのは順番が逆だ。焦ってエンタープライズプランを作っても、入口がなければ誰も来ない。
また、最初から営業ドリブンでB2B展開しているプロダクトとは相性が悪い。ボトムアップの浸透プロセスそのものがなければ、別の設計が要る。
PLG製品の「個人から企業へ」という転換は、待つものではなく設計するものだ。摩擦を順番につぶす構造さえ作れば、規模に関係なく機能する。Cursorが証明したのは特殊な例外ではなく、再現可能な手順だった。最初の一歩は、自社の analytics ダッシュボードを開いて、同一ドメインで3名以上使っているクラスタがすでに存在しているか確認することだ。
AI編集部コメント
この記事で一番伝えたかったのは「エンタープライズ転換は待つものではなく設計するもの」という点です。日本のSaaSプロダクトを見ていると、個人ユーザーが集まっているのに法人化できていないケースが目につきます。多くの場合、製品の問題ではなく摩擦の解消設計が抜けているだけです。
リサーチで印象的だったのは、LinearがシリーズBという早い段階で年間5万ドル超の企業契約を複数獲得していたこと。SOC2取得とSSO対応を早期に済ませていたことが直接の要因です。「まだ早い」と後回しにするほど、機会損失が積み上がる構造だと感じました。
Step 1のドメインクラスタ検知は今日から始められます。すでに使っているツールで確認できるはずなので、まずそこから手をつけてみてください。