サポート
サポートチケット自動化のためのAIエージェント:返信からクローズまで
チケットが起票され分類された後も、返信を書き、SLAの期限を追い、きちんとクローズする作業が残ります。自律型AIエージェントはこの部分、返信作成と解決までの追跡を担います。事前の仕分け判断は担いません。
よくある質問
サポートチケット自動化のAIエージェントとは何ですか。
サポートチケット自動化のAIエージェントは、企業のナレッジベースをもとに返信を作成し、繰り返し発生する案件にマクロを適用し、優先度に応じて各チケットのSLA期限を追跡し、解決後に顧客情報を更新します。すでに起票されたチケットを対象に動き、その前段階の優先順位付けの判断は担いません。
連携ツール
Zendesk
grantが書き込みを許可している場合、作成した返信をupdate_ticketでチケットに投稿し、クローズまでステータスを追跡する。
Freshdesk
このチケット管理ツールを使うチームに向けて、Freshdesk側で同様の返信と追跡のロジックを実行する。
Notion
返信を作成する前に、記載された問題に最も関連するナレッジベースの記事を検索する(search、query_database)。
HubSpot
チケット解決後、対応内容の要約とともに顧客情報を更新する(update_contact、create_note)。
Slack
チケットが十分な返信のないままSLA期限に近づいたら、サポートチームに知らせる(post_message)。
ステップバイステップのワークフロー
エージェントができること
- 接続されているすべてのチケット管理チャネルを横断し、すでに起票・分類されたチケットのキューを監視する
- チケットに記載された問題に最も関連するナレッジベースの記事を検索する
- その記事をもとに、チケットの具体的な文脈と企業が定めたトーンに合わせて返信を作成する
- grantが書き込みを許可していればチケットに返信を投稿し、そうでなければ確認用の下書きとして用意する
- 優先度に応じて各チケットの残りSLA期限を計算し追跡する
- 十分な返信のないままSLA期限が近づいたチケットについて、Slackでチームに知らせる
- チケットの内容がすでに何度も解決済みのパターンに合致する場合、マクロを適用または提案する
- チケットのクローズ後、CRM上の顧客情報を対応内容の要約とともに更新する
人間が行うこと
- 承認済みのマクロに該当しない案件について、生成された返信を送信前に確認または修正する
- 既存のナレッジベースでカバーされない、複雑またはエスカレーションされたチケットに対応する
- ナレッジベースを最新に保つ。そうでなければエージェントは返信に引用できる信頼できる情報源を持てない
きちんと仕分けされたチケットも、返信がなければ意味がありません。内容と緊急度が分かった後も、返信を書き、投稿し、期限が切れる前に追跡し、きちんとクローズする作業が残ります。この、最も反復的で件数の増加に最も弱い部分こそ、自律型AIエージェントが担える領域です。
問題
対応が不十分なチケットのコストは、顧客の行動にすぐ表れます。Zendeskが引用するZendesk Benchmarkのデータによると、消費者の73%は複数回の悪い対応を経験するとブランドを乗り換え、半数以上はたった一度の悪い体験でそうします(https://www.zendesk.fr/blog/customer-service/satisfaction/customer-service-statistics/)。22カ国11,000人以上の回答者を対象にしたZendeskのCX Trends 2026レポートも同じ方向を示しています。CX責任者の85%が、初回の問い合わせであっても未解決の問題があれば顧客は離れると考えています(https://cxtrends.zendesk.com/)。
良い知らせは、同じZendesk Benchmarkのデータが、まさにこの領域でAIがすでに有用だと認識されていることを示している点です。消費者の10人中8人近くが、単純な問題にはAIボットが役立つと考えており、回答した経営層の3分の2が、カスタマーサービスへのAI投資が明確な成果改善につながったと答えています。具体的な結果を示す一つのシグナルとして、自社のAIサポートエージェント(Fin)を販売するIntercomは、2026年6月時点で7,000社を超える顧客チーム全体の平均解決率が76%に達し、この数字は同社によれば毎月上昇していると述べています(https://www.intercom.com/blog/from-resolutions-to-outcomes-evolving-how-fin-delivers-value/)。これはベンダーが自社製品について発表した数字であり、独立した測定ではないため、その留保つきで読む必要がありますが、AI支援による対応がナレッジベース型のチケットでどこまでカバーできるかのおおよその感覚は得られます。
これらの数字が示していないのは、高い解決率を実現するために事前に必要な作業です。最新のナレッジベース、繰り返し発生する案件に対応する適切なマクロ、期限後ではなく期限前に知らせるSLA追跡です。この準備がなければ、自動化された対応は的外れで汎用的な返信を量産しがちで、信頼を高めるどころか損ないます。このエージェントが埋めるように設計されているのは、まさにこのギャップです。ゼロから答えをでっち上げるのではなく、すでにあるものを活用します。
エージェントが行うこと、ステップごとに
Atakoでは、このエージェントは人によって仕分けされたか、専用の仕分けエージェントによって仕分けされたかを問わず、すでに起票・分類されたチケットを対象に動きます。接続されているすべてのチケット管理チャネルを横断し、チームの勤務時間に左右されることなくキューを継続的に監視します。
各チケットについて、企業のナレッジベースから最も関連する記事を検索し、そのチケットの具体的な文脈と企業が定めたトーンに合わせた返信を作成します。チケット管理コネクタに付与されたgrantが書き込みを許可していれば、返信を直接投稿します。許可されていない場合は、人による確認用の下書きとして用意します。並行して、優先度に応じて各チケットの残りSLA期限を計算・追跡し、十分な返信のないままチケットが期限に近づくとSlackでチームに知らせます。チケットの内容がすでに何度も解決済みのパターンに合致する場合は、ゼロから返信を書くのではなくマクロを適用または提案します。チケットが解決すると、対応内容の要約とともにCRM上の顧客情報を更新します。
活用するインテグレーション
ZendeskとFreshdeskは、grantが書き込みを許可していれば作成した返信をupdate_ticket経由で受け取り、エージェントがクローズまでチケットのステータスを追跡できるようにします。Notionはナレッジベースとして機能し、エージェントは何かを書く前にsearchやquery_databaseで関連する記事を検索するため、根拠のない返信をでっち上げることを防ぎます。
HubSpotはチケット解決後、対応内容の要約を該当する連絡先または商談に記録し、顧客情報を更新します。Slackは、十分な返信のないままチケットがSLA期限に近づいた際のアラートを受け取り、期限が切れる前に人が対応を引き継げるようにします。
人間に残る判断
エージェントがゼロから返信をでっち上げることは決してありません。既存のナレッジベースに依拠しており、チケットのテーマがカバーされていなければ、提示できる信頼できる内容がありません。エージェントが利用する各インテグレーションは、正確なgrantに依存しています。例えば、Zendeskの読み取り専用grantでは、エージェントは返信を直接送信するのではなく下書きとして用意することを求められ、チームが望む限り常に人によるチェックポイントが確保されます。
3つの責任は明確に人間に残ります。まず、チームがすでに承認したマクロに該当しないすべての案件について、生成された返信を送信前に確認または修正すること。次に、ナレッジベースでカバーされない複雑またはエスカレーションされたチケットに対応すること。これには顧客の状況に対する本当の判断や、時にはエージェントが単独で下す権限を持たない営業上の判断が求められます。最後に、ナレッジベースを最新に保つこと。どれほどよく設計されたエージェントであっても、古くなった、あるいは不完全なドキュメントから正しく回答することはできません。
この仕組みはヒューマン・イン・ザ・ループの原則に従っています。エージェントは反復的な返信作成と期限の追跡を吸収し、案件が既知の範囲を外れた瞬間から、実際に顧客へ届く内容の判断は人間が持ち続けます。返信の投稿、マクロの適用、CRM更新といったエージェントのすべての操作はステータスとともに記録され、エージェントのアクティビティタイムラインで確認できるほか、管理者向けには全社的なインテグレーションログでも確認できます。
測定可能な成果
時間が経つにつれ、この一貫性はサポートチームが日々の業務量をどう感じるかも変えます。SLA期限が静かに切れてしまうことによるストレスのピークが減り、他所ですでに書かれている返信ではなく、本当に人間の判断が必要なチケットにより多くの時間を割けるようになります。
主な効果は2つの軸で測れます。一つはSLA期限の遵守です。エージェントが各チケットを継続的に監視し、期限後ではなく期限前に知らせるためです。もう一つは返信品質の一貫性です。異なる人がそのたびに異なる形で言い換えるのではなく、常に同じナレッジベースから引かれるためです。だからといってナレッジベースを最新に保つ必要がなくなるわけではなく、むしろこの効果が長続きするための条件です。どれほどよく設計されたエージェントであっても、読み込む内容の質に左右され続けます。これはドキュメント整備を、プロジェクト開始時に一度片付けて次のインシデントまで忘れられる単発の作業ではなく、継続的な投資にするということです。
Atakoのスタンダードプランは、エージェントスロット1つあたり月額20ユーロで、記事検索、返信作成、SLA追跡に使うモデル呼び出し向けに、毎月1,000クレジットが含まれています。このコストは月間に処理されるチケットの件数にかかわらず一定で、変動するのは同時に稼働するアクティブなエージェントの数だけです。詳細は料金ページをご覧ください。
よくある質問
このエージェントとチケット仕分けエージェントの違いは何ですか。
仕分けは、対応の前段階でチケットの行き先と緊急度を決めます。このエージェントはその後に動きます。返信を作成し、SLA期限を追跡し、チケットをクローズします。Atakoではこれらは別々の自動化であり、すでにある運用に応じて組み合わせて使うことも、単独で使うこともできます。
エージェントは人間のサポート担当者を置き換えるのですか。
いいえ。既存コンテンツをもとにした返信作成、SLA追跡、マクロ適用といった反復的な対応部分を担い、人間は本当の判断が必要な複雑な案件と顧客関係に集中できます。ナレッジベースの範囲外のチケットは引き続き人が対応します。
このエージェントの導入にはどれくらい時間がかかりますか。
画一的な目安はありません。すでに用意されているナレッジベースの充実度と、チケット管理コネクタのgrantを正確に定義するのにかかる時間に大きく左右されます。ナレッジベースがすでによく整理されていれば、導入期間は大幅に短縮されます。
どのチケット管理システムに対応していますか。
現時点でAtakoが提供するチケット管理のインテグレーションはZendesk、Freshdesk、Intercomで、それぞれgrantによって許可される読み取り・書き込みのアクションが異なります。
次に読む
出典
- From resolutions to outcomes: evolving how Fin delivers value (Intercom) · 閲覧日 2026年9月4日
- CX Trends 2026 (Zendesk) · 閲覧日 2026年9月4日
- 92 customer service statistics you need to know in 2026 (Zendesk) · 閲覧日 2026年9月4日