コールセンターRPA:何を自動化し、どこで破綻するか

コールセンターRPAの正体

私はここ数年、実際に稼働しているサポートキューの上で動くAIエージェントを構築してきましたが、まず言っておきたいのは、RPAはその評判を正当に得てきたということです。実際に価値のあることをやっています。

ロボティック・プロセス・オートメーションとは、ベンダー自身の言葉を借りれば、デジタルシステム上で「データ入力、ファイル移動、取引処理といった反復的でルールベースの業務」を実行する人間の動作を模倣するソフトウェアロボットです。ボットは文字通り、エージェントがマウスとキーボードで行うのと同じ動作、同じ画面のクリックを、より速く、飽きることなく実行します。Automation Anywhereも同じ捉え方をしていて、RPAは自動化の「腕と脚」であり、構造化された繰り返し可能なステップを確実に実行するものだとしています。

そもそもRPAがコールセンターに適している理由は、コンタクトセンター業務の大部分が実際にルール化・反復可能だからです。シフトリーダーが朝の時間をチケットの項目を請求ツールへコピーすることに費やしているなら、それは書き出せるルールであり、ルールとして書き出せることは何でもボットが実行できます。

現場の異なる業務に対応する、知っておく価値のある2つのタイプがあります。

• **アンアテンデッドRPA(無人型)**は、スケジュールやトリガーに基づいて、人が監視することなく単独で動きます。Automation Anywhereはこれを、一括データ入力やシステム連携といったバックオフィス業務に位置づけています。夜間のバッチ処理を思い浮かべてください。
• **アテンデッドRPA(有人型)**は現場のエージェントに寄り添い、通話の途中でフォーム入力やレコード取得のために動き出します。ベンダーはこれを、人間が関与するカスタマーサービスやITヘルプデスク業務のカテゴリーとして明示しています。これがいわゆる「エージェントデスクトップ」ボットです。

どちらも何かを理解しているわけではありません。これは批判ではなく、そういう設計なのです。RPAは本質的に決定論的であり、だからこそ信頼でき、監査可能である一方、業務が決定論的でなくなった瞬間に破綻するのもそのためです。

コールセンターRPAが得意とすること

ここがRPAが本領を発揮する部分です。その多くは、エージェントの1日を静かに食いつぶす地味な業務であり、それをボットに任せることは実質的な勝利と言えます。

Automation Anywhereは、まさにこれらをカスタマーサービスのユースケースとして挙げています。問い合わせ対応の自動化、チケット化と振り分け、オンボーディング時のデータ入力です。そしてプロセスが安定している場合、その成果は本物です。シアトル市の事例は具体的でわかりやすいものです。同市は6,000件を超える公共料金プログラムの申請の滞留を解消し、1日700件のパスワードロック解除申請を自動化し、月30時間以上を節約しました。しかもこれらはすべて、AIを重ねる前のルールベースRPAだけで実現しています。

あなたのコールセンターがこうした反復的なバックオフィス業務を抱えているなら、RPAは正当な答えであり、大きな混乱もなくカスタマーサービスのワークフローの一部として組み込めます。ここはRPAベンダーがうまく語る部分であり、それは間違っていません。

コールセンターRPAが破綻する場面

ここからはパンフレットが触れない部分です。RPAの仕組みそのもの、つまり人のクリックを装うボットという構造が、そのまま弱点でもあります。実際のサポートキューをRPAに担わせようとするチームを見てきましたが、たいてい予測可能な3つの形で破綻します。

壊れやすい。 ボットはページ上の特定のボタンや項目を対象にしています。レイアウトを変えたり、項目名を変えたり、UIを更新したりすれば、自動化はすぐに壊れます。r/rpaの実務者たちも率直にこう言っています。

"UI automation is brittle, so we built an AI-based solution... that makes UI-based automation on websites extremely easy."

r/rpa, on constant UI changes breaking automations

