Slackbot becomes an AI agent

eyecatch AI関連

「どのSlackアプリに話しかければいいんだっけ？」
インシデント中に /pagerduty か /opsgenie かで数秒迷ったこと、ありませんか？
プロダクトマネージャーが「Jiraのステータスちょっとまとめて」と言ったら、結局エンジニアが手で集計して貼ってる、みたいな。

そんな“Slackアプリ迷子問題”に対して、かなり本気の回答が出てきました。
Slackbotが、ついに「AIエージェント」になりました。

一言でいうと：Slack界の「Bashシェル」がついにAI化した

一言でいうと：Slack界の「Bashシェル」がついにAI化した

今回のアップデートを雑にまとめると：

Slackbotが「ただのヘルプボット」から「AIオーケストレーター」に昇格した

という話です。

今までは：
- /jira
- /deploy
- /something

みたいな、いわばバラバラに散らばったCLIツールがSlack上に転がっていた状態。

これからは：
- ユーザーはSlackbotに自然言語でお願いするだけ
- 「このプロジェクトの進捗ざっくり教えて」
- 「次のスプリントのミーティングアジェンダ作って」
- 裏でSlackbotが：
- Slack AIでメッセージやファイルを検索したり要約したり
- 必要なら、JiraやCI、社内ツールのSlackアプリを“ツール”として呼び出してオーケストレーション

つまり、Slackbot = AI版 Bash になろうとしているわけです。
ユーザーは「やりたいこと」を日本語で書くだけ、あとはSlackbotが「どのツールをどう呼ぶか」を決める。

ぶっちゃけ、これは「SlackにおけるDocker Compose誕生」みたいな匂いがします。
コンテナ（＝各Slackアプリ）は前からあったけど、Compose（＝エージェントとしてのSlackbot） がなかった。
それがようやく出てきた。

何が本当に変わるのか：ボットから「ツール」への立場逆転

正直、このアップデートのポイントは「Slackbotが賢くなった」ことではありません。
本質は、エコシステムの重心がズレることです。

これまで：各アプリがそれぞれ会話体験を実装

  • 各チームがそれぞれボットを作り：
  • Slashコマンドを定義し
  • 独自の会話フローを実装し
  • ヘルプメッセージやチュートリアルを書き
  • ユーザーは：
  • 「あれ、どのコマンドだっけ？」と毎回思い出す必要がある

これから：Slackbotがフロント、アプリは「関数」に降格

Slackbotが「トップレベルのエージェント」になり、
各アプリはAIに呼ばれるバックエンド関数みたいなポジションになります。

開発者視点だと、求められるものが変わります：

  • Before
  • 会話設計、コマンド設計、レスポンスのUIまで全部自前

  • 「人間にとってわかりやすいチャットボット」を作る

  • After

  • やるべきことは「AIにとって扱いやすいツール」を作ること
  • create_issue, fetch_metrics, start_deploy みたいな明確なアクションとパラメータスキーマを定義
  • 「人間」ではなく「エージェント」が使うことを前提に設計

このシフト、エンジニアとしてはかなりデカいです。
JavaScriptフレームワークが全部TS＋型定義前提になったときと同じ空気を感じます。

競合との比較：これは「Teams vs Slack」の第2ラウンド

競合との比較：これは「Teams vs Slack」の第2ラウンド

AIエージェント戦争という意味で、今回一番意識すべき相手はやはりMicrosoft Teams ＋ Copilotです。

スコープの違い：Slackは「会話」、Teamsは「オフィス全部」

  • Slack＋Slackbot AI
  • 主戦場：チャンネル・DM などのテキスト会話

  • 強み：

    • 開発・SRE周りのツール連携（GitHub, Jira, CI/CD, PagerDuty…）
    • メッセージとファイルを横断するSlack AI検索・要約

  • Teams＋M365 Copilot

  • 主戦場：
    • Teamsチャット＋会議
    • Word, Excel, PowerPoint, Outlook, SharePoint などドキュメント中心
  • 強み：
    • Office文書の編集・要約・生成
    • 会議の自動議事録・アクション抽出
    • Azure/Power Platform/Dynamicsとの統合

