AIデモエージェントは、バイブコーディングで自作すべきか？

AIデモエージェントは、バイブコーディングで自作できるのでしょうか？ 週末のうちに動くものなら作れます。しかし、実際の製品で、実際の見込み顧客を相手に、毎日動かし続けるのはまったく別のプロジェクトです。そして、パイプラインを左右するのはその2つ目のプロジェクトです。

その2つ目のプロジェクトに何が含まれ、それぞれがどれほど難しいのかをまとめました。

検討事項	必要なこと	難易度
ライブの製品を操作する	ログイン、認証コード、ボット対策、そしてUIが変わっても壊れないフロー	非常に難しい
レイテンシ	聞く、考える、話す、クリックするを約1秒以内でこなすこと	非常に難しい
音声技術	自然な声、話者交代、割り込み、なまり、雑音への対応	難しい
サンドボックス	セッションごとにリセットされ、製品と常に同期するリアルなデモデータ	難しい
プロンプト設計とガードレール	メッセージから外れず、価格や機能、セキュリティについて決して作り話をしないこと	難しい
評価（Evals）	会話を採点し、プロンプトやモデルを変えるたびに品質の低下を検知すること	難しい
CRMとパイプラインへの引き継ぎ	リード獲得、データエンリッチメント、HubSpotやSalesforceとの同期、フォローアップ	中程度
保守	製品のリリースやモデルの変更のたびに、上記すべてを確認し直すこと	終わりがない

Karumiを検討しているチームから、「うちのチームの誰かがバイブコーディングで作れるのでは」という声をよく聞きます。そう考えるのも当然です。コーディングエージェントは今や非常に優秀です。LLMをヘッドレスブラウザにつなぎ、音声APIを加えて自社アプリに向ければ、日曜の夜には製品を話しながらクリックして回る何かができあがります。

私たちは、その後どうなるかも見てきました。自作したチームは、このシステムの構築と運用がどれほど難しく、コストがかかるかを知り、私たちのもとに戻ってきました。本記事では、プロトタイプが動いた後に彼らが直面した課題を紹介します。

バイブコーディングで作ったデモエージェントは、どこまでできるのか？

中核となる仕組みは、今では本当に簡単です。LLMはページを読み、何をクリックするかを判断し、見えているものを説明できます。音声APIを使えば話せるようになります。コーディングエージェントなら、それらすべての土台を数時間で組み上げてくれます。

社内向けのデモならそれで十分です。しかし見込み顧客に対しては十分ではありません。プロトタイプは、うまく動いてほしいと願っている相手の前で、一度動けばよいだけだからです。

	週末のプロトタイプ	見込み顧客の前に出すエージェント
相手	応援してくれる自社のチーム	最初の不具合で離脱する、懐疑的な見込み顧客
製品の状態	ノートPC上の、ログイン済みのセッションひとつ	それぞれ独自のログイン、データ、タイミングを持つ数千のセッション
会話	想定どおりの質問	価格、競合、セキュリティ、「〇〇はできますか？」
失敗したとき	笑い話	失注と、悪い第一印象
稼働期間	デモ1回	毎日、すべてのリリースを通じて
担当者	土曜日に作った人	専任者が恒常的に必要

この2つの列の差こそが、本当のプロジェクトです。そしてデモは、本番で失敗が許されない場面のひとつです。壊れるときは、最も好印象を与えたかった見込み顧客の目の前で壊れるからです。

運用するには、何を使いこなす必要があるのか？

本番で動くデモエージェントは、ひとつの技術ではありません。少なくとも4つの技術から成り、それぞれが独立した専門分野です。

• 音声技術。 音声認識、音声合成、話者交代、割り込み、なまり、背景の雑音。声を自然に聞こえさせ、相手が話し終えたタイミングを判断すること自体が、ひとつの専門分野です。
• サンドボックス。 リアルなデータを備えた製品のコピーで、セッションごとにリセットされ、リリースする内容と常に同期し、実際の顧客の情報を決して表に出さないものです。
• プロンプト設計。 エージェントが初めて出会う数千の会話のなかでも、メッセージから外れず、自社製品の話題にとどまり、ガードレールの内側で動き続けるための指示です。
• 評価（Evals）。 会話を採点して品質の低下を検知する仕組みです。これがあれば、プロンプトやモデルの変更で良くなったのか悪くなったのかがわかります。

