「みんな、自分ができることに満足しすぎです」
この日いちばん強い言葉が出たのは、講義の中盤でした。LPが1枚作れるようになった。それは通過点であって、到達点ではない——ここから先は、レベルの違うビジネスが展開される、という話です。


前半:台本 → 撮影 → 編集が、もう回り始めている

恒例の進捗共有から。教育事業の参加者は、この1週間でYouTubeの台本づくり・撮影・編集まで到達し、特典配布用の動画が揃ったと報告しました。注目すべきは、その作り方です。

  • 台本はMarkdownで作る。Bロールの指定、挿入する図の作成指示まで、あわせて出させる
  • 撮影はスマホのインカメ+プロンプターアプリ。カメラの上部にプロンプターを固定すると、台本を読んでいるだけで自然とカメラ目線になる。一発撮りが成立した
  • 編集も投げてみた。フォルダを指定するだけで、AIが素材動画を全部見て、台本に沿う場面を切り出し、つないだ。本人の評価は「割と使い物になる」

ここで講師が反応したのが、最後の一点でした。編集の自動化はずっと試していて、いまひとつ噛み合わなかった領域です。先に台本があると、AIは「その台本に合う画」を探しに行ける。素材を見て要約させるのではなく、完成形の設計図を先に渡す——順番の違いだけで、結果が変わる。

「トークンを使いすぎないか」への答え

参加者から出た心配に対する回答は、前回の宿題の延長線上にありました。アクションログに、使用トークンも記録させてしまう。そうすれば、どの作業にどれだけ消費しているかが、いちいち確認しに行かなくても記録として残ります。不安を我慢で管理せず、計測で管理する。これもS1から一貫している考え方です。


本題:受け皿を、1枚ずつ増やす

ここからがS3の後半、STEP 3「自社の提案を大量に展開できる体制を作る」です。

台本も動画も編集も回り始めると、人がやることは「上がってきた案のどれを選ぶか」と「素材を撮ること」くらいに減っていきます。だとすれば次にやるべきは、流れ込んでくる人の受け皿を増やすこと。SNSからLPへ、LPから問い合わせへ——この動線を体制にします。

原則は明快です。1LP=1訴求。似たようなLPを大量に作っても意味がないので、先に「どう分けるか」を決めます。

誰に × 何を × 期待するアクション(相談会に来てほしいのか、問い合わせてほしいのか、資料をダウンロードしてほしいのか)

材料は新しく発明するものではありません。S2で作った参入戦略とターゲット定義がそのまま効きます。「自社の提案を、1枚のLPで訴求できる単位に分解して、訴求リストを作って」——依頼はこれだけです。

この日、業種ごとの粒度が具体的に示されました。

  • 不動産:ポータルサイトの掲載枠に頼らず、1物件に専用LP。しかもそこで終わらず、周辺環境を押し出した版、間取りを主役にした版、富裕層向け、地元の方向け——同じ物件で切り口別のバリエーションまで作れる。実際、参加者はすでに1物件専用LPを作り、顧客の反応も上々だと報告しました
  • 教育:クラス・コースごとの詳細提案、シラバス、到達目標、講師の考え方。パンフレットの数行では載せきれない中身を1クラス1枚で。さらに、受講生専用ページを非公開+パスワードで配る——以前ならプログラムを書かなければできなかったことが、いま自由にできる
  • 飲食:メニュー1品の深掘り、季節イベントの告知。しかもこれは、AI側から「そろそろ秋メニューの仕込みを」と週次で提案させるところまで行ける

そして買い手のペルソナで分けることもできます。1軒の空き家を、フルリノベーション前提の層が買うのか、DIYしながら住む層が買うのか。プロモーションの仕方がまったく変わるのだから、ページも分ける。先にペルソナを読み込ませておけば、それぞれ用のLPが揃います。

LPの用途そのものが変わる

前回の「LPは広告ではなくステートメント」の続きです。新しいコースの案内、お知らせ、新刊の紹介——これまでメールで送っていたもの、SNSに一行で書いていたものが、そのままLPになる。1行のプロンプトで出せる状態が整うからです。

さらに、LPの上にアプリケーションを載せるのもおすすめされました。本を買ってくれた人がどう遊べるかを、ページの中に組み込んでしまう。ユーザー別(子ども向け/年配の方向け)に切り分けることもできます。


自動化しないのは「制作」。3段階で進める

