サポートデータのAI向け準備：チケット、マクロ、ナレッジコンテンツ

著者: Linh Ngo · 更新日: 2026年10月11日

サポートデータのAI向け準備とは、モデルが顧客に触れる前に、3つの資産を整えることです。正確で曖昧さがなく最新のナレッジベース、タグが一貫していて解決内容が整理されたチケット履歴、そして自社チームの実際の回答方法に合ったマクロのライブラリです。 AIエージェントは、与えられたものから答えを作ります。ヘルプセンターが自己矛盾していれば、ボットも同じ矛盾を、丁寧な言葉で、大規模に伝えます。

このガイドは、AIエージェントを有効にしようとしている、あるいはすでに有効にして誤った回答に悩んでいる、サポートリーダー、CXのDirector、サポートマネージャーに向けたものです。カスタマーサービスにおけるAIの概要の下に位置づけられ、成果の大半を左右する1つの要素、つまりツールの土台となるコンテンツとデータを掘り下げます。

重要なポイント

• NBERの研究「Generative AI at Work」では、AIアシスタントによって、カスタマーサポート担当者5,179人の1時間あたりの解決件数が平均で約14%、新人や低スキルの担当者では34%向上しました（NBER w31161）。
• 同じ著者らは、AIが「より有能な担当者のベストプラクティスを広めている」ことを示唆する証拠を見出しており、これはそうした実践が、記録された使える形で存在している場合にのみ成り立ちます（NBER w31161）。
• Intercomのドキュメントによると、人間の読者と異なり、AIは「明確な構造、曖昧さのない表現、顧客のインテントとの強い整合性に大きく依存」します（Intercom Help Center）。
• Intercomは、AIによるコンテンツの提案とチームメイトのフラグを毎週レビューすること、関与は多いのに解決率が低い記事を毎月レビューすることを推奨しています（Intercom Help Center）。
• ZendeskのAIエージェント向けのガイダンスは、AIエージェントが使うため、古い情報や信頼できない情報を避けるよう述べています（Zendesk Help Center）。

AIが実際に必要とするサポートデータ

AIサポートツールの多くは2つの系統に分かれ、それぞれが異なる資産を読み取ります。

1つ目は、ドキュメントに基づいて質問に答えるタイプです。関連するヘルプ記事を取得し、そこから返信を書きます。このパターンは検索拡張生成として知られています。ACE Frameworkの用語では、rag-assistantパターンです。品質の上限は、ナレッジコンテンツで決まります。モデルは、書き留められていないポリシーを引用できず、食い違う2つの記事のどちらが正しいのかも判断できません。コンテンツが整った後にこのエージェントがどう振る舞うかは、AIナレッジベースエージェントのページで解説しています。

2つ目は、分類してルーティングするタイプです。受信したチケットを読み、カテゴリー、緊急度、感情を割り当て、適切なキューに送ります。これはscoring-routingパターンであり、過去のチケットから学習します。タグが一貫していなければ、一貫しない習慣を学習してしまいます。十分なデータで育てたものがどう動くかは、AIサポートトリアージエージェントを参照してください。

マクロは、この2つの中間に位置します。チームが承認した文言であり、下書きツールにもエージェントアシストの提案にも使われます。

サポート以外も含めたデータの全体像については、AIのためのデータ準備が一般的なチェック項目を順に説明しています。

よくあるギャップ

AIをローンチする前のサポート部門では、5つの問題が繰り返し見つかります。

記事間の矛盾。 2年の間隔で書かれた返金に関する2つのページが、異なる期間を示しています。人間の担当者はどちらが正しいか知っています。検索システムは、どちらも取り出す可能性があります。Zendesk自身のヘルプセンターも、AIエージェントが古い情報や信頼できない情報を使うと注意していますが、古い記事はまさにそれに当たります。

人の頭の中にしかないナレッジ。 特殊な請求のエッジケースへの対処法が、最もシニアな担当者の記憶の中にしか存在しません。これがNBERの研究が指摘するギャップです。AIはトップ担当者の実践を広めますが、それは記録された形で見つけられるものに限られます。

タグの乱立。 3年後には140個のタグがあり、そのうち6個が「請求の問題」を意味し、担当者はドロップダウンの最初に出てきたものを選びます。その履歴で学習したルーティングモデルは、同じ混乱を再現します。

空の解決メモ。 「解決済み」や「完了」でクローズされたチケットからは、何も学べません。価値があるのは、「顧客のSSO証明書が失効していたため、管理設定で更新して再同期しました」という一行です。

ポリシーより長生きしたマクロ。 ポリシーが14日に変更されて久しいのに、30日間の返品期間を約束するマクロがショートカットメニューに残っています。エージェントアシストのツールは、それを忠実に提案します。

優れたナレッジコンテンツとは

