コードを書く前にSaaSを検証するウェブサイトの作り方

コードを書く前にSaaSを検証するウェブサイトが証明すべきこと

“プレSaaS検証”とは、数か月のプロダクト開発に投資する前に、シンプルなウェブサイトを使ってあなたのアイデアが作る価値があるかどうかを示す証拠を集めることを指します。機能を出す代わりに、特定の人たちが意味のある行動を取るかどうかをテストします。

目的：虚栄指標ではなく意思決定

検証サイトは次の4点について明確なゴー／ノーゴーの判断を助けるべきです：

• 市場：この問題は十分に一般的で痛みが大きく、プロダクトに値するか？
• オーディエンス：単なる好奇心の訪問者ではなく、適切な人物や企業を引き寄せているか？
• ポジショニング：一目で理解でき、差別化が感じられる約束か？
• 価格：提示する価格帯やプラン構成に対して人は受け入れるか？

良い検証データは行動に結びつきます：メールサインアップ、デモ依頼、「通知希望」クリック、アンケートの完了、フォローアップへの返信など。ページビューや滞在時間は文脈を与えますが、厳しい疑問に答えることは稀です。

検証サイトが「約束」してはいけないこと

検証はリスクを減らしますが、成功を保証するものではありません。ランディングページは保持率や長期的な支払意思、競合対策の勝敗を証明できません。できることは、誰にも求められていないものを作るのを防ぐことです。

ソフトウェアを作ることと、証拠を作ることの違い

ソフトを作るときは機能を作っています。証拠を作るときは仮説を検証しています。

プレSaaS検証サイトは構造化された実験です：一つの明確な問題、一つの特定のオーディエンス、一つの簡潔な価値提案、そして一つの行動喚起。弱い結果は失敗ではなく、安価で速いシグナルです。アイデアを修正する、対象を絞る、メッセージを調整する、あるいは価格を再考する判断をコードを書く前にできます。

明確な仮説とターゲットユーザーから始める

検証サイトは特定の賭け（ベット）を中心に作られているときにのみ機能します。“誰にでも受ける”ようにしようとすると、ページが誰に効いたのか、なぜ効いたのかがわかりません。

1つのペルソナと1つの痛みのあるジョブを選ぶ

主たるペルソナは一文で説明できるようにします（役割＋状況）。例：「50〜200人規模の物流会社でスプレッドシートを使って配送を調整しているオペレーションマネージャー」。

次に、明確に痛くて頻繁に起きる1つのジョブを定義します。単に「生産性を上げる」ではなく、「ルートの突然の変更で発生する遅延を減らす」のように具体的にします。これでコピーが焦点を保ち、結果の解釈が可能になります。

誰が、何を、なぜ今：クリアな仮説を書く

あなたの仮説はテスト可能な主張の形にします：

• Who（誰）：ペルソナ
• What（何を）：彼らが求める成果（とあなたの提案するアプローチ）
• Why now（なぜ今）：緊急性（新しい規制、コスト上昇、チームの成長、ツール移行）

例：「中規模物流会社のオペレーションマネージャーは、配送遅延に対する顧客罰則が増えたため、ルート変更アラートを自動化するツールのウェイトリストに参加するだろう。」

テストすべき前提を3〜5個特定する

アイデアの最もリスキーな前提を列挙します：

• 緊急性：これはトップ3の問題か、それとも単なる不便か？
• 支払意思：ビジネスを維持できるだけ支払ってくれるか？
• チャネル：予測可能な獲得チャネルで届くか？
• 代替手段：スプレッドシートや既存ツールに満足していないか？
• 購入制約：承認やセキュリティレビュー、統合が必要か？

公開前に合格／不合格のシグナルを定義する

進める・止めるの判断基準を決めておきます。例：「一つのチャネルから2週間で少なくとも20件の適格サインアップ、うち30%が15分の電話に同意する」など。事前に定義しておけば、弱いシグナルを成功だと解釈するのを防げます。

ページをパンフレットではなくテストとして設計する

プレSaaS検証ページは“完成したように見せる”ためのものではありません。目的は「このオファーを見たときに適切な人が次のステップを踏むか」を答えることです。つまり、すべての要素は明確な実験をサポートするようにあるべきで、機能紹介のツアーではありません。

