Slackチケットシステム: 2026年のベスト8選

普通のSlackがキューとして破綻する理由

私はeesel自身のサポートキューを実際に担当しています。だからこそ、リクエストをSlackで直接受け付けようと決めた人には本当に共感します。頼む側にとってはその方が速いからです。しかし、それこそがまさに問題でもあります。

2026年3月にHacker Newsに投稿したある運用担当者は、どのベンダーのページよりも的確にこの失敗パターンを言い表していました。

"We have Slack Connect channels with all of our customers ... and I've since grown to hate it. ... Because Slack is so frictionless, there was no barrier asking anything, including questions that were answered the day prior in the main channel or questions that are right in our searchable API docs."

jjice, Hacker News

同じ不満の社内版は、いたるところで見られます。

"If I can believe what I've been seeing in our internal support channel, no one uses the slack search feature and keep asking the same questions over and over, I really see a space for [Stack Overflow] for Teams to fix this internal knowledge sharing issue."

Chico75, Hacker News

どちらの声も、ステータスが足りないという不満ではないことに注目してください。どちらも「量」に対する不満です。この違いが、以下のどのツールが自分に合っているかを決めるポイントであり、たいていの比較記事がまるごと飛ばしてしまう部分です。

もう一つ、より静かな問題があります。Redditのあるカスタマーサクセス担当者は、その仕組みを的確に言い表していました。

"Slack makes every customer feel “close”, but it does not give you a queue by default. So the team thinks they are being responsive while important stuff is just buried three scrolls up. The fix I have seen work is boring: every channel needs a visible owner, one current next step, and a lightweight rule for what leaves Slack and becomes a tracked ticket/project."

u/TheChandrianX, Reddit

Slackのスレッドには所有者がいません。3人が👀でリアクションし、誰も返信せず、そのリクエストはスクロール履歴の奥へと消えていきます。それがチケット記録によって埋められるギャップであり、本物の問題です。だからこそこの記事の残りが存在します。また、Slackは「結局チケットシステムになってしまうが、それもあまり出来の良くないものだ」という、ネット上で最も辛辣なHacker Newsのtrollbridgeによる評も、間違いというより半分正しいと言えます。

Slackチケットシステムを構築する3つの方法

Slackネイティブ。 チケットの記録はベンダーのシステム内にありますが、体験そのものはすべてSlack上で完結します。メッセージがチケットになり、エージェントは絵文字でそれを引き受け、ステータスはスレッド内で変わります。Suptask、Unthread、Thenaはすべてここに属します。回答する人たちが一日中Slackにいるならこれが最適です。

ヘルプデスクブリッジ。 Slackは受付と気づきのためだけに使われます。チケットはJira、Freshservice、Zendeskに存在し、エージェントは結局別のタブを開くことになります。すでに本格的な社内ヘルプデスクにお金を払っていて、そのレポート機能や資産管理、メールチャンネルが必要な場合に最適です。

AI回答レイヤー。 質問はスレッド内で既存のドキュメントをもとに回答され、残ったものだけがチケットになります。これが私なら最初に追加したい形です。なぜなら、これは出力を整理するのではなく、他の2つへの入力そのものを変えるからです。

実際の運用の多くは、この2つを同時に組み合わせた形に落ち着きます。よくある間違いは、3つ目を試す前に2つ目を買ってしまうことです。

比較の方法

この8つすべてを5週間かけて比較検証したわけではありませんし、正直なところ、そう主張する記事があれば私は疑ってかかります。実際にやったのは、2026年7月31日時点で各ベンダー自身の料金ページと製品ドキュメントをすべて読むことです。そのうえで、実際にチームで使えるかどうかを左右する4つのポイントを抜き出しました。Slackのメッセージが正確にどうチケットになるか、エージェントがSlackを離れずに何ができて何ができないか、どのプラン階層でAIが解放されるか、そして実際のチーム規模で公開価格がいくらになるか、の4つです。

ベンダー自身のマーケティング以外では確認できなかった主張については、それを事実であるかのように繰り返すのではなく、その旨をはっきり書いています。ベンダー自身のドキュメントに制限が明記されている場合は、それを引用しました。そうした制限は、1週目ではなく3か月目になって効いてくるものだからです。

