AIチャットボット開発を依頼する前に：種類・RAGの仕組み・準備・リスク対策まで実務目線で解説

「社内の問い合わせ対応をAIに任せたい」「Webサイトの質問窓口を24時間対応にしたい」。生成AIが身近になり、こうした相談がとても増えました。一方で、いざ開発を依頼しようとすると、何を決めておけばよいのか、見積もりの前に何を伝えればよいのかが分からず、話が進まないという声もよく聞きます。

この記事は、AIチャットボットの導入を検討している企業の担当者、とくに社内FAQや問い合わせ対応の効率化を任された方に向けて書いています。チャットボットの種類の違い、生成AIチャットボットでよく使われるRAGという仕組み、開発を依頼する前に整理しておきたい項目、見落としやすいリスクとその対策、公開前の品質確認と公開後の運用まで、順を追って説明します。専門知識がなくても読めるように、技術用語はできるだけ言い換えています。

AIチャットボットは大きく2種類に分けられる

ひとくちに「チャットボット」といっても、仕組みによって得意なことが大きく異なります。依頼の前に、自社がどちらを求めているのかを把握しておくと、開発者との会話がスムーズになります。

ルールベース型（シナリオ型）

あらかじめ用意した質問と回答の組み合わせや、選択肢を順にたどる会話の流れ（シナリオ）に沿って応答するタイプです。「営業時間を知りたい」「配送について」といったボタンを押していくと、決められた回答にたどり着く形式を見たことがある方も多いと思います。回答はすべて人が事前に書いたものなので、想定外の内容を答えてしまう心配はほとんどありません。その代わり、想定していない聞き方や質問には対応できず、質問のパターンが増えるほどシナリオの作成と保守に手間がかかります。

生成AI型

大規模言語モデル（LLM）を使い、利用者が自由に書いた文章を理解して、その場で回答文を組み立てるタイプです。言い回しが多少違っていても意図をくみ取れる、長い資料の中から該当部分を探して要約できる、といった柔軟さが強みです。一方で、事実と異なる内容をもっともらしく答えてしまうことがあり、回答の正確さを担保する工夫が欠かせません。

2つのタイプの比較

実際の開発では、どちらか一方に決めるのではなく、両方を組み合わせることもよくあります。たとえば、申込手続きのように手順が決まっている部分はシナリオで確実に案内し、自由な質問は生成AIで受ける、といった構成です。「間違えたら困る回答」と「柔軟さが欲しい回答」を分けて考えると、どちらを使うべきかが見えてきます。

AIチャットボットのよくある活用場面

生成AIチャットボットがよく検討される用途を挙げます。自社の課題に近いものがあるか、照らし合わせながら読んでみてください。

• 社内FAQ：経費精算、勤怠、社内システムの使い方など、総務・人事・情報システム部門に繰り返し届く質問への回答。担当者が同じ説明を何度もする負担を減らせます。
• お客様からの問い合わせの一次対応：商品やサービスの基本的な質問に答え、解決しない場合は問い合わせフォームや有人窓口に案内します。夜間や休日にも最低限の案内ができます。
• 社内規程・マニュアルの検索：就業規則や業務マニュアルなど、分量が多く目的の箇所を探しにくい文書から、関連する記述を探して答えます。
• 文書の要約・下書き支援：長い報告書や議事録の要点をまとめる、定型的なメールの下書きを作るといった、社内向けの作業補助です。
• 新人・異動者のオンボーディング：配属直後に聞きづらい基本的な質問を、気兼ねなく聞ける相手として使う例もあります。

社内向けとお客様向けでは、求められる正確さや、答えてよい内容の範囲が大きく異なります。お客様向けは誤回答がそのまま企業の信用に関わるため、最初は社内向けで小さく試し、運用の勘所をつかんでから社外に広げるという進め方も現実的です。

RAGとは：自社の資料をもとに答えさせる仕組み

生成AIチャットボットの相談で、ほぼ必ず出てくるのが「RAG（ラグ）」という言葉です。Retrieval-Augmented Generationの略で、日本語では「検索拡張生成」と訳されることがあります。

大規模言語モデルは、学習した大量の文章から知識を得ていますが、自社の社内規程や最新の商品情報のように、学習していない情報は当然知りません。知らないことを聞かれても、それらしい文章を作ってしまうことがあります。そこで、質問を受けたらまず関連する資料を検索し、見つかった記述を材料としてAIに渡したうえで回答を作らせる、というのがRAGの基本的な考え方です。

処理の流れを簡単にまとめると、次のようになります。

