カスタマーサポートにおけるエージェントの強み 第 3 章

自律型カスタマーサポートへのロードマップ

自律型カスタマーサポートは、スイッチを入れるだけで導入できるものではありません。 時間をかけて構築していく能力です。 目標は、初日からすべてのケースを自動化することでも、サポート業務から人間の専門知識を排除することでもありません。 目指すべきは、自律的に対応できるサポートの範囲を着実に拡大しながら、人間の専門知識が最大の価値を発揮するケースに人材を集中させることです。

ほとんどの組織が比較的定型的なサポート業務から着手します。そして、AI エージェントが成果を上げるために必要な知識や評価の基盤を確立したら、より複雑なケースへと自律型サポートを段階的に拡大していくのです。 そのための 5 つのステップを紹介します。

ステップ 1: サポートの基準を確立する

自動化する内容を決定する前に、現在サポート部門がどこに時間とコストを費やしているかを把握する必要があります。 まずは、既に追跡している指標から始めます。チケット件数、平均処理時間 (AHT)、平均解決時間 (ART)、エスカレーション率、自己解決率、チケットあたりのコストなどです。 その上で、ケースの複雑さという観点からそれらの指標を分析します。

解決に何時間もかかる L1 リクエストと、専門的なエンジニアリングの知識を要する L3 の課題とでは、自動化の機会が大きく異なります。 ケースの種類ごとに、処理件数、解決までの時間、コストを分析します。これにより、自律化によって初期段階で最大の効果が得られる分野を特定しやすくなります。

特に、発生件数が多いケースの中で、解決までの流れが明確なものに注目します。 こうしたケースは、多くの場合、処理の予測可能性が高く、判断を要する部分も少ないため、初期段階で自律的な解決を進めるのに最も適した候補となります。

ただし、個々のチケットだけで評価を判断してはなりません。 解決に至るまでの全プロセスに目を向ける必要があります。 エージェントはいくつのシステムにアクセスしますか? 引き継ぎはどこで発生しますか? 情報の検索にどれだけの時間が費やされていますか? 人の判断が必要なステップはどれで、単なる手作業に過ぎないものはどれでしょうか?

目標は、自動化そのものよりも重要な指標、すなわち「各ケースの解決にどれだけの人手が必要か」を測定するための基準を確立することにあります。

ステップ 2: ナレッジの基盤を整備する

AI エージェントにナレッジ ベースへのアクセス権を与えることと、顧客の問題を解決するために必要な知識を与えることは同じではありません。 企業には多くの場合、長年にわたるサポート文書、解決済みのケース、製品ドキュメント、トラブルシューティング ガイド、エンジニアリング ノート、そして組織固有の知識などが存在します。 その蓄積は極めて貴重なものとなり得ますが、同時に、古くなった指示、重複した情報、矛盾する解決策、あるいはもはや関連のない製品やバージョン向けに書かれたコンテンツが含まれている場合もあります。

そうした知識は、自律的なサポートに向けて整備しておく必要があります。 組織は、関連性の高いコンテンツを特定し、不要な情報を排除し、情報を適切に構造化する必要があります。また、特定の顧客、製品、構成、あるいは問題といった文脈で、エージェントが適切な知識を確実に引き出せるようにすることも不可欠です。 しかも、これは一度きりの移行作業ではありません。

この基盤はまた、担当者が各ケースのエスカレーションや解決に取り組むたびに、継続的に改善されていくべきものです。 完了したケースを評価して既存のナレッジ ベースにおける不備や不足しているガイダンスを特定し、システムが自律的に新しいナレッジ記事を生成できるようにします。 その記事は、組織のガバナンス プロセスに従ってレビューおよび公開することができます。 別の顧客から同様の問題について問い合わせがあった場合、AI エージェントは新たに作成されたそのナレッジを活用して、改めてエスカレーションすることなく問題を解決できるようになります。 こうして、エスカレーションがナレッジ基盤を強化し、将来的な解決率を向上させるというクローズドループ システムが構築されます。

新製品のリリース、サポート ケース、そして問題解決のたびに、新たなナレッジが生まれます。 自律的なパフォーマンスを維持するには、エージェントが製品に関する古い理解に基づいて推論しないように、情報を常に最新の状態に更新し続ける必要があります。 結局のところ、自律的な解決の質は、それを支える知識の質に大きく左右されることになります。

ステップ 3: L1 から着手し、L2 を見据えて構築する

定型的な L1 サポートは、最適な出発点です。 こうしたケースは、一般的に処理件数が多く、リスクが低く、結果が予測しやすいため、エンドツーエンドの自律的な解決に最適な候補となります。 だからといって、孤立した L1 自動化環境を構築し、それ以外のことは後回しでよいというわけではありません。

L1、L2、L3 の境界は、必ずしも明確ではありません。 AI エージェントには、ケースを理解し、その複雑さを分類し、安全に解決できるかどうかを判断して、解決できない場合にはエスカレーションするために十分な背景情報が必要です。 より効果的なアプローチは、L1 と L2 の両方を対象にして機能の構築を開始し、それぞれの中で異なる自律性レベルを追求することです。

