Atsushi Nakatsugawa
May 19, 2026
1 min read
CodeRabbit Agent for Slack: Four workflows your team can useの意訳です。
月曜日の朝9時14分。Slackを開くと、未読のチャンネルが47件。「ちょっとした質問」で始まるDMが6件。金曜の午後に誰かが@メンションしてきたLinearチケットが1件。日曜の夜に誰かがすでに応急処置したDatadogアラートが1件。そして#eng-supportでは、既知の問題なのか新しいリグレッションなのか判別がつかないお客様からのエスカレーションが1件。
IDEはまだ開いていません。あと1時間は開かないでしょう。「本当の仕事」が始まらないのは、コンテキストの収集が終わっていないからです。
ここは、エンジニアリングの中でも誰もベンチマークしない領域です。そして、まさにそのためにCodeRabbit Agent for Slackは作られました。
私たちはCodeRabbitのメンバーがこのエージェントに、エンジニアの1日を実際に埋めているワークフローを処理させている様子を、短いデモとして録画してきました。以下はその中から4つを紹介します。どれもこれまでは、人が12個のタブを行き来しながら手作業でこなしていた仕事です。それが今では、Slackのスレッド1本の中で完結します。
エンジニアリングマネージャーをやっていれば、このリズムには見覚えがあるはずです。火曜にPRが開かれます。木曜には動きが止まります。翌週の水曜にはマージコンフリクト、古くなった依存関係、そしてSlackでの謝罪スレッドへと育っていきます。
PRが放置されるのは、レビュアーがサボっているからではありません。チャンネルを見ても、そのPRが何の話なのか、何か重要な仕事の足を引っ張っているのかどうかが、ぱっと見では分からないからです。PRのタイトルは「fix flaky test（不安定なテストの修正）」。本当にそうかもしれません。あるいは、認証まわりのリファクタリングが正体を隠して入っているのかもしれません。
ここで使う自動化は、次のようになります。エージェントが1時間毎に、8時間以上動きがないオープンなPRをスキャンします。そして、エンジニアリングチャンネルに、放置されたPRごとに1本のスレッドを投稿します。スレッドには次の情報が乗っています。
最後の項目こそが、このワークフローの価値を支えています。チャンネルをスクロールしてサマリーを読めば、30秒のうちに「いま注意すべきPRはどれか」「朝会まで待っても良いPRはどれか」が分かります。PR作成者にとっても、レビュアーが本当に必要としているコンテキストが添えられているため、嫌味のないリマインドになります。
毎時間というのがややしつこく感じるのであれば、4時間ごとや1日2回など、チームが受け止めやすい頻度に調整できます。
CodeRabbitでは、エンジニアリングが絶えず何かをリリースしています。新しいモデル、新しい仕上げの改善、新しいエージェントの機能などです。社内にいてもキャッチアップが大変な日があるくらいで、マーケティング、サポート、他のエンジニアまでもが、その週に本番へ着地したものを見落としがちです。
だからこそ、私たちは毎週、リリースされたものすべてをエージェントにブリーフィングしてもらっています。
毎週、社内チャンネルにエージェントが次の内容を投稿してくれます。
これは「リリースノート以前のリリースノート」のような存在です。プロダクトマーケティングチームも、サポートチームも、新入社員も使っています。
スピード感のあるチームに合流して、最初の1か月「組織がブラックボックスに感じた」経験がある方なら、これがなぜ効くかはすぐ分かるはずです。これはステータスミーティングでも、誰も更新しないNotionページでもありません。チームが普段から読んでいる場所に届く、自分で自分を書いてくれるダイジェストなのです。
社内的に、これは私たちのお気に入りのワークフローです。お客様にお見せしてきた中でも、CodeRabbit Agent for Slackが他の組織でどう動きうるかが、最もはっきり伝わるものでした。
お客様のチケットがPylonに届きます。サポートエンジニアがそれを#eng-supportに貼り付け、エージェントにタグを付けます。そこから先は、1本のSlackスレッドの中で次が進みます。
かつては、このワークフローを3〜4人と5つのツールで回していました。それが今では、1本のスレッドに収まっています。
ここでぜひ強調しておきたいのは、エージェントがすべてをこなしただけでなく、チーム全員が公開チャンネルでその一部始終を見られたという点です。サポートは、自分が起票したチケットのその後を把握できます。エンジニアリングは、その情報がどこから来たのかを把握できます。1週間後にチャンネルを遡れば、決定の経緯まで含めたインシデントの全履歴が、時系列で並んでいます。「タスクを投げて待つ」非同期のディスパッチ型のモデルが、チームが途中で舵を取れる同期型のワークフローに置き換わっているのです。
最後のこの点こそ、私たちがエージェント型SDLCと呼んでいるものの本質です。あなたがすでに使っているツール群の上を横断し、あなたがすでに仕事をしている場所で動くエージェント、ということです。
金曜にログオフします。月曜に戻ってきます。その間も、組織は止まっていません。
典型的な月曜の段取りはこうでしょう。12個のチャンネルを軽く流し見し、GitHubの通知を片っ端からクリックし、誰かが更新した設計ドキュメントを探し当て、#eng-incidentsに上がっていたインシデントのうち本当に深刻だったものはどれかを判断する。そして、何かしら重要なことを見落とす。
あるいは、エージェントにDMを送ります。「週末のキャッチアップをお願い」と。
エージェントは組織のリポジトリ、あなたがアクセス可能なチャンネル、マージ済みPR、動きのあったスレッドを巡回し、サマリーを返してくれます。「起きたことすべて」ではなく、「あなたが注意を払うべきこと」だけがまとまっています。
ステージングのデプロイを壊したPR。土曜にチームメイトがあなたへ引き継いだLinearチケット。#eng-supportでまだ未解決のお客様スレッド。#platformで議論中のアーキテクチャ論争で、11時に表に出てきそうなもの。
それを2分で読み、最初のミーティングに「ちゃんと状況を把握した状態」で臨めます。
ここに紹介したワークフローのアイデア自体は、新しいものではありません。エンジニアリングチームは、長年にわたって似たことをスクリプトで実現してきました。cron、自前のSlack bot、誰かが英雄的に3か月だけ維持し、その後は生活に追いやられて止まってしまう社内ニュースレター、といった具合です。
いま違うのは、エージェントがコンテキストを持っているという点です。エージェントは、あなたのリポジトリ、チケット、トレース、スレッドを読みつつ、そのアクセスをチャンネル単位、チーム単位、ワークスペース単位で適切にスコープします。利用料、アクセス権、メモリは組織レベルで統治され、火曜になんとなくCLIをインストールしたエンジニア個人の判断に委ねられたりはしません。
ここまでが揃って初めて、上記4つのデモは「一発芸の手品」ではなく、誰でも再現できるものになります。コードがシステムだった時代には、IDEが重心として正しい場所でした。今や、システムがそのままシステムであり、それについてチームが実際に話している場所はSlackです。
インストールして、チャンネルに追加し、スレッドでタグを付けて、上記のいずれかのワークフローから試してみてください。