1. マニュアルやFAQなどの資料を、検索しやすい単位に分割して保存しておく
2. 利用者の質問に関連しそうな箇所を、保存した資料の中から検索する
3. 見つかった記述と質問をあわせてAIに渡し、その内容に基づいて回答を作らせる
4. 必要に応じて、回答の根拠になった資料名や該当箇所を一緒に表示する

RAGという名称は、Patrick Lewisらが2020年に発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」に由来します。この論文では、事前学習済みの言語生成モデルと、Wikipediaから関連文書を取り出す検索の仕組みを組み合わせる手法が提案されました。現在のチャットボット開発でいう「RAG」は、この考え方を広く応用したものを指すことが多く、検索の方法や構成は開発者やサービスによってさまざまです。

RAGを使う利点は、回答の根拠を自社の資料に寄せられること、資料を差し替えればAIの再学習をしなくても回答内容を更新できること、根拠となった資料を利用者に示せることです。ただし、RAGを使えば誤回答がなくなるわけではありません。検索で的外れな箇所を拾ってしまえば回答もずれますし、資料そのものが古かったり矛盾していたりすれば、その内容がそのまま回答に出ます。RAGの品質は、参照させる資料の品質に大きく左右されると考えておくのが実態に近いと思います。

開発を依頼する前に整理しておきたいこと

ここからが本題です。以下の項目が整理されているほど、開発者は必要な作業を見積もりやすくなり、完成後の「思っていたものと違う」も減ります。すべてを完璧に決める必要はありません。未定の項目は「未定」と書いておくだけでも、相談の中で一緒に詰めていけます。

1. 目的と、成功したと判断する基準

「問い合わせ対応の工数を減らしたい」「社員が規程を探す時間を短くしたい」など、何のために導入するのかを一文で言えるようにしておきます。あわせて、導入後に何を見て効果を判断するかも考えておくと、公開後の改善の方向性がぶれません。たとえば、担当部署に届く問い合わせ件数、チャットボットで解決した割合、利用者アンケートの満足度などが考えられます。

2. 対象ユーザーと想定される質問

社員全員なのか、特定の部署なのか、社外のお客様なのかで、言葉づかいや前提知識、必要な権限管理が変わります。実際に届いている質問の例を20〜30件ほど集めておくと、開発の段階でも公開前のテストでも非常に役立ちます。問い合わせメールの履歴や、担当者が「よく聞かれる」と感じている質問を書き出すだけでも十分です。

3. 参照させる資料と、その更新方法

• どの資料を参照させるか（FAQ、マニュアル、規程集、商品ページなど）
• 資料の形式と置き場所（Word、PDF、Excel、Webページ、社内のファイル共有サービスなど）
• 資料の更新頻度と、更新されたときに誰がどう反映するか
• 資料の中に古い版や重複、矛盾している記述がないか

見落とされがちなのが更新方法です。公開時点では正しくても、規程が改定されたのにチャットボット側の資料が古いままだと、古いルールを自信たっぷりに案内してしまいます。「担当者が管理画面から差し替える」「決まったフォルダに置けば自動で取り込まれる」など、運用に合った方法を開発者と相談して決めておきます。

4. 回答してはいけない範囲

個人情報、人事評価や給与の個別事情、未公開の経営情報、法律・医療・税務などの専門的な判断が必要な内容など、チャットボットに答えさせたくない範囲を洗い出しておきます。お客様向けであれば、値引きや契約条件の変更のように、担当者の判断が必要な約束をしないことも重要です。こうした質問を受けたときにどう返すか（「担当窓口にお問い合わせください」と案内する等）も、あわせて決めておきます。

5. 人への引き継ぎ

チャットボットだけですべてを解決するのは現実的ではありません。答えられなかったとき、利用者が納得しなかったときに、どこへつなぐかを決めておきます。問い合わせフォームへのリンクを表示する、担当者に通知を送る、会話の内容を引き継いで有人チャットに切り替える、などの方法があり、どこまで作り込むかで開発の規模も変わります。

6. 設置場所と利用環境

自社のWebサイト、社内ポータル、SlackやMicrosoft Teamsなどの社内チャットツール、LINEなど、どこでチャットボットを使うのかを決めます。設置場所によって、ログインの要否、利用者の特定方法、画面の作り方が異なります。社内向けなら、普段から使っているチャットツールに組み込むと利用されやすい傾向があります。

7. 社内のルールと関係者

社内の資料を外部のAIサービスで扱ってよいか、情報システム部門や法務の確認が必要かどうかも、早めに確認しておきます。開発が進んでから利用できるサービスの制約が判明すると、構成の作り直しになることがあります。承認に関わる人、資料を管理している人、公開後に運用を担当する人を、あらかじめ把握しておくと進行が止まりにくくなります。

見落としやすいリスクと対策

