SaaSマーケティングの構造

誰に向けた本か

この本は、SaaSビジネスに関わるすべての人に向けて書いた。

マーケター、プロダクトマネージャー、カスタマーサクセス、事業責任者、創業者。肩書きを問わず、「なぜ成長が持続しないのか」「なぜ獲得しても獲得しても解約が追いつかないのか」と感じたことがある人へ。

特に、次のような悩みを抱えている人に読んでほしい。

• SEO、広告、ウェビナー。施策をこなしているが、成果が積み上がらない
• PLGを導入したが、フリーミアムにしても有料転換率が上がらない
• 競合が増えて、機能では差がつかなくなった
• 何を指標にすべきか分からない。MQL、PQL、NRR、どれを追うべき？

どれか一つでも心当たりがあるなら、この本には読む価値がある。

なぜ今この本を書いたのか

SaaSマーケティングの世界は、過去5年で根本的に変わった。

2020年代前半まで、PLG（Product-Led Growth）という言葉が業界を席巻した。フリーミアムにして、製品の力で顧客を獲得する。その考え方自体は正しい。しかし、多くの企業がPLGを「魔法の杖」のように扱い、そして失敗した。

なぜか。入り口を広げても、中身が伴わなければ意味がないからだ。

そこにAIが登場した。2024年以降、開発コストは劇的に下がった。一人で動くSaaSを24時間で作れる時代になった。マイクロSaaSが無限に生まれ、機能による差別化はほぼ不可能になった。

今、SaaSマーケティングに求められているのは、施策のカタログではない。

「なぜそれが機能するのか」「なぜうまくいかないのか」を説明できる構造の理解だ。

私は、この構造を「ループ」と呼んでいる。顧客の成功体験が、次の顧客を呼び込む循環。この循環を設計できるかどうかが、持続的な成長を決める。

この本は、そのループの設計図を提供する。

この本で得られること

読み終えたとき、あなたには三つの変化が起きている。

第一に、視点が変わる。

「どの施策を打つか」ではなく、「どんな構造を作るか」と考えるようになる。施策は手段であり、構造が目的だ。この視点の転換が、打ち手の幅を広げる。

第二に、優先順位が見える。

「何から手をつけるべきか」が自分で判断できるようになる。AIが答えを出してくれる時代に、なぜそれが正しいのかを説明できる力が、あなたの価値になる。

第三に、明日から動ける。

各章では、抽象的な原理だけでなく、具体的なアクションを示す。読んで終わり、ではなく、読んだ翌日から実践できる内容にした。

本書の読み方

この本は、16の章と終章で構成されている。

順番に読むことを勧めるが、必須ではない。

第1〜3章は「土台」だ。SaaSマーケティングの現在地と、ファネルからループへの転換を理解する。ここを飛ばすと、後の章が表面的になる。

第4〜8章は「設計図」だ。ループの各パーツ（接点、Aha!体験、解約、CRM、コミュニティ）を組み立てる。自社にとって優先度が高い章から読んでもいい。

第9〜10章は「組織と個人」だ。構造を動かすのは人である。組織をどう変え、自分をどう成長させるか。

第11〜13章は「事例」だ。具体例から学びたい人は、ここから読み始めてもいい。

第14章は「リスク」だ。PLGの失敗パターンを冷静に分析する。うまくいかないときに読み返してほしい。

第15章と終章は「未来」だ。エコシステム、成果連動型課金、そしてあなた自身のキャリアへの示唆。

著者から読者へのメッセージ

SaaSビジネスは、終わりのないマラソンのように感じることがある。

施策を打っても成果が出ない。成果が出ても持続しない。獲得しても解約で消える。その繰り返しに疲弊することもあるだろう。

私がこの本で伝えたいのは、その疲弊から抜け出す方法がある、ということだ。

それは「もっと頑張る」ではない。「構造を変える」だ。

構造を見る目を養えば、同じ努力でも成果が変わる。努力が積み上がるようになる。

ファネルからループへ。売ることから成功させることへ。

この転換を一緒に歩んでいこう。

あなたの成長を、この本が少しでも後押しできれば幸いだ。

さあ、第1章を開こう。

なぜ「良いプロダクト」だけでは勝てなくなったのか

「うちのプロダクトは、競合より機能が優れている」

この言葉を何度聞いただろうか。そして、その優位性が半年後には消えているのを、何度見てきただろうか。

SaaS市場で起きていることは、実にシンプルな構造変化である。かつて機能は「差異」だった。特定の課題を解決できるかどうかが、プロダクトの価値を決めた。ところが今、その差異は急速に縮小している。

理由は明快だ。

ひとつは、開発の民主化。ローコードツールの普及により、かつては専門エンジニアが数ヶ月かけて開発していた機能を、数週間で実装できるようになった。AIの進化がそれをさらに加速させている。コードを書けない人間が、アイデアを形にできる時代が来た。

もうひとつは、情報の透明化。競合がどんな機能を持っているか、どんなUIを採用しているか、すべてがオープンに観察できる。良い機能は即座にコピーされる。差異は生まれた瞬間から消滅へのカウントダウンを始める。

思い当たる節はないだろうか。

「先月リリースした新機能、もう競合も実装している」 「せっかく作った機能が、フリーのツールで代替できてしまう」 「機能比較表では勝っているのに、なぜか選ばれない」

これらはすべて、同じ構造から生まれている。機能という「差異」が価値を持っていた時代の終焉である。

正直に言えば、私自身もかつては「良いプロダクトを作れば売れる」と信じていた。技術的な優位性が市場での勝利に直結すると考えていた。しかし現実は違った。機能で勝っていても選ばれないプロダクトを、何度も見てきた。逆に、機能では劣っているのに圧倒的なシェアを取るプロダクトも見てきた。

その差は何か。本章から、その構造を解き明かしていく。

AIでマイクロSaaSが無限に生まれる時代の構造

2025年以降、SaaS市場に起きている最大の変化は「マイクロSaaS」の爆発的増加である。

マイクロSaaSとは、特定のニッチな課題だけを解決する小規模なSaaSを指す。請求書のPDF変換、AIによるメール要約、Excelの数式生成。かつては「そんな小さな市場で商売になるのか」と言われた領域に、無数のプロダクトが生まれている。

なぜか。答えは、参入障壁の消滅だ。

AIとローコードツールの組み合わせにより、個人や少人数チームが「動くプロダクト」を作れるようになった。開発コストが劇的に下がった結果、「月額数十万円の売上があれば成立する」ビジネスが現実的になった。

ExcelFormulaBot、CoverLetterGPT、UnicornPlatform。これらは個人または数人のチームが運営し、それぞれが月額数百万円規模の収益を上げている。一人で作って、一人で売って、一人で食べていける。そんな世界が現実になった。

この変化が既存のSaaS企業にもたらす影響は深刻である。

想像してほしい。自社プロダクトの「機能A」を切り出したマイクロSaaSが、無料または月額数百円で登場する。機能Aだけを使いたいユーザーは、わざわざ高額な総合ソリューションを契約する理由がなくなる。こうして顧客が流出していく。

機能の「バンドル」で価値を出すモデルが崩れ始めている。

では、既存のSaaS企業はどう戦えばいいのか。

答えは3つある。

第一に、垂直統合。特定の業界に深く入り込み、業務プロセス全体をデジタル化する。建設、医療、不動産など、業界固有の複雑さがある領域では、マイクロSaaSが入り込みにくい。

第二に、ワークフローへの食い込み。「便利な補助ツール」で終わらず、コア業務が回らなくなるほど深く組み込まれる。スイッチングコストを上げることで、機能比較だけでは選ばれない状態を作る。

第三に、信頼とブランド。エンタープライズ顧客が求めるのは、機能だけではない。セキュリティ、コンプライアンス、長期的なサポート体制。「この会社なら任せられる」という信頼は、マイクロSaaSでは代替できない。

気づいただろうか。これらすべてに共通するのは、「機能」ではなく「関係性」で勝負しているという点だ。

「売る」から「循環させる」へ。本書の全体像

SaaSマーケティングの教科書を開くと、たいてい「ファネル」が登場する。

認知→興味→検討→購入。上から下へ、顧客を流し込んでいく。広告を打ち、リードを獲得し、ナーチャリングして、商談に持ち込む。この「漏斗」のモデルが、長らくマーケティングの基本だった。

しかし、ファネル思考には致命的な欠陥がある。

「漏れる」のだ。

ファネルの各段階で顧客は離脱していく。上から100人入れて、下から出てくるのは数人。残りの90人以上は、どこかで消えていく。そしてまた、上から新しい100人を入れる。その繰り返しだ。

広告費は上がり続ける。競合も同じことをしているから、獲得コストは年々高騰する。消耗戦に突入する。

この構造には限界がある。

本書が提案するのは、「ファネル」から「ループ」への転換だ。

ループとは何か。一度入ってきた顧客の成功体験が、次の顧客を呼び込む循環構造である。

Dropboxを思い出してほしい。ユーザーが友人を招待すると、双方に追加容量が与えられる。ユーザーにとっては「得」であり、Dropboxにとっては「新規獲得」になる。広告を打たなくても、ユーザーが勝手に広めてくれる。

Slackはどうか。一人では使えない。チームで使って初めて価値が出る。だから、ユーザーは自発的に同僚を招待する。使う人が増えるほど、サービスの価値が上がる。

これがループの構造だ。

顧客の成功が、次の顧客を連れてくる。顧客が顧客を呼ぶ仕組みを、プロダクトとマーケティングの中に埋め込む。

本書では、このループをどう設計するかを体系的に解説する。

まず、SaaSマーケティングがどう進化してきたかを振り返る。Sales-Led、Marketing-Led、Product-Led、Customer-Led。それぞれの時代に何が機能し、何が限界だったのかを理解する。

次に、ループの設計方法を具体的に見ていく。アタッチメント（最初の接点）、Aha!体験（価値実感）、解約率の構造、CRMの使い方、コミュニティの設計。それぞれのパーツをどう組み立てるかを解説する。

さらに、実際の事例から「ループのパターン」を抽出する。Dropbox、Slack、Figma、Loom、Calendly。成功したSaaSが、どんな循環構造を持っているのか。

最後に、これからのSaaSマーケティングがどこへ向かうのかを展望する。エコシステム、成果連動型課金、垂直統合。次の10年を見据えた視点を提供する。

機能ではなく「構造」を見る視点へ

本章の冒頭で、機能競争の終焉を述べた。

しかし、より重要なのはその先だ。機能で勝てないなら、何で勝つのか。

答えは「構造」である。

機能とは、プロダクトが「できること」だ。請求書を発行できる、タスクを管理できる、分析レポートを出力できる。これらは目に見える。比較しやすい。だからこそ、すぐにコピーされる。

構造とは、プロダクトが「どう機能するか」だ。なぜ顧客はこのプロダクトを使い続けるのか。なぜ顧客は他の人にこのプロダクトを紹介するのか。なぜ顧客はこのプロダクトなしでは仕事が回らなくなるのか。

構造は目に見えにくい。だからこそ、コピーされにくい。

本書を通じて伝えたいのは、この「構造を見る視点」だ。

施策のカタログを提供するつもりはない。「こうすればうまくいく」という小手先のテクニックは、すぐに陳腐化する。そうではなく、なぜその施策が機能するのか、背後にある原理を理解してほしい。原理が分かれば、状況に応じて自分で施策を設計できる。

SaaSマーケティングは「売る」仕事ではない。「循環を設計する」仕事だ。

顧客の成功体験が、次の顧客を呼び込む。その循環を作ることが、これからのSaaSマーケターの仕事になる。

では、その循環をどう設計するか。

まずは、SaaSマーケティングがどのように進化してきたかを振り返ることから始めよう。歴史を知ることで、今どこにいるのか、次にどこへ向かうべきかが見えてくる。

Sales-Ledの時代：「人」と「関係」が売りだった

SaaSという言葉が生まれる前から、ソフトウェアは売られていた。

1990年代から2000年代初頭。エンタープライズソフトウェアの世界では、営業担当者こそが主役だった。スーツを着た営業マンが顧客のオフィスを訪問し、デモを行い、要件をヒアリングし、提案書を作り、契約を取り付ける。製品の機能よりも、「誰が売るか」が成約を左右した。

これがSaaS 1.0、Sales-Ledの時代である。

当時のソフトウェアは高額だった。オンプレミスで導入するため、初期費用だけで数千万円、大企業なら億を超えることも珍しくなかった。それだけの投資を決断させるには、人間の信頼関係が必要だった。

製品は売った後にカスタマイズされるのが前提だった。顧客ごとに要件が違い、標準機能だけでは足りない。だから営業は「何でもできます」と言い、導入後にSIerが作り込む。そんなモデルが主流だった。

振り返れば、Sales-Ledには合理性があった。

高単価・低頻度の取引では、一人ひとりの顧客に時間をかけることが許される。製品が複雑で、導入に専門知識が必要なら、人間が介在して説明するしかない。意思決定者が「誰から買うか」を重視する文化では、関係構築が最も効率的な戦略になる。

しかし、この時代には限界があった。

営業の数がボトルネックになる。属人的なスキルに依存するため、スケールしにくい。そして何より、顧客は「売り込まれる」ことに疲れ始めていた。

Marketing-Led/PLGの功罪：ファネルの限界

2010年頃から、潮目が変わり始めた。

クラウドの普及により、ソフトウェアの導入ハードルが劇的に下がった。初期費用ゼロ、月額課金、ブラウザからすぐ使える。「試しに使ってみる」ことが可能になった。

これがSaaS 2.0、Marketing-Ledの時代の幕開けである。

マーケティング部門が主役に躍り出た。SEO、コンテンツマーケティング、ウェビナー、ホワイトペーパー。大量のリードを獲得し、ナーチャリングして、「温まった」見込み客を営業に渡す。MQL（Marketing Qualified Lead）という概念が生まれ、マーケと営業の分業体制が確立された。

このモデルは一定の成功を収めた。営業一人に依存せず、効率的にリードを生成できる。コンテンツは資産として蓄積され、寝ている間にも見込み客を集めてくれる。

しかし、Marketing-Ledにも構造的な問題があった。

リードの「質」と「量」のトレードオフである。大量にリードを集めれば、その中には今すぐ買う気のない人も混じる。営業は「冷たいリード」に時間を取られ、効率が落ちる。マーケは「数」を追い、営業は「質」を求め、両者の間に軋轢が生まれる。

そして2015年頃から、次のパラダイムが登場する。Product-Led Growth、PLGだ。

PLGの思想はシンプルである。製品そのものをセールスパーソンにする。

無料トライアルやフリーミアムで、まず製品を使ってもらう。使ってみて価値を感じた人だけが、有料版に移行する。営業が説得する必要はない。製品が自らを売り込む。

