1. ホーム
  2. ブログ
  3. カスタマーサポートにおけるAI
  4. 顧客サポートにおけるAI導入:なぜ91%の経営陣のプレッシャーがプラットフォームの能力を上回っているのか
カスタマーサポートにおけるAI

顧客サポートにおけるAI導入:なぜ91%の経営陣のプレッシャーがプラットフォームの能力を上回っているのか

10分で読める
専門家によるレビュー済み 
カスタマーサポートにおけるAIの導入

経営陣は顧客サポートにAIを導入したいと考えているが、今度は既存のヘルプデスクと連携させる方法を考え出す必要がある。

それは、既存のシステム構成に別のAIツールを追加するよりも難しい場合があります。既存のプラットフォームには、何年分ものチケット、時代遅れのナレッジベース記事、一貫性のないタグ、古いワークフローから残されたカスタムフィールドなどが蓄積されている可能性があります。AIはこれらのデータに依存するため、データの質と構造が、テクノロジーそのものよりも大きな問題となる可能性があります。

そこで、新たなツールに投資する前に、現在お使いの ヘルプデスク がどのような機能をサポートできるかを確認することをお勧めします。この記事では、サポートプラットフォームがAIに対応できる条件、古いシステムが問題を引き起こす可能性のある箇所、そして既存のシステムにAIを追加するか、より計画に合ったプラットフォームに移行するかを判断する方法について解説します。

AIの導入は優先事項だが、完全な統合はまだ限定的だ

カスタマーサポートにおけるAI導入に関する数字は、誤解を招く可能性がある。調査で何を測定するかによって、「導入」の意味は、AIツールの使用からサポート業務への統合まで、多岐にわたるからだ。経営陣の期待と実際の統合レベルを分けて見ることで、より明確な全体像を把握できる。.

サポートリーダーの91%がAI導入のプレッシャーに直面している

ガートナーは 2025年10月に321人のサービスおよびサポート責任者を対象に調査を実施しました。その結果、91%が経営陣からAI導入のプレッシャーを受けていると回答しました。

そのプレッシャーは、サポートチームの人員配置計画にも影響を与える。.

~80%

回答者の約80%が、AIが定型業務を担うようになるにつれて、エージェントは新たな役割に移行すると予想していると答えた。.

84%

回答者の84%が、この変化に対応するために、必要なスキルを追加したり、採用基準を変更したりする予定だと回答した。.

しかし、これらの計画は既存のサポート環境が対応できる範囲に依存します。現在のヘルプデスクとそこに保存されているデータによっては、実現可能なAIのユースケースが制限される可能性があります。.

AIの導入は用途によって異なる

コンタクトセンターにおけるAIの活用は、実に様々な意味合いを持つ。COPC Inc.のコンタクトセンター技術レポートに よると、コンタクトセンターの42%が顧客ケアとサポートにAIを使用しているが、その導入率はアプリケーションによって異なる。最も多かったのはチャットボットで59%、次いでロボティック・プロセス・オートメーションが48%、顧客感情分析が44%、テキスト分析が42%だった。音声分析は32%、ボイスボットは23%で利用されていた。

完全な統合は、サポートデータの質とアクセスしやすさに依存します。

  • チケットフィールド: 現在および過去のチケット全体で一貫したカテゴリ、タグ、および値
  • チケット履歴: 問題の内容、講じられた措置、および解決策を理解するのに十分な情報
  • 知識ベース: 明確な構造を持ち、矛盾する回答のない最新のコンテンツ

AIツールもこのデータへのアクセスを必要としますが、それはヘルプデスクがAPIや連携機能を通じて公開するデータに依存します。.

顧客サポートにおけるAI導入が停滞する理由

既存のサポート業務にAIを導入する場合、長年にわたって培われてきたプロセスを扱うことになります。エージェントは既にエスカレーションや承認のルールに従って業務を行っており、AIに何を実行させたいかによっては、品質保証プロセス、システム統合、 AIナレッジベース すべてに変更が必要になる可能性があります。

スキル、ガバナンス、エージェントの導入は、AIプロジェクトの進行を遅らせる可能性がある。