AIチャットボットは便利な反面、仕組み上避けられない弱点があります。リスクをゼロにすることはできないので、「起こりうる前提で、影響を小さくする設計と運用」を考えるのが基本です。

誤回答（ハルシネーション）

生成AIが事実と異なる内容をもっともらしく答えてしまう現象は、ハルシネーションと呼ばれます。RAGで自社の資料を参照させても、完全には防げません。対策としては、資料に書かれていない内容には「分かりません」と答えるよう指示する、回答に参照元の資料名やリンクを示して利用者が原文を確認できるようにする、重要な手続きや金額に関わる内容はチャットボットの回答だけで完結させず原文や担当者の確認を促す、といった方法を組み合わせます。利用者に対しても「AIによる回答であり、誤りを含む場合がある」ことを画面上で伝えておくのが一般的です。

機密情報・個人情報の扱い

利用するAIサービスに送信したデータがどのように保存・利用されるかは、サービスや契約プランによって異なります。導入前に、利用規約やデータの取り扱いに関する説明を確認し、社内の情報管理ルールに合っているかを確かめる必要があります。個人情報保護委員会は2023年6月に「生成AIサービスの利用に関する注意喚起等」を公表しており、事業者が個人情報を含むプロンプトを入力する場合には、利用目的の達成に必要な範囲内であることを十分に確認するよう求めています。また、入力した個人データが応答結果の出力以外の目的で扱われる場合には、個人情報保護法の規定に違反する可能性があると指摘しています。個人情報を含む資料を参照させる、または利用者が個人情報を入力しうる設計にする場合は、特に慎重な検討が必要です。

社内向けの場合は、閲覧権限の問題にも注意します。本来は一部の社員しか見られない資料をチャットボットの参照先に入れてしまうと、権限のない社員にも内容が回答として表示されてしまうおそれがあります。部署ごとに参照できる資料を分ける、機密度の高い資料はそもそも対象に入れない、といった線引きが必要です。

悪意のある入力（プロンプトインジェクション）

AIへの指示を上書きするような文章を入力して、想定外の動作をさせようとする攻撃があります。OWASPが公開している「OWASP Top 10 for LLM Applications 2025」でも、プロンプトインジェクションは最初の項目（LLM01）に挙げられており、利用者の直接の入力だけでなく、Webサイトやファイルなど外部の内容に仕込まれた指示によって起こる場合もあると説明されています。特に社外向けのチャットボットでは、AIに渡す権限を必要最小限にする、社内システムの操作を伴う機能は慎重に設計する、といった配慮を開発者と確認しておきます。

参照資料の鮮度

先ほど触れたとおり、資料が古いとチャットボットの回答も古くなります。資料ごとに管理担当者を決める、改定があったらチャットボット側も更新する手順を業務フローに組み込む、資料に最終更新日を記載して回答にも表示する、といった仕組みづくりが有効です。古い版の資料を参照先に残したままにしないことも大切です。

ログの確認

公開後にどんな質問が来て、どう答えたのかを確認できなければ、誤回答にも気づけません。会話ログを保存し、定期的に確認できるようにしておきます。ただし、ログ自体に個人情報や機密情報が含まれる可能性があるため、保存期間、閲覧できる人、利用目的もあわせて決めておく必要があります。

公開前に品質を確かめる方法

「何となく試して、良さそうだから公開」は失敗のもとです。公開前の評価は、次のような手順で行うと抜け漏れが減ります。

1. テスト質問集を作る：依頼前に集めた実際の質問例をもとに、質問と「正解として期待する回答の要点」「根拠となる資料の箇所」を表にまとめます。よくある質問だけでなく、言い回しを変えた質問、資料に答えがない質問、答えてはいけない質問も意図的に含めます。
2. 判定の基準を決める：「正しい」「一部誤りがある」「誤り」「適切に回答を控えた」など、評価の区分を事前に決めておくと、担当者によって判断がぶれにくくなります。
3. 業務を知っている人が確認する：回答が正しいかどうかは、その業務の担当者でなければ判断できないことが多いものです。開発者任せにせず、資料の管理部署の人に確認してもらいます。
4. 問題の原因を切り分ける：誤回答があったときは、資料に正しい記述がないのか、検索で正しい箇所を拾えていないのか、回答の作り方に問題があるのかを分けて考えます。原因によって、資料の修正で済むのか、開発側の調整が必要なのかが変わります。
5. 限られた利用者で試験運用する：いきなり全社や一般公開にせず、一部の部署や社内メンバーだけで試し、実際の質問のされ方を見てから範囲を広げます。

生成AIの回答は毎回まったく同じとは限らないため、同じ質問を何度か試して回答のぶれを確認しておくと安心です。テスト質問集は公開後も使い続けられる資産になるので、資料や設定を変更したときの再確認にも活用できます。

