この記事で分かること

• 生成AIチャットボットが「作ったのに使われない」状態に陥る主な原因
• 既存文書をそのまま流用しても成果が出にくい理由
• ナレッジを「読む文書」から「答える文書」に変える考え方
• 社内向けBotの失敗事例と社外向けBotの改善実践の違い
• 現場に定着する生成AI活用に必要な運用設計の3原則

2026年6月16日、「生成AIは、なぜ「使いこなせない」のか？～ナレッジを育て、現場に根付かせる運用設計～」というセミナーが開催されました。本記事では、その講演内容のポイントをご紹介します。

登壇者

生成AIチャットボットが定着しない原因は、ツールではなくナレッジ設計と運用設計にある

まず、生成AIチャットボットが現場に定着しない理由は、モデル性能やUIの問題だけではなく、回答のもとになるナレッジの作り方と、それを育て続ける運用設計にある点を解説します。

生成AIの導入が進む一方で、PoCや一部部署での成功にとどまり、全社展開まで進まない企業は少なくありません。そのときに起きがちなのは、「現場が使わない」「回答精度が低い」「システムが悪い」といった表面的な評価です。しかし、実際に見直すべきポイントは、AIの土台になるナレッジが使われる形で整備されているかどうか、そして改善を回し続ける運用体制があるかどうかです。

RAGや基盤モデルの性能が向上しても、参照する情報が曖昧で、構造が不揃いで、更新されないままであれば、回答品質は安定しません。逆に、利用者が知りたいことに沿ってナレッジを設計し、継続的に育てる仕組みを整えれば、同じ生成AIでも回答の質は大きく変わります。生成AI×チャットボットの成否を分けるのは、ツール選定そのものより、ナレッジ育成とAI運用設計の成熟度だといえます。

特に重要なのは、利用者がそのまま次の行動に移れる形で答えを返せるかどうかです。「担当者にお問い合わせください」で終わる回答では、自己解決にはつながりません。現場に定着する生成AIとは、質問に対して具体的で、理解しやすく、行動につながる答えを返せる仕組みです。その実現には、言葉の粒度、情報の網羅性、構造の明確さをそろえたナレッジ設計が欠かせません。

さらに、導入失敗の背景には、更新責任が曖昧なままリリースしてしまう問題もあります。誰がナレッジを追加・修正し、どのように評価し、どのタイミングで改善するのかが決まっていなければ、最初は使えていたチャットボットも徐々に陳腐化し、使われなくなっていきます。生成AI 定着の鍵は、導入時点から運用まで含めて設計することにあります。

“読む文書”をそのまま使っても、生成AIは現場で役立つ回答を返せない

次に、既存の規定書やPDFをそのまま投入しても、利用者が欲しい形の回答にはなりにくい理由を整理します。読むために作られた文書と、質問に答えるためのナレッジは別物であり、ユーザーの質問起点で情報を再構成する必要があります。

規定書やマニュアル、PDF資料は、人が順に読んで理解することを前提に作られています。一方で、生成AIチャットボットに求められるのは、質問に対して必要な部分だけを抽出し、文脈に合わせて分かりやすく返すことです。この前提が違うため、既存文書をそのまま投入すると、回答が長い、要点がぼやける、知りたいことに直接答えない、といった問題が起こりやすくなります。

例えば、利用者が申請方法を知りたいときに、「申請フローに従いご対応ください」と返されても、実務上は動けません。必要なのは、「この手続きであれば、このフォームから申請できます」といった、回答として成立する言葉です。ナレッジを「読む文書」から「答える文書」へ変えるとは、単なる書き換えではなく、利用者の質問と行動を起点に情報を再設計することを意味します。

もう一つ見落としやすいのが、AIに細かく条件分岐を与えすぎることです。精度を上げようとして「この質問にはこう答える」「この条件ならこの表現を使う」と細かく固定すると、AIは文脈理解や言い換え対応といった強みを発揮しにくくなります。生成AI 導入失敗の典型例は、AIを柔軟な回答エンジンではなく、複雑な分岐ルールの実行装置にしてしまうことです。

そのため、RAG 精度向上を目指すうえでも、情報を大量に入れること自体が目的になってはいけません。重要なのは、必要な情報が引き出せる状態に整っていることです。1つの質問に対して1つの明確な回答を基本単位にし、ユーザーが使う言葉で整理し、答えられない質問には無理に答えず適切に案内する。この設計思想が、現場で役立つ回答につながります。

社内向けBotの失敗と社外向けBotの改善実践が示した、使われる生成AIの条件

そして、社内向けBotの失敗事例と社外向けBotの改善実践を対比しながら、使われる生成AIに必要な条件を具体化します。質問の棚卸し、ユーザーの言葉への変換、更新権限の整理といった差分が、運用成果を分けるポイントになります。