AIが生成した回答を評価し、誤りを特定し、エージェントが対応を引き継ぐタイミングを定義する担当者が必要です。顧客対応のユースケースでは、顧客情報の取り扱いとAIが生成した回答のレビューに関する明確なルールも必要となります。.

エージェントにも同様の明確さが必要です。トレーニングでは、応答のレビューが必要な場合、不適切な提案を報告する方法、担当者に直接引き継ぐべきケースなどを網羅できます。これにより、AIが業務フローに組み込まれた際に、エージェントの役割が明確になります。.

古いヘルプデスクでは統合がより困難になる可能性がある

統合に関する問題はAIだけにとどまりません。CX Networkの「 Global State of CX 2025」調査に よると、回答者の31%が既存ツールとの統合をCX投資の実現を阻む障害と捉えています。これより上位にランクインしたのは、ROIの実証(39%)と予算の確保(35%)のみでした。

AIプロジェクトは、既存の統合における限界を露呈させる可能性があります。古いヘルプデスクでは、エージェントがインターフェースを通じて情報にアクセスできる一方で、同じ情報をプログラムで取得するためのオプションが少ない場合があります。APIに一部のカスタムフィールドが欠落していたり​​、エクスポート時に会話スレッドを再構築するための追加作業が必要になったり、既存の統合でチケットの一部しか取得できなかったりする可能性があります。.

QAは、AIによって要件がどのように変化するかを示す良い例です。COPC社によると、従来、ほとんどのチームは 顧客とのやり取りのわずか2~5%しか ず、そのサンプルをエージェントの指導、コンプライアンスの追跡、プログラムのパフォーマンス評価に利用していました。AIを活用した品質モニタリングは、より多くのやり取りをカバーできるため、はるかに多くの会話データを取得・処理することが可能になります。

ヘルプデスクのAPI、エクスポート、および統合機能を通じて取得できる情報を、実装予定のAIユースケースと照らし合わせて確認してください。たとえば、チケット要約ツールは会話内容へのアクセスを必要とし、自動分類はトレーニングデータまたは参照データに使用されるフィールドとカテゴリに依存します。.

過去のデータをAIのユースケースと照らし合わせて確認する

AIが効果的に活用できるナレッジベースには、最新かつ一貫性のある回答が必要です。同じ問題に対して2つの記事が矛盾する指示を出している場合、書式が明確であるだけでは十分な効果は得られません。AIがどのコンテンツを使用するかを決定する前に、重複する記事、以前の製品バージョン、廃止されたサポートポリシーを参照しているガイダンスなどを確認してください。.

チケット履歴にも同じロジックを適用します。例えば、ヘルプデスクの移行後、現在の「請求」カテゴリが3つの古いカテゴリに置き換わったとします。古いチケットを分類に使用したい場合は、まず以前のカテゴリを現在の分類体系にマッピングする必要があります。ユースケースが最近解決されたチケットのみに依存している場合は、この作業の価値は低いかもしれません。デフォルトでサポート履歴全体をクリーンアップするのではなく、ユースケースに必要なデータから始めましょう。

サポートチームのための実践的なAI導入フレームワーク

導入したいAI機能が決まったら、現在のヘルプデスクと比較して評価しましょう。まずは自社のサポートデータを使ってテストしてください。その結果は、別のプラットフォームへの移行にかかるコストと労力を比較するための具体的な指標となります。.

1

現在のプラットフォームがサポートできる内容を監査する

この機能で使用するチケットの中から、代表的なサンプルを選択してください。よくあるリクエストに加え、エージェントが分類や解決に苦労するケースも含めるようにしてください。.

機能に必要な情報をテストしてください。チケットの分類を評価する際は、経験豊富なエージェントが割り当てたカテゴリと比較してください。要約機能については、会話全体と関連するチケットフィールドが正しく入力されているか確認してください。応答生成についても、エージェントが現在使用しているナレッジベースの記事を与え、回答の正確性を確認してください。.

発見した問題点を記録し、その原因を突き止めてください。分類の不整合は分類体系の問題を示している可能性があり、要約の不備はフィールドや会話データの欠落を示している可能性があります。関連性のないナレッジベース記事に基づいた不適切な回答は、内容をより詳細に確認する必要があるかもしれません。.