公開後の運用で大切なこと

AIチャットボットは、公開したときが完成ではなく、運用しながら育てていくものです。公開後に取り組みたいことを挙げます。

• ログの定期的な確認：答えられなかった質問や、利用者の評価が低かった回答を中心に確認し、改善点を洗い出します。
• 資料の追加・修正：答えられなかった質問の多くは、資料側に情報がないことが原因です。FAQを追加したり、分かりにくい記述を直したりすることで、チャットボットの回答も改善されます。結果として、社内の資料そのものが整理されるという副次的な効果もあります。
• 利用者からのフィードバックの仕組み：回答ごとに「役に立った／役に立たなかった」を押せるようにするなど、利用者の声を集める仕組みがあると、改善の優先順位をつけやすくなります。
• AIモデルやサービスの変更への対応：利用しているAIサービスは、モデルの更新や提供終了などで仕様が変わることがあります。変更の際はテスト質問集で回答品質を確認し直します。
• 運用担当者の明確化：ログ確認や資料更新を誰が担当するのかが曖昧だと、公開直後は良くても徐々に品質が落ちていきます。

開発を依頼する際には、公開後の保守や改善をどこまで対応してもらえるのか、自社で行う作業は何かも確認しておくと、後々の行き違いを防げます。

VibeCoderでは、AIチャットボットをはじめとする開発の依頼を依頼ページから受け付けています。依頼の送信は無料で、担当者より2〜3営業日以内にご連絡します。この記事で挙げた項目がすべて決まっていなくても、目的と想定している使い方が分かれば相談は始められます。

よくある質問

ChatGPTなどをそのまま使うのと、チャットボットを開発するのは何が違いますか？

汎用のAIサービスは幅広い質問に答えられますが、自社の規程や商品情報を踏まえた回答は、そのままでは期待できません。チャットボットとして開発すると、参照する資料を自社のものに限定する、答えてよい範囲を制御する、自社のWebサイトや社内チャットツールに組み込む、ログを確認して改善する、といった業務に合わせた作り込みができます。

RAGを使えば、誤回答はなくなりますか？

なくなりません。RAGは回答の根拠を自社の資料に寄せる仕組みですが、検索で関係のない箇所を拾ったり、資料の内容を取り違えたりすることはあります。参照元の表示、回答を控える条件の設定、公開前のテスト、公開後のログ確認を組み合わせて、誤回答が起きても気づけて直せる体制にしておくことが大切です。

参照させる資料が整理されていなくても依頼できますか？

依頼すること自体は可能です。ただ、資料に古い版が混ざっていたり、部署ごとに異なる説明が書かれていたりすると、チャットボットの回答もそれに引きずられます。まずは対象を絞り、よく聞かれる質問に関係する資料から整理していくと、無理なく始められます。

開発期間はどのくらいかかりますか？

対象とする資料の量、設置場所、人への引き継ぎや権限管理をどこまで作り込むかによって大きく変わります。VibeCoderでは最速1日で納品できる場合もありますが、納期は内容・規模によって異なります。試作を早めに作り、実際に触りながら仕様を詰めていく進め方もおすすめです。

社内で運用を担当できる人がいなくても大丈夫でしょうか？

高度な技術知識は必須ではありませんが、ログを確認して資料を更新する担当者は社内に置くことをおすすめします。回答が正しいかどうか、どの資料を直すべきかは、業務を知っている人でなければ判断しにくいためです。開発者には、担当者が無理なく更新できる仕組みにしてほしいと伝えておくとよいでしょう。

参考

• Patrick Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"（arXiv, 2020）
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）
• OWASP Gen AI Security Project「LLM01:2025 Prompt Injection」

まとめ

AIチャットボットの開発を依頼する前に押さえておきたいポイントを振り返ります。

• 決まった案内を確実に返すならルールベース型、自由な質問に柔軟に答えるなら生成AI型。両者を組み合わせる構成もある
• 自社の資料をもとに答えさせるにはRAGがよく使われるが、回答の品質は参照資料の品質に左右される
• 依頼前に、目的、対象ユーザーと質問例、参照資料と更新方法、答えてはいけない範囲、人への引き継ぎ、設置場所を整理しておく
• 誤回答、情報の取り扱い、悪意のある入力、資料の鮮度、ログ管理のリスクは、設計と運用の両面で備える
• テスト質問集で公開前に品質を確かめ、公開後はログと資料の更新で育てていく

最初から完璧なチャットボットを目指すより、対象を絞って公開し、実際の質問をもとに改善を重ねるほうが、結果的に現場で使われるものになります。まずは社内でよく聞かれる質問を書き出すところから始めてみてください。