量産の話をしながら、講師が繰り返し釘を刺したのは「制作は自動化しない」ということでした。流れは3段階です。

  1. 企画書を徹底的に修正する — ざっくりのまま進めない。手を抜いた企画書が放置されていると、あとで何をすべきか分からなくなる
  2. 企画書をベースに制作を依頼する — 「これをベースに。余計なことはしないで」
  3. 納得したら、公開をキックする

そして重要なのが、量産に入る順番です。

「まず自分で10枚くらい、納得できるLPを作り切る。その修正の履歴が構造化データとして溜まって初めて、『うちの会社のLPはだいたいこう作る』というデータになる。自動化ができるのは、そこからです」

最初から自動化はできない。現実のレベルで使い物になるものを、繰り返し作りながら積み上げていく——S1のバイブコーディングとまったく同じ型が、ここでも出てきます。40パターンのLPを作るなら、まず40本の企画書(Markdown)から。


保管と公開を、分けて考える

この日、いちばん時間を使ったのが公開の仕組みでした。参加者から「そもそもLPって、どうやって見るんですか?」という質問が出たところから、話は具体的になります。

まず、作ったHTMLは手元で確認できます。エディタの中では見えませんが、エクスプローラーで(表示を「詳細」に変えるとファイルの種類が分かります)HTMLをダブルクリックすれば、ブラウザで開く。これはまだ公開されていない、自分だけが見ている状態です。

そこから世界に出すために、家(保管庫)を2つ使います。