Slack、Dropbox、Zoom、Notion。PLGで急成長したSaaSは枚挙にいとまがない。「営業ゼロで10億ドル企業になる」という夢が、現実のものになった。

だが、PLGにも落とし穴がある。

「使ってもらえば価値が伝わる」という前提が、常に成り立つわけではない。製品が複雑すぎる、ターゲットがITリテラシーの低い層、単価が高すぎるなど、PLGが機能しにくい条件は多い。

そして何より、PLGは「入り口」の話でしかない。無料で入ってきたユーザーが、有料に転換し、長く使い続けてくれるかは別問題だ。フリーミアムのユーザーを大量に抱えながら、有料転換率は数%という企業も少なくない。

ここに、次のパラダイムの芽がある。

Customer-Led/Community-Ledへの移行

PLGの限界が見えてきた2020年頃から、新しい概念が注目を集め始めた。

Customer-Led Growth。顧客主導の成長である。

Customer-Ledの核心は、「入り口」ではなく「定着と伴走」に焦点を当てることだ。

いくらユーザーを獲得しても、すぐに解約されては意味がない。LTV（顧客生涯価値）を最大化するには、顧客が成功体験を得られるよう支援し、長期的な関係を築く必要がある。

ここで重要になるのが、カスタマーサクセスの概念だ。

カスタマーサポートが「問い合わせに対応する」受動的な機能だとすれば、カスタマーサクセスは「顧客が成果を出せるよう能動的に支援する」機能である。待つのではなく、こちらから働きかける。問題が起きてから対処するのではなく、問題が起きる前に予防する。

カスタマーサクセスをコストセンターではなく、収益ドライバーとして位置づける。この発想の転換が、Customer-Ledの本質だ。

そして、Customer-Ledと並んで注目されているのが、Community-Led Growth（CLG）である。

CLGは、コミュニティの力で成長を加速させる戦略だ。

ユーザー同士が交流し、ナレッジを共有し、お互いの課題を解決し合う。企業はその場を提供し、ファシリテーターとして関与する。

SlackコミュニティやDiscordサーバー、日本ならLINEオープンチャットやnoteのサークル機能。こうした「たまり場」が、新規ユーザーの引き止め（リテンション）と呼び込み（獲得）の両方に効く。

なぜコミュニティが機能するのか。構造は明快だ。

人は、製品に対してはドライになれる。合理的に比較し、より良いものがあれば乗り換える。しかし、人間関係に対してはそうはいかない。コミュニティで仲間ができ、居場所ができると、そう簡単には離れられなくなる。

加えて、コミュニティはコンテンツを自動生成する。ユーザーが投稿した質問と回答、成功事例、失敗談。これらはすべて、新規ユーザーにとっての学習リソースになる。企業が一から作らなくても、コンテンツが勝手に積み上がっていく。

Customer-LedとCommunity-Ledは、どちらも「売った後」に焦点を当てている。

これが、現在のSaaSマーケティングのトレンドだ。

Ecosystem-Ledとは何か ─ 次の10年の主戦場

さて、ここまでの流れを整理しよう。

Sales-Led → Marketing-Led → Product-Led → Customer-Led/Community-Led。

各フェーズで、マーケティングの重心は移動してきた。営業から、マーケ部門へ。マーケ部門から、製品そのものへ。製品から、顧客との関係へ。

では、次はどこへ向かうのか。

私は、次の10年の主戦場は「Ecosystem-Led」になると見ている。

Ecosystem-Ledとは、単独のプロダクトとしてではなく、エコシステム（生態系）の一部としてポジションを取る戦略である。

具体的に言えば、APIファーストの設計だ。他のSaaSやツールと容易に連携し、顧客のワークフローの中に組み込まれる。単体で完結させるのではなく、他のツールと一緒に使われることを前提にする。

ZapierやMakeを見てほしい。それ自体が機能を持つというより、他のサービスをつなぐ「接着剤」として機能している。そして、その接着剤なしでは業務が回らなくなっている企業が無数にある。

Slackも同様だ。Slackの価値は、チャットツールとしての機能だけではない。あらゆるSaaSの通知がSlackに集約され、Slack上でワークフローが完結する。Slackを使わなくなることは、接続されたすべてのツールから切り離されることを意味する。

これがEcosystem-Ledの本質だ。単独のツールとして優れているだけでは足りない。エコシステムの中で「なくてはならない」ポジションを取る。

もうひとつの潮流が、Outcome-Based Pricing（成果連動型課金）だ。

従来のSaaS課金は、ユーザー数（シート）に基づくものが多かった。5人で使えば5ライセンス分、100人で使えば100ライセンス分。

しかし、この課金モデルには問題がある。AIの普及で、少人数でも大量の処理ができるようになった。シート数で課金すると、効率化が進むほど売上が下がるという逆説が生まれる。

そこで注目されているのが、成果連動型だ。売上増、コスト削減、処理件数など、顧客のビジネス成果に連動して課金する。

このモデルでは、顧客の成功と自社の収益が直結する。顧客が成果を出すほど、自社も儲かる。だからこそ、顧客の成功を本気で支援するインセンティブが生まれる。

Ecosystem-LedとOutcome-Based Pricing。この2つが、次の10年のSaaSマーケティングを規定するキーワードになると私は考えている。

では、このような大きな流れの中で、今日から何をすべきか。

まず必要なのは、「ファネル」から「ループ」への思考転換だ。次章では、この転換が何を意味するのか、より深く掘り下げていく。

なぜ「漏斗」思考では成長が頭打ちになるのか

「今月のMQL目標は500件」

マーケティング部門の会議で、こんな数字が飛び交っている光景は珍しくない。リード数を追い、広告費を投下し、ファネルの上から見込み客を流し込む。

この思考モデルを、私は「漏斗思考」と呼んでいる。

漏斗のイメージは明快だ。上が広く、下が狭い。認知→興味→検討→購入と、段階が進むにつれて人数が減っていく。上から1000人入れて、下から出てくるのは10人。コンバージョン率1%。この数字を改善することがマーケターの仕事だとされてきた。

しかし、この漏斗思考には致命的な構造問題がある。

それは「一方通行」だということだ。

上から入れて、下から出す。出た顧客はどこへ行くのか。漏斗の図には、その先が描かれていない。まるで、購入した瞬間に顧客の存在が消えてしまうかのようだ。

そして、漏斗は「漏れる」。各段階で見込み客が離脱していく。離脱した人たちはどこへ行くのか。競合に流れていく。あるいは、購買自体を諦める。いずれにせよ、もう戻ってこない。

漏れた分を補うために、また上から新しい見込み客を入れる。広告を打ち、コンテンツを作り、イベントを開く。終わりのない消耗戦が始まる。

広告費は年々高騰している。Google、Meta、LinkedInといった主要プラットフォームのCPC（クリック単価）は、毎年10〜20%上昇しているというデータもある。同じ数のリードを獲得するために、より多くのお金が必要になる。

これが、漏斗思考の限界だ。

では、どうすればいいのか。

答えは、漏斗を「ループ」に変えることだ。

「循環（ループ）」の5つのパターン

ループとは何か。一言でいえば、「出口が入口につながっている」構造である。

漏斗が一方通行なのに対し、ループは循環する。顧客がプロダクトを使い、価値を感じ、その体験が次の顧客を呼び込む。新しい顧客がまた価値を感じ、さらに次の顧客を呼び込む。自己増殖する仕組みだ。

私がこれまで観察してきたループには、大きく5つのパターンがある。

第一のパターン：招待報酬型

最も分かりやすいのがこれだ。ユーザーが他のユーザーを招待すると、双方に何らかのインセンティブが与えられる。

Dropboxが先駆者だ。友人を招待すると、招待した側も招待された側も、追加のストレージ容量がもらえる。ユーザーにとっては「得」であり、Dropboxにとっては「新規獲得」になる。広告費ゼロで、ユーザーが勝手に営業してくれる。

第二のパターン：コラボ必須型

プロダクトの性質上、一人では使えない。複数人で使って初めて価値が生まれる。

SlackやFigmaがこれに該当する。Slackを一人で使っても、ただのメモ帳だ。チームで使うからこそ、コミュニケーションツールとして機能する。だから、ユーザーは自発的に同僚を招待する。招待しないと、自分が使えないからだ。

第三のパターン：UGCシェア型

ユーザーが生成したコンテンツが、他のユーザーを引きつける磁石になる。

Spotify Wrappedを思い出してほしい。年末になると、自分の一年間の音楽視聴履歴がまとめられ、SNSでシェアしたくなるビジュアルとして提供される。みんながシェアすることで、Spotifyを使っていない人の目にも触れる。「自分も使ってみたい」という動機が生まれる。

第四のパターン：ワークフロー統合型

プロダクトの使用が、既存の業務フローの中に自然に組み込まれる。そして、その使用行為自体が、他者への露出機会を生む。

LoomやCalendlyが典型だ。Loomで録画した動画のリンクをメールで送る。受け取った相手は、Loomの存在を知る。Calendlyのスケジュールリンクを送る。相手は、Calendlyの便利さを体験する。ユーザーが普通に仕事をしているだけで、プロダクトが拡散していく。

第五のパターン：コミュニティ主導型

ユーザー同士がつながり、交流し、お互いに価値を提供し合う場を作る。その場の魅力が、新しいユーザーを引きつける。

前章で触れたCommunity-Led Growthがこれにあたる。コミュニティに参加しているユーザーの成功事例が発信され、それを見た外部の人が「自分も入りたい」と思う。コミュニティからコンテンツが生まれ、そのコンテンツが新規ユーザーを呼ぶ。

これら5つのパターンに共通するのは、「顧客の行動が、次の顧客を連れてくる」という構造だ。

顧客の成功体験が次の顧客を呼ぶ構造

ループが機能するかどうかを決める、最も重要な要素がある。

それは「成功体験」だ。

考えてみてほしい。なぜユーザーは、友人にプロダクトを紹介するのか。なぜ自分の成果をSNSでシェアするのか。なぜコミュニティで積極的に発信するのか。

答えは「自分が得をしたから」だ。

プロダクトを使って、仕事が楽になった。時間が節約できた。成果が上がった。その成功体験があるからこそ、他の人にも教えたくなる。成功体験がなければ、誰も紹介しない。

つまり、ループの起点は「顧客の成功」なのだ。

ここが、漏斗思考とループ思考の決定的な違いだ。

漏斗思考では、「獲得」がゴールになりがちだ。どうやってリードを集めるか、どうやって購入に至らせるか。購入した後のことは、後回しになる。

ループ思考では、「成功」がゴールになる。顧客がプロダクトを使って成果を出すこと。それが次の獲得につながる起点だからだ。

正直に言えば、多くのSaaS企業がここを見誤っている。

「PLGを導入すれば成長できる」と思い込み、フリーミアムにしたり、無料トライアルを始めたりする。しかし、肝心の「使った人が成功する」部分の設計が甘い。結果、無料ユーザーは大量に入ってくるが、有料転換しない。解約も止まらない。

入口だけ広げても、中身がなければループは回らない。

では、どうすれば顧客の成功を設計できるのか。それは第5章で詳しく扱う「Aha!体験」の話になる。ここでは、ループの全体構造を理解することに集中しよう。

ループ思考がCAC・LTVに与える影響

ループ思考への転換は、単なる概念の問題ではない。数字に直結する。

CAC（Customer Acquisition Cost、顧客獲得コスト）を考えてみよう。

漏斗思考では、CACは基本的に上がり続ける。広告市場は競争が激しく、同じクリックを奪い合う企業が増え続ける。SEOも競争が激化し、上位表示のためのコストは上がる。

ループが機能すると、状況が変わる。

既存顧客が新規顧客を連れてきてくれるなら、その分の獲得コストはゼロだ。Dropboxが招待プログラムで成長したとき、何が起きていたか。広告を打たなくても、ユーザーが増え続けた。CACは劇的に下がった。

次に、LTV（Lifetime Value、顧客生涯価値）を考えてみよう。

漏斗思考では、LTVを上げるために「もっと多くの機能を売る」「上位プランへアップセルする」という発想になりがちだ。押し売りの構造が生まれやすい。

ループ思考では、LTVは「顧客の成功」と結びつく。顧客が成功体験を得ている限り、製品を使い続ける理由がある。無理にアップセルしなくても、成功が定着を生む。

そして、ループがもたらす最大の変化は「成長の持続可能性」だ。

漏斗型の成長は、燃料を燃やし続けないと止まる。広告費を止めれば、リードの流入が止まる。コンテンツの生産を止めれば、検索流入が減っていく。常に入力を続けなければ、出力が止まる。

ループ型の成長は、一度回り始めると自走する。顧客が次の顧客を連れてくる構造ができていれば、広告を止めても成長が続く。もちろん、ループを加速させるための施策は必要だ。しかし、ゼロから積み上げる消耗戦ではなく、すでに回っている車輪を加速させる作業になる。

これが、ファネルからループへの転換が持つ意味だ。

「マーケティングの仕事が変わる」という言い方もできる。漏斗時代のマーケターは、上からリードを流し込む仕事をしていた。ループ時代のマーケターは、循環構造を設計する仕事をする。

前者は「どれだけ広告を打てるか」が勝負だった。後者は「どんな仕組みを作れるか」が勝負になる。リソースの量ではなく、設計の質が問われる。

ループ思考は、SaaSマーケティングのゲームルールを根本から変える。

ではそのループを機能させるために、何から始めるべきか。

まず必要なのは、顧客との最初の接点を作ること。次章では、この「アタッチメント戦略」について具体的に見ていこう。

PLG系ループ：無料ツール・テンプレートをマグネットにする

ループを回すには、まず誰かが入ってこなければならない。

当たり前のことだが、ここを軽視している企業は多い。「良いプロダクトを作れば人は来る」という幻想にとらわれ、入口の設計がおざなりになっている。

結論から言おう。最初の接点において最も効果的なのは、「無料で価値を提供すること」だ。

これはPLG（Product-Led Growth）の基本思想と通じる。製品そのものを体験してもらい、その価値を実感してもらう。実感した人だけが、次のステップに進む。

具体的には、3つのパターンがある。

無料ツール型

HubSpotのWebsite Graderを知っているだろうか。URLを入力すると、そのサイトのSEOやパフォーマンスを無料で診断してくれる。診断結果を見た人は「HubSpotって便利だな」と感じる。そして一部の人は、本体のマーケティングツールに興味を持つ。

重要なのは、この無料ツールがHubSpotの本業と関連していることだ。まったく無関係なものを提供しても意味がない。本業につながる領域で、価値ある体験を無料で提供する。

テンプレート型

