AIチャットボットの作り方｜5つの仕様

AIチャットボットは、数時間あれば試作品を動かせる。社内文書を数点読み込ませ、質問画面を用意すれば、もっともらしい回答が返ってくる。

ところが、実務で使い始めると景色が変わる。「この質問には答えてよいのか」「古い規程を参照していないか」「答えられないときは誰へ渡すのか」といった問題が一気に出てくる。

つまり、AIチャットボットの作り方で難しいのは、会話画面やモデル選びではない。回答範囲、参照情報、引き継ぎ、評価、運用の5つを仕様にすることだ。

ここでは、社内問い合わせ対応のチャットボットを例に、試作を本番運用へつなぐ設計順を整理する。

AIチャットボットの作り方は目的を一文で決める

最初に、チャットボットの目的を一文で書く。

「生成AIで社内問い合わせを効率化する」では広すぎる。次のように、利用者、対象業務、成果を入れる。

> 経費申請を行う従業員に対し、最新の社内規程と申請手順を根拠付きで案内し、解決できない質問は総務担当へ引き継ぐ。

この一文があると、作るものが具体的になる。

• 利用者は従業員である
• 対象は経費申請に限る
• 根拠は社内規程と申請手順である
• 解決不能時は総務へ渡す

Google Cloudのエージェント設計ガイドも、構築前に業務目的、利用者の期待、利用頻度を検討するよう示している。目的を決めずにFAQや文書を投入すると、回答できる範囲だけが増え、責任を持てる範囲は曖昧なままになる。

目的を一文にできたら、次の5仕様へ分解する。

仕様1：回答する範囲と答えない範囲を分ける

最初の仕様は、対象質問と対象外質問の一覧である。

経費申請のチャットボットなら、回答対象は次のように切れる。

ここで大事なのは、AIの知識量ではなく業務上の決定権だ。規程を説明することと、個別案件を承認することは違う。後者まで任せるなら、承認権限、証跡、取消手順が必要になる。

NIST AI RMF Coreでは、AIが支援する具体的な業務と利用範囲、人間による監督を定義・文書化することが示されている。チャットボットでも、対象外と禁止事項を先に書く方が安全だ。

作成物は「対象質問・対象外質問・禁止質問」の3列でよい。最初から完全にする必要はない。問い合わせ履歴を20〜50件ほど確認し、実際に多い質問から埋める。

仕様2：参照する情報と更新責任者を決める

次に、回答の根拠を決める。

RAGを使えば、社内文書から関連箇所を検索して回答できる。ただし、文書を入れれば正しくなるわけではない。古い規程、重複ファイル、下書き、閲覧権限の異なる資料が混ざると、検索結果もぶれる。

Microsoft Copilot Studioの公式文書では、Webサイト、ファイル、SharePoint、Dataverse、Azure AI Searchなどを知識源として追加できる。選択肢が多いからこそ、接続できるかではなく、どれを正本として扱うかを決める必要がある。

参照情報は、次の表で管理する。

MicrosoftのRAGガイダンスは、組織固有の信頼できる情報で回答を根拠づける設計を説明している。ここでの「信頼できる」は、内容が正しいだけでは足りない。版、所有者、権限、更新日を追えることまで含む。

生成モデルの一般知識をどこまで許すかも決める。社内規程の回答では、根拠文書を見つけられないときに一般論で補わない方がよい。「確認できませんでした」と返す仕様は、失敗ではなく安全機能である。

モデルやAPIの選択は、この知識源と回答制約を満たせるかで比べる。生成AIのAPIを選ぶ4つの運用条件も、データ保持、可用性、速度、モデル更新の確認に使える。

仕様3：人への引き継ぎ条件を決める

AIチャットボットは、すべての質問へ答える必要はない。むしろ、答えない判断を正しくできる方が本番では役に立つ。

引き継ぎ条件を明示する。