Consortium for Service InnovationのKnowledge-Centered Service（KCS）v6実践ガイドは、これに対する最も確立された手法です。作業を、担当者がチケットを解決しながらナレッジを取得、構造化、再利用、改善するSolve Loopと、コンテンツの健全性、プロセスの統合、成果の評価、リーダーシップを扱うEvolve Loopに整理しています（KCS v6 Practices Guide）。Solve Loopの4つの実践は、AI向けの準備にそのまま対応します。

• 取得（「その場でナレッジを取得する」を含む）：四半期ごとのドキュメント整備のスプリントではなく、チケットを解決しながら記事を書きます。
• 構造化（「シンプルなテンプレートを使う」）：問題、環境、解決策、原因といった一貫したテンプレートにより、人間にも検索システムにも内容を解析しやすくなります。
• 再利用（「早く、何度も検索する」「リンクする」）：使った記事にチケットを紐付けると、実際に使われているコンテンツが分かります。
• 改善（「フラグを立てるか、直す」）：誤った記事を見つけた人は、直すかフラグを立てるので、劣化が見つかります。

KCSを丸ごと採用しなくても、効果は得られます。原則は、ナレッジはチケットを解決する副産物であり、担当者がいるということです。

ベンダーのガイダンスも同じ方向を示しています。Intercomは、AIが明確な構造と曖昧さのない表現に依存すること、目的や範囲が不明確な記事は、間違った種類の質問で取得されることがあると述べています（Intercom Help Center）。実践的な目安として、新入社員が読んだ後に「待って、どちらが自分に当てはまるのか」と尋ねるようなら、AIは推測します。

役立つ書き方の習慣をいくつか挙げます。

1. 最初の文に答えを置き、その後に条件と例外を続けます。
2. 回答が当てはまる顧客セグメント、プラン、地域を明記します。
3. タイトルには社内用語ではなく、顧客が使う言葉を使います（「アカウントのメールアドレスを変更したい」）。
4. 1記事につき1タスクとし、共通の手順はコピーせずにリンクします。
5. 製品のバージョンやポリシーの日付を記事の中に記し、レビュアーが古い記事を見つけられるようにします。

チケット履歴とマクロの整理

チケット履歴は、AIが自社の分類ロジックを学ぶ場所であり、エージェントアシストのツールが回答例を見つける場所でもあります。

タグ。 新人の担当者が覚えられる、管理されたリストに減らします。複雑さによりますが、通常は15〜40の理由です。それぞれに1行の定義と例を書きます。同義語を統合し、ロングテールを廃止し、主要な問い合わせ理由を必須フィールドにします。その後、サンプルにラベルを付け直し（テストには数百件のチケットで十分です）、担当者が元々選んだものと比較します。大きな食い違いは、担当者が雑なのではなく、カテゴリーが不明確であることを意味します。

解決メモ。 必須の「何で解決したか」フィールドか、クローズ用のテンプレートを追加します。短く具体的なメモでも、すべてのチケットがナレッジ記事の候補になり、より優れた学習例になります。

センシティブなデータ。 チケットには、氏名、カード番号の断片、健康に関する詳細、人々が誤って貼り付けたパスワードが含まれています。チケットのテキストを学習や検索に使う前に、何をマスキングまたは除外するかを決めてください。プライバシーまたはセキュリティの責任者を早めに巻き込みます。

マクロ。 利用回数付きで全リストをエクスポートします。1年間使われていないものは廃止し、残りのマクロにはそれぞれ担当者を割り当て、それが表現しているポリシーに紐付けます。ポリシーが変わったら、担当者が同じ変更の中でマクロと対応する記事を更新します。

ステップごとに進める：サポートデータの準備

1. 最初のユースケースを選ぶ。 パスワードと請求の質問に対するデフレクション用ボットには、強力な記事が必要です。トリアージモデルには、強力なタグが必要です。最初のプロジェクトが依存する資産から始め、各パターンが何を必要とするかはパターン別のデータ準備のガイドで確認してください。
2. 上位50トピックを監査する。 件数の多い問い合わせ理由の上位を抽出します。それぞれについて、最新の記事がちょうど1つで答えているかを確認し、不足、重複、矛盾しているものに印を付けます。
3. まず矛盾を解消する。 重複を統合し、劣るほうを削除またはリダイレクトし、ポリシーの問題はその担当者と決着をつけます。これが最も早く精度を高める方法です。
4. 実際のチケットからギャップを埋める。 カバーされていない上位のトピックについて、解決済みチケット20件を読み、最も優れた解決内容から記事を書きます。これはKCSの「取得」をまとめて行うものです。
5. テンプレートを標準化する。 記事の構造とタイトルのスタイルを1つに統一します。ライブラリ全体ではなく、まず上位50件を書き直します。
6. タグとメモを整える。 定義付きの管理されたタグリストを公開し、履歴をそれに合わせて再マッピングし、今後は解決メモを必須にします。
7. マクロを見直す。 廃止、更新、担当者の割り当てを行い、それぞれをポリシーに紐付けます。
8. 担当者と見直し日を設定する。 すべての記事とマクロに、担当者の名前と見直しの間隔を決めます。最終更新日で並べ替え、トラフィックの多い記事から始め、レビューを定期的なカレンダーに入れます。
9. テストセットを作る。 ボットが断るべき質問を含め、実際の顧客の質問50〜100件と、それぞれの正しい回答を書きます。ローンチ前と、コンテンツを変更するたびに実行します。
10. フィードバックのループを開く。 担当者がワンクリックで誤りや不足のある回答にフラグを立てられるようにし、フラグを毎週レビューします。Intercomは、AIによるコンテンツの提案とチームメイトのフラグを毎週レビューすること、AIがよく使うのに質問を解決することが少ない記事を毎月確認することを推奨しています（Intercom Help Center）。