Notionのテンプレートギャラリーは、それ自体がマーケティングツールになっている。プロジェクト管理、読書記録、習慣トラッカー、週次レビュー、OKR管理。数百種類のテンプレートが公開されていて、誰でも無料で使える。

テンプレートを使うためには、Notionに登録する必要がある。テンプレートという「餌」で釣って、製品に引き込む。そしてテンプレートを使い始めた人は、自然とNotionのヘビーユーザーになっていく。

フリーミアム型

最もスタンダードな形態だ。基本機能は無料で使えて、高度な機能やより多くの容量が必要な場合に有料版へ移行する。Slack、Zoom、Canvaなど、成功したSaaSの多くがこのモデルを採用している。

ただし、フリーミアムには落とし穴がある。無料でも十分使えてしまうと、誰も有料版に移行しない。かといって無料版を制限しすぎると、最初の価値体験が貧弱になる。このバランスが難しい。

いずれのパターンでも共通するのは、「売り込む前に価値を提供する」という順序だ。

従来の営業マインドでは、まず売って、それから価値を提供していた。PLG時代は順序が逆転する。まず価値を体験させ、価値を感じた人だけが買う。この順序の逆転が、初期の接点設計における最大のポイントである。

「Powered by」と共有リンクの仕掛け

無料で価値を提供する。しかし、それだけではループは回らない。

ループを回すためには、ユーザーの行動が「可視化」される仕組みが必要だ。ユーザーがプロダクトを使っていることが、外部から見える状態を作る。

最もシンプルな仕組みが「Powered by」ロゴだ。

無料版のユーザーが作成したページやコンテンツに、「Powered by 〇〇」というロゴが自動的に挿入される。見た人は「これ何だろう」と思ってクリックする。そこから新規ユーザーが生まれる。

Typeform、Calendly、Notion、Loom。いずれもこの仕組みを使っている。ユーザーが普通にプロダクトを使っているだけで、勝手に広告されていく。

共有リンクも同様の効果を持つ。

Loomで録画した動画を誰かに送る。相手はLoomのプレイヤーで動画を視聴する。「便利だな、自分も使ってみよう」と思う人が出てくる。動画を送るという普通の行為が、新規ユーザー獲得につながっている。

Calendlyも同じだ。スケジュール調整のリンクを相手に送る。相手はCalendlyの画面で日時を選ぶ。「自分もこういうツールが欲しい」と思った人が登録する。

この仕組みの美しいところは、ユーザーが意識的に「宣伝」しているわけではないことだ。普通に仕事をしているだけ。しかしその行為が、プロダクトの露出機会を生んでいる。

もうひとつ重要なのが、チーム招待機能の配置だ。

SlackやFigmaでは、チームメンバーを招待するボタンが目立つ場所にある。一人で使っても価値は限定的。チームで使って初めて本領が発揮される。だから招待を促す。

招待ボタンがどこにあるか。どれだけ目立つか。招待フローがどれだけスムーズか。こうした細部が、ウイルス係数（一人のユーザーが何人の新規ユーザーを連れてくるか）を左右する。

ループを設計するとは、こうした「仕掛け」を製品の中に埋め込むということだ。

コンテンツ×SEO×AI検索（GEO）の設計

ここまでの話は、すでにプロダクトに触れた人をどう増殖させるかだった。

しかし最初の一人は、どこから来るのか。

伝統的な答えは、SEOとコンテンツマーケティングだ。検索エンジンで上位表示され、そこから流入を得る。

2026年現在、この構造は変化している。AIの登場により、検索エンジン自体が変わりつつあるからだ。

従来のSEOでは、Googleの検索結果ページで上位に表示されることを目指した。キーワードを調査し、コンテンツを最適化し、被リンクを獲得する。

しかし今、ChatGPTやGemini、Perplexityなどの生成AIが、検索の入口になりつつある。ユーザーは検索エンジンではなく、AIに質問する。AIが情報をまとめて回答する。その回答の中で言及されることが、新しい「上位表示」になる。

これを「GEO（Generative Engine Optimization）」と呼ぶ人もいる。

GEOで重要なのは、AIが引用したくなるコンテンツを作ることだ。

具体的には何か。

まず、構造化されたデータだ。AIは明確に整理された情報を好む。表、リスト、定義。「〇〇とは」「〇〇の方法」「〇〇のメリットとデメリット」。こうした形式で記述されたコンテンツは、AIが回答を生成する際に参照されやすい。

次に、具体的な事例と数値だ。「売上が30%向上した」「導入から3ヶ月で効果が出た」。こうした具体的な成果は、AIの回答に説得力を与える材料になる。

そして、一次情報だ。自社で調査したデータ、自社顧客のケーススタディ、独自の見解。他では手に入らない情報は、AIが参照せざるを得ない。

とはいえ、従来のSEOが死んだわけではない。

Googleは依然として巨大なトラフィック源だ。長尾キーワード（具体的で競合が少ないキーワード）を攻めることで、効率よく流入を得ることはできる。「SaaSマーケティング」で上位表示するのは難しくても、「BtoB SaaS 解約率 改善方法」なら戦える可能性がある。

重要なのは、どちらか一方ではなく、両方を見据えることだ。従来のSEOでロングテールを取りながら、AIに引用されるコンテンツも作っていく。二つの流入経路を同時に育てる視点が必要だ。

接点から信頼へ。最初の一歩の構造

本章では、最初の接点をどう設計するかを見てきた。

無料ツールやテンプレートで価値を先に提供する。Powered byロゴや共有リンクで自然な露出を生む。SEOとGEOで検索からの流入を確保する。

しかし、ここで一つ注意がある。

接点を作ることと、信頼を得ることは別だ。

ユーザーがサイトに来た。無料ツールを使った。しかし、それで終わってしまうケースは多い。なぜか。信頼が生まれていないからだ。

「この会社、本当に信用できるのか」 「無料で釣っておいて、後で高額請求されるのでは」 「データを渡して大丈夫なのか」

こうした不安が、次のステップへの移行を妨げる。

信頼を構築するために必要なことが、いくつかある。

第一に、透明性だ。料金体系は明確に示す。無料版の制限事項も隠さない。「後出しジャンケン」をしない。

第二に、社会的証明だ。導入企業のロゴ、顧客の声、メディア掲載実績。「他の人も使っている」という事実が不安を和らげる。

第三に、専門性の証明だ。ブログ記事、ホワイトペーパー、ウェビナー。専門的なコンテンツを発信することで、「この会社は分かっている」という印象を与える。

接点の設計と、信頼の構築は、車の両輪である。どちらが欠けても、ループは回り始めない。

接点ができ、信頼が芽生えた。では次に、ユーザーにどんな体験をさせるべきか。

それが「Aha!体験」だ。ユーザーが「これだ！」と価値を実感する瞬間。この瞬間をどう設計するかが、次章のテーマになる。

TTVを短縮する ─ 初回ログインから数分で「わーっ」

SaaSの世界には、ある残酷な法則がある。

「最初の5分で価値を感じなければ、ユーザーは二度と戻ってこない」

誇張ではない。データがそれを示している。多くのSaaSにおいて、初回ログイン後に何も行動せずに離脱するユーザーは、再訪率が極めて低い。一度離脱した人を呼び戻すのは、新規獲得よりコストがかかることすらある。

だからこそ、TTV（Time to Value、価値実感までの時間）を最小化することが死活的に重要になる。

TTVとは、ユーザーがサインアップしてから「このツール、良いな」と思うまでの時間だ。この時間が短ければ短いほど、定着率は上がる。

では、「価値を感じる」とは具体的にどういう状態か。

それが「Aha!体験」だ。

Aha!体験とは、ユーザーが製品の核心的な価値を実感する瞬間を指す。「あ、これだ！」という閃きの瞬間。この一瞬があるかないかで、その後の行動が決定的に変わる。

Slackであれば、初めてチームメンバーとリアルタイムでやり取りできた瞬間。Notionであれば、自分だけのダッシュボードが形になった瞬間。Zoomであれば、ワンクリックでビデオ会議が始まった瞬間。

この瞬間を、できるだけ早く、できるだけ確実に訪れさせる。それがオンボーディング設計のすべてだと言っても過言ではない。

正直に言えば、私自身も多くのSaaSを試してきた中で、Aha!体験のないまま離脱したサービスは数えきれない。機能は揃っている。UIも悪くない。でも「何が良いのか」が分からないまま、画面を閉じてしまう。

そうしたサービスに共通するのは、最初のステップが複雑すぎることだ。

オンボーディングのUX設計原則

Aha!体験を早く訪れさせるために、オンボーディングのUXはどうあるべきか。

いくつかの原則がある。

原則1：最短経路を設計する

ユーザーがサインアップしてから、Aha!体験に至るまでの「最短経路」は何か。それを明確にする。

多くのSaaSは、ユーザーに選択肢を与えすぎる。「何ができるか」を全部見せようとする。結果、ユーザーは迷子になる。

そうではなく、「まずこれをやれ」という一本道を示す。Notionなら「最初のページを作ってみよう」。Slackなら「チームメンバーを1人招待してみよう」。一つのアクションに集中させる。

原則2：空っぽの画面を見せない

初回ログイン時、何もない真っ白な画面を見せることほど離脱を招くものはない。

人は空白を埋めることに抵抗を感じる。何を書けばいいか分からない。どこから手をつけていいか分からない。

解決策は簡単だ。デフォルトで何かが入っている状態を作る。サンプルデータ、テンプレート、チュートリアル用のダミー情報。「ゼロからのスタート」ではなく「ここから始められる」状態を用意する。

原則3：小さな成功を積み重ねる

いきなり大きなゴールを目指させない。小さなステップに分解し、一つずつ達成感を与える。

タスク管理ツールなら、まず「タスクを1つ作成する」。次に「そのタスクを完了にする」。チェックマークが入る。小さな達成感。これを繰り返す。

ゲーミフィケーションの要素を取り入れている製品も多い。プログレスバー、バッジ、レベルアップ。これらは単なる装飾ではない。「自分は前に進んでいる」という感覚を与えるための仕掛けだ。

原則4：摩擦を徹底的に排除する

サインアップに必要な情報を最小限にする。クレジットカード登録を後回しにする。入力フォームの項目を減らす。

Calendlyは、アカウント作成時にGoogleカレンダーとの連携だけを求める。それだけで、カレンダーと同期したスケジュールページが自動生成される。ユーザーは何も「設定」していないのに、もう使える状態になっている。

摩擦を減らすとは、ユーザーが「面倒だな」と思う瞬間をなくすことだ。

「習慣化」のトリガーをどこに埋め込むか

Aha!体験は入り口に過ぎない。

一度「良いな」と思っても、それが続かなければ意味がない。日常的に使われる習慣を作らなければ、やがて忘れられる。

習慣化の設計には、行動科学の知見が役立つ。

「フック・モデル」という概念がある。トリガー→行動→報酬→投資というサイクルを回すことで、習慣を形成するというものだ。

トリガーとは、行動を促すきっかけだ。通知、メール、定期的なリマインド。「〇〇さんがコメントしました」「今週のレポートが完成しました」。こうしたトリガーがユーザーを製品に呼び戻す。

ただし、トリガーの乱発は逆効果だ。通知が多すぎると、ユーザーはそれを無効化する。本当に必要なときだけ、価値のある情報を届ける。

行動は、できるだけ簡単にする。通知を見てワンクリックで該当画面に飛べる。アプリを開いたら、すべきことがすぐ分かる。

報酬は、行動した結果得られる満足感だ。タスクを完了した達成感。チームメンバーからのリアクション。分析レポートを見て得られる洞察。この報酬がなければ、行動は続かない。

投資とは、ユーザーが製品に蓄積するものだ。データ、設定、カスタマイズ、人間関係。投資が増えるほど、スイッチングコストが上がる。「ここまで積み上げたものを捨てるのはもったいない」という心理が働く。

この4つのサイクルを意識して、製品体験を設計する。

たとえば週次レポートの自動送信。毎週月曜日に「先週のアクティビティサマリー」がメールで届く。トリガーになる。そこから製品を開く。自分のデータを見る。報酬を感じる。そしてまた一週間使い続ける。投資が増える。

習慣化とは、このサイクルを回し続けることだ。

Aha!体験から定着へ。接続点の設計

本章では、Aha!体験とは何か、それをどう設計するかを見てきた。

TTVを短縮し、オンボーディングで最短経路を示し、習慣化のサイクルを回す。これらが組み合わさって、初めて「定着」が実現する。

ここで重要なのは、Aha!体験は一度きりではないということだ。

製品には複数の価値がある。ユーザーは使い続ける中で、新しい機能に触れ、新しい使い方を発見し、新しいAha!体験を得る。

Notionを例に取ろう。最初のAha!は「ページを作れた」かもしれない。使い続けるうちに「データベースが便利だ」と気づく。さらに使い込むと「APIで他のツールと連携できる」ことを知る。それぞれの段階で、新しい価値への気づきがある。

この「多層的なAha!」を設計することが、長期的なリテンションにつながる。最初のAha!だけで終わると、ユーザーはやがて物足りなさを感じる。新しい発見がなくなると、飽きる。

だから、ユーザーの成長に合わせて、次のAha!が訪れるよう設計する。この考え方を「アダプティブオンボーディング」と呼ぶ人もいる。

初心者には基本機能を教える。中級者には応用機能を紹介する。上級者には外部連携やカスタマイズを提案する。ユーザーがどのレベルにいるかを把握し、それに応じた体験を提供する。

Aha!体験は入り口だ。しかし、入り口で終わらせてはいけない。そこから先の道を、どこまでも続けていく。

ユーザーが製品を使い続け、価値を感じ続けている限り、解約は起こらない。逆に言えば、解約が起こるのは、価値を感じなくなったからだ。

では、なぜユーザーは価値を感じなくなるのか。解約率の構造を、次章で解き明かしていこう。

LTV/CACより先に、解約率を見よ

SaaSのユニットエコノミクスを語るとき、まず登場するのがLTV/CAC比率だ。

「LTVはCACの3倍以上あるべき」

どこかで聞いたことがあるだろう。この「3倍ルール」は業界の常識として広まっている。

しかし私は、この指標を見る前に見るべきものがあると考えている。

解約率だ。

理由は単純。解約率こそが、LTVを決定する最大の変数だからだ。

LTVの計算式を思い出してほしい。最もシンプルな形は「月額単価 ÷ 解約率」だ。月額1万円のサービスで、月次解約率が5%なら、LTVは20万円。解約率が2.5%なら、LTVは40万円。解約率が半分になると、LTVは倍になる。

つまり、解約率が1ポイント改善するだけで、LTVは劇的に変わる。