• 根拠文書を取得できない
• 複数の規程が矛盾している
• 個人情報や権限外の情報を含む
• 承認、契約、法務、税務など人間の判断が必要である
• 利用者が回答に納得せず、担当者対応を希望した
• 同じ質問を繰り返しても解決しない

引き継ぎ時には、会話全文をそのまま担当者へ投げない。次の情報を構造化して渡す。

1. 利用者が解決したいこと
2. チャットボットが確認した情報
3. 参照した文書と該当箇所
4. 解決できなかった理由
5. 担当者に判断してほしいこと

これで担当者は、質問を最初から聞き直さずに済む。個人情報が含まれる場合は、引き継ぎ先と保存期間も決める。

Google Cloudの設計ガイドは、no-matchやWebhook失敗をイベントとして扱い、再質問、再試行、終了などの処理を用意することを勧めている。AIチャットボットでも、通常回答だけでなく、検索失敗、接続失敗、権限不足を別の状態として設計する。

仕様4：公開前のテストと合格条件を作る

「何件か質問して良さそうだった」は、受け入れテストにならない。

本番前には、実際の問い合わせをもとにテストセットを作る。正常な質問だけでなく、次の種類を混ぜる。

合格条件は、回答の正しさだけで決めない。

• 根拠の正しさ
• 対象外で止まれた割合
• 誤った断定の件数
• 人への引き継ぎ成功率
• 回答までの時間
• 担当者が修正した箇所数

重要な質問には、平均点とは別に失格条件を置く。たとえば「権限外情報を1件でも回答したら不合格」「根拠なしで申請可否を断定したら不合格」とする。重大な失敗を、他の正答で相殺しないためだ。

評価の考え方は、AIエージェントの評価設計でも詳しく整理している。試作時のテストセットを保存しておけば、文書やモデルを更新した後の回帰テストにも使える。

仕様5：公開後の改善ループを決める

公開日は完成日ではない。実際の質問が集まり、改善が始まる日である。

運用では、少なくとも次の指標を確認する。

• 利用者数と質問数
• 自己解決率
• 人への引き継ぎ率
• 根拠なし回答の件数
• 対象外質問の上位
• 低評価回答の上位
• 参照されない文書、頻繁に参照される文書
• 回答後に担当部署へ再問い合わせされた件数

数字だけでなく、改善の担当と頻度を決める。

問い合わせをそのまま知識源へ追加するのは避ける。利用者の誤解や個人情報が混ざるからだ。未解決質問を確認し、正式な規程やFAQへ反映してから読み込ませる。

生成AIのPoCを本番運用につなげる条件でも触れたように、技術指標と業務指標は分けて持つ。回答精度が上がっても、担当者への問い合わせが減らなければ目的は達成していない。

5つの仕様を一枚にまとめる

AIチャットボットの作り方を、成果物で並べると次の形になる。

この5点が揃っていれば、ツールやモデルが変わっても要件を引き継げる。逆に、会話画面とプロンプトしか残っていないと、担当者が変わるたびに設計意図を推測することになる。

構築基盤を比べるときは、この5仕様を共通シナリオとして候補へ渡す。AIエージェントの比較で見る6つの条件のように、権限、評価、運用、出口まで同じ条件で比べると、機能数だけの選定を避けられる。

費用を見積もる際も同じだ。AIチャットボットの費用を決める5項目と照らすと、知識整備、連携、評価、運用に必要な作業が見えやすい。

AIチャットボットは、答える仕組みだけでは業務に定着しない。答えてよい範囲、根拠、人へ戻す条件、合格基準、改善責任を仕様にして、初めて運用できる。

株式会社Atsumellでは、問い合わせ業務の整理から知識源、引き継ぎ、評価、運用を含むAIチャットボットの要件定義と構築を支援している。自社の問い合わせ履歴を5つの仕様へ変えたい場合は、お問い合わせから相談してほしい。

関連記事

• AIチャットボットの費用は5項目で決まる
• AIエージェントに「文脈」を渡す技術 — 仕様書の構造がすべてを決める
• ER図の書き方｜業務ルールから作る5ステップ