私が半日を費やして得た、あなたの半日を節約する警告があります。このカテゴリーは異常なほどステルスマーケティングが多いです。本物の購入検討者の質問のように見えるRedditスレッドのいくつかは、実はベンダーのスタッフによる投稿でした。同じ従業員アカウントから書かれた「価格を計算してみた」という投稿が2件別々に見つかったほどです。ここで扱っているあるツールのCapterraページはレビュー10件のうち6件がインセンティブ付きとタグ付けされており、別のツールのG2ページはレビュー13件が揃って星5つ・満足度100%です。以下に載せているユーザーの引用はすべて、このリストのどのベンダーとも結びつけられなかったアカウントによるものです。

8つの選択肢をひと目で比較

自分のチーム規模で実際にいくらかかるか

上記のツールは1つを除いてすべて席単位で課金されるため、自分の数字を当てはめるまで、掲示価格はほとんど何も教えてくれません。スライダーを動かして、チケットあたりのコスト列がどう変化するか見てみてください。それこそ、経理チームが最終的に聞いてくることになる数字です。

実際に動かしてみると、2つのことが見えてきます。6エージェント・400チケットの場合、席単位のツールは月$228~$474かかるのに対し、チケット単位のモデルは$160に収まります。同じ6エージェントのままチケット数を3,000まで増やすと、順位は完全に逆転します。席単位の価格は、その6人がどれだけ働いているかをまったく気にしないからです。

1. eesel AI

最適な用途: Slackチャンネルの大半が同じ質問の繰り返しになっているチーム。

最初に断っておくと、私はeeselで働いているので、このセクションは中立的なレビューというより内部の視点として読んでください。お伝えできるのは、なぜこの作り方にしたかです。私たちは何年もの間、実際のサポートキューにAIエージェントを導入してきましたが、ほぼすべての導入で共通して見えてくるのは、Slackチャンネルのトラフィックのかなりの部分が、すでにドキュメントで答えが出ている質問だということです。それをチケットに整理しても、数は減りません。

Slack内でのリクエスト処理方法。 eeselはウィジェットではなく、実際のボットとしてワークスペースに参加します。チャンネルとDMを読み取り、@メンションで回答し、チャンネルごとに異なる挙動を設定できるため、#supportではサポート対応、#opsではダイジェスト投稿、DMでは質問への回答といった使い分けが可能です。パブリックチャンネル、プライベートチャンネル、DMのいずれでも動作します。Slack Connectについては連携ページに明記がないため、事前に確認せずに顧客対応チームへ約束することはおすすめしません。

エージェントができること。 連携したナレッジをもとに回答し、人が承認するための下書きを作成し、トリアージを行い、既存のヘルプデスクへエスカレーションします。導入はあえて段階的にしてあり、1週目はレビュー用の下書きを作成するだけで、信頼できるようになった時点で自律モードに切り替えます。確信度の低い回答はそのまま公開されずに下書きへ回され、顧客に公開される前に過去のチケットに対してシミュレーションを行うこともできます。この最後の部分があるのは、私たちが自信ありげに間違った回答をするボットを目の当たりにしたことがあり、それが一度で十分だったからです。

ナレッジソース。 Google Drive、Confluence、Notion、Zendesk、Freshdesk、SharePoint、ウェブサイト、PDFがすべて自動でインデックスされます。これは、昨年3月の商談であるB2B SaaSチームが語っていたのと同じ発想です。彼らは、ユーザーガイド、Slack、社内KB、過去のチケットを1つずつ個別に見るのではなく、横断的に参照できるAIヘルプデスクエージェントを求めていました。

料金。 対応したチケットあたり$0.40、またはヘルプデスクの会話単位で課金され、返信の回数ではなくチケット単位で課金されるため、15往復のやり取りも1件としてカウントされます。ブログの下書きのような重いタスクは$4.00、ダッシュボードでの質問は無料です。席の概念はなく、最低利用数もありません。カード登録なしで$50分の無料利用枠があり、デフォルトの支出上限は$250で50%・75%・100%でアラートが届き、月$300を年間契約でコミットすると25%割引になります。EnterpriseはSSO、HIPAA、BAAのために、利用料に加えて月額$1,000のプラットフォーム料金がかかります。

"We needed a turnkey solution for Confluence that met our GDPR requirements and could serve different teams through dedicated Slack bots. eesel AI delivered exactly that, with EU data residency included."

Flemming Ottosen, Development Director, Simployer

メリット: 席数の計算が不要、Slack App Directoryから開発者なしで30分以内にセットアップ完了、チャンネルごとのルール設定、80以上の言語に対応、そして移行を求めるのではなく既存のヘルプデスクの上にそのまま乗せられる。

デメリット: チケットの保存場所そのものではない。ヘルプデスクを一切持っておらず、記録自体をSlack内に置きたいなら、代わりにSuptaskかUnthreadを選ぶべき。Slack Connectのサポートは文書化されていない。そして従量課金なので、忙しい月はコストが上がる。それが、静かな月のコストが下がることと引き換えのトレードオフだ。

私の見解: 問題が「整理」ではなく「量」であるならeeselを選んでください。もし#it-helpチャンネルの60%がパスワードリセットや配送ポリシーに関する質問なら、これはそれらをなくしてくれます。キューツールでは、それらにチケット番号を付けるだけで終わっていたはずです。

2. Suptask

最適な用途: Slackから一切離れない、本物のサービスデスク。

Suptaskはこの中でもっとも一点集中型のツールです。自社の締めの一文では、Slackをチームが実際に使うヘルプデスクに変えるとうたっており、製品のあらゆる部分がそこから導かれています。

チケットの作成方法。 文書化された経路は4つあります。指定されたリクエストチャンネルに投稿する、🎫絵文字でリアクションする、/suptaskまたは/helpdeskを実行する、または「Create a ticket」というメッセージショートカットを使う、です。SlackサイドバーにはSuptaskアプリの画面もあり、サービスデスクのハブとして機能します。1件のチケットには、依頼者向けの公開スレッドとエージェント側の非公開スレッドの両方があり、この点が、会話の半分を見せるべきでないIT業務でも使いやすくしている細部です。

エージェントができること。 Slackを離れることなく、ほぼすべてのことが可能です。ルーティングはラウンドロビン、対応中チケット数が最少のエージェントへの割り当て、キーワードルールに対応しており、ITキューにおけるチケットトリアージに求められる内容の大半をカバーします。チーム別のInbox、承認フロー、カスタムステータス、応答時間・解決時間・CSAT・SLA遵守率を網羅するダッシュボードが仕上げとなっています。

料金。 エージェントあたり月額で、依頼者は無制限かつ無料です。Starterは年間払いで$15、月払いで$18、Professionalは$24と$29、Growthは$38と$45、そして見積もり制のCustomプランがあります。席の最低数はなく、永久無料プランもありませんが、Growthプランでカード登録なしの14日間トライアルがあり、それを過ぎるとアカウントはブロックされます。StarterはInbox 1つに制限されており、SLA管理、動的フォーム、AIアシスタントはすべてGrowthに含まれます。

メリット: 席の最低数がないため、2人のITチームなら実際に月$30で運用できる。依頼者は無制限かつ無料。セキュリティ欄にはSOC 2 Type IIの記載あり。公開+非公開スレッドのモデルは、この製品でもっとも設計が優れている部分。

デメリット: AIの利用量メーターが非公開。Growthプランのカードには「エージェントごとにクレジットを含む」という注記があるだけで、クレジット数も、クレジットあたりの価格も、超過分の料金もどこにも公開されていない。Suptaskの主要な統計(1,700以上のチーム、応答76%高速化、AIによる自動解決85%)は自社サイトにしか掲載されておらず、算出方法の記載もないため、根拠というよりマーケティングとして扱うべき。

もっとも参考になった第三者の評価は、約500人のユーザーを5人体制で対応しているRedditのあるitマネージャーによるもので、経営陣がポータルの利用を強制してくれなかったことが、まさに導入の決め手になったといいます。

"We conceded that if we couldn't get management to enforce user behavior, then at least with suptask, any DM or message in a it-requests channel could easily get turned into ticket. It did help but suptask is not fully featured like a bigboy ITSM so it really depends on your needs."

u/signal_empath, Reddit

私の見解: チケットを本当にSlack内に置きたく、かつ処理件数が安定しているなら、もっとも有力な選択肢。契約前に、AIクレジットの数値を書面で営業チームに確認しておくこと。これは料金ページからは予測できない唯一の項目だから。

3. Unthread

最適な用途: 社内ITと社外顧客の両方に同時に対応する1つのキュー。

Unthreadは、IT・カスタマーサポート・RevOps・HRを横断する1つのヘルプデスクとして自社を売り込んでおり、自社の顧客リストもそれを裏付けています。Lemonadeの推薦の声はHead of ITから寄せられたもので、thirdwebは社外ユーザー向けに利用しています。

チケットの作成方法。 経路は2つ。Unthreadが監視対象のチャンネルを自動追跡し、条件を満たす会話をチケットに変換するか、ユーザーがサポートボットにDMを送って非公開のチケットを開くかのいずれかです。エージェントはSlack Inboxから作業しますが、レポート、ナレッジベース、設定は別のWebダッシュボードにあるため、Slack専用ではなくSlackファーストという位置づけです。

料金。 ここは注意深く読む必要があります。Basicはエージェントあたり$50、Proは$75で、どちらも「~から」という表記であり、どちらも最低5席が必要です。つまり実質の入り口価格は月$250と$375になります。Basicは月100会話までに制限されており、AIは一切含まれていません。自動化ビルダー、自己学習ドキュメント、ナレッジベース同期はPro以上の機能です。SSO、Slack Enterprise Gridへの対応、BAA付きHIPAAはすべてEnterpriseに含まれ、こちらは見積もり制のため、すでにGridを使っている大企業でもリスト価格では購入できません。

メリット: Slack UIはSlackネイティブ系の中でもっとも洗練されており、承認とエスカレーションが標準で組み込まれ、G2で4.9/5のバッジを獲得している。エンジニアリングチームがLinearやJiraを使っている場合、サードパーティのトラッカーとの双方向チケット同期は実質的な強み。

デメリット: 5席という最低ラインが、小規模チームを完全に締め出してしまう。2026年にもなってBasicにAIが一切ないというのは奇妙な線引き。ホームページの「初日から40%を偏向(deflect)」という主張は、Lemonadeの事例の約40%という数字とぴったり一致しており、1社の事例をそのまま見出しに一般化したように読める。そして14日間トライアルはデモ経由でしか始められず、セルフサーブではないため、金曜の午後にこっそり試すということができない。

レポート機能は、実際のユーザーから繰り返し挙がる不満点です。2025年12月のG2のあるレビュアーは、率直にこう述べています。

"It does not have a proper customer centric dashboard to track and create reports. Need to click on few tabs to make it user friendly."

Verified user, G2

私の見解: 1つのチームが本当に社員と顧客の両方に対応しているなら、10エージェント以上の規模でその価値がある。5エージェント未満だと、持っていない席の分まで払うことになるので、もっと軽量なAI ITヘルプデスク構成の方が、より少ないコストでより多くをこなしてくれる。

4. Thena

最適な用途: 共有Slack Connectチャンネルを通じてサポートを行うB2B企業。

Thenaは、誰のためのツールかについて曖昧にしていません。サイトには「B2B向けのサポートプラットフォーム」と明記されており、製品全体が、顧客とすでに共有チャンネルでつながっていることを前提に作られています。

チケットの作成方法。 目玉となる仕組みはAIによるチケット検出で、エントリープランから利用できます。Thenaは連携チャンネルを監視し、どのメッセージが本物のリクエストかを判断したうえで、AIによる要約とタグ付けを施したチケットを作成します。絵文字アクション、構造化フォーム、チャンネルごとのコンバーターが手動での経路をカバーし、内部スレッドを使えば、顧客側のチャンネルに漏れることなくチームでチケットについて話し合えます。

エージェントの作業場所。 あえて両方に対応しています。エージェントはSlackから、またはボード・トリアージ・ビューを備えたフルダッシュボードからチケットを管理できます。ThenaはMCPサーバーも公開しており、Claude、Cursor、Raycastからチケットを読み取り、操作することも可能です。これは今回の比較の中でもっとも先進的な機能です。

料金。 年間払いのみで、このカテゴリーでは珍しく、3プランすべてが具体的な数字を公開しています。Starterはユーザーあたり月額$29で、5席・月1,000チケットまで、Slackとメールのみに対応。Standardは$79、Enterpriseは$119です。SLA、CSAT、Insightsは全プランに含まれており、これは珍しく、多くのヘルプデスクはSLAを中間プラン以上に制限しています。Microsoft TeamsはEnterprise限定で、RBAC、API、Webhook、AIエージェントはStandardでは「制限あり」とだけ記載されており、Thenaはその制限の中身を一切定義していません。

