CodeRabbitがClaude Marketplaceに登場！Learn more
Atsushi Nakatsugawa
June 16, 2026
1 min read
Slack agentic workflows: how they work & use casesの意訳です。
Slackのエージェント型ワークフローでは、AIエージェントがプルリクエストの作成、障害の切り分け、Jira、Linear、Datadog、GitHub、GitLabなどのプラットフォームからコンテキストを取得し、それをチームがすでに作業しているチャネル内にまとめて配置できます。すべてスレッドの外に出ることなく行えます。
従来のSlackボットはトリガーを待ってメッセージを投稿するのに対し、エージェントは目標を受け取り、使用するツールを選び、複数ステップからなる計画を実行し、作業が完了した時点で結果を報告します。
エンジニアリング、サポート、ITチームにとっては、Slackの中ですでに行われている運用作業の中で、ツール間の受け渡しを減らせることになります。
Slackは、エージェントを「自律的で目標指向のAIアプリケーション」と定義しています。これらは推論を行い、ツールを使い、会話をまたいでコンテキストを保持できます。Slackエージェントは、チャンネル、ダイレクトメッセージ（DM）、スレッド、専用のアシスタントパネルのいずれでも動作できます。どの画面でも、会話そのものがエージェントの作業メモリになります。メッセージをまたいでコンテキストが維持され、エージェントは作業を一時停止して再開でき、目標が変わったときにもチームメンバーが同じ場所に会話を転送できます。
Slackは、エージェントが存在できる場所のひとつです。会話の構造が、人による引き継ぎが必要な複数ステップの作業に特に適しています。なぜなら、エージェントの状態を保持する同じ画面が、チームメンバーが介入するための会話の場にもなるからです。
2つの統合アーキテクチャが共存しており、ワークフロービルダー（Workflow Builder）をその上に配置した構成として使えます。この違いは、エンジニアリングチームが構築するか導入するかを評価するうえで重要です。通常、次の3つの質問が判断の軸になります。
これらの答えによって、エージェントはカスタムアプリとして動作するのか、MCP経由で接続するのか、広い範囲のワークフロー構成に対応するステップとして公開されるのかが決まります。
Slackは、メッセージ、リアクション、スレッド返信、ワークフロービルダーのステップ呼び出しなどのイベントを、アプリの登録済みHTTPSエンドポイントに配信します。Boltアプリ（JavaScriptまたはPython）がイベントを処理し、独自インフラ内の大規模言語モデル（LLM）を呼び出し、Web API経由で応答します。これは、モデル、ロジック、データフローを完全に制御したい、自前で構築・ホストするエージェント向けの経路です。
イベントのライフサイクルは、ユーザーがエージェントパネルを開いたときに発火するassistant_thread_startedから始まります。エージェントはchat.postMessageで応答します。
外部のAIシステムはSlackに接続し、必要に応じてツールコールを発行してコンテンツを読み取り、操作を実行できます。これは、すでに実行しているAIシステムがSlackをデータソース兼アクションソースとして必要とする場合の経路です。
どちらの経路も同じワークスペースで共存できます。たとえば、エンジニアリングチームはBoltを使ってカスタムのデプロイ通知エージェントを構築しつつ、MCP経由で外部AIシステムをSlackに接続して、臨時の調査タスクに活用できます。
ワークフロービルダーは、これら2つの経路の間に位置する、ドラッグアンドドロップでワークフローを組み立てるための構成層です。開発者はBoltアプリからカスタム関数をステップとして公開し、非技術系のチームメンバーがそれをワークフローに組み込めるようにします。
Slack AIは、単一の自然言語プロンプトからワークフロービルダーの自動化を構築できるようになりました。ワークスペースのユーザーがサードパーティ製アプリのステップを含めると、Slackがそのアプリに実行をルーティングします。Slackは、カスタム関数ステップが実行される際にfunction_executedイベント購読でアプリに通知します。アプリはそのロジックを実行し、完了をSlackに返します。
Slackエコシステムには4つのカテゴリのエージェントがあり、それぞれ異なるチーム構成と、構築するか導入するかというトレードオフに適しています。
Slackは、プラットフォームに組み込まれた独自のAI層を提供しています。Slackbot、会話の要約、AIを活用した検索、Salesforceや接続済みシステムにまたがるエンタープライズ検索は、追加の導入なしに利用できます。
Salesforceは営業、ITサービス、人事、購買管理、製品とエンジニアリング向けのAgentforceエージェントを用意しています。SalesforceはSlackでのAgentforce利用を推進しており、公式ページではSlack上でのアクセス方法と設定方法が案内されています。2025年6月には、SalesforceはAgentforceをすべての有料Slackプランに展開できるようにしました。
Slack Marketplaceには、Adobe Express、Cohere、Asana、Boxなどのサードパーティ製エージェントが掲載されています。Slack内でPRレビューやコード特化の機能を求めるエンジニアリングチームは、ゼロから構築するよりも、CodeRabbit Agent for Slackのようなサードパーティ製エージェントを選ぶことが多いです。
自前でエージェントを構築するチーム向けに、Bolt SDKは主要な抽象化としてAssistant クラスを提供しています。公式のサンプルアプリケーションには、ITヘルプデスクのエージェントが含まれており、問題の切り分け、ナレッジベースの検索、チケット作成ができます。これは最も高い制御性を持つ一方で、運用負荷も最も大きい選択肢です。エージェントをホストし、LLMを管理し、監査証跡も自前で保持します。
この分野の多くのエンジニアリングエージェントは、同じパターンに従います。まずコンテキストを集め、その後に操作を実行します。エンジニアは、JiraやGitHubなどのツールに散らばっている関連情報や、古いSlackスレッドの情報を追うために多くの時間を費やしています。
AWS DevOps Agentは、このパターンを明確に示しています。AWSの説明例では、CloudWatchアラームがHTTP 5xxレスポンスなどのエラー率上昇を検知し、エージェントがテレメトリを使って障害を診断し、最近のデプロイと原因を結び付けます。その後、Slackに具体的な緩和策を含む原因分析を投稿します。
PagerDutyのSite Reliability Engineering（SRE）エージェントは、Slack内でインシデント対応を自動化します。切り分け、過去の障害コンテキストの収集、原因の特定、対応手順の提案を行います。関連リンク付きのJiraチケットも作成できます。何かを実行する前に、エンジニアが承認します。
障害の原因が最近のコード変更に遡る場合、CodeRabbit Agent for Slackのようなエンジニアリング向けエージェントが、失敗したビルドを調査し、原因となったコミットを特定し、その場のSlackスレッドから修正用のPRを作成できます。
Slack Marketplaceに掲載されているRavennaやMoveworksなどのツールは、従業員メッセージからのチケット作成や、よくある質問への即時回答を支援します。従業員はSlackを離れることなく、ヘルプデスク業務を処理できます。
一部のチームでは、Slackエージェントをエンジニアリングサポートやトリアージに活用しています。サポートチケットが届くと、AIワークフローがそれを各重要度カテゴリの代表例と照合し、重大なチケットを優先してエスカレーションし、適切なチャネルに振り分けます。
AIコーディングツールはコード生成を高速化しました。2026年1月のJetBrains AI Pulse調査では、開発者の90%が仕事で少なくとも1つのAIツールを日常的に使っていると回答し、CodeRabbitによる470件のPRレビューでは、AI共同作成のPRは人間のみのPRよりもPRあたり1.7倍多くの問題を含むことが分かりました。生成の速度は上がった一方で、確認の速度は追いついていませんでした。
この確認のギャップが、Slack向けのエンジニアリング特化エージェントに余地を生み出しています。CodeRabbit Agent for Slackは、CodeRabbitのレビュー層を、エンジニアリングチームがすでに作業しているチャネルに拡張します。同じスレッドから、エンジニアは保留中のPRを調査し、次の変更に向けた実装計画を作成し、修正内容を含むPRを作成できます。定期実行の自動化では、前日のマージ内容、ブロックされているチケット、夜間のSentryの問題、今日のデプロイ内容をまとめた日次スタンドアップの要約を投稿します。
freeeは、CodeRabbitを導入した結果、6か月間で32.8週間分のレビュー時間を節約しました。Common Appは、個人情報（PII）を扱う高リスクなコードを混在した技術スタックで運用しており、コードレビュー時間を35%短縮し、従来のプロセスでは見逃していたレースコンディションを検出しました。Slack内のエージェント型レビューワークフローは、検知から実行までの遅延を短縮し、エンジニアリング上の判断を維持します。
2025年のDeveloper Surveyでは、開発者のAIコーディング利用は増加している一方で、自信は低下していることが示されています。この傾向は、リポジトリを変更したり、修復作業を実行できるエージェントにとって、機能性だけでなくガバナンス設計が同じくらい重要である理由です。
CodeRabbit Agent for Slackは、スコープシステムを通じて、この課題に対応しています。これは、エージェントが各チャネルやDMでどこにアクセスし、どれだけのコストを使えるかを制御します。各ワークスペースには、デフォルトで全体に適用されるベースのスコープがあり、追加のスコープを設定することで、特定のチャネルやDMに対して既定値を上書きまたは拡張できます。
PagerDutyのSREエージェントは、修復作業を実行する前に明示的な承認を必要とします。エージェントが文章の下書き以上のことをできるようになったら、独立したレビューと限定された権限が不可欠です。
Gartnerのペアで示された予測は、今のエージェント導入の現実をよく表しています。Gartnerは、2026年までに企業向けアプリの40%にタスク特化型AIエージェントが搭載されると予測しています。また、2027年末までにエージェント型AIプロジェクトの40%以上が中止されると予測しています。価値がまだ明確でない場合や、コストとリスク管理の体制が十分でない場合です。Slackのエージェント型ワークフローで成功するチームは、汎用的なAI導入の方針ではなく、特定の負荷の高いワークフローから始めます。
Slackエージェントを使えば、チームはSlackから作業を起動し、承認できます。役立つエージェントは、意思決定と次のアクションの間の距離を縮めます。
エンジニアリングチームは、すでに最も多くの時間を消費しているレビューから始めるのがよいでしょう。CodeRabbit Agent for Slackは、CodeRabbitのレビューエンジンを基盤に、Slack上でAIコードレビューを通じた調査に接続します。スコープ付きのガバナンスと、コンテキストエンジニアリングを3層のメモリにわたって活用します。CodeRabbitは、プラットフォーム全体で1日あたり数千件のPRをレビューしています。その規模により、レビューのボトルネックがプラットフォーム全体で見えやすくなっています。
CodeRabbitは、コードレビューにかかる時間とバグを50%削減します。14日間の無料トライアルを開始。