ざっくり言うと：

  • Slack陣営：
    「開発チーム・プロダクトチームの“運用OS”をAI化する」

  • Microsoft陣営：
    「全社の“ドキュメントと会議”をAI化する」

どちらが正しいというより、組織の文化とスタック次第で向き不向きがきれいに分かれる気がします。

  • Slack＋Slackbotに向いてる会社
  • GitHub/Jira/Notion/Linear/Figma あたりが日常
  • Slackが「実質的な本社」になっている

  • DevOps/インシデントレスポンスがビジネスの生命線

  • Teams＋Copilotに向いてる会社

  • Word/Excel/PowerPoint/Outlook が主戦場
  • SharePoint/OneDriveが情報の源泉
  • 業務アプリはDynamicsやPower Platform前提

Slackは「アプリ連携ハブとしての歴史」が長いので、
エージェントが外部ツールを叩きまくる形のAIワークフローに強い。
逆にMicrosoftは、「Office文書そのものを編集するエージェント」に強い。

Slackbot AIは、完全に前者のポジションを取りにきた感じですね。

一番効いてくるのは、実はスタートアップ潰し

今回のアップデート、地味に一番ダメージを受けるのは、

「Slack上で動く汎用AIアシスタント」を売りにしてきたスタートアップ

だと思います。

  • Slackのメッセージを読んで、要約・検索・Q&Aしてくれる
  • さらに外部ツール（JiraやGitHub）もつないで「エージェント化」します
  • そしてSlack上で自然言語で操作できます

みたいなプロダクト、ここ1〜2年で山ほど出てきましたが、
正直、Slackがネイティブでやる方が圧倒的に有利です。

  • 権限・コンプライアンスの統合（Slack側で一元管理）
  • UXもSlackbotとして馴染んでいる
  • ワークスペース横断じゃなく、「うちのSlack」前提で最適化できる

「Slack向けのAIエージェント」だけを売りにしていたベンダーは、
これから一気に差別化が難しくなるはずです。

逆に言うと、LangChain的な基盤や、社内システム統合そのものに強みがある会社は、
「Slackbotが叩く裏側の“重い”ワークフロー」を請け負うポジションに移動する余地があります。

とはいえ手放しで喜べないポイント：正直ここが怖い

とはいえ手放しで喜べないポイント：正直ここが怖い

便利そうな話ばかりですが、エンジニア視点で見ると「うーん…」と唸る懸念もかなりあります。

ベンダーロックイン：ワークフローごと人質にされる未来

Slackbotをオーケストレーションレイヤーにし始めると、
組織の「AIワークフロー」がどんどんSlack固有の設計に引き寄せられます。

  • ツールのスキーマ
  • 権限モデル
  • ワークスペースごとの制約

全部がSlack前提になる。

その結果：

  • 別のチャットツールや社内ポータルに乗り換えたいとき
  • 表面的なメッセージだけでなく
  • AIエージェント＋自動化フローごと移植が必要

正直、「Slackが社内OS」になっている会社ほど、
このロックインはかなりエグいものになります 🤔

オーケストレーションの“中身”が見えない問題

AIエージェントって、便利な反面何やったかが見えにくい。

  • どのアプリを何回呼んだのか
  • 途中でどんな中間結果が出ていたのか
  • どこでエラーになったのか

記事からは、まだこのあたりのトレース機能や監査ログについての言及はほとんどありません。

金融・医療・公共系みたいにコンプライアンスの厳しい領域だと：

  • 「このレポート、Slackbotがどのデータを元に、どう集計したの？」
  • 「このチケット作成、誰の指示で実行されたことになってる？」

といった説明責任が求められます。
ここをSlackがどこまで真面目にやるかで、エンタープライズ導入の現実度がかなり変わります。

レイテンシと信頼性：チェーンが長くなるほど地獄

AIエージェントが複数ツールを連鎖的に叩くようになると：

  • 1つのリクエストで：
  • Slack AI検索
  • Jira API
  • CIのステータス取得
  • その結果の要約
  • …と、3〜5ステップ平気で発生します。

そのたびに：
- ネットワーク遅延
- レートリミット
- 認証周りのエラー

が積み上がる。

ユーザーの期待値はいつも通り：

「Slackbotに聞いたら、すぐ答えが返ってくるよね？」

