「ウェビナーで3daysの教材販売をやりたいんですが、どう思いますか？」
クライアントからそのメッセージが来たのは、ある教育サービスの案件がスタートした直後だった。専門資格の受験対策に特化した高額教材を販売するための仕組み作り。それがこのプロジェクトの出発点だった。
最初に頭に浮かんだのはZoomだった。ウェビナーといえばZoom。業界標準の選択肢だし、クライアントも知っている。「まずZoomで設計しましょう」と返そうとして、少し考えた。
「毎週3日間、ライブでやり続けるのか？」
その問いが引っかかったまま離れなかった。
Zoomウェビナーの現実問題
高額教材の販売には「温め」が必要だ。Day1で現状把握、Day2で解決策の提示、Day3でクロージング。この3日間の流れで見込み客の購買意欲を育てるのが定石だ。
しかしこれをZoomでライブ開催するとなると、毎週この3日間をクライアントが拘束されることになる。集客がうまくいった週も、3人しか集まらなかった週も、同じ熱量で話し続けなければならない。
教材販売で月に10〜20本の契約を目指すなら、ウェビナーへの集客を毎週続けて、毎週ライブで話して、毎週疲弊する。これでは教材を売るための仕組みが、逆にボトルネックになってしまう。
「ライブをやめる方法はないか」と調べ始めた。
Simuliveという考え方に辿り着くまで
「疑似ライブ」「オートウェビナー」「Simulive」といった言葉を調べると、海外では一般的な概念だとわかった。事前に録画した動画を、ライブ配信のように届けるシステムだ。
参加者がURLを開くとカウントダウンが始まり、時刻になると動画が自動再生される。巻き戻しはできない。スクロールできない。今この瞬間に流れていく映像を見るしかない。それがライブウェビナーと同じ緊張感を生む。
既存のSimuliveサービスを調べると、海外製が多く月額が高い。日本語対応が弱い。何より、エルメ（LINE公式アカウントの拡張ツール）との連携を考えると自由度が足りなかった。
「自分で作った方が早い」と判断した。
Vercel（無料ホスティング）とYouTube限定公開を組み合わせれば、ランニングコストはほぼゼロになる。仕様も完全にコントロールできる。Zoomで設計するより、むしろこちらの方がシンプルで確実だった。
技術的に一番苦労した「動的な開始タイミング」問題
設計の中で最も詰まったのが、「視聴者がいつURLを開いても、次の配信回が自動で始まる」という動作の実装だった。
ウェビナーは時刻が来たら始まるものだ。だがSimuliveの場合、参加者は告知を見て好きなタイミングでURLを叩く。アクセスした瞬間に「次の回がいつ始まるか」を計算して、カウントダウンを表示しなければならない。
1日3回（12時・18時・21時）の配信スロットを設定した。視聴者がアクセスした時刻から、この3つのスロットのうち「最も近い未来のスロット」を自動選択する。シンプルに聞こえるが、実装してみると想定外の複雑さがあった。
日付をまたいだ場合の処理。残り時間がマイナスにならないようにする処理。テスト時に任意の日時を上書きできる仕組み（?start=2026-04-30T18:00というパラメータで日時を指定できるようにした）。これらを一つひとつ潰していくのに時間がかかった。
開始10分以内にアクセスした場合は動画を先頭から再生する。10分以上経過してからアクセスした場合は「遅刻」として別のURLに飛ばす。動画を最後まで見終わったら「視聴完了」として別のURLに飛ばす。この3パターンの分岐も、それぞれ正確に動作させる必要があった。
URLにはランダムなトークン（?t=mk7r3xwqのような推測不可能な文字列）を付与した。直接URLを共有されても、正規の登録ルートを経由していない視聴者は入れない設計にした。
エルメ連携で起きた設計ミス
システムの技術的な部分が固まってから、次はエルメ側の設計に入った。タグ15個・テンプレート13個・フォーム3個・計測URL6個・サロン予約3個・タグアクション9個という規模の構築だ。
最初にぶつかった失敗が、リマインドをエルメの「シナリオ機能」で組もうとしたことだった。
Day1の登録者に、Day1の視聴URLを送る。視聴完了したらDay2への案内を送る。遅刻した場合は次の回への案内を送る。これをシナリオの条件分岐で管理しようとした。
しかしDay1〜Day3それぞれに「視聴完了」「遅刻」「未視聴」の状態が発生し、それぞれに対応するメッセージがある。組み合わせが急速に増え、タグの絡み合いが複雑になり、どこで何が発動しているか追いにくくなっていった。
「これは設計ミスだ」と気づくのに少し時間がかかった。
正解はエルメの「サロン予約機能のリマインド設定」を使うことだった。サロン予約の確認メッセージ・リマインドメッセージに{視聴URL}のプレースホルダーを埋め込む。あとはサロン予約が入ったタイミングで自動的にリマインドが飛ぶ。
シナリオの複雑な分岐を全部捨てて、サロン予約機能の既存の仕組みに乗っかる。この切り替えで、全体の設計が一気にシンプルになった。「機能を正しく使い直す」ことで解決した典型的なケースだった。
「これは使える」と確信した瞬間
テスト用のURLを自分のスマホで開いた。
カウントダウンが表示された。「18:00まで あと 0時間 3分 42秒」。その数字がリアルタイムで減っていく。時刻になった瞬間、動画が自動再生を始めた。
巻き戻しができない。早送りもできない。ただ今この瞬間に流れる動画を、最初から見るしかない。
ライブウェビナーを見ているときと、何も変わらない感覚だった。むしろ、ライブでは絶対に出ない「安定感」がある。喋りのムラがない。毎回同じクオリティで届く。機材トラブルもない。
1回録画すれば、あとはエルメがリマインドを送り続ける。クライアントは当日何もしなくていい。Day1〜Day3を通じて見込み客を温め、最終日に個別相談への案内が自動で届く。
「仕組みで売る」という形が、ここで一つ完成した。
システムの汎用性と今後
このSimuliveシステムは、あるクライアント専用ではない。config.jsの動画ID・トークン・リダイレクトURL・配信スロットを書き換え、Vercelに再デプロイするだけで、別のクライアントに流用できる。
実際に別のクライアント向けにも使用予定で、汎用テンプレートとして展開する計画が進んでいる。
高額商品のウェビナー販売に興味があるが「毎週ライブは無理」と感じている方に、このシステムは刺さるはずだ。録画×ライブ感×エルメ追客の3つを組み合わせることで、完全自動のセールスファネルが実現できる。
まとめ
Simuliveウェビナーシステムを作るまでの流れを振り返ると、3つの転換点があった。
第一に「Zoomをやめる」という判断。ライブの消耗を切り捨て、仕組みを作ることを選んだ。第二に「動的な開始タイミング」の実装。ユーザーがいつ開いても次の回が自動で始まる仕組みを作り込んだ。第三に「シナリオをやめてサロン予約に切り替える」という設計の修正。シンプルな機能を正しく使う、という判断だった。
graciautoでは、このSimuliveシステムの構築を初期設定・エルメ連携込みで提供しています。「ウェビナーで売りたいが、毎回ライブはしたくない」という方はご相談ください。