意図をテストするためのシンプルなワンページ構成

ページは分かりやすく予測可能に保ち、訪問者が迷わないようにして結果が混ざらないようにします。

• Promise（折り返し上部）：成果と対象を示す一文。例：「領収書を追いかけずに月次決算を2時間で終わらせる—小規模エージェンシー向け。」
• Proof（証拠）：疑いを減らすための軽めの信頼シグナル（これまでの実績、学んだこと、なぜ資格があるか）と、仕事を理解していることを示す具体性。
• Path to action（行動への道筋）：ステージに応じたコミットメントを求める主要なボタン。

追加セクションを入れるなら、機能を拡張するのではなく反論（時間、リスク、乗り換え、プライバシー）に答える内容にします。

主要CTAは1つに絞り、すべてをそこに向ける

データをクリーンに保つために主要な行動喚起を一つ選びます：

• ウェイトリスト：需要とユースケースを検証する場合
• デモ依頼：価値の一部を手動で提供できる、またはより高い意図の会話が欲しい場合
• 事前注文：支払意思をテストする準備ができている場合

「仕組みを見る」などのセカンダリリンクは控えめにして、主要CTAと競合しないようにします。

機能の羅列を避け、具体的なユースケースで成果を売る

機能リストは「いいアイデア」的な興味を引くだけで、本気のコミットメントを引き出しにくいことが多いです。代わりに、ユーザーが認識する具体的なシナリオで成果を説明します：

「経費を自動分類する」ではなく：「カードの明細をアップロードすると、次の請求前にプロジェクトごとにタグ付けされた顧客向けの経費報告書が手に入る」など。

ユーザーが普段使う平易な言葉を使う

ターゲット顧客がメールやチケット、求人投稿で使う言葉で書きます。社内用語は避け、観察可能な結果、節約される時間、避けられるミス、安堵の瞬間を示します。目的は見栄えよくすることではなく、瞬時に理解されて「はい」と言いやすくすることです。

測定可能なメッセージを作る

検証サイトがテストなら、メッセージは測定ツールです。目標は印象的に聞こえることではなく、訪問者が素早く自己選択できるようにして、異なる約束を比較できるようにすることです。

A/Bテストできる見出しの定型を使う

実用的な構造：

成果 + オーディエンス + 時間／労力の節約

例：

• 「ブティック系エージェンシー向けに、毎週より質の高い商談を3件多く獲得—日々のフォローアップ不要で」
• 「Eコマース向けに月末の帳簿を2日で終わらせる—混乱するスプレッドシートなしで」

この形式は期待値を明確にするため測定しやすく、共鳴すればCTAへのクリック率やサインアップが高くなります。

サブヘッドラインで問題とアプローチを名指しする

サブヘッドラインは次の2点を明確にします：

1. 扱う痛み（ユーザーの言葉で）
2. どのように解決するか（高度なレベルで、機能ではなく）

例：

「返信の遅さでリードを失うのを止めます。受信リクエストを適切な担当者にルーティングし、見込みが予約するまで自動でフォローを送ります。」

「オールインワン」や「最高のソリューション」といった曖昧な主張は避けます。テストしにくく、訪問者の判断を助けません。

検証可能な2–3のベネフィットを書く

ベネフィットの箇条書きは後で検証可能であるほど効果的です。たとえまだ提供していなくても、人々が何を求めているかをテストします。

• 「ガイド付きチェックリストでオンボーディング時間を数日から数時間に短縮」
• 「自動リマインダーと再スケジュールリンクで欠席を減らす」
• 「毎週の進捗を1つのダッシュボードで確認（手動レポート不要）」

実データがなければ「削減」「時間短縮」「より少ない」などの方向性を示す表現を使い、どのバージョンがコンバージョンするかをテストします。

混乱を減らすための短い「仕組み（3ステップ）」を入れる

短く一貫したフローは摩擦を減らし、オファーを現実的に感じさせます：

1. 接続：既存ツールを連携するか詳細を送信
2. 解析／準備：裏側で何が起きるかを示す
3. 成果の受け取り：ユーザーがいつ・何を受け取るか

