AIチャットボット導入前にナレッジを整理する方法

AIチャットボットの回答は、モデルだけで決まりません。どの資料を読めるか、正本が一つに決まっているか、公開してよい情報と社内向け情報が分かれているかで、回答の根拠と安全性が変わります。導入前には資料を全部つなぐのではなく、対象質問・回答の根拠・更新責任を揃えてから接続します。

まず決めるのは、Botに答えさせる質問の範囲

「問い合わせを減らす」だけではナレッジの範囲を決められません。注文状況、返品、請求、操作方法、障害などから、最初に扱う問い合わせを2〜3種類選びます。選ぶ条件は、問い合わせ頻度があり、正解を示す現行資料があり、誤回答時に人へ引き継げることです。

表は横にスクロールできます

質問の種類	参照する正本の例	Botに答えさせる条件	人へ渡す条件
操作方法	現行ヘルプ記事	対象製品・画面・版が一致	画面が異なる、手順が見つからない
返品・契約	承認済み規約と個別注文記録	公開済み一般条件だけで回答できる	期限、例外、個別契約の判断が必要
障害	現行ステータス・障害手順	対象サービスと発生状況が一致	顧客固有データや復旧判断が必要
社内手続き	社内規程	社員だけが参照できる範囲に限定	個人の権限・人事判断を含む

初回導入では、正答を一意にできない質問をBotの対象から外します。FAQが足りないからといって、AIに不足部分を補わせてはいけません。「回答しない」「担当へ引き継ぐ」も設計した回答です。

架空の記入例：資料台帳で正本と更新責任を決める

まず資料名だけでなく、使い道・読者・正本・責任者・最終確認日を記録します。ファイル名に「最新版」と付いているだけでは正本の根拠になりません。内容を管理する部門に確認し、どのページ・規程が現行かを決めます。

表は横にスクロールできます

資料	公開範囲	正本の場所	内容責任者	確認日	Bot利用
返品条件	公開	Help Center「返品」	CS運用責任者	2026-10-10	一般条件のみ
障害対応手順	社内限定	承認済み運用Wiki	SRE当番	2026-10-10	Agent支援のみ
旧キャンペーン資料	公開終了	保管庫	マーケティング	—	対象外

同じ質問に答える資料が複数ある場合、Botへ投入する前に優先順位を明示します。古い価格表を削除できないなら「参照対象外」として区分し、現行資料が上書きされる状態を放置しないでください。更新日が不明、責任者が不在、規約とFAQが矛盾する資料は、保留リストに回します。

一枚の大きな資料を、読者の質問単位に分ける

長いマニュアルをそのまま登録すると、別の条件が同じ文書内に混ざったり、検索された抜粋だけでは前提が抜けたりします。分割の目安はページ数ではなく、「質問に答えるのに必要な条件が一まとまりか」です。

たとえば「請求を変更したい」という質問には、契約プラン、変更時期、請求先の権限が関わります。これを「請求の変更」とだけ書くより、変更できる人、反映タイミング、できない例、問い合わせ先を一つの説明単位にすると、回答の抜けを検査できます。一方、同じ操作を別々の短い記事へ切り刻み、共通の前提を失うのも避けます。

各情報単位には、対象読者、対象製品・プラン、適用条件、更新日、問い合わせ先を添えます。手順を版ごとに分ける場合は、どの画面・版が対象かをタイトルや冒頭に明記し、旧版の手順が現行として検索されないよう管理します。

公開用と社内用は「置き場所」ではなく権限で分ける

顧客へ表示してよい回答と、担当者だけが見る判断材料は別の情報です。社内向けの記事をPublic Help Centerへ出さない、公開記事のURLを知っていれば誰でも見られると決めつけない、という二段階の確認が必要です。ナレッジ製品によって公開記事、内部記事、PDF、Webサイトなど、入力できる形式と利用可能なチャネルは異なります。

IntercomではKnowledgeのsource種別やFin・Copilot・Help Centerでの利用先を管理する仕組みが案内されています。ただし、製品の画面・契約条件・提供機能は更新されるため、実導入時には自社ワークスペースで利用可能なsourceとアクセス範囲を確認してください。社内向け資料をBotへ接続しても、その回答が顧客向け画面に出ないことを、権限の異なるテストアカウントで確かめます。

FAQ候補づくりとBot用ナレッジ整備を混ぜない

