Slack Code: コーディングエージェントがチームのチャンネルに入ってきた

コーディングエージェントでいちばん重要なのは、もうコードをどれだけ上手に書けるかではありません。誰が、その作業を見られるかです。今月までは、多くのチームにとって率直な答えはこうでした。1人の開発者が、非公開のターミナルかブラウザータブで見守り、あとでエージェントが実際に何をしたか思い出せることを願う。8月20日に公開されたSlack Codeは、その答えを「プロジェクトの全員が、最初から見られる」に変えようとする、これまでで最大の試みです。

私はローンチ発表、Slack自身の続報、それから報道を読みました。下で動くモデルは、すでに知っているClaude Code、Devin、Copilotと同じです。変わるのは仕事が行われる部屋です。そして、その違いは多くの報道が示す以上に大きいと思います。

要点 - Slack Codeは「コードチャンネル」を追加します。Claude Code、Devin、GitHub Copilot、Vercel、今後追加予定のChatGPTといったコーディングエージェントを呼び出し、共有プロジェクト空間で作業させます。差分、ライブプレビュー、人間による出荷前承認が全員に見えます。 - 初日からすべてのSlackプランで使えます。ただし各エージェントの利用権は別途購入します。作業が終わるとチャンネルは自動アーカイブされ、監査ログが残ります。 - 本当の変化は監督の仕方です。1人だけが見る非公開セッションから、チームで見る共有成果物へエージェント作業が移ります。帰属とレビューの穴を埋める一方、傍観者効果、形だけの承認、チャンネルのコンテキスト自体が攻撃面になるといった新しい問題も生みます。 - これは配布経路を取る動きでもあります。Slackは1年かけてエージェント向けの配管を整えてきました。MCPサーバー、リアルタイム検索、SlackbotのMCPクライアントです。コードチャンネルは、それをユーザーの目に見える形にするサーフェスです。 - 「出荷前に人が承認する」は設計目標として扱うべきで、保証ではありません。レビュー工程そのものは、やはり本物でなければなりません。

何が起きたのか

8月20日、Slackは無料ワークスペースを含むすべてのプランでSlack Codeを公開しました。ローンチ時の報道とTechRepublicの記事によると、仕組みはこうです。

• Slackの任意の会話でコーディングエージェントをメンションします。バグ修正、ページ更新、機能開発など、そのタスク専用のコードチャンネルをエージェントが作ります。

• チャンネルにいる全員が、エージェントが参照している同じ会話を見られます。提案されたコード差分を確認し、HTMLのライブプレビューを見て、フィードバックを送り、それをエージェントが反映します。最後は人間が完成物を承認します。人の承認なしでは何も出荷されません。

• 作業が終わるとチャンネルは自動的にアーカイブされ、記録用の監査ログが残ります。

• ローンチパートナーはAnthropicのClaude、CognitionのDevin、GitHub Copilot、Vercelです。OpenAIのChatGPTも近日追加予定と発表されています。SlackはコードチャンネルAPIをより広い開発者コミュニティに開き、独自エージェントも参加できるようにする予定です。

誰をチャンネルへ入れるかは設定できます。Slackの製品担当VP Katie Steigman氏はReworkedにこう話しています。「エージェントをメンションしてコードチャンネルを作ったユーザーだけを参加させることもできますし、エージェントが持つコンテキストを基に、誰をチャンネルへ入れるべきか自分で推測するよう設定することもできます」。SlackのEVP兼ゼネラルマネージャーRob Seaman氏は狙いをこう表現しました。「AIは、チームが実際に仕事をする流れの一部になって初めて価値を生みます」。

Slack Codeは2026年8月20日にすべてのSlackプランで公開されました。提携コーディングエージェント（Claude、Devin、Copilot、Vercel、今後追加予定のChatGPT）を共有の「コードチャンネル」に入れ、チーム全員がエージェントの会話、差分、ライブプレビューを見られるようにします。出荷前に人が承認し、作業完了後にチャンネルが自動アーカイブされると監査ログも残ります。Slackの発表で確認できます。

監督が非公開セッションの外へ出る

機能一覧では見えにくいことがあります。今のエージェント監督の多くは、疲れた1人の人間が維持している半分フィクションのようなものです。エージェントは誰かのIDEかクラウドサンドボックスで動き、差分がプルリクエストとして届き、「レビュー」は午後5時のその開発者にどれだけ気力が残っているかで決まります。推論の流れ、行き止まり、うまくいった案の前に試した3つの案は、全部消えます。私はエージェントの成果物をかなり見てきましたが、差分はプロセスの中で最も情報量が少ない部分だと思っています。

Slack Codeが本当に提案しているのは、プロセス自体を成果物にすることです。チャンネルには、エージェントが参照した会話、中間段階、受け取ったフィードバック、得た承認が残り、そのすべてが検索可能な記録としてアーカイブされます。これは監督モデルとして本当に違います。そして、今のチームがエージェントをレビューするやり方より、優れたチームが若手エンジニアを見るやり方に近い。出力だけではなく、仕事の過程を見るわけです。

