Town AI for Slack：@Townにできること、できないこと、そして費用

Town AIはSlackで何をするのか

私はAliciaで、eeselのAIエージェントを作っています。エージェントがSlackチャンネルに参加しても場を乗っ取らないようにする部分も担当しています。TownのSlackドキュメントを読んで、まず確認したのは、誰かがメンションを入力したときに誰のアシスタントが答えるのかでした。この一点が、連携のそれ以外の部分すべてを決めます。

Townは個人向けのAIアシスタントです。Townieに名前を付けると、専用の@town.comメールアドレスが付き、受信トレイ、カレンダー、ドキュメント、チャットアプリをまたいで動作します。まだご存じなければ、製品そのものはTown AIレビューで、他の選択肢との比較はAIパーソナルアシスタントのまとめで紹介しています。

SlackについてTownのドキュメントは、「役割が異なる」2つの連携を説明しています。

Botが標準です。招待されたチャンネルで@Townをメンションすると、アシスタントがスレッドで返信します。Townのドキュメントによると、まず完全なセッションへのリンク付きで「Working on it」というメッセージを投稿し、作業中（メール検索、Web閲覧など）はリアルタイムで進捗を表示し、最後にスレッドへ最終回答を投稿します。ドキュメントにある典型的な依頼は、「@Town summarize this thread」「@Town turn this into a Linear issue」「@Town what emails did I get from Acme Corp today?」です。

注目すべきは「あなたの」という言葉です。Townのドキュメントでは、メンションは「あなたのパーソナルアシスタントを使う」とされ、記憶、プロフィール、接続済みのツールは他の場所と同じです。Teamsのドキュメントも反対側から同じことを述べています。「Townアカウントを持つチームメンバーは全員、@Townと入力して自分専用のアシスタントを呼び出せます」。

Slack BotとSlack Personaの違いは何か

Townの連携カタログでは別々のタイルで、それぞれ個別に連携します。Townの表と、ページ下部の機能の詳細をもとに、並べて整理するとこうなります。

出典：TownのSlackドキュメント。

この分け方は、Slack自身の認証ドキュメントにある2種類のトークンと対応しています。Botトークンは「アプリに紐づく」もので人には紐づかないため、インストールしたユーザーが無効化されてもアプリはインストールされたままです。ユーザートークンはワークスペースのメンバーを表し、それによる書き込み操作は「ユーザー本人が行ったかのように」実行されます。Townのドキュメントはこの表現を使っていないので、この対応づけは私の解釈ですが、PersonaがDMを読めてBotが読めない理由を説明できます。

Townのドキュメントにある2つの制限は、初日から重要です。Botは「招待されたチャンネルでのみ動作できる」ため、プライベートチャンネルでは/invite @Townが必要です。また「単一ワークスペース」という制限があり、Townアカウント1つにつきSlackワークスペースは1つです。

TownはSlackでどんな操作ができるか

Townの機能表には8つの機能があり、変更を伴うものが示されています。

検索はクエリをそのままSlackに渡すので、普段使っている検索演算子がそのまま使えます。in:#general budget、from:@john meeting、before:2026-08-20 launchなどです。Slackはafter:とbefore:を境界の日を含めない指定として扱うため、Townのドキュメントは、対象にしたい日の前日をafter:に指定するよう案内しています。

読み取りと投稿を合わせれば、個人用のツールキットとして十分です。にぎやかなチャンネルに追いつく、3週間前に誰かが下した決定を探す、ルーティンが終わったらチャンネルに知らせる、といった使い方ができます。Townのドキュメントには、チャンネルからユーザーのフィードバックを集めて返信やLinearのIssueにする例もあります。アシスタントなしでSlack側だけ使いたい場合は、Slack自動化のガイドでSlack標準のツールを紹介しています。

SlackによるTownのルーティンにはどんなものがあるか

Townのルーティンライブラリでは、Morning Briefing、Daily Priority Briefing、Meeting Slip Alert、Delegation Tracker、Weekly Website Reportなど、23のルーティンでSlackが接続済みの連携として表示されています。多くは、メールの代わりに、またはメールに加えて、Slackにダイジェストやアラートを送ります。Town自身のベストプラクティスは、緊急のアラートにはSlack、長めの要約にはメールを使い、通知しすぎないことです。「Slackのメッセージが多すぎると、メールと同じくらい負担になる」ためです。

Slack専用のトリガーもあります。Townのトリガーのドキュメントは、「Slack mention」をルーティンのトリガーとして説明しており、「誰かがSlackでTownアシスタントを@メンションしたときに実行」されます。ユースケースは「Slackでチームの質問に答える」「チャンネルでの依頼を処理する」「Slackの会話からルーティンを起動する」です。Slack連携が接続されている必要があります。

プランが重要になるのはこのトリガーで、詳しくは後述します。チャットではなく受信トレイからクライアントにフォローアップするルーティンについては、クライアントフォローアップ向けTown AIとHubSpot向けTown AIにまとめました。

TownはSlackの送信をどう安全に保つのか

