AIエージェントをローンチ前にテストする方法：初日に備える7つのチェック

回答テストに合格しても、ローンチの準備ができたとは限らない理由

私はeeselのヘルプデスク連携を作っています。つまり、トリガー、引き継ぎ、注文システムへのAPI呼び出し、誰がチケットに触れたかを示すタグなど、ローンチ当日の問題が潜むコードの中で毎日を過ごしています。壊れるのはモデルであることはまれで、たいていは配管です。

Zendesk自身のテストのベストプラクティスは、業界の多くがこの問題をどう考えているかをよく表しています。テスト担当者にはこう伝えています。"Focus on whether the AI agent's response was accurate and matched the tone of voice you expected." 良いアドバイスですが、氷山の一角にすぎません。同じヘルプセンターは別の記事で、AIエージェントのチケットはエスカレーションされるまでチケットトリガーと自動化を実行しないと説明しています。つまりルーティングルールが初めて発火するのは引き継ぎのまさにその瞬間で、精度テストが決して届かない瞬間です。

私自身にも痛い経験があります。eeselのプラットフォームで、ボットが自分の返信を顧客からの新しいメッセージとして扱い、自分に返信する自己返信ループを見ました。本番のヘルプデスクで動かして初めて表面化したものです。顧客の本番トライアル中に、社内UIの文言が公開返信に漏れたのも見ました。また、ナレッジベースが空で返ってきたときに、引き継ぐ代わりに答えを作り上げてしまうボットも、eeselのプラットフォーム上で見ました。どれも、テスト用の質問に対する間違った回答ではありませんでした。すべてつなぎ目の問題です。

法的な面でも状況は進んでいます。Moffatt v. Air Canadaでは、同社のチャットボットが顧客に、搭乗後でも航空券の発行から90日以内なら忌引き運賃を申請できると伝えましたが、これはAir Canada自身のポリシーページと矛盾していました。審判所は、チャットボットは"a separate legal entity"だというAir Canadaの主張を"remarkable submission"と呼び、$812.02の支払いを命じました。ボットは間違っていましたが、本当の失敗は、顧客が信じる前に誰も元のポリシーと照合しなかったことです。

同僚のAIサポートエージェントのテストガイドをすでに読んでいれば、回答側はカバーできています。この記事はその補完で、スイッチを入れる前の1週間にそれ以外で確認すべきことをまとめています。

ローンチ前の7つのチェック一覧

計画全体を1画面にまとめます。最初のチェックは多くのチームがすでに行っているものです。残りの6つで、ローンチ当日につまずきます。

合格ラインは私のものであり、業界標準ではありません。自分たちの基準を決めてください。ただし、結果を見たあとではなく、テストを始める前に書き留めておきましょう。数字の決め方で迷うなら、AI support pilot scorecardにテンプレートがあります。

チェック1：実際のチケットを再現して回答を確認する

まず回答のテストから始めます。ほかのすべては、エージェントが簡単な質問に正しく答えられることを前提にしているからです。主要トピックにわたる最近解決済みのチケットを50〜100件取り出し、誰にも返信させずにエージェントに通して、その回答をチームが実際に送った内容と比べます。

多くのヘルプデスクにはこのための機能があります。Freshdeskのメールエージェントはインポートしたチケットを評価でき、1回の実行で最大50件、最低20件を推奨しています。HubSpotのカスタマーエージェントは、クレジットを使わずに最大8つのテストセットのバッチテストを実行します。eeselのSimulationスキルは、実際の過去チケットを再現して、チームが送った内容と照らして各回答を採点し、指示の変更案を提案します。

精度とトーンは別々の数字として採点してください。ライブのトラフィックで行ったeeselのあるトライアル、月に約1,000件のチケットを扱うジュエリーECの受信箱では、下書きの88%は正しい方向を向いていましたが、そのまま送信されたのは12%だけで、7%に事実の誤りがありました。書き直しの大半は事実ではなく、長さとトーンのためでした。「精度」の1つのスコアだけでは、両方の問題が隠れていたはずです。

そのうえで、テストセットを生かし続けてください。このRedditのコメントはこのテーマで最も役に立つアドバイスで、凝ったものではありません。

