Portfolioはじめに
「この問い合わせ、前にも同じようなのがあったはずだけど、どう対応したっけ？」
カスタマーサポートの現場では、こういった場面が日常的に発生します。ベテラン社員なら経験で対応できても、新人には難しい。社内Wikiにマニュアルはあるけれど、「どこに書いてあるか分からない」「検索しても見つからない」——そんな課題を抱えている企業は少なくないのではないでしょうか。
この記事では、社内WikiとAIチャットを連携させて、「誰でも同じ品質の対応」を実現するプロジェクトの全体像をご紹介します。Vercel Neonデータベースを活用し、RAG（検索拡張生成）ベースのAIアシスタントを構築した事例です。
プロジェクトの背景と課題
属人化の問題
カスタマーサポート業務では、以下のような属人化の問題が発生しがちです。
| 課題 | 具体的な状況 |
|---|---|
| ベテラン依存 | 経験の長い社員にしか分からない対応ノウハウが存在 |
| 都度確認の発生 | 新人が「この場合どう対応すればいい？」と毎回ベテランに聞く必要がある |
| マニュアルの形骸化 | 社内Wikiはあるが、「どこに書いてあるか分からない」「検索しても見つからない」 |
情報の分散
さらに問題を複雑にしているのが、情報の分散です。
- 対応マニュアル：社内Wiki
- 過去の対応履歴：スプレッドシート
- 見積データ・商品マスタ：別のスプレッドシート
それぞれ別の場所にあり、横断検索ができません。「この問い合わせに対して、過去にどう対応したか」を調べるには、複数のツールを行き来する必要がありました。
理想の状態
このプロジェクトで目指したのは、以下のような状態です。
「こういう問い合わせが来たんだけど、どう対応すればいい？」
過去の対応事例とマニュアルを自動で検索
参照元リンク付きで対応方針を提案
テンプレート形式の返信文案をそのままコピペ可能
解決アプローチ：RAGシステムの採用
なぜRAGを選んだのか
「ChatGPTを使えばいいのでは？」と思われるかもしれません。しかし、単純にChatGPTを使うだけでは、業務利用には不十分な点があります。
| アプローチ | メリット | デメリット |
|---|---|---|
| ChatGPTをそのまま使う | 手軽に始められる | 社内情報を知らない、ハルシネーション（嘘を言う）のリスク |
| RAG（検索拡張生成） | 社内データを根拠に回答、参照元を示せる | 初期構築に手間がかかる |
業務で使うには、「根拠を示せる」ことが重要です。AIが「たぶんこうです」と言うのではなく、「このマニュアルのこの部分に書いてあります」「過去にこういう対応事例があります」と、参照元を明示できる必要があります。
データソースの統合
このプロジェクトでは、複数のデータソースを1つのデータベースに統合しました。
| データソース | 内容 |
|---|---|
| FAQ（手動整備） | 対応マニュアルを整理したもの |
| FAQ（PDF抽出） | 既存のPDFマニュアルから抽出 |
| 対応履歴 | 過去の実際の問い合わせと対応事例（数千件） |
| 見積データ | サービス内容と目安価格 |
| 商品マスタ | 品番・商品名などの基本情報 |
| 製品適合情報 | モデル別の適合データ |
これらを同じテーブルに格納することで、1回の検索で全データを横断できるようになりました。質問の内容に応じて、最適な情報が自動で選ばれます。
システム構成
全体アーキテクチャ
マニュアル・FAQ
対応履歴・各種データ
ベクトル検索対応DB
全ページで利用可能
技術選定のポイント
| コンポーネント | 選定理由 |
|---|---|
| Neon PostgreSQL + pgvector | ベクトル検索が可能なマネージドDB、Vercelとの親和性が高い |
| OpenAI Embedding API | 日本語の意味理解に優れる、コストも比較的低い |
| Next.js | 既存サイトとの統合が容易、API Routesでバックエンドも実装可能 |
実装で工夫したポイント
回答フォーマットの統一
AIの回答がバラバラだと使いにくいため、テンプレート形式を採用しました。
- 状況整理：前提確認
- 対応方針：結論を先に
- 確認すべき追加情報：足りない情報があれば質問
- 次アクション：優先度付きのToDoリスト
- 返信文案：そのままコピペ可能な文面
- 根拠：参照元リンク
このフォーマットにより、「結局どうすればいいの？」が一目で分かるようになりました。
差分同期によるコスト最適化
数千件以上のデータを毎回処理すると、時間もコストもかかります。そこで、コンテンツハッシュによる変更検知を実装しました。
| ケース | 処理時間 | API費用 |
|---|---|---|
| 変更なし | 数秒 | ほぼゼロ |
| フル処理 | 約10分 | 約$0.01 |
変更があったデータだけを再処理することで、日常的な運用コストを最小限に抑えています。
UIの設計と運用
全ページ共通チャットウィジェット
AIチャットは、どのページにいても質問できるウィジェット形式で実装しました。
- わざわざ「AIチャットページ」に移動しなくていい
- 今見ているページのURLが自動で送信される（文脈の理解に役立つ）
フレンドリーなデザイン
業務ツールは「使われてなんぼ」です。見た目の親しみやすさも重要なため、以下の工夫をしました。
- 明るいカラーテーマの採用
- アバターアイコンによる親しみやすさ
- 「AIサポートも使えます」の吹き出しで存在をアピール
免責事項と監査ログ
AIを業務で使う以上、透明性の確保も欠かせません。
- 「回答は必ずダブルチェックを」という注意書きを表示
- 全ての質問・回答を監査ログとして記録
- 記録されることを明示して透明性を確保
導入効果
Before / After
| 項目 | Before | After |
|---|---|---|
| 対応方針の確認 | ベテランに聞く / Wiki検索 | AIに質問するだけ |
| 過去事例の確認 | スプレッドシート内を手動検索 | AIが自動で引用 |
| 回答の根拠 | 「たぶんこう」 | リンク付きで明示 |
| 新人の立ち上がり | 数ヶ月かかることも | 初日から使える情報基盤 |
運用のしやすさ
データ更新は、月1回程度のコマンド実行だけで完了します。
- 技術者がいなくても運用可能
- 変更があったものだけ処理するため高速
- 監査ログからよくある質問を分析し、マニュアル改善に活用
今後の展望
短期的な改善
- 回答品質のモニタリングと継続的な改善
- よく使われる質問パターンの分析
- マニュアルの不足箇所の補完
中長期的な発展
- データ同期の自動化（現在は手動トリガー）
- 部署別のアクセス制御
- 多言語対応
まとめ
このプロジェクトの成功要因は、以下の3点に集約されます。
- 既存資産の活用：新しくマニュアルを作るのではなく、既存のWiki・対応履歴を活用
- 段階的な実装：まず動くものを作り、徐々に改善
- 運用のしやすさ：月1回のコマンド実行だけでデータ更新可能
AIは「魔法の箱」ではなく、「賢い検索エンジン」です。根拠のない回答は信用せず、最終判断は人間が行う——この原則を守りながら、AIを業務に活用することで、属人化の解消と対応品質の均一化を実現できます。