Townのデフォルトは慎重です。Modes and Approvalsでは、セッションの既定設定は「Ask before any changes」で、変更を伴うすべての操作があなたの確認を待ちます。「Sending Slack messages」は承認が必要な操作の表に名前が挙がっており、「Always allow safe actions」設定でも、外部とのコミュニケーションなので「still requires approval」に分類されています。

忙しいワークスペースで動かす前に、確認しておきたい点が3つあります。

• Personaの送信は常に承認が必要です。 TownのSlackドキュメントには「Sending as you always requires your explicit approval」とあります。ボットがあなたの名前でメッセージを送ると、人間関係に響くのはそこなので、これは正しいデフォルトです。
• ルーティンのモードがセッションの既定を上書きします。 自律モードのルーティンは操作を「すぐに」実行するため、自律に設定したSlackダイジェストのルーティンは確認なしで投稿します。ツールごとの設定で、読み取りと下書きは自動のまま、Slackの送信は「毎回確認」にしておけます。Townは「他の人に連絡するすべてのこと」についてこの設定を残すよう勧めています。「送信したメッセージは取り消せない」からです。
• Slackチャンネルは信頼できない入力です。 Townのドキュメントは、非公開データを読み、信頼できない入力を取り込み、外部に送信できるルーティンに警告しており、保存時にその組み合わせを知らせます。他の人のメッセージだらけのチャンネルはまさにその種の入力なので、Slackメンションのルーティンを外部に送信するものにつなぐ際は注意してください。

Townの共同創業者Jean-Denis Grezeは、ローンチ時に製品の姿勢をこう表現しました。

"And it only acts when you say so."

Jean-Denis Greze, X

Slackでは、送信を承認制にしておく限りこれが成り立ちます。同じアシスタントをClaudeにつないでも状況は似ており、Claude CoworkのSlack連携のガイドとSlackのChatGPTの記事で、他のアシスタントがSlackの操作をどう制御しているかを比較しています。

SlackでのTownの費用はいくらか

Slackを連携すること自体に追加費用はかかりません。Townの料金ページでは、アシスタントが「across email, Slack, WhatsApp, Telegram」で使えるものとして無料プラン（月30チャット）に記載されています。支払う対象は、アシスタントがどれだけ動くか、どのトリガーを実行できるかです。

出典：Townのプランと料金のドキュメント。

Townのプランのドキュメントでは、Starterが実行できるのはスケジュールトリガーのみです。Slackメンションのルーティンはイベントトリガーなので、ProかTeamの有料プランが必要というのが私の解釈です。15ドルのStarterで得られるのは毎日のSlackダイジェストであり、メンションに反応するルーティンではありません。実行ごとのクレジットも固定ではありません。使用量は、1回の実行でどれだけ読み、何をするかで変わるためです。超過分の計算はTown AIの料金の解説に、Slack自体の席費用はSlack AIの料金のガイドにあります。

チームでのTownのSlackセットアップはどう進むのか

Slack Botは1つのアカウントではなくチーム向けにインストールするので、先にTownチームが必要です。デフォルトでは、チームメンバーなら誰でも連携できます。チームのアクセスルールで「Manage integrations」が制限されている場合は、管理者とオーナーだけにConnectボタンが表示されます。そのあと、SlackワークスペースでTownを承認し、対象にしたい各チャンネルで/invite @Townを実行します。

TownのTeamsドキュメントには、見落としやすいルールがあります。チームの連携は「共有される」ため、チーム連携があるツールで到達できるものは、アクセス権のあるメンバー全員が到達できます。Slackでは影響は小さく、Botは「あなたの個人アクセスを持たない」のでDMは読めません。自分のアカウントで接続するツールでは影響が小さくないため、全員に自分が見られる範囲だけに制限したい場合は、個人連携を使うようドキュメントは勧めています。

私が持っておきたいメンタルモデルはこれです。SlackでのTownは、各人の専用アシスタントへの入り口です。Greze自身の考えも同じ方向を向いています。Xでの彼の見方は、強みは互いに会話するアシスタントにある、というものです。

"I think the moat in AI assistants is going to be multiplayer."

Jean-Denis Greze, X

個人アシスタントにとっては妥当な賭けで、Townが社内で1人ずつ広がっていく理由でもあります。投資家であり開発者でもあるswyxは、まさにその様子を語っています。

"Town is the Devin for Everything Else i was talking about at AIE Europe i brought it into our company one day and a few weeks later was shocked to hear that it had just organically spread to @liamcbride and the rest of our team with no further hyping or enablement from me."

swyx, X

TownのSlack連携に特化した公開のXやRedditの投稿は見つからなかったため、上の評判はTown全般についてのものです。TownにはまだG2やCapterraのレビューもありません。

SlackでのTownの限界と、共有ボットの出番

TownのSlack連携は、一度に1人のために作られています。メンションのたびに、その人のアシスタントがその人の記憶で動き、返信がスレッドに届きます。チームのランブックを持ち、チャンネル内の誰にでも同じように答える単一の共有エージェントについては、Townのドキュメントに記載がありません。これは設計上の選択であり、個人アシスタントとしては妥当です。