監督する人も変わります。売り文句として明確に、PM、デザイナー、非技術系のチームメンバーも経過を追えるとされています。私は慎重ながら賛成です。ただし一つ留保があります。見ている人がたくさんいる部屋と、レビュー担当者がいることは同じではありません。差分を読める力は、その場にいるだけで身につきません。「チーム全員が見られる」は、静かに「誰も確認しなかった」へ変わり得ます。ここで生まれるガバナンス上の問い、つまり10人が見ていたのに誰も承認責任を負っていなかった場合に誰が責任を負うのかという問題は、私がエージェントガバナンスの枠組みで扱っているものそのものです。Slack Codeが答えを出してくれるわけではありません。ただ、問題を見えるようにします。それは誠実な第一歩です。

Slack Codeはエージェント監督を非公開セッションから、共有されてアーカイブされるチャンネル記録へ移します。会話、中間段階、フィードバック、承認がすべて検索可能な成果物として残ります。Slackの製品記事にあるとおりです。一方、見物人が何人もいる部屋で誰が承認責任を持つのかという問いは、顧客側で決める必要があります。

共有コンテキストには両面がある

2つ目の大きな主張はコンテキストです。Slackの考え方は、タスクに必要な文脈はすでにチャンネル内にある、というものです。バグ報告、仕様の議論、顧客からの苦情などです。それを非公開プロンプトへコピーして貼るのではなく、文脈がある場所でエージェントも仕事をするべきだ、と。これは正しいと思いますし、Slackが今年ずっと出してきた基盤の上に乗っています。MCPサーバーとリアルタイム検索APIは2月に一般提供となり、エージェントがガバナンスされた形でワークスペースのメッセージとファイルへアクセスできるようになりました。6月にはSlackbotのMCPクライアントも続きました。私は使う価値のあるMCPサーバーのまとめで、チームのツールへMCPでアクセスできることこそエージェントコンテキストの有用な半分だと書きました。チャンネルモデルは、その考えを最後まで進めたものです。

ただし、共有コンテキストは共有された露出面でもあります。チャンネルを読むエージェントは、その中のすべてを読みます。「ちょっとだけ」と誰かが貼った認証情報も、顧客から転送された外部コンテンツも含みます。私が知るセキュリティ研究者なら全員、同じことを言うでしょう。エージェントが読めるコンテンツは、エージェントへの指示にもなり得ます。共有チャンネルは、非公開セッションより大きなプロンプトインジェクション面です。これは単純な事実です。書き込み権限を持つエージェントを活発なチャンネルへ向ける前に、どのチャンネルを読ませ、どのツールに触らせるかを意識的に決める価値があります。これは設定の話ではなく、アーキテクチャの話です。エージェント型アーキテクチャで書いたのと同じトレードオフで、能力と被害範囲は一緒に大きくなります。

Slack Codeのコンテキスト上の利点、つまりタスクの文脈がすでにある場所でエージェントが働くことは、Slackが2026年2月に一般提供したMCPベースのワークスペースアクセスの上に成り立っています。Unite.AIの記事でも触れられています。同じ共有コンテキストは、プロンプトインジェクションと認証情報露出の範囲も広げます。このトレードオフはローンチ資料では扱われていません。

帰属とレビュー、地味だけれど効くところ

このローンチでいちばん派手ではない部分こそ、私は実際に買いたいと思います。まず帰属です。コードチャンネルでは、すべてのエージェント行動がエージェント自身のIDの下に残ります。ワークスペースはすでに全員のIDを把握しており、プロジェクトが終わっても監査ログが残ります。基本的な話に聞こえます。そのとおり、基本です。ただ、今の多くのチームがエージェント作業に持っている帰属基盤よりはずっと進んでいます。今は「エージェントがやった」と「私がやった」が同じgit履歴に溶けていることが珍しくありません。規制の厳しい業界は、この退屈な仕組みをもう1年ほど求め続けています。

次にレビューです。チャンネル上で差分とライブプレビューを見て、フィードバックをエージェントが反映し、出荷前には強制的な承認ゲートがあります。ただし、書かれていないことにも注目してください。Slackの資料は「人が作業を承認する」と説明しますが、私が見た範囲では、その人が誰であるべきか、何を見せられるのか、設定されたレビュー担当者が休暇中ならどうなるのかは指定していません。承認をチェックボックスにすると、形だけの承認になります。誰もが緑のボタンを押すことだけ学ぶ。ここで価値を得るのは、承認を実際のコードオーナーと本物の差分レビューにつなぎ、エージェントのチャンネル出力はレビューそのものではなく証拠として残すチームでしょう。

競争状況も無視できません。Reworkedの記事が触れているように、Microsoftは2025年9月にTeamsのスレッドへCopilotコーディングエージェントを入れ、Blockは2026年7月にオープンソースのBuzzを公開しました。チャット画面はエージェント仕事の争奪地になりつつあります。Slackの強みは派手ではありません。チームがすでにそこにいることです。コラボレーションソフトウェアでは、賢さより配布経路が勝つことが多い。今回もそうだと思います。

