はじめに
社内イベントやキャンペーンの “お楽しみツール” として、クライアントのモバイル／Webアプリに RAG（Retrieval‑Augmented Generation）チャットボット を組み込むケースが増えています。
しかし「検索＋生成」であるがゆえに、システムプロンプト――モデルに最初に渡す指示文――を書き間違えると、意図しない回答やポリシー違反を招きがちです。
本記事では、実際に RAG チャットボットを導入した際に痛感した 4 つの勘所 を共有します。
1. 「絶対に外せないこと」はシステムプロンプトで固定する
| 抑えるべき要素 | 具体例 | なぜ必要か |
|---|---|---|
| ボットの役割・人格 | 「あなたは○○会社の公式キャラクター“〇〇”として回答します」 | 一貫したトーン・スタイルを保証 |
| 対象ドメイン | 「回答は社内ナレッジベースと公開 FAQ から。個人的な意見は述べない」 | 専門外への脱線・幻覚を防ぐ |
| 禁止事項／NGワード | 「機密情報・顧客個人情報は出力しない」「✕✕という単語は使わない」 | コンプラ・ブランド保護 |
| フォールバック指示 | 「該当情報が見つからない場合は“お役に立てず申し訳ありません”と返す」 | 無根拠な推測を抑止 |
ポイント
- “柔らかい文章で”といったスタイル指定もここに書く
- プロンプトが長くなったら、JSON で構造化すると管理しやすい
2. 回答ロジックは「まず RAG」――ベースラインを決める
-
検索 → 要約 → 合成 を明示
# 内部フロー 1. クエリをエンコードしてベクトル検索 2. 上位 N 件を抜粋 3. 抜粋内容を Markdown 箇条書きで要約 4. 要約を下敷きにユーザ向け回答を生成 -
メタデータで優先度付け（投稿日時・タグ・信頼度スコアなど）
-
“回答の根拠”を明示：「必ず
<ref>タグで出典 URL を付ける」 -
検索失敗時のフォールバック：「分かりません」と正直に返す → 幻覚防止
3. セーフティの視点――ガードレールは多層で
| レイヤ | 実装例 | 役割 |
|---|---|---|
| 前処理 | ユーザ入力の Profanity / PII フィルタ | “危ない質問”を入口でブロック |
| 生成中 | OpenAI / Anthropic の safe completion モード | ヘイト・暴言・性的表現の自動抑制 |
| 後処理 | RegEx / ルールベース再検査 | 出力テキストから NG ワードを最終除去 |
| 監査ログ | 質問・回答・ベクトル ID を全保存 | 事後レビュー & モデル改善に必須 |
追加で忘れがちなのが レートリミット／コスト制御。
スパイク時は RAG 検索をキャッシュし、モデル呼び出しをキューイングすると安心です。
4. クライアントの「期待値コントロール」――実装前後でギャップを潰す
| フェーズ | やること | ありがちな落とし穴 |
|---|---|---|
| キックオフ | できること／できないこと を明文化（例：FAQ 対応のみ・専門外は回答しない） | 「AI なら何でも答えられる」と誤解されがち |
| プロトタイプ | 実際のナレッジで動くデモ を早期提供 | デモなしだと「完成品も完璧」と思われやすい |
| 運用設計 | ヒット率・応答品質の KPI を共有し、初期はベータ扱いと宣言 | 100 % 正答を求められて炎上 |
| UI/UX | “答えが見つからない場合”の文言を相談して決める | 404 的メッセージが冷たく見える |
| 継続改善 | ログ分析 → ナレッジ追加サイクルを契約に組み込む | 納品後に改善予算が取れず品質が停滞 |
ポイント
- 「RAG は検索エンジン＋要約」であって万能 AI ではないと強調
- “ベータ版で学習しながら改善”という 成長型プロダクト の考え方を共有
- KPI は「回答採用率」「ユーザ CS スコア」など人間の評価指標も混ぜると伝わりやすい
まとめ
- システムプロンプトは“契約書”――ボットの人格・範囲・NG を明示
- 回答は RAG が軸――検索結果を第一ソースに、失敗すれば丁寧にフォールバック
- セーフティは多層防御で――前→中→後処理＋監査ログ
- クライアントの期待値コントロールを最初に――“万能ではない”ことを合意し、改善サイクルまで設計
これらを押さえると、ユーザ体験とリスク管理を両立した RAG チャットボットを素早く、そして長期的にも健全に運用できます。