役割サービスできること
保管・管理GitHubファイルを貯める。バージョン履歴が残るので、変な更新をしても元に戻せる。公開・非公開を選べる(Privateを推奨
公開・配信Cloudflare PagesGitHubのファイルを、公開ページとして配信する。プッシュすると自動で本番へ反映

この分離が効くのは、「保存はするが、まだ公開はしない」が選べるからです。GitHub側に鍵をかけておけば、URLを知っている人にも中身は見えません。逆に、つないでしまえば「プッシュしたら自動で公開」も作れます。

用語 — キック/プッシュ/デプロイ

  • キック:処理を起動する(「始めて」と指令を送る)
  • プッシュ:GitHubへ保存を送る
  • デプロイ:本番に反映して公開する

厳密に覚える必要はありませんが、この3語が使えると指示が短く正確になります。「このHTMLをGitHubにキックして、できそうならデプロイまで進めて」——それで通じます。

なお、これまで練習で使ってきた手動アップロード型のサービス(Netlify)は、公開できる回数・容量に上限があるため、量産に入るならCloudflare Pages側に寄せた方がよい、という整理も示されました。すでに独自ドメインを別サービスに向けている場合は、無理に動かさなくて構いません(サブドメインだけ新しい方に流す、という使い方もできます)。

ドメインについては、講師の立場ははっきりしていました。

「URLに配信サービスの名前が出るのを格好悪いと感じる人もいますが、いまは検索画面から来る人がほとんどいない。みんなSNSのリンクから来ます。だから、ここで格好つける必要は正直あまりない」

ちなみに、1つのリポジトリの中にLPごとのフォルダ(HTML・CSS・画像のセット)を足していけば、同じ設定のまま10枚でも100枚でも横展開できます。設定をやり直す必要があるのは、サブドメインを分けるなど配信のルールを変えるときだけです。


必ず入れるタグ、絶対に入れない情報

量産体制で効いてくるのが、タグの自動付与です。あとから何十枚にも手作業で入れて回るのは、枚数が増えるほど不可能になります。だからルールファイルに書いておく。

  • GA4(Googleアナリティクス)の計測タグ — 言わないと入れてくれません。誰がどのページを見て、どこまでスクロールして、どれくらい滞在したかが数字で残ります
  • メタタグ(title・description・OGP) — 検索やSNS、AI検索での見え方を決める情報
  • 量産LPは noindex — 検索結果に出さない指定です

3つめは、質問から生まれた論点でした。「似たようなページを大量に作ると、スパム扱いされませんか?」——答えは、そもそも検索に載せない

「300個の物件LPが全部検索に出てきたら、見る側もわけが分からなくなる。検索に出すのはメインのページだけにして、個別に作っていくLPは基本的に出さない。それを最初にルールへ書いておく」

そしてもう一方向、出してはいけないものの話です。手元のフォルダには財務データも顧客リストもあります。公開用のフォルダにそれらを混ぜない。最初は必ず自分で確認する。そして——

「AIが個人情報を書き込んでくることが、たまにあります。そういうときは修正するだけでなく、『二度とやらないで』をその場でルールに書かせる。それで次から起きなくなります」

これは講師自身の運用でもあります。この勉強会のレポート(いま読んでいるこの記事です)も自動生成が土台になっていますが、初稿には参加者の実名が入ってきます。それを抜く処理を、都度の修正ではなくルールとして持たせている——という実例が共有されました。


そして、ワンボタンまで行った

後半は各自の実装タイムです。GitHubのアカウント作成、リポジトリの作成(Private)、Cloudflare Pagesとの接続——この手の初期設定は、細かいところで必ず詰まります。だからこそ全員で集まってやる意味がある、という時間でした。

詰まったときの最短手も共有されました。画面をスクリーンショットして、そのまま貼って聞く。Windowsなら Windowsキー+Shift+S。「どのボタンを押せばいいか」を文章で説明するより速く、正確です(逆に、AIにブラウザそのものを操作させるのは、都度スクリーンショットを撮る動作が挟まるため効率が悪くおすすめしない、という注意もありました)。

そして、食品事業の参加者の画面で、この日の到達点が形になります。企画書を1本追加で作り(商品ラインアップ全体ではなく1品だけを売るための訴求です)、内容を確認し、そのまま「企画書をベースに制作してデプロイまでして」と投げる。

「ほら、もうこれでワンボタン」

制作が終わったところがゴールではなく、公開されたところまでが1回の指示で終わる。その場では「どこがワンボタンなんですか」という素朴な反応もありましたが、意味が伝わった瞬間に空気が変わりました。ここまで来れば、30パターンでも、600パターンでも、同じ手数で回せます。

実装メモ:この日出てきた細かい判断

  • 作業フォルダ:オンラインで共有する前提ならクラウドドライブの同期フォルダに、手元だけならユーザーフォルダ直下に myproject を作る(デスクトップは非推奨)。ワーキングフォルダは分けすぎない——あとで切り分けが面倒になる。文体などの細かいルールは、もっと下の階層で指定すれば足りる
  • フォルダ整理は週1回:放っておくとAIが勝手な場所に保存し始める。「この作業はここ」が決まっている状態を保つ
  • モデルの使い分け:最上位モデルは1枚のLPに数百円かける感覚で、常用すると一瞬で枠が尽きる。中位・下位のモデルを常用し、推論レベルも「処理系は低く、アイデア出しは高く」と切り替える
  • ノート系ツールとの比較:チームで使うならNotionのようなツールは非常に便利。ただし1人で回すなら、ファイルとAIエージェントを直接つなぐ方が組み合わせやすい

派生した質問:会計ソフトは入れるべきか

「そろそろ売上管理をしないと」という質問には、「それはS5でやります」と前置きしつつ、要点だけ回答がありました。会計ソフトを使う意味は2つです。

  1. 税理士との共同作業の場になる — 同じ画面で作業できる
  2. 銀行・カード・交通系ICと連携した履歴が、自動で帳簿になる

2つめが本質だ、という指摘が印象的でした。いまや領収書の画像は生成AIで作れてしまいます。だからこそ、「実際に口座から出ていった」という連携データが、信頼の基盤になる。税務の仕組み自体がその方向に寄っている以上、連携していないこと自体が問われうる時代になる——という話です。

なお、法人向けの会計クラウドはAIエージェントから直接操作できる接続(MCP)に対応しており、個人向けサービスは未対応のためCSVを経由する必要がある、という現状も共有されました。


この日の宿題

  • 訴求ごとにLPの企画書(Markdown)を複数作る。最初の10枚は自分で直し切る
  • GitHub(Private)→ Cloudflare Pages の自動デプロイ体制を、各自の環境で完成させる
  • 全ページにGA4タグとメタタグ。量産するLPは noindex
  • 「公開フォルダに機密を混ぜない」をルールファイルへ明記する
  • フォルダ整理を週1回

次回は、S3の最後のSTEP——「AIで“売れるLP”を作る」です。量産できる体制ができた次は、中身の話になります。誰でもそれらしいページを作れる時代に、何が差になるのか。答えは「実体を提示できること」——現場の写真、実在の情報、今日の判断。これまで貯めてきた行動履歴が、そのまま実体の証明になります。

1つスキルを進めるたびに、レベルの違うところまで行く。第8回は、その言葉が実演された回でした。