Skip to Content
Docs07. ケーススタディケーススタディ: カスタマーサポート Agent
中級ai-agentraghuman-in-the-loop更新: 2026-07-07この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

ケーススタディ: カスタマーサポート Agent

注記: 本記事は、本ライブラリの設計判断を 1 つの物語で通すために構成した**架空の事例(構成事例)**です。登場する組織・数値は実在のものではありませんが、各段階の判断と失敗は実際のプロジェクトで広く観察されるものに基づいています。

この記事の目的

「問い合わせ対応 Agent」という 1 つの題材を、ユースケース選定 → 要件定義 → PoC本番導入を判断するために必要な「問い」を、期間を区切って検証する使い捨て前提の試作。デモの成功ではなく、本物のデータ分布での測定結果を成果物とする。 → 段階導入 → 運用改善まで通しで追い、案件推進(09-business)と実装・運用・評価の各記事の判断がどう連続するかを実例で掴みます。経費精算アシスタントの事例が「技術構成の段階的な育て方」を見せるのに対し、本記事は「ビジネス案件としての推進」に重心を置きます。

対象読者

前提知識

本文

背景: 題材と出発点

題材は SaaS 企業のカスタマーサポートです。メール・フォームでの一次問い合わせが増え続け、担当者が定型的な質問への回答に追われていました。「AI で何とかできないか」という相談から始まりましたが、いきなり実装には入らず、まず案件として成立するかを検討しました(ユースケース発見と要件定義)。

  • 向き不向きの判定: 問い合わせ対応は「結果を検証できる(担当者のレビューがある)」「手順が毎回変わる(質問が多様)」「失敗の損害が限定的(送信前に人が確認できる設計にできる)」「データにアクセスできる(FAQ・製品ドキュメント・注文 DB が API で取れる)」の 4 条件を満たしました
  • 範囲の 1 文記述: 「サポート一次対応の担当者向けに、過去問い合わせと FAQ から回答の下書きを生成する(送信判断は人)」— 自律度を「下書きまで」に絞ったのが最初の重要判断です
  • 最初の題材選び: 全問い合わせを狙わず、まず「製品仕様・使い方に関する定型質問」(全体の約 4 割で、検証しやすい)に限定しました。価値の大きい「解約・請求トラブル」は、実績と型ができた後に回す判断です

設計: 要件定義と成功基準

着手前にユースケース発見と要件定義の「要件定義の型(8 項目)」に沿って要件を固め、成功基準を数値で合意しました(下表はうち主要 6 項目の抜粋です)。

項目決定
入力問い合わせ本文 + 顧客情報 + FAQ・製品ドキュメント
出力回答の下書き(出典付き)をサポートツールに保存
自律性の範囲下書きまで。送信は担当者が承認
人の関与点全件レビュー(将来は抜き取りへ移行する計画も明記)
データ要件顧客情報は参照のみ。会話ログの保持方針を情報セキュリティ部門と合意
失敗時の扱い回答不能と判定したら人のキューへ。誤りは修正内容を記録して改善に使う

成功基準は「定型質問の 60% で採用可能な下書きを生成、担当者の修正率 30% 以下、一次対応時間の中央値を短縮」とし、着手前に 2 週間のベースライン計測を行いました。

設計: PoC

PoC は問いを 1 つに絞りました — 「過去問い合わせと FAQ から、担当者が使える下書きを生成できるか」(PoC から本番への進め方)。

設計: 本番化の関門

パイロット → 本番の関門で、機能以外の観点を通しました(PoC から本番への進め方)。

結果: 段階的リリースと運用

本番投入は一斉切り替えでなく、自律度と対象範囲の 2 軸で段階的に広げました。

段階を追ううちに、修正率が基準を下回ったカテゴリから順に「全件レビュー → 抜き取り監査」へ自律度を引き上げました。要件定義に「将来の引き上げ計画」を書いておいたことが、この移行をスムーズにしました。

設計判断: この事例の教訓

  1. 自律度を最初から絞る — 「下書きまで、送信は人」に絞ったことで、誤りが顧客に直接届くリスクを構造的に避けつつ、実績と改善データを安全に貯められました
  2. 案件推進と技術が連続している — ユースケース選定の「範囲の 1 文」が要件定義の自律度になり、PoC の評価セットが本番の回帰テストプロンプト・ツール・モデルの変更で既存の品質が壊れていないかを、評価データセットの再実行と前回比較で検知するテスト。になり、フィードバックが ROI の実績値になる、という具合に各記事の成果物が次の入力になりました
  3. 範囲を欲張らない — 価値の大きい請求トラブルを最初に狙わず、検証しやすい定型質問から始めたことで、最初のリリースが成功し「AI は使える」という組織の実績になりました

実務での注意点

アンチパターン

  • 全問い合わせの全自動対応を最初のゴールにする → 検証が難しい高リスク質問で事故が起き、「AI は使えない」という組織記憶を残す → 検証しやすい定型質問・下書き自律度から始め、実績で範囲を広げる
  • PoC の下書き品質を数件のデモで判断する → ハッピーパス偏重のまま本番に出て、多様な実問い合わせで崩れる → 分布を代表する評価セットで採用可能率を測る
  • 顧客データへのアクセス設計を後回しにする → 本番化直前に認証・権限の手戻りでリリースが止まる、または他顧客情報の混入事故が起きる → PoC 段階で認証・権限反映検索を設計に含める
  • 架空事例の数値(4 割・60%・50 件等)を基準値として引用する → これらは物語のための例示であり実測値ではない → 自社のログとベースラインから自分の数値を得る

チェックリスト

関連トピック

参考資料

TODO・未確認事項

なし

ケーススタディ: メールアシスタントの情報漏えいインシデントケーススタディ: 社内ナレッジ Agent(RAG 運用)