メッセージを変えるときはページの他を安定させ、コンバージョントラッキングがコピーの変化を反映するようにします。

ステージに合ったCTAを選ぶ

CTAは検証サイトの測定器です。要求する情報が少なすぎるとあいまいな関心しか集められません。多すぎると、本来良い顧客をフィルタリングしてしまいます。現在学びたいことに応じたCTAを選びます。

1つのオファーを明確にする

ステージに合った単一のオファーを選び、ページをそれに合わせて作ります：

• ウェイトリスト：問題とオーディエンスを検証するのに最適
• コンシェルジュパイロット：ソリューションのアプローチを検証するのに最適
• 有料事前注文：支払意思を測るのに最適

複数のオファーを混ぜるとシグナルが希薄になります。

摩擦のバランス：努力量を確信度に合わせる

ルールは単純：オーディエンスと問題に自信があるほど、より多い摩擦（入力）を追加してリードの質を上げられます。

• メールのみ：最低摩擦。初期のアイデア検証に適する。
• 短いフォーム（3–6項目）：役割、会社規模、現在のツールなどの文脈を追加してもハードルになりにくい。
• カレンダー予約：最高摩擦。メッセージが既に共鳴している場合のコンシェルジュパイロットに最適。

フォームを使う場合は後でセグメントできる1つの質問を含めてください（例：「何を達成したいですか？」）。フォローアップインタビューが格段に有用になります。

インセンティブは慎重に、約束は厳密に

インセンティブは有効ですが具体的かつ安全であるべきです。

• 早期アクセスや限定割引を提供する場合、機能や日程を確約するような表現は避けます。
• サインアップした人が受け取るもの（更新、パイロット招待、短いインタビュー依頼）と現実的なタイムライン（例：「約4–6週間でパイロット開始を目指す」）を明確にします。

その明確さが信頼を高め、数だけ膨らませる“ジャンクサインアップ”を減らします。

倫理的なスモークテストで価格を検証する

価格は「後で考える」ものではありません。それはあなたが提示する約束の一部であり、誰がサインアップするかに強く影響します。プレSaaS検証サイトは、金銭を受け取らずに支払意思をテストできます（かつ誤解を与えない方法で）。

本物の価格アンカーをページに置く

2〜3のプラン（例：Starter / Pro / Team）を作り、詳細が未確定でも許容される範囲やパッケージングを学びます。各プランは短い説明と主要ベネフィット、明確な月額価格を持たせます。偽の割引や“期間限定”の圧力は避けます。

倫理的なスモークテストCTAを実行する

**「トライアルを開始」**のような高い意図のCTAを使いますが、プロダクトが存在するふりはしません。

クリック後は次のようにします：

• **「ウェイトリストに参加」または「早期アクセスをリクエスト」**に遷移
• 短い説明：需要を検証中で、プロダクトは開発中であること、および次のステップを説明
• 試用で何をしようとしたかを共有するオプション

これにより「購入しようとした」人のシグナルは得られる一方で透明性は保たれます。

課金モデルの仮定をテストする

数値だけでなく構造もテストします。トラフィックを分けて次のようなモデルを試します：

• 1席当たり（チーム向け）
• 利用量ベース（メーターされた価値向け）
• 固定月額（単純で予測可能）

プランごとの興味と離脱を測る

価格セクションのエンゲージメントと、プランごとのクリック率を追跡します。人がどこで離脱するかも追います：

• 価格閲覧 → プランクリック → 「トライアル開始」クリック → ウェイトリスト送信

もしProが最もクリックされるがウェイトリスト送信が少ないなら、価格やポジショニングが高すぎるか、価値がまだ明確でない可能性があります。

実証できない主張をしないで信頼を築く

まだプロダクトがない場合、信頼は通貨です。証明できない成果（「解約を40%削減」など）や存在しない顧客の暗示は信頼を失わせます。検証サイトは正直で具体的、リスクが低い印象を与えるべきです。

実際に検証できる“証拠の代替物”を使う

ロゴやケーススタディがなくても、なぜあなた（あるいはチーム）がこの問題を解けるのかを示せます。