2

決定事項:既存のヘルプデスクにAIを追加するか、AIネイティブツールに移行するか

まずはテスト中に見つかった問題点から始めましょう。中には、小規模なクリーンアップ作業や統合部分の変更で済むものもあれば、ヘルプデスクと並行して維持管理する必要のあるカスタム開発が必要なものもあるでしょう。.

次に、使用予定のAI機能に必要な作業量を見積もります。初期データの準備と統合変更、および継続的なメンテナンスを含めてください。また、受け入れざるを得ないプラットフォームの制限事項も記録してください。.

この取り組みを、検討中のプラットフォームへの移行と比較してください。必要なチケットデータへのアクセスが可能かどうか、また、計画しているAI機能の基盤となる統合をサポートしているかどうかを確認してください。移行には、特に長年のサポート実績や確立されたワークフローがある場合は、独自のコストがかかります。そのため、比較には導入と継続的な作業の両方を考慮する必要があります。.

AI ファーストの移行では、 計画しているAI機能の要件を移行範囲に含めます。たとえば、チケットの分類が特定のフィールドに依存している場合は、移行中にそのフィールドを保持してマッピングします。応答生成に過去の会話を使用する場合は、その履歴のどの部分をターゲットのヘルプデスクに送信する必要があるか、またどのような形式で送信する必要があるかを判断します。

3

データを使用してAIをテストするための移行手順

完全な履歴を転送する前に、最近の代表的なチケットと関連するナレッジベースコンテンツを移動し、その後、移行したレコードを使用して計画されているAI機能をテストします。.

レコードが届いたかどうかだけでなく、さらに詳しく調べてください。つまり、 マッピングされたフィールド、関連レコード間のリンク、会話の順序、コンテキストに必要な添付ファイル、および移行されたコンテンツへのアクセスに影響を与える権限などを確認します。

カテゴリは、誤ったターゲット値で正常に転送される可能性があります。会話にはすべてのメッセージが含まれているにもかかわらず、カスタムフィールドが欠落しているために分類に必要なコンテキストが失われる場合があります。テストセットでこれらの問題を発見することで、残りのレコードに適用する前にマッピングを調整する機会が得られます。.

テストセットでマッピングを検証した後、残りの移行にも同じ構成を使用してください。.

AI導入に必要なサポートプラットフォームの要件

AIがカスタマーサポートに導入されると、要件は過去のデータへのアクセスだけにとどまりません。エージェントは引き続きチケットを作成し、ナレッジベースの記事は更新され、 サポートプロセスも 変化します。こうした変化に対応して、AIが使用する情報を常に正確に保つ方法が必要になります。

AIに対応するための知識ベースを準備する

各記事は明確な質問に焦点を当て、重要な回答は検索可能なテキストで記述してください。手順が添付ファイル、動画、またはリンクされたページに依存している場合は、AIツールがそれらからどのようなコンテンツを取得できるかを確認してください。.

コンテンツの維持管理を担当する人材も必要です。製品のアップデートによって既存の手順が古くなる場合や、同じ問題を複数の記事で扱うことになる場合もあります。定期的な見直しを行うことで、AIが生成する回答に古いガイダンスが残ってしまう前に、これらの問題を早期に発見できます。.

ガートナーの報告に よると、サービスリーダーの58%が、カスタマーサービス担当者をナレッジマネジメントスペシャリストに育成する計画を立てている。彼らの職務には、AIや顧客セルフサービスのためのコンテンツのレビュー、キュレーション、および維持管理が含まれる。

データ量ではなく、データ品質に焦点を当てる

過去のチケットの枚数だけでは、AIのユースケースにおいてどれほど有用かを判断することはできません。一貫したカテゴリと完全なフィールドを持つ少数のチケットセットの方が、複数の分類体系で作成された何年にもわたる記録よりも、より有用な入力データを提供できる可能性があります。.

ガートナーによると、組織の63%はAIに適したデータ管理手法を欠いているか、あるいはそれができているかどうか確信が持てない状況にある。同社はまた、2026年までに、AI対応データに裏付けられていないAIプロジェクトの60%が組織によって放棄されると予測している。

