お疲れ様です。tkmiです。
最近、AIがずいぶん身近になってきたと感じています。
外部サービスなどの調べものをしている時には、その外部サービスが用意している、AIチャットボットを使うようになりました。
企業においてもAIを使ったシステム開発を行うことも増えたと思います。
最初に導入しやすいものとしては、やはりAIチャットボットがハードルが低いと思います。
今回はDifyを使ったAIチャットボットの作り方について解説していきたいと思います。
Dify でチャットボットを構築するにあたり、まずはチャットボットとは？というところから説明したいと思います。
チャットボットとは（概要）
基本構造：入力 → 処理 → 出力
チャットボットは、シンプルに分解すると次の 3 つのステップで構成されます。
入力（ユーザーからのメッセージ）
ユーザーがテキストやボタン操作などで問い合わせを行う部分です。
処理（意図の理解・情報取得・アクション）
ユーザーの意図を判断し、必要に応じて社内ナレッジや外部システムにアクセスします。
出力（応答メッセージの生成）
LLM などを用いて、ユーザーに返す回答文や次のアクションを提示します。
AIが広く利用されるようになる以前よりチャットボットは存在していましたが、決めたルールに当てはめることしかできませんでした。
生成AIを組み合わせることにより、ユーザーの意図を判断して必要な情報を探し、柔軟に回答を生成することができるようになりました。
設計について
次に「実装に入る前の設計」をどのように整理したかを解説します。
最近は、LLM（大規模言語モデル）を前提としたチャットボット構築が一般的になりつつありますが、LLM の性能に頼るだけでは、業務で使えるボットにはなりません。
どのような目的で、誰のために、どのような構成でボットを設計するかが、安定した運用・コスト最適化の観点からも重要です。
今回は、Dify の「知識検索ベース」のチャットボット機能を題材に、設計時に整理しておきたいポイントを UI イメージに近い形でご紹介します。
LLM 前提の時代になっても「設計」が重要な理由
近年は ChatGPT をはじめとした LLM の普及により、「とりあえず LLM につなげば何とかなる」という印象を持たれがちです。しかし、実際の業務シナリオでは次のような観点が欠かせません。
- どの情報をもとに回答させるのか（社内ドキュメント・製品マニュアル・FAQ など）
- 回答の正確性・再現性をどのレベルで担保するか
- 誰がどの場面で使い、どこまで自動化して良いか
- 障害時・誤回答時のエスカレーションフロー
これらはすべて「設計」の範囲です。LLM はあくまで応答生成のエンジンであり、ボットとしての振る舞いや責任範囲を定義することが、プロダクション運用では不可欠です。
チャットボットの基本構成
ここでは、典型的な LLM ベースのチャットボット構成を UI 的な視点で分解してみます。
1. 入力（ユーザーインターフェース）
- Web サイトのチャットウィジェット
- 社内ポータルのチャット画面
- LINE・Teams・Slack などのメッセージングアプリ
ユーザーはここから自然言語で質問を投げかけます。UI 設計としては、以下のような要素が重要です。
- プレースホルダー文（例：「お困りごとを入力してください」）
- よくある質問のショートカットボタン
- 利用上の注意・免責の表示
2. 意図判断（インテント判定）
入力されたテキストが 「どの種類の問いか」 を分類するステップです。
- 問い合わせ内容のカテゴリ分け
例：請求に関する質問 / 技術的なトラブル / アカウント手続き - 雑談か業務質問かの判定
- クリティカル度合い（緊急度）の推定
UI の観点では、ユーザーには見えない処理ですが、後段のフロー（人間オペレーターへの切り替えなど）に影響します。
3. 知識参照（RAG など）
RAG（Retrieval Augmented Generation：検索拡張生成）とは、LLM が社内のナレッジベースやドキュメントを検索し、その結果をもとに回答するアーキテクチャです。
- 社内ドキュメント・マニュアル・FAQ などのインデックス化
- ユーザーの質問に関連する文書の検索
- 検索結果を LLM へのプロンプトに埋め込む
UI としては以下の表現が考えられます。
- 「この回答は社内マニュアル ver.x.x をもとに生成しています」といった出典表示
- 関連ドキュメントへのリンク表示
- 「回答はお役に立ちましたか？」のフィードバックボタン
4. 応答生成（LLM）
検索で取得した情報を踏まえて、LLM が自然な日本語で回答を生成します。
- トーン＆マナーの調整（敬語・社内向け・外部向け等）
- ポリシーに反する回答の抑制（コンプライアンス遵守）
- 重要な数値や手順は箇条書きで整理するなどのフォーマット統一
UI 上は、ユーザーが読みやすい形で整形されたテキストとして表示されます。
5. 必要に応じたアクション実行
ボットが外部システムと連携して実行する処理です。
- チケット発行（サポートシステムとの連携）
- 見積依頼フォームの自動起票
- サーバー状態の確認、ジョブ実行 など
UI 例：
- 「この内容で問い合わせチケットを作成しますか？」という確認ダイアログ
- 実行結果の通知メッセージ
どんなボットを作るかを最初に決める
1. 何を解決するボットか
まずは、以下を具体的に定義します。
- 解決したい業務課題
例：一次問い合わせ対応の工数削減、社内問い合わせの平準化、深夜帯の自動応答 - 成功指標（KPI）
例：オペレーター対応件数の削減率、平均応答時間、ユーザー満足度
2. 対象ユーザー
- 社外のお客様向けか、社内メンバー向けか
- IT リテラシーのレベル
- 想定される利用シーン（PC メインか、スマートフォンメインか）
3. ユースケース
利用シナリオを具体的に洗い出します。
- サーバー障害時の一次切り分け Q&A
- 契約・請求に関するよくある質問
- 社内のシステム利用手順の確認
ここを曖昧にしたまま実装に入ると、
「何でも答えようとして中途半端なボット」になり、運用段階で破綻しがちです。
Dify のように手軽なツールであっても、設計フェーズでの線引きが重要です。
構成パターンの整理
チャットボットの構成パターンは、大きく次の 3 つに分類できます。
1. FAQ 型
- あらかじめ登録した「質問と回答」のペアから、最も近いものを返す方式
- シンプルで実装しやすく、挙動も読みやすい
- 想定外の質問には弱いが、内容のコントロールはしやすい
2. シナリオ型
- 対話の流れをフローチャートのように事前設計する方式
- 例：
「問い合わせ種別を聞く → 契約 / 技術 / 請求 から選択 → 詳細を深掘り」 - フローに沿った案内が得意で、手続きの自動化に向いている
- 分岐が増えると設計・保守コストが増大しやすい
3. RAG 型（検索拡張生成）
- 社内ドキュメントやナレッジベースを検索し、その内容をもとに LLM が回答する方式
- ドキュメントの更新に追随しやすく、汎用性が高い
- ナレッジの構造化や検索精度の設計が品質を左右する
今回採用した構成：Dify の RAG 型チャットボット
本記事で取り上げているケースでは、Dify の「知識検索ベース」のチャットボット機能を利用しており、これは RAG 型に分類されます。
- 社内のナレッジ（マニュアル、手順書、FAQ など）を Dify に登録
- ユーザーの質問に対して関連文書を検索
- 検索結果をもとに LLM が回答を生成
Dify では、この一連の流れを比較的少ない設定で実現できますが、
どのドキュメントをどのような粒度で登録するか、回答トーンをどうするか、といった設計はツールの外側で検討する必要があります。
コストを意識した設計
LLM は従量課金が基本
LLM を利用する場合、多くのサービスがトークン数（文字数に相当）に応じた 従量課金 となっています。そのため、以下のような要素がコストに直結します。
- 1 回の対話で送信するテキスト量（プロンプト + コンテキスト）
- 1 セッションあたりの発話回数
- 同時接続ユーザー数
無駄な呼び出しを減らす工夫
設計段階で、次のような工夫を検討できます。
- 不要な履歴を毎回 LLM に送らない
- 明らかに定型的な応答は LLM を使わずに返す（例：「営業時間」「電話番号」など）
- ナレッジ検索の絞り込み条件を適切に設計し、無関係な情報を送らない
設計段階で考えるべきポイント
- どのユースケースに LLM を使い、どこをルールベースで処理するか
- 応答の最大文字数・履歴の保持ポリシー
- 突発的なアクセス増加（キャンペーン等）があった場合のコスト上限
これらは、インフラコストや運用コストの見積もりにも直結するため、初期設計時に押さえておきたいポイントです。
詳細なコスト最適化の手法については、次回の記事で掘り下げます。
まとめ
チャットボットは「入力 → 意図判断 → 知識参照 → 応答生成 → アクション」という構造で整理すると設計しやすくなります。
LLM 前提の時代であっても、「どんな課題を、誰に対して、どのユースケースで解決するボットか」を明確にすることが不可欠です。
FAQ 型・シナリオ型・RAG 型という 3 つのパターンを押さえたうえで、自社の課題に合った構成を選択する必要があります。
Dify は RAG 型チャットボットを比較的容易に構築できる実装ツールですが、「どのナレッジをどう使うか」「どこまで自動化するか」といった設計は別途検討が必要です。
LLM 利用は従量課金が一般的なため、設計段階からトークン量や呼び出し頻度を意識したアーキテクチャにしておくことで、後のコスト最適化がスムーズになります。
次回は、Dify を用いた具体的な構成例と、コストを抑えながら品質を確保するための設計パターンについて、より踏み込んでご紹介します。
