リード

LPを1本作ったのではない。LP製造装置を作った。

V0でプロトタイプ、Next.jsで本番化、SKILLで業種別に量産する。フォームからSlack通知・スプレッドシート管理・自動返信まで、リード管理の仕組みもセットで構築した。この全工程を残しておく。

業種別LPを1本ずつ作ると、非線形にコストが増える

AI顧問サービスのLPを作るとき、最初に考えたのは「誰に向けて作るか」だった。

士業向け、EC向け、スタートアップ向け。業種が違えば、ペインポイントも、言葉の選び方も、事例も変わる。汎用版LPは存在できるが、業種を絞ったほうが問い合わせ率は上がる。業種別に作るのが正しい、という結論に至った。

問題は、1本ずつフルスクラッチで作ると、コストが業種の数に比例することだ。いや、正確には比例より悪い。毎回デザインの判断からやり直すと、2本目・3本目でも初回と同じ時間がかかる。

「1本作ったら10本作れる設計」が必要だと気づいた。

V0でベースLPを1日以内に作った

まず汎用版のベースLPを作ることにした。使ったのはV0だ。

V0は、プロンプト（指示文）を渡すとWebサイトのコードを出力するAIツールだ。デザインカンプを作ってからコーディングする、というフローを省略できる。「こういうLPを作りたい」という要件を言葉で書き込めば、動くコードが出てくる。出力されるコードはNext.js / React / Tailwind CSSという構成で、そのまま本番で動かせる品質だ。

「かっこいいLP」は1日以内に手元に来た。

セクション構成はHero・Philosophy・Services・How It Works・Pricing・About・FAQ・CTAで組んだ。スタイルはダークトーン。ページ全体をなめらかにスクロールするアニメーションも実装した。

コードはNext.jsの構成で出力された。Vercel（Next.jsを開発したチームが運営するホスティングサービスで、GitHubにプッシュするだけで自動デプロイされる）に繋げばすぐ公開できる状態だ。

しかし、ここで最初の問題に気づいた。

「かっこいい」と「問い合わせが来る」は別の話

動くLPはできた。見た目は良かった。しかし「これで問い合わせが来るか」という問いに、答えられなかった。

ヒーローコピーが抽象的だった。誰向けかが伝わっていなかった。悩みを言語化するセクションがなかった。事例がなかった。CTAが1箇所しかなかった。

「かっこいいLP」を「問い合わせが来るLP」に変えるための改修が必要だった。

ここでもV0を使った。「修正指示」をプロンプトで渡す方法だ。追加するセクション、変更するコピー、実装するロジックを指示として書き込み、差分コードを出してもらう。

v2での主な変更：

• Heroにターゲットを明示（社員5〜30名規模の中小・個人事業主）
• 「こんな悩みはありませんか？」セクションを新規追加（6項目）
• 事例セクション（CASE）を新規追加（課題→支援→結果の3カード構成）
• CTAを全セクション末尾に繰り返し配置

v3での追加変更：

• CTAの文言を行動ベースに統一（「無料相談する」→「自社のAI化ポイントを30分で整理する」）
• 「こんな方には向かない」セクションを追加（逆張り設計）
• How It Worksを3ステップ→4ステップに拡張し、費用が発生するタイミングを明示

v2・v3の修正指示は、V0に貼り付けるプロンプトとしてドキュメントに残してある。次の業種別LPを作るとき、同じ完成度からスタートできる。

同じことを自分の事業でもやりたい方。設計相談はこちら → ai.tosakafunk.com

V0のコードはNext.jsにそのまま入る

ここが核心だ。

V0はNext.jsのコードを出力する。だからV0で作ったものをNext.jsリポジトリに入れるとき、変換や書き直しが不要だ。コピーしてGitHubにプッシュすれば、Vercelが動くものをデプロイしてくれる。

従来のLP制作フローでは、デザイン→コーディング→レビュー→修正、という工程があった。それぞれに専門性が必要で、時間もかかる。V0はデザインとコーディングを同時に出力する。そのコードがそのまま本番で使えるから、間に挟まる工程がなくなる。

ただし、V0で完結するのは「プロトタイプ品質まで」という認識でいる。本番に向けての最適化や細かい調整は別途やる。あくまでV0は「動くものを最速で手に入れるツール」だ。

ページだけ作っても意味がない：リード管理の仕組みもセットで作る