一方、CACを下げるのはどうか。広告費を削る、営業効率を上げる。できることはあるが、限界がある。そして競合も同じことをするから、構造的に上昇圧力がかかり続ける。

解約率の改善は、CACの削減より投資対効果が高いことが多い。にもかかわらず、多くの企業が獲得に資源を注ぎ、解約対策を後回しにしている。

これは構造的な問題だ。獲得はマーケットの仕事だと思われ、解約対策はカスタマーサクセスの仕事だと思われている。マーケティング部門は獲得数を追い、カスタマーサクセス部門は限られたリソースで既存顧客を抱えている。

しかしループ思考に立てば、これは一体の話だ。解約を減らすことは、獲得のコストを下げることと等価。いや、それ以上かもしれない。

まず解約率を見る。そこを改善する。それからLTV/CACを考える。順序を間違えてはいけない。

「離脱しそうなアカウント」を検知する仕組み

解約は突然起きるように見えて、実はそうではない。

解約に至るまでには、必ず予兆がある。その予兆を捉え、介入することで、多くの解約は防げる。

では、どんな予兆があるのか。

最も分かりやすいのは、利用頻度の低下だ。毎日ログインしていたユーザーが、週に一度になり、月に一度になる。これは明確な危険信号だ。

機能利用の偏りも見逃せない。コア機能を使わず、周辺機能だけを触っている。本来の価値を享受できていない可能性がある。

ユーザー数の減少も重要だ。チームで使っているサービスで、アクティブユーザーが減っていく。残っているのが管理者だけ。これは解約が近い兆候だ。

サポートへの問い合わせパターンも示唆を与える。問い合わせが急に増えた場合、何かに困っている。逆に、問い合わせがゼロになった場合も危険。使っていないから質問もないのかもしれない。

これらの予兆を組み合わせて、「ヘルススコア」を設計する企業が増えている。

ヘルススコアとは、アカウントごとの「健康状態」を数値化したものだ。ログイン頻度、機能利用状況、サポート問い合わせ、契約期間残りなどを変数として、スコアを算出する。

スコアが一定以下になったアカウントは「リスク顧客」としてフラグが立つ。カスタマーサクセスチームが優先的にアプローチする。

重要なのは、待ちの姿勢ではなく、攻めの姿勢だ。解約の申し出があってから慌てても遅い。その前に検知し、介入する。

とはいえ、ヘルススコアは万能ではない。スコアが高くても解約する顧客はいる。予算の問題、組織変更、事業撤退。外部要因による解約は予測が難しい。

できることとできないことを分ける冷静さも必要だ。

カスタマーサポート＝コストセンターという誤解

多くの企業で、カスタマーサポートは「コストセンター」として扱われている。

経費を削減すべき部門。人件費を抑えるためにチャットボットを導入する部門。顧客満足度調査のスコアを追いかける部門。

この認識は、根本的に間違っている。

カスタマーサポートは、顧客との最前線だ。製品に対する不満、要望、期待。生の声が集まる場所だ。この情報をどう使うかで、プロダクトの進化が決まる。

問い合わせが来たとき、それは単なる「対応すべき案件」ではない。「顧客が何に困っているか」を知るチャンスだ。同じ質問が繰り返し来るなら、UIが分かりにくいのかもしれない。特定の機能への問い合わせが多いなら、そこに改善の余地がある。

私が見てきた優れたSaaS企業には、共通点がある。サポートチームがプロダクトチームと密に連携していることだ。

問い合わせの傾向分析を週次でプロダクトチームに共有する。よくある質問をUIの改善につなげる。顧客の声を機能開発のロードマップに反映する。

サポートを「対応」で終わらせるのではなく、「改善」につなげる。この差が、長期的なプロダクトの競争力を左右する。

そしてもうひとつ。サポートの品質は、そのまま顧客ロイヤルティに影響する。

問題が起きたとき、迅速かつ丁寧に対応された顧客は、ファンになる。逆に、たらい回しにされた顧客は、二度と戻ってこない。

「神対応」がSNSで拡散されることがある。あれは単なるPRではない。顧客との接点で起きた、小さな感動の積み重ねだ。

コストセンターという発想を捨てよう。サポートは、ロイヤルティを生み出す装置だ。

解約を減らすことが成長エンジンになる構造

解約率を下げることが、なぜ「成長」につながるのか。改めて整理しよう。

まず、LTVの向上だ。解約が減れば、顧客一人あたりの生涯価値が上がる。同じ獲得数でも、売上は増える。

次に、CACの実質的な低下だ。穴の空いたバケツに水を入れ続ける状態から、しっかり水を貯められる状態になる。獲得の努力が無駄にならない。

そして、NRR（Net Revenue Retention）への影響だ。NRRとは、既存顧客からの収益がどれだけ維持・拡大されているかを示す指標。解約が減り、アップセル・クロスセルが増えれば、NRRは100%を超える。新規獲得がゼロでも売上が成長する状態を作れる。

Slackの上場時のNRRは143%だった。既存顧客だけで、毎年43%成長していたということだ。新規獲得は上乗せに過ぎない。

この構造を理解すると、成長戦略の優先順位が変わる。

「新規をどれだけ獲るか」よりも、「既存をどれだけ維持・拡大できるか」が先に来る。マーケティング部門とカスタマーサクセス部門の連携が必須になる。むしろ、境界自体が曖昧になっていく。

解約を減らすことは守りではない。最も効率的な攻めだ。

そのためには、顧客を深く理解する必要がある。顧客が何を望み、何に困り、何を達成しようとしているのか。それを知るための仕組みが、CRMだ。

次章では、AI時代のCRMをどう再定義すべきか見ていこう。

「誰がどこでつまずいているか」を可視化する

CRM（Customer Relationship Management）という言葉を聞いて、何を思い浮かべるだろうか。

Salesforce、HubSpot、Zoho。こうしたツールの名前が浮かんだかもしれない。あるいは「顧客データベース」「営業進捗管理」「名刺管理」。

多くの企業でCRMは、「データを貯める箱」として使われている。顧客情報を入力し、商談履歴を記録し、売上予測に使う。営業マネージャーがパイプラインを可視化するための道具。

これは、CRMの使い方としては半分しか正しくない。

本来、CRMは「顧客を理解する」ためのツールだ。単にデータを貯めるのではなく、そのデータから洞察を引き出す。顧客が何に困っているか、何を求めているか、どこでつまずいているかを明らかにする。

この視点で見ると、CRMの使い方が根本的に変わる。

具体的に見ていこう。

まず「顧客セグメント」の話だ。従来のセグメントは、企業規模、業界、地域など、静的な属性で分類していた。

AI時代のセグメントは、行動ベースになる。どの機能をどれだけ使っているか。オンボーディングを完了したか。過去3ヶ月のログイン頻度はどうか。こうした動的なデータでセグメントを作る。

「大企業の顧客」と「中小企業の顧客」を分けるより、「アクティブに使っている顧客」と「休眠状態の顧客」を分ける方が、打ち手が明確になる。

次に「つまずきポイントの特定」だ。ユーザーがどこで離脱しているかを、ファネルごとに可視化する。

サインアップはしたが、初回ログインをしていない。ログインしたが、最初のアクションを取っていない。アクションは取ったが、2回目のログインがない。どの段階で止まっているかを見れば、どこに課題があるか分かる。

CRMをプロダクトアナリティクスと連携させることで、こうした可視化が可能になる。Amplitude、Mixpanel、Heap。こうしたツールとCRMを統合し、行動データを顧客データに紐づける。

行動データとフィードバックの統合

データには二種類ある。行動データと、声のデータだ。

行動データは、ユーザーが製品内で何をしたかを示す。クリック、ページビュー、機能利用、滞在時間。ユーザーが意識せずに残す「足跡」だ。

声のデータは、ユーザーが意識的に発した情報だ。サポートへの問い合わせ、アンケート回答、NPS（顧客推奨度）のコメント、SNSでの発言。

この二つを組み合わせることで、より立体的な顧客理解が得られる。

たとえば、ある機能のNPSスコアが低いとする。ユーザーは「使いにくい」と言っている。なぜ使いにくいのか。行動データを見る。その機能のページで離脱が多いポイントがある。UIを確認すると、ボタンの位置が分かりにくい。

声だけでは「使いにくい」という事実しか分からない。行動データと組み合わせて初めて、「なぜ使いにくいのか」が見えてくる。

逆のパターンもある。行動データ上は問題ないように見えるが、ユーザーからのフィードバックでは不満の声が上がっている。これは「使えるけれど、本当に欲しいものではない」可能性を示唆する。機能としては動いているが、ユーザーの本質的なニーズを満たしていない。

AI時代になって、この統合はより容易になった。

大量のサポートチケットをAIで分類し、頻出テーマを抽出する。SNSのメンションを自動収集し、感情分析にかける。アンケートの自由記述をクラスタリングし、共通する課題を特定する。

人間がすべてを読む必要はない。AIが下処理を行い、人間が洞察を引き出す。この分業が、顧客理解のスピードを劇的に上げる。

「あなたの声でこう変わりました」のUI表示

データを集め、分析し、改善する。それは企業側の話だ。

ここで忘れがちなのが、「顧客に伝える」ことだ。

フィードバックを送った顧客は、それがどうなったか知りたい。自分の声が届いているのか、無視されているのか。反映されたのか、されなかったのか。

多くの企業は、この「閉じるループ」を設計していない。顧客からフィードバックを集めるだけ集めて、その後が見えない。

これは機会損失だ。

「お客様の声で、この機能が改善されました」

製品のリリースノートやUI上でこのメッセージを表示するだけで、顧客との関係は変わる。「自分の声が反映された」という実感は、ロイヤルティを生む。

いくつかの具体的な方法がある。

リリースノートで「Customer Requested」タグをつける。どの改善が顧客からのリクエストに基づいているかを明示する。

フィードバックを送ったユーザーに個別通知を送る。「以前リクエストいただいた機能がリリースされました」。パーソナライズされた連絡は、汎用的なアナウンスより響く。

製品内で「What's New」セクションを設け、改善の背景を説明する。なぜこの機能を追加したか。どんな課題を解決するか。ストーリーとして伝える。

こうした工夫により、顧客は「この会社は自分の声を聞いている」と感じる。解約の抑止にもなるし、紹介の動機にもなる。

閉じたループは、信頼のループを回す仕掛けでもある。

データではなく「洞察」を得るためのCRMへ

本章の冒頭で、CRMは「データを貯める箱」として使われていると述べた。

この状態から抜け出すには、発想の転換が必要だ。CRMの価値は「貯めたデータの量」ではなく「得られた洞察の質」で測るべきだ。

洞察とは何か。それは「だから何をすべきか」が分かる情報だ。

「顧客Aは過去30日でログインが50%減少した」はデータだ。 「顧客Aは解約リスクが高い。今週中にCSからコンタクトすべき」は洞察だ。

「機能Xの利用率は15%」はデータだ。 「機能Xは価値が伝わっていない。オンボーディングで紹介するか、UIを改善すべき」は洞察だ。

データから洞察への変換。これがCRMを使いこなす本質だ。

そのためには、いくつかの条件が必要になる。

第一に、データの統合。CRM、プロダクトアナリティクス、サポートツール、マーケティングオートメーション。これらがバラバラでは、全体像が見えない。統合プラットフォームを構築するか、ツール間の連携を整備する必要がある。

第二に、適切な問いの設定。「何を知りたいのか」が明確でなければ、データを眺めても何も分からない。「なぜ解約率が上がっているのか」「どのセグメントで満足度が低いのか」。具体的な問いから始める。

第三に、分析のリテラシー。データを読み解き、示唆を引き出す能力。これはマーケターだけでなく、カスタマーサクセス、プロダクト、営業、すべてのチームに求められる。

AI時代のCRMは、単なる顧客データベースではない。顧客を理解し、次のアクションを導くインテリジェンスエンジンだ。

顧客理解が深まると、何が可能になるか。一人ひとりに寄り添った対応ができる。それが信頼を生み、定着につながり、紹介を生む。

しかし、一人ひとりに対応するにはリソースの限界がある。そこで登場するのが「コミュニティ」という仕組みだ。

次章では、コミュニティ主導成長（CLG）の設計について見ていこう。

なぜコミュニティが成長エンジンになるのか

「コミュニティを作ろう」

この言葉が、SaaS業界で頻繁に聞かれるようになった。しかし、多くの企業がコミュニティを始め、そして多くが失敗している。

なぜか。コミュニティの「構造」を理解していないからだ。

コミュニティが成長エンジンになる理由は、三つある。

第一に、リテンション効果だ。人は製品には飽きるが、人間関係には飽きにくい。コミュニティで仲間ができ、居場所ができると、製品を使い続ける理由が増える。製品の機能だけでは代替されるが、コミュニティは代替できない。

第二に、サポートコストの削減だ。ユーザー同士が質問に答え合う。公式サポートに来る前に、コミュニティで解決される。企業のリソースをかけずに、顧客の課題が解消される。

第三に、コンテンツの自動生成だ。コミュニティでの質問、回答、議論、事例共有。これらはすべてコンテンツとして蓄積される。SEOにも効く。新規ユーザーがコミュニティの過去ログを見て問題を解決する。

そして最も重要なのが、獲得への寄与だ。コミュニティ自体が「この製品を使うとこんな仲間ができる」という訴求になる。成功事例がコミュニティから発信され、それを見た外部の人が興味を持つ。

これがCommunity-Led Growth（CLG）の構造だ。

ただし、注意が必要だ。コミュニティは「作れば人が来る」ものではない。そして「人が来れば回る」ものでもない。設計と運営の両方に、専門的な知見が必要になる。

Slack/Discord/LINEオープンチャットの使い分け

コミュニティを作るとして、どのプラットフォームを使うべきか。

日本市場でよく使われるのは、Slack、Discord、LINEオープンチャットの三つだ。それぞれに特徴がある。

Slack

ビジネス利用に馴染みがある。多くの企業が社内コミュニケーションにSlackを使っているため、新しいツールを覚える必要がない。チャンネル構造が明確で、トピックごとの整理がしやすい。

欠点は、無料版の検索制限だ。90日以上前のメッセージが検索できなくなる。ナレッジの蓄積という点では不利。有料版を企業が負担するか、別のナレッジベースと併用する必要がある。

BtoB SaaSのコミュニティには向いている。ターゲットがビジネスパーソンであれば、Slackの操作に抵抗はないだろう。

Discord

ゲーマー発祥のプラットフォームだが、今や幅広いコミュニティで使われている。音声チャンネル、ボット、ロールなど、機能が豊富。コミュニティの「盛り上がり感」を演出しやすい。