• 創業者の物語：問題に直面した瞬間とその重要性
• 関連経験：過去の役割やドメインの専門性、関連する仕事
• プロセス：顧客と一緒にどのように作るか（例：「コードを書く前に20人のオプスリードにインタビューします」）

具体的にしてください。「ファイナンスオプスで10年」などは「生産性に情熱がある」より強いです。

ソーシャルプルーフに注意する

推薦文を入れるなら、それが実在し出典が明確であること。まだないなら、得られるもののプレビューに置き換えます。

例：

• 週次レポートのサンプル説明（アプリ内で既に存在すると偽らない）
• ビフォー/アフターのワークフローのモック
• 「最初の14日がどうなるか」の短いタイムライン

これらは明確に例やプレビューであることを示してください。

ステージに合ったリスク低減策を入れる

訪問者はスパムや時間の無駄、囲い込みを恐れます。簡潔で真実の保証を追加します：

• フォーム近くに簡潔なプライバシーノート（収集する情報、理由、データを売らないこと）
• 「いつでもキャンセル可」や「クレジットカード不要」は事実であれば記載
• 預り金を取る場合は返金条件を平易な英語で書く

FAQで反論に先回りして答える

短いFAQはもう一段の信頼を生みます。よくある懸念に答えます：

• 統合（最初にサポート予定のもの）
• 価値の提供時期（最初の成果が何でいつか）
• サポート（誰が応答し、ベータ期間の期待応答時間）

目的は“大きく見せる”ことではなく“信頼できそうに見せる”ことです。

本当のシグナルを捉えるために分析を仕込む

検証サイトが「誰が」興味を持ち「何を」したかを教えてくれないなら、あなたは推測することになります。プレSaaS検証の解析は、行動が意図を示すかに焦点を当てるべきで、総訪問数のような虚栄指標ではありません。

意図を示すイベントを追跡する

シンプルに始め、重要なステップがすべて計測可能であることを確認します。最低限追うべきは：

• ページビュー（トラフィックの基礎と離脱パターン）
• CTAクリック（次のステップへの興味）
• フォーム送信（コミットメント）
• 価格セクション閲覧（価格への関心と購買マインド）

複数のCTAがある場合は別々に追跡し、どの約束が反応を引き出しているかを見ます。

実際に使う変換指標を定義する

生のカウントだけでは意思決定に役立ちません。次のような比率の小さなセットを使い、どこで関心が落ちているかを示します：

• 訪問者 → CTAクリック（メッセージの明確さと関連性）
• クリック → サインアップ（摩擦と信頼）
• サインアップの質（適切な人か）

サインアップの質を測るために、フォームに一つ軽い判別子（役割、会社規模、「何を解決したいか」）を入れて、回答を週次でレビューします。

UTMタグでチャネルとメッセージを比較する

すべてのキャンペーンリンクにUTMパラメータを付け、ソースやアングル（広告文やコミュニティ）ごとに成果を比較します。命名規則（utm_source, utm_campaign, utm_content）を一貫させれば十分です。

週次のシンプルなダッシュボードで結果を確認する

複雑なBIツールは不要です。スプレッドシートや基本的なダッシュボードにUTMごとの週次トラフィック、イベント数、主要なコンバージョン率を表示します。目的は意味のある変化を見つけ、次に何をテストするかを判断することです。

コントロールされた実験のためにターゲットトラフィックを集める

トラフィックは、将来の顧客に近いものでなければ検証に役立ちません。ランダムな千人の訪問者よりも、適切な50人の訪問者の方が作るべきものを教えてくれます。

ペルソナに合う1〜3チャネルを選ぶ

ターゲットが既に集まっているチャネルで、意図が見えやすい場所を選びます：

• コミュニティ（Slack/Discord、サブレディット、ニッチフォーラム）：会話からのフィードバックや高速な反復に向く
• 検索（SEO記事や小規模な検索広告）：人々が問題を言語化して探しているときに有効
• 有料ソーシャル広告：職種や業界で精緻なターゲティングができる場合に有効

チャネルは少数に絞り、変数を分離して結果を比較しやすくします。

複数のメッセージを用意して制御されたテストを行う

