サポートAIエージェント：Intercomの会話を仕分けし、ヘルプ記事を提案

サポートチームは2つの場面で時間を失います。1つ目は仕分けです。会話を1件ずつ開き、何についてのものかを理解し、顧客の状況を探し、答えがどこかにすでにあるかを確かめます。2つ目はもっと目立たないものです。同じ質問が毎週のように戻ってきますが、それをなくすヘルプ記事を書く時間は誰にもありません。どちらも読み取りと要約の仕事で、顧客の前で発言する権限を与えないかぎり、自律型AIエージェントによく合います。

着想：返信は用意するが、自分では出さない

自律型エージェントの利用者の声には、慎重な使い方が登場します。エージェントがサポートの受信箱を読み、下地を整えて、返信は人に任せるというものです。得られるのは顧客との会話の自動化ではなく、返信する人が、すでにタグが付き、要約され、提案まで添えられた会話を開けることです。Atakoはこの役割分担を守ります。エージェントは読み取り、タグを付け、社内向けに書き、顧客と話すのは人です。

エージェントの働き

このシナリオでは、それぞれ独自のリズムで動く2つのエージェントを配置します。

サポート仕分け担当は、Intercomの未対応の会話を読み取ります。会話ごとに、指定された緊急ケースを踏まえて、設定されたカテゴリの1つと緊急度を選び、既存のタグを再利用してタグを付けます。最後に「[仕分け]」で始まる内部メモを追加します。2行の要約、顧客の背景、顧客が期待していること、使用した参照元（ヘルプ記事や似た過去の会話）、そしてブランドの口調に合わせた返信案です。営業日の9時から18時まで1時間ごとに戻ってきますが、すでにメモのある会話は、顧客が再び書き込んだ場合を除いて仕分けし直しません。

ドキュメント担当は週単位で働きます。過去7日間の会話を読み、文言ではなく根底にある質問ごとにグループ化し、各グループの件数を数えて、既存のヘルプ記事と比較します。よい記事がない上位3〜5件の質問について、Wikiにページの下書きを書きます。まず短い答え、次に手順、最後にそれでも解決しない場合の対処です。根拠として会話の件数とIDを添え、顧客名は載せません。毎週金曜日の16時には、「毎週のドキュメントレビュー」ページを書きます。

エージェントがしないこと

制限は設計の一部です。どちらのエージェントも、顧客に返信すること、会話をクローズすること、担当を割り当てることをしません。そのためのツールがないからです。ドキュメント担当は記事を公開せず、下書きは人がIntercomにコピーするまでWikiに残ります。返信案の中で、日付、返金、修正を約束することもありません。そして作り話もしません。ドキュメントや履歴から答えが得られない場合はメモにそう書き、下書きには「要確認」とはっきり示した空白が残ります。これがヒューマン・イン・ザ・ループの設計の考え方です。

Atakoでの設定方法

デプロイは4つのステップです。

1. Intercomを接続します。 Atakoが求めたら、Intercomのアクセストークンを貼り付けます。接続は、何かを作成する前に確認されます。
2. 状況を入力します。 ブランドの口調を説明し、問い合わせカテゴリを（最大8つまで）挙げ、必要に応じて緊急として扱うべきものを伝えます。
3. デプロイします。 1回の操作で、2つのエージェントと「サポート仕分けとドキュメント」プロジェクトが作成されます。エージェントは自動で準備され、最初の指示も自分で受け取ります。
4. 最初の仕分け、その後は定期的なリズムです。 最新の15件の会話は、最初の実行が終わると仕分けされます。その後、仕分け担当は1時間ごとの実行を、ドキュメント担当は毎週金曜日16時のレビューを、自分で予定に組み込みます。

まだアカウントをお持ちでない場合は、作成するとトライアルが始まり、その直後にシナリオが設定されます。

結果の確認先

作業は3か所で確認できます。Intercomでは、仕分けされた会話ごとにタグと内部の「[仕分け]」メモが付いており、チームには見えますが顧客には見えません。プロジェクトのWikiでは、「仕分けログ」ページに件数がまとまり、「記事の下書き」と「毎週のドキュメントレビュー」のページにドキュメント担当の成果が入ります。フロアでは、各エージェントの現在の動きを確認できます。

チャットで話しかけることもできます。カテゴリの追加、口調の調整、今すぐレビューをしてもらう、ある会話がなぜ緊急と分類されたのかを説明してもらう、といった依頼ができます。

ガードレール

Intercomへのアクセスは意図的に絞られています。ツールは8つで、書き込みを行うのはタグと内部メモの2つだけです。返信、クローズ、担当割り当て、記事公開のツールは付与されないため、この制限は単なる指示ではなく構造的なものになります。人による確認は肝心な場所に置かれています。返信案はあくまで提案であり、顧客と話すのはあなたのチームです。

期待できること

特に役立つのは、会話ごとの最初の1分を節約できるメモです。長いやり取りを読み返さなくても、状況が分かります。返信案は、使い方の質問では適切なことが多く、特殊なケースではより慎重になり、エージェントは分からないと言うほうを選びます。ドキュメント面では、効果は反復から生まれます。数週間たつと、下書きから公開された記事が、最もよく戻ってきた質問を減らします。カテゴリと口調には短い調整期間を見込み、メモが的外れに見えたらチャットで直してください。エージェントは、その後の会話のために覚えています。

実用面で一点。返信案の質は、伝える口調の説明に左右されます。「名前で呼ぶ、短い文、日付は約束しない」といった一文のほうが、長いスタイルガイドよりも出力を大きく変えます。まず短く始めて、実際に読んだメモをもとに磨いてください。

最後に、仕分けのタグはあなたのものです。チームがすでにIntercomでタグの体系を使っている場合は、同じ名前をカテゴリとして伝えてください。エージェントは別の体系を作らず、それらを再利用します。