欠点は、日本のビジネスパーソンには馴染みが薄いこと。「ゲームのツールでしょ？」という先入観がある。ターゲットがテック寄りの人であれば問題ないが、一般企業の担当者だとハードルが高い。

開発者コミュニティ、スタートアップ界隈、若年層向けには相性が良い。

LINEオープンチャット

日本では圧倒的にリーチが広い。LINEを使っていない人を探す方が難しい。参加ハードルが極めて低い。

欠点は、機能の限定性だ。チャンネル分けができない、検索性が低い、アーカイブ性が弱い。深い議論やナレッジ蓄積には向かない。「ライトな情報共有」「イベント告知」「クイックなQ&A」に適している。

幅広い層をターゲットにするBtoC寄りのサービス、あるいはBtoBでもITリテラシーが低い顧客層には有効だ。

結論として、「誰のためのコミュニティか」によって選択が変わる。ターゲット顧客が普段使っているツールに合わせるのが原則だ。

ユーザー同士のナレッジ共有が引き止めと呼び込みになる構造

コミュニティが「成長エンジン」になるためには、ユーザー同士のナレッジ共有が活発に行われる必要がある。

質問が投稿され、他のユーザーが回答する。使い方のTipsが共有される。成功事例が紹介される。この循環が生まれると、コミュニティは自走し始める。

なぜナレッジ共有がリテンションに効くのか。

まず、問題解決速度だ。公式サポートに問い合わせるより、コミュニティで聞く方が早いことがある。同じ問題に直面したことがあるユーザーが、すぐに答えてくれる。問題が解決すれば、製品を使い続けることができる。

次に、使い方のインスピレーションだ。「こんな使い方があるのか」という発見。自分では思いつかなかった使い方を知ることで、製品の価値が広がる。価値が広がれば、使い続ける理由が増える。

そして、帰属意識だ。コミュニティで発言し、貢献し、認められる。「自分はこの製品のユーザーコミュニティの一員だ」というアイデンティティが形成される。これは製品への愛着とは別次元の結びつきだ。

なぜナレッジ共有が獲得に効くのか。

コミュニティでのやり取りは、しばしば外部からも見えるようにする。Slackは基本クローズドだが、公開チャンネルを作る企業もある。Discordは読み取り専用の公開サーバーを設定できる。LINEオープンチャットは名前から検索可能だ。

外部の人がコミュニティを覗いて、「活発な議論がされている」「困ったときに助けてもらえそう」「使っている人が楽しそう」と感じる。これが参加動機になり、製品の試用動機になる。

さらに、コミュニティの中で生まれた成功事例がブログやSNSで発信される。「このツールで売上が2倍になった」「業務効率が劇的に改善した」。ユーザー自身の言葉での発信は、企業の広告より信頼される。

ナレッジ共有は、引き止め（リテンション）と呼び込み（獲得）の両方に効く。だからこそ、いかにナレッジ共有を促進するかがコミュニティ設計の核心になる。

企業は「司会・進行」に徹する ─ コミュニティ運営の要諦

コミュニティ運営で最もやってはいけないことがある。

「企業がコンテンツを発信し続けること」だ。

これは一見すると正しいように見える。コミュニティを盛り上げるために、企業がどんどん情報を発信する。しかし、これをやると、コミュニティは「企業のブログ」になってしまう。ユーザーは消費者として情報を受け取るだけで、発信者にはなれない。

コミュニティの価値は、ユーザー同士が交流することにある。企業の役割は、その交流を促進することだ。

具体的には何をすべきか。

第一に、場を設定する。テーマごとのチャンネル分け、自己紹介スレッドの用意、ルールの明示。ユーザーが発言しやすい環境を整える。

第二に、最初の火をつける。立ち上げ期は、企業側から話題を振る必要がある。「皆さんはどんな使い方をしていますか？」「この課題をどう解決していますか？」。問いかけからスタートする。

第三に、発言に反応する。ユーザーが投稿したら、必ずリアクションする。スタンプでもいい。無視されると、次から発言しなくなる。

第四に、貢献者を称える。たくさん回答しているユーザー、有益なTipsを共有しているユーザー。彼らにスポットライトを当てる。公式ブログでのインタビュー、限定オンラインイベントへの招待、特別なバッジの付与。承認欲求は強いモチベーションになる。

第五に、イベントを仕掛ける。定期的なミートアップ、オンラインセミナー、ユーザー同士の交流会。イベントはコミュニティの求心力を高める。

企業は司会者であり、舞台の設営者だ。主役はユーザーである。この原則を忘れると、コミュニティは形骸化する。

コミュニティ主導成長は、一朝一夕には実現しない。時間をかけて育てていく必要がある。しかし、一度機能し始めると、広告に依存しない持続可能な成長エンジンになる。

ここまで、個人や顧客に焦点を当ててきた。では、組織全体としてはどうあるべきか。

次章では、「伴走型組織」への転換について見ていこう。

BtoBバイヤーの行動変化：すでに選定した状態で接触する

営業に会う前に、顧客はすでに決めている。

これは大げさな表現ではない。調査によれば、BtoB購買プロセスの60〜70%は、営業担当者と接触する前に完了しているという。Webで情報を調べ、事例を読み、比較サイトをチェックし、同業者に聞く。そして「このツールを検討しよう」と決めてから、問い合わせフォームを送る。

この変化は何を意味するのか。

営業の「説得力」が、以前ほど効かなくなっているということだ。顧客はすでに自分なりの結論を持っている状態で現れる。そこから180度覆すのは難しい。

だからといって、営業が不要になったわけではない。役割が変わったのだ。

従来の営業は「教える」立場だった。製品の価値を伝え、競合との違いを説明し、導入のメリットを語る。情報の非対称性を利用して、顧客を説得する。

現在の営業は「一緒に考える」立場になる。顧客が抱えている課題を深く理解し、その課題にどうアプローチすべきかを一緒に探る。製品が解決策の一つになるかもしれないし、ならないかもしれない。

このスタンスの変化を、私は「伴走」と呼んでいる。

伴走とは、顧客の隣を走ることだ。前から引っ張るのでも、後ろから押すのでもない。同じ方向を向いて、並んで走る。

これができる組織と、できない組織で、成果は大きく分かれる。

説得より信頼、説明より伴走

なぜ「説得」が効かなくなったのか。もう少し掘り下げよう。

情報過多の時代だからだ。

顧客は毎日、大量のセールスメール、広告、ウェビナー招待にさらされている。どの企業も「うちの製品が一番」と主張する。主張のレベルでは差がつかない。

その中で選ばれるために必要なのは、「この人（会社）は信頼できる」と思ってもらうことだ。

信頼はどうやって生まれるか。

一つは、有益な情報を無料で提供することだ。売り込みではなく、顧客の課題解決に役立つコンテンツを発信する。「この会社は自分のことを売りたいだけじゃなく、本当に役立つことを教えてくれる」という印象が形成される。

もう一つは、聞く姿勢だ。自社の製品がいかに素晴らしいかを語る前に、顧客の状況を深く聞く。何に困っているのか。なぜそれが問題なのか。これまで何を試したか。聞くことで、「この人は自分のことを理解しようとしてくれている」と感じてもらえる。

そして、正直であることだ。自社製品が顧客の課題にフィットしないと思ったら、そう伝える。場合によっては、他社製品を勧めることすらある。これは短期的には売上を逃すが、長期的には信頼につながる。

営業のKPIを「商談化数」「成約数」だけで測っていると、こうした行動は生まれにくい。「顧客の成功」を中心に据えた評価指標が必要になる。

導入前・導入時・導入後の伴走設計

伴走は営業だけの話ではない。顧客との接点すべてに関わる。

顧客のジャーニーを三つに分けて考えよう。導入前、導入時、導入後だ。

導入前の伴走

これは主にマーケティングと営業が担う。

教育コンテンツの提供が基本だ。ブログ、ホワイトペーパー、ウェビナー、事例集。顧客が「この領域について学びたい」と思ったときに、有益な情報を見つけられるようにする。

相談窓口を設けるのも有効だ。チャットボット、オンライン相談会、お問い合わせへの丁寧な対応。「まだ買うかどうか決めていないけど、話を聞いてほしい」という顧客に門戸を開く。

無料トライアルやフリーミアムも導入前の伴走だ。言葉ではなく体験で価値を伝える。

導入時の伴走

オンボーディングが中心になる。

キックオフミーティングで目標を擦り合わせる。「何を達成したいのか」「成功とは何か」を明確にする。これがなければ、後の評価ができない。

設定サポート、データ移行支援、初期トレーニング。製品を使い始めるまでの障壁を徹底的に取り除く。

進捗確認のタッチポイントを設ける。「ここまで来ました」「次はここです」。マイルストーンを見せることで、顧客は前進を実感できる。

導入後の伴走

カスタマーサクセスの領域だ。

定期的なビジネスレビューを行う。「最初に設定した目標に対して、どれくらい進んでいますか」。成果を振り返り、次のアクションを決める。

製品の使われ方を広げるサポートも重要だ。「新機能がリリースされました」「こんな使い方ができます」。製品の価値を継続的に提示する。

解約リスクの検知と介入は前章で述べた通りだ。利用が減ってきたら、能動的にアプローチする。

導入前・導入時・導入後。この全体を通じて、一貫した伴走体験を提供する。どこかで途切れると、顧客は「急にほったらかされた」と感じる。

営業・CS・マーケの壁を溶かす構造

伴走型組織を実現するには、部門間の壁を溶かす必要がある。

従来の組織では、マーケがリードを集め、営業が成約し、カスタマーサクセスが定着を担う。それぞれの部門が、それぞれのKPIを追う。引き継ぎの瞬間、顧客情報がロストすることも珍しくない。

顧客から見ると、これは分断された体験になる。「マーケの人と話したこと、営業の人に伝わっていないな」「導入時に相談したこと、サポートに伝わっていないな」。

この分断を解消するには、いくつかのアプローチがある。

第一に、顧客情報の一元管理だ。CRMを核にして、すべてのタッチポイントの履歴を統合する。マーケがどのコンテンツに接触したか、営業がどんな商談をしたか、CSがどんなサポートをしたか。全員が同じ情報を見れる状態を作る。

第二に、共通の成功指標だ。NRR、顧客満足度、NPSなど、顧客の成功を測る指標を全部門で共有する。部門ごとに違う指標を追っていると、部分最適に陥る。

第三に、クロスファンクショナルなミーティングだ。週次で部門横断の顧客レビューを行う。「この顧客は今こういう状態」「ここに課題がある」。情報を共有し、連携プレイを設計する。

第四に、役割の越境を歓迎する文化だ。営業がCSの仕事を手伝う、CSがマーケのコンテンツ作成に関わる。境界をまたぐ動きを推奨する。

組織の壁を溶かすのは簡単ではない。歴史、利害、プライド。複数の要素が絡み合っている。しかし、顧客視点に立てば、壁など存在すべきではない。

顧客は一つの体験を求めている。それに応えられる組織が、選ばれる時代になった。

組織の話をしてきた。では、個人としてのSaaSマーケターは、どのように進化すべきか。

次章では、キャリアの観点から「施策の実行者」から「構造の設計者」への進化を考えていこう。

施策をこなす人と、構造を見る人の違い

同じ会社で働いていても、明らかに「見えている景色」が違う人がいる。

ある人は「今週はSEO記事を3本書いた」「広告のCPCが下がった」「ウェビナーの参加者が増えた」と報告する。施策の実行と、その結果の計測。これが仕事だと考えている。

別の人は「なぜこの施策が効いているのか」「このチャネルと他のチャネルはどう関係しているか」「今の延長線上に何があるか」を考えている。施策の背後にある構造を見ようとしている。

前者は「実行者」であり、後者は「設計者」だ。

実行者は価値がないと言いたいわけではない。実行なしに成果は生まれない。しかし、実行だけでは「替えの利く人材」にとどまる。ツールが進化し、AIが普及するにつれ、単純な実行は自動化されていく。

設計者は「なぜ」を問う人だ。なぜこの施策が効くのか。なぜ他社でうまくいったことが自社でうまくいかないのか。なぜ顧客はこの行動を取るのか。

「なぜ」への答えが見えると、打ち手の幅が広がる。定石通りにやるだけでなく、自社の状況に合わせた施策を設計できる。前例のない課題にも対応できる。

SaaSマーケティングの教科書には、いくつもの「ベストプラクティス」が載っている。しかし、それをそのまま真似しても成果が出ないことがある。自社のプロダクト、顧客、市場環境が違うからだ。

構造を見る目があれば、ベストプラクティスの「転用可能な部分」と「適用できない部分」を見分けられる。

PLGの次を見据えるキャリア戦略

SaaSマーケターとして、どのようなスキルを磨くべきか。

従来は「チャネル別」のスペシャリティが重視されていた。SEOの専門家、広告運用のプロ、コンテンツマーケティングのエキスパート。それぞれのチャネルを深く極めることが、キャリアの王道だった。

これは今も有効だ。ただし、それだけでは足りなくなっている。

第一に、チャネル横断の視点が必要だ。SEOと広告とコンテンツとPRは、バラバラに存在しているのではない。相互に影響し合い、顧客のジャーニー全体を形成している。どこかひとつを最適化しても、全体最適にはならない。

第二に、プロダクトへの理解が必要だ。PLG時代において、マーケティングとプロダクトの境界は曖昧になっている。製品の中にマーケティングを埋め込む。オンボーディングもリテンションもマーケティングの射程に入る。

第三に、データリテラシーが必要だ。どんな施策を打つにしても、効果検証ができなければ改善できない。データを収集し、分析し、示唆を引き出す能力。これがなければ、勘と経験に頼ることになる。

第四に、顧客理解の深さが必要だ。ペルソナをパワポに書いて終わりではない。実際の顧客に話を聞き、行動データを読み、「なぜこの人はこう行動するのか」を腹落ちするまで理解する。

これらを総合すると、「グロースマネージャー」とでも呼ぶべき役割像が浮かび上がる。チャネルを横断し、プロダクトと連携し、データを読み、顧客を深く理解する。成長の構造全体を設計できる人材だ。

「界隈」に群れず、差異を作る

SaaSマーケティングの世界には、「界隈」がある。

Twitter（X）でよく見る名前、ウェビナーの常連講師、コミュニティの中心にいる人たち。彼らが発信する情報は有益だし、つながりを持つことにも意味がある。

しかし、注意が必要だ。

界隈の中にいると、「そこで当たり前とされていること」に染まっていく。最新のトレンド、よく使われるフレームワーク、業界の共通言語。知っていることは悪いことではない。問題は、それが「思考の枠」になってしまうことだ。

みんなが同じことを言っているとき、そこに差異はない。PLGが流行れば全員がPLGを語り、CLGが注目されれば全員がCLGを語る。それでは「流行に乗っているだけの人」に見える。

