この記事の要点
- AIチャットボット導入は「既製SaaS」「ノーコード自作」「受託開発」の3択。分岐条件は(1)社内文書を参照させるか (2)基幹システムと連携するか (3)回答責任を社外に対して負うか、の3つです
- 費用の目安はSaaS型で初期0〜50万円＋月額3〜30万円、社内文書を読ませるRAG型の開発で200〜1,000万円規模。これに加えてLLMの従量課金と文書整備の人的工数が乗ります
- 社外のAIサービスに社内文書を入れるなら、学習利用の有無・データの保存先・参照権限の制御の3点を契約前に必ず確認します
- 最初から全社展開せず、問い合わせが集中している1業務に絞ったPoCから始めるのが失敗しにくい順序です
問い合わせ対応の負荷を下げたい。AIチャットボットを入れれば減りそうだ。ここまでは多くの会社が同じところに立っています。詰まるのはこの先です。月数万円のSaaSで足りるのか、社内文書を読ませる仕組みを作らないと使い物にならないのか。その判断材料がないまま比較サイトを回っても、ツール名が増えるだけで決められません。
この記事では、AIチャットボット導入を発注する側の視点で、自社がどの選択肢に該当するかを判断する条件、費用の内訳と見積もりの見方、社内文書を外部サービスに入れる際の確認項目を整理します。
目次
AIチャットボット導入は「既製SaaS」「自作」「開発」のどれを選ぶべき？
導入形態は既製SaaS・ノーコード自作・受託開発の3択です。分かれ目は3つ。(1)自社の社内文書を参照させるか (2)基幹システムや業務システムと連携するか (3)回答の正確性について社外に責任を負うか。3つとも該当しないならSaaSで足ります。1つでも深く該当するなら開発を検討する段階です。
SaaSで足りるか、開発が必要かを分ける3つの条件
YES/NOで答えられる3つの質問で切り分けます。YESが0個ならSaaS、1個ならSaaS＋アドオンやオプション機能の検討、2個以上なら開発またはハイブリッドが現実的な線です。ツールの機能比較より先に、この3問を社内で確定させてください。
条件1：社内文書を横断参照させる必要があるか
想定される質問が数十件で、答えがFAQとして書き出せる範囲なら、SaaSのシナリオ型やFAQ型で十分です。一方、就業規則・製品マニュアル・過去の議事録・技術仕様書など、数百から数千ファイルを横断して答えさせたいなら話が変わります。この場合は社内文書を検索して回答を生成するRAG（検索拡張生成）の構築が必要で、文書の前処理・検索精度のチューニングが工程として発生します。SaaSにも文書アップロード機能はありますが、対応形式・容量上限・更新頻度で制約が出やすい部分です。
条件2：基幹システムや業務システムと連携するか
「営業時間は？」「経費精算の締め日は？」のような一般的な案内だけならSaaSの領域です。「私の注文はいま出荷されましたか」「顧客IDに紐づく契約プランを教えて」のように、質問者ごとに違う答えを返すには、在庫・受注・顧客管理システムとのAPI連携が要ります。連携先が増えるほど見積もりは上がり、既存システムがオンプレミスで古い場合は接続方式の検討だけで工数が乗ります。
条件3：回答の正確性に社外への責任を負うか
社内向けで「あくまで参考情報、最終判断は担当者に確認」という運用ならSaaSで始められます。社外の顧客に契約内容・料金・製品仕様を回答させるなら、その回答は企業の公式見解とみなされます。回答根拠の提示、ログの保全、答えられない質問を有人に渡すエスカレーション設計が必須になり、要件は一気に開発寄りに傾きます。
3つの選択肢を費用・期間・柔軟性・運用負荷で比較すると
結論から言えば、判断は「どこまで自社固有の情報を扱うか」でほぼ決まります。汎用的な案内で済むほどSaaSが有利で、自社固有の文書やデータに踏み込むほど開発の必要性が高まります。下の表は前提条件つきの目安です。
| 既製SaaS | ノーコード自作 | 受託開発 | |
|---|---|---|---|
| 初期費用 | 0〜50万円 | ほぼ0 | 200〜1,000万円 |
| 月額 | 3〜30万円 | 数千〜3万円＋API従量 | 保守費として月額発生 |
| 導入期間 | 2週間〜2ヶ月 | 数日〜1ヶ月 | 2〜6ヶ月 |
| カスタマイズ性 | 製品の範囲内 | ツールの範囲内 | 要件次第で自由 |
| 社内文書への対応 | 製品差が大きい | 小規模なら可 | 大量・多形式に対応可 |
| システム連携 | 用意された連携のみ | ほぼ不可 | 設計次第 |
| 運用に必要なスキル | 業務知識＋管理画面操作 | 作った人への依存が強い | 発注側は文書更新の体制 |
金額はユーザー数・質問件数・文書量で変わります。同じ「月額10万円」でも、100人利用と1,000人利用では条件がまったく違うので、比較するときは前提を揃えてください。
もう一つ現実的な進め方が、まずSaaSで始めて限界が見えたら開発に移すハイブリッドです。SaaSの数ヶ月で「どの質問が多いか」「どこまで自動化できたか」の実データが手に入ります。そのログは、開発を発注するときの要件定義そのものになります。いきなり数百万円の投資判断をするより、判断材料を買う意味でも合理的な順序でしょう。
ノーコード・ChatGPT APIでの自作はどこまでできる？
小規模な社内FAQボットなら、非エンジニアでも数日で作れます。GPTsやノーコードのAIアプリ構築ツールを使えば、PDFを数個読ませて部署内で試す程度は現実的です。限界が来るのは、権限制御・ログ管理・大量文書での精度改善・システム連携が必要になった時点。ここから先は開発の領域です。
自作が向くのは、部署単位の実験、10〜50件程度のFAQ、外部に公開しない前提の検証です。逆に向かないのは全社展開、人事評価や取引条件などの機密文書、そして顧客対応。人によって見せてよい文書が違う状況を、ノーコードツールの標準機能で作り込むのは無理があります。
自作でよく起きる問題が2つあります。1つは属人化です。作った担当者が異動すると、プロンプトの意図もデータ更新の手順も誰も分からなくなります。もう1つはAPIの従量課金です。無料枠や少額の想定で始めたものが、利用者が増え、長い文書を毎回読み込む設計のまま走ると、月額が想定の数倍になることがあります。試作段階から、質問1件あたりのコストを概算しておくと安全です。
AIチャットボットの導入費用はいくら？相場と内訳
費用の目安は、SaaS型で初期0〜50万円＋月額3〜30万円、社内文書を参照するRAG型の開発で200〜1,000万円規模です。ただし、見積書に載りにくいLLMの従量課金とFAQ・文書整備の人的工数が、総額の2〜3割を占めることがあります。金額を比べるときは、利用ユーザー数・想定質問件数・対象文書量の3つを揃えて確認してください。
SaaS型チャットボットの料金相場と課金体系
SaaS型は初期0〜50万円、月額3〜30万円が一般的なレンジです。課金軸は大きく3つ。ユーザー数課金、メッセージや質問件数による従量課金、機能別のプラン制です。自社の使い方がどの軸で膨らむのかを先に見極めないと、安いプランを選んだのに総額が高くなります。
- ユーザー数課金：社内利用で全社員に配るとID数が一気に増える
- 質問件数課金：社外公開で問い合わせが季節変動する場合、繁忙期に超過しやすい
- 機能別プラン：有人チャット連携やAPI連携が上位プラン限定のことが多い
初期費用に何が含まれるかも製品差が大きい部分です。アカウント発行だけの場合と、FAQの登録代行・初期シナリオ設計まで含む場合では、同じ「初期30万円」でも中身が違います。契約前に確認したいのは、超過分の単価、契約期間の縛りと解約条件、最低契約期間、そしてデータのエクスポート可否。特に最後は、後で開発に移行するときに効いてきます。
社内文書を読ませるRAG型を開発する場合の費用構成
RAG型の開発費用を決めるのは、文書の「量」ではなくデータ整備・権限制御・システム連携の3要素です。同じ1,000ファイルでも、整ったWord文書と画像スキャンのPDFでは前処理工数が数倍変わります。工程別の内訳を見て、どこが厚いのかを確認するのが見積もりの読み方です。
- 要件定義：対象業務・対象文書・評価基準の確定
- データ前処理／文書整備：形式変換、重複排除、最新版の特定
- RAG基盤構築：検索インデックス、生成部分の実装
- UI・チャネル実装：Teams、Slack、社内ポータル、Webサイト
- 権限制御：誰がどの文書を参照できるかの制御と既存ID基盤との連携
- 評価・精度チューニング：評価用質問セットでの検証と改善
- 保守：モデル更新への追随、障害対応、文書更新の仕組み
規模感の目安は3段階で捉えると分かりやすくなります。1業務・限定文書での小規模PoCが50〜200万円、部門展開が200〜500万円、全社展開＋基幹システム連携で500〜1,000万円超。クラウドベンダーが提供するLLMサービスを土台にするか、検索基盤から作り込むかでも差が出ます。開発工数と費用の関係は、規模別の実績値が公開されており、見積もりの妥当性を考える際の一般的な材料になります※1。
見積書を受け取ったら、権限制御と評価・チューニングの工数が計上されているかを見てください。この2つが極端に薄い見積もりは、「動くものは作るが、実運用で使えるかは検証しない」という内容になっている可能性があります。
見積書に載らないランニングコストと工数
継続的に発生するのは、LLMのトークン従量課金、社内文書の整備・更新、回答精度の改善サイクル、問い合わせログのレビューです。初期費用の比較だけで決めると、運用が始まってから予算が足りなくなります。3年間の総額で比べるのが実務的な見方です。
API費用の考え方はシンプルです。1回の質問で「参照する文書の抜粋＋質問文＋回答」の分だけトークンを消費します。参照文書を多く詰め込む設計ほど1件あたりのコストが上がります。月間1,000件規模なら金額としては大きくならないケースが多いものの、全社数千人が毎日使う想定なら、事前に1件あたりの単価×想定件数で試算しておくべきです。
人的工数のほうが読み違えやすい部分でしょう。社内マニュアルが3年前で止まっている、PDFが画像スキャンで文字が抽出できない、部署ごとにフォーマットがバラバラ。こうした状態だと前処理工数が跳ね上がります。運用担当者の稼働は、立ち上げ期で月10〜20時間程度を見ておくと現実的です。回答できなかった質問の確認、文書の追記、誤回答の原因特定。これを誰の業務時間に組み込むかを決めずに始めると、数ヶ月で放置されます。
費用対効果はどう試算する？回収ラインの計算式
試算の式はこれです。削減額＝月間問い合わせ件数 × 1件あたり対応時間 × 時間単価 × 自動応答率。稟議に載せるならこの4つの数字を自社の実績から埋めます。件数と対応時間は問い合わせ管理システムやメールの件数から拾えます。
計算例を出します。月800件、1件あたり平均15分、時間単価3,000円、自動応答率40%と置くと、800×0.25時間×3,000円×0.4＝24万円。月24万円相当の工数削減です。年間では288万円。ここからSaaSの月額や開発費を引いて回収期間を見ます。自動応答率は導入直後から40%出るわけではないので、初年度は20〜30%で保守的に置いたほうが説明しやすいでしょう。
金額に換算しにくい効果も稟議では効きます。担当者によって回答が違う状態の解消、深夜や休日の一次受付、退職・異動で知識が失われるリスクの低減、そして「誰に聞けばいいか分からない」時間の削減。これらは定量化しづらいものの、現場に聞けば具体的なエピソードが出てきます。数字と併記すると通りやすくなります。
※1 IPA「ソフトウェア開発分析データ集」リンク
社内文書をAIに読ませる前に確認すべき情報の取り扱い
社外のAIサービスに社内文書を入れるなら、確認すべきは3点です。(1)入力データが学習に使われないか (2)データの保存先と保存期間 (3)誰がどの文書まで参照できるかの権限制御。この3つが契約書と設定で担保されていない状態で、社内規程や顧客情報を投入してはいけません。逆に言えば、担保できていれば過度に恐れる必要もありません。
外部サービスに社内データを入れる前のチェックリスト
発注前・契約前に確認する項目を並べます。営業担当に口頭で聞くだけでなく、利用規約やデータ処理に関する条項の該当箇所を示してもらってください。無料版の生成AIサービスと法人向けAPI・エンタープライズ契約では、入力データの扱いが異なるのが一般的です。
- 入力データが学習に利用されるか。オプトアウトが可能か、法人プランでは既定で除外されるか
- データの保存先リージョン（国内か海外か）と、再委託先の有無
- ログ・入力データの保存期間と、削除要求に応じてもらえるか
- 通信・保存時の暗号化、アクセスログの取得可否
- 第三者認証（ISMS、SOC 2など）の取得状況
- 解約・退会時のデータ返却および消去の手続き
- 障害時・インシデント発生時の通知フローと責任分界
- サービス側のモデル変更・仕様変更が事前に通知されるか
技術的な確認と同じくらい重要なのが、社内側の準備です。どの文書までなら外部に出してよいのかを、「公開可／社内限定／機密」の3分類で先に決めておきます。この分類がないまま「とりあえず全部読ませてみよう」と進めると、後から止められません。個人情報を含む文書を扱う場合は、利用目的の範囲と第三者提供・委託の整理が必要になります※2。AIの利活用にあたって組織が備えるべき事項は、政府のガイドラインでも整理されています※3。
「見えてはいけない情報」が回答に出てしまう権限制御の問題
社内チャットボットで実際に起きやすい事故は、外部への漏えいより内部でのはみ出しです。人事評価や役員会資料の内容が、一般社員の何気ない質問への回答として出てしまうケースです。原因はほぼ設計にあります。全社の文書を1つの検索インデックスにまとめてしまうと、AIは「聞かれたら関連文書を探して答える」ので、権限の概念がそもそも存在しません。
対策は3方向です。まず、参照範囲を部署・役職と連動させること。既存のID基盤やグループウェアの権限設定と同期できれば、人事異動のたびに手作業で直す必要がなくなります。次に、機密度の高い文書は最初から投入しない切り分け。全部入れなくても、問い合わせの多くは一般的な規程やマニュアルで答えられます。そして回答に出典（参照した文書名）を表示させること。おかしな回答が出たときに、どの文書を見に行ったのか追跡できます。
この権限連動がどこまでできるかは、SaaS製品によって差が大きい部分です。「文書をアップロードできる」ことと「利用者ごとに参照範囲を制御できる」ことはまったく別の機能。要件が厳しいなら開発側に寄ります。最初のH2で挙げた条件1と条件3に該当する会社ほど、ここで判断が変わります。
権限制御の要件、要る/要らないを整理します。hikeに相談する
誤回答したときの責任範囲をどう設計するか
生成AIは誤りを含む回答をします。精度を上げることはできても、ゼロにはできません。前提を「誤回答は起きる」に置いたうえで、起きたときに被害を抑える設計をするのが実務です。社外向けほどこの設計の重みが増します。
- 回答に出典（参照した社内文書名やURL）を必ず付ける
- 確信度が低い質問は無理に答えず、有人にエスカレーションする閾値を決める
- 「回答は参考情報です」といった免責表示と、利用規約への明記
- 回答ログを保全し、定期的にレビューする体制
- 料金・契約条件・法務判断など、回答させない禁止トピックを定義する
社内向けなら、回答は「参考情報」として運用できます。最終判断は担当者に確認する前提を周知すれば、多少の誤りは業務の中で吸収されます。社外向けは違います。顧客からすればチャットボットの回答は企業の公式回答です。料金や契約条件を誤って伝えた場合、その説明責任が発生します。だからこそ社外向けは、回答範囲を狭く定義して、範囲外は有人に渡す設計が基本になります。
※2 個人情報保護委員会「個人情報保護法」リンク
※3 経済産業省・総務省「AI事業者ガイドライン」リンク
AIチャットボット導入の進め方5ステップ
進め方は、対象業務の絞り込み→FAQ・文書の棚卸し→PoC→本番展開→運用改善の5ステップです。最初から全社展開を狙わず、問い合わせが集中している1業務でPoCを回すのが失敗しにくい順序。各ステップに「次に進んでよい条件」を決めておくと、途中で判断がぶれません。
STEP1〜2：対象業務の絞り込みと社内文書の棚卸し
最初に決めるのは対象業務であって、ツールではありません。ツール比較から入ると、機能の話に引きずられて自社の課題が後回しになります。対象業務が決まれば、必要な機能は自動的に絞られます。期間の目安は2つ合わせて2〜4週間です。
対象業務を選ぶ基準は4つ。問い合わせ件数が多い、回答が定型的、答えが文書として存在する、担当者の負荷が高い。この4つが揃う業務が第一候補です。典型的なのは情シスヘルプデスク（パスワードリセット、VPN接続、ソフトのインストール申請）、人事・総務（有給の付与ルール、経費精算の締め日、慶弔手当）、営業の製品仕様確認（対応OS、オプション構成、納期の目安）といったところ。
次が文書の棚卸しです。ここを飛ばすと、どんなに良いツールを入れても精度は上がりません。確認するのは、既存FAQがあるか、最新版がどこに置かれているか、更新責任者が誰か、そして画像スキャンのPDFやレイアウトが複雑なExcelなど機械が読みにくい資料の割合。3割以上が機械可読でないなら、前処理工数を見積もりに明示的に含めてもらってください。「文書を渡せば読み込みます」という説明を鵜呑みにしないことです。
STEP3：PoCで何を検証し、どの数値で合否を判断するか
PoCで見るのは「動くかどうか」ではありません。正答率・カバー率（回答できた質問の割合）・想定削減工数の3指標で合否を判断します。この基準を始める前に決めていないと、「なんとなく微妙」という感想で終わり、本番判断に進めません。期間の目安は1〜2ヶ月、費用は50〜200万円程度が一つのレンジです。
進め方はこうです。過去の問い合わせ履歴から、実際に来た質問を50〜100問抜き出して評価用セットを作ります。作文した質問ではなく、実際の言い回しのまま使うのが重要。表記ゆれや曖昧な聞き方への耐性が、そこで初めて分かります。その質問をボットに投げ、業務を分かっている人が正誤を判定します。
合格ラインの目安は、対象領域を絞った状態で正答率70〜80%以上。ここで大事なのは、誤答と無回答を分けて数えることです。「分かりません」と答えて有人に回すのは、業務上は許容できます。危険なのは、それらしい誤答を自信ありげに返すケース。無回答率が高いのは文書の不足、誤答率が高いのは検索や回答生成の設計に原因がある、と切り分けられます。
STEP4〜5：本番展開と運用改善のサイクル
成果を決めるのは導入後です。回答できなかった質問のログを毎週レビューし、文書を追記・修正するサイクルを回せるかどうか。これができている組織とできていない組織で、半年後の利用率がはっきり分かれます。
展開時に決めるのは、利用チャネルと導線です。TeamsやSlackなど既に毎日開いているツールに載せるのが、使ってもらう一番の近道。新しいポータルを作って「ここに来てください」は定着しません。あわせて、答えられなかったときに有人へつなぐ導線を用意します。行き止まりを作ると、一度使って諦めた人は戻ってきません。
運用KPIは、利用率（対象部署の何%が月1回以上使ったか）、自己解決率、有人問い合わせの削減件数、利用者の満足度。そして最も重要なのが体制です。文書を更新するのは誰か。情シスが全部門の規程を最新に保つのは現実的ではありません。対象業務の所管部署が更新責任を持ち、情シスは基盤を見ます。この分担を導入前に合意しておいてください。
社内向けと社外向けで導入の勘所はどう違う？
社内向けは文書整備と権限制御が要、社外向けは誤回答リスクと有人連携が要です。同じAIチャットボットでも設計の重心が違います。1つのボットで社内と社外を兼ねようとすると、回答範囲の設計が中途半端になり、どちらでも使われないものになりやすいので分けて考えてください。
社内チャットボットで成果が出やすい業務と設計のポイント
社内チャットボットで効果が出やすいのは、情シスヘルプデスク、人事・総務の規程問い合わせ、営業の製品仕様確認です。共通するのは、質問が繰り返し発生し、答えが文書として存在していること。「パスワードをリセットしたい」「有給はいつ付与されるか」「この製品は最新OSに対応しているか」といった質問が毎月何十件も来ているなら、候補になります。
設計のポイントは3つあります。既に使っているTeamsやSlackに載せる導線、社内文書の更新責任者の明確化、部署ごとの参照権限の設定。特に2つ目が抜けやすい部分です。ボットは元の文書が古ければ古い答えを返します。文書の鮮度を保つ担当が決まっていないなら、その業務はまだ導入時期ではないかもしれません。
社内向けの利点は、回答を「参考情報」として運用できることです。最終確認は担当者に、という前提を周知しておけば、精度が完璧でなくても導入を始められます。スモールスタートしやすいのは、この責任設計の軽さによるものです。
社外向け（カスタマーサポート）で追加で必要になること
社外向けでは、回答範囲の限定・有人エスカレーション・ログ保全・免責表示が追加で必要になります。顧客から見ればボットの回答は企業の公式回答だからです。「たぶんこうです」で済む世界ではありません。
加えて要件として乗ってくるのが、既存のCRMや問い合わせ管理システムとの連携（有人に引き継ぐときに会話履歴も渡す）、注文状況など顧客個別データの照会、多言語対応、ブランドトーンに合わせた文体の調整です。これらは最初のH2で挙げた条件2（基幹システム連携）と条件3（社外への回答責任）に真正面から当たります。社外向けの本格導入が開発側に寄りやすいのは、この構造的な理由によるものでしょう。
効果としては、24時間の一次受付による営業時間外の取りこぼし削減、よくある質問の自動処理によるオペレーターの負荷軽減が挙げられます。ただし「有人対応をゼロにする」目標は現実的ではありません。一次受付とルーティングを担わせ、複雑な案件は人が対応する。この役割分担を前提に設計するほうが、結果的に顧客満足度も保てます。
導入が失敗する典型パターン3つ
頓挫するケースは、だいたい3つのどれかです。文書が整備されていない、目的とKPIがない、運用担当が決まっていない。技術の問題より、発注前の準備で防げるものがほとんどです。自社に当てはまるものがないか確認してみてください。
パターン1：元の社内文書が整備されていないまま導入して精度が出ない
AIは存在しない情報を正しく答えられません。マニュアルが古い、複数バージョンが混在している、そもそも文書化されず担当者の頭の中にある。この状態で導入すると、当然ながら回答は当たりません。回避条件は、STEP2の文書棚卸しを発注前に済ませ、整備工数を見積もりに含めておくことです。
パターン2：目的とKPIを決めずに、AI導入自体が目的化する
「AIチャットボットを導入した」で満足してしまうケース。何件の問い合わせを、どの部署の、どれだけの工数削減につなげるのかが定義されていないため、成果を評価できず、次の投資判断もできません。回避条件は、PoC前に対象業務と評価指標を数値で決めておくことです。
パターン3：運用担当と更新責任者が決まらず、数ヶ月で使われなくなる
導入直後は物珍しさで使われますが、情報が古くなり、外れた回答が続くと利用者は離れます。一度「使えない」と認識されたものを再度使ってもらうのは、新規導入より難しくなります。回避条件は、契約前に「誰が毎週ログを見て、誰が文書を直すか」を部署名と役割で決めておくことです。
まとめ：自社はSaaSと開発のどちらから始めるべきか
判断の順序はシンプルです。3つの分岐条件で形態を決め、費用は総保有コストで見て、外部サービスを使うなら情報の取り扱いを契約前に確認し、1業務のPoCから始める。この流れを押さえておけば、比較サイトのツール一覧に振り回されずに済みます。
- 社内文書の参照／基幹システム連携／社外への回答責任、この3条件のYESの数でSaaSか開発かを判断する
- 費用の目安はSaaSで初期0〜50万円＋月額3〜30万円、RAG型の開発で200〜1,000万円。加えてLLMの従量課金と文書整備の工数を見込む
- 外部サービスを使うなら、学習利用の有無・データ保存先・参照権限の制御の3点を契約前に確認する
- 1業務に絞ったPoCを行い、正答率とカバー率で合否を判断してから本番展開する
- 成果を決めるのは導入後の運用サイクル。文書の更新責任者を決めてから始める
次の一歩として手を付けやすいのは、直近1ヶ月分の問い合わせログを集計し、多い質問の上位20件を洗い出すことです。この20件が「答えが文書に存在するもの」で埋まっていれば、SaaSでも十分に効果が出る可能性があります。逆に、顧客ごとの状況確認や、複数の社内文書をまたぐ判断が並ぶなら、開発を含めた検討が必要な領域です。この集計は、後にどの選択肢を取るとしても要件定義の材料になります。
よくある質問
AIチャットボットの導入期間はどれくらいかかりますか？
SaaS型なら2週間〜2ヶ月、社内文書を読ませるRAG型の開発なら2〜6ヶ月が目安です。最も変動するのは文書整備の状況で、既存FAQが整っている場合と、資料が各部署に散らばっている場合では前工程の期間が大きく変わります。社内の合意形成や情報システム部門のセキュリティ審査の期間も、別途見込んでおくと安全です。
従来のシナリオ型チャットボットとAIチャットボットは何が違いますか？
シナリオ型は事前に定義した選択肢と分岐で回答し、AIチャットボット（生成AI型）は文書を検索して回答文を生成します。違いが出るのは、想定していない聞き方への耐性と、FAQ件数が増えたときのメンテナンス負荷です。シナリオ型は答えが確定的で管理しやすい反面、質問の表記ゆれには弱い面があります。生成AI型は柔軟ですが、誤回答の可能性が残ります。両方を組み合わせる製品も一般的です。
FAQが整備されていなくても導入できますか？
過去の問い合わせメールやチャットのログから作ることは可能です。ただし、その整備は無料では終わりません。ログの抽出、重複整理、回答内容の正誤確認には工数がかかるため、発注時に「文書整備は誰がどこまでやるのか」を見積もりの中で明記してもらってください。ここを曖昧にしたまま進めると、後から追加費用の議論になりやすい部分です。
AIチャットボットの回答精度はどれくらい期待できますか？
対象領域を絞れば、正答率70〜90%程度が現実的なラインとされます。ただし数値は評価用の質問セットの作り方によって変わるため、他社の数字をそのまま自社に当てはめないでください。全社横断の汎用ボットにすると参照範囲が広がり、精度は落ちる傾向があります。領域を絞るほど精度は上がりやすい、と覚えておくと設計判断がしやすくなります。
導入に補助金は使えますか？
IT導入補助金など、対象になる可能性のある制度は存在します。ただし対象経費・申請要件・補助率は年度ごとに変わり、2026年時点の情報がそのまま次年度に当てはまるとは限りません※4。申請を前提に計画を立てる場合は、必ず最新の公募要領で対象要件とスケジュールを確認し、交付決定前の発注が対象外になる点にも注意してください。
導入後の運用は誰が担当すべきですか？
情報システム部門の単独運用は避けたほうが無難です。回答の元になる文書の内容を判断できるのは、その業務を所管する部署だからです。基盤・アカウント管理を情シスが、文書の更新と回答内容のレビューを所管部署が担う分担が現実的でしょう。立ち上げ期は月10〜20時間程度の稼働を業務として割り当てておくと、形骸化を防げます。
※4 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク