
Slackでサポートが静かに崩壊する理由
Slackには摩擦がなく、それこそが問題です。チケットフォームもなければ、「先に検索しましたか?」という確認もなく、キューもありません。誰かが質問を打ち込むだけです。だから来週も、その次の週も同じ質問が打ち込まれ、ドキュメントにある答えは一度も読まれません。
ある創業者は、Slack Connectで顧客サポートを運用することについて、私よりも的確にHacker Newsのスレッドで表現していました。
「すべての顧客とSlack Connectチャンネルを持っています……それが今では嫌になってしまいました。……Slackはあまりに摩擦がないため、前日にメインチャンネルで回答済みの質問や、検索可能なAPIドキュメントに載っている質問も含めて、何かを尋ねることへの障壁が一切ありませんでした。」
社内版もまったく同じです。IT担当やオペレーション担当のリーダーに#it-helpチャンネルについて尋ねれば、同じ答えが返ってきます。検索ボックスはあるのに、誰も使わない、と。
「誰もSlackの検索機能を使わず、同じ質問を何度も繰り返しています。この社内のナレッジ共有の問題を解決するには、チーム向けの[Stack Overflow]のようなものの余地が本当にあると感じます。」
ここが自動化の狙い目です。ほんの一握りの質問が一日の時間を食いつぶし、答えはすでに存在しているなら、必要なのは人手を増やすことではありません。誰よりも早くドキュメントを読んでくれる何かが必要なのです。
「Slackサポートを自動化する」とは実際どういうことか
何かを設定する前に、2つの仕事のうちどちらを解決しようとしているのかをはっきりさせましょう。チャンネルもエスカレーションルールも異なるからです。

外部/顧客サポートは、クライアントと共有するSlack Connectチャンネルで行われます。ここではAIが製品やAPIに関する質問に答えますが、顧客の目に触れるため、誤答が許されるハードルは高くなります。エスカレーション寄りに設定しておきたいところです。
社内サポートは、#it-help、#people-ops、#eng-questionsといった自社チャンネルで行われます。ここはAI ITヘルプデスクが真価を発揮する場所です。ポリシーやオンボーディング、ハウツーの回答は淡々としていて反復的で、すべて文書化されているからです。また、自社チームは顧客より寛容なので、始めるにも最も安全な場所です。
どちらのケースでも、エージェントはSlackのチャット履歴だけでなく実際のナレッジをもとに回答する必要がある、という点は共通です。これが本物のエージェントとSlack標準の検索機能との境界線であり、標準機能で十分だと判断する前に、Slack AIが何をできて何をできないのかを知っておく価値はあります。
AIが実際にSlackで質問に答える仕組み
その仕組みは見た目より単純で、理解しておけばガードレールをどこに置くべきかがわかります。

誰かがエージェントに@メンションします。エージェントは、優秀なチームメイトがWikiを確認するのと同じように、連携済みのソースを検索します。そして重要なのはここからです。エージェントは自分の確信度をスコアリングします。確信度が高ければ、スレッド内でそのまま回答します。確信度が低ければ推測はしません。すでに集めた文脈をもとに、人向けの下書きを作成するか、エスカレーションします。
この確信度チェックがすべてと言っていいでしょう。常に答えようとするボットは負債になりますが、黙って引き継ぐべきタイミングを知っているボットは同僚になります。これは、実際のヘルプデスクでAIを役立つ存在にしているのと同じチケットの振り分けロジックを、Slackのスレッドに向けているだけです。
Slackサポートを自動化する手順
顧客対応であれ社内対応であれ、私ならこう設定します。これはeeselのSlack連携の仕組みに沿っていますが、まともなツールであればどれも同じような手順になります。
ステップ1:エージェントをSlackにインストールする
Slack App Directoryからアプリを追加し、認可します。開発者もカスタムアプリマニフェストも不要です。エージェントは@メンションできるボットとしてワークスペースに参加し、チャンネルにいることがわかるよう短い自己紹介を投稿します。ここまで数分で終わります。
ステップ2:ナレッジを連携する
ここが全体がうまくいくかどうかを左右するステップなので、急がないでください。実際の答えが書かれているすべてのソースにエージェントを向けましょう。Google Drive、Confluence、Notion、ヘルプセンター、そして何より重要な、ZendeskやFreshdeskにある過去のチケットです。

過去のチケットは、ヘルプドキュメントよりも重要です。公式版だけでなく、チームが実際にどう言葉を選んで回答しているかがわかるからです。ヘルプセンターだけでなく解決済みチケットからも学習することが、あなたのチームらしく話すエージェントと、マニュアルのように話すエージェントの違いを生みます。すべて自動的にインデックス化され、同期され続けるため、エージェントは半年前のスナップショットではなく、今日時点のドキュメントをもとに回答します。
ステップ3:チャンネルルールとエスカレーションを設定する
チャンネルごとに、エージェントに何をさせるかを決めましょう。#it-helpでは質問に回答し、#opsでは週次のダイジェストを投稿し、#randomには関与しない、といった具合です。エージェントがそもそも見ることのできるチャンネルもコントロールでき、エスカレーションのトリガーも設定します。確信度が低いとき、人向けに下書きするのか、チームメイトにタグ付けするのか、Jira Service Managementでチケットを起票するのか。これらのルールは平易な言葉で書きましょう。ここで、顧客チャンネルでは慎重に、社内チャンネルではより大胆に、とエージェントの挙動を調整します。
ステップ4:本番運用前にシミュレーションする
テストしていないボットを顧客に向けてはいけません。まずは実際の過去の質問に対して実行し、AIが何と答えていたかを確認しましょう。これにより、リスクがゼロの段階で、ドキュメントがないトピックや微妙に間違った回答といったギャップが明らかになります。ギャップを埋めて再実行し、それから初めてオンにしましょう。このステップを飛ばすことが、こうしたプロジェクトが誰かの顔に泥を塗る、最もよくある原因です。
ステップ5:下書きモードで運用開始し、レポートを見守る
オンにはしますが、下書きモードでです。エージェントが返信を書き、人が承認ボタンを押します。最初の1週間は、その回答を読み、間違っているものを修正し(修正のたびにエージェントは学習します)、信頼を積み上げていきます。何を解決していて何をエスカレーションしているのか、レポートで確認しましょう。

トラストランプ:一気に全部オンにしない
最もよく見かける間違いは、自動化をスイッチのように扱うことです。実際はダイヤルです。最初はAIがすべてを承認待ちの下書きとして作成し、AIが信頼を勝ち取るにつれて自律性の幅を広げていきます。

1週目はエージェントが下書きし、あなたが承認します。3週目には、簡単で確信度の高い質問には自動で回答し、難しいものは下書きするようになります。6週目には階層1を自力で処理し、それ以外はエスカレーションするようになります。ダイヤルを動かすのはあなたであり、AIが勝手に動かすわけではありません。
このように運用しているチームは、実際の数字という成果を得ています。Jira Service Management、Confluence、Slackで社内デスクを運用しているあるフィンテック企業のIT責任者は、このエージェントを本物のファーストレスポンダーだと表現しました。
「Jiraのヘルプデスクチケットに対するファーストレスポンダーとして使っています。まさにエージェントそのもののように機能します。」
初日にすべてを賭けるのではなく段階的に広げていったからこそ、彼らは15%の解決率から始めて55%まで押し上げることができました。顧客対応の面では、Global Paymentsは、ナレッジを連携してSlack内で検索できるようにした結果、ドキュメント全体から答えを探す時間を最大80%削減できたと報告しています。
避けるべきよくある間違い
私が苦い経験から学んだ、避けるべき落とし穴をいくつか紹介します。
- ドキュメントだけ連携し、過去のチケットを連携しない。 ヘルプドキュメントはエージェントにポリシーを教えますが、チケットは人々が実際に納得する回答を教えてくれます。チケットを飛ばすと、機械的な受け答えになってしまいます。
- シミュレーションなしで本番運用する。 エージェントが実際に発言する前にその内容を確認できないなら、それは顧客相手にテストしていることになります。やめましょう。
- すべてのチャンネルに同じエスカレーションルールを使う。 顧客チャンネルと社内チャンネルでは求められる慎重さのレベルが異なります。それぞれ個別に設定しましょう。
- 課金単位ではなく表示価格だけでツールを比較する。 シート課金、解決件数課金、会話課金はそれぞれ別物です。シート課金型ボットを使う40人のチームは、ボットが何もしなくても40シート分を支払います。表面上の数字だけでなく料金モデルを読み込み、同じ対応量におけるAIと人的オペレーターのコストを把握しましょう。
- Slack標準のAIで十分だと思い込む。 Slack AIは既存のチャットを要約するのが得意です。しかし、より広いナレッジベースと連携してそれをもとに行動することはできません。解決率の向上が目的なら、必要なのは別のツールです。
Slack向けにeeselを試す
1か月がかりの導入を経ずにSlackサポートを自動化したいなら、eesel AIはまさにそのために作られています。@メンションできるチームメイトとしてSlackに参加し、連携済みのドキュメントと過去のチケットをもとに回答し、顧客チャンネルと社内のIT・HRサポートの両方をチャンネルごとに異なるルールで処理します。
サポート担当者にとって重要なポイントはこちらです。App Directoryからワンクリックでインストールでき、過去の履歴に対してシミュレーションを行うため顧客より先に回答内容を確認でき、確信度ベースのルーティングにより、自信がないときは推測せずに下書きまたはエスカレーションを行います。料金は従量課金制で1会話あたり約0.40ドル、シート課金はなく、30分足らずで運用を開始できます。無料トライアルもあるので、導入を決める前にテストチャンネルで動作を確認できます。
よくある質問
チームのSlackサポートを自動化するにはどうすればよいですか?
AIはSlackチャンネル内で直接質問に答えられますか?
Slackサポートを自動化するにはどのくらいの費用がかかりますか?
AIがSlackで顧客に誤った回答をしてしまうことはありますか?
Slack AIとSlackサポートの自動化の違いは何ですか?

Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.






