企業Webサイトの生成AI・実務実装ガイド
第4回
自社AIボットが「使えない・嘘をつく」本当の理由。
RAG成功の鍵は"CMSの情報品質"
「自社の製品マニュアルやFAQを学習させたAIチャットボットを導入した。これで問い合わせ対応が劇的に楽になるはずだ」
――そう期待して公開したものの、数週間後には「AIが平気で嘘の仕様を答える」「的外れな回答ばかり」という理由で、誰も使わなくなってしまった。
現在、非常に多くの企業でこのような「AIチャットボットの形骸化」が起きています。
この時、多くの担当者は「導入したAIツールの性能が悪かった」と考えがちですが、それは大きな誤解です。
AIチャットボットが嘘をつく本当の原因は、 AIに読み込ませている「元データ（WebサイトのコンテンツやPDF）」が整理されていないからです。
連載第4回となる今回は、自社データを活用するAIの仕組み「RAG」の真実と、 システムベンダー任せでは解決しない、WEB担当者がCMSを使って行うべき「情報品質の改善」の実務について解説します。
RAG（検索拡張生成）の仕組みと「ゴミ」データ
自社専用のAIチャットボットのほとんどは、「RAG（Retrieval-Augmented Generation = 検索拡張生成）」という技術で作られています。 仕組みはシンプルで、「まず自社のデータベースから関連する情報を検索し、その『カンペ』を読みながらAIが回答を生成する」というものです。
ここで重要なのは、「渡されたカンペの中身が間違っていたり、乱雑で読解不能だったりしたら、どれだけ優秀なAIでも間違える」ということです。
ITの世界には「Garbage In, Garbage Out（ゴミを入れたらゴミが出てくる）」という格言があります。 古いPDFを何百ファイルも丸投げしたり、構造化されていないWebページを読み込ませることは、「ゴミのようなカンペ」をAIに渡しているのと同じなのです。
AIが混乱する「NGなデータ」と、読みやすい「構造化データ」
では、AIにとって「読み取りにくいデータ」と「読み取りやすいデータ」とは具体的にどのようなものでしょうか。
⚠️ AIが混乱するNGなデータ（人間は読めてもAIには読めない）
文字が画像として埋め込まれたカタログPDFは、AIがテキストとして抽出できません。また、「本機能は〜」「このボタンは〜」など、ページ全体を読まないと何について書かれているか分からない文章は、AIがその一文だけを切り取った際に文脈を見失います。
サーバー内に「マニュアル2023」「マニュアル2026」が両方残っていると、AIはどちらが最新か判断できず古い仕様を答えます。また、見出しタグ（h2など）がなく文字の大きさだけで装飾された長文は、情報の「まとまり」をAIが理解できません。
✅ AIが正確に読み取れる構造化データ
- セマンティックなHTML：見出し（h1〜h6）やリスト（ul/ol）が正しくマークアップされている
- Q&A形式での分割：「質問」と「回答」が明確なセットとして区切られている
- メタデータの付与：「対象製品名」「最終更新日」などのタグ情報が設定されている
RAG成功の鍵を握る「CMSの情報基盤化」3つのポイント
チャットボットを賢くするためには、データソースとなるCMS（WordPressやMovable Type）のコンテンツ管理を見直すことが圧倒的に効果的です。
フリーエリアにベタ打ちされた長文はAIにとって読解難易度が高くなります。FAQを登録する際、「質問」「回答」「対象製品」という入力項目（フィールド）をシステム的に分割することで、AIは意味を正確に解析できるようになります。
📌 Before/After：乱雑なFAQと構造化されたFAQ
【Before（NG）】
「A製品とB製品の仕様について。エラーコード01が出た場合は電源を切ってください。エラー02はサポートへ。」とフリーエリアにベタ書きされている状態。AIはどの製品のどのエラーか混同しやすい。
【After（OK）】
カスタムフィールドで区切り、
[対象製品]：A製品、B製品
[エラーコード]：01
[解決策]：電源を切る
と明確に分割する。これによりAIは「A製品のエラー01の解決策」として正確に情報を抽出できる。
AIの嘘を防ぐ最強の対策は、「古い情報を削除する」ことです。サポート終了した製品情報などは非公開にするか、AIのクローラーが読み込まない特定ディレクトリへ隔離します。「CMS上のデータ＝常に最新の正解のみ」という状態を保ちます。
FAQPageなどの構造化データ（JSON-LD）をCMS側で自動出力するよう設定します。これはSEOだけでなく、RAGのデータ収集時にも情報構造を正確にAIへ伝える手助けになります。
「嘘をつかせない」プロンプト設計と効果測定
CMS側のデータ品質を高めることと両輪で重要なのが、AI側での「防御線の構築」と「導入後の効果測定」です。
防御線：「わかりません」と正直に言わせるプロンプト設計
どれだけデータを綺麗にしても、ユーザーが想定外の質問をすればAIはカンペにないことを推測で語ろうとします（ハルシネーション）。これを防ぐため、AI（LLM）へのシステムプロンプト（指示書）には強力な制約を設けます。
【プロンプト例】
「あなたは自社サービスのサポートAIです。提供されたデータベース（カンペ）の情報のみを元に回答してください。もし該当する情報が見つからない場合は、絶対に推測で答えず、『申し訳ありませんが情報が見つかりません。担当者へお問い合わせください』と回答し、有人サポートのリンクを提示してください。」
導入後の効果測定（KPIの設定）
チャットボットは「導入して終わり」ではありません。上層部へ効果を説明し、改善を回すための具体的なKPI（指標）を設定します。
- 正答率のスコアリング： 想定されるQ&Aリストを50件用意し、定期的にテスト質問を投げて「正解」「不正解」「エスカレーション（わからないと答えたか）」を採点する。
- 有人対応へのエスカレーション率： ボットで解決せず、有人サポートへ引き継がれた割合（この率を徐々に下げるのが目的）。
- 解決率（フィードバック）： ユーザーへの「この回答は役に立ちましたか？」アンケートでの高評価率。
導入前にWEB担当者がやるべき準備とセキュリティ確認
「AIベンダーにツールを導入してもらえば勝手に賢くなる」という幻想は捨ててください。導入前の泥臭い準備がプロジェクトの成否を分けます。
重複ページや古いPDFを洗い出し徹底的に除外します。
社内データをAIベンダーのツールに渡す際、「自社のデータがAIモデルの学習に利用されない（オプトアウトされている）こと」を契約や設定で必ず確認します。また、従業員の役職によって見せて良い情報が異なる場合は、アクセス権限の分離設計も必要です。
散在する情報を、最新の「マスターデータ」として自社サイトのCMSへ一元化し、HTMLとして公開します。
最初から全情報を読ませるとAIは高確率で混乱します。「主力製品のFAQ50件のみ」など、データが整っている狭い範囲でテストし、精度を確認してから範囲を広げます。
公開後の運用：情報鮮度を保つ体制づくり
チャットボット公開後、最大の課題となるのが「誰が情報を最新に保つのか」という運用体制（ガバナンス）です。 CMS内の情報が古くなれば、翌日からAIは平気で古い情報を答え始めます。
- 新製品のリリースや仕様変更があった際、「マニュアルの改訂と同時にCMSのデータを更新する」ことを必須の業務フローに組み込む。
- 現場部門（サポートや営業）と、Web担当者（CMS更新者）の役割分担を明確にする。
この「組織づくり・体制づくり」こそが、AI活用における最後のハードルとなります。（※この組織づくりについては、次回の連載第5回で詳しく解説します）
まとめ
AIチャットボット（RAG）の導入は、純粋なシステム開発ではありません。 自社の情報資産を、機械が読み取れる形に整理し直すプロジェクトです。
- AIが嘘をつく原因の多くは、元データが汚い（古い・構造化されていない）ことにある
- CMSのカスタムフィールドや構造化データを使い、情報を意味ごとに分割管理する
- 「わからない場合は正直に担当者へ繋ぐ」プロンプト設計で防御線を張る
- 学習利用のオプトアウトなど、情報漏洩を防ぐセキュリティ確認を怠らない
- いきなり全データを読ませず、スモールスタートで正答率（KPI）を検証する
どれだけ高額なAIツールを導入しても、土台となるWebサイトのコンテンツ品質が低ければ成果は出ません。
チャットボット導入を検討する前に、まずは自社サイトの「情報構造の整理」から着手してください。
AI時代の安全なWebサイト保守・運用体制でお悩みの方へ
「担当者が退職し、サイトの中身がブラックボックス化している」
「AIを活用して内製化を進めたいが、セキュリティ面が不安」
「WordPressやMovable Typeのアップデート・保守を任せたい」
「ステージング環境やGit管理フローを構築したい」
株式会社ヒューコネクトでは、エンタープライズ向けのWebサイト構築から、技術的負債を解消する保守・運用サポートまで、エンジニアチームが伴走支援します。
現状の課題整理や、既存の制作会社との役割分担に関するご相談も可能です。貴社の運用フローに合わせた安全なシステム基盤の構築をご支援します。