メンテナンスに骨の髄まで食われる。 壊れやすいボットは、誰かが子守をしなければならないボットでもあります。これは見えないコストであり、数字がそれを裏付けています。Deloitteのグローバル調査では、51件以上の稼働中の自動化を持つ組織だけが「スケーラー」とみなされ、ほとんどのプログラムはそこまで到達せずに停滞します。オートメーション・アズ・ア・サービスを使うチームの3分の1は、ボットの管理とメンテナンスそのものを外部委託しています。動かし続けること自体が一つの仕事だからです。あるr/automationのスレッドが言うように、本格的なエンジニアリングの裏付けがなければ「中長期的にはメンテナンスの負担が骨の髄まで食い尽くす」ことになります。

言葉、例外、判断を扱えない。 これがコールセンターにとって最大の問題です。なぜならそれこそが実際の仕事だからです。顧客が質問の言い回しを変えたり、予期しない書類を添付したり、ルールのないエッジケースに当たったりした瞬間、ボットは何もできません。RPAのベンダー自身もこれを認めています。AIなしのRPAは「構造化データでしか効果的に機能できず……これがRPAの効果を制限し、より多くの例外を人間の従業員に押し戻す」としています。コミュニティの見解も同じで、驚くほど公平です。

"RPA thrives in rules based end to end process so it's more reliable for structured tasks, while agents thrive on processes having lots of nuances... Not everything needs an LLM to perform rules based decisions."

r/rpa, "RPA vs AI agents vs Agentic Process Automation"

この最後の引用は正直な整理の仕方です。RPAが悪いわけではなく、守備範囲が狭いだけなのです。そしてサポートキューの大半は、その守備範囲の外にあるニュアンスに富んだ会話的な業務です。だからこそ、チケットにRPAを追加していくだけではチケット自動化がなかなか前進しないのです。

RPAとAIエージェント:それぞれの役割

この議論の役に立たないバージョンは「RPA対AI、どちらが勝つか」です。役に立つバージョンは、両者はそれぞれ違う仕事をしており、優れた構成はその両方を使う、というものです。以下が私の考える役割分担です。

AIエージェントは届いたメッセージを読み取り、顧客が実際に何を求めているのかを把握し、次のステップを判断します。RPAボットは、必要であれば、決定論的な実行を担います。ERPへのログイン、データの移動、決まったルールに従った処理です。人間は本当の例外に対応し、全体を見守ります。UiPathも同じ役割分担を説明しています。エージェントが分析し判断し、RPAがその判断を確実に実行に移し、人間が監督する、というものです。

だからこそ、議論の枠組みは「AIはRPAを置き換えるのか」から「上にAI、下にRPA」へと静かに変化しつつあり、AIと人間のコストの計算は、会話部分にエージェントを置くことをますます有利にしています。このカテゴリーは3つの段階を経て成長してきました。

最初に来たのは単純なタスク自動化(誰もが思い浮かべる2010年代のRPA)でした。次に来たのがインテリジェント・オートメーションで、RPAを機械学習や言語モデルと組み合わせ、メールや文書のような非構造化データを読み取れるようにしたものです。そして今はエージェント型AIで、エージェントが理解と判断を担い、RPAはそれが呼び出す実行層になります。Gartnerは、2024年下半期だけでエージェント型自動化に関するクライアントからの問い合わせが750%増加したと記録しており、需要がどこへ向かっているかがわかります。

サポート部門のリーダーにとって、実践的な読み解き方はシンプルです。あるタスクをどう自動化するか決めるときは、それがどんな種類のタスクなのかを問うことです。以下のツールで確認してみてください。

eeselが当てはまる場所

これが私が実際に取り組んでいる階層です。RPAが決して想定していなかった会話の階層です。eesel AIは、届いたチケットやチャットを読み取り、あなた自身のナレッジから答えを引き出して解決するか、エージェントが送る返信を下書きするヘルプデスク向けのAIエージェントです。これは全体像における「AIが判断する」半分にあたり、カスタマーサービスにおけるAIの一部として、何かを作り直すことを求めるのではなく、すでに運用しているヘルプデスクに組み込まれます。

これがチケットにRPAを当てるのとは違う理由がいくつかあります。