メリット: 本当に透明性の高い料金体系、エントリープランからSLA対応、Starterから含まれるAI検出、そしてこのグループの中でもっとも明確なB2Bポジショニング。実名で紹介されているClarifyの事例では、以前は4人体制でこなしていた業務を、今では1人のサポートリードでカバーできているといいます。

デメリット: 年間契約のみで、月単位で試す方法がない。Starterの席上限がページ間で矛盾している(料金ページでは5席、ホームページのカードでは10席と表記)。ホームページでは無料プランを宣伝しているが、料金ページには無料プランの条件が一切掲載されていない。そして「制限あり」という機能表記に数字の裏付けがないまま、1年契約にサインする気にはなれない。

私の見解: 顧客がSlack Connectチャンネル経由でリクエストを送ってくるなら、これがこの中でもっとも目的に特化したツール。キューが社内IT向けなら、一生使わないB2Bアカウントのコンテキストにお金を払うことになる。

5. Jira Service ManagementのAtlassian Assist

最適な用途: すでにJiraにお金を払っていて、追加ライセンス費用なしでSlackからの受付を実現したいチーム。

Halpを覚えている方には、これがその行き先です。Atlassianは2023年5月9日に販売を終了し、2024年6月4日にはHalp webとHalp-Assistのチケット機能を停止して、その機能をFreeを含む全プランのJira Service Management Cloudに統合しました。

チケットの作成方法。 文書化された経路は5つあり、数そのものよりもそれぞれの違いの方が重要です。:ticket:でリアクションする方法は、設定済みのリクエストチャンネル内でのみ機能します。「Raise a request」というメッセージアクションは、プライベートチャンネルとDMで使える唯一の方法です。どこでも/assistと入力する方法もあります。Assist Homeタブを使う方法はJira管理者である必要があります。あるいは自動作成をオンにすれば、リクエストチャンネル内のすべてのメッセージがワークアイテムになります。

この絵文字の制限に引っかかる人があまりに多いため、Atlassianは専用の記事を公開しているほどです。導入後、チームの半数が絵文字が「動かない」と報告してきたら、それが理由です。

エージェントができること。 「Take it」を押すか:eyes:でリアクションすると割り当てができ、スレッドからステータスを変更でき、メッセージの先頭に:lock:を付けると内部メモになります。展開カードには最大10フィールドまで表示され、それを超えるとAssistはJira側でリクエストを確認するよう案内し、複数行のテキストフィールドは仕様上表示されません。

料金。 Assist専用のSKUは存在しません。現在Service Collectionとして販売されている通常のJira Service Managementのエージェント席を支払うだけです。Freeは3エージェントまで、Standardは最初の15席まで1エージェントあたり月額$25、Premiumは$57.30です。本当に制限されているのはバーチャルサービスエージェントで、こちらはPremium限定であり、SlackまたはMicrosoft Teamsのどちらか一方でのみ動作し、両方同時には使えません。

メリット: すでにJiraを運用しているなら実質無料、小規模チームならFreeプランでも動作し、リクエストは結局エンジニアがすでに使っているのと同じシステムに集まる。Assistは全4プラン階層で動作し、これは珍しく寛大な扱いで、すでに導入しているかもしれないより広範なJira Slack自動化ともきれいに組み合わせられる。

デメリット: 10フィールドという上限のせいで、複雑なリクエストフォームはSlack上では使い勝手が悪くなる。Atlassian自身のドキュメントにはSlack Connectの対応について肯定・否定どちらの記載もなく、社外チャンネルについては「対応する」ではなく「不明」という扱い。そしてAIはPremium限定で、エージェントあたりのコストは2倍以上になる。

私の見解: すでにJiraが正式な記録システムになっているなら、これが自然な選択。そうでないなら、Slackチケット機能だけのためにJira Service Managementを導入するべきではありません。受付という一つの課題を解決するために、ITSMプラットフォームをまるごと買うことになってしまうからです。このプラットフォームが席のコストに見合うかどうかは、私のJira Service Managementレビューでさらに詳しく扱っており、Premiumの価格が高く感じる場合はJSM向けベストAIのまとめも別に用意しています。

6. Freshservice