広告や投稿の2–4バリアントを用意し、それぞれ異なる価値提案に軸を置きます。その他は同じに保ちます：同じランディングページ、同じCTA、可能なら同じターゲティング。こうすることでパフォーマンスの“なぜ”が解釈しやすくなります。

試せるメッセージ軸の例：

• 時間節約 vs コスト削減
• コンプライアンス／リスク低減 vs スピード
• 「X役割向け」ポジショニング vs 「Yユースケース向け」ポジショニング

小さな予算で学ぶ、拡大するためではない

洞察に使う許容範囲の予算から始めます。目的は方向性を示すシグナル（どの問題設定が適格なクリックを引くか）であり、完璧なCACモデルではありません。

クリックだけでなく品質を追跡します：スクロール深度、CTA完了、確認メールへの返信など。

ソース＋メッセージで勝者を記録する

簡単な表やドキュメントに記録します：

• トラフィックソースとターゲティング
• メッセージバリアント
• 訪問者 → CTAコンバージョン率
• リードの質に関するノート（役職、会社規模、インタビュー参加率）

最良の組み合わせは最も低コストのクリックではなく、最も強い意図を生むものです。

サインアップを顧客発見につなげる

サインアップは検証の終わりではなく、学習のスタートです。目的は“興味”を“具体性”に変えること：彼らが誰で何をしようとしているか、何を既に試したか、何があれば乗り換えるかを知ることです。

有用な程度の小さな摩擦を入れる

サインアップフォームに一つ短い質問を入れて匿名の需要を行動可能な文脈に変えます。複数選択か短文で、完了率が落ちないようにします。

例：

• 役割：創業者、オペス、セールス、ファイナンス、エージェンシーなど
• 主な課題：一つ選ぶ（または「その他」）
• 現在の代替手段：スプレッドシート、競合、社内ツール、未対応

この一つの質問でフォローアップが格段に良くなります。彼らの現実に基づいた質問ができるからです。

全員にプレッシャーをかけずにインタビューへ誘う

オプションのチェックボックスを入れます：「この件について15分お話しできます」。チェックがあることは強い動機のシグナルで、アウトリーチを適格なリードに絞れます。

初期段階では次の人を優先してください：

• 想定ペルソナに一致する人
• 高コストの代替手段を報告している人
• 話すことに同意している人（チェック済み）

最初の返信を自動化し、その後パーソナライズする

サインアップ直後に自動メールを送り、1〜2の明確な質問を投げます。長いアンケートではなく返信しやすくします。

例：

• 「今はどのツールを使っていますか？」
• 「これが問題になる瞬間はいつですか（週次の締め、オンボーディング、レポーティング等）？」

その後、短く具体的な手動の招待メールを送ります：「15分いただければ、現在のXのやり方を理解したいです」など。

セグメントして洞察が平均化されないようにする

すべてのサインアップを一つにまとめないでください。役割、問題、回避手段でセグメントし、セグメントごとにコンバージョンや返信をレビューします。多くの場合、最良のセグメントは小さいが一貫しています。

次の簡単なステップ：スプレッドシートやCRMに3–5のペルソナタグを作り、インタビューのノートをタグ別にまとめることです。パターンが明白になり、「誰のために作るか」を見失わずにすみます。

組織的に反復する：テスト、期間、判断ルール

検証ページはいつまでも“生きている”ように感じられます—新しいアイデア、新しいコピー、新しい微調整。学習を速める最短の方法は実験室のように扱うことです：制御された変更、明確な期間、勝ちとみなすルールを事前に決めます。

1つの変数を分離するA/Bテストを実行する

何かを一度に一つだけ変えて、結果の原因が何かを知ります。見出しとCTAを同時に変えるとノイズが増えます。

良い単一変数テスト例：

• 見出し：問題主導（「〜に時間を奪われるのを止める」） vs 成果主導（「5分でレポート作成」）
• CTA：「ウェイトリストに参加」 vs 「早期アクセスを得る」
• 価格表示：開始価格を見せる vs 「価格はお問い合わせ」

ページの他の部分は同一にし、テスト途中で覗いて調整しないでください。

