サポート業務を「分類→回答→ナレッジ更新」のループとして設計する。 本記事では、問い合わせ30件分の分類ラベル設計から、回答案の品質管理、ナレッジベースの更新サイクルまでを、すぐに自社で回せる形で解説します。
この記事の位置づけ
対象読者はビジネスサイド（CS責任者・カスタマーサクセス・サポートオペレーション担当）です。ソースコードやスクリプトは載せず、図解・表・箇条書きで「何ができるか・なぜそうするか」を中心に解説します。問い合わせサンプルは匿名・架空データです。
なぜ「ループ」で設計するのか
パイプラインの限界
多くのCS組織でAI活用の第一歩は「問い合わせの自動分類」や「FAQ検索の高速化」です。しかし、これらを個別のパイプラインとして作ると、以下の問題が温存されます。
- 分類しても、次のアクションが曖昧 — 分類結果が分析ダッシュボードに積まれるだけで、対応が変わらない
- 回答しても、知識が蓄積されない — 同じ質問に毎回ゼロから回答を生成している
- ナレッジを更新しても、現場に届かない — KBの記事が古いまま放置され、AIの回答精度も下がる
これらは「分類」「回答」「ナレッジ更新」が分断されていることが原因です。
KCSのダブルループに学ぶ
KCS（Knowledge-Centered Service）v6は、サポート業務を2つのループで捉えます。
| ループ | 役割 | 回す人 |
|---|---|---|
| Solve Loop（現場ループ） | 問い合わせを受けて、分類→回答→解決する | 現場のエージェント（人＋AI） |
| Evolve Loop（改善ループ） | 解決パターンからナレッジを更新し、根本原因を分析・改善する | 監督者・チームリード |
重要なのは、Solve Loopの品質がEvolve Loopを成立させるという点です。現場で正確に分類し、根拠付きで回答し、解決を記録するからこそ、ナレッジの改善と根本原因分析が可能になる。この相互依存を「AIエージェントの設計」に組み込むのが本記事のアプローチです。
分類ラベルの設計 — 30件で始める
ラベル設計の原則：「次のアクション」から逆算する
分類ラベルは「分析のため」だけでなく、次に誰が何をするかを決めるために設計します。KCSは「少しの構造は大きく効くが、過剰な構造は作業を阻害する」と明言しています。
| 設計の方針 | 良い例 | 悪い例 |
|---|---|---|
| アクションに直結 | 「返金」→経理チームへルーティング | 「お金の話」→対応不明 |
| 階層化（上位＝分析/下位＝運用） | カテゴリ「請求」→サブ「返金」「請求内容確認」 | 50個のフラットなラベル |
| 曖昧さを辞書で吸収 | 「退会」「解約」「キャンセル」→同義語として統一 | 表記ゆれのたびに新ラベルを追加 |
推奨ラベル体系（10カテゴリ×サブカテゴリ）
以下は、SaaS/EC横断で参考になるラベル体系です。Bitextの公開データセット（10カテゴリ×27インテント）やZendeskのcustom intentカテゴリを参考に設計しています。
| カテゴリ（上位） | サブカテゴリ（下位）の例 | 想定アクション |
|---|---|---|
| 請求・支払い | 返金依頼、請求内容確認、支払方法変更 | 経理チーム or 自動処理 |
| 不具合・障害 | 機能エラー、パフォーマンス問題、データ不整合 | 開発チームへエスカレ |
| 使い方・操作 | 初期設定、機能の使い方、連携方法 | KB検索→自動回答 |
| アカウント | ログイン問題、プラン変更、解約 | 本人確認→手順実行 |
| 配送・納品 | 配送状況、届かない、返品 | 物流チーム or 自動追跡 |
| 商品・サービス情報 | 仕様確認、在庫、比較 | KB検索→自動回答 |
| 苦情・クレーム | サービス品質、対応不満 | 即時エスカレ→上位者 |
| 契約・法務 | 契約内容確認、NDA、規約 | 法務チームへルーティング |
| 連携・API | 外部サービス連携、API仕様 | 技術サポートチーム |
| その他 | 上記に該当しない | 人が判断→適切なチームへ |
迷いを減らす3つの工夫
1. 辞書（同義語）で表記ゆれを吸収するZendeskのエンティティ検出では、シノニム（同義語）の追加で分類精度を上げる運用が推奨されています。「退会」「解約」「やめたい」「キャンセル」を同義語として登録し、ラベルを増やさずに吸収します。
2. 新カテゴリの候補を定期的にレビューするZendeskは週次で新しいintent候補を提示する機能を提供しています。Atlassianの「Suggested Topics」も、最近のリクエストからナレッジギャップを推定します。重要なのは「候補の自動提示→人の承認→採用」という流れを運用に組み込むことです。
3. 会話の進行で分類が変わる前提を持つチケットは作成時点で情報が揃わないことが多い。ByteDanceの研究でも、会話の進行に伴う状態変化を踏まえた"オンライン"なエスカレーション判定の必要性が指摘されています。初回分類を「暫定」とし、追加情報で更新する設計にしておきます。
30件の分類で精度と迷いポイントを出す
実際に30件の問い合わせ（匿名/架空）を上記ラベルで分類してみると、以下のような「迷いポイント」が浮かび上がります。
| 迷いパターン | 例 | 対処法 |
|---|---|---|
| 複合問い合わせ | 「返金してほしいし、使い方もわからない」 | メインの意図（返金）を優先し、サブを付記 |
| 感情が先行 | 「もう最悪！何とかして！」 | 感情検出とカテゴリ分類を分離する |
| 情報不足 | 「動かないんですけど」 | 「不具合」に仮分類し、追加情報を聞く |
| エスカレ判断 | 法的表現が含まれる苦情 | キーワードルールで強制エスカレ |
回答案の生成 — 根拠付き・手順付き・棄権できる
回答の3つの型
| 型 | 条件 | 処理 |
|---|---|---|
| 自動回答 | KB検索で高信頼度のヒットあり | 引用付きで自動返信→フィードバック依頼 |
| 下書き＋人レビュー | 信頼度が中程度、または複雑な問い合わせ | 回答案を生成し、人が確認して送信 |
| 棄権→エスカレ | 信頼度が低い、高リスク、根拠不足 | 「回答しない」と判断し、人に引き継ぐ |
FreshworksのEmail AI Agentは、このフローを具体的に実装しています。KB検索（上位3記事＋信頼度スコア）、引用付き回答の生成、フィードバックウィジェット、ポジティブフィードバックで自動クローズ、不十分なら人が介入——という閉ループが定義されています。
「手順」と「決定論的制御」の組み合わせ
FAQ回答だけでなく、返金・解約・本人確認などの複雑シナリオでは、IntercomのProceduresの設計思想が参考になります。
- 自然言語の指示（「お客様に返金理由を確認してください」）
- 決定論的制御（返金額が1万円以上→承認者にエスカレ）
- 承認点（人間の承認を待ってから実行）
- ハンドオフ用の内部メモ（人に引き継ぐ際の経緯サマリ）
これらを組み合わせ、さらにSimulations（本番前の大規模テスト）で手順を検証してからデプロイします。
誤回答（ハルシネーション）の2つの型と対策
| 型 | 原因 | 対策 |
|---|---|---|
| 内部要因 | モデル自体が事実に反する出力を生成 | 出力制約（引用必須）、根拠不足なら棄権 |
| 外部要因 | 検索した根拠文書との不整合、検索不足 | RAG精度の改善、KB記事の鮮度管理 |
この区別は、「対策をどこに入れるか」を決める上で実務的に重要です。
ナレッジ更新 — 下書き自動化＋監督＋期限管理
ケースクローズ→ナレッジ下書きの自動生成
ループの終端（Evolve Loop）は、解決したケースからナレッジ記事の下書きを自動生成し、監督者がレビューして公開する仕組みです。
| ベンダー | 機能 | 特徴 |
|---|---|---|
| Microsoft | Customer Knowledge Management Agent | ケースクローズ時に会話・メール・ノートを分析して下書き作成。既存KBと重複回避。コンプライアンスチェック内蔵 |
| ServiceNow | Now Assist for CSM | KCSシステムプロパティと連携し、解決ケースからナレッジ記事ドラフトを作成 |
| Atlassian | Suggested Topics＋AI drafts | リクエストからナレッジギャップを推定し、記事下書きを生成 |
| Zendesk | Help Center記事生成 | 直近30日のSolved/Closedチケットから記事を生成。PII自動リダクション |
「使った記事を直す」文化（KCSの reuse is review）
KCSの設計思想では、記事を使ったエージェントがその記事を更新する権限と責任を持つ（reuse is review）。AIがナレッジ検索で古い記事を参照した場合、その事実を検出し、更新タスクとして可視化する仕組みが理想です。
トピックギャップの検知
Atlassianの「Suggested Topics」やServiceNowの「trending topics」は、最近のリクエストの中でKBにまだ記事がないテーマを自動で検知します。このギャップ検知を記事作成のバックログに変換し、定期的に消化するサイクルを組みます。
品質指標 — 何を測り、どう使うか
「解決率」だけでは不十分
Intercomは、平均解決率が6,000社超で66%に達したと公表しつつ、「解決率だけでは仕事量削減を表せない」と述べています。分類→回答ができても、本人確認・返金・例外処理などの作業が残ると実際の負荷は減りません。
4つの指標を分けて追う
| 指標 | 定義 | 測り方のポイント |
|---|---|---|
| Deflection率 | 人に届かずに解決した比率 | セルフサービス（FAQ/チャットボット）で完結したケースを計測 |
| Resolution率 | 顧客の用件が完了した比率 | 顧客フィードバック（肯定回答）をトリガーに判定 |
| Automation率 | 端から端までAIが処理した仕事量比率 | 分類＋回答＋クローズまで人の介入なしに完了したケース |
| Handoff率 | 人への引継ぎが発生した比率 | エスカレーション・転送が発生したケース |
FCRは「Net」で定義する
FCR（First Contact Resolution）は顧客満足と強い相関がありますが、Gross FCR（全流入を分母）とNet FCR（レベル1で解決不能なものを除外）の区別が重要です。AI分類・自動応答を回す場合、対象レンジを誤るとFCRが歪むため、Netの除外条件を先に固定してから計測します。
AI特有の品質指標
Zendeskは従来指標（deflection・応答時間・CSAT）だけでは質が見えないとし、AQS（Automated Quality Score）——AIが会話を自動評価してスコア化する指標を提示しています。また、誤回答率は「内部要因（モデルのハルシネーション）」と「外部要因（根拠文書との不整合）」を分けると、対策の優先順位が明確になります。
効果値は「定義」とセットで読む
FreshworksのIRでは解決時間76%短縮・初動応答41%短縮・チケットディフレクション65%、Zendeskの顧客事例ではdeflection 41%などの数値が公表されていますが、これらはIR文脈の数値です。適用条件（対象範囲、定義、期間）を自社で再定義しないと比較できません。「活動量」ではなく「成果（なぜ改善したか）」を説明できる指標へ寄せることが大切です。
ガードレール — 個人情報と機密を扱う設計
「マスキング」≠「匿名加工情報」
問い合わせデータには個人情報・機密が含まれます。日本の個人情報保護委員会は、単にマスキングしただけでは匿名加工情報ではなく、個人データのままであることを明確に述べています。匿名加工情報は「特定の個人を識別できず、復元できない」ように加工した情報であり、以下の措置が必要です。
- 識別記述（氏名・住所等）の削除
- 個人識別符号の削除
- 連結符号（ID）の削除
- 特異値の削除
- 識別（再同定）行為の禁止
データセット公開は段階設計で
分類ラベルとデータセットの公開を目指す場合、一気にチケット本文を公開するのではなく、段階的に進めます。
| 段階 | 公開内容 | リスク |
|---|---|---|
| 段階1 | ラベル体系・頻度分布のみ | 極低 |
| 段階2 | 合成データ（実データ分布を模倣） | 低 |
| 段階3 | 匿名加工情報としてのチケット本文 | 中（法的要件の充足が前提） |
合成データ生成（synthetic data）は、実データの分布を模倣しつつ個人情報を開示しないアプローチとして研究が進んでいます。例えばSNOOKERはヘルプデスク向けの合成データ生成器として、実データとの分布的な近さを統計的に評価しながらプライバシー問題を回避する設計が公開されています。
LLMに渡す前の前処理が必須
Zendeskのドキュメントが指摘する通り、UIのマスキングだけではAI要約や分類がPIIを露出し得ます。LLMに渡す前の前処理（検出・削除/置換）と権限制御を別途設計する必要があります。
データの流れを可視化して管理する
問い合わせデータは「入力→処理→出力→保存」の各段階を流れます。どこで何が残るかを設計時に明確化し、各段階でPII検出・最小化・権限制御・保持期間管理を組み込むことが重要です。
国際的なガバナンスフレームワーク
B2Bや越境データを扱うCSでは、以下のフレームワークが運用設計の拠り所になります。
| フレームワーク | 概要 |
|---|---|
| EDPB「AI Privacy Risks & Mitigations – LLMs」（2025年4月） | LLMシステムのデータフローに沿ったプライバシーリスクの識別・評価・低減の実務ガイド。GDPR Art.25（Privacy by design）やArt.32（Security of processing）に資する対策を整理 |
| NIST AI 600-1（Generative AI Profile） | AI RMFに基づき、組織がAIリスクをガバナンス・測定・管理するための行動指針を提示 |
| ISO/IEC 42001（AIマネジメントシステム） | AIの信頼性・透明性・説明責任・プライバシーを含むリスクベースの要求事項。経済産業省も紹介 |
日本の制度改正動向（方針段階）
個人情報保護委員会は「3年ごと見直し」の制度改正方針（2026年1月9日公表）で、統計作成等にのみ利用されることが担保される等の条件下で本人同意不要とする方向性を示し、注記で「統計作成等に整理できるAI開発等を含む」と明記しています。ただし現時点では方針段階であり、実務は現行法・現行ガイドライン準拠で設計しつつ、改正の確度が上がったら運用ルールを更新できる設計にしておくのが安全です。
LLM利用時の最低限の確認事項
| 確認項目 | 内容 |
|---|---|
| 学習利用 | 顧客データでモデルを再学習するか否か |
| データ保持 | 入出力データの保持期間と削除ポリシー |
| 監査 | ログの取得・保全・アクセス制御 |
| サブプロセッサ | データが第三者に共有されるか |
| 暗号化 | 転送中・保存中の暗号化レベル |
例えばOpenAIはEnterprise向けに「デフォルトでは顧客データで学習しない」「保持期間を顧客が制御」「SOC 2」「暗号化」等のコミットメントを提示し、DPA（データ処理契約）で処理者義務・監査・サブプロセッサ・返却/削除の条項を明示しています。これは特定ベンダーの推奨ではなく、問い合わせデータをLLMに通す場合に最低限確認すべき論点の具体例として参照できます。
あわせて読みたい
導入ステップ — 30件から始めて回す
| ステップ | やること | 成果物 |
|---|---|---|
| 1. ラベル設計 | 上記10カテゴリ×サブカテゴリをベースに自社用に調整。同義語辞書を作成 | 分類ラベル定義書、同義語辞書 |
| 2. 30件分類 | 直近の問い合わせ30件を手動で分類。迷いポイントを記録 | 分類済みデータセット、迷いログ |
| 3. 回答設計 | 自動回答/下書き/棄権の3パターンとルーティング条件を定義 | 回答フロー定義書 |
| 4. KB連携 | ナレッジ下書きの自動生成→レビュー→公開のワークフローを構築 | KB更新運用ルール |
| 5. 指標設定 | Deflection・Resolution・Automation・Handoff・Net FCRの定義を固定 | KPIダッシュボード |
| 6. ループ稼働 | 週次でラベル候補レビュー＋KB更新＋指標確認のサイクルを開始 | 週次運用チェックリスト |
30件で十分な理由
最初から完璧なラベル体系は作れません。30件の分類で「迷いポイント」を洗い出し、ラベルの粒度を調整してから100件→500件と拡大するのが、最も手戻りの少ないアプローチです。週次で新カテゴリ候補をレビューし、必要なら追加するサイクルを回すことが重要です。
最初の30件の分類に必要な時間は、2〜3時間程度です。この投資で「分類→回答→ナレッジ更新」のループが初めて回り始めます。ループさえ回れば、AIの支援範囲を段階的に広げていけます。まずは30件から始めてください。
Agenticベースでは、CS業務の「分類→回答→ナレッジ更新」ループの設計から、AIエージェントの構築、品質指標のダッシュボード構築まで一貫して支援しています。まずは現状のサポートフローの課題をお聞かせください。
この記事の著者
Agentic Base 編集部
AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。