ただ、別の要望もよく耳にします。Frontを使うB2B SaaSのチームが、eeselの営業チームに、ユーザーガイド、Slack、社内ナレッジベース、過去のチケットを横断的に参照して答えるAIがほしいと話しました。これは共有回答の仕事です。質問は誰からでも来て、答えは誰が聞いても同じであるべきです。#it-helpのようなチャンネルにある社内ヘルプデスクの形で、おすすめの社内ヘルプデスクソフトウェアの比較とIT部門向け社内ヘルプデスクのガイドで取り上げました。

eeselは、特定の仕事のために採用するAIチームメイトのセットで、現在のラインナップはヘルプデスクのチームメイトとブログライターです。Slackで共有チャンネルの仕事をするのはヘルプデスクのチームメイトで、1つの仕事に特化したAI従業員に最も近い存在です。eeselのSlackドキュメントによると、次のように動作します。

• チャンネル全体に答えます。 誰でもメンションでき、接続済みのナレッジをもとにスレッドで回答し、情報源へのリンクを付けます。そのスレッドでのフォローアップには再メンションなしで答え続け、DMではメンションは不要です。
• 参加する前に確認します。 接続した直後、インストールした人にDMで、参加したい公開チャンネルとその理由を伝えます。承認したチャンネルにだけ参加します。プライベートチャンネルでは、必ず人が/invite @eeselを実行する必要があります。
• スレッドから行動します。 ヘルプデスクなど他の接続済みアプリで情報を調べ、返信を下書きして、あなたが送信と言うまでスレッドに置いておきます。人の判断を待つ操作がある場合は、Approve、Deny、Review in eeselの付いた承認カードが同じスレッドに投稿されます。
• 検索はSlackの権限に従います。 参加している公開チャンネルと、質問した人も参加しているプライベートチャンネルが対象です。Slackからeeselにデータはコピーされず、回答しながらリアルタイムで検索します。

制限は具体的で、私から正直にお伝えしておきます。メンションの自動化がSlackで唯一のトリガーで、1つのSlackワークスペースは1つのeeselワークスペースに対応します。また、eeselはSlack Marketplaceに掲載されていないため、インストール時にSlackに「not approved by Slack」という通知が表示されます。セットアップはダッシュボードのチャット、またはeesel CLIを使ったターミナルから行えます。eesel integrations connect slackを実行し、続けてeesel automations enable slack slack_eesel_mentioned --instructions "..."を実行します。接続の承認は、Slack上で人が行います。

Slackのプラットフォーム自体にも似た線引きがあります。MCPサーバーは、承認されたAIクライアントがメッセージの検索、読み取り、送信を行えるようにし、「ワークスペース管理者はすべてのMCPクライアント連携を承認し管理できます」。アシスタントがSlackとどうつながるかを比べているなら、Slackでエージェントを構築する、カスタマーサポート向けMCP、Slack AIのエンタープライズ検索の各ガイドが残りを補います。

Slackではどちらを選ぶべきか

私ならこう判断します。

• Townを選ぶのは、あなたが1人（創業者、チーフ・オブ・スタッフ、運用リーダー）で、どのチャンネルでも呼び出せて、受信トレイとカレンダーを把握し、ワンタップなしにあなたの名前で何も送らないアシスタントがほしい場合です。Slackのルーティンを試せるよう、7日間のProトライアルから始めましょう。Instinct AIやLindyと比べているなら、Town AIの代替サービスの記事もご覧ください。
• 共有のチームメイトを選ぶのは、IT、サポート、人事、オンボーディングなど、チームが質問するのがチャンネルで、情報源リンク付きの一貫した回答がほしい場合です。これがeeselの道で、ZendeskやGorgiasなど、すでに運用しているヘルプデスクと併用できます。
• 両方を選ぶのは、個人アシスタントとチームボットの両方がほしいリーダーの場合です。重なりは多くありません。一方はあなたの受信トレイを読み、もう一方はあなたのチャンネルに答えます。

Slackでの仕事が実はチケットキューなら、Slackチケットシステムの比較と、AIヘルプデスクエージェントがチケットそのものに何をするかをご覧ください。AIを追加する前にチャットプラットフォームを選んでいるなら、SlackレビューとSlack vs Teamsの比較が役立ちます。

Slackチャンネル全体の質問にeeselを試す

#it-help、#support、#ask-opsで同じ質問が繰り返されているなら、eeselのSlack向けAIチームメイトが、ConfluenceやNotion、Google Drive、ヘルプセンターをもとにスレッドで回答し、情報源へのリンクを付けます。チャンネルに参加する前に確認し、変更を伴う操作の前には承認カードを投稿します。

プランはeeselの料金ページにある固定のクレジットバンドルなので、静かなチャンネルなら安く済み、連携する前に費用がわかります。テスト用のチャンネルを1つ接続し、短い指示でメンションの自動化をオンにして、1週間分の実際の質問を観察してください。eeselを試す