Slack Codeでは各エージェントがチャンネル内で独立したIDを持ち、アーカイブされたプロジェクトごとに監査ログが残ります。TechRepublicが報じています。ただし承認ゲートの「出荷前に人が承認する」という説明には、レビュー担当者のIDやレビュー基準まで指定されていません。直接比較できる例として、MicrosoftのTeams Copilotエージェント（2025年9月）とBlockのオープンソースBuzz（2026年7月）があり、Reworkedが整理しています。

今、何をすべきか

Slackを中心に仕事をしていて、コーディングエージェントも使っているチームなら3つです。

1. 今週: 重要度が低く、仕様がはっきりしたタスクを一つ選んでください。文言変更、再現手順が明確な小さなバグなどです。2、3人が見ているコードチャンネルで実行します。試しているのはエージェントではなく、チームのレビュー行動です。誰かが本当に差分を読むか見てください。

2. 本物の変更を出荷する前に: 各リポジトリのエージェント作業について、誰が承認者なのか、何を確認しなければならないのかを書面で決めてください。答えが「チャンネルにいる誰か」なら、レビュー工程があるのではなく、ボタンがあるだけです。

3. 広く展開する前に: エージェントが読めるチャンネルと、その実行環境が持つ認証情報の範囲を決めてください。チャンネル履歴はコンテキストであり、コンテキストは攻撃面でもあります。狭く始め、証拠がたまってから広げてください。

FAQ

Slack Codeとは何ですか

2026年8月20日に公開されたSlackの機能です。チームが会話の中で提携コーディングエージェント（Claude Code、Devin、GitHub Copilot、Vercel、今後追加予定のChatGPT）をメンションできます。エージェントはタスク専用の「コードチャンネル」を開き、チームは作業を見て、差分とプレビューを確認し、出荷前に結果を承認します。作業が終わるとチャンネルは自動でアーカイブされます。

有料のSlackプランが必要ですか

いいえ。Slack Codeは無料ワークスペースを含むすべてのプランで利用できます。ただし、各コーディングエージェントへのアクセスは、そのエージェントのベンダーから別に購入します。実際の費用は、どのエージェントにすでに支払っているかで変わります。

Slack Codeはコードレビューの代わりになりますか

なりません。そして、代わりになると思うことが最大のリスクです。Slack Codeはレビューを共有・アーカイブ可能なチャンネルへ移し、承認ゲートを追加します。ただしレビューの質は、名前のある人間が差分を読むかどうかに依存したままです。責任者のいない見えるプロセスは、きちんとしたレビュー担当者がいる非公開プロセスより悪い場合があります。監督されているように見えてしまうからです。

エージェントにチャンネル全体を読ませても安全ですか

チャンネルに何があるか次第です。貼り付けられた認証情報や、転送された外部コンテンツを含め、エージェントが読めるものはすべてエージェントへ影響を与え得ます。読み取り範囲を狭くし、エージェントの認証情報は最小権限にし、チャンネル内容を信頼できない入力として扱ってください。エージェント側から見れば、実際そのとおりです。

結論

Slack Codeでエージェントがより良いコードを書くようになるわけではありません。そのための製品ではありません。エージェントの仕事を、チームがすでにいる場所で、最初から見えるもの、誰がしたか分かるもの、レビューできるものにします。そしてこの3つは、多くのエージェント導入で静かに欠けているものです。ただし、見えることと監督されていることは同じではありません。チャンネルは記録とゲートを用意します。誰かが本当に見ているかは、まだ自分たちで解かなければならない問題です。エージェントそのものより、チームが承認者をどう設定するかを見てください。これが機能するか、形だけになるかはそこに出ます。

レビューの統制を失わずにエージェントをチームのワークフローへ入れる方法を考えているなら、これは私がクライアントとよく話すテーマです。お問い合わせください。

情報源

• Salesforce「Slack Codeの紹介: チーム向けエージェント型コーディング」: https://www.salesforce.com/introducing-slack-code/ （2026-08-19公開、2026-08-29参照）

• Slack「Slack Code: チームとエージェントが一緒に作る場所」: https://slack.com/blog/news/slack-code-channels-for-agents （2026-08-28公開、2026-08-29参照）

• Unite.AI「Slack Code、AIコーディングエージェントを専用プロジェクトチャンネルへ」: https://www.unite.ai/slack-code-puts-ai-coding-agents-in-dedicated-project-channels/ （2026-08-20公開、2026-08-29参照）

• TechRepublic「Slack Code: AIコーディングエージェントにレビューと監督の共有チャンネル」: https://www.techrepublic.com/article/news-slack-code-ai-coding-agents/ （2026-08-21公開、2026-08-29参照）

• Reworked「Slack Code、AIコーディングエージェントを共有チャンネルへ」: https://www.reworked.co/collaboration-productivity/slack-code-brings-collaborative-ai-coding-into-channels/ （2026-08-20公開、2026-08-29参照）