社内向けBotの事例では、Amazon BedrockとBedrock Chatを活用して問い合わせ削減とナレッジ共有の効率化を目指しました。しかし、ナレッジ整備が開発スコープ外となり、依頼部門側で既存のPDF規定をそのままアップロードしたことが、使われない状態につながりました。読むための文書をそのまま参照させた結果、回答は長く分かりにくくなり、精度が上がらない印象が先に広がってしまったのです。さらに、インテント設計に条件を書き込みすぎたことで、AIの文脈理解やあいまいな質問への補完力も生かしにくくなりました。

一方、社外向けBotの事例では、Amazon Lexとlex-web-uiを用い、開発チームとマーケティング部門が共同でナレッジ整備を進めました。ここで大きかったのは、ナレッジ整備をシステム開発と同等の重要タスクとして扱ったことです。まず「何を聞かれるか」を洗い出し、初期リリースで答える範囲を絞り込み、共通フォーマットでFAQを整備しました。社内用語ではなく利用者の言い回しで書き直し、1問1答を基本単位にし、さらに大カテゴリ・中カテゴリ・個別FAQの3階層で構造化することで、引き出しやすいナレッジへと変えていきました。

改善実践では、答えられない質問に対して無理に答えない設計も組み込まれています。これは回答の取りこぼしを認めるというより、誤案内を避けながら利用者を適切な次の行動へ導く考え方です。また、Sales Cloud由来のデータはExcel、自社情報やグループ情報はMarkdownというように、データ種別ごとに管理方法を分けた点も有効でした。メタデータや構造を意識して整備することで、検索性と保守性の両立がしやすくなります。

加えて、テストと改善の進め方にも差がありました。想定シナリオに基づくテストを実施し、不具合を記録し、原因を分類して修正し、再テストを繰り返す流れを取ることで、使われる精度へと近づけていきます。AI運用設計は、リリースして終わりではありません。質問ログや利用状況を見ながら、ナレッジを追加し、表現を直し、利用部門と開発側の双方が更新できる体制を回していくことが、現場で使われ続ける条件になります。

生成AIを現場に根付かせるには、回答設計・AIの余白・運用責任者の3点を先に決める

まとめとして、生成AI活用を定着させるための原則として、ナレッジを回答として設計すること、AIに余白を残すこと、ナレッジオーナーと更新体制を事前に定めることの3点を整理します。

第1に、ナレッジは「情報」ではなく「回答」として設計することが必要です。利用者の質問に対して、そのまま返して役立つ言葉になっているかを基準に整備しなければ、チャットボットはあっても使われません。第2に、AIに余白を残すことです。細かな条件分岐で縛りすぎるのではなく、最低限の制約にとどめることで、生成AIの文脈理解や表現の柔軟性を生かしやすくなります。

第3に、ナレッジオーナーと更新体制を先に決めることです。誰が育てるか決まっていないナレッジは、時間とともに劣化します。更新責任者、更新頻度、更新のきっかけ、評価方法まで含めて定めることで、生成AI活用を単発で終わらせず、現場に根付かせることができます。

上位層の判断が進まない場合も、最初から大規模導入を目指す必要はありません。実際の運用に関わるメンバーとともに、どの業務から自動化や支援を始めると効果が見えやすいかを整理し、小さく始めて改善を積み上げる進め方が有効です。成功パターンを社内に蓄積し、再現できる状態をつくることこそが、生成AIを点ではなく面で広げるための現実的な道筋です。

よくある質問

Q1. 生成AI活用の方針はあるのに、上位層から具体的なGoが出ない場合はどうすればよいですか？

A. 最初から全社規模で進めようとせず、スモールスタートで効果を見せる進め方が有効です。経営層だけでなく、実際の運用に関わる担当者も交えて、どの業務なら自動化や支援の効果を出しやすいかを具体化すると、判断しやすくなります。

Q2. 既存の規定書やマニュアルをそのまま生成AIに入れてはいけないのでしょうか？

A. 原本として保管・参照する価値はありますが、そのまま回答用ナレッジとして使うと、長く分かりにくい返答になりやすくなります。利用者の質問起点で、回答として成立する言葉に再構成して使うほうが実務には適しています。

Q3. FAQのように整理するなら、あえてAIを使う意味はあるのでしょうか？

A. 意味はあります。データ量が増えるほど、人手で必要な情報を探す負荷は高まります。生成AIは、表現ゆれやあいまいな質問を含めて意図をくみ取り、適切な回答候補へつなぎやすい点に価値があります。

Q4. ナレッジ整備にはどの程度の工数がかかりますか？

A. 社外向けBotの初回整備では、会社・グループ概要の整備に半月から1カ月程度、Sales Cloudデータの抽出・整備に約1カ月、合計で約2カ月という感覚値が示されています。対象は初回リリース時点で5つのカンパニー分のサービス・ソリューションを検索できる範囲であり、実際の工数はデータ量や整備粒度によって変わります。

Q5. 機密情報や個人情報を含む場合、どのように扱うべきですか

A. 何を個人情報・機密情報とみなすかの判断を先にそろえたうえで、現状は1件ずつ内容を確認し、公開してはいけない情報を除外する運用が必要です。過去の導入企業名などは注意して外し、AIが自動で安全に仕分けてくれる前提では進めないほうが現実的です。