なんですが、裏側の現実は：

「これ、3つの外部SaaSとL3の社内APIたたいてるんだけど…😇」

みたいなことになります。

開発者側からすると：
- 冪等性（同じツールが何回呼ばれても安全）
- タイムアウト設計
- リトライ戦略

をちゃんと設計しないと、
「時々変な二重登録が発生する謎のAIフロー」が量産されます。

開発者負荷の質が変わる：確率的な呼び出しと戦うことになる

今までのSlashコマンドは、ある意味とても健全でした。

  • 引数は自分でパース
  • バリデーションも自分でコントロール
  • 仕様どおり動く or 明示的にエラー返す

AIエージェント経由になると：

  • AIがツール仕様を「だいたいこんな感じでしょ」で理解してくる
  • 想定と微妙に違うパラメータが飛んでくる
  • オプションの解釈が曖昧になる

これ、完全に確率的なインターフェースです。
エラー処理・スキーマバリデーション・安全装置を、今まで以上にゴリゴリ書く必要が出てきます。

「LLMのtool callingを本番で運用するときのつらみ」を、
Slackアプリ開発者が一斉に味わうフェーズに入る、という感じですね。

料金とプランの壁：全員が体験できるとは限らない

Slack AI自体が、
- 無料プランでは使えない
- 有料でも一部の上位プラン・オプション扱い

であることを考えると、

  • Slackbot AIエージェント体験 = Slack AIが前提
  • つまり、「お金を払っているワークスペース」だけの世界

という線が濃厚です。

スタートアップや小規模チームだと：

  • 一部チームだけAIエージェントが使える
  • 別ワークスペースのクライアント側では動かない
  • PoCはできたけど本格展開はコストで頓挫

みたいな、なんともモヤモヤする未来も見えます。

じゃあエンジニア的にどう向き合うべきか？

個人的な結論を正直に書くと：

プロダクションのクリティカルフローを全部Slackbotに預けるのは、まだ様子見。
でも、「ツールとして呼ばれても大丈夫な状態」に今のSlackアプリを進化させる価値は高い。

すぐにやっても良さそうなこと

  • 既存のSlackアプリを棚卸しして：
  • どの機能が「ツール化（＝明確なアクション＋パラメータ）」しやすいか洗い出す
  • 副作用のある操作は冪等性とロールバックを考えなおす
  • APIレスポンスの速度と安定性を改善する
    → エージェント経由のチェーンに乗ると、遅いツールは即ボトルネックになります
  • ログと監査の設計を見直す
    → 「誰の指示で、Slackbot経由でこの操作が走ったのか」が追えるようにしておく

逆に、今はまだ慎重でいいと思うこと

  • 「インシデント時の本番デプロイフロー」を最初からSlackbot任せにする
  • 給与・人事・権限変更系など、人間のレビューが絶対必要な業務を丸ごとエージェント化する

ここは正直、
- Slack側がどこまでトレーサビリティ・権限管理・エラーハンドリングを整えてくるか
- 社内で「AIエージェントにどこまで任せていいのか」という合意形成が進むか

を見ながら、段階的に侵食させるのが現実的だと思います。

最後に：Slackbotが「空気」になるか、「黒箱」になるか

最後に：Slackbotが「空気」になるか、「黒箱」になるか

今回のSlackbotのエージェント化は、
歴史的には「Bashが単なるシェルから、スクリプトでなんでもできるOS的存在になった瞬間」にちょっと似ています。

  • うまくいけば：
    Slackbotは「意識せずに使い続けている空気のような存在」になり、
    開発チームの生産性を1段上げるインフラになる。

  • 失敗すると：
    「たまに便利だけど、何やってるかよくわからない黒箱」になり、
    本番運用からは徐々に遠ざけられていく。

どちらに転ぶかを決めるのは、
Slack自身の実装とプロダクト設計もありますが、
我々開発者が“ツール側”をどれだけちゃんと設計できるかにもかかっています。

プロダクションのど真ん中を任せるのは、正直まだ様子見。
でも、「Slackbotに呼ばれても恥ずかしくないツール」を今から作っておくこと自体は、
どの方向に転んでも無駄にはならない投資だと思っています。

スポンサーリンク

コメント

タイトルとURLをコピーしました