さらに、この4つすべてにまたがるのがレイテンシです。音声の会話では、1秒ほどを超える間があるだけで壊れているように感じられます。エージェントはその時間内に、聞いて、考えて、話して、ライブの製品をクリックしなければなりません。これを短縮するには、すべての段階をストリーミングし、品質だけでなく速度でもモデルを選び、見込み顧客が尋ねる前にページを先読みしておく必要があります。極めて重要であり、正しく仕上げるのが最も難しい部分のひとつです。

なぜライブの製品を操作するのが難しいのか？

私たち自身のエンジニアリング時間の大半は、チャットではなくここに費やされています。録画ではなく実際の製品を見せるには、次のすべてを解決する必要があります。

• 立ちはだかるログイン。 SSO、メールアドレスを先に入力させる画面、マジックリンク、認証コード、デモの途中で切れるセッション。失敗が成功のように見えることもよくあります。エージェントはログインできたと思っていても、実はログインページにとどまっているのです。
• ボット対策。 Cloudflare、Akamaiなどのツールは、自動化されたブラウザをブロックするために存在します。自社アプリに対してスクリプトを頻繁に実行すると、デモ用アカウントがロックされることもあります。
• 安全なデモデータ。 見込み顧客に実際の顧客データを見せたり、共有アカウントを壊させたりするわけにはいきません。本物らしく見え、きれいにリセットされ、本番環境には一切触れないサンドボックスが必要です。
• 変わり続けるUI。 リリースのたびにボタンの位置が変わり、ページの名前が変わります。ハードコードされたクリックは気づかないうちに壊れるため、見込み顧客より先に壊れたフローを検知する仕組みが必要です。
• 速度。 ページごとに8秒待たされるデモは、壊れているように感じられます。先読み、キャッシュ、ページの読み込みに合わせたナレーションのタイミング調整は、それぞれが独立した作業です。
• 割り込み。 実際の見込み顧客は「待って、戻って」と口を挟みます。エージェントは止まって答え、中断したところから再開しなければなりません。

どれもプロトタイプの動画には映りません。しかし、すべて見込み顧客の前では表面化します。

会話を信頼できるものにするには、何が必要なのか？

デモエージェントは、あなたのブランドを代表して話します。見込み顧客の前で製品について作り話をするエージェントは、エージェントがいないよりも大きな損害を与えます。信頼性を保つには、継続的な取り組みが必要です。

• 根拠のある回答。 ドキュメント、導入事例、ポジショニングに基づいて答え、価格やロードマップについて推測する代わりに、自社のチームへ引き継ぐ必要があります。
• ガードレール。 競合、値引き、法務やセキュリティに関する質問、そしてジェイルブレイクの試みには、すべて意図的な対応が必要です。
• 自然な音声。 低いレイテンシ、割り込みや沈黙への対応、そして画面の内容と同期したナレーションです。
• 多言語対応。 複数の市場で販売しているなら、すべての台本、フロー、回答がそれぞれの言語で機能しなければなりません。
• レビュー。 毎週、誰かが会話を読み、採点し、弱い回答を修正する必要があります。そうしなければ品質は少しずつ落ち、誰もそれに気づきません。
• セキュリティに関する質問。 セキュリティチームは、会話の記録がどこに送られ、どのモデルプロバイダーがそれを見るのかを尋ねてきます。尋ねられる前に答えを用意しておく必要があります。

エージェントがあれば、それで完成ではないのか？

いいえ。デモエージェントの価値は、パイプラインにどう貢献するかにあります。自作のボットは、たいてい会話のところで止まってしまいます。セールスとマーケティングには、その周りのすべてが必要です。