• 自社の履歴で学習する。 eeselは過去のチケット、ヘルプセンター、マクロから学習するため、あらゆる場面ごとにルールを書く必要がなく、初日からあなたの会社らしい言葉で回答します。これはRPAスクリプトが強いるメンテナンスの終わりなき労働とは正反対です。
• 本番稼働前にシミュレーションできる。 これは痛い経験から生まれた機能です。私たちは、自信ありげに聞こえるボットがひっそりと誤った回答をするのを目にしてきました。そのためeeselは過去のチケットに対してシミュレーションを実行し、実際の顧客に触れる前に解決率と正確な返信内容を示します。どう振る舞うかを確認してから、本格稼働させられます。
• 止めどきを知っている。 購入検討者から最もよく聞く要望は、完全な自動化ではなく、コントロールです。あるDTC企業のサポートリーダーは私たちにこう言いました。「自信を持って対応できるチケットだけを扱ってくれるAIが必要で、それ以外のものには手を出さないでほしい」。eeselは確信度に基づくエスカレーションと引き継ぎを行うため、確信の持てるものは解決し、残りはきれいに引き渡します。

プロセスが本当に決定論的である場合、eeselもそれに逆らうことはなく、チケット解決の一環として、RPAが行うのと同じ種類のアクション(タグ付け、担当割り当て、ステータス更新、API呼び出し)を実行します。Zendesk上で運用しているGridwiseチームは、導入から最初の1か月で、eeselがティア1リクエストの73%を解決したのを確認し、このプラットフォームは「チケットのタグ付け、割り当て、ステータス更新の自動化まで含まれている」と述べています。これがまさに全体の考え方です。会話にはAIを、実行には決定論的なアクションを、というものです。

これはまた、エンジニアリング志向の強いコールセンターの多くが抱く「自分たちで作ればいいのでは」という疑問にも答えます。GENERAL BYTESのチームは、自作ではなく購入を選んだ理由をこうまとめています。「自分たちでLLMアプリケーションを書くこともできましたが、そこに時間を投資したくありませんでした。メンテナンスの必要がないものが欲しかったのです」。このメンテナンスの論点は、RPAスクリプトが高くつく理由と同じものが、一段階上に移っただけです。

実際にどう始めるか

今まさにコールセンターRPAを検討しているなら、すべてを一度に自動化するのではなく、私ならこの順序で進めます。

1. タスクを洗い出して分類する。 キューを決定論的なバックオフィス業務(データ入力、レポート取得、ステータス更新)と会話業務(人間が読んで解釈する必要があるもの)に分けます。前者はルールベースの自動化が担うべき部分であり、後者はAIカスタマーサービスソフトウェアの仕事です。
2. 安定した地味な業務はルールで自動化する。 本当に固定されたプロセスであれば、ルールベースのボットやヘルプデスク組み込みのワークフロー自動化で十分ですし、AIエージェントより安く済みます。ただし画面が変わったときにはメンテナンスが必要になることを承知の上で導入してください。
3. 会話部分にはAIエージェントを置く。 理解を必要とするチケットやチャットには、意図を読み取って解決するAIチケッティングシステムを使います。ここが実際に解決率やティア1振り分けの数字を動かす階層であり、本当のサポートコスト削減が現れる場所です。
4. シミュレーションしてから段階的に展開する。 本番稼働前に実際の過去のチケットでテストし、AIが最も自信を持てるチケットの種類から始めて、そこから範囲を広げていきます。初日からすべてを自動に切り替えないことです。

私が最もよく見る間違いは、これを一つの大きな自動化プロジェクトとして扱うことです。実際には違います。これは2つの異なる仕事であり、うまくいくチームはそれぞれに適したツールを使い分けています。

あなたのコールセンターでeeselを試す

あなたのキューの大部分が会話の階層であるなら、それこそがeesel AIの役割です。数分で既存のヘルプデスクに組み込まれるAIエージェントで、過去のチケットとナレッジベースから学習し、最前線を解決しながら残りはきれいにチームへ引き継ぎます。多くの人を納得させるポイントは、過去のチケットでシミュレーションできることです。実際の顧客が一人も話す前に本当の解決率がわかるので、賭けに出る必要はありません。

無料で試せて、何かを作り直すことなくヘルプデスクに向けて使い始められます。要点はそれだけです。配管部分はRPAに任せたままにして、RPAが決して想定していなかった会話の部分はAIエージェントに任せましょう。