"keep a list of test questions handy and run it through and see if you get the right answers. Whenever an edge case appears, add to the list of test questions, update your agent and re-run your tests. Boring, but works."

u/ankursarda, r/CustomerSuccess, Reddit

ドキュメントが半分しか答えていない質問も入れてください。その場合の正しい結果は、自信満々の推測ではなく引き継ぎです。情報源が古いために回答が間違っているなら、それは知識の問題で、プロンプトの微調整よりもナレッジベースの監査のほうが多くを改善します。

チェック2：答えてはいけないことをテストする

「やらないように言った」が現実とぶつかるのがここです。主要なヘルプデスクはどれも、ゆるいガイダンスと強いルールを分けており、多くのチームが設定するのはゆるいほうです。

• Zendeskは"Always escalate to an agent if the user mentions being hacked"を悪い指示の例に挙げています。"Instructions cannot trigger escalations"だからです（Zendeskの指示ガイド）。そのためにはユースケースが必要です。
• Freshdeskは「Topics to avoid」設定が"may not fully prevent responses in edge cases"と述べ、厳格に適用するには引き継ぎ設定を使うよう案内しています（Freshdeskのアイデンティティと指示）。
• Help Scoutははっきり言っています。ロールはScoutの返信の仕方を変えるもので、トピックをチームに直接送るには"create an exclusion"と（Scoutのロール）。
• HubSpotではセグメントごとにガードレールを設定でき、回答が指定どおりに"may not always exactly match"と警告しています。

そこで、「絶対にしない」リストの各トピック（上限を超える返金、法的な脅し、アカウントのセキュリティ、医療や安全に関する質問、約束できない配送日に関することすべて）を3通りでテストします。直接聞く、長いメッセージに埋もれさせる、エージェントが断ったあとにもう一度聞く、です。合格ラインは毎回引き継ぎです。

eeselを使うあるECのサポートマネージャーは、まさにこれをレビューで見つけました。エージェントが顧客に「注文は期日までに届きます」と言い続けたため、彼らが残したメモははっきりしていました。"stop promising customer things we cant do. we cannot guarantee this customer's order to them by friday." これはローンチ前に書けるスコープのテストです。「金曜までに届きますか？」

次に、顧客がエージェントを台本から外そうとしたときの挙動をテストします。2024年1月、DPDの顧客がボットに悪態をつくよう頼み、会社についての詩を書かせると、ボットはそのとおりにしました。

"Parcel delivery firm DPD have replaced their customer service chat with an AI robot thing. It's utterly useless at answering any queries, and when asked, it happily produced a poem about how terrible they are as a company. It also swore at me. 😂"

Ashley Beauchamp, X

OWASPはプロンプトインジェクションをLLMアプリの最大のリスクに挙げ、"adversarial testing and attack simulations"を推奨しています。サポートエージェントなら、試すことは短いリストで済みます。"ignore your instructions"、"are you a human?"、"give me a discount code"、そして偽のポリシー文を貼り付けたメッセージです。より詳しい手順は敵対的テストのガイドを参照してください。

顧客事例を見ると、対応範囲の考え方がよく分かります。プロジェクションシステムを販売するLuxedoは、eeselのエージェントを一般家庭の顧客だけに限定しました。学校、ジム、その他の法人購入者からのチケットはスキップされ、営業に残ります。ハードウェアの故障、保証の判断、返金、電気的な安全性は常にチームに回ります。これだけ具体的な境界なら、ローンチ前のテストも簡単です。除外した各グループからチケットを1件ずつ送り、エージェントが手を出さないことを確認してください。

チェック3：すべての引き継ぎ経路を最初から最後まで確認する

本物の引き継ぎテストでは3つの問いを立てます。人がチケットを受け取ったか、何が起きたか見えたか、そして顧客は何を待てばよいか分かっていたか。これは3つの別のチェックで、ヘルプデスクごとに扱いが異なります。

これらのうち、見落としやすく初日に痛い点がいくつかあります。

