問い合わせ自動化の技術的挑戦

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

Transcript

1. RECRUIT TECH CONFERENCE 2026 開発とPM視点で語る、カスタマー／クライアントサポートの進化 問い合わせ自動化の 技術的挑戦 LLMと人の協働による課題解決のアプローチ Megagon Labs / データ推進室 山下 雄大
2. 2016年にリクルートホールディングスへ入社。データサ イエンティストとして、『タウンワーク』などアルバイ ト領域のデータ開発に従事。 独立後、スタートアップの立ち上げおよびサービス開発 を経験し、2022年にリクルートへ再入社。 自然言語処理を中心としたAI研究組織Megagon Labsの TPMとして、AIプロジェクトの技術リーダーとして開発 を推進。 Webアクセシビリティ改善にAIを活用した取り組みが、 リクルートのナレッジ共有イベント（FORUM）に選出 される。 山下 雄大 ゲーム・紅茶 経歴 / Career 趣味 / Hobbies データ推進室 データテクノロジーユニット イノベーティブテクノロジー研究戦略部 Ｍｅｇａｇｏｎグループ
3. 1. 問い合わせ自動対応の必要性 2. 自動化の技術的な難しさと困難要因 3. アプローチ方針の設計 4. 解決策の具体化 5. まとめ Agenda
4. 如何に 「素早く」「正確」に解決へ導けるか? 多くの問い合わせに至るユーザーは、 • 問題発生への “不安” • 早期解決を求める “焦り” などの負の感情を抱いている。 問い合わせ自動化の必要性 多くのユーザーにとって、問い合わせとは「早く脱したいネガティブな状態」 ? ? ? エラーが出る 解決しない... ログインできない
5. 問い合わせ自動化の必要性 様々な理由から全てを人手で即時解決することには「構造的な限界」がある 予測困難なトレンド どれだけの問い合わせが いつ来るかを正確に予測 することは困難であり、 最適な人材配置は困難。 24/365の維持 対応品質維持・向上 深夜・休日を含めた完全 な有人体制の維持は、 様々なコスト観点から極 めて困難。 問い合わせに適切に対応 できる高スキル人材の確 保は、採用・教育の両観 点で難易度が高い。
6. 問い合わせ自動化の必要性 だからこそ、システムによる「自動応答」の活用が不可欠 柔軟なScalability 予測できない問い合わせ の急増であっても、リ ソースの増強で対応が可 能。 24/365の完全稼働 品質均一化と高速化 システムは休憩が不要で あるため、深夜・休日問 わず、ユーザーが待つこ となく応答が可能。 モデルが完成すれば、品 質維持が一定期間可能。 高い品質のまま、対応ス ピード向上が可能に。
7. 取り消しではなく、ずらした場合に手数料がか かるか知りたい。 自動化の技術的な難しさと困難要因 従来のシナリオ・ルールベースでは、対応シナリオが限定される。 分岐の複雑性 1つの問題解決に膨大な条件分岐が必要。 例外処理が増え、修正困難なスパゲッティ状態に。 キーワード依存の限界 同義語や多義語に弱く、 少しの言い回しで解決できない状態が頻発。 管理・運用コストの限界 サービス改修のたびに膨大な工数が発生し、 有人対応に戻るリスクが増加。 明日の便が欠航になったので、予約を1日ずら したい。手数料はかかりますか？ 「予約変更」ですね。お手続きを 1.新規、2.取消から選択してください。 すみません。よくわかりませんでした。
8. 自動化の技術的な難しさと困難要因 言語モデルの進化で、「単語検索」から「文脈」を捉える対話へ。 従来の仕組み LLM活用 　文脈から「意図」を抽出 　知識・文脈に基づき動的に回答生成 　キーワード一致に依存 　条件分岐の網羅性で対応 インプット → キーワード一致 → 定型文 インプット → 文脈・意図の理解 → 動的回答
9. 自動化の技術的な難しさと困難要因 LLMは強力な技術だが万能薬ではない 誤った案内 情報過多 予約変更の基本ルール 日程・人数・部屋タイプの直接変更は できない 多くの場合は 「一度キャンセル → 取り直し」 が必要 ※ 例外的に、宿側が変更を受け付けてくれ るケースもあります。 まずは宿に連絡する事をおすすめします。 予約変更できない 予約変更の基本 予約の内容・支払い方法の変更は、原則としてお客様ご自身で手続きしま す。 じゃらんのマイページから、該当の予約を選択して変更してください。 じゃらん側で予約内容を変更することはできません。 会員登録をして予約した場合 マイページから変更できる場合 会員登録をしてログインした状態で予約している場合、 以下の条件を満たしていれば、マイページから予約変更が可能です。 /// 略 /// オンラインカード決済から現地決済へ変更したい場合 オンラインカード決済から現地決済への変更はできません。 この場合は、予約をキャンセルし、現地決済で再度予約を行います。 予約変更できない
10. 自動化の技術的な難しさと困難要因 本質的な困難要因の1つは、問い合わせの不完全性・曖昧性から来る情報不足 予約変更できない 2026年4月1日から2泊3日で予約して いるホテルA（予約番号0123456）の 予約人数を3人から4人に変更したい。 予約一覧画面を開いたところ、画面に ホテルAの予約が表示されておらず、 予約変更ができずに困っています。 ユーザーが持つ情報例 • 環境: どのような画面を見ているか？ • 対象: どの予約に関する話か？ • 意図: 変えたいのは人数？日程？ リクルートが持つ情報例 • 状態: 実際の予約ステータス • 履歴: 過去の操作ログ
11. アプローチ方針の設計 対応方法は幾つか考えられるが、UX/コストなど様々な観点でリスクももたらす 各々の技術リスクに加え、研究・開発工数の増加により、 リリースまでの期間（Time-to-Market）が長期化するリスクも発生する。 聞き返し（マルチターン） 社内システム/DB接続 ユーザーの意図しない回答により、無 限ループや認識齟齬が発生。時間は使 うが解決しないリスクがあり、シナリ オ設計が指数関数的に複雑化する。 社内基幹システムへの直接接続は、セ キュリティや権限管理の難易度を跳ね 上げる。個人情報保護の観点からも、 実装ハードルが極めて高い。
12. アプローチ方針の設計 Step-by-Stepで完全自動化までのロードマップを描き 第一段はマルチエージェント構成で一部の問い合わせへの自動応答を実現する 大きな視点 完全自動化を目指しつつ、人とAIの協働 （Hybrid）から開始。リスクを抑えつつ、 段階的に自動化比率を高める。 小さな視点 単一モデルに頼らず、役割特化型マルチ エージェントを採用。適切な「差配」と厳 格な「検閲」で品質を担保。 Phase1 Single Turn Phase2 Multi Turn Phase3 System Integration … Router Agent Worker Agent Judge Agent Operator
13. 必要な役割を定義し、3つのエージェントを設計 解決策の具体化: マルチエージェント構成 … Router Agent インテント（意図）を推 定し、AIが答えるべき か、人が答えるべきかを 差配する。 Worker Agent Judge Agent 特定されたインテントと ユーザーの状況に応じ て、最適な回答案を生成 する。 生成された回答がユー ザーの問題を適切に解決 できるかの最終判断を下 す。
14. Single-Turnで解決可能な問い合わせを中心に、自動応答を実現 解決策の具体化: マルチエージェント構成 問い合わせ Router Agent （意図推定含む） Worker Agent (回答文生成) Judge Agent Intent DB オペレーター 回答送信 構成イメージ
15. 正しい回答には、「固有の業務知識」をLLMで活用することが不可欠。 解決策の具体化: 業務ナレッジのDB構築 id 問い合わせ分類 回答テンプレート 過去問い合わせケースNo. 1 予約を変更したい XXX 123-456, 789−123 2 ポイント数を確認したい XXX 456−789 Intentの事前定義 ハルシネーション抑制 Intent（意図）を事前に 設計することで、対応範 囲を明確化。 高制御性の実現 答えられない領域をLLM が認識できる構造を明示 的に構築。 テンプレートを用いるこ とで、LLMの応答のブレ を抑え、品質を担保。
16. 数多くのIntentから意図を正確に特定し、最適な回答を行うための採用手法。 解決策の具体化: Router Agent実現の手法 Chain-of-Thought 1回の分類で答えを出さず、 「大分類→詳細Intent」と段階的に思考プ ロセスを分離。 • 文脈の読み飛ばしを防ぎ、複雑な要 求でも正確な意図推定を実現 • 判断ロジックが透明化され、デバッ グが容易に Critique Learning 過去の誤判定や「迷いやすい境界線」の データを使い、AI自身に判断基準を批判 ・再定義させる。 • 「なぜAではなくBなのか」の論理的 根拠を自己学習 • プロンプトだけでは困難な微細な ニュアンス差を判別
17. 24時間365日の「即時解決」への挑戦 有人対応だけでは限界がある中、ユーザーの課題を今すぐ解決するために自動化が不可欠。 課題の本質は「情報不足」 問い合わせの不完全さや曖昧性が、LLMでの正しい回答生成を妨げていた。 「人とAIの協働」による段階的導入 完全自動化を目指しつつ、確実に解ける領域から適用するアプローチを選択した。 「マルチエージェント」による品質担保 Router, Worker, Judgeの3エージェントを設計し、可能な限り誤回答を防ぐ安全なアーキテク チャを構築した。 まとめ