「これ、絶対需要あると思うんだけど」と思いついたアイデアを、いきなり開発に進めてしまう前に、一度立ち止まってほしいことがあります。それは「本当に欲しい人がいるかどうか」を、お金や時間をかけずに確かめる方法があるということです。その代表的な手法が、ランディングページ（LP）を使った需要検証です。
この記事では、ランディングページ（LP）を使ってサービスへの需要を確かめる方法を、具体的な手順とともに解説します。会社員として複業で再挑戦する方も、まず小さく検証してから本業や複業の時間を投じたい方も、共通して使える考え方です。思いついたアイデアに時間とお金を投じる前に、この記事で紹介する手順を一度通してみることをおすすめします。
この記事で分かること
サービスを開発する前にランディングページで需要を検証することには、明確なメリットがあります。作り込む前に「本当に欲しい人がいるか」が分かれば、開発に進むべきか、アイデアを見直すべきかを、感覚ではなくデータで判断できるようになります。
結論を先に示すと、この記事で伝えたいポイントは次の3つです。
- ランディングページ検証とは、実物のサービスを作る前に「1枚の説明ページ」だけを用意し、興味を持つ人の反応を数値で確かめる手法である
- 見るべき指標は「見た人の数」ではなく「行動した人の割合（登録率・クリック率）」であり、目安となる数字の基準がある
- 反応が悪かった場合こそ価値がある。開発せずに気づけたことは、時間とお金の節約になる
ランディングページ検証とは何か
ランディングページ検証（LP検証）とは、実際にサービスやアプリを開発する前に、そのサービスを紹介する1枚のWebページだけを作り、そこに人を集めて反応を確かめる手法です。ページを見た人が「もっと知りたい」「使ってみたい」と思った場合に、メールアドレスの登録や、事前登録ボタンのクリック、簡単なアンケートへの回答といった、何らかの行動を取ってもらうように設計します。
この手法が有効なのは、「作ってから欲しい人を探す」のではなく、「欲しい人がいることを先に確かめてから作る」という順番に変えられる点です。開発には、早くても数週間、規模によっては数ヶ月かかることが多く、まとまった費用もかかります。その前に、数日から1週間程度、数千円から数万円程度のコストで需要のあたりをつけられるのが、ランディングページ検証の最大の利点です。
検証を始める前の構想の固め方から確認したい場合は、「あったらいいのに」を、形にできるアイデアに変える。構想期の進め方も参考になります。この考え方は、MVP（実用最小限の製品）（実用最小限の製品）やPoC（概念実証）（概念実証）と近い発想ですが、ランディングページ検証はさらに手前の段階にあります。MVPは「動くもの」を最小限作って検証しますが、ランディングページ検証は「動くものすら作らず」、説明文だけで検証する点が特徴です。つまり、検証の階段としては、
- ランディングページ検証（説明文だけ、開発ゼロ）
- ベータ版・ベータリリース（最小限動くものを一部の人に試してもらう）
- 本格開発・正式リリース
という順序で考えると分かりやすくなります。いきなり2や3に進むのではなく、1から始めることで、失敗した場合の損失を最小限に抑えられます。
なぜ「作ってから確かめる」のは危険なのか
複業や個人開発でよくある失敗パターンは、「アイデアを思いついたら、すぐに開発に着手してしまう」という進め方です。数ヶ月かけて機能を作り込み、いよいよ公開してみたら、思ったように登録者が集まらない。この段階になってから「そもそも誰も欲しがっていなかったのではないか」と気づくのは、非常につらい経験です。
このパターンが起きる理由は、いくつかあります。
理由1：自分が欲しいものと、市場が欲しいものは違うことが多い
自分自身が不便を感じていることは、必ずしも他の多くの人が同じように感じているとは限りません。自分にとっては強い課題でも、実は自分の職業・環境・性格に特有の悩みで、一般化できない場合があります。
理由2：知人の「いいね」は本当の需要ではない
アイデアを友人や同僚に話すと、多くの場合「いいね、それ」「使いたいかも」といった好意的な反応が返ってきます。しかし、これは社交的な相づちであることが多く、実際にお金を払って使うかどうかとは別問題です。ランディングページ検証では、実際に行動（登録・クリック）した人の数という、社交辞令が入り込みにくい指標で確かめられます。
理由3：作り込むほど、方向転換のコストが上がる
開発が進むほど、後から方向転換（ピボット）するのが難しくなります。機能を作り込んでしまった後で「実は誰も欲しがっていなかった」と分かると、その機能を丸ごと作り直すことになり、時間とお金の両方を失います。ランディングページの段階であれば、テキストと画像を変えるだけで方向転換できるため、傷が浅い状態で軌道修正できます。
ランディングページ検証の具体的な手順
ここから、実際にランディングページ検証を進める手順を、順番に解説します。
ステップ1：1つの価値提案に絞ってページ文章を書く
まず、ランディングページに書く文章を用意します。ポイントは、機能の説明ではなく「誰の、どんな悩みを、どう解決するか」という価値提案を中心に書くことです。
書くべき要素は次の通りです。
- 見出し（キャッチコピー）：一文でサービスの価値が伝わる言葉
- サブ見出し：見出しを補足する具体的な説明
- 悩みの提示：想定する利用者が抱えている課題を言葉にする（共感を得る部分）
- 解決策の提示：そのサービスがどう解決するかを、機能名ではなく効果で説明する
- 行動ボタン：「事前登録する」「気になる方はこちら」などのボタン
- （あれば）価格の目安：料金に対する反応も見たい場合は、想定価格を記載する
このとき、機能の網羅的な説明よりも「一言で言うと何が嬉しいのか」を明確にすることを優先してください。機能が多いページほど、逆に「結局何のサービスか分かりにくい」ページになりがちです。
ステップ2：ページを実際に作る
文章ができたら、ページ自体を作ります。この段階でも、コードを書く必要はありません。以下のような選択肢があります。
- ノーコードのページ作成サービス（無料プランがあるものが多い）
- フォーム作成サービスに、簡単な説明文を添えるだけの簡易版
- 資料作成ツールで1枚のスライドを作り、それをPDFやWeb公開機能で共有する方法
デザインの完成度は、最初はそれほど重要ではありません。「何のサービスか」「なぜ良いのか」「次に何をすればいいか」が伝わることの方が優先です。時間をかけすぎず、まずは半日から1日程度で公開できる状態を目指すことをおすすめします。
ステップ3：行動を促す仕掛けを1つ用意する
ページを見た人に、何らかの行動を取ってもらう仕掛けを用意します。代表的なものは次の3つです。
- メールアドレスの事前登録フォーム：「サービス公開時にお知らせします」という形で、メールアドレスを集める
- 有料予約・デポジット：本当に「お金を払ってもいい」と思っているかまで確かめたい場合、少額の予約金を求める（この手法はベータ版・ベータリリース枠の先行申込みに近い設計です）
- アンケートへの回答：登録の代わりに、簡単な質問に答えてもらう形式
どれを選ぶかによって、検証の厳しさが変わります。メールアドレスの登録だけを求めるのが最も手軽で、多くの登録検証がまずここから始めます。一方、少額でもお金を払ってもらう検証は、より本気度の高い需要を確かめられますが、その分ハードルが上がり、集まる数自体は少なくなる傾向があります。最初はメールアドレス登録から始めて、反応が良ければ次の段階で有料予約を試す、という進め方が無理がありません。
ステップ4：ページに人を集める
ページを作っただけでは、誰にも見てもらえません。人を集める方法として、次のような選択肢があります。
- SNS（X、Instagram等）での発信
- 想定する利用者が集まるコミュニティ・掲示板での紹介（宣伝目的だけの投稿はマナー違反になりやすいので、コミュニティのルールを確認する）
- 少額の広告（SNS広告等。数千円程度から始められるものもある）
- 知人・同僚への直接の共有（ただし前述の通り、知人の反応は補助的な情報に留める）
ここで重要なのは、「できるだけ、想定する利用者そのものに近い人に見てもらう」ことです。全く関係のない人が1000人見てくれても、需要の判断材料にはなりません。ターゲットに近い人が100人見て、そのうち何人が行動したか、という質の高いデータを集めることを意識してください。
ステップ5：数字を記録し、期間を決めて振り返る
最後に、集めたデータを記録し、あらかじめ決めた期間（例えば1週間、または2週間）で一度振り返ります。
記録すべき数字は次の通りです。
- ページを訪れた人の数（訪問数）
- 行動（登録・クリック・回答）した人の数
- 行動した人の割合（行動した人数 ÷ 訪問数）
この「行動した人の割合」が、需要検証における最も重要な指標です。次のセクションで、この数字をどう読むかを詳しく説明します。
見るべき指標と、目安になる数字
ランディングページ検証で最もよくある間違いは、「訪問数の多さ」だけで満足してしまうことです。SNSでバズって1万人が見てくれたとしても、そのうち登録した人が10人しかいなければ、需要の裏付けとしては弱いと考えるべきです。逆に、100人しか見ていなくても、そのうち20人が登録すれば、強い需要のサインと言えます。
見るべき指標は、次の「行動した人の割合」（コンバージョン率、または登録率）です。
行動した人の割合 ＝ 行動した人数 ÷ ページを訪れた人数 × 100（％）
一般的な目安として、次のような数字が参考にされることが多いです（業種やターゲットの質によって変動するため、あくまで参考値です）。
| 行動した人の割合 | 目安となる評価 |
|---|---|
| 1％未満 | 需要が弱い可能性が高い。ページの訴求内容の見直しを検討 |
| 2〜5％ | 一般的な水準。ターゲットや訴求の精度をさらに上げる余地あり |
| 5〜10％ | 良好な水準。前向きに開発を検討できる材料 |
| 10％以上 | 強い需要のサイン。ただし訪問者の質（ターゲットとの合致度）も併せて確認する |
ここで注意したいのは、訪問者の質が低いと、この数字自体の信頼性も下がるという点です。全く関係のない人ばかりを集めたページで割合が低いのは当然であり、それは「需要がない」ことの証明にはなりません。逆に、ターゲットに近い人だけを集めたページで割合が低ければ、それはより強い「需要が弱いかもしれない」というシグナルになります。人を集める段階で、できるだけターゲットに近い層にリーチする工夫が、この検証の精度を左右します。
また、絶対数の少なさにも注意が必要です。訪問者が10人しかいない状態で「2人登録したから20％だ、需要がある」と判断するのは早計です。最低でも50〜100人程度の訪問数を確保したうえで、割合を評価することをおすすめします。
反応が悪かったときこそ、価値がある
ランディングページ検証を始める方の多くは、「良い反応が出ること」を期待して取り組みます。しかし実際には、反応が悪かった結果こそが、この検証の一番の価値だと考えることをおすすめします。
もし数百人に見てもらって、登録した人がほとんどいなかったとしたら、それは「このアイデアのまま開発に進んでも、同じように反応が薄い可能性が高い」ということを、開発前に、しかも数千円程度のコストで教えてくれたということです。もしこれを検証せずに数ヶ月かけて開発していたら、同じ結論に達するまでに、はるかに大きな時間とお金を失っていたはずです。
反応が悪かった場合、次に考えるべきことは「アイデア自体をやめる」ことだけではありません。むしろ、次のような見直しの余地を探ることをおすすめします。
- 訴求の仕方が悪かった可能性：同じサービス内容でも、見出しや悩みの提示の仕方を変えると反応が変わることがあります。文章を変えて、もう一度検証してみる価値があります。
- 対象を集める場所が間違っていた可能性：ターゲットが実際にいる場所とは違うところで宣伝していた可能性があります。集める場所を変えて再検証します。
- アイデアの前提そのものを見直す可能性：訴求や集客先を変えても反応が変わらない場合は、アイデアの核となる部分（誰の、どんな悩みを解決するか）に立ち返って見直す必要があります。
このように、1回の検証結果だけで一足飛びに「ダメだった」と結論づけるのではなく、変数を1つずつ変えながら、2〜3回検証を繰り返すことをおすすめします。それでも反応が変わらない場合は、いったんこのアイデアへの投資を止め、別のアイデアに時間を使う判断も、賢明な選択のひとつです。
よくある失敗パターン
ランディングページ検証を実際にやってみると、いくつかの共通した失敗パターンに陥りがちです。事前に知っておくことで、同じ失敗を避けやすくなります。
失敗パターン1：機能を全部書いてしまう
「せっかく作るなら」と、思いついた機能を全部ページに書き込んでしまうケースです。機能が多いページは、一見充実して見えますが、実際には「結局何のためのサービスなのか」が伝わりにくくなります。1つの核となる価値提案に絞り込むことをおすすめします。
失敗パターン2：デザインに時間をかけすぎる
検証の目的を忘れて、デザインの完成度にこだわりすぎてしまうケースです。検証段階のページは、あくまで「反応を確かめるための仮のもの」です。デザインに1週間かけるよりも、1日で公開して人に見てもらう方が、得られる学びは大きくなります。
失敗パターン3：身近な人にしか見せない
知人や家族にだけ見てもらい、「いいねと言われた」ことに満足してしまうケースです。前述の通り、身近な人の反応は社交的な配慮が混ざりやすく、実際の需要とは異なることが多いです。できるだけ自分と直接の関係がない、ターゲットに近い層に見てもらうことを意識してください。
失敗パターン4：良い数字が出るまでページを何度も直してしまう
数字が悪いと、ページの文言を何度も書き直して、良い数字が出るまで粘ってしまうケースです。もちろん訴求の改善自体は有効な手段ですが、「良い結果が出るまで検証を続ける」という姿勢では、本当に需要がなかった場合にもそれに気づけなくなります。あらかじめ「〇回試して反応が変わらなければ、いったん立ち止まる」という基準を決めておくと、無限にやり直す事態を避けられます。
失敗パターン5：登録者に何もフォローしない
検証で登録してくれた人たちは、興味を持ってくれた貴重な相手です。ここで登録だけしてもらって、その後何の連絡もしないままにしてしまうと、実際に開発が進んだときに再度アプローチする機会を失います。検証の段階で「進捗があればお知らせします」といった簡単な一言を伝え、後から連絡できる関係を維持しておくことをおすすめします。
複業として検証する場合の視点
会社員として複業で再挑戦する方や、複業でまず検証してみたいと考えている方にとって、ランディングページ検証には特に大きなメリットがあります。
複業の場合、使える時間は限られています。平日の夜や休日にまとまった開発時間を確保するのは簡単ではなく、貴重な時間を投じる前に「本当にやる価値があるアイデアか」を見極めることの重要性は、専業で取り組む場合よりもむしろ高いといえます。
ランディングページ検証は、開発の知識がなくても、平日の夜1〜2時間程度の作業を数日重ねるだけで完了できます。本業がある中でも無理なく進められる規模の作業である点が、複業での取り組みに向いています。
また、過去に一度アイデアがうまくいかなかった経験がある方（会社員として複業で再挑戦する方の中には、以前に一人で開発まで進めて反応がなかった、という経験を持つ方も少なくありません）にとっては、この検証プロセスを踏むこと自体が、「今回は同じ失敗を繰り返さない」という安心材料にもなります。前回は感覚だけで開発に進んでしまった、という反省があるなら、今回はまず数字で確かめてから動く、という進め方に変えることをおすすめします。
さらに、複業で検証する場合は、検証にかけられる期間や広告費にも制約があることが多いはずです。無理に大きな予算をかけず、まずは無料のSNS発信と無料のページ作成サービスの範囲内で、小さく検証を始めることをおすすめします。数字が良ければ、そこで初めて有料広告や本格開発への投資を検討する、という段階的な進め方が、複業という制約のある状況では特に理にかなっています。ランディングページ検証で需要が確認できたら、次はいよいよ開発フェーズです。特に個人・小規模チームでの開発では、PoCから本番運用へ進める際の勘所も事前に押さえておくと、後の手戻りを減らせます。
ランディングページ検証と、他の検証手法の組み合わせ方
ランディングページ検証は強力な手法ですが、これだけで全てが分かるわけではありません。他の検証手法と組み合わせることで、判断の精度が上がります。
- ユーザーインタビューとの組み合わせ：ランディングページで登録してくれた人に、後から個別に話を聞くことで、「なぜ登録したのか」「どんな場面で使いたいと思ったのか」という、数字だけでは分からない背景を知ることができます。
- 検索需要調査との組み合わせ：ページを公開する前段階で、そもそもそのテーマに関する検索需要があるかを確認しておくと、ページに人を集める際の見通しが立てやすくなります。
- フェイクドアテストとの組み合わせ：ランディングページの「行動ボタン」を、実際の購入ボタンのように見せて、クリックした人に「近日公開予定です」と伝える手法（フェイクドアテスト）を組み合わせると、より強い需要のシグナルを確認できます。
これらの手法は、それぞれ得意な検証の側面が異なります。ランディングページ検証は「多くの人からの反応を数字で見る」ことに強く、ユーザーインタビューは「少数の人から深い理由を聞く」ことに強い、という違いを理解して、両方を組み合わせることをおすすめします。
Q&A：ランディングページ検証によくある疑問
Q1. まだサービス名も決まっていないのですが、それでも検証を始められますか。
始められます。むしろ、名前やブランディングにこだわる前に、価値提案そのものが受け入れられるかを確かめる方が優先度は高いです。仮の名前で検証を始めて、反応が良ければ、その後じっくり名前を検討する、という順番でも問題ありません。ただし、ドメインを後から変更すると、検証時に集めたメールアドレス登録者への案内が分かりにくくなることがあるため、ページのURL自体は分かりやすい仮称で統一しておくことをおすすめします。
Q2. 競合が既にいる場合、ランディングページ検証はやる意味がありますか。
意味があります。競合が存在するということは、そのテーマに需要があること自体はある程度証明されているとも言えます。その場合のランディングページ検証は、「需要があるかどうか」ではなく、「自分の切り口・訴求の仕方に、既存の競合とは違う魅力を感じてもらえるか」を確かめる目的で活用します。競合との違いを明確にした訴求文で検証し、反応を見ることをおすすめします。
Q3. 登録してくれた人には、その後どう対応すればよいですか。
まずは、検証への協力に対するお礼の連絡を送ることをおすすめします。その後、実際に開発を進める場合は、進捗の節目ごとに簡単な報告を送ると、登録してくれた人たちとの関係を維持できます。もし検証の結果、開発を見送ることにした場合も、その旨と理由を簡単に伝えると、誠実な対応として好意的に受け取られることが多いです。将来別のアイデアで再度声をかけたときにも、良い関係が続きやすくなります。
具体例で見る：良い訴求文と、伝わりにくい訴求文の違い
ランディングページ検証の成否は、訴求文の書き方に大きく左右されます。ここでは、架空の例を使って、伝わりにくい訴求文と、改善後の訴求文を比較してみます。
例：個人事業主向けの請求書作成サービスを検証する場合
改善前の見出し例として、「クラウド型請求書発行・管理・郵送代行システム」という書き方があります。これは機能を並べただけの文章で、読んだ人は「便利そうだけど、自分にとってどう嬉しいのか」がすぐには分かりません。
改善後の見出し例として、「請求書作成に毎月2時間かけていませんか。3分で終わらせる方法」という書き方に変えると、悩みへの共感と、解決後のイメージが一文で伝わります。
この2つの違いは、「機能」を主語にするか、「悩みと解決後の状態」を主語にするかにあります。ランディングページ検証で反応が薄いと感じたときは、まず機能中心の文章になっていないかを見直すことをおすすめします。
同様に、サブ見出しや悩みの提示部分でも、次のような違いが生まれます。
- 伝わりにくい例：「請求書、見積書、納品書をワンストップで管理できます」（機能の列挙）
- 伝わりやすい例：「今月も、確定申告の時期に慌てて請求書を掘り出す羽目になっていませんか」（具体的な状況への共感）
具体的な場面を思い浮かべられる文章のほうが、読んだ人が「自分ごと」として受け止めやすくなります。訴求文を書くときは、抽象的な機能説明ではなく、想定する利用者が実際に困っている場面を、できるだけ具体的に描写することを意識してください。
検証結果を判断するときのチェックリスト
検証期間が終わったら、次のチェックリストを使って、結果を整理することをおすすめします。感覚だけで「良かった」「悪かった」と判断せず、項目ごとに確認することで、判断のブレを減らせます。
- [ ] 訪問者数は、判断に足るだけの数（目安として50〜100人以上）に達しているか
- [ ] 訪問者の大半は、想定するターゲット層に近い人たちだったか（無関係な層が多数を占めていないか）
- [ ] 行動した人の割合は、目安となる基準（2〜5％以上）を超えているか
- [ ] 登録・行動した人からの、自由記述コメントやアンケート回答に、共通する声や熱量の高い反応があったか
- [ ] 訴求文・ページデザイン・集客チャネルのうち、まだ試していない改善の余地が残っていないか
- [ ] 反応が悪かった場合、それは「アイデア自体」の問題か、「伝え方」の問題か、切り分けができているか
- [ ] 次に取るべき行動（開発に進む／訴求を変えて再検証する／アイデアを見直す）が、感覚ではなく数字を根拠に決められているか
このチェックリストの全項目に自信を持って答えられない場合は、結論を急がず、もう一度検証のサイクルを回すことをおすすめします。特に、訪問者数が少ない状態での判断は、良い結果も悪い結果も、どちらも信頼性が低いという点に注意してください。
検証にかける期間と予算の考え方
ランディングページ検証で悩みやすいのが、「どのくらいの期間、どのくらいの予算をかければよいか」という点です。目安として、次のような範囲で考えることをおすすめします。
期間の目安
最初の検証サイクルは、1〜2週間を目安に設定することをおすすめします。それより短いと十分な訪問者数が集まらず、それより長いと「検証」のつもりが「放置」になってしまい、次のアクションが遅れがちです。あらかじめ終了日を決めておき、その日になったら一度必ず数字を確認する、という進め方が習慣化しやすいです。
予算の目安
最初の検証は、無料の範囲内で完結させることをおすすめします。ページ作成サービスの無料プラン、SNSでの無償の発信だけでも、一定数の訪問者は集められます。もし無料の範囲で十分な訪問者数が集まらない場合に限り、数千円程度の少額広告を追加で検討する、という順序にすると、アイデアの初期段階で大きな金額を投じるリスクを避けられます。
複業として取り組む場合、時間も予算も限られていることが前提になります。最初の検証で大きな予算をかけてしまうと、たとえ結果が悪くても「もう少し予算をかければ変わるかもしれない」という後戻りしにくい心理状態に陥りがちです。小さく始めて、良い反応が確認できてから予算を増やす、という段階的な進め方を徹底することをおすすめします。
検証後、開発に進む場合の橋渡し
ランディングページ検証で良い反応が得られた場合、次のステップは本格的な開発ではなく、MVP（実用最小限の製品）の設計です。検証で分かった「どの訴求に反応したか」「どんな悩みを持つ人が登録してくれたか」という情報は、MVPで最初に作るべき機能を絞り込むための、貴重な材料になります。
このとき注意したいのは、検証段階で書いた訴求文の「全て」を、そのまま機能として実装しようとしないことです。訴求文はあくまで「関心を引くための言葉」であり、実際に価値を感じてもらうために必要な機能は、その中の一部に絞られることがほとんどです。登録者への簡単なヒアリングを行い、「訴求文の中で、特にどの部分に惹かれたか」を確認したうえで、MVPに含める機能の優先順位を決めることをおすすめします。