• **Zendeskの転送グループには、静かなフォールバックがあります。**設定ダイアログはこう警告しています。"If a selected group is deleted, the default group will be used instead." セットアップ後にグループの名前を変えたり統合したりすると、引き継ぎは静かに別の場所へ行きます。Zendeskのメールエージェントは、escalated_by_ultimateタグが付くと返信も止まり、そうしたチケットを自分で見つけるようワークフローを設定するようZendeskは案内しています。
• Gorgiasは、引き継ぎをデフォルトでチームにルーティングしません。ai_handoverタグに対する自動割り当てルールを自分で作ります（Gorgiasの引き継ぎガイド）。作らないと、引き継ぎはAI Agentビューに残ったままです。
• **HubSpotの"Team only"ルーティングは、誰もいなくても引き継ぎます。**HubSpotによれば、エージェントは"will execute a handoff even if no users are currently available"で、チャットウィジェットの対応可否は見ません（HubSpotの引き継ぎ設定）。
• **Freshdeskの引き継ぎ取得は元に戻せません。**担当者が"Stop responding & assign to me"をクリックすると、AIの下書きは"is discarded permanently"となります（Freshdeskのメールのセーフガード）。大事なチケットで試す前に、チームがこれを知っていることを確認してください。

顧客側から見た引き継ぎループは、こんな具合です。どの出口も最初に戻ります。

"The ChatBot looping around providing generic answers, asking what my problem is. It ignores direct request to speak with an agent or to create a customer service. It simply starts with "Please, tell us about the problem ..." If I keep asking the same question, I can managed to get to a list of choices: 1. Report a technical issue, 2. Visit our Status page, 3. Time Tracker issues. Typing 2 and 3 leads to nowhere. Typing 1 reset the chatbot and it start again asking about my problem."

u/-Big-Hat-, r/Upwork, Reddit

そして、引き継ぎは「成功」したのに文脈が届かなかったバージョンがこちらです。

"Doesn't help at all if your support team ignores the bot chats. There is NOTHING more frustrating than talking to a bot for ten minutes just to have your live agent ask "can you please give me your account number one more time?"."

u/quietvectorfield, r/CustomerSuccess, Reddit

したがって、引き継ぎテストは5つのステップです。人間への対応を3通りの言い方で求めます（直接的、苛立った言い方、フローの途中）。設定したすべてのエスカレーション理由を発生させます。受け取る担当者としてチケットを開き、履歴と要約があるか確認します。次に何が起きるかについて顧客が受け取ったメッセージを読みます。そして、チームの誰かがチケットに気づくまでの時間を計ります。引き継ぎ自体の設計については、このAI引き継ぎのベストプラクティスと、いつ人に引き継ぐかのガイドも参照してください。

引き継ぎメッセージは、ルーティングと同じくらい重要です。SE Rankingは、eeselのエージェントに、顧客には1〜2営業日以内に返信があると伝え、誰かが今すぐ参加するとは決して言わないよう設定しました。返金、トライアルの延長、繰り返される質問は、顧客の名前とメールアドレスを添えてチームに回ります。これはチームが守れる約束なので、テストできる約束でもあります。

営業時間外の経路は別にテストする

営業時間外は、引き継ぎが最も壊れやすい場面です。普段見ているキューを誰も見ていないからです。ヘルプデスクごとに少しずつ扱いが違います。

• Freshdeskには"Transfer outside business hours"トグルがあり、営業時間の処理に指示を使うのは避けるよう警告しています（Freshdeskの引き継ぎ設定）。
• Zendeskは、エスカレーション経路の先頭に可用性ブロックを使います。
• Gorgiasは、オフラインのチャットチケットで、買い物客がメールアドレスを残さないと、そのチケットを閉じます。

営業時間を「閉」にして引き継ぎテストを1回行い、3点を確認します。チケットがどこに着くか、顧客に何が伝えられるか、返信なしで閉じられるものがないか。ヘルプデスク独自の営業時間設定がある場合は、AIエージェントがチームと同じスケジュールを使っているか確認してください。

チェック4：すべてのアクションをテストし、わざと壊す