差異を作るには、自分の頭で考える時間が必要だ。

流行りのキーワードを鵜呑みにせず、「本当にそうか？」と問い返す。自社の状況に照らして、「これは当てはまるのか？」を検証する。うまくいかなかった経験から、「なぜ定石通りにいかなかったのか」を考える。

一次情報を持つことも重要だ。誰かのブログを読む、セミナーに参加する、それだけではなく、自分で手を動かして得た経験。自社のデータを分析して見つけた傾向。顧客との対話から得た洞察。こうした一次情報は、他の誰も持っていない。

界隈と適度な距離を保ちながら、自分だけのポジションを築く。それがキャリアにおける差異化だ。

構造を見る目を磨く ─ マーケターの知的独立性へ

本章の冒頭で、「施策をこなす人」と「構造を見る人」の違いを述べた。

では、構造を見る目はどうやって磨くのか。

第一に、抽象と具体を行き来する習慣だ。目の前の施策は具体だ。その施策がなぜ効くのか、どんな原理に基づいているのかを考えると、抽象に上がる。抽象で理解した原理を、別の施策に適用するとまた具体に降りる。この往復を繰り返すことで、構造が見えるようになる。

第二に、異分野から学ぶことだ。SaaSマーケティングの本だけ読んでいても、視野は広がらない。経済学、心理学、組織論、歴史。異なる分野の知見が、SaaSマーケティングの現象を説明することがある。

第三に、「なぜ」を繰り返すことだ。うまくいった施策があったとき、「よかった」で終わらせない。なぜうまくいったのか。その要因は他に適用できるか。逆に、うまくいかなかったとき、なぜ失敗したのか。何が仮説と違っていたのか。

第四に、言語化する習慣だ。頭の中でぼんやり考えていることを、言葉にして書き出す。ブログでもメモでもいい。書くことで思考が整理され、構造が浮かび上がる。

これらは一朝一夕には身につかない。日々の仕事の中で、少しずつ積み上げていくものだ。

知的独立性という言葉を使いたい。

界隈の常識、上司の命令、ベンダーの売り込み。無数のノイズの中で、自分の頭で考え、自分の判断を下す。それができるマーケターは、どんな環境でも価値を発揮できる。

施策の実行者は、環境に依存する。優れたツールと予算があれば成果を出せるが、なければ何もできない。

構造の設計者は、環境を変える。限られたリソースでも、構造を工夫することで成果を出す。

SaaSマーケターとして、どちらを目指すか。その選択が、キャリアの軌道を決める。

ここまで、理論と方法論を中心に語ってきた。次章からは、実際の事例を見ていこう。成功したSaaSがどのようなループを設計しているか。そこから学べることは多い。

Dropbox：招待インセンティブ・ループ

ループの教科書的事例と言えば、Dropboxだろう。

2008年のローンチ時、Dropboxは「紹介プログラム」を核にした成長戦略を取った。友人を招待すると、招待した側も招待された側も、500MBの追加ストレージがもらえる。

このシンプルな仕組みが、爆発的な成長を生んだ。

分析してみよう。なぜこのループが機能したのか。

第一に、インセンティブが製品利用に直結していた。「500MB追加」は、Dropboxユーザーにとって本当に欲しいものだった。単なるクーポンではなく、製品体験を向上させるインセンティブ。これが招待の動機を強めた。

第二に、双方が得をした。招待する側だけでなく、される側にもメリットがあった。「自分が得するから紹介する」だけでなく、「相手にも喜んでもらえる」。これが紹介の心理的ハードルを下げた。

第三に、製品自体が「共有」を前提としていた。ファイル共有サービスなのだから、他の人と使うのが自然。招待行為が「売り込み」ではなく「一緒に使おう」という誘いになった。

この事例から抽出できるパターンは何か。

「製品の本質的価値と紐づいたインセンティブ」が鍵だ。現金やギフトカードではなく、製品の利用体験を向上させるものを報酬にする。

自社に適用するとき、問うべき質問がある。「ユーザーが本当に欲しいもので、かつ製品利用に直結するものは何か」。それを招待報酬にできないか検討する。

Slack/Figma：コラボ必須・ループ

Dropboxのループは「招待すると得をする」構造だった。SlackやFigmaのループは、それとは異なる。

「招待しないと使えない」構造だ。

Slackを一人で使っても意味がない。チームメンバーがいて初めて、コミュニケーションツールとして機能する。だからユーザーは、自発的に同僚を招待する。

Figmaも同様だ。デザイナーがFigmaでプロトタイプを作っても、それをレビューする人がいなければ意味がない。エンジニアやプロダクトマネージャーを招待して、初めてワークフローが回る。

このタイプのループには、いくつかの特徴がある。

第一に、バイラル係数（一人のユーザーが何人連れてくるか）が高い。招待インセンティブ型では「招待してもしなくてもいい」が、コラボ必須型では「招待しないと自分が困る」。強い動機が働く。

第二に、招待される側の定着率も高い。「誰かから誘われた」という社会的文脈がある。チームで使うことが前提なので、一人だけやめるのは難しい。

第三に、ネットワーク効果が働く。使う人が増えるほど、サービスの価値が上がる。Slackにチームメンバー全員がいれば、メールを使う理由がなくなる。

このパターンを適用できるのは、どんな製品か。本質的に複数人で使うものだ。コミュニケーション、コラボレーション、プロジェクト管理。これらの領域では、コラボ必須ループの設計が有効になる。

一人で使っても価値がある製品であっても、「複数人で使うとより価値が高まる」機能を設計することで、このパターンに近づけることは可能だ。

Loom/Calendly：ワークフロー統合・ループ

Loomは画面録画サービスだ。ユーザーが動画を録画し、そのリンクを誰かに送る。

リンクを受け取った相手は、Loomのプレイヤーで動画を視聴する。その体験の中で、Loomの存在を知る。「自分も使ってみよう」と思う人が出てくる。

これが「ワークフロー統合型」のループだ。

CalendlyもPDF同様だ。ユーザーがスケジュール調整のリンクを送る。相手がそのリンクから日時を選ぶ。Calendlyを知らなかった人が、Calendlyの価値を体験する。

このループの特徴は、ユーザーが「意図せず」プロダクトを広めていることだ。

Dropboxの招待プログラムでは、ユーザーは「招待する」という明確な行為をする。報酬目当てでやることもある。

Loom/Calendlyでは、ユーザーは単に仕事をしているだけだ。動画を送る、日程調整をする。普通の業務の中で、自然とプロダクトが露出する。

これが可能になる条件がある。製品の使用結果が、外部の誰かとシェアされること。

動画は見せるためにある。スケジュールは調整相手がいる。この「他者への出力」がある製品は、ワークフロー統合型のループを設計できる。

応用例を考えてみよう。請求書発行サービスなら、送付される請求書の中に「〇〇で作成されました」と入れる。アンケートツールなら、回答画面に「Powered by 〇〇」を表示する。

「ユーザーがアウトプットを誰かに見せる」瞬間を捉え、そこでブランドを露出させる。

事例から「型」を抽出する思考法

三つの事例を見てきた。それぞれ異なるメカニズムで動いている。

招待インセンティブ型：報酬で動機づけ、双方が得をする構造 コラボ必須型：製品の性質上、他者を巻き込まないと使えない ワークフロー統合型：通常業務の中で自然にブランドが露出する

これらは排他的ではない。組み合わせることもできる。

Slackはコラボ必須型だが、同時にワークフロー統合型でもある。Slackから送られた通知リンクをクリックすると、Slackの画面に飛ぶ。外部の人がその体験をして、Slackに興味を持つ。

Figmaにも招待インセンティブ的な要素がある。エデュケーション版の拡張など、特定の条件で特典がつく。

事例を見るときのポイントは、「表面的な施策」ではなく「背後にある構造」を見ることだ。

「Dropboxが招待プログラムをやったから、うちもやろう」では不十分。なぜDropboxの招待プログラムが機能したのか。どんな条件が揃っていたのか。その条件は自社にあるのか。

構造を理解すれば、まったく同じ施策でなくても、同じ原理を適用した別の施策を設計できる。

自社製品を分析する問いをいくつか挙げておこう。

• ユーザーが他者にシェアしたくなる瞬間はあるか
• 複数人で使うと価値が高まる機能はあるか
• ユーザーのアウトプットが外部の目に触れる瞬間はあるか
• 招待報酬として提供できる「製品価値に直結するもの」はあるか

これらの問いに答えることで、自社に適したループのパターンが見えてくる。

次章では、SaaSから少し離れて、コミュニティや情報起業の領域での事例を見ていこう。異なる領域の事例からも、SaaSに転用可能な示唆が得られる。

LINEオープンチャット/note：日本型コミュニティ成長の設計

日本市場でコミュニティを設計するとき、海外事例をそのまま適用できないことがある。

LINEオープンチャットは、日本ならではのコミュニティプラットフォームだ。国内のLINEユーザーは9,500万人以上。新たなアプリをインストールする必要がなく、参加ハードルが極めて低い。

LINEオープンチャットを使ったSaaSの例を見てみよう。

あるBtoC向けマーケティングツール会社は、ユーザー向けのLINEオープンチャットを運営している。製品の使い方Tips、成功事例の共有、運営からのアップデート情報。参加者2,000名を超えるコミュニティになっている。

ここで働いているループは「情報価値→参加→定着→口コミ」という流れだ。

コミュニティで価値ある情報が流れている。それを聞きつけた人が参加する。参加すると、製品への理解が深まり、使いこなし度が上がる。満足度が上がると、他の人にも勧める。

LINEオープンチャットの特徴は、参加のハードルが低いこと。DiscordやSlackは「わざわざ入る」感覚があるが、LINEは「ちょっと覗いてみる」感覚で入れる。そして匿名参加も可能なため、発言への心理的障壁が下がる。

一方、noteは日本発のコンテンツプラットフォームだ。記事を書いて発信する機能に加え、「サークル」という月額課金コミュニティ機能がある。

noteを使ったループの例として、あるHRテック企業がある。人事向けのノウハウ記事をnoteで発信し、読者を製品サイトへ誘導する。記事そのものがSEOで上位表示され、ターゲット顧客を集客する装置になっている。

この事例では「コンテンツ→検索流入→信頼構築→製品検討」というループが回っている。

オンラインサロン：DMMオンラインサロン・CAMPFIREの構造

オンラインサロンは日本独自の発展を遂げた形態だ。

有料会員制のコミュニティで、主宰者（インフルエンサー、専門家、起業家など）を中心に形成される。DMMオンラインサロン、CAMPFIREコミュニティなどのプラットフォームがある。

オンラインサロンの構造には、SaaSが学べる点がある。

第一に、「主宰者のブランド」が入り口になっている。製品機能ではなく、人への信頼で入会が決まる。SaaSでも、創業者やプロダクトマネージャーの発信がブランドになり得る。

第二に、「限定性」がリテンションを生む。サロン内でしか見られないコンテンツ、サロンメンバーだけが参加できるイベント。この限定性が「やめると損」という心理を生む。

第三に、「帰属意識」がコミットメントを高める。サロンに所属していることがアイデンティティになる。活動に参加し、他のメンバーと交流し、自分もコミュニティの一員だと感じる。

SaaSでオンラインサロン的なコミュニティを作るとすれば、どうなるか。

製品の「ユーザー会」をサロン化する手法がある。単なる情報共有の場ではなく、メンバー限定のコンテンツ、リアルイベント、メンバー同士のマッチングなどを提供する。月額費用は製品利用料に含めるか、あるいはプレミアムオプションとして切り出す。

オンラインサロンの成功要因を抽象化すると「人の魅力」「限定コンテンツ」「帰属意識」の三つに集約される。これらはSaaSコミュニティにも応用可能だ。

チャレンジ形式：参加→シェア→呼び込みのループ

コミュニティやオンラインコースで広く使われている手法に「チャレンジ」がある。

期間限定（5日間、7日間、30日間など）で、特定の目標に向けて参加者が取り組む形式だ。

「5日間でLPを作るチャレンジ」「30日間毎日投稿チャレンジ」「7日間で売上を上げるチャレンジ」。

なぜチャレンジが効くのか。構造を分析しよう。

第一に、期間限定が参加ハードルを下げる。「ずっとコミットしなければならない」より「5日間だけ頑張る」方が踏み出しやすい。

第二に、明確なゴールがモチベーションになる。「何となく学ぶ」より「5日後にはLPが完成する」の方が、行動を起こす理由が明確。

第三に、進捗をシェアする仕組みが組み込まれている。SNSで「#〇〇チャレンジ」とハッシュタグをつけて投稿する。これが外部への露出になり、新規参加者を呼び込む。

第四に、期間中に成果が出ると「うまくいった」体験が残る。この成功体験が、次のステップ（有料コースへの申し込み、製品の購入など）への動機になる。

SaaSでチャレンジ形式を使う例を考えてみよう。

プロジェクト管理ツールなら「5日間で業務フローを可視化するチャレンジ」。分析ツールなら「7日間でダッシュボードを完成させるチャレンジ」。マーケティングオートメーションなら「30日間毎日1つ自動化を作るチャレンジ」。

チャレンジ期間中は無料またはトライアルとして開放し、成果を出したユーザーが有料版に移行する流れを作る。

「参加→実践→成功→シェア→新規呼び込み」。このループがチャレンジ形式の核心だ。

国内事例をSaaSに転用する視点

本章で見てきた事例は、厳密にはSaaSとは異なる領域のものが多い。

しかし、ループの構造という観点で見れば、共通するパターンがある。

まず抽出できるのは「コンテンツ起点のループ」だ。

note記事、オンラインサロン内のコンテンツ、チャレンジ期間中の教材。これらが価値を提供し、人を引きつける。SaaSでも、教育コンテンツを起点にしたループは設計可能だ。

次に「人・コミュニティ起点のループ」がある。

製品機能ではなく、「この人に会いたい」「この仲間と繋がりたい」が動機になる。SaaSでも、創業者の発信力、ユーザーコミュニティの魅力、カスタマーサクセスチームの信頼感が、ループの起点になり得る。

そして「参加型・体験型のループ」だ。

受け身でコンテンツを消費するのではなく、能動的に参加する。チャレンジ、ワークショップ、ハッカソン。こうした「やってみる」体験が、深いエンゲージメントを生む。

日本市場特有の要素もある。

LINEの普及率の高さ、匿名文化、「オンラインサロン」という言葉の浸透。これらを踏まえた設計が必要だ。海外の事例をそのまま持ってきても、日本では機能しないことがある。

