「Air ビジネスツールズ」のクライアントサポートにおける生成 AI 活用

2026/2/27に、RECRUIT TECH CONFERENCE 2026で発表した金田の資料になります。

Transcript

1. RECRUIT TECH CONFERENCE 2026 開発とPM視点で語る、カスタマー／クライアントサポートの進化 No Code 開発と自動評価パイプラインで回す、高速な改善サイクルと高品質な AI エージェント運用 「Air ビジネスツールズ」の クライアントサポートにおける生成 AI 活用 データ推進室 金田 拓
2. 2021 年にリクルートにキャリア入社。 入社以来、社内向けのデータ基盤の開発・運用に従事。 主に Notebook 基盤の新規開発や FinOps の推進を担 当。 直近では、「Air ビジネスツールズ」の FAQ チャット ボットの構築や、「Geppo」 のデータパイプラインの整 備を進める。 金田 拓 ランニング・筋トレ・フットサル・スポーツ観戦(⚽🎾🏀🏎) 読書・映画鑑賞 経歴 / Career 趣味 / Hobbies データ推進室 データテクノロジーユニット データプロダクトマネジメント２部 データプロダクトエンジニアリング１グループ
3. Agenda 1. 「Air ビジネスツールズ」とは 2. 背景と課題 3. 技術選定 4. アーキテクチャ設計・構築 5. 安全性・性能評価 6. 運用改善とまとめ
4. 「Air ビジネスツールズ (ABT)」 とは？ 「商うを、自由に。」 ひとつの AirID で、お店のあらゆる業務を効率 化する業務支援サービス群 • フロント業務: 予約管理、レジ、決済 • バックヤード業務: シフト管理、給与計 算、採用 • 経営支援: 資金調達、経営状況の可視化 データが連携し、事業の成長を加速させるプ ラットフォームを提供 https://airregi.jp/brand/ より引用
5. 背景：クライアントサポートの課題 利用者の増加に比例し問い合わせが増加！従来のサポート体制が限界に 💰 コストの増大 アカウント数に比例してサポー トコストが増加傾向にある。 💥 分断された体験 プロダクトごとに窓口（電話・ チャット）が異なり、ユーザー 体験が一貫していない。 ⚠ 旧来 Bot の限界 FAQ 記事の URL を提示するだ けの「検索エンジン」止まり。 自己解決に至らない。
6. ゴール:『解決を手元に』届ける 目指す姿 ユーザーが「探す」から「解決する」へ 困ったとき、FAQを探し回ることなく、すぐに・簡単に・ 確実に解決できる「真の自己解決」体験の実現 KGI (重要目標達成指標) 有人ヘルプデスクへの 問い合わせ率削減 手段: 生成 AI による「対話型」チャットサービス • FAQ 記事の URL を返すのではなく、AI が文脈を理解 し、最適な答えを生成・提示 • サポートの「AI 対応率の最大化*」を目指す *最終的には人間が品質を担保し、必要に応じて判断・介入を行います
7. 技術選定: Conversational Agents※ 開発スピードとコスト、性能のバランスから No Code (Conversational Agents※) を採用 ⚡開発スピード ほぼノーコードで構築可能なた め、デリバリーまでが高速。 PDCA サイクルを迅速に回せ る。 🔍 RAG 性能 検索 (Retrieval) の性能がプロダ クトの肝。標準機能で高品質な RAG が実現可能。 ⚙ 拡張性 サーバーレスでスケーラブル。 将来的な電話対応 (CCAI) への 拡張も見込める。 ※ Conversational Agents: Google Cloud が提供する、no/low code で会話型 AI エージェントを構築・実行できるフルマネージドサービス
8. アーキテクチャ：BFF パターンによる制御 Cloud Load Balancing Cloud Armor Cloud Run Conversational Agents Cloud Logging BigQuery Playbook Tools (Data Store) Cloud Storage Bucket Zendesk Cloud Run job Cloud Scheduler FAQ データ (html) Conversational Agents Details • FAQ データ(Zendesk) を Cloud Scheduler & Cloud Run job で毎日同期 • 常に最新の情報を RAG で参照可能に Cloud Run (BFF) の役割 データ連携 • 前・後処理: ユーザー入力の正規化やレスポンスの整形 • 変更容易性: モデルの変更や A/B テストが簡単に実現 可能に
9. 設計のポイント：Playbook と Data Store Playbook (Agent の挙動制御) Conversational Agents の中核設定 Data Store (知識ベース) チャットボットの回答品質は、投入するデータに依存！ • 社内組織との連携: クライアントサポート組織と協 力し、FAQ記事の内容を精査 • データ前処理: 「限定公開記事」や「過去のキャン ペーン」など、回答に適さない情報を除外する処 理を実装 Goal: このPlaybookで達成したいゴールを定義 Instructions: Markdownリスト形式で詳細な指示 を記述 Examples: 良い回答/悪い回答の例（Few-shot を 与えることで、回答精度を大幅に向上
10. • 一般的リスク: ヘイトスピーチ、危険なコン テンツなど • ビジネス固有リスク: ◦ サービス範囲外の応答 ◦ 権限を超えた約束（返金・値引き対応など） ◦ 不適切な責任転換や反論 安全性評価：ビジネス固有リスクへの対策 ユーザー入力起点の脅威に加え、ビジネス固有のリスクを独自に定義 リスクの分類 対策と評価サイクル 対策: • Prompt Security によるインジェクション対策 • Safety Filter によるブロック • プロンプト調整 評価: • リリースごとに独自のテストケースを用いて回 帰テストを実施し、不適切な回答を未然に防止
11. 性能評価システム：BigQuery ML × RAGAS 評価観点 チャットボットの品質を保証するため、LLM (BigQuery ML) による自動評価で 5 つの観点を測定 会話のターン単位での評価 • 忠実性 (Faithfulness): ハルシネーション検知 • 関連性 (Relevance): 無関係情報の排除 • 検索結果有用性 (Search Results Usefulness): RAG 精度の確認 • 検索実施率 (Search Execution Rate): 必要な時に 検索したか 会話全体での評価 • 解決率 (Resolution Rate): 総合的な品質指標 RAGAS ベースの評価パイプライン 評価の仕組み: • データ取得 : 会話ログと検索元のドキュメント (FAQ) を取得 • 主張の抽出 : LLM の回答を、意味のある最小単位「主張 (claim)」に LLM で分解 • 自動判定 : 「主張」一つひとつが評価観点を満たすか LLM に て判定 • 集計・可視化 : 結果の集計と、全体の品質を定量的に把握 判定プロセス: これら複数の指標を総合的に判断し、リリース可否を決定する dbt + BigQuery ML による性能評価パイプライン
12. 運用と改善サイクル Looker Studio でのモニタリング KGI/KPI の推移や、低評価だった会話ログをダッ シュボードで可視化。関係者全員が状況を把握で きるように。 改善事例: FAQ 返却率の向上 リリース当初、参考 FAQ 記事を含む回答率が想 定を下回る。 ✅対応策 • Instruction (プロンプト) の修正 • 「FAQ 返却率」という指標も追加
13. 導入効果：KGIの達成 KGI: 有人ヘルプデスク問い合わせ率 リリース後、改善施策（プロンプト調整、パラメータ 変更）を経て、目標値を下回る問い合わせ率を実現。 Project 目標値 ✔ 実施した改善一例 • UI 変更 • プロンプト改修 (前述) • パラメータ変更 • 「よくある質問ボタン」の追加 高速なデリバリー 開発期間: 約 6 ヶ月 (5 人月) • 評価・安全性開発: 2 人月 • API・ボット開発: 1.5 人月 • インフラ・ジョブ開発: 1.5 人月
14. 成果とまとめ 🏆 成果 半年という短い開発期間で、KGI で ある「有人ヘルプデスクへの問い合 わせ率」を大幅に削減し、目標を達 成中。 🔑 成功要因 No Code ツールによる開発生産性 の向上、ビジネス要件に踏み込ん だ安全性設計、自動評価システム の構築。 ⏩ 今後の展望 他プロダクトへの横展開。ユー ザー情報を連携したパーソナライ ズの強化。