AIチャットボット

AI開発発注の失敗図鑑｜チャットボット導入で使われない原因

2026年5月25日15分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

GXO COLUMN

AI開発

AIチャットボットを導入したものの、数か月後にはほとんど使われていない。問い合わせは結局、電話やメールに戻っている。こうした事例は珍しくない。チャットボット自体の出来が悪いとは限らず、多くは「使われ続ける仕組み」を発注前に設計していないことが原因である。

本記事では、AIチャットボットが定着しない原因を発注者の視点で整理し、発注前に確認すべき項目と開発会社への質問を示す。社内向け（従業員の問い合わせ対応）でも、社外向け（顧客対応）でも、定着の論点は共通している。重要なのは、導入時の完成度よりも、使われ続ける仕組みを発注前から考えておくことである。チャットボットは、作って置くだけでは定着しない。

結論：チャットボットは回答範囲、導線、改善ログで定着する

AIチャットボットを使われ続ける状態にするには、発注前に「どの質問に答えるか」「どこから使わせるか」「答えられなかった質問をどう直すか」を決めておく必要がある。GXOが導入前に確認するのは、FAQの元データ、利用導線、有人対応への引き継ぎ、KPI、更新担当である。

実際の問い合わせ上位から回答範囲を決める
問い合わせが起きる画面や手続きに入口を置く
利用件数、解決率、引き継ぎ率を見て改善する

この設計がないと、導入直後は試されても、数か月で電話やメールに戻りやすい。

MANUFACTURING DX

Excel限界から受発注システムへ、同規模の概算は？

中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。

製造業DXの概算を見る

使われないチャットボットに共通する状態

導入後に使われなくなるチャットボットには、いくつか共通の状態がある。

よくある質問に答えられず、「分かりません」が続く
どこから使えるのか分かりにくく、利用者が存在に気づかない
回答内容が古いまま更新されず、信頼されなくなる
解決しないときに、人へつなぐ導線がない
何件解決し、どれだけ役立ったのかを測っていない
運用する担当者がおらず、導入後に放置される

これらは技術というより運用設計の問題である。発注前にここを詰めておくと、定着率は大きく変わる。

なぜチャットボットは使われなくなるのか

回答できる範囲が利用者の期待とずれている

利用者は「自分の疑問に答えてくれる」ことを期待する。ところが、用意したFAQの範囲が狭いと、最初の数回で「使えない」と判断され、二度と使われなくなる。最初の体験が定着を左右する。

導線がなく、存在に気づかれない

トップページの目立たない場所にしか入口がないと、利用者はチャットボットの存在に気づかない。問い合わせが発生する場面（料金ページ、手続きページなど）に導線がないと使われない。

回答を更新する運用がない

商品や制度が変われば、回答も変える必要がある。更新する担当と仕組みがないと、回答は古くなり、誤った案内をするようになる。古い回答は、不信感につながる。

解決しないときの引き継ぎがない

チャットボットだけですべてを解決するのは難しい。解決しないときに、人へスムーズにつなぐ導線（有人チャット、問い合わせフォーム、電話）がないと、利用者は途中で離脱する。

効果を測っていない

利用件数、解決率、人への引き継ぎ率などを測っていないと、どこを改善すべきか分からない。改善されないチャットボットは、やがて使われなくなる。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

「使われない」と「使われ続ける」の違い

横にスクロールして確認できます

観点	使われないチャットボット	使われ続けるチャットボット
回答範囲	用意したFAQが少ない	よくある質問を優先して網羅
導線	トップにしか入口がない	問い合わせが起きる場面に配置
回答更新	更新する人がいない	更新の担当と頻度が決まっている
有人対応	解決しないと行き止まり	人へつなぐ導線がある
効果測定	測っていない	利用・解決・引き継ぎを測る
運用体制	導入後は放置	定期的に見直す担当がいる

定着は、導入時の完成度より、運用の仕組みで決まる。

社内向けと社外向けで変わる論点

チャットボットは、社内の従業員向けか、社外の顧客向けかで、定着のために重視すべき点が変わる。発注前に、どちらを対象にするのかを明確にしておきたい。

社内向け：利用者が限られるため、まず「よく聞かれる質問」に確実に答えられることが重要になる。就業規則、経費精算、システムの使い方など、回答の元になる情報が社内に散らばっていることが多く、それをどう集めるかが鍵になる。利用が広がらない場合は、入口の周知と、答えられる範囲の見直しが効く。
社外向け：不特定多数が利用するため、誤った回答が信頼に直結する。回答の正確さと、解決しないときに人へつなぐ導線が特に重要になる。問い合わせが発生する場面（料金、申し込み、解約など）に入口を置くと使われやすい。

どちらの場合も、最初から完璧を目指すより、利用の多い質問から着実に答えられるようにし、ログを見ながら範囲を広げる進め方が現実的である。

定着につながる初期の進め方

導入直後の使われ方が、その後の定着を大きく左右する。最初の数週間で「使えない」と判断されると、利用は戻りにくい。立ち上げ期には、次のような進め方が有効である。

実際の問い合わせデータから、上位の質問に優先して答えられるようにする
答えられなかった質問をログから抽出し、短いサイクルで回答を追加する
解決しなかったときの人への引き継ぎを、最初から用意しておく
利用件数と解決率を見て、入口の場所や回答範囲を調整する