過去ログから頻出質問を見つける作業と、正しい回答を承認済み資料から作る作業は別です。問い合わせログのクラスタは「よく聞かれる候補」を示すもので、回答の正しさや公開承認を示しません。ログ分析は個人情報や注文情報を除いた最小データで行い、抽出候補は担当部門が正本と照合してから記事化します。

候補行には、質問の言い換え、該当する正本、回答可能 / 要確認 / 対象外、責任者、承認日を残すと、問い合わせ件数だけでFAQを量産するのを防げます。既存FAQに追記すべき質問か、新しい記事にするべきかも確認します。似た質問を個別記事にすると、更新時に一方だけ古くなるからです。

接続前の試験セットを作る

本番の全資料をつなぐ前に、対象質問を使った小さな評価セットを作ります。各質問に「正しい回答の根拠」「答えない条件」「公開範囲」を付け、次を最低限含めます。

• 正本に明確な回答がある質問

• 正本に回答がない質問

• 古い資料と現行資料が衝突する質問

• 公開用と社内用で答えが変わる質問

• 個別契約や本人確認が必要な質問

• 質問の条件が足りず、聞き返す必要がある質問

出力は「結論」「根拠source」「適用条件」「不明点」「人へ渡す条件」に分けて確認します。誤答が出たときは、モデルを変えるだけでなく、正本、検索対象、文書分割、権限、回答ルールのどこで失敗したかを記録します。修正後は同じ質問を再実行し、別の質問で回帰がないかも確かめます。

運用開始後に更新を止めない

公開・接続後は、誤回答だけでなく「答えが見つからない」「古い情報が参照された」「社内資料が不要な場所へ出た」も見ます。各sourceの同期方法や反映時間は製品によって異なります。Intercomの公式案内では、ネイティブ記事・snippetと外部Web sourceで更新の扱いが異なる例が示されています。現在の同期条件は導入する機能の公式設定で確認してください。

更新担当者が変わったとき、規約が改定されたとき、ページを削除したときに、Botの参照対象も変わる手順を決めます。変更前後の版、承認者、反映日を記録し、重要な条件が変わったら評価セットを再実行します。更新作業を毎回の「AI調整」にせず、通常のコンテンツ管理へ組み込むのが長続きする形です。

導入判断

次のすべてがそろう小さな範囲から始めます。

1. 対象問い合わせを2〜3種類に絞れている。

2. 各質問の正本と内容責任者が決まっている。

3. 公開用と社内用の権限を実環境で確認できる。

4. 回答できないときの引き継ぎ先が決まっている。

5. 正答・不足・矛盾・権限の評価質問を用意できる。

一つでも欠ける場合は、資料を追加投入するより先に欠けた条件を直します。まず既存FAQの一領域を棚卸しし、正本・範囲・責任者・確認日を埋めてください。そこが整ってから、限定的なチャットボットや担当者支援へ接続するのが安全です。

ナレッジの公開・更新フローを決める

整備した資料を継続して使うには、誰がどの状態を変えられるかを決めておきます。たとえば次の状態を台帳へ持たせます。

表は横にスクロールできます

状態	意味	次にすること
Draft	内容責任者が作成中	根拠と対象読者を埋める
Review	関連部門が事実を確認中	条件や例外の衝突を解消
Approved	公開・接続範囲が承認済み	対象sourceとBot利用先を設定
Expired	確認期限を過ぎた、または条件変更	Botから一時的に外し再確認
Archived	現行運用で使わない	正本へのリンクを残して参照停止

ステータスを付けるだけで自動的に正本性が生まれるわけではありません。特に契約・価格・安全・障害対応など、間違いの影響が大きい情報は、担当部署が承認し、変更がBotへ反映されたことまで確認します。期限切れの資料を自動削除するのではなく、回答に使わない状態へできる仕組みを選んでください。

よくある誤回答を、資料と設定のどちらから直すか

誤回答の原因を分類すると、場当たり的にプロンプトを足すのを減らせます。

• 正しい記事がない：内容責任者が正本を作る。

• 正本はあるが古い：記事の更新と同期状態を確認する。

• 似た記事が複数ある：優先する正本と対象範囲を決める。

• 社内文書が顧客回答に混じる：権限と利用チャネルを見直す。

• 回答が広すぎる：対象プラン・地域・時期などの適用条件を明記する。

• AIが不明点を補う：回答条件と「不明なら引き継ぐ」ルールをテストする。

変更後は誤回答を出した質問だけでなく、同じsourceを参照する質問も再実行します。ナレッジの一文を変えると、複数回答へ影響するためです。修正前の回答・根拠・変更内容・再試験結果を短いログで残します。