AI APIで回答を生成
公開仕様ではOpenAI APIとGemini APIを利用。FAQの自動応答や会話を、サービス内のAI機能として提供する。
01 / 課題から仕様・成果物へ要望を整理し、
要望を整理し、
確かめられる形に。
要望・設計上の問い
設計上の問い：AIで答える場面と人が対応する場面の間で、会話の文脈と担当状態をどうつなぐか。
要件・仕様に変える
会話ログと有人対応の受付・割当を分け、知識の取得状況も保存する。担当者不在、同時割当、取得失敗を確認条件にする。
設計判断を読む成果物で確かめる
公式の会話表示例・管理ガイドと、会話・有人対応・担当割当を保存するDB定義。OpenAI API・Gemini APIの利用は公開規約で確認できます。
実画面を見る
この事例の担当範囲
個人で企画し、生成AIを活用して設計・実装から本番公開まで担当。AI応答と有人対応をつなぐ画面・保存設計を紹介します。
使う人：Webサイト運営者 / 問い合わせ担当者 / サイト訪問者02 / 体験と処理の流れ画面の操作と、
画面の操作と、
裏側の処理をつなぐ。
画面の見どころ / 01
質問に、自然な言葉で答える。
- 01Webサイトに会話の入口を設置。
- 02AI応答と訪問者の発言を読み分けられるUI。
操作に対応する内部処理を読む
利用者の操作内部の処理
- 01
ボットを用意する
運営者がサイトとボットの設定を管理する。
内部の処理テナント・slugでボットを区別し、AI設定や許可オリジンを保持。
- 02
知識を取り込む
回答のもとになるWebサイト情報を登録する。
内部の処理URL・本文・内容ハッシュ・最終クロール日時・エラーを管理。
- 03
会話を残す
訪問者がボットに質問する。
内部の処理セッションとメッセージを分け、訪問者の要約記憶も保持する構造。
- 04
人へ引き継ぐ
必要な場面で担当者が対応する。
内部の処理会話モードと担当者、有人対応の待機状態・順番を分けて管理。
03 / AI・APIの役割AIが担う体験と、
AIが担う体験と、
APIの役割。
AIによる会話と、外部サービス連携
AIが質問に答え、 必要な会話を人へつなぐ。
- 01質問・サイトの知識
FAQ・ページ情報・会話の文脈
- 02AIが応答を生成
OpenAI API / Gemini API
- 03会話・担当者へ
履歴を残し、必要に応じて有人対応
AI・APIの役割と、確認できる範囲
Webサイトの知識と会話の文脈を使い、AIが自然な言葉で応答するチャットボット。AI APIと、知識管理・履歴・有人対応を組み合わせたサービスです。
回答の振る舞いを設定
DBではプロバイダー、モデル、カスタムプロンプト、禁止事項を管理。ボットの用途に合わせて応答方針を設定する構造。
生成したFAQを、人が確認
公式ガイドではURLの内容からFAQ候補をAIが生成し、人が編集・承認する流れを紹介。知識を更新する運用までを機能にする。
Slackへ引き継ぎを通知
公式ガイドではIncoming Webhookで有人引き継ぎ等を通知。DBにも送信イベント、応答ステータス、試行回数を保持する。
本番公開済みのサービスです。利用API・サービス機能は公開規約、設定・通知の関係はDB設計をもとに紹介しています。図は各処理の役割を示します。
04 / データのつながり体験を支える、
体験を支える、
データの関係。
- 質問と知識FAQ・サイト情報
- AI APIOpenAI・Gemini
- 会話と有人対応履歴と担当者を管理
AIの応答を、知識と運用のしくみで支える。
資料から整理した構成図データ項目と関連を詳しく見る
項目を選ぶと、そのデータにつながる関係を確認できます。
主要なデータの関係
外部キー キー・保存先messagessession_id接続先：sessionssessionstenant_id + config_slug / slug接続先：chatbot_configssite_knowledgeconfig_id接続先：chatbot_configslive_chat_sessionssession_id接続先：sessionsvisitor_memoriestenant_id + visitor_id接続先：sessions
実線は外部キー、破線は名前・キーによる関連です。破線の関係は、このダンプでは外部キー制約としては確認できません。
05 / 設計判断と制約その設計には、
その設計には、
理由と制約がある。
画面の先まで考える
1回の会話を追う情報と、訪問者を継続して理解する情報を、別の単位で扱える。
01会話履歴と、再訪時の記憶を分ける。
- しくみ
- 会話をsessions / messagesで扱い、visitor_memoriesには要約・重要事項・最終セッションを保存する。
- この構成でできること
- 1回の会話を追う情報と、訪問者を継続して理解する情報を、別の単位で扱える。
- 制約・考慮点
- 記憶の一意キーはテナントと訪問者。ボットごとの記憶分離、削除連動、要約の精度は動作確認が必要。
参照：aitolie.sql / visitor_memories
02人への引き継ぎを、受付の状態として持つ。
- しくみ
- 会話モードと担当者に加え、live_chat_sessionsで待機順や開始終了時刻を保持。
- この構成でできること
- 会話そのものと、誰がいつ対応するかを分けて管理できる。
- 制約・考慮点
- 担当者が切断した場合や同時割当で、会話側と受付側が食い違わないかはAPI側の確認が必要。
参照：aitolie.sql / sessions・live_chat_sessions
03知識の取得状況も、データにする。
- しくみ
- URL単位で本文・内容ハッシュ・最終クロール日時・エラーを保持する。
- この構成でできること
- 回答元の内容だけでなく、いつ取り込み、どこで失敗したかを追える。
- 制約・考慮点
- ハッシュを用いた更新処理や検索方式はSQLだけでは分からない。ベクトル検索や特定のRAG構成は断定しない。
参照：aitolie.sql / site_knowledge
06 / 場面ごとの動きこんなとき、
こんなとき、
どう動く？
AIから担当者へ、会話をどう引き継ぐ？
AI対応・担当者待ち・接続切れの3場面を紹介します。保存する情報から組み立てた説明で、実際にチャットが動くデモではありません。
下の状況を選ぶと、図や説明が切り替わります。
この例の結果
AIとのやり取りを、会話ごとに記録します。
一つひとつの発言を、同じ会話の中に保存します。訪問者についての要約は、会話の記録とは別に管理する構造です。
しくみと、実運用で確認したいこと
- AIが使う知識この例では完了・保持
- 会話の記録この例の注目点
- 担当者への引き継ぎこの例では未実施
- 会話側の項目
- chat_mode / visitor_id
- 発言の保存先
- messages → sessions
- 継続する文脈
- visitor_memories
実運用で確認したいこと別の訪問者の会話や要約が混ざらないかを確認します。
07 / 担当と次の検証担当したことと、
担当したことと、
今後の改善。
この作品で取り組んだこと
01
AIに任せる範囲を考える
AI応答から人による対応まで、利用者と担当者の両方の流れを整理する。
02
運用要件を具体化する
会話・知識管理・有人対応の仕様と画面構成を自分で整理。コード作成に生成AIを活用し、操作や処理の検証・改善まで担当する。
03
検証の観点を持つ
応答品質だけでなく、引き継ぎ、記憶の範囲、知識の更新を確認点として説明する。
掲載資料と確認できる範囲
画面で示せること
公開サービスの会話表示例と管理ガイドの画面です。ガイド用の強調表示を含み、画面内の数値はサンプルです。
DBで示せること
会話・記憶・知識・有人対応の保存項目を確認。担当割当と取得状態を手がかりに、引継ぎや知識更新の確認条件を説明できます。
AI・動作確認の範囲
本番環境へ公開済みです。利用APIはOpenAI API・Gemini API。掲載の図と条件切替デモでは、AI応答・有人対応・会話保存の役割を説明します。