最適な用途: 承認フロー、資産管理、そしてSlackの背後にある本格的なITSM記録を必要とするITチーム。

FreshserviceのSlack上の存在はServicebotというボットで、単なる受付以上のことを行います。まずナレッジベースによる偏向(deflection)を試み、サムズダウンが押されるとチケットへとエスカレーションします。これは正しい設計です。

チケットの作成方法。 経路は4つ。@ServicebotにDMを送りプロンプトに答える、Freddyが事前入力したフォームを使う、/freshservice-ticketスラッシュコマンドを実行する、またはSlackのショートカットやメッセージアクションを使う、です。スラッシュコマンドには知っておく価値があります。DMでしか使えず、管理者が別途有効化する必要があり、すべてのエージェントが自分のプロフィールから個別にSlackを認可する必要があり、直前1時間分のメッセージをチケットに取り込みます。

知っておくべき制限。 FreshserviceからSlackへ流れる返信とプライベートノートは、250文字までに制限されています。実際のIT対応の回答が250文字に収まることはめったにありません。チャンネルへの返信もプライベートノートとして扱われるため、依頼者には届きません。Slackからの添付ファイルと資産の紐付けは、どちらも明示的に非対応です。

料金とAIの制限。 SlackのFreddy AI AgentはFreshworks自身のプラン表によればEnterprise限定で、Enterpriseの価格は公開されていません。Enterpriseライセンス1つにつき年間1,200回分のFreddyセッションが含まれますが、超過分のレートは公開されていません。エージェント側のアシスタントであるFreddy AI Copilotは別売のアドオンで、年間払いでエージェントあたり月額$29、月払いなら$35です。全体の料金体系については、当社のFreshservice AI料金の記事で詳しくまとめています。

メリット: Slack内での承認機能はきちんと文書化されており、ワンクリックでの承認と、却下時のコメント必須という仕様がある。チケット化の前に偏向(deflection)を試みるのが適切なデフォルト動作であり、Freshserviceのより広範な従業員セルフサービスの一部としても機能する。記録自体は、資産管理や変更管理を備えた本格的なITSMシステム。

デメリット: 250文字という上限は、機能面での明確な天井。フォームの互換性は静かに失敗する。8フィールドを超える、選択肢が100を超える、あるいは動的セクションを含むフォームは、代わりにユーザーをWebポータルへ誘導してしまう。そして誰もが求めているAIは、非公開のEnterprise価格の向こう側にある。

私の見解: すでにFreshserviceがITSMとして使われているなら、受付窓口としては悪くない。しかしFreshserviceを買う理由にはならない。目的が偏向(deflection)であれば、Freshservice上のAIレイヤーを使えば、Enterpriseの制限を完全に回避できる。

7. ZendeskのSlackアプリ

最適な用途: すでに運用しているZendeskのキューに社内リクエストを取り込むこと。

Zendeskは2つの別々のSlack製品を提供しており、ドキュメントでもこの2つは互換性がないと明記されています。Slack for Zendesk Supportは、多くの人が思い浮かべる内部連携です。一方、Slack Direct Messagesチャンネルは別のメッセージングチャンネルで、エンドユーザーが特定のハンドルにDMを送り、そのDMがチケットになる仕組みで、1対1の会話に限定されており、スレッドは明示的に非対応です。

チケットの作成方法。 /zendeskショートカット、既存メッセージへのメッセージアクション(説明欄が自動入力される)、アプリのHomeタブ、またはSlack Connectチャンネルでの@zendeskメンションで、これが社外ユーザーに使える唯一の経路です。最初の2つの方法で作成されたチケットにはcreated_from_slackタグが付き、これをもとにビューを作成できますが、Connect経由の場合このタグは付きません。絵文字トリガーはありません。

エージェントができないこと。 ここが今回の比較の中でもっとも厳しい制限のセットで、Zendesk自身のFAQに直接書かれています。Slackからチケットをクローズすることはできません。チケットのフィールドを編集することはできません。割り当てはグループにのみ可能で、個人には割り当てられません。Slackからの公開の顧客向け返信については一切文書化がなく、内部メモのみです。Slackはあくまで取り込みと気づきのための画面であり、Zendeskのエージェントワークスペースは依然として必須です。