テストをタイムボックスし、最低サンプルサイズを定める

事前にテストの実施期間と何人の訪問者が必要かを決めます。

初期検証の実用ルール：

• 各バリアントにつき最低200–500訪問者を目安（トラフィックが安価で一貫するならもっと）
• 7–14日でタイムボックスして平日／週末の挙動を捕まえる

もし最低トラフィックに到達できないなら、それ自体がチャネルが実用的でないかターゲティングが外れているシグナルです。

シンプルな変更ログを保持する

記録すること：何を変えたか、なぜ変えたか、日時、トラフィックソース、結果（コンバージョン率、メールの質、インタビュー受諾）。これが循環的なテストを防ぎ、チームや投資家に決定を説明する助けになります。

テストを止めるタイミングを知る

ページの反復を止め、実際のパイロット構築に移るのは次のような一貫したシグナルが出たときです：

• ベストバージョンでの安定したコンバージョン率が複数のトラフィックバーストで再現される
• 繰り返し同じ痛みを語るインタビューが得られる
• 「いつ使えるのか？」と聞かれ、デモ／有料パイロット／デポジットといった具体的な次のステップを受け入れられる

その時点では、ボタンの色の微調整より最小限の実装を作る方が学びになります。

検証サイトから最初のSaaS構築へ

検証サイトが役割を果たしたなら、不確実性は減っています：誰が欲しがっているか、何を期待しているか、どれほど欲しているか（サインアップ、返信、支払意思で測定）を知っています。構築フェーズはそのシグナルの直接の延長であるべきで、新たなブレインストーミングではありません。

次に何を作るかを正しく選ぶ

約束した成果を提供できる最も軽いパスを選びます：

• コンシェルジュMVP：人々が結果を求めている場合は手作業で提供する（スプレッドシート、メール、ノーコード）。ワークフローや例外を素早く学べます。
• プロトタイプ：概念の理解に苦労する場合はクリック可能なデモやスクリプト化されたウォークスルーを作り、エンジニアリング前にユーザビリティと期待を検証。
• 狭い機能のMVP：需要が明確かつ繰り返される場合は、ランディングページのコア約束を満たす最小限のプロダクトを構築。

何を最初に作るかの判断基準

強い需要セグメントをスコープフィルタとして使います。最初のバージョンは次に基づいて作ります：

• インタビューで最も頻繁に言及された単一のジョブ・トゥ・ビー・ダン
• サインアップや支払いを阻んだ主要な1–2の反論
• 価値提案を明確な“完了”に結びつける1つのワークフロー

価格テストで感度が見られたらMVPは柔軟に（ティアは後でも）します。価格ページへの高い意図を示すユーザーが多ければ、初期オファリングは /pricing に期待されるものに合わせます。

初期導入フローを簡潔にして早期除外と学習を促す

初期オンボーディングは価値を早く確認し、フィードバックループを作るべきです：

1. 歓迎＋期待設定（次に何が起きるか、タイムフレーム）
2. 一つの質問でのインテイク（役割、ユースケース、データソース）
3. 最初の成功ステップ（インポート、接続、最初のプロジェクト作成）
4. パーソナルなフォローアップ（メールかカレンダーリンク）で体験が新しいうちに学ぶ

コントロールを失わずに構築を速める

検証のシグナルが強くなったら、ボトルネックはしばしば実行になります。ランディングページの約束とインタビューのノートから実際に動くウェブ／モバイルアプリに早く移すことが必要です。

vibe-codingのようなプラットフォーム（例：Koder.ai）はここで役立ちます。仕様（あるいはランディングページの約束＋インタビューノート）からチャットで動くWebやモバイルアプリに移せ、planning mode、スナップショットとロールバック、ソースコードエクスポートのような機能で素早く反復できます。狭いMVP（一般的にフロントはReact、バックはGo＋Postgres、モバイルはFlutter）を素早く出したいときに特に便利です。

検証の勢いを維持する

「Xユーザーが要求し、Z%が支払いを試みたのでXを作る」という決定ルールを文書化し、2～4週間のチェックポイントを設定します。次に何をすべきかの実用的チェックリストは /blog/your-next-step を参照してください。