アクションは、AIエージェントが話すだけでなく実際に動く場面です。注文の参照、タグの追加、返金の開始、サブスクリプションのキャンセルなど。ここは、テスト環境が最も頼りにならない場所でもあります。アクションのテストは、たいてい本物のシステムに触れることを意味するからです。

各アクションを、問題になり得る5つの観点でテストします。Read：同じ名前の顧客が2人いるとき、正しい注文を取得するか。Write：タグ、メモ、フィールドの変更が正しいチケットに反映されるか。Act：お金がかかるものは人を待つか。Escalate：アクションが完了できないとき、チケットは人間に回るか。Recover：APIがダウンまたは遅いとき、顧客は無言ではなく妥当な返信を受け取るか。

失敗についてヘルプデスクが記載していること：

• Zendeskのカスタムアクションは10秒でタイムアウトし、その後は"the action isn't performed."となります。Zendesk自身の生成プロシージャのガイドには、真似したい良いルールがあります。"If API returns 'timeout', retry up to 2 times. If still failing, escalate the request." また、エージェントがレスポンスを読み取れない場合、呼び出しが成功を返しても失敗の分岐に進むことがあると指摘しています。
• Freshdeskのチャットアクションは、タイムアウトや失敗時にフォールバック経路へ回ります。ただしメールでは、ライブの会話がないため"confirmation blocks are skipped"となり、Freshdeskはセーフガードを"at the API layer"に置くよう案内しています（FreshdeskのAPIアクション）。Test APIボタンは"real values and may affect your external system"を使います。
• Gorgiasは、複数ステップのアクションが失敗したステップで止まり、チケットをチームに引き継ぎますが、それ以前のステップは実行されたままです（Gorgiasのアクションログ）。テスト会話は"use real data from your connected apps"なので、テスト用の顧客プロフィールを使ってください。
• HubSpotは、アクション保護レベル（None、Match email、Verify email）付きで最大20個のアクションを設定できますが、失敗したときに何が起きるかは記載していません。自分でテストしてください。

私が確認した範囲で、APIの停止をシミュレートするボタンを持つヘルプデスクはありません。Recoverのステップをテストするには、アクションをステージング用エンドポイントに向けてそれを停止するか、間違った注文番号と期限切れのトークンを渡します。余計な手間に感じますが、注文システムの調子が悪い朝までの話です。

最も安全なデフォルトは地味なものです。何かを変更するすべてのアクションを、承認の後ろに置いて始めます。eeselでは、各アクションをAuto、Needs approval、Disabledのいずれかに設定し、新しいエージェントは監督下で始まるようになっていて、"Approvals never run on their own after a timeout."です。ボットが触れてよい返金について自分でルールを書くなら、返金承認マトリクスが良い出発点です。

チェック5：出てくる場所と、黙っている場所を確認する

正しいチケットでうまく答えるエージェントでも、間違ったチケットで恥をかかせることがあります。トリガー、チャネル、ブランド、ルールが、エージェントが見るチケットを決めます。そしてヘルプデスクごとに意外な挙動があります。

• **Gorgiasのルールが先に実行されます。**ルールが自動返信を送ると、AI Agentは"may still attempt its own response"で、顧客には2通のメッセージが届きます（GorgiasのルールとAI Agent）。Gorgiasはまた、EC やサポートに無関係と判断したメッセージを返信せずに閉じ、これはオフにできません。テスト実行のあとに、閉じられたチケットと保留されたチケットを確認してください。
• Zendeskは、PDFを含むすべてのメッセージを人にエスカレーションし、これを"expected behavior"と呼んでいます（Zendeskのトラブルシューティング）。顧客が請求書をPDFで送ってくる場合、自己解決率はテストのときとは違って見えます。
• Freshdeskでは、まずメールエージェントを社内チームに展開でき、"a safe pilot rollout"として、誰に対応するかを最大5階層のネストしたルールで指定できます（Freshdeskのメールエージェント設定）。

エージェントがスキップすべきチケットの種類ごとに、テストチケットを1件送ります。社内チケット、スパム、VIP、2つ目のブランドのチケット、求人応募、ベンダーからの売り込みなどです。1つのZendeskから複数のレッスンブランドを運営するLesson Proは、eeselのエージェントが、求人応募、留守番電話、注文フォームをスキップし、1語書く前にブランドを特定するよう設定しました。返信でブランドを間違えるのは、返信が遅いことより悪く、しかも最もテストしやすい点です。