逆に言えば、日本市場に適応したコミュニティ設計ができれば、競合優位になる。海外発のSaaSが日本でうまく浸透できない理由の一つが、コミュニティを日本向けにローカライズできていないことだからだ。

日本市場の特性を理解することは、次章のテーマでもある。海外事例を日本でどう適用するか、その視点を深めていこう。

日本特有のBtoB商習慣

海外発のSaaSが日本に進出し、苦戦する例は多い。

なぜか。製品が悪いわけではない。本国では大成功している。問題は、日本市場の「構造」が違うことだ。

日本のBtoB市場には、いくつかの特有の商習慣がある。

第一に、意思決定のスピードが遅い。

アメリカでは「良さそうなら試してみる」「ダメならすぐやめる」がスタンダードだ。フリーミアムやトライアルで使い始め、価値を感じたらクレジットカードで即購入。決裁は個人または部門単位。

日本では「稟議」がある。複数の承認者を通過しなければ、ツールの導入が決まらない。無料トライアルで価値を感じていても、正式導入まで数ヶ月かかることも珍しくない。

第二に、「対面」へのこだわりが根強い。

ZoomやTeamsが普及しても、「一度お会いしたい」「訪問して説明してほしい」という要望は多い。特に大企業や地方企業、伝統的な業界ほどその傾向がある。

PLGのように「製品だけで売れる」モデルは、日本ではセルフサーブだけで完結しにくい。ハイタッチの営業サポートを組み合わせる必要が出てくる。

第三に、カスタマイズ要求が強い。

「うちは少し事情が違うので」「この機能をこう変えられないか」。日本の顧客は、標準機能をそのまま受け入れず、自社に合わせたカスタマイズを求めることが多い。

SaaSの思想は「One to Many」、つまり同じ製品を多くの顧客に提供することで効率を上げるというものだ。カスタマイズ要求に応えすぎると、この効率が崩れる。

第四に、既存ベンダーとの関係性が切れにくい。

日本企業は「長期的な取引関係」を重視する。新しいツールの方が優れていても、長年の付き合いがあるベンダーを切るのは心理的に抵抗がある。

これらの商習慣は、良い悪いではなく「事実」として存在する。海外の成功パターンをそのまま持ち込んでも、この壁にぶつかる。

コミュニティ文化の違い

前章でコミュニティ主導成長（CLG）について触れた。日本でCLGを実践する際にも、文化的な違いを考慮する必要がある。

第一に、発言のハードルが高い。

欧米のコミュニティでは、メンバーが積極的に発言し、議論が活発に行われる。間違ったことを言っても「それは違う」と指摘し合い、健全に議論が進む。

日本では「間違ったことを言いたくない」「恥をかきたくない」という心理が働きやすい。ROMる（読むだけで発言しない）メンバーが多くなりがちだ。

この対策として、匿名性の導入、質問しやすい雰囲気づくり、少人数グループでの対話、運営側からの積極的な問いかけなどが有効になる。

第二に、コミュニティの「求心力」の持たせ方が違う。

海外では「同じ製品を使っている」ということ自体がコミュニティの求心力になりやすい。Salesforce TrAILER、Atlassian Communityなど、ユーザーコミュニティが大規模に機能している。

日本では、「この人の話を聞きたい」「この仲間に入りたい」という「人」への求心力が重要になる傾向がある。製品だけでは弱い。主宰者やコミュニティマネージャーの人間的魅力、アクティブメンバー同士の人間関係が、コミュニティを維持する接着剤になる。

第三に、オフラインイベントの重要性が高い。

日本では「リアルで会う」ことの価値が相対的に高い。オンラインコミュニティだけでなく、定期的なオフラインミートアップを開催することで、結束が強まる。

逆に言えば、オフラインイベントを続けるリソースがなければ、コミュニティは形骸化しやすい。

ローカライズすべき点と普遍的な原理

では、何をローカライズすべきで、何は普遍的な原理として適用できるのか。

ローカライズすべき点は、主に「コミュニケーション」と「プロセス」だ。

営業のアプローチ。対面の場を設けること、稟議に必要な資料を用意すること、導入後のサポート体制を丁寧に説明すること。これらは日本向けに調整が必要だ。

コミュニティの運営。発言を促す仕掛け、少人数グループの導入、オフラインイベントの開催。日本の文化に合わせた設計が求められる。

カスタマーサクセスのアプローチ。能動的に連絡を取りつつも、過度にプッシュしない。「いつでもご相談ください」と門戸を開きながら、押し付けがましくならないバランス。

一方、普遍的な原理として適用できる点もある。

ループの構造自体は普遍的だ。「顧客の成功が次の顧客を呼ぶ」という原理は、日本でもアメリカでも変わらない。

TTVの短縮、Aha!体験の設計、解約率への注目。これらの概念は普遍的に適用可能だ。

データ分析やセグメンテーションの手法も普遍的だ。顧客行動を可視化し、ヘルススコアを設計し、適切なタイミングで介入する。この方法論は国を問わない。

抽象的な原理を理解し、具体的な施策は日本向けに調整する。この二層の思考が必要になる。

日本発SaaSの勝ち筋を構造で考える

最後に、日本発のSaaS企業が取りうる戦略を考えてみよう。

第一に、日本市場の特性を強みに変える。

対面重視、カスタマイズ要求、長期の関係性。これらは海外発SaaSにとっては面倒だが、日本企業にとっては自然に対応できることだ。

フィールドセールスとカスタマーサクセスを組み合わせたハイタッチモデル。日本企業の要望に柔軟に応えるサポート体制。こうした対応力を武器にできる。

第二に、国内の業界特化（Vertical SaaS）を狙う。

建設、医療、不動産、飲食、物流。日本には業界固有の業務プロセスや法規制がある。海外SaaSがカバーしにくい領域だ。

業界特化型であれば、「その業界のことを深く理解している」こと自体が競争優位になる。海外大手が入りにくい「城」を築ける。

第三に、LINEやnoteなど日本特有のプラットフォームを使う。

海外SaaSはSlackやDiscordでコミュニティを作ることが多い。日本ではLINEオープンチャットの方がリーチが広い場合がある。この差を活かす。

第四に、「Made in Japan」のブランドを活かす。

データセキュリティ、日本語サポート、日本の法規制への準拠。特にセキュリティに敏感なエンタープライズ顧客にとって、日本企業であることは安心材料になる。

日本市場で勝つには、グローバルスタンダードを学びつつ、日本に根ざした戦略を設計すること。

事例フェーズはここまでだ。次章からは、リスクと未来を見ていく。PLGがうまくいかない失敗パターンから、何を学べるか。冷静に分析しよう。

フリーミアムにすれば伸びるという誤解

PLG（Product-Led Growth）が注目を集め、多くの企業が飛びついた。

「Slackのように無料で使ってもらい、価値を感じたら有料に」 「Dropboxのように招待プログラムで広がっていく」 「営業を増やさずに成長できる」

この夢に惹かれて、フリーミアムを導入する企業は後を絶たない。

しかし、現実は厳しい。

無料ユーザーは増えるが、有料に転換しない。サーバーコストだけかかって収益にならない。結局、PLGを諦めて従来の営業モデルに戻る。こうした失敗例を、私は何度も見てきた。

なぜうまくいかないのか。

最大の誤解は、「フリーミアムにすれば勝手に広がる」という思い込みだ。

Dropboxが成功したのは、フリーミアムだったからではない。「ファイルが同期されている」という強烈なAha!体験があり、友人と共有する動機があり、招待にインセンティブがあった。これらの構造が組み合わさって、初めてループが回った。

フリーミアムは「入り口を広げる」だけだ。入ってきた人が価値を感じ、使い続け、他の人を呼び込む。この後工程が設計されていなければ、無料ユーザーが増えるだけで終わる。

PLGを導入する前に問うべき質問がある。

「製品を使えば、数分以内に価値を感じられるか」 「一人で使っても価値があるか、それとも複数人が必要か」 「ユーザーが自然に他者を巻き込む動機はあるか」

これらに明確な答えがないまま、「とりあえずフリーミアム」は危険だ。

「入り口」だけ整えても定着しない構造

PLGがうまくいかない二つ目のパターンは、オンボーディングの軽視だ。

無料登録のハードルを下げることだけに注力し、登録後の体験設計がおろそかになる。

ユーザーがサインアップする。ダッシュボードに入る。何を最初にすべきか分からない。いくつかの機能を触ってみるが、ピンとこない。離脱する。二度と戻ってこない。

これはPLGの失敗ではなく、オンボーディングの失敗だ。

第5章で述べた「TTV（価値実感までの時間）の最小化」が設計されていないと、PLGは絵に描いた餅になる。

よくある間違いをいくつか挙げよう。

第一に、「全機能を見せようとする」。製品が持つすべての機能をツアーで紹介する。情報過多になり、ユーザーは圧倒される。

第二に、「空っぽの状態から始まる」。何もないダッシュボード、空のリスト。ユーザーは「何を入れればいいか」分からず固まる。

第三に、「設定項目が多すぎる」。初回ログイン時に20個の設定を求める。面倒になって離脱する。

第四に、「価値を感じる前に有料を勧める」。まだ製品の良さが分かっていない段階でアップグレードを促す。押し売りに見える。

入り口を広げることは、そこから先の設計がしっかりしていて初めて意味がある。穴の空いたバケツに水を入れても、貯まらない。

よくある失敗パターン5選

ここで、PLG導入でよく見る失敗パターンを整理しておこう。

パターン1：製品がPLGに向いていない

製品が複雑すぎる、設定に専門知識が必要、導入にデータ移行が伴う。こうした製品は、自己解決型のPLGには向かない。人間のサポートが必要になる。

無理にPLGにすると、「使い方が分からない」で離脱する。ハイタッチモデルとの併用を検討すべきだ。

パターン2：無料版が良すぎる/悪すぎる

無料版で十分使える場合、有料に移行する理由がない。逆に、無料版が制限されすぎていると、価値を体験できない。

無料版で「ほぼ価値を実感できるが、もう少し欲しくなる」ラインを見つけるのが難しい。

パターン3：ウイルス係数の過信

「ユーザーが勝手に広めてくれる」と期待しすぎる。実際には、製品によってウイルス係数は大きく異なる。

Slackのように「複数人で使わないと意味がない」製品ならウイルス係数は高い。一人で使って完結する製品では、自然な拡散は起きにくい。

パターン4：PQLの定義が曖昧

MQL（Marketing Qualified Lead）の代わりにPQL（Product Qualified Lead）を使う。製品の利用状況から「有料転換しそうなユーザー」を特定する考え方だ。

しかし、PQLの定義が曖昧だと機能しない。「どの行動をしたユーザーが転換しやすいか」をデータで検証せず、感覚で決めてしまう。

パターン5：組織がPLGを理解していない

マーケがPLGを推進しても、営業は従来のやり方を続ける。プロダクトチームはオンボーディングより新機能を優先する。

PLGは組織全体の取り組みだ。一つの部門だけで完結しない。経営層の理解とコミットメントがなければ、掛け声だけで終わる。

冷静にリスクを見る ─ 構造的な診断法

PLGを導入すべきかどうか。冷静に判断するためのフレームワークを提示しよう。

まず、「製品の適性」を評価する。

• 初回利用で価値を感じられるか（TTV < 10分が目安）
• 一人で使っても価値があるか
• セットアップに専門知識が不要か
• 無料版と有料版の境界を設計できるか

これらにすべてYesでなければ、純粋なPLGは難しい。PLGとセールスを組み合わせた「Product-Led Sales」を検討する。

次に、「市場の適性」を評価する。

• ターゲット顧客はセルフサーブで購入する層か
• 競合がすでにPLGで成功しているか
• 単価は低〜中程度か（高単価ではハイタッチが必要になりやすい）

日本市場では、前述のように稟議文化や対面志向がある。PLGだけで完結しにくい。

最後に、「組織の適性」を評価する。

• プロダクトチームがオンボーディングにコミットできるか
• データ分析の体制はあるか
• 部門横断で協力できる文化があるか

こうした診断を経て、「PLGを中心に据えるか」「PLGを補助的に使うか」「PLGを見送るか」を判断する。

PLGは流行りだからと飛びつくと失敗する。自社の製品、市場、組織に合った戦略を選ぶことが重要だ。

リスクを理解したうえで、次は未来を見よう。SaaSマーケティングは、この先どこへ向かうのか。

APIファーストとプラットフォーム化

第2章で触れた「Ecosystem-Led」の話を、より具体的に掘り下げよう。

SaaSの進化を振り返ると、一つの傾向が見える。単独のツールから、エコシステムの一部へという流れだ。

初期のSaaSは、特定の課題を解決するスタンドアロンのツールだった。請求書を発行する、タスクを管理する、メールを送る。それぞれが独立して機能していた。

次の段階で、連携が生まれた。Zapierのような「接着剤」ツールが登場し、異なるSaaSをつなぐ。A社のツールで発生したイベントを、B社のツールに自動で反映する。

そして今、SaaS自体がプラットフォーム化している。SlackにはApp Directoryがあり、数千のアプリがSlack上で動く。NotionにはAPIがあり、他のツールと自由に連携できる。Shopifyにはエコシステムがあり、無数のアプリがShopify上でビジネスを展開している。

このトレンドが意味することは何か。

第一に、APIファーストの設計が必須になる。

自社のプロダクトを、他のツールと連携可能な状態で作る。データを閉じ込めるのではなく、データを流通させる。他のツールと組み合わせて使われることを前提にする。

APIを持たないSaaSは、エコシステムから取り残される。ユーザーのワークフローに組み込まれず、「たまに使う補助ツール」のポジションにしかなれない。

第二に、エコシステム内でのポジショニングが重要になる。

すべてのSaaSがプラットフォームになれるわけではない。Slack、Salesforce、HubSpotのような「ハブ」になれるのは一握りだ。

多くのSaaSは、これらのハブと連携する「スポーク」のポジションを取る。Slackのアプリ、Salesforceのパートナー、Shopifyのアドオン。ハブの成長に乗って、自身も成長する戦略だ。

どのエコシステムに属するか。その選択が、成長の軌道を左右する。

Outcome-Based Pricing：成果連動型課金の設計

従来のSaaS課金モデルは、主に二つだった。

一つは、ユーザー数（シート）による課金。5人で使えば5ライセンス分、100人なら100ライセンス分。

もう一つは、使用量（メータリング）による課金。API呼び出し回数、ストレージ容量、トランザクション数。

しかし今、第三の課金モデルが注目されている。Outcome-Based Pricing、成果連動型課金だ。

成果連動型とは、顧客のビジネス成果に応じて課金するモデルだ。

たとえば、マーケティングオートメーションツールが「獲得したリード数」に応じて課金する。採用管理ツールが「採用決定した人数」に応じて課金する。広告最適化ツールが「増加した広告収益」の一定割合を受け取る。