「導入して様子を見る」のではなく、最初の改善サイクルを発注前から計画しておくと、定着の確率が上がる。

発注前に確認すべき項目

チャットボットに答えさせる「よくある質問」を実際の問い合わせから洗い出したか
利用者がどの画面・場面からアクセスするか（導線）を決めたか
回答を更新する担当者と頻度を決められるか確認したか
解決しないときに人へつなぐ導線（有人対応・フォーム・電話）を決めたか
効果を測る指標（利用件数、解決率、引き継ぎ率など）を決めたか
導入後に運用・改善を担う担当者を確保できるか確認したか
社内向けか社外向けかを明確にし、想定利用者を定義したか

開発会社に確認する質問

横にスクロールして確認できます

質問	確認したいこと
回答できる範囲はどう決めますか	FAQ設計に踏み込むか
利用者の導線はどう設計しますか	配置場所まで提案するか
回答の更新は誰が、どう行いますか	運用の仕組みがあるか
解決しないときの人への引き継ぎはどう設計しますか	有人対応への接続
効果はどの指標で測りますか	改善のための測定設計
導入後の改善はどう進めますか	定着までの伴走

「高精度なAIなので何でも答えられる」という説明だけでは、定着の設計としては不十分である。

GXOに相談する前に整理するとよい情報

現在の問い合わせの内容と件数（多い質問の上位が分かると有用）
問い合わせが発生している場面（どのページ、どの手続きか）
解決しないときに、今は誰がどう対応しているか
回答の元になる情報（FAQ、マニュアル、規程など）の有無
社内向けか社外向けか、想定する利用者

実際の問い合わせデータがあると、「まず何に答えさせれば使われるか」を具体的に設計できる。

参考にした外部観点

AIチャットボットは、回答品質、権限、ログ、利用者体験をまとめて設計する必要がある。NIST AI Risk Management FrameworkはAIリスク管理の観点を提供し、OWASP Top 10 for Large Language Model ApplicationsはLLMアプリケーションで注意すべきリスクを整理している。

導入前には、問い合わせ上位10件、答えられなかった質問の30日分ログ、3ヶ月の改善期間、1年分の更新担当を決めておくと、導入後の放置を避けやすい。

GXOの見解

システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。

GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。

GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。

実務判断のポイント

この記事は、経営者、情シス、業務責任者、発注担当向けです。要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。

GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。AI開発発注の失敗図鑑｜チャットボット導入で使われない原因に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。

放置した場合と整備した場合の違い

横にスクロールして確認できます

観点	放置した場合	整備した場合
業務影響	属人的な判断が増え、対応の優先順位がぶれやすい	影響範囲、期限、責任者を決めて進められる
投資判断	ツール導入や外注費だけが先行し、効果測定が曖昧になる	売上、工数削減、リスク低減の指標にひも付けられる
現場運用	例外処理や承認フローが残り、定着しにくい	権限、ログ、教育、改善サイクルまで設計できる
経営報告	問題が発生してから説明資料を作ることになる	月次で状況、課題、次の打ち手を説明できる

導入・改善前のチェックリスト

対象業務、対象部門、対象データを明文化しているか
現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
例外処理、承認、差し戻し、監査証跡まで確認しているか
社内で判断できる範囲と外部支援が必要な範囲を分けているか
初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
経営判断に必要な資料を1枚で説明できる状態にしているか
次の90日で検証する範囲と、やらない範囲を明確にしているか

GXOの見解

システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。

GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。

自社だけで整理が難しい場合、GXOは業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる。最初から大規模な発注を前提にせず、現状整理や診断から必要な範囲を確認できます。

実行までの進め方

現在の業務、データ、ツール、担当者を棚卸しする
売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
初期対応、90日以内の改善、半年以上の投資を分ける
必要な社内体制、外部支援、予算、セキュリティ確認を整理する
小さく検証し、効果測定後に本番化や横展開を判断する

よくある質問

Q1. 高性能な生成AIを使えば、FAQを用意しなくても答えられますか

生成AIは流暢に答えるが、社内の正確な情報を渡さなければ、誤った内容を自信ありげに返すことがある。よくある質問とその正解を用意することは、社外向けでも社内向けでも有効である。

Q2. 小規模でもチャットボットは効果がありますか

問い合わせが特定の質問に集中している場合、小さく始めても効果は出やすい。まず上位の質問に答えさせ、解決しないものは人へつなぐ設計が現実的である。

Q3. 導入後にすぐ使われなくなったら、どうすればよいですか

利用ログから「答えられなかった質問」を抽出し、回答範囲と導線を見直すのが基本である。測定していないと改善できないため、効果測定は導入時から設計しておきたい。

Q4. 導入してすぐに効果を求めてもよいですか

立ち上げ期は、答えられる範囲を広げ、入口や導線を調整する期間と考えたほうがよい。最初から高い解決率を求めるより、よく聞かれる質問に確実に答えられる状態を作り、ログを見ながら範囲を広げるほうが、結果的に定着は早い。効果は、利用件数と解決率の推移で見ると判断しやすい。逆に、導入直後の数字だけで「使えない」と結論づけると、改善の余地を残したまま運用をやめてしまうことになる。最初の数か月は改善期間として計画に織り込んでおきたい。