サイドカンバセーションは逆方向の機能で、エージェントがチケットの中からSlackスレッドを開始できます。1コメントあたり1,000文字までに制限され、同期には5~30秒かそれ以上かかり、絵文字リアクション、DM、入力中インジケーターには対応しておらず、Slack Connectチャンネルが自社ではなく外部ワークスペースの所有である場合は完全に機能しなくなります。Suite Professional以上、またはCollaborationアドオンが必要です。

メリット: 既存のSuiteプランに追加料金なし。承認機能は動作する。Answer Bot for Slackは利用可能な範囲では無料で、チャンネル通知は完全にトリガー駆動なので、すでに運用しているZendeskのルーティング自動化にそのまま組み込める。

デメリット: Answer Bot for Slackは、2025年2月2日時点でAIエージェントを下書きまたは公開済みだったアカウントに限定されており、それ以降の新しいアカウントは代わりに有料のAIエージェントアドオンへ誘導されます。中国語、韓国語、日本語、タイ語では記事の提案ができません。そしてチャンネル内の誰もが、そこで作成されたチケットを見られてしまうため、HRや機密性の高い用途では実質的な問題になります。

私の見解: これはチケットシステムではなく、取り込みツールとして扱うべきです。Slackで本当にZendeskのキューに対する問題を解決したいなら、実際に返信できるレイヤーが必要で、そのギャップについては当社のZendesk AI代替ツールの記事で詳しく解説しています。

8. Slack listsとWorkflow Builder

最適な用途: 何かを購入する前に、本当にチケット管理の課題があるのかを見極めること。

Slack自身がこのユースケースを打ち出しています。「Slack lists: Collect and triage requests」というヘルプ記事があり、その実例はまさにITヘルプデスクそのものです。

実際に得られるもの。 どのメッセージも、オーバーフローメニューからlistのアイテムにできます。listsにはデフォルトでCompletion、Name、Assignee、Due Dateのフィールドがあり、ステータスを含め他のフィールドも自由に追加できます。Help request trackerテンプレートには、あらかじめRequest、Category、Priorityが追加されています。期限を追いかける自動化が2つ用意されており、1つは担当者にDMを送り、もう1つはチャンネルにダイジェストを投稿します。listのアイテムの更新をワークフローのトリガーにすることもでき、これがステータス変更の自動化にもっとも近いネイティブ機能です。

限界。 Workflow Builderは1ワークフローあたり100ステップまでという制限があり、深刻度でルーティングするために必要な条件分岐はBusiness+以上の機能です。ワークフローのアクティビティログは直近90日分しか残らず、エクスポートもできないため、チケット件数の推移も、初回応答時間も、CSATも把握できません。そのログにあるステータスは、あくまでワークフローのステータス(完了、進行中、ワークフローエラー、キャンセル、ユーザーの操作待ち)であり、自動化が動いたかどうかを示すだけで、リクエストが解決したかどうかは示しません。SLAタイマーも、チケットIDも、依頼者と担当者の区別もありません。

料金。 listsとWorkflow Builderのどちらも、Slack Freeでは使えません。SlackProはユーザーあたり月額$8.75、年間払いなら$7.25、Business+は$18または$15です。FreeでのSlack Connectは1対1の社外DMに限定されるため、顧客と共有するチャンネルには最低でもProが必要で、上限は250組織です。

メリット: 新しいベンダーも、新しいログインも、購買手続きも不要。週に数件のリクエストしか受けない小規模チームであれば、これに多少のSlack自動化を加えるだけで、正直なところ十分です。

デメリット: 無料ではないうえ、SLAもレポート機能もありません。そしてSlack自身のコネクタ一覧が、それとなく本音を明かしています。コネクタにはJira、ServiceNow、Zendeskが含まれており、つまり「本物のチケットはどこに存在するのか」というSlack自身の答えは、他社の製品だということです。

listsをまったく使わず、純粋な絵文字ルールだけで運用しているチームも少なくありません。Redditのあるitマネージャーは、その仕組み全体を説明しつつ、同じ口でその限界も明かしていました。

"Eyes 👀 emoji to acknowledge you’ve read it. @ the person who will complete the request. Checkered flag 🏁 emoji when it is complete. This will get you organized at least somewhat. It won’t help you report on tickets per day or old incomplete tickets or anything else that a proper ticketing system would do."

u/cspinelive, Reddit

