AIチャットボットをサイトに置く前に：答えの元になるページを整える

AIチャットボットをサイトに置く前に、FAQ、料金、対応範囲、問い合わせ先を、会社が確認した本文としてそろえます。答えの材料がない状態で会話の入口だけ増やすと、何を根拠に回答してよいかを決められません。

営業や受付で繰り返し聞かれる質問を出し、その答えが今のどのページにあるかを調べてください。ページがあっても、料金の条件や対象外の依頼が抜けていれば、元の本文から直します。導入製品を比べる前にできる作業です。

ここで扱うのは、自社サイトを訪れた人へ案内するチャットです。外部のAI検索で自社が引用されるかとは別の話です。検索で情報を取り出して答えを作る仕組みはRAGの意味とAI検索との関係⁠にまとめています。

チャットボットの型はどう違う？

会話の分岐や回答をあらかじめ設計するシナリオ型と、モデルが回答文を作る生成AI型に分けて考えます。ただし、製品ごとに呼び方と組み合わせ方は異なります。名前だけで、できることを決めないようにします。

Google Cloudの構成の説明は、生成型、決定的なフロー、両者を部分的に組み合わせる方式を示しています。フローでも質問の意図の理解に言語モデルを使うため、AIを使うかどうかだけで二分できません。

RAGは生成AI型と並ぶ別の接客方式というより、外から検索した情報を回答に使う仕組みです。会社の資料を参照する生成AI型にも組み込めます。入れた資料を丸ごと覚えさせる再学習とは区別します。

製造業なら、資料請求先を示すだけの受付と、加工条件を文章で答える受付では必要な設計が違います。質問へ自由に文章を返せることより、どの条件を会社の回答として返してよいかから決めます。

参照するページがあれば答えは正しくなる？

Google Cloudのデータストア説明は、指定したウェブサイトや文書などから質問への答えを探し、内容をまとめ、根拠のリンクを示す機能を説明しています。すべてのチャット製品が同じ仕様という意味ではありません。

同資料はFAQ専用の形式について、質問への一致の確度が高いときは、登録された回答を変更せず返すと説明しています。通常の文書としてFAQを取り込む方式では、回答を書き換える可能性も示しています。

同じFAQを渡す場合でも、登録の方式によって返し方が違うという具体例です。導入先には、固定の答えを返すのか、原文を要約するのか、根拠リンクを出せるかを聞いてください。

資料の参照機能があっても、誤答がなくなると判断しません。検索で必要な箇所を取得できたか、回答で条件が落ちていないかを分けて確かめます。料金表に条件がないなら、回答の正誤を比べる基準自体がありません。

FAQと料金には何を書いておく？

よく聞かれる問いと、会社として答えられる範囲を対応させます。新しいFAQページを大量に作る必要はありません。製品やサービスの既存ページにある説明へ、欠けた条件を補う作業から始めます。

たとえば、図面がない段階で加工の相談ができるかという質問です。相談の受付ができることと、見積もりを確定できることを別に書きます。図面の代わりに必要な情報、担当者の確認が要る条件も示してください。

料金が個別見積もりなら、固定の価格を作りません。何によって変わり、見積もりの前に何が必要かを本文へ書きます。納期も同様に、決まった日数を答えられないなら、人が確認する事項として示します。

私たちは暦の自社メディアで、FAQを構造化データにだけ入れ、画面に出していない失敗がありました。その後、一覧のFAQを画面にも出す形へ直しました（出典は自社の作業記録）⁠。これはチャットボットの導入成果ではありませんが、持っている答えを読める場所へ出す必要があった経験です。

本文の整え方は質問に答える文章の書き方⁠で扱います。チャットを使わない訪問者も、同じ条件をサイトで確かめられる状態にしてください。

古いページと新しいページはどう整理する？

料金や受付条件が変わったら、同じ説明があるページを洗い出します。古いページを残したまま新しい案内を足すだけでは、どれを現行として答えてよいか曖昧になります。必要な既存ページを直し、重複は統合します。

参照先を一覧にして、公開用か社内用か、現行か廃止済みかを記します。公開ページを更新した後、チャット側の取得や索引へ反映する操作が必要かも確認します。ウェブを直した瞬間に、すべての製品の回答が更新されるとは仮定しません。

更新担当は、本文の修正、参照側への反映、回答の再確認までを一つの仕事として持ちます。修正前と同じ質問を聞き、新しい条件で答えるか、古いURLへ案内しないかを見ます。

回答が間違うたびに別ページを追加するより、誤った根拠の箇所を特定します。元ページに答えがないのか、古い資料が検索されたのか、正しい原文を回答で広げたのかで、直す場所が違います。

公開前にどんな質問で試す？

担当者が正解を用意できる質問を使います。正常に答えられる問いだけでなく、対象外の依頼、条件が足りない問い、料金や納期を確定させようとする問いも含めます。製品の説明画面だけで確認を終えないでください。

たとえば、相談だけ可能と書いてあるサービスへ、図面なしで見積もり額を確定してほしいと聞きます。回答が受付条件を守るか、確認が必要と案内するかを確かめます。期待する回答は技術や営業の担当者が先に作ります。

質問、期待する答え、実際の回答、参照元、確認日を残します。正解した回数だけでなく、根拠のない断定や対象外の受付を別に記録してください。営業上の約束に見える誤答が残るなら、その回答範囲を公開する前に見直します。

個人情報や社内FAQはどう扱う？

問い合わせる人が、連絡先や案件の詳細を自由に入力することを想定して準備します。チャットで受け取る必要のない個人情報や図面は入力しないよう、入力前に案内してください。入力欄の近くから、正式な問い合わせ方法へ進めるようにします。

導入するサービスでは、会話の保存、学習利用、閲覧権限、外部連携、削除の扱いを公式文書と契約で確認します。特定のサービスが全情報を安全に扱うと、ここで一律には判断しません。

社内FAQにある原価、顧客別の条件、担当者の連絡先などは、公開向けの参照資料へ混ぜません。社内の回答を整える作業と、社外へ見せる回答を用意する作業を分けます。非公開情報を資料へ入れたまま、答えに出さないと指示するだけの運用にしないことです。

外部のAIへ資料を渡す判断と承認は生成AIの社内ガイドライン⁠へ進めます。公開向けと社内向けで、参照する資料とアクセスできる人が一致しているかを確認します。

人へ引き継ぐ入口はどこに置く？

根拠がない質問、個別見積もり、苦情、技術者の確認が要る相談は、人が受ける窓口へ案内します。回答の最後だけでなく、会話の途中でも問い合わせへ移れる状態にします。

営業時間外なら、返答できる時間や受付方法を実際の運用に合わせて示してください。有人対応と表示しながら、担当者が受け取れない状態にしないようにします。チャットからフォームへ移るなら、同じ説明を何度も入力させずに済むかも試します。

会話履歴を引き継ぐ機能がある場合は、何を誰へ渡すかを確認します。履歴が連携されないなら、必要な情報だけを改めて送る手順を案内します。入力した情報がすべて担当者へ届くように見せないことです。

問い合わせ先そのものの設計はBtoBサイトの問い合わせ導線⁠で確認できます。自社サイトのLLMO対策⁠と同じく、会社として答えられる条件を先に整え、その本文を使って回答の範囲を決めてください。導入の判断には、答えられる件数だけでなく、人が訂正して受け取る仕事も含めます。

仕様・出典の確認日：2026年10月23日⁠。