はじめに

Webサイトにチャットボットを載せる施策は、気になっていても導入のイメージを持ちにくいテーマです。

実際に導入を考えると、先に整理したくなるのは「何でも答えられる高性能なAI」というよりも、

• サービス内容をざっくり案内したい
• 営業時間外でも一次対応したい
• お問い合わせや資料請求への導線を増やしたい
• 既存サイトの見た目を壊さずに後付けしたい

といった、かなり実務寄りの論点です。

今回は、Bloengで試作しているWebサイト埋め込み型チャットボットについて、どんな方針で組んだのかをまとめます。

いわゆる「AIで何でもできます」という話ではなく、既存サイトに無理なく載せられて、問い合わせや相談の導線として機能しやすい受付ウィジェットをどう作っているかという内容です。

技術の細かい話そのものよりも、「なぜその設計にしたのか」「導入時にどんな点が重要なのか」が分かるように書いています。

実際の見え方や操作感を先に確認したい場合は、デモページを先に触るとイメージしやすいです。

デモページを見てみる

まず意識したこと

この手のウィジェットは、どうしても回答精度や使うモデルの話に目が行きがちです。

ただ、実際にサイトへ埋め込むことを考えると、先に気になるのは別のところでした。

• 既存サイトのCSSと干渉しないか
• 導入が面倒にならないか
• APIが未完成でも画面確認を進められるか
• モバイルで邪魔にならないか
• お問い合わせ導線としてちゃんと機能するか

このあたりを先に整理しておかないと、回答の精度だけ上げても実運用にはつながりにくいです。

そのため、今回の試作では次の3点を先に成立させる方針にしました。

1. scriptタグ1本で導入できること
2. 埋め込み先のスタイルを壊さないこと
3. API未接続でもモックで画面確認できること

今回作ったウィジェットについて

見た目としては、サイト右下に常駐する小さな受付ウィジェットです。

まずは閉じた状態だとこのような見た目です。右下にラベル付きのランチャーが表示される形にしています。

ランチャーを押すとパネルが開いて、初期メッセージ、クイックリプライ、自由入力欄が表示されるようにしています。

実際に開くと、初回メッセージと選択肢が見えるので、最初の一言を考えなくても触り始めやすくなります。

派手な演出を入れるというよりは、既存サイトの導線を邪魔しないことを優先しました。

実際のデモページでは、架空のコーポレートサイトに対して後付けで読み込む形にしています。ウィジェット自体はページ本体のコンポーネントに強く依存させず、scriptタグ経由で動く構成にしています。

既存サイトに載せやすい形にした

まず重視したのは、できるだけ少ない手間で試せることです。

実際の埋め込みはかなりシンプルです。

<script
  src="/scripts/ai-uketsuke.js"
  defer
  data-ai-uketsuke
  data-mode="mock"
  data-position="right"
  data-title="AI コンシェルジュ"
  data-launcher-variant="label"
  data-launcher-label="チャットで相談する"
></script>

やっていること自体は単純ですが、この形にしておくと扱いやすいです。

• Astroでも静的HTMLでも導入しやすい
• CMS管理のサイトでも比較的載せやすい
• ReactやVue前提にしなくてよい
• 表示設定をdata属性だけで調整できる

特に、制作の現場では「新しい仕組みを大きく追加したくない」「既存サイト側の改修を最小限にしたい」というケースがよくあります。

そのため、npmパッケージとして組み込む形よりも、まずはscriptタグを1本追加すれば試せることを優先しました。

サイトごとに見せ方を変えやすくした

導入しやすさと同じくらい重要だったのが、載せるサイトに合わせて見せ方を変えやすいことです。

ローダーでは、読み込まれたscriptタグのdata属性を拾って、ウィジェットの設定に変換しています。

この方式にしておくと、埋め込み先ごとにタイトルやクイックリプライを変えやすくなります。

例えば今回の試作では、次のような項目をscriptタグ側から切り替えられるようにしています。

• タイトル
• サブタイトル
• 右下配置か左下配置か
• クイックリプライの文言
• ランチャーの見た目
• モック応答を使うか、本番APIを叩くか

この形にした理由は、同じウィジェットでも載せるサイトによって期待される会話が変わるからです。

コーポレートサイトなら「資料請求」「料金」「導入相談」が先に来ますし、制作会社サイトなら「サービス内容」「見積もり」「問い合わせ」が先に来ます。

毎回コードを調整しなくても、埋め込み時の設定だけである程度寄せられるようにしておいた方が、運用の負担を増やしにくいです。

既存サイトの見た目を壊しにくくした

今回の実装で大きかった判断の1つがこれです。

埋め込み型のUIは、導入先サイトのCSSに引っ張られやすいです。たとえば、全体に button {} や input {} が強く当たっているサイトだと、ちょっとしたチャットパネルでも見た目が崩れます。

今回のウィジェットでは、専門用語でいう custom element と Shadow DOM を使って、スタイルをできるだけ閉じた形で持たせました。

これで少なくとも、

• サイト本体のCSSでボタンが崩れる
• 行間やフォントサイズが意図せず変わる
• 入力欄や見出しの印象がサイト側の設定に引っ張られる

といった事故を減らしやすくなります。

LPでも「完全に独立したスタイル」を打ち出していますが、これは単なる売り文句ではなく、実装上かなり重要なポイントでした。