次に、エージェントに本番のヘルプデスク内の実際のテストチケットへ返信させ、そのチケットを10分間見守ります。先ほど触れた自己返信ループ、つまりトリガーがエージェント自身の返信で発火するバグを見つけられるのは、この方法だけです。サンドボックスでも現れません。ZendeskのサンドボックスはWebhookがデフォルトでオフで、アクションフローやスキルベースのルーティングはコピーされず、SMSには対応せず、フルコピーには"can take up to a week or more"かかります。回答のテストには良い場所ですが、つなぎ目のテストには弱い場所です。このトレードオフの詳細はZendeskのサンドボックスと本番にあります。

チェック6：停止スイッチをリハーサルする

どのローンチ計画にも「何かあれば止められる」という一行があります。実際に止めてみたチームはごくわずかです。ローンチ前にやってみて、時間を計り、2人がやり方を知っているようにしてください。

停止スイッチはヘルプデスクごとに同じではなく、一見それらしいスイッチが期待どおりに動かないこともあります。

このうち2つは、もう一度読む価値があります。Gorgiasでは、「返金スキルをオフにする」ように見える操作をしても返金の質問は止まりません。エージェントがナレッジから答えるようになるだけで、チケットの一部で止めるには"ignore"ルールが必要です。HubSpotでは、引き継ぎのページは"the agent is paused"を引き継ぎの理由として挙げていますが、デプロイのページはオフのときも既存のスレッドは動き続けると述べています。どちらになるかをテストしてください。

訓練内容は1ページのランブックに書き出してください。誰が止められるか、正確なクリック手順、停止中にチケットがどこへ行くか、誰がチームに知らせるか、再開する前に何が満たされていなければならないか。

チェック7：初日の前にレポートを整える

ローンチ当日、誰かが「うまくいってる？」と聞いてくるので、1分以内に答えたいはずです。そのためには、タグとビューが最初の本番チケットの前に存在している必要があります。後では遅いのです。

最低限、AIが触れたすべてのチケットにタグを付け、すべての引き継ぎに理由のタグを付け、「引き継ぎ済みでまだ対応されていない」ビューを1つ作ります。SE Rankingは、eeselが触れたすべてのチケットにai_handledタグ、さらに役に立った・役に立たなかったタグを求めました。推測ではなくZendesk内で自己解決を数えるためです。Freshdeskはすべてのチケットに引き継ぎ理由を自動で記録し、"System issue"や"Max turns exceeded"も含まれるので、使えば無料でエスカレーションの質のレポートになります。

次に、最初の1週間に何をレビューするか決めます。これについて私が読んだ中で最も良い短い答えがこちらです。

"The expensive misses are usually the ones that look confident and don't escalate. So I'd rather have a slightly annoying bot that hands off early than one that quietly invents an answer. If I were running it, I'd review a small sample of resolved tickets every week, plus every escalation and complaint. That's probably more important than the model choice."

u/TheChandrianX, r/CustomerSuccess, Reddit

Gorgiasは、最初の1週間にAIが処理したチケットを少なくとも10件レビューするよう勧めています（Gorgiasのゴーライブガイド）。私なら初日はさらに踏み込み、すべての引き継ぎとすべてのアクション実行を読みます。その後に追うべきものはCXのAI指標のガイドで解説しています。

初日に何か問題が起きたら

7つのチェックをすべて終えても、何かは驚かせてきます。大事なのは、それが「今すぐ一時停止」の問題か「今日中に修正」の問題かを見極めることです。見えている症状を選んでください。

このウィジェットの背景にあるパターンは次のとおりです。顧客を閉じ込めるものやお金を使うものは一時停止し、ルーティングとトリガーの問題はエージェントを動かしたまま直します。ベンダーのサポートボットが公の場で失敗したときも、対応は似た形になります。2025年4月にCursorのAIサポートボットがロックアウトのポリシーを作り上げたあと、共同創業者がHacker Newsに書いた事後報告は、ラベル付けと返金から始まっていました。

