「リンクを送るたびに顧客が増える」設計の作り方——CalendlyのバイラルPLG構造を自社SaaSに再現する5ステップ

スケジュール調整リンクを受け取った人が、使い終わった後に自分でアカウントを作る。Calendlyが設計したのはそういう仕組みです。ユーザーが他者に「何かを送る」たびに製品が広がるループを意図的に組み込み、ARR 2.7億ドル・企業評価30億ドルまで、実質的に広告費なしで到達しました。

この記事では、同じ設計を自社SaaSに再現する具体的な手順を5ステップで説明します。「製品共有が新規獲得になる構造」をゼロから組み込む方法です。対応するケーススタディ（Calendlyの構造分析）はこちらで読めます。

なぜ「使うたびに広まる」設計がこれほど強いのか

通常のSaaSでは、新しいユーザーを呼ぶためにGoogle広告、セールス人員、マーケ予算が必要です。Calendlyの場合、既存ユーザーが日程調整リンクを送るたびに、受取人が製品を体験します。Sacraの分析によれば、Calendlyの新規登録者のうち招待・リンク経由が50%以上を占めています。

この構造の強さは「スケールしても変わらない」点です。ユーザーが増えれば共有数も増え、共有数が増えれば新規獲得数も増える。PLG（Product-Led Growth）の中でも特に、利用アクション自体がバイラルを生む設計は「シングルプレイヤーモードゼロ設計」と呼ばれ、再現するには製品の中心機能を「1人では完結しない形」に設計する必要があります。

重要なのは、これが特別な業種の話ではない点です。フォーム・電子署名・承認フロー・共同編集・レポート共有など、「成果物を誰かに渡す」機能を持つSaaSであれば、ほぼすべてが対象になります。

始める前に確認すること

この設計が機能するかどうかは、製品の性質によります。まず確認するのは「共有される側も価値を感じる体験があるか」です。ユーザーが送ったリンクの先で、受取人が何かを操作したり、何かを得たりする必要があります。受取人がただURLを開いて閲覧するだけで終わる製品は、バイラルループの設計が成立しにくい。

次に、サインアップフローの現状を確認します。受取人がサインアップしたいと思った瞬間に、入力フォームが長かったり認証メールを待たせたりすると、そこでループが途切れます。現状のサインアップ完了までの時間と離脱率を計測しておくことが最初の準備です。

スキルと人員の面では、エンジニア1〜2名でフロントエンドの共有フローを修正できること、PostHogやAmplitudeなどのツールでファネルを設計できることが必要です。初期のバージョンなら2〜4週間で出せます。

CalendlyのバイラルPLG構造を再現する5ステップ

ステップ1：自社製品の「自然な共有ポイント」を書き出す

最初にやることは調査です。製品内で「ユーザーが他者に何かを送る・渡す・依頼する」アクションをすべてリストアップします。日程調整・フォーム回答依頼・承認リクエスト・ファイル共有・レポート送付・招待メール、なんでも対象です。

次に、その受取人が製品を実際に体験できているかどうかを確認します。受取人がリンクを開いて操作するなら、そこがバイラルの種になります。リンクを開いても閲覧するだけで受取人が何も操作しないなら、能動的に関与できる形に設計を変える必要があります。

最も効果が高い共有ポイントは「受取人が何かを決断・入力しなければならない場面」です。スケジュール選択・フォーム記入・署名・コメントなど、受取人が主体的に動く構造であるほど製品体験の密度が上がり、サインアップへの自然な流れが生まれます。

ステップ2：共有ページに「Powered by〇〇」を自然に置く

受取人が見るページやメールに、製品ブランドが自然に見える形で入るようにします。ここで大事なのは「目立たせすぎないこと」です。フッターに小さくロゴと「〇〇で作成」と入れる程度でかまいません。

「今すぐ登録」のようなCTAをページ冒頭に置くのは逆効果です。受取人は渡されたタスクを完了したいだけです。製品の存在を「気づかせる」だけにとどめ、CTAはタスク完了後に表示します。日程を確定した後・フォームを送信した後・ファイルを確認した後という流れです。Calendlyでは日程確定画面の下部に「Calendlyで自分の予定を管理する」という誘導が表示されます。

CTAの文言は「登録」より「試してみる」「自分用に作る」のような行動起点の表現が転換率は高い傾向にあります。A/Bテストで数値を見ながら改善するポイントです。

ステップ3：受取人がサインアップできるまでの摩擦を削る

バイラルループが壊れる場所として最も多いのがここです。受取人がサインアップしたいと思った瞬間に手続きに時間がかかると、離脱します。目標は「CTAクリックから最初の価値体験まで90秒以内」です。

最も効果的なのはGoogleアカウントでのワンクリック認証です。メール認証を使う場合は、サインアップ自体を先に完了させてバックグラウンドでメール送信する設計にします。「メールを確認してください」の画面で止めない。

さらに、招待リンク経由でサインアップした新規ユーザーには、招待元との関係を引き継いだオンボーディングを用意します。「Aさんに招待されましたね。まずAさんの〇〇に参加しましょう」という流れにすることで、最初のアクションまでの時間を大幅に短縮できます。IntercomやCustomer.ioを使えば、サインアップ経路の分岐設計は比較的簡単に実装できます。

ステップ4：バイラル係数を計測して弱い箇所を特定する

バイラル係数（k値）とは、1人の既存ユーザーが平均何人の新規ユーザーを連れてくるかを示す数値です。k値が1.0を超えると理論上は広告ゼロでも成長が続きます。まずはk値を測れる状態にすることが目標です。

PostHogまたはAmplitudeで以下のファネルを設定します。「共有アクション発生数」→「受取人のページ到達数」→「受取人のCTAクリック数」→「受取人のサインアップ完了数」。この4段階を週次で追います。最初は転換率が数%でも問題ありません。どこで落ちているかを特定することが目的です。

よくあるパターンとして、「ページ到達→CTAクリック」が低い場合はCTAの位置か文言の問題です。「CTAクリック→サインアップ完了」が低い場合はサインアップフローの摩擦です。「共有アクション発生数」自体が少ない場合は、そもそも共有したくなる設計になっていない可能性があります。

ステップ5：フリーミアムとアップグレード設計を組む

バイラルPLGで大量に獲得した無料ユーザーを収益に変える仕組みが必要です。Calendlyの場合、無料プランではカレンダー接続数・イベントタイプ数に制限があり、チームでの利用・カスタムブランディング・分析機能には有料プランが必要な設計です。

設計の核心は「バイラルが起きる機能は制限しない」ことです。共有リンクの基本機能を無料プランで制限してしまうとバイラルが止まります。一方で「規模が増えると必要になる機能」で課金する。チーム機能・分析・カスタマイズがアップグレードの動機になります。

Stripeを使えば、フリーミアムから有料への転換はシートベース・使用量ベースのどちらでも実装できます。最初のうちは複雑な設計を避け、「機能の壁を感じた人が自然にアップグレードする」という単純な構造から始めます。転換率が安定してから、オンボーディングメールや製品内トリガーで能動的なアップグレード訴求を加えていきます。