要点
AIサポートのパイロットは、4週間と狭いレーン1本で進めます。第0週は計画です。ドキュメントからそのまま答えられるチケットタイプを2、3個選び、現状のベースラインと合格ラインを書き出し、同じチケットについてAIキューと人間のみの対照キューを並べて設定します。第1週はシャドウモードで、AIは下書きだけを作り、チームがそれを採点します。第2週は、レーンの10〜20%で顧客に回答します。第3週に半分程度まで広げます。第4週は何も変えず、数字が落ち着くのを待ち、その1週間後に判断します。拡大するか、直して再テストするか、止めるかです。
チームが飛ばしがちな部分が、毎日のレビューです。前日のAIチケット、AIが行ったすべての操作、再開された会話をすべて読む1日15分が、パイロットの成否を分けます。ミスは4つの原因（ナレッジの不足、指示、データの欠落、ルーティング）のどれかに行き着き、それぞれ直し方が違います。返金、キャンセル、アカウント変更は、回答のみのレーンがきれいになるまで、パイロットの対象外にするか、人の承認の裏に置きます。
すでにこの形で動くパイロットがほしいなら、eeselは初日の前に過去のチケットを再生してスコアを出し、Zendesk、Freshdesk、Gorgias、HubSpotの中で下書きから始め、すべての操作を毎日のレビュー用に記録します。XAPは、紹介案内のチケットを社内メモとして下書きするという1つの切り口から始め、そこからフィルターを広げています。無料プランでは100クレジットで、自社のキューを試せます。
なぜAIサポートのパイロットの多くは2週目でつまずくのか
私はeeselのサポートキューを担当しているので、パイロットを内側から見ています。第1週のセットアップの質問、そして第2週の「これは普通ですか？」というメッセージです。止まってしまうパイロットは、AIが悪いから止まるわけではほとんどありません。たいていは、AIが何をしたかを毎日読む担当者がいない、最初のレーンがきれいになる前にスコープが広がる、そして同じ午後に3つの変更が入って、どれが返品の回答を壊したのか誰にもわからなくなる、といったことが原因です。
実際の例を挙げます。Zendeskを使うデンマークの車両テレマティクスのチームは、ボットがデータベースにないメーカーについて「はい、お客様の車種に対応しています」と答えていることに気づきました。モデルが何もないところから作り話をしたわけではありません。ヘルプ記事の1つに「全車種に対応」と書かれていて、AIがそれを信じたのです。彼ら自身によるセットアップの総括は「trial and error in the beginning」で、正直な言葉であり、まさにパイロットの役目そのものです。人間の担当者なら黙って回避しているような、ナレッジベース内の誤った文を見つけることです。
だから私は、パイロットをソフトウェアのテストではなく、運用プロジェクトとして計画します。私が話すほとんどのチームでうまくいくパターンは、結局みなが求めるものです。まずAIにエージェント向けの返信を下書きさせ、下書きが正しくなったら、顧客へ単独で回答させます。
"The safest rollout I have seen is: let the agent draft, tag confidence plus reason, require approval for refunds or account changes, and review every reopened conversation for the first month. That review log is usually where the real automation boundary shows up."
この記事は、その4週間の実行手順書です。測定の部分（スコアカードに何を載せ、どう採点するか）は、AIサポートのパイロット用スコアカードにあります。公開前のテスト手順をより詳しく知りたい場合は、AIサポートエージェントのテストをご覧ください。
第1週の前に準備すること
第0週は数日にわたる数時間の作業で、パイロットの残りを読み取れるかどうかを左右します。AIが本番のチケットを1件でも見る前に、5つのことを整えておく必要があります。
- 名前の決まった責任者1人。 毎日のレビューを行い、変更を承認し、一時停止を判断できる人です。小さなチームではサポートリーダーが多いでしょう。セットアップを作った人と同じ人にはしないでください。Zendesk自身のテストガイドも、「select testers who aren't the same people who built your conversation flows」と述べているのと同じ理由です。
- ベースライン。 対象チケットタイプの前四半期の数字です。週次ボリューム、初回返信時間、再開または再問い合わせ率、そして人が処理したチケットのコストも含めます。取得方法はカスタマーサービスKPIのガイドにあります。
- 書き出した合格ライン。 拡大するために最後に何が成り立っている必要があるかです。新しく作るより、パイロットのスコアカードのゲートと目標をそのまま使い、初日の前にベンダーへ送ることをお勧めします。
- ルーティング計画。 どのチケットをAIキューに入れ、どの同種のチケットを人間のみの対照キューに残すか、そして後で取り出せるよう両方にどうタグを付けるかです。詳しくは後述します。
- 一時停止計画。 誰がAIを止められるか、ヘルプデスクのどこにスイッチがあるか、何が停止の理由になるかです。
そのうえで、サポートチームに何が起きているか、そして自分たちの役割を伝えてください。顧客からの苦情でパイロットを知ったエージェントは、何か月もAIを脅威として扱うでしょう。「あなたたちはレビュアーで、AIは注文状況の山を引き受ける」と伝えられたエージェントは、最良の不具合報告者になります。パイロット用のサポートSOP（誰が、いつレビューし、悪い回答をどこで報告するか）は10分で書け、Slackのやり取りを大きく減らせます。
| パイロットでの役割 | 担当 | かかる時間 |
|---|---|---|
| パイロット責任者 | セットアップを作っていないサポートリーダーまたはシニアエージェント | 1日15〜20分、加えて週次の報告 |
| レビュアー | エージェント2、3人。できれば新人を含める | 第1週は1人あたり1日10分、その後は減らす |
| ナレッジ修正担当 | ヘルプセンターの管理者 | 週に数件の修正。主に第1、2週 |
| エスカレーション窓口 | 返金とアカウントの権限を持つ人 | 引き継ぎに判断が必要なときのみ |
AIサポートのパイロット用チケットの選び方
多くのチームは、パイロット候補をトピックで分類します。私は、チケットを閉じるためにAIが何をしなければならないかで分類することをお勧めします。リスクがあるのはそこだからです。3種類あります。
- ドキュメントからの回答。 返品ポリシー、配送日数、使い方の質問。AIが間違えても、顧客が間違った一文を受け取るだけで、直すのは多くの場合1本の記事です。
- 参照のみの問い合わせ。 注文状況、配送追跡、プランの詳細。AIはシステムを読み、見つけたことを報告します。ここでの誤りは、誤った注文や状況を読むことで、深刻ですが何かが変わるわけではありません。
- お金やアカウントに関わる操作。 返金、キャンセル、住所変更、アカウントの編集。ここでの誤りは、すでに何かが起きてしまい、それを元に戻さなければならないということです。
パイロットは第1の種類から始め、毎日のレビューがきれいなら第3週に第2の種類を加えます。第3の種類は、パイロットが終わってから、承認の裏で扱います。この分け方は、ベンダー自身のテスト設定とも合っています。たとえばGorgiasは、テスト会話ではアクションをデフォルトでオフにしています。有効にすると「can affect real customer and order data (like cancelling an order)」だからです。
チケットタイプが採用されるまでには、さらに2つのフィルターがあります。ドキュメントがすでにそれに答えていること（答えていなければ、パイロットの発見ではなく、第0週のナレッジギャップ分析の仕事です）。そしてボリュームがあることです。週15件のレーンでは、1か月たってもほとんど何もわかりません。注文状況の問い合わせがよく選ばれるのはこのためで、ボリュームが多く、参照は1回で、リスクも低いからです。
判断を要するもの（苦情、チャージバック、怒っている顧客）は、パイロットの間ずっと人が担当します。ある運用担当者が、その基準をうまく言い表しています。
"Splitting it by impact makes more sense to me. A slightly awkward response is one thing but anything involving pricing, refunds or account changes should have a much higher bar."
狭くて構いません。大学進学とキャリア準備のソフトウェアを手がけるXAPは、Freshdesk上のeeselのセットアップを、1つの切り口から始めました。学生が、大学や州の機関が扱う事柄について質問してくる、丁寧で正確な案内が必要なチケットです。フィルターがそれらのケース（とポータルのパスワード再設定）だけを通し、eeselがチームの定型文から返信全文を社内メモとして下書きし、人が送信します。事例では、この紹介案内エージェントを「the first slice」と呼んでおり、他のポータル向けの案内ケースが加わるにつれてフィルターが広げられています。小さく、答えられ、確認しやすい、よくできたパイロットのレーンです。
自社のチケット構成を入力して、各タイプがどのレーンに入るか、そして第4週の終わりまでに判断できるボリュームがあるかを確認してください。
レーンが足りなければ、期間を延ばす前に、回答タイプのチケットをもう1つ加えてください。薄いレーンで期間を延ばしても、スコープが膨らむ時間が増えるだけのことが多いのです。
ヘルプデスクでAIキューと対照キューを分ける方法
同じチケットタイプを、同じチャネルで、同じ週に2通りで処理したいはずです。一方はAI、もう一方は人間のみです。人間のみの対照キューがなぜ数字に重要かは、スコアカードの記事で説明しています。ここでは、各ヘルプデスクで設定がどこにあるかを、2026年10月20日時点で各ベンダー自身のヘルプセンターで確認した内容でまとめます。
| ヘルプデスク | AIレーンの絞り込み | 対照キューの確保 | 一時停止 |
|---|---|---|---|
| Zendesk | AIエージェントごとのチャネル、メールエージェントのトリガー条件 | 対照グループ付きのランダムなtrafficSplit（アカウントマネージャーが有効化、A/Bテスト）、または別のサポート用アドレス | Manage channelsでチャネルの選択を外す |
| Freshdesk | チケットのソース、「Deploy to internal teams」、最大5階層のAND/ORを使うカスタムルール | レーンの一部を除外するカスタムルール（メールボックス、顧客属性） | Daily conversation limitsの上限、またはそのソースでエージェントを無効化 |
| HubSpot | デプロイごとに1チャネル、営業時間、メールの対象・除外リスト | Conversation coverageの割合（残りは人へ） | customer agentの割り当てをオフにする |
| Gorgias | AI Agent > Deployでチャネルごと、スキルは1つずつ | レーンのチャネルまたはスキルをオフのままにして比較 | スキルを「without affecting others」でオフにする |
| Help Scout | Beaconごと、受信箱ごと。メールは「Only customers matching these conditions」に限定可能 | 同じ受信箱で「except ones matching these conditions」のスコープ | Enableの切り替え（Beaconまたは受信箱ごと） |
これらのページから、設定のしかたに影響する細かい点をいくつか挙げます。
- Zendeskでは、1つのチャネルで同時に動かせるAIエージェントは1つだけで、メッセージング用に作ったエージェントは後からメールに切り替えられません。構築する前にチャネルを決めてください。
- Freshdeskの本番開始は前方のみ有効です。 デプロイ前に届いたチケットには「are not retroactively answered」なので、パイロットの初日はきれいな状態で始まります。
- HubSpot自身の助言は、ここでの段階的な広げ方と一致しています。 「a single channel or limit it to a small percentage of conversations」から始め、拡大する前にエスカレーションとナレッジの不足を確認します。一時停止中は「it keeps existing chats but won't get new ones」です。
- Gorgiasには受信箱ビューがあり、AIが対応中のチケット、閉じたチケット、引き継いだチケットを見られます。これは基本的に、毎日のレビューキューがすでにできているということです。
Help Scoutの条件ビルダーは、レーンをどこまで細かく絞れるかのよい例です。AIは、タグや担当者ルールに一致するチケットにだけ返信します。
どのヘルプデスクでも、初日から両方のキューにタグを付けてください（ai_pilotとai_controlで十分です）。名前の付け方はAIサポートのタグ付けのガイドに詳しくあります。第4週には、ベンダーのレポートに頼らず、両方のデータをスプレッドシートに取り出したくなるはずです。
第1週：顧客の目に触れる前のシャドウモード
シャドウモードとは、AIがレーン内の実際の受信チケットを処理しつつ、書くものはすべて下書きか社内メモという状態です。人がそれを読んで採点し、送信するか、編集するか、無視します。顧客には何の違いも見えません。顧客リスクはなく、修正可能な問題のほとんどはここで見つかります。
シャドウの週が始まる前に、推測ではなくスコアを持って臨めるよう、AIを過去のチケットで動かすことをお勧めします。今ではほとんどのヘルプデスクに、無料で行える方法があります。
- FreshdeskのメールAI Agent評価は、1回の実行につき最大50件のクエリまで「to use solved historical tickets」をImport ticketsでき、Freshworksは「at least 20 representative queries before deploying」を推奨しています。プレビューは「does not affect live conversations or consume message limits」です。
- HubSpotのバッチテストは、実際の会話のテーマからテスト用の質問を作成し、プレビューやテストではHubSpot Creditsを消費しません。
- Gorgiasのテスト会話は「are free to use」で、「an existing ticket」を1件ずつ再生できます。
- Zendeskのサンドボックス、テストウィジェット、会話シミュレーターは自動解決を消費しませんが、本番でテストしたメールエージェントは消費します。Freshdesk側の同等の手順は、Freshdeskのサンドボックス設定のガイドで扱っています。
シャドウの週の間は、レビュアーに各下書きを3段階で採点してもらいます。そのまま送信、編集して送信、誤り、です。「誤り」には必ず短いメモを残してください。金曜日までにリストができ、そのリストが第2週の修正計画になります。「あなたは間違っている、返金して」といった、押しの強い意地悪なチケットも混ぜてください。敵対的テストのガイドに、借りられるセットがあります。
最初は「編集して送信」が多くなると予想しておいてください。慌てる必要はありません。あるジュエリー小売店のeeselでの試用では、エージェントが下書きに加えた編集のほとんどは長さとトーンに関するもので、これはAIがチーム自身の送信済み返信から学ぶと改善するタイプのものでした。事実の誤りを直す編集は、ごく一部でした。これは「AIが間違っている」とはまったく異なる発見で、レビュアーが編集した理由を書かなければ見えてきません。
第1週の終了テストは単純です。「誤り」の山が小さく、その中の各項目に、すでに行った修正か、そのチケットタイプをレーンから外す理由のどちらかがあることです。
第2週と第3週：一部で本番に出し、その後広げる
第2週から、AIが顧客に回答を始めますが、レーンの一部だけです。私は10〜20%から始めます。HubSpotのcoverageフィールドなら直接設定でき、他のヘルプデスクでは、顧客属性やメールボックスに対するルールで実現できます。レーンの残りは人が担当し、それがそのまま対照キューになります。
この2週間の3つのルールです。
- きれいな期間が続いてから広げる。 毎日のレビューが3、4営業日きれいだったなら、第3週に約20%から約半分へ進みます。そうでなければ今の位置にとどまり、まず直してください。
- 一度に変えるのは1つだけにして、日付を記録する。 レーンの拡大と新しい指示を同じ日に入れると、どちらが数字を動かしたのかわかりません。英国で個人向けナンバープレートを販売するSwiftregは、eeselのサポート指示を番号付きのリリースとして管理し、ライブで編集するのではなく自社の手順でロールアウトしています。ほとんどのパイロットには過剰なプロセスですが、変更ごとにバージョンと日付を持つという習慣は正しいものです。
- 操作の前に、参照のみの問い合わせを加える。 第2週が回答のみのチケットできれいだったなら、第3週が注文状況や配送追跡を加えるタイミングです。操作はオフのままです。
本番の初日から、「人に話す」経路をわかりやすくしてください。行き詰まって人が見つからない顧客は、ほとんどのダッシュボードでは失敗として現れず、途中離脱した会話や、別のチャネルでの怒りのチケットとして現れます。AIエージェントの引き継ぎのチェックリストでは、担当者が聞き直さなくて済むよう、引き継ぎに何を含めるべきかを扱っています。
開示については、顧客にAIと話していると伝えることをお勧めします。Swiftregは、すべての公開AI返信の末尾に、AI Support Assistantが書いたものであり誤りを含む可能性があるという注記を付けています。HubSpotのライブチャットは、customer agentが割り当てられている間、ヘッダーに「Powered by AI」と表示します。期待値を揃えられ、誤答も許されやすくなります。
パイロットを左右する毎日のQAレビュー
これは、明確な判断で終わるパイロットと、議論で終わるパイロットを分ける習慣です。毎日同じ時間に15分、シャドウの週から第4週の終わりまで続けます。
15分に含めるもの。
- AIが行ったすべての操作（オンにしているものがあれば）。返信だけでなくログを読んでください。返信が完璧に読めても、その下にある注文番号が間違っていることがあります。
- AIキューで再開された、または再問い合わせのあったすべての会話。 ダッシュボードが成功として数えてしまうミスです。
- すべての引き継ぎ。 人が聞き直さずに続けられるだけの情報を受け取れたか。
- 「解決済み」の山からのサンプル、1日10〜20件。Gorgiasは、本番開始の一環として最初の週に「at least 10 tickets that AI Agent handled」をレビューするよう勧めています。私はこのペースをパイロット全体で保ちます。
そのうえで、各ミスを原因でタグ付けします。原因ごとに直し方も担当者も違うからです。
| ミスの原因 | 見え方 | 修正 | 誰が直すか |
|---|---|---|---|
| ナレッジの不足 | 古い、または存在しない記事から回答した（「we support all models」） | 記事を編集または追加し、そのトピックを再テスト | ヘルプセンターの管理者（ナレッジベース監査） |
| 指示 | 事実は正しいが振る舞いが誤り：長すぎる、トーンが違う、引き継がなかった | ルールを1つ追加または厳格化 | パイロット責任者 |
| データの欠落 | 見られない注文、アカウント、システムが必要だった | データソースを接続するか、そのチケットタイプをレーンから外す | 連携の担当者 |
| ルーティング | レーンに入るべきでないチケットが入った | フィルターやトリガーを絞る | ヘルプデスク管理者 |
3列の共有変更ログをつけてください。日付と変更内容、そして変更した理由です。Zendeskのテストガイドも、テスターに同じことを勧めていて、「track whether a resolution has been implemented」ための共有ファイルです。第3週に数字が動いたとき、火曜日に直した記事によるものか、水曜日に広げたレーンによるものかを、ログが教えてくれます。2人のレビュアーが、ある返信が「誤り」かどうかで意見が分かれたら、短いQAキャリブレーションで採点基準をそろえれば、意見の食い違いが結果のノイズになるのを防げます。
このレビューの責任者は技術者である必要はありません。北海の島々へ向かうドイツのフェリー会社Norden-Frisiaでは、サポートリーダーのFrauke Hagenさんが、eeselのセットアップを1人で運用しています。会話履歴を確認し、回答がFAQと食い違っていれば問い合わせ、Zendeskのボットからチャットボットへ修正を自分でコピーしています。試用はわずか1週間で、契約を決めたのは過去のチケットでの学習でした。
"I think the key is testing the decision separately from the conversation. An agent can have a perfectly polite chat and still issue a refund it wasn't allowed to. If it has to state which policy and limit it applied before it takes any action, you can check that against the rule instead of reading through transcripts."
AIサポートのパイロットを途中で一時停止するとき
一時停止のルールは第0週に書いておき、調子の悪い火曜日に誰も議論しなくて済むようにしてください。次のいずれかが起きたら、その日のうちにAIキューを一時停止します。
- 誤った操作が顧客に届いた：誤った注文への返金、誤ったアカウントへの変更。
- AIが存在しないポリシーを述べた、またはチームが実現できないことを約束した。
- 人への取り次ぎを求める顧客の割合が、直近数日と比べて急増した。
- ポリシーが変わったのに、ナレッジが追いついていない。 新しい返品期間、新価格、障害など。記事が更新されるまで一時停止し、そのトピックを再テストします。ポリシー変更管理のガイドにチェックリストがあります。
スイッチの場所がわかっていれば、一時停止は簡単です。Zendeskではチャネルの選択を外すことで行い、独立した一時停止ボタンはありません。
HubSpotでは「manually pause customer agent assignment by turning it off」でき、これは「when updating or reviewing content sources or making changes to the agent's configuration」に勧められています。Freshdeskの1日の上限は、より穏やかなブレーキです。「Conversations continue to arrive but the AI stops replying once the limit is reached」とあります。どれを使うにしても、一時停止はパイロットの失敗を意味しません。日付と理由を記録し、原因について短いエラー分析を行い、修正できたらそのレーンのカウントを最初からやり直してください。
第4週とその後：拡大、再テスト、中止
第4週は維持の週です。新しいチケットタイプも、カバー率の変更も、何かが実際に壊れていない限り新しい指示も加えません。最後の変更を落ち着かせ、最終週が安定した1つのセットアップを反映するようにします。そして、ベンダーの解決判定期間と自社の再問い合わせチェックが数え終わるまで少し時間がかかるため、判断の会議はパイロット終了の1週間後に設定してください（タイミングはスコアカードで説明しています）。
判断自体は3つのうち1つで、それぞれが翌月に具体的な意味を持ちます。
| 判断 | いつ | 次にやること |
|---|---|---|
| 拡大 | ゲートを守り、レーンで目標を達成した | 1段階上げる：次の回答タイプのチケット、または参照のみの問い合わせ、またはチャネルを1つ追加。1つずつ、同じ毎日のレビューで |
| 修正して再テスト | 安全だが目標に届かない | 変更ログの主な原因に取り組み、過去チケットの再生をやり直し、同じレーンでさらに2週間 |
| 中止 | ゲートが失敗した、または顧客が対照キューより多く戻ってきた | 整理した記事とチケットのタグは残し、理由を書き残して、別のツールやより狭いレーンで2回目のパイロットを行う価値があるか決める |
「拡大」では、多くのチームがいきなり返金に飛びつきたがります。私は操作をもう1サイクル待たせ、まず承認ワークフローを通すことをお勧めします。AIが返金を準備し、人が承認し、人が反対する頻度を数えます。その数字が数週間ほぼゼロなら、定型的な操作は自動で動かせます。高額の返金、チャージバック、返金承認マトリクスの上限を超えるものは、人が担当し続けます。
チームがAIパイロットで犯しがちな失敗
- 名前の決まった責任者がいない。 毎日のレビューが「手の空いた人」になり、木曜日には誰もやらなくなります。
- 「本当に試すため」に最も難しいチケットでパイロットする。 難しいチケットは難しい、とわかるだけです。AIが勝てるところから始め、そこから広げてください。
- すべてのチャネルを一度に。 チャットとメールの両方で悪い週があっても、どちらが原因か突き止められません。
- 1日に3つのことを変える。 どれが効いたのか、どれが返品を壊したのかわかりません。
- ビフォーアフターが明らかに見えるからと、対照キューを省く。 チケットの構成や季節性も変動します。
- チケットではなくベンダーのダッシュボードを読む。 ダッシュボードが示すのは終わった会話の数であって、正しかったかどうかではありません。より長いリストはAIカスタマーサービス導入の失敗にあります。
eeselでAIサポートのパイロットを実施する
eeselは、Zendesk、Freshdesk、Gorgias、HubSpotなどの既存のキューに加わるAIヘルプデスクのチームメイトで、この記事で説明した方法でパイロットできるように作られています。
- 自社の履歴から第0週のスコアを出す。 Simulationスキルは、エージェントを実際の過去のチケットに対して動かし、チームが送った内容と照らして各回答を採点し、指示の変更案を提示します。顧客には何も送信しません。
- デフォルトでシャドウモード。 下書きから始まります。すべての返信は、人が送信する下書きまたは社内メモです。準備ができたら簡単なものを最初から最後まで回答させ、いつでもすべてをオフに戻せます。
- 承認の裏の操作。 各アクションはAuto、Needs approval、Disabledのいずれかで、承認がタイムアウトで自動実行されることはありません。返金はパイロット中ずっとNeeds approvalのままにできます。
- すでに整った毎日のレビュー。 Activityページには、処理したすべてのチケット、検索した内容、各アクション、承認者、そしてその根拠が並びます。実行の横のチャットで修正すると、その修正が指示内のルールになり、来週も修正が効き続けます。
料金は固定の月額プランで、1チケットまたは1チャットが1クレジットです。カード不要で100クレジットまで無料、その後は500クレジットで$299/monthからです。何かに契約する前に、自社のチケットで下書きを見るには無料プランで十分です。どのベンダーでもパイロットを始めようとしているなら、まず自社のキューでeeselのシミュレーションを実行し、そのレポートを比較に持ち込んでください。eeselを試す。