LPは「問い合わせを受け取る装置」だ。受け取った後の仕組みがなければ、ページがどれだけ良くても意味がない。

ベースLPには、問い合わせフォームから始まる一連のフローがすでに組み込んである。

フロント：Next.jsのカスタムフォーム + Cloudflare Turnstile

フォームコンポーネントはNext.jsで自作している。GoogleフォームやTypeformは使っていない。理由は、デザインをLPに完全に合わせたかったからだ。

スパム対策にはCloudflare Turnstileを使っている。reCAPTCHAの代替で、ユーザーに「私はロボットではありません」チェックをさせない。バックグラウンドで判定が完了し、ボットだけをはじく。

バックエンド：GASウェブフック → Googleスプレッドシート + Slack通知 + 自動返信メール

フォームが送信されると、GASのウェブフックにデータが飛ぶ。GASが受け取った後にやることは3つだ。

1. Googleスプレッドシートに記録する。氏名・メールアドレス・問い合わせ内容・送信日時・送信元LPを1行として追加する。
2. Slackに通知を送る。問い合わせが入った瞬間にSlackのチャンネルに飛んでくる。メールより早く気づける。
3. 自動返信メールを送る。送信者に「受け取りました」メールを即時送信する。問い合わせ後に「届いたのか？」という不安を消す。

GASのスプレッドシートには「対応ステータス」列があり、GASの関数を呼び出すことでステータスを「未対応 → 対応中 → 完了」に更新できる。簡易的なCRMとして機能する。

10本のLPが1つのスプレッドシートに集約される

ここが重要な設計ポイントだ。

業種別LP10本は、全部同じGASウェブフックに繋がっている。スプレッドシートの「送信元」列に ai-tax.tosakafunk.com や ai-ec.tosakafunk.com といったドメインが記録されるので、どのLPから来た問い合わせかが一目でわかる。

管理画面は1つ。10本分の問い合わせを一元管理できる。

GASとスプレッドシートはベースLPと共用なので、新しい業種のLPを追加しても管理側の作業はゼロだ。Vercelの環境変数にウェブフックURLをコピーして設定するだけで、新しいLPの問い合わせが自動的に同じスプレッドシートに流れ込む。

差分設計：ベースLPに何を変えれば業種別LPになるか

ベースLPの型が固まったところで、「業種別に変える部分はどこか」を整理した。

全体のコードのうち、業種によって変わるのは2ファイルだけだ。

app/site-config.ts（サイト全体の設定ファイル）

• URL（ai-[slug].tosakafunk.com）
• アクセス解析の測定ID
• メタタイトル・description・SNSシェア用テキスト
• 検索キーワード配列

app/page.tsx（ページの中身）

• ヒーローコピー（h1・サブコピー・補足テキスト）
• ペインポイント6項目
• サービス内容3項目
• 事例3カード
• FAQ（業種特有の質問を前半に）
• CTAボタンテキスト

デザイン・コンポーネント・フォーム・スクロールアニメーション・スパム対策——これらはすべて共通のままでいい。変えるのはコンテンツだけだ。

この「差分だけ書けばいい」という構造が、量産の前提になる。

SKILL化：工程をコマンド一発で立ち上げる

差分設計ができたところで、業種別LP展開の全工程をSKILLにした。/lp-expand というコマンドで呼び出す。

SKILLの内容は5フェーズで構成している。

フェーズ1：調査・戦略

対象業種のペインポイント・競合・差別化ポイントを整理し、リサーチドキュメントとして記録する。調査結果がそのまま次フェーズのコンテンツ差し替えのインプットになる。

フェーズ2：セットアップ

ベースLP（lp-tosakafunk-ai）のリポジトリをコピーして業種別リポジトリを作る。不要なファイルを除外し、GitHubにリモートを設定する。その後、2つの設定ファイルを業種特化コンテンツに書き換える。

Vercelのデフォルトドメイン（lp-tosakafunk-ai-[slug].vercel.app）からカスタムドメインへのリダイレクト設定もコードに追加する。Vercel管理画面での追加操作が不要になり、コードだけで管理できる。

フェーズ3：公開・ドメイン設定

VercelにプロジェクトをインポートしてカスタムドメインをVercelに追加する。合わせてDNSの設定（ドメイン管理サービス側でCNAMEレコードを追加）を行い、サブドメインを向ける。

