AIチャットボットを社内に入れたい、という相談の中身は大きく2つに分かれる。社員の質問に社内の規程や手順書をもとに答えるものと、顧客の問い合わせに答えるものだ。どちらも画面は同じように見えるが、間違えたときの重さと、作る前に決めることが違う。
この記事は、AIチャットボット開発を社内に入れるまでの手順と注意点をまとめる。作る前に決める3つのこと、作り方の型、6つの手順、注意点、導入費用の考え方の順に書く。社内の文書を検索して答える仕組みの作り方はRAGの作り方に、誤った答えを減らす設計はハルシネーション対策に詳しく書いた。
作る前に決める3つのこと
私の見方では、AIチャットボット開発が止まる原因は、技術より先にこの3つが決まっていないことが多い。
| # | 決めること | 決めないと起きること |
|---|---|---|
| 1 | 誰に向けるか（社員か、顧客か） | 誤回答の重さが分からず、確認の手間をどこまでかけるか決まらない |
| 2 | 何に答えるか（答える範囲と、元にする文書） | 何でも聞かれ、答えの質が測れない |
| 3 | 答えられないときにどうするか | 分からない質問にもそれらしく答え、誤回答がそのまま届く |
1つ目は特に大きい。カナダでは2024年、Air Canadaのチャットボットが運賃の払い戻しについて規程と違う案内をした件で、紛争解決の審判所が航空会社の責任を認めた。チャットボットは別の存在だという会社の主張は退けられ、審判所は、Air Canadaは自社サイト上のすべての情報に責任を負うと述べた。顧客に向けたチャットボットの答えは、会社の答えとして扱われうる。
3つ目は、範囲外の質問や自信のない質問を、問い合わせ窓口や担当者に渡す道のことだ。私の見方では、これを最初の設計に入れておくかどうかで、試験運用で信頼されるかが決まる。
作り方の4つの型
AIチャットボットの作り方は、手間と自由度で4つの型に分けて考えると選びやすい。表は私の整理だ。
| 型 | 中身 | 向いている場面 |
|---|---|---|
| 既製のサービスをそのまま使う | 問い合わせ対応などのチャットボット製品を契約し、文書を登録する | 答える範囲が狭く、社内のシステムとつなぐ必要が少ない |
| 生成AIの法人プランの機能で作る | 社員が使っている生成AIのサービスに、文書と指示を登録して共有する | 社員向けで、まず小さく試したい |
| クラウドの部品で組む | クラウド事業者の検索やモデルのサービスを組み合わせて作る | 社内のシステムやデータとつなぎ、権限を細かく分けたい |
| 自前で開発する | モデルのAPIを使い、検索・画面・記録を自社で作る | 業務の流れに深く組み込みたい、独自の制御が要る |
下の型ほど自由度は高いが、作る人と運用する人が要る。私の見方では、最初から自前で開発するより、上の型で答える範囲と評価の仕方を固め、足りなくなった部分から下の型に移る方が、何に費用を払うのかがはっきりする。
社内に入れるまでの6つの手順
型を決めたら、次の6つの手順で進める。
1. 質問を集める
対象の部署から、実際に来ている質問を集める。問い合わせの記録や、社内のチャットでよく聞かれていることが材料になる。集めた質問は、あとで評価に使うのでそのまま残しておく。
2. 答えの元になる文書を整える
古い版の規程や、部署ごとに違う手順書が混ざっていると、チャットボットは古い方を答える。どの文書を正とし、誰が更新するかを決める。文書を検索しやすく分ける方法はRAGの作り方にまとめた。
3. 権限を設計する
社員向けでも、全員がすべての文書を読めるわけではない。OWASPのLLMアプリのリスク一覧（2025年版）は、LLM08「Vector and Embedding Weaknesses」で、アクセス制御が不十分だと機密情報を含む埋め込みに権限のない人がアクセスできてしまうリスクを挙げている。利用者が本来読めない文書の内容を答えないように、文書ごとの閲覧権限を検索の段階で反映させる。
4. 試作して評価する
手順1で集めた質問を、正しい答えと一緒に評価用の質問の一覧にする。試作したチャットボットにその一覧を通し、正しく答えたか、元の文書を正しく示したか、答えられない質問を断れたかを数える。測り方はLLMの評価のやり方に書いた。
5. 小さく試験運用する
一つの部署か、一部の顧客に絞って出す。利用者が答えの良し悪しを返せるようにし、答えられなかった質問を記録する。試験運用で集まった質問は、評価の一覧に足していく。
6. 本番に出し、運用を決める
本番に出す前に、文書の更新、評価の一覧の見直し、誤回答の報告を受ける窓口を、誰がどの頻度で担うかを決める。私の見方では、AIチャットボット開発の手間は、作るときより出したあとの方が長く続く。
注意点: 誤回答・攻撃・個人情報・告知
誤回答
生成AIは、もっともらしい誤りを答えることがある。答えに元の文書を添えて利用者が確かめられるようにし、答える範囲の外の質問は断るか人に渡す。設計の詳しい考え方はハルシネーション対策にまとめた。
指示を書き換える攻撃
チャットボットへの入力や、読み込んだ文書に紛れた文章で、作り手の意図しない動きをさせる攻撃がある。プロンプトインジェクションと呼ばれる。チャットボットにメールの送信やデータの更新などの操作をさせるなら、操作の権限を絞り、重い操作には人の承認を挟む。仕組みと対策はプロンプトインジェクションとはに書いた。
個人情報
個人情報保護委員会は2023年6月2日の「生成AIサービスの利用に関する注意喚起等」で、個人情報取扱事業者が個人情報を含むプロンプトを入力する場合には、利用目的を達成するために必要な範囲内であることを十分に確認するよう求めた。あらかじめ本人の同意を得ずに個人データを含むプロンプトを入力し、そのデータが応答結果の出力以外の目的で取り扱われる場合は、個人情報保護法の規定に違反する可能性があるとし、提供事業者が個人データを機械学習に利用しないこと等を十分に確認するよう書いている。顧客の問い合わせ内容を扱うチャットボットは、この確認が要る。設定の確かめ方はChatGPTに学習させない設定にまとめた。
AIであることの告知
EUの利用者に向けて出す場合は、EUのAI規則の第50条で、人と直接やり取りするAIは、相手がAIと話していることを知らせる義務がある。日本の利用者だけに向けたチャットボットでも、私の見方では、AIが答えていることと、人に問い合わせる道を画面に示しておく方がよい。EUの規則の全体はEU AI法と日本企業に書いた。
AIチャットボットの導入費用の考え方
AIチャットボットの導入費用は、次の3つに分けて見積もる。表は私の整理だ。
| 内訳 | 中身 | 見積もりで抜けやすいもの |
|---|---|---|
| 最初に作る費用 | 質問の収集、文書の整理、権限の設計、試作と評価 | 文書の整理と権限の設計 |
| 使った量に応じた利用料 | モデルのAPIの料金、検索のサービスの料金、製品の利用料 | 1回の質問で読み込む文書の量 |
| 運用を続ける費用 | 文書の更新、評価の見直し、誤回答への対応 | ほぼ全部 |
利用料は料金表で見積もれる。Anthropicの価格表では、Claude Sonnet 5.5は100万トークンあたり入力2ドル、出力10ドルだ。たとえば1回の質問で検索した文書を含めて入力5,000トークン、出力500トークンを使うと仮定すると、1回あたり0.015ドルになる。この仮定で月に1万回答えると150ドルだ。数字は計算の例で、実際の量は文書の長さと質問の数で大きく変わる。
私の見方では、利用料より大きくなりやすいのは、最初に作る費用のうちの文書の整理と、運用を続ける費用だ。見積もりを比べるときは、この2つが入っているかを先に確かめるとよい。開発費の内訳の見方はAI開発の費用の内訳に詳しく書いた。
外部に頼むときに確かめること
私の見方では、誰に向けるか、何に答えるか、答えられないときにどうするかは、社内で決めるべきことだ。外部に頼む意味が大きいのは、社内のシステムやデータとつなぎ、権限を設計し、評価の仕組みを作る部分だ。
頼む相手を選ぶときは、次の4つを確かめるとよい。
- 評価用の質問の一覧を一緒に作り、数字で良し悪しを示すか
- 文書ごとの閲覧権限をどう反映させるかを説明できるか
- 答えられない質問を人に渡す流れまで設計に入れるか
- 本番に出したあとの文書の更新と評価の見直しを、社内で回せる形で渡すか
チャットボットを作って渡すだけでなく、現場に入って業務の流れに組み込み、使われるところまで付き合う役割は、FDE（Forward Deployed Engineer）と呼ばれる職種の仕事と重なる。FDEという職種はFDEとは？Forward Deployed Engineerの意味と仕事内容に、頼む相手の選び方はFDE支援会社の選び方にまとめた。
私たちが何をどこまで引き受けるかはサービス詳細に書いている。