サポートデータ準備状況チェックリスト

各行を0（当てはまらない）、1（部分的に当てはまる）、2（当てはまる）で採点します。最初のブロックで16点満点中10点を下回る場合は、顧客向けのボットをローンチする前にコンテンツを修正してください。

スコアは、合否の判定ではなく、チームとの対話のきっかけとして使ってください。最もスコアの低い行が、最初のスプリントになります。

職種別の実例

以下は説明のためのシナリオであり、測定されたケーススタディではありません。

カスタマーサポート。 旧ログイン用とシングルサインオン用の、パスワードリセットの記事が2つあるソフトウェアのサポートチームを想像してください。これを1つの記事に統合し、冒頭に「どのログインを使っていますか？」という短いセクションを置けば、ボットの情報源は1つになります。精度がどれだけ向上するかは、自社のテストセットが教えてくれます。

請求と経理のサポート。 返金ポリシーには、請求の責任者だけが知っている例外がよくあります。年間プラン、地域ごとのルール、部分的な利用などです。これらを1つの記事の中で明示的なルールの表として書けば、AIも新人の担当者も一貫して適用できます。

テクニカルサポート。 エンジニアがコードで問題を修正しても、サポートが回避策を記録していないとしましょう。クローズ用のテンプレートに必須の「原因と対処」メモを加えると、下書き記事が継続的に生まれ、サポートスペシャリストが毎週レビューできます。

オンボーディングとサクセス。 カスタマーサクセスマネージャーが、同じセットアップの質問に個人のテンプレートで答えているなら、最良のバージョンを共有の担当者付きマクロに移すことで、チームの文言が揃い、AIが参照できる承認済みの素材ができます。

オペレーションと品質。 QAリーダーは、毎週AIの回答をテストセットに照らしてサンプリングし、失敗をそれぞれコンテンツの修正、タグの修正、ポリシーの問題として記録できます。失敗の中心がコンテンツのギャップからまれなエッジケースに移れば、コンテンツへの取り組みが実を結んでいます。

避けるべき落とし穴

• すべてを取り込む。 あらゆる記事、フォーラムのスレッド、古いリリースノートをAIに与えると、古いものを引用してしまいます。情報源のセットを選別し、アーカイブ済みのコンテンツは除外してください。
• モデルのアップグレードをコンテンツの修正と見なす。 より優れたモデルでも、矛盾する2つのポリシーは解決できません。より雄弁に自己矛盾するだけです。流暢な誤答が主要なリスクである理由は、AIハルシネーションを参照してください。
• まずライブラリ全体を書き直す。 件数を生んでいるトピックから始めてください。10本の優れた記事は、誰も尋ねない500本の整理済み記事に勝ります。
• 担当者がいない。 担当者のいないコンテンツは劣化します。ローンチ後の最初のポリシー変更で、何かが壊れます。
• 非公開のナレッジを後回しにする。 社内のRunbookやエスカレーションのルールは、公開記事と同じくらい重要ですが、最も整理されていないことが多いものです。どのAI機能にそれらを読ませるかを意識的に決めてください。Zendeskは、生成される回答の大半が一般に公開されている記事に基づくため、制限付きのコンテンツは使われない場合があると述べています。
• 人を無視する。 ナレッジを書く担当者には、そのための時間と評価が必要です。コンテンツの仕事が誰が何をするかをどう変えるかは、AIとサポートチームの役割を参照してください。
• テストセットなしでローンチする。 ローンチ前に回答の品質を測定できなければ、顧客から教わることになります。

次に読む記事

上位20の問い合わせ理由を選び、それぞれに最新の記事が1つあることを確認し、矛盾を解消してください。この1回の監査で、通常はどんなツール設定よりも大きな成果が得られます。その後、テストセットを作り、担当者を決め、毎週のフラグレビューを実施します。そして概要を使って、この取り組みをより広い展開の中に位置づけてください。