環境変数（お問い合わせフォームの通知先・スパム対策のキー）はベースLPからコピーして設定する。環境変数追加後は再デプロイが必要なので忘れない。

スパム対策（Cloudflare Turnstileというボット判定サービス）は、新しいサブドメインを許可リストに追加しないとフォームが動かない。最初の立ち上げで1回忘れた。

フェーズ4：計測設定

Google Analytics 4（GA4）でプロパティ作成 → BigQueryへのデータ連携 → Google Search Consoleで検索データの収集開始、という順で進める。

GA4はGoogleが提供するアクセス解析ツール。「どこから来たか」「どのページを見たか」「フォームを送信したか」といったデータを収集する。

BigQueryはGoogleのデータ分析基盤で、GA4で収集したデータを大量に蓄積・SQL（データを取り出すためのクエリ言語）で分析できる。GA4のダッシュボードでは見られないような詳細なデータを掘り下げるために使う。毎日（Daily）でエクスポートするよう設定する。

GA4のコンバージョンイベントはgenerate_lead（問い合わせ完了）だ。フォーム送信成功時に自動発火するよう、すでにベースLPのコードに実装してある。GAダッシュボードで「コンバージョンとしてマーク」するだけでいい。

Google Search Consoleは検索キーワードや表示順位を管理するツール。所有権の確認はGA4連携で行う。GA4設定済みなら追加コード不要で確認が通る。

フェーズ5：動作確認

検索エンジンへの案内ファイル（robots.txt・sitemap.xml）にアクセスできるか確認し、フォーム送信テストでSlack通知とスプレッドシートへの記録が動いているか確認する。

1本目と10本目で、かかる時間が変わる

LPを量産するとき、コストは通常「本数×1本あたりの工数」で増える。

この設計だと違う。

ベースLP構築が終わった後は、業種ごとに変わるのはリサーチとコンテンツ差し替えだけだ。インフラの判断、コンポーネント設計、スタイルの決定——これらは1回しかやらない。

実際の工数目標：

• ベースLP構築（v1〜v3）：約1週間
• 業種別LP 1本：リサーチ半日 + コンテンツ差し替え半日 = 1日以内

10本目は、1本目より速い。それが「製造装置」という言葉を使った理由だ。

次の構想：LPが自律的に更新され続ける仕組み

「製造装置」が動き始めたら、次のステップがある。作って終わりではなく、LP10本が自律的に改善され続ける仕組みだ。

構想しているのは3つのSKILLの追加だ。

データ集計・分析のSKILL化

BigQueryに蓄積されたアクセスデータを定期的に自動集計し、レポートを出力するSKILLを作る。「どの業種LPでどのセクションが読まれているか」「CTAのクリック率はどの業種が高いか」「検索キーワードはどう変化しているか」といった分析を、コマンド一発で出せるようにする。

LPブラッシュアップ案・ABテスト提案のSKILL化

集計データを元に、SKILLが改善案を提案する。「このセクションのコピーをこう変えるとCVRが上がると予測する」「このキーワードでのABテストを提案する」という形で、次のアクションを提示してくれる。

人間がやることを「承認」と「調整」だけにする

最終的に目指しているのは、自分の仕事を「提案を見て判断する」だけにすることだ。

分析も、改善案の提案も、コードの差し替えも、SKILLが進める。自分は提案を見て「これでいく」か「この方向に修正して」かだけを判断する。マーケターとしての判断力と構想力だけを使い、実作業はSKILLに任せる。

LP製造装置を作った次のステップは、LP改善装置を作ることだ。

現在の派生LP計画

ベースLP（ai.tosakafunk.com）から展開予定の業種別LPは以下のとおりだ。

/lp-expandを呼び出せば、このリストはいつでも伸ばせる。

設計の話から始める

「LPを作りたい」という依頼は多い。しかし多くの場合、作るべきは「LP1本」ではなく「LP製造装置」だと思っている。

1本で終わる可能性が低いからだ。業種を変えたい、訴求を変えたい、季節のキャンペーンを打ちたい——そういう派生が必ず来る。最初から量産と改善を前提に設計しておけば、その派生が安く・速くなる。

V0・Next.js・Vercel・SKILLはどれも手段にすぎない。大事なのは「どう設計するか」だ。

LP設計から量産フローまで、一緒に考えます → ai.tosakafunk.com

---