チャットボットは便利でも、導入した瞬間に既存サイトの印象を壊してしまうと使いづらくなります。なので、まずは賢さよりも安全に置けることを優先しています。

本番前に受け答えを確認できるようにした

これは実装を進めるうえでかなり助かりました。

最初から本番API前提で組むと、UI確認、文言確認、導線確認が全部バックエンド待ちになります。

それを避けるために、今回は mock モードと remote モードを切り替えられるようにしました。

モック側では、入力キーワードに応じて返答を出し分けています。たとえば、

• 料金
• 導入の流れ
• 資料請求
• 問い合わせ

といったよくある相談に対して、デモ用の返答を返す作りです。

実際のやり取り中の画面は次のような形です。入力内容に応じて返答が切り替わるので、UIの確認だけでなく導線の見え方も合わせて確認できます。

これを先に作っておくと、APIがまだ固まっていない段階でも、

• どのクイックリプライが自然か
• ファーストメッセージが硬すぎないか
• ランチャー文言は「相談する」がいいか「質問する」がいいか
• チャットを問い合わせ導線として見せたときに違和感がないか

を先に検証できました。

AI機能の開発では、どうしてもモデルやRAGの話に意識が向きますが、実際にはその前の体験設計で詰まることの方が多いです。ここを先に確認できたのは大きかったです。

同じタブの中では会話が続くようにした

今回の試作では、会話IDとメッセージ履歴をsessionStorageに持たせています。

これは長期保存のためというより、同じタブの中では会話が急に消えないことを優先した結果です。

ページをまたいで長期的に履歴を残す設計もありますが、受付ウィジェットの初期段階では少し重いと感じました。

むしろ今回は、

• 同じタブ内ならリロードしても会話がすぐ消えにくい
• ただし、ブラウザに履歴を長く持ちすぎない
• 実装コストを増やしすぎない

このあたりのバランスを取っています。

小さな判断ですが、こういう部分は使い心地にかなり影響します。せっかく相談しようとしたのに、少し操作しただけで会話が消えるように見えると、それだけで体験が雑に見えてしまいます。

クイックリプライを最初から置いた

自由入力だけでもチャットは成立しますが、実際には最初の一言が出てこない人は多いです。

そこで今回の試作では、最初からクイックリプライを並べています。

これはAIを賢く見せるためというより、相談のきっかけを作るためです。

たとえば、

• サービスを見る
• 料金について聞く
• デモを予約する

のような選択肢が最初にあるだけで、チャットを開いた人の迷いはかなり減ります。

実装してみて感じたのは、チャットは入力UIであると同時に、かなり強いナビゲーションUIでもあるということです。ここは今後もっと詰めたいところです。

待ち時間の不安を減らす表示にした

本番モードでは、内部的には /api/chat からストリーミングでイベントを受け取り、テキストを少しずつ描画する形にしています。

これも、技術的に格好いいからというより、無反応に見える時間を減らしたかったのが理由です。

チャットUIは、返答まで1秒待つだけでも体感が悪くなりやすいです。特に受付用途では、「ちゃんと反応しているか」が分からない時間が一番不安を生みます。

なので、少しずつでも返ってくるようにして、会話のテンポを保つ方向に寄せました。

実装してみて感じたこと

今回の試作で改めて感じたのは、サイト埋め込み型のチャットボットは、できることを増やしすぎない方がよいということです。

少なくとも、企業サイトやサービスサイトの一次窓口として考えるなら、最初にやるべきことはかなり限られています。

• サービス内容の案内
• よくある質問への一次回答
• 問い合わせや資料請求への誘導
• 必要なら人への引き継ぎ

ここが曖昧なまま「何でも聞けます」にすると、回答品質も導線設計も崩れやすいです。

逆に、役割を絞ると、必要な文言もクイックリプライも導入ページも決めやすくなります。これは実装より前の話に見えて、実際はかなりコードに効いてきます。

改善しやすい部分とカスタマイズしやすい部分

もちろん、これで方向性がすべて固まったわけではありません。

今の段階でも、サイトに合わせて調整しやすい部分や、今後さらに改善しやすい部分ははっきりしています。

• 実運用時の参照元設計をどうするか
• 問い合わせ送客までの導線をどこで切るか
• サイト種別ごとの初期テンプレートをどう持つか
• 管理画面なしでどこまで運用できるようにするか
• モバイルでの表示圧をどこまで下げるか

このあたりは、単にチャットUIを完成させるだけでは決まりません。どのサイトで使うのか、どこまで自動案内させたいのか、公開後にどう運用するのかまで含めて調整していく部分です。

まとめ

今回作った埋め込み型チャットボットは、まだ発展途上です。

ただ、実装してみて見えてきたのは、サイト向けのチャットボットで本当に大事なのは、モデルの名前や派手さではなく、既存サイトに無理なく載せられて、訪問者を次の行動に進められることでした。

その意味では、今回先にやって良かったのは次の4つです。

• scriptタグで導入できる形にしたこと
• Shadow DOMで見た目の事故を減らしたこと
• モックモードを先に作ったこと
• 会話の入り口としてクイックリプライを置いたこと

もし「運営中のサイトにチャットボットを載せたいが、何から考えればよいか分からない」という段階なら、いきなり高機能な仕組みを作るより、まずは役割を絞った小さな受付ウィジェットから始める方が現実的です。