実装後に作成されたチケットにも同様の問題が発生します。チームがカテゴリを変更したり、新しいフィールドを導入したりする場合は、その変更をAI機能で使用されるデータにどのように適用するかを決定する必要があります。そうしないと、現在および過去のレコードが徐々に別々の構造になってしまう可能性があります。.

AIファーストの移行では、移行プロセスの一環としてこれらのデータルールを確立できます。各AI機能が使用する情報を文書化し、移行後にサポートチームが実施するプロセスにそのメンテナンスを含めてください。.

これはサポートチームにとって何を意味するのか

AIツールを選択する前に、現在のサポート体制で計画されているユースケースに必要な機能を提供できるかどうかを確認してください。その評価の結果、以下の点が明らかになるはずです。

  • AI機能が使用するサポートデータは、会話履歴やチケットフィールドから関連するナレッジベースコンテンツまで多岐にわたります。.
  • そのデータの準備にどれだけの労力が必要かを検討してください。サポート履歴全体を整理するのではなく、使用予定のレコードに基づいて範囲を決定してください。.
  • 現在のヘルプデスクで十分なアクセス権限が得られるかどうか。不足部分を補うために必要な統合作業や継続的なメンテナンスについても検討してください。.
  • 移行がより良い選択肢となる場合。現在のヘルプデスクを適応させるために必要な作業と、計画しているユースケースをより直接的にサポートするプラットフォームへの移行にかかるコストと複雑さを比較してください。.

AIの導入が既存システムの移行よりも非現実的になる普遍的な基準点はありません。この評価では、自社のサポート業務における比較検討に必要な数値と技術要件を提供します。.

Help Desk Migrationの無料デモを利用すれば、決定を下す前に、自社のサポートデータがどのように移行されるかをテストできます。

よくある質問(FAQ)

経営陣からのプレッシャーは高く、サポートリーダーの91%がAI導入を迫られていると感じているものの、既存のヘルプデスク環境がレガシーアーキテクチャに依存しているため、統合は停滞している。チケット分類の不整合、古いナレッジベース記事、制限されたAPI、レガシーカスタムフィールドといった問題が、AIツールによるクリーンで構造化されたデータへのアクセスを妨げている。.

いいえ。何年にもわたる過去の記録を大規模にデフォルトでクリーンアップしようとするのではなく、対象となるAIユースケースに必要な特定のデータにのみ焦点を絞ってください。たとえば、チケット分類を実装する場合は、その特定のモデルのトレーニングまたはデータ入力に使用されるカテゴリと最近のチケットフィールドのみをマッピングして絞り込みます。.

簡単な監査を実行することで、現在のプラットフォームを評価できます。

  • APIとエクスポートの制限事項: システムのAPIがカスタムフィールドを省略したり、会話スレッド全体を再構築できなかったりしないか確認してください。
  • ナレッジベースの矛盾: 既存の記事に古い情報や矛盾する製品情報が含まれていないか監査します。
  • AIの結果のテスト: 複雑な過去のチケットの代表的なサンプルをAI機能に入力し、コンテキストの欠落、要約の誤り、または不適切な分類がないかテストします。

これらのギャップを埋めるために大規模かつ継続的なカスタム開発が必要となる場合は、移行を検討する時期かもしれません。.

AIファーストの移行では、計画中のAIツールの技術的なデータ要件を移行プロジェクトの範囲に直接組み込みます。単に生のレコードを移動するのではなく、AIファーストのアプローチでは、重要なチケットフィールド、会話順序、添付ファイルのコンテキスト、ナレッジベースの構造が、ターゲットプラットフォーム上のAI機能のために適切にクリーンアップ、マッピング、および保持されることを保証します。.

まず、データ転送の順序を決めましょう。最初に、最近のチケットとコアとなるナレッジベースコンテンツから代表的なテストバッチを抽出し、それらのレコードに対してAI機能をテストします。履歴全体にわたる本格的なデータ移行を実行する前に、テスト環境でフィールドマッピングの精度、レコードリンク、アクセス権限を確認してください。.

Help Desk Migration

プログラミングスキルがなくても、ヘルプデスクプラットフォーム間でデータを移行できる自動サービスです。簡単な 。