AIチャットボット開発の進め方/やり方/流れや方法/手法/工程/手順

AIチャットボットの開発は、回答範囲と正答例を決めてから、資料の整備、検索、回答生成へと進み、権限と有人対応の試験で仕上げます。チャット画面が動いた段階では、公開の判断はできません。

社内文書を参照するRAG型を例に、工程ごとの確認事項を説明します。登録FAQやシナリオを併用する場合も、評価問題を先に用意します。

工程1:回答する質問と評価問題の決定

回答方針を回答する・聞き返す・移管するの3つに分けた図
根拠の有無や質問条件が振り分けの目印になります。

対象部署と回答の責任者

初期版では、範囲を「情報システムの利用案内」などに絞ります。なお、規程の解釈や個別の承認判断を含めるかは、業務責任者が決めます。

回答方針は、「回答する」「聞き返す」「移管する」に分けて定めます。

  • 回答する:正式なマニュアルで裏付けられる手順。
  • 聞き返す:端末や利用者区分など、必要条件が足りない質問。
  • 移管する:例外申請、個別障害、資料に根拠がない相談。

たとえば「接続できない」という質問だけでは、ネットワークか業務アプリかを判別できません。そのため、最初に利用環境を聞く会話を用意し、何でも一度に回答させないようにします。

実際の問い合わせを使った試験問題

過去の問い合わせを匿名化したうえで、正答、必要な根拠、許容しない回答を用意します。表記ゆれや省略、複数の条件を含む質問も試験に入れます。

資料にない質問と権限外の質問は、必ず試験に含めます。さらに、評価用の問題の一部は調整に使わずに残し、修正後も未知の質問で性能を確認できるようにします。

ポイント

回答してよいかは、正式なマニュアルで裏付けられるかで判断します。根拠のない相談や例外申請は移管に回し、端末や利用者区分が足りない質問は聞き返します。

工程2:文書の検索可能な形への整備

正本と旧版の整理

同じ手順の旧版が混ざると、検索自体は成功しても間違った案内につながります。そのため、正式な資料と管理者を決め、適用開始日や利用対象を記録します。

文書ごとの付帯情報は、回答の条件と閲覧の範囲を判断できるように整理します。

  • 出典:文書名、参照URL、版、更新日。
  • 適用条件:対象部署、サービス、地域、利用者区分。
  • 権限:誰が本文と回答を閲覧できるか。

また、PDFの表や画像は、読取り結果を目視で確認します。表の列見出しと条件が離れると、金額や申請条件を別の行に結び付ける原因になります。

分割した文書の意味の保持

RAGでは、検索しやすい単位に文書を分けます。ただし、文字数だけで切ると、各条件や例外が手順と切り離され、一緒に解釈できなくなります。そこで、分けた後の文が、見出しや条件、例外とともに読めるかを確かめます。

MicrosoftのRAG解説では、検索方式と索引の設計を扱っています。検索では、型番などの完全一致と意味の近さを、質問に応じて使い分けます。

ポイント

正本と旧版の整理は、検索の前に済ませておきます。文書を分けるときは、文字数ではなく、条件や例外が手順から離れていないかで判断します。

工程3:検索と回答生成の切り分け

検索品質と回答根拠の整合性を左右で比べる図
検索結果の確認と回答条件の照合は別々の評価になります。

正しい資料が見つかるかの確認

回答文を調整する前に、評価問題に対して必要な資料が検索で出てくるかを確かめます。該当する資料が出てこなければ、モデルへの指示だけを変えても解決しません。

検索が外れる原因は、どこにあるかで切り分けます。

  • 資料不足:正式な回答根拠が登録されていない。
  • 検索不一致:略称や言い換えを拾えていない。
  • 分割不良:検索箇所に条件や例外が含まれていない。

検索の結果と順位を記録し、改善の前後で同じ問題を比べます。ただし、必要以上に多くの資料を渡すと、無関係な条件が回答に混ざることもあります。

根拠の提示と、不足時の回答停止

生成処理には、確認できた情報で回答し、条件が足りなければ聞き返すという方針を与えます。そのうえで、回答には参照文書を示し、利用者が原文を確認できるようにします。

正答かどうかは、回答の各条件が参照箇所と一致しているかで決まります。なお、参照リンクが付いているだけでは、正答の証明にはなりません。その一致を、人が確認できる評価記録として残します。

MicrosoftのRAG評価も、検索品質と回答の根拠の整合性を分けて扱っています。原因ごとに直すと、改善が再現しやすくなります。

ポイント

回答文を直す前に、評価問題で正しい資料が検索されるかを確かめます。根拠は、回答の各条件が参照箇所と一致するかを人が確認し、評価記録に残します。

工程4:権限と有人対応を含めた公開判定

文書を中心に別部署・異動や退職・共有端末の権限試験を示す図
利用状況が変わる場面も検索権限の確認対象です。

利用者ごとの検索対象の制御

ログインしているかどうかだけでなく、文書を読む権限を検索の時点で適用します。生成が済んでから注意文を出す方式では、モデルに渡した機密情報を守り切れません。

Azure AI Searchのアクセス制御は、ユーザーやグループに応じて検索結果を制御する方法を説明しています。そこで、採用している基盤に合う方式を実装します。

権限の試験では、正常な利用以外の状態も確かめます。

  • 別部署:参照できない文書の本文や要約が出ないか。
  • 異動・退職:権限変更が検索と会話履歴に反映されるか。
  • 共有端末:前の利用者の会話やキャッシュが残らないか。

有人移管と更新後の再試験

回答できないときや利用者が希望したときに、人へつなぐ導線を用意します。その際は、会話、聞き取った条件、未解決の内容を渡し、受付完了を表示します。

加えて、公開前には、担当者が不在の場合や受付システムに障害が起きた場合も試しておきます。転送したつもりで相談が消えてしまう状態を防ぐため、受付番号や代替窓口を利用者が確認できるようにします。

限定公開の結果を見て、対象を広げていきます。文書・モデル・検索設定を変えたときは、同じ評価問題で再試験し、悪化していれば前の設定へ戻せるようにします。

ポイント

公開の判断は、権限の試験と有人移管の試験がそろってから行います。限定公開で対象を広げた後も、設定を変えたら同じ評価問題で再試験します。

まとめ

チャットボットの開発は、評価問題を用意し、資料、検索、回答を順につなげて、窓口の運用へと進めます。各工程の結果を記録しておくと、答えられない原因がどこにあるかを切り分けて改善できます。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。