• キャンペーンごとの入り口。LinkedIn、イベント、Webサイト、アウトバウンドのそれぞれに専用のリンク、あいさつ、開始フローを用意し、どのチャネルが効果的かを把握できるようにします。
• リード獲得とデータエンリッチメント。訪問者が誰で、どの企業に属し、ICPに合致するかどうかを把握します。
• 自社のツールへの引き継ぎ。有望なセッションは要約付きでHubSpotやSalesforceに登録され、適切な営業担当者に通知が届き、フォローアップも自動で送られます。
• インサイト。見込み顧客が最もよく尋ねる質問、離脱するポイント、よく挙がる懸念点を把握します。
• ノーコードでの編集。マーケティングやセールスエンジニアが、チケットを起票することなく台本やフローを変更できるようにします。

これらはどれも、それ自体がひとつの小さな製品です。社内で作れば、デモボットは独自のロードマップを持つ社内プラットフォームになってしまいます。

自作には、実際どれほどのコストがかかるのか？

バイブコーディングのおかげで、最初のバージョンはほぼ無料で作れます。しかし、その後の100のバージョンは無料にはなりません。コストがかかるのはそこです。

• 製品のアップデートは、すべてデモのアップデートです。 リリースのたびに、ボタンの位置が変わったり、ページ名が変わったり、フローが変わったりします。リリースのたびに誰かがジャーニーを確認し直し、サンドボックスを更新し、台本を書き直し、評価を再実行しなければなりません。
• 誰かが責任を持たなければなりません。 作った人が本業の製品開発に戻ったり退職したりすると、ボットは静かに壊れていきます。誰も完全には理解していない生成コードは、引き継ぐのが困難です。
• 土台となる技術は動き続けます。 LLM、音声、ブラウザ自動化のベンダーは、数か月ごとにモデル、価格、APIを変更します。変更のたびにテストをやり直す必要があり、書き直しになることも少なくありません。
• 自社のロードマップと競合します。 デモボットに費やすエンジニアリングの1週間は、実際に販売している製品に費やせなかった1週間です。
• 価値が出るまでの時間。 社内で動くものができても、見込み顧客に安心して見せられるようになるまでには、通常あと数か月かかります。その間、プロジェクトの根拠だったはずのパイプラインは待たされることになります。

つまり公正な比較とは、サブスクリプションと週末のコーディングを比べることではありません。サブスクリプションと、無期限に続く兼任のエンジニアリングチーム、さらに構築中に失う商談とを比べることなのです。

自作が理にかなうのは、どんなときか？

次の3つがすべて当てはまるなら、自作は正しい選択です。

1. AIデモエージェントが、別の何かを売るためのチャネルではなく、自社の売り物の中核である。
2. 1スプリントだけでなく、専任のチームを恒常的に配置できる。
3. 見込み顧客に見せられるまで、数か月待っても問題ない。

そうでなければ、チームがバイブコーディングで作るべき最も有益なものは、自分たちが求めるもののプロトタイプです。その要望リストを、ログイン、サンドボックス、ガードレール、音声、分析、CRMへの引き継ぎにすでに対応しているプラットフォームに渡し、エンジニアリングの時間は自社の製品に使いましょう。

それを実現するのがKarumiです。エージェントは製品を探索して学習し、見込み顧客と話しながらライブで製品を操作し、すべてのセッションをCRMに送ります。ほとんどのチームは2週間で稼働を開始し、保守は私たちが担います。

よくある質問

まずプロトタイプから始めて、後から乗り換えることはできませんか？

できます。プロトタイプは、自分たちが何を求めているかを見極める良い方法です。ただし、乗り換えのための予算は確保しておきましょう。コストの大半はプロトタイプの後の作業にかかり、壊れたデモを見た見込み顧客が、もう一度見に来ることはないからです。

製品が毎週変わる場合はどうなりますか？

それこそが、ハードコードされたフローに反対する最も強い理由です。Karumiは製品の変化に合わせて学習し直すため、ページ名が変わったりボタンが移動したりしても、デモが止まることはありません。

自作しないと、コントロールを失いませんか？

いいえ。台本を書き、フローを選び、ガードレールを設定するのは貴社のチームです。任せるのはインフラです。ブラウザ、ログイン、音声、サンドボックス、そして各種連携です。

両者を公平に比較するには、どうすればよいですか？

見込み顧客が重視するコアなフローをひとつ選び、1週間、両方で試してください。自社のプロトタイプとKarumiのエージェントに同じ質問をぶつけ、それぞれが不具合なくデモを最後までやり遂げた回数を数えましょう。