私の見解: まずは2週間、ここから始めてみてください。リストが短いまま保たれ、みんながきちんとクローズしていくなら、そもそもツールは必要なかったということです。もし墓場のようになってしまったら、どんな形のツールを買うべきかが正確にわかります。

多くのチームが間違えていること

先ほどのSlack Connectチャンネルに関するHNの引用を振り返ってみてください。あの不満は「どのリクエストが未対応かわからない」というものでは一度もありませんでした。「同じ質問がずっと届き続ける」というものでした。席単位で課金するチケットツールは、1つ目の問題には見事に応えてくれますが、2つ目の問題には何もしてくれません。

席単位の課金では、請求額は何人雇っているかで決まり、どれだけの業務が発生しているかでは決まりません。偏向(deflection)しても1セントも安くはなりません。チケット単位のモデルはその鏡像です。雇用人数を変えても料金は変わらず、チケットになる前にAIが答えた質問1つ1つが、そのまま手元に残るお金になります。どちらが絶対的に正しいというわけではありませんが、両者はまったく異なる行動に報酬を与えるものであり、ほとんどのチームは、自分がどちらを選んだのかに気づかないまま契約しています。

ついでに言えば、期待値はベンダーのページではなくユーザーから設定しましょう。このカテゴリーのベンダーは80%台の偏向率を宣伝していますが、実際に運用している人から得られたもっとも信頼できる数字は、Redditのあるユーザーが報告した「おそらく3540%」が自動解決し、残りは引き続き追跡されているというものでした。独自のSlack-to-Jira自動化を構築した別のチームは、1年間でチケット数を「ほぼ70%」削減したと報告しています。実際の導入がどんな姿になるかは、この3570%のどこかということです。

サポートの業務量を整理するのではなく減らしたいのであれば、正直なアドバイスは、まず入力の側を直すことです。これはチケット偏向全般の背後にあるのと同じ論理であり、Slackはまさに質問するときの摩擦がなさすぎるがゆえに、他のどこよりも強くこの論理が当てはまります。

良いSlack構成とは実際どのようなものか

あるHacker Newsのユーザーは、どんなアーキテクチャ図よりも的確にこのパターンを説明していました。

"My current employer has a slack helpbot where you dm the bot and it does a first pass at trying to find the right ticket/form etc to solve your problem. If it can't, it opens a regular helpdesk ticket with the info you have given it so far and the helpdesk sorts your problem out. It's great."

seanhunter, Hacker News

ここでは3つのことが起きています。まずボットが先に試みます。対応できない場合は、すでに収集済みのコンテキストとともにエスカレーションします。これこそ、優れたAIエージェントの引き継ぎの要点であり、担当者が依頼者に同じ話を繰り返させずに済む理由です。そしてリクエストは、実際の記録を持つ本物のヘルプデスクに届きます。これが全体の設計であり、この記事で扱ったツールはどれも、その一部か二部を担っています。

4つ目のステップは、ほとんど誰も構築していないものです。ある質問に答えられなかった場合、そのギャップはドキュメントに書き戻され、次に同じような質問をした人には答えられるようにするべきです。このループがなければ、偏向率は初日にドキュメントがたまたまカバーしていた範囲で頭打ちになります。この側面を健全に保つ方法については、当社のナレッジベーストレーニングガイドで解説しています。

Slackでeeselを試す

ここまで挙げたツールはすべて、Slackのリクエストを整理するためのものです。eesel for Slackは、そもそもリクエストの数自体を減らすためのものです。Slack App Directoryからワンクリックで導入すると、Google Drive、Confluence、Notion、既存のヘルプデスクを自動でインデックスし、指定したチャンネルでチャンネルごとのルールに沿って回答を始めます。最初はレビュー用の下書きを作成するところから始まり、準備ができたら自律モードに切り替えられます。そしてZendesk、Freshdesk、あるいはすでに使っている他のツールへエスカレーションするため、何かを移行する必要はありません。

Slackのキューに限って言えば、重要なのは課金の単位です。エージェント単位ではなく、対応したチケットあたり$0.40を支払います。静かな週はコストが下がり、人間が対応したチケットには一切費用がかかりません。カード登録不要の$50分の無料利用枠から始め、何かをオンにする前に支出上限を設定しておきましょう。eeselを試すと、繰り返しの質問が届かなくなったチャンネルがどうなるか確かめられます。