このモデルのメリットは何か。

第一に、顧客と自社の利害が一致する。顧客が成果を出すほど、自社の収益も増える。だから本気で顧客の成功を支援するインセンティブが生まれる。

第二に、顧客の導入障壁が下がる。「成果が出なければ払わなくていい」なら、試してみるハードルが下がる。効果に自信があるなら、このモデルは強力な訴求になる。

第三に、解約率が下がりやすい。成果が出ている間は「やめる理由」がない。成果と課金が連動しているから、費用対効果が常に明確だ。

一方、課題もある。

成果をどう定義し、どう計測するか。「売上が増えた」として、それが本当にSaaSのおかげなのか。他の要因も絡んでいないか。この因果関係の証明が難しい。

また、成果が出なかったときのリスクは自社が負う。景気が悪化し、顧客のビジネスが停滞すると、シート課金なら収益は維持されるが、成果連動なら収益が落ちる。

成果連動型は、すべてのSaaSに適しているわけではない。成果が明確に計測できる領域、自社のプロダクトが成果に直接貢献する領域で有効だ。

垂直統合（Vertical SaaS）の可能性

SaaSの進化をもうひとつの軸で見ると、水平から垂直への流れがある。

水平SaaS（Horizontal SaaS）は、業界を問わず使えるツールだ。Slack、Zoom、Dropbox。どの業界の企業でも、コミュニケーションやファイル共有のニーズはある。

垂直SaaS（Vertical SaaS）は、特定の業界に特化したツールだ。建設業向けの工程管理、医療機関向けの電子カルテ、飲食店向けのPOSシステム。

水平SaaSの市場は巨大だが、競争も激しい。GoogleやMicrosoft、大手IT企業がひしめいている。スタートアップが正面から戦うのは難しい。

垂直SaaSは市場規模こそ小さいが、ニッチで深い。業界特有の業務プロセス、法規制、商慣習を理解していることが競争優位になる。大手ITが参入しにくい「城」を築ける。

日本市場では、垂直SaaSの可能性が特に大きい。

第13章で述べたように、日本には業界固有の事情が多い。建設業の工事台帳、医療の診療報酬、不動産の契約書式。これらは日本独自であり、海外SaaSがカバーしにくい。

また、日本の中小企業のIT化はまだ道半ばだ。紙やExcel、FAXが現役の業界が多い。ここにSaaSを浸透させる余地がある。

垂直SaaSで成功するポイントは何か。

第一に、業界知識の深さ。その業界でずっと働いてきた人、業界の痛みを肌で知る人がチームにいること。表面的なリサーチでは分からない「本当の課題」を理解していること。

第二に、業界ネットワーク。最初の顧客をどう獲得するか。業界のキーマンとのつながり、業界紙への露出、展示会への出展。その業界に入り込むチャネルを持っていること。

第三に、オペレーション統合の射程。単なるツールではなく、業務プロセス全体をカバーする。点のソリューションではなく、線や面で価値を提供する。

SaaSの未来像 ─ 「ツール」から「業界インフラ」へ

本章のまとめとして、SaaSの向かう先を展望しよう。

SaaSは「ツール」として始まった。特定の作業を効率化するもの。あると便利だが、なくても仕事は回る。

次に、SaaSは「習慣」になった。毎日使うもの。ワークフローに組み込まれ、なくなると困る。

そして今、SaaSは「インフラ」へと進化しつつある。業界の基盤。それなしでは業界自体が回らない。

Shopifyを見てほしい。単なるECサイト構築ツールではない。決済、物流、マーケティング、販売データ分析。EC事業に必要なすべてがShopify上で回る。Shopifyは「EC業界のインフラ」になりつつある。

Stripeを見てほしい。決済処理のAPIだが、今やインターネットビジネスの金融インフラだ。Stripeなしでは、多くのスタートアップが事業を始められない。

このレベルに到達したSaaSは、解約される心配がほぼない。なぜなら、解約することは事業を止めることに等しいからだ。

もちろん、すべてのSaaSがインフラになれるわけではない。しかし、自社の製品が顧客のビジネスにどれだけ深く組み込まれているかを問うことは重要だ。

「便利なツール」にとどまるか、「なくてはならないインフラ」になるか。その違いが、長期的な競争力を決める。

ここまで15章にわたって、SaaSマーケティングの構造を見てきた。

終章では、本書全体を振り返り、明日から始められるアクションへと落とし込んでいこう。

本書のまとめ：7つの構造原理

15章にわたって、SaaSマーケティングの構造を見てきた。

ここで、本書を貫く7つの原理を整理しておこう。

原理1：機能ではなく構造で勝負する

機能競争は終わった。AIとローコードツールにより、機能はすぐにコピーされる。勝負を決めるのは、製品が「どう機能するか」という構造だ。なぜ顧客は使い続けるのか、なぜ次の顧客を連れてくるのか。この構造が競争優位になる。

原理2：ファネルからループへ

マーケティングの思考モデルを転換する。上から流し込んで下から漏れる「漏斗」ではなく、顧客の成功が次の顧客を呼ぶ「循環」を設計する。ループが回り始めれば、広告依存の消耗戦から脱却できる。

原理3：顧客の成功が起点

ループを回すエンジンは「顧客の成功体験」だ。価値を感じていない顧客は紹介しない、シェアしない、使い続けない。だから獲得より先に、オンボーディングとAha!体験を設計する。

原理4：解約率は成長のレバー

LTV/CACを見る前に、解約率を見る。解約率が1ポイント改善すれば、LTVは劇的に変わる。解約を減らすことは、最も効率的な成長戦略だ。

原理5：伴走が信頼を生む

BtoB購買行動は変わった。顧客は「売り込まれる」ことを嫌う。説得ではなく伴走、説明ではなく対話。顧客の成功を一緒に考える姿勢が、信頼と長期的な関係を生む。

原理6：コミュニティは資産

コミュニティは単なる施策ではなく、成長のインフラだ。ユーザー同士がナレッジを共有し、製品への愛着を育み、新規ユーザーを呼び込む。時間をかけて育てる価値がある。

原理7：構造を見る目を磨く

施策をこなすだけでは不十分だ。なぜその施策が効くのか、背後にある原理は何かを考える。構造を見る目があれば、どんな状況でも自分で打ち手を設計できる。

明日から始めるアクションプラン

本書を読んで「なるほど」と思っても、行動しなければ何も変わらない。

明日から始められる、具体的なアクションを提案しよう。

アクション1：自社のループを図にする

紙やホワイトボードに、今の顧客獲得・定着の流れを図にしてみる。どこに「循環」があるか。あるいは、ないか。

なければ、どこに仕込めそうか。製品の性質、顧客の行動を踏まえて、ループのアイデアを考える。

アクション2：解約顧客にヒアリングする

過去3ヶ月に解約した顧客のうち、話を聞けそうな数人にコンタクトを取る。なぜやめたのか。何が足りなかったのか。正直に聞く。

その声の中に、改善のヒントがある。

アクション3：オンボーディングを体験し直す

自社のプロダクトに新規ユーザーとして登録し直す。最初の数分で何が起きるか。価値を感じるまでに何ステップかかるか。

客観的に体験することで、見落としていた摩擦が見つかる。

アクション4：一人の顧客を深く理解する

今週中に、一人のアクティブな顧客と30分話す。なぜ使っているのか。どこに価値を感じているか。他の人に勧めるとしたら何と言うか。

ペルソナではなく、生身の人間を知る。

アクション5：PLG適性を診断する

第14章で示した診断項目を使って、自社プロダクトのPLG適性を評価する。無理にPLGを進めるべきか、ハイブリッドが良いか、判断する。

これらのアクションのうち、一つでいい。明日始めてほしい。

「売る」を手放し「循環させる」へ

本書を通じて繰り返し伝えてきたことがある。

SaaSマーケティングは「売る」仕事ではない。

もちろん、売上は重要だ。収益がなければ事業は続かない。しかし、「売ること」を直接の目的にすると、視野が狭くなる。短期的な獲得に走り、長期的な関係を犠牲にする。

発想を転換しよう。

「循環を設計する」仕事だと考える。

顧客が成功体験を得て、その体験が次の顧客を呼び込む。この循環を作ることが、SaaSマーケターの仕事だ。

循環が回っていれば、売上は自然についてくる。広告費を増やさなくても、営業を増員しなくても、ループが顧客を連れてくる。

「売る」姿勢ではなく「成功させる」姿勢。 「獲得する」思考ではなく「循環させる」思考。

この転換が、マーケターとしての成果を変え、キャリアを変え、会社の成長を変える。

構造を見る目を持つ者だけが、未来を設計できる

最後に、もう一つ伝えたいことがある。

SaaSマーケティングは、これからも変わり続ける。

今日有効な施策が、3年後には陳腐化しているかもしれない。今日のトレンドワードが、来年には誰も使っていないかもしれない。

表面的な施策やツールを追いかけ続けると、変化に振り回される。新しいものが出るたびに飛びつき、古いものを捨て、また新しいものへ。

そうではなく、構造を見る目を持ってほしい。

表層は変わる。しかし、構造は変わりにくい。

「顧客の成功が次の顧客を呼ぶ」という原理は、10年後も通用するだろう。「信頼が関係を築く」という原理も変わらない。

ツールは変わる。チャネルは変わる。プラットフォームは変わる。しかし、人間の行動原理、価値交換の構造、信頼形成のメカニズムは、そう簡単には変わらない。

構造を見る目があれば、変化を恐れる必要がない。新しいツールが登場しても、「これはどの構造に当てはまるか」と考えられる。新しいトレンドが来ても、「本質はどこにあるか」と見抜ける。

本書で伝えたかったのは、施策のカタログではない。構造の地図だ。

この地図を手に、自分の道を切り拓いてほしい。自社の状況に合わせて、自分の頭で考え、自分なりの施策を設計してほしい。

循環を設計する者が、次の10年を制する。

その「循環の設計者」に、あなたがなることを願っている。

本書で伝えたかったこと

本書を通じて、私は一つのメッセージを繰り返し伝えてきた。

「売る」から「成功させる」への転換である。

SaaSマーケティングは、長く「いかに効率よく獲得するか」を競ってきた。その競争は終わっていないが、主戦場は変わった。獲得の効率ではなく、定着の深さ。説得の巧みさではなく、伴走の誠実さ。機能の差異ではなく、構造の強さ。

PLGが流行り、AIが登場し、マーケットは変わり続ける。しかし、本質は変わらない。

顧客が課題を解決し、成功体験を得て、それを他者に伝える。この「ループ」が回っている限り、ビジネスは成長し続ける。

あなたが設計すべきは、LPのコピーでも広告のバナーでもない（それらは手段だ）。設計すべきは、顧客の成功を中心とした循環構造である。

ここからがスタート

この本を閉じた瞬間から、あなたの「設計者」としての時間が始まる。

明日、職場に行ったら（あるいはSlackを開いたら）、自分のプロダクトを見てほしい。

• このプロダクトの「Aha!体験」はどこにあるか？
• 顧客はどの瞬間、他人に伝えたくなるか？
• 営業とCSの間に壁はないか？
• 自分たちは「売る組織」になっていないか？

小さな違和感から始めてほしい。

いきなり組織全体を変えるのは難しいかもしれない。でも、自分の担当領域でループの種を植えることはできる。

マーケターなら、獲得数の裏にある「定着率」を見てみる。 営業なら、商談で「御社の成功とは何か」を深く聞いてみる。 CSなら、顧客の声をプロダクトチームに「構造的なフィードバック」として届けてみる。

その一歩一歩が、やがて大きなループになり、組織を変え、市場を変えていく。

謝辞

本書の執筆にあたり、多くのSaaSマーケター、プロダクトマネージャー、そして挑戦者たちの知見に触れさせていただいた。

特に、現場で日々顧客と向き合い、悩み、試行錯誤している名もなき実践者たちに、深い敬意を表したい。彼らの挑戦があるからこそ、SaaSという産業はここまで面白くなった。

また、本書の構成について壁打ち相手になってくれたAIエージェントたちにも感謝を（彼らは文句も言わず、私の構造分析に付き合ってくれた）。

著者から最後のメッセージ

最後に、私の個人的な願いを記してペンを置きたい。

日本のSaaSが世界で勝つところを見たい。

言葉の壁、商習慣の壁。これらは確かにある。しかし、日本には「三方よし」や「おもてなし」といった、本質的なカスタマーサクセスの精神が根付いている。

伴走し、丁寧にサポートし、相手の成功を喜ぶ。この精神性は、Loop型のSaaSマーケティングにおいて強力な武器になる。

機能では負けるかもしれない。規模では負けるかもしれない。でも、顧客との関係性の深さでは負けない。

そんな「日本らしいSaaS」が、世界中の企業の生産性を上げ、創造性を解き放つ未来。

その未来を作るのは、今これを読んでいるあなただ。

循環を設計せよ。そして、次の10年を制しよう。

本書の執筆にあたり、以下の文献・資料を参考にしました。また、SaaSマーケティングをより深く学びたい読者のために、推奨図書としてリストアップします。

書籍（国内・海外）

• Wes Bush『Product-Led Growth: How to Build a Product That Sells Itself』Product-Led Institute, 2019
• Aaron Ross, Marylou Tyler『Predictable Revenue: Turn Your Business Into a Sales Machine with the $100 Million Best Practices of Salesforce.com』Pebblestorm, 2011
• Marc Benioff, Carlye Adler『Behind the Cloud: The Untold Story of How Salesforce.com Went from Idea to Billion-Dollar Company-and Revolutionized an Industry』Jossey-Bass, 2009
• Geoffrey A. Moore『Crossing the Chasm, 3rd Edition: Marketing and Selling Disruptive Products to Mainstream Customers』HarperBusiness, 2014
• Sean Ellis, Morgan Brown『Hacking Growth: How Today's Fastest-Growing Companies Drive Breakout Success』Crown Business, 2017
• 佐藤航陽『お金2.0 新しい経済のルールと生き方』幻冬舎, 2017

Webサイト・レポート

• OpenView Venture Partners

- SaaSのベンチマークやPLGに関する調査レポートを定期的に発行 -

• SaaStr

- 世界最大級のSaaSコミュニティ・メディア -

• HubSpot Blog

- インバウンドマーケティングおよびFlywheel（弾み車）モデルの提唱 -

• Notion Template Gallery

- コミュニティ主導型エコシステムの事例として参照 -

謝辞

本書の構造分析の一部は、SaaSコミュニティでの対話や、現場のマーケターからのフィードバックに基づいています。特定の引用箇所こそありませんが、業界全体の知見の積み重ねに深く感謝いたします。