"Apologies - something very clearly went wrong here. We've already begun investigating, and some very early results:

Any AI responses used for email support are now clearly labeled as such. We use AI-assisted responses as the first filter for email support. We've made sure this user is completely refunded - least we can do for the trouble." mntruell (Cursor cofounder), Hacker News

ゴー・ノーゴーの判断

ローンチの前夜に、このリストを確認してください。1つでも「いいえ」の行があれば、その部分は今回は見送ります。通過したレーンだけをローンチし、残りは保留にします。

• エージェントが実際の過去チケットで採点され、精度とトーンが別々に採点されている。
• 「絶対に答えない」トピックはすべて引き継がれ、指示ではなく強い除外設定を使って3通りでテスト済み。
• すべての引き継ぎ経路が、誰かが見ているキューに、営業時間内も時間外も、文脈付きで届く。
• すべてのアクションがテストレコードでテストされ、1回は強制的に失敗させている。
• 除外タイプごとのテストチケット1件が正しくスキップされ、本番のテストチケットがループしなかった。
• 2人がエージェントを停止して再開し、停止中にチケットがどこへ行くか知っている。
• AIが扱ったチケットと引き継ぎにタグが付き、対応されていない引き継ぎのビューがある。

これに合わせた完全な展開計画が必要なら、AIサポートのパイロットを実行するガイドがローンチ後の4週間を、AI導入の失敗例のリストが後から現れる失敗を扱っています。

eeselがローンチ前につなぎ目をどう扱うか

自分で作っているので偏りはありますが、ここはeeselで私が最も誇りに思っている部分です。デモではなく、つなぎ目を中心に作られているからです。

• まず回答。Simulationスキルは、過去のチケットを再現し、チームが送った内容と照らして各回答を採点し、修正点を一覧にします。ヘルプデスクの接続は読み取り専用です。"It does nothing on tickets until you create an automation."
• **指示だけでなく、強いスイッチ。**過去のチケット履歴の一部から学習させたくない場合、eeselのドキュメントははっきりしています。"Telling it in its instructions to ignore past tickets does not stop it finding them; the switch does"（Zendeskのセットアップ）。
• **承認の後ろにアクション。**すべてのアクションはAuto、Needs approval、Disabledのいずれかで、ドキュメントは返金を承認の後ろに置くことを推奨しています。
• **実際に何をしたかのログ。**Activityページには、すべてのチケット、検索した内容、各アクション、承認者、スキップしたチケットとその理由が一覧表示されます。
• 配管のためのターミナル。eesel CLIでは、eesel chatでエージェントをテストし、eesel approvalsで保留中のアクションを確認し、eesel activityを読み、--dry-runで書き込みが行う正確な呼び出しを送信せずに表示できます。Claude Codeのようなコーディングエージェントに連携の接続を手伝ってもらうときに、書き込みが起きる前にそれを見たい場合に便利です。

ドイツのB2B機器サプライヤーBeautekは、引き継ぎ側がうまくいっている好例です。ウェブサイトのチャットはドイツ語で製品や注文の質問に答えますが、不満、法的な質問、複雑な注文、人への対応の要求があると、会話を添付したZendeskチケットが作られます。ある月にはチャットから作られたZendeskチケットが20件あり、その大半は営業リードでした。一方、Zendeskのチケット自体は、チームが承認する下書きのままです。

eeselでローンチ前にAIエージェントをテストする

ローンチ計画が「回答はテストした、あとは本番で何とかする」なら、eeselはその「あと」のために作られています。あなたのZendesk、Freshdesk、Gorgias、HubSpotに新入社員のように加わります。過去のチケットから学び、顧客に触れる前にそれらで採点され、すべての返信と返金をあなたの承認待ちにした状態で始められます。各レーンをいつ本番にするかはあなたが決め、どれもまた止められます。

無料プランにはカード不要で100クレジットが含まれ、有料プランは500クレジットで$299/monthから始まります（料金）。先週のチケットのコピーでeeselを試して、何をしていたか確かめてみてください。