定型的な L1 のケースについては、エンドツーエンドでの解決に向けて推進すべきです。 より複雑な L2 のケースについては、AI エージェントに対応可能な解決プロセスの部分を処理させ、必要に応じて人の専門知識をプロセスに組み込むようにします。 それにより、次の段階、つまりそうした人の介入から学習するという基盤が築かれます。

ステップ 4: 評価と学習のループを構築する

支援型から自律型への移行には、AI エージェントが依然としてどのような場面でなぜ支援を必要としているのかを正確に把握することが不可欠です。 そのため、評価は運営モデルの中核をなす要素となります。 組織には、エージェントの行動、問題解決の質、知識の検索、エスカレーションの判断、そしてその結果を継続的に評価する手段が必要です。 エージェントが自律的にケースを完了できない場合、単にそのチケットを人に引き継いで終わりにするだけではいけません。

その代わりに、何が起きたのかを検証する必要があります。 エージェントは、どのような点で支援を必要としていたでしょうか? 不足していたのはどのような情報ですか? 人間はどのような行動を取りましたか? エージェントは誤ったナレッジを取得したのでしょうか、誤った判断を下したのでしょうか、それともこれまでに遭遇したことのない状況に直面したのでしょうか? 人が成功させた解決策は、その後の貴重な新しい知識となります。

それを記録してナレッジ ベースに組み込み、更新された情報に基づいてエージェントをテストした上で、その結果を活かして将来の類似ケースへの対応を改善します。 こうして継続的なサイクルが形成されます。 成功している組織は、人の介入を自律的な運用の失敗とは見なさず、むしろそれを活用して AI エージェントが次に対応できる範囲を拡大しています。

ステップ 5: 自律性の範囲を拡大し続ける

目標は、必ずしも 100% 自律的に解決することではありません。 人の手を介さずに完了できるサポート業務の割合を、継続的に向上させることが目標です。 当初は解決プロセスの 60% で人の関与を必要とする L2 のケースを考えてみてください。 AI エージェントは、エンジニアが引き継ぐ前に、既に問題の分類、顧客の背景情報の収集、関連知識の検索、ログの分析を終え、対処法の提案を用意できているかもしれません。

組織が成果を収集し、エージェントを改善していくにつれて、そのバランスは変化する可能性があります。 40% が自律対応で 60% が支援付きだったものが、最終的には 60% が自律対応で 40% が支援付きになるかもしれません。 時が経つにつれて、このプロセスにおける人手による部分はますます縮小していきます。

その学習サイクルが L2 のケースで確実に機能するようになれば、組織はリスク許容度、ビジネス要件、そしてエージェントのパフォーマンスに基づいて、同じモデルを特定の L3 シナリオへと拡大していくことができます。 その結果、人の専門知識がこれまでとは異なる形で活用されるサポート体制が実現します。

AI エージェントは、定型的な調査、システムとのやり取り、そして問題解決を担う割合を増やしていきます。 一方、サポート エンジニアは、新規性が高く、曖昧で、価値の高い問題に専念します。 そして、人が介入して成功したケースはすべて、次のやり取りをより自律的なものにする機会を生み出します。

こうして自律型カスタマーサポートは規模を拡大していきます。つまり、手動から自律型に一気に飛躍するのではなく、人の専門知識が必要な領域と必要でなくなった領域との境界線を絶えず移動しながら実現されるのです。

ロードマップの実践

自律的なサポートへの道のりは、組織ごとに異なるものとなるでしょう。 製品の複雑さ、ケースの件数、利用可能な知識、リスク許容度、既存システムといった要素がすべて、どこから着手すべきか、また、どの程度のスピードで拡大するかに影響を及ぼします。 しかし、具体的なサポートのシナリオに目を向ければ、その流れがより理解しやすくなります。

以下の 3 つの事例は、極めて定型的な L1 リクエストから技術的なトラブルシューティング、そして最終的にはケースのライフサイクル全体のオーケストレーションに至るまで、組織がどのようにして自律性のレベルを段階的に高めて適用していけるかを示しています。

ユーザー アクセス管理: 予測可能で処理量の多い業務から着手する

一般的な L1 リクエストを考えてみましょう。 ある顧客が新しい従業員を採用しました。その従業員は、サポート ケースの提出や管理のために、カスタマー ポータルへのアクセス権を必要としています。 そのリクエストによってチケットが作成され、サポート担当者または管理担当者がチケットを確認し、対応を完了させる必要があります。 作業そのものは単純かもしれませんが、リクエスト 1 件ごとに人的リソースを消費するため、チケット件数の増加につながります。

AI エージェントであれば、リクエストを理解して必要な情報を収集し、ユーザーの資格要件や権限を確認できます。そして、連携したシステム間での適切なアクセス ワークフローを実行し、アクセス権の付与が正常に完了したことを確認できます。 これは、自律的な解決を始めるのに適した、結果が予測しやすく難易度の低いケースの一例です。 L1 のケースは、適切な対応が概ね明確であり、反復も可能であるため、エンドツーエンドの自律的な解決を非常に高いレベルで達成することができます。

ここから得られる教訓は、単にアクセス リクエストを自動化することではありません。 こうした予測可能なケースを活用して、より複雑な自律的解決を支える基盤となる能力、つまり知識、統合、テスト、評価、ガバナンスといった要素を確立することにあります。

Bot のデプロイ失敗: 技術的なトラブルシューティングにおける自律性を拡大する

では、もっと複雑なシナリオを考えてみましょう。 ある顧客が本番環境への移行準備を進めている最中に、Bot のデプロイに失敗し、画面が真っ黒になってしまいました。 アクセス権の要求とは異なり、この問題の解決に至る道筋は、必ずしも一つに絞られているわけではありません。 原因は、ログ、設定、製品バージョン、顧客環境、過去のケース、またはその他の技術的要因によって異なる可能性があります。

AI エージェントは、調査の開始にあたり、報告された問題を把握し、関連する背景情報を収集し、利用可能なログを分析し、該当する製品知識を検索することで、最も可能性の高い解決策を特定できます。 信頼性が高く、安全対策が確立されている場合、エージェントは承認済みの是正措置を実行し、デプロイが成功したかどうかを確認することができます。 追加の専門知識が必要な場合は、収集済みの情報 (ケースの概要、診断結果、関連知識、推奨される次のステップなど) を添えて、サポート エンジニアにケースをエスカレーションすることができます。

これは、自律型ロードマップの重要な原則を示しています。すなわち、ケースが完全に自律化されていなくても価値を生み出せるということです。 ある組織では、この問題解決プロセスの 40% を自動化し、残りの 60% は人手に頼るという形から始めるかもしれません。 エージェントがどこで支援を必要としたかを評価し、エンジニアが成功させた解決策を記録し、その知識をシステムに反映させることで、組織は将来的なケースにおける自律的な対応の割合を段階的に高めていくことができます。

目標は、自律的な作業が終わり、人間の介入が始まるまでの距離を継続的に縮めていくことです。

ケース ライフサイクル管理: 受付から解決までのサポートをオーケストレーションする

ケースのライフサイクル管理は、自律的なカスタマーサポートのより広範な最終形態を表しています。 AI エージェントは、特定のタスクやトラブルシューティングのシナリオを自動化するのではなく、問題が組織に報告されてから解決・完了に至るまでのサポート プロセス全体に関与します。

このプロセスは分類から始まります。 AI エージェントは顧客の問題を解釈し、自律的な解決を試みるために必要な知識や能力を備えているかどうかを判断します。 その上で、サポート システム全体から情報を収集し、関連する知識を検索し、考えられる解決策について推論を行い、適切な対応を実行することができます。 やり取りの最中に、顧客の感情やエージェントのパフォーマンスなどのシグナルも評価し、ケースを自律的に継続すべきか、それとも人の専門家に引き継ぐべきかを判断することもできます。

人の支援が必要な場合、その目的はチケットを別のキューに振り分けることだけではありません。 エンジニアは、AI が事前にまとめた背景情報を受け取り、調査を最初からやり直すことなく問題解決作業を継続できます。 こうした人による介入も、継続的な学習サイクルに貢献します。 成功した解決策は、記録され、組織の知識として組み込まれます。つまり、将来的に同様の状況が発生した際にエージェントの対応改善に役立てられるのです。

時間の経過とともに、ケースのライフサイクルの中で自律化する部分が増えていきます。

また、こうした状況ではシステム間を行き来する手間をなくすことが極めて重要になります。 テクニカル サポートのケースを解決するには、チケット管理システム、CRM、ナレッジ ベース、顧客ポータル、コミュニケーション プラットフォームなどにまたがる情報や対応が必要となる場合があります。 自律型のケース管理では、顧客やサポート エンジニアが各アプリケーションを手動で操作するのではなく、エージェントがその環境全体を横断して状況を判断し、対応する必要があります。

その結果、根本的に異なるサポート モデルが実現します。ケースは動的に分類されて、可能な場合には自律的に解決され、人の専門知識が必要な場合にはシームレスにエスカレーションされます。そのデータは将来の解決策を改善するために継続的に活用されます。

個別の事例から自律型サポート モデルへ

これらの例は、3 つの独立した自動化プロジェクトとして捉えるべきではありません。

ユーザー アクセス管理は、組織が定型的なサポート業務に関して自律性を確立する方法を示しています。 Bot のデプロイに失敗した事例は、自律的な解決と支援型の解決が連携する、より複雑なケースにまで同じ基盤を拡大できることを示しています。 ケースのライフサイクル管理は、これらの機能がサポート プロセス全体を通じて統合的に運用された場合にどのようなことが実現するかを示しています。

共通しているのは、継続的な拡大です。 組織は、知識と統合の基盤を確立し、確実に解決できる業務を自動化するとともに、依然として人の支援を必要とする業務を評価し、人が成功させた解決策を蓄積します。そして、その知見を活用して自律性をさらに高めていきます。

これが、サポート業務の自動化から自律的なサポート体制の構築に至る道筋です。