Slack Codeとは｜Claude Codeをチームで動かす

「AIにコードを書かせているが、何をやっているのか本人以外は誰も見ていない」「気づいたら勝手に動いていて、後から追えない」——AIエージェントをチームに入れた会社が、最初にぶつかるのがこの不透明さです。

結論から言うと、Slack Codeはこの不透明さそのものを設計対象にした製品です。エージェントの作業を専用チャンネルの中で行わせ、計画・コードの差分・動くプレビューをタブとして開いたまま進め、終わったらアーカイブして記録に残します。2026年8月20日にSlackが発表し、Claude・Devin・GitHub Copilot・ChatGPT・Vercelの5社が最初のパートナーとして名を連ねています（このうちChatGPTは、公式発表で「近日中に対応予定」とされています）。

株式会社Fyveは、AIエージェントを無人で常時稼働させる運用を自社で1年近く続けてきました。その立場から見て、Slack Codeで本当に重要なのは「Slackでコードが書ける」ことではなく、エージェントの作業を"見える場所"へ引きずり出したことだと考えています。この記事では発表内容を整理したうえで、実際に無人運用をしてきた側の視点で「何が効くのか」「導入前に何を決めるべきか」を書きます。

Slack Codeとは——2026年8月20日発表の「エージェントと一緒に作る場所」

3行でいうと

• Slackの会話からコーディングエージェントにメンションすると、そのプロジェクト専用の「コードチャンネル」が自動で立ち上がる
• チャンネルの中には会話のほかに「計画」「コードの差分」「ライブプレビュー」のタブがあり、チーム全員がリアルタイムで見て、口を出せる
• 作業が終わるとチャンネルはアーカイブされ、Slack上に監査ログのように記録が残る

Slackの発表文には、Slack Codeの狙いがこう書かれています。「Slack Code は、ソフトウェア開発をプライベートなタブから解放し、オープンな場へと持ち込みます。チームと AI エージェントが一緒に計画し、コードを書き、レビューできるようにするためです」。

つまり主語は「コードを速く書くこと」ではありません。「一緒に」の部分です。ここを読み違えると、単に「Slackの中でもコードが書けるようになった機能」という理解で終わってしまいます。

発表時点で参加している5社のエージェント

Slackは公式発表で「本日は Anthropic、Cognition、GitHub、OpenAI、Vercel とともにローンチし、さらに多くのパートナーが順次加わる予定です」としています。パートナーは次の5社です。

なお、この5社目の扱いは、参照する媒体によって書きぶりが割れています。Slack公式とThe Next Webは5社を創業パートナーとして並べていますが、VentureBeatの記事本文はClaude・Devin・GitHub Copilot・Vercelの4つのみを挙げています。「パートナーは5社、ただしChatGPTは発表時点で利用開始前」と読むのが、公式発表の記述と最も整合します。実際に使い始める前に、対応状況は公式の最新情報で確認してください。

加えてSlackは、コードチャンネルのAPIを開発者コミュニティへ開放する方針を示しています。将来的には独自のエージェントをコードチャンネルへ持ち込めるようになる、という位置づけです。ここが実現するかどうかで、Slack Codeが「5社の相乗り機能」で終わるか「エージェントの運用基盤」になるかが分かれます。

使える条件と料金

報道各社の記述で一致しているのは次の2点です。

• どのSlackプランでも、発表当日から利用できる（「Slack Code is available today on any Slack plan」）
• 各エージェントへのアクセスは別途購入が必要（「Access to each partner agent is a separate purchase」）

読み方としては「Slack側の入場料は取らない。エージェント側の契約は自分で持ってきてください」という設計です。すでにClaude CodeやGitHub Copilotを契約しているチームは、追加コストなしで試せる可能性が高い、ということになります。

ただし、Slack Code側の細かい制限（同時に動かせるエージェント数、対応リポジトリ、無料プランでの回数上限など）は発表時点の各記事では明示されていません。導入判断に金額が絡む場合は、必ず公式の最新情報で確認してください。

何が変わるのか——「1人と1体の密室」が開く

これまでのAIコーディングは、他の人から見えなかった

VentureBeatは、Slack Codeが解こうとしている問題をこう表現しています。「Today, most work with AI coding agents happens between one person and one agent, invisible to everyone else（今日、AIコーディングエージェントとの作業のほとんどは、1人と1体のあいだで起きていて、他の誰からも見えない）」。

この一文が、Slack Codeという製品のすべてです。

AIエージェントに仕事を任せると、作業の実体はローカルのターミナルか、個人のチャット画面の中で完結します。チームに共有されるのは「終わった結果」だけです。どういう計画で進めたのか、途中で何度やり直したのか、どこで判断を変えたのかは、指示を出した本人の記憶の中にしか残りません。

その状態でも、うまくいっているうちは問題になりません。問題になるのは、うまくいかなかったときです。「なぜこうなったのか」を誰も再構成できないからです。

コードチャンネルの動き——4つのタブ

Slack Codeでは、会話の途中でコーディングエージェントをメンションすると、その場でプロジェクト専用のチャンネルが立ち上がります。Slackの発表文では「複雑なプロジェクトでコーディングエージェントをメンションすると、チャンネルが立ち上がり」「コードの差分やライブプレビューが、長文テキストではなく、コードチャンネル内に直接表示されます」と説明されています。

報道によれば、チャンネル内には次のタブが用意されます。

私がここでいちばん効くと思うのは「計画」タブです。差分はできてしまった後のものですが、計画はできる前に止められる唯一のポイントだからです。エージェントの事故は、実装の巧拙ではなく「そもそも違うものを作りにいった」で起きることのほうが圧倒的に多い。差分レビューだけを置いても、この型の事故は防げません。

もう一つ、非エンジニアの立場から見て見逃せないのがライブプレビューです。コードの差分は読めなくても、動いている画面なら判断できます。「AIが作ったものを社内の誰も検品できない」という中小企業でよく起きる詰まりに、直接効きます。

終わったらアーカイブされ、記録として残る

Slackの発表文にはこうあります。「作業が完了すると、チャンネルはアーカイブされますが、Slack 上に監査ログのように残り、後から参照できます」。

ここは地味ですが、運用の観点では最も価値がある部分です。作業チャンネルが増え続けると、それ自体がノイズになって誰も見なくなります。終わったものを自動で閉じるという設計が入っているかどうかで、半年後の使われ方がまったく変わります。

途中で止められる／本番マージには人間の承認が要る

統制まわりで報じられているのは次の3点です。

• 「Agents in code channels inherit Slack's permissions and admin controls」——エージェントはSlack既存の権限と管理者コントロールを引き継ぐ
• 「Anyone in a channel can pause, redirect or stop an agent mid-task」——チャンネルにいる誰もが、作業の途中でエージェントを一時停止・方向転換・停止できる
• 「Slack Code also requires human sign-off on high-stakes actions like merging code to production」——本番へのマージのような影響の大きい操作には、人間の承認が必要

Slack公式も「Slack Code は Slack 既存の権限と管理者コントロールを継承するため、IT 部門が新たな設定や監査を行う必要はありません」と書いています。新しい権限体系を増やさない、という判断です。

権限設計の考え方そのものについては、こちらの記事で整理しています。

Claude CodeAIエージェントの権限管理｜業務導入で押さえる3層設計

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

私が無人でAIエージェントを動かして分かった3つのこと

ここからは実運用の話です。私は自社で、AIエージェントの実行専用にした1台のマシンを常時稼働させています。決まった時刻に複数のジョブが自動で起動し、調査・執筆・チェック・公開までを人の操作なしで進める構成です。誰も見ていない時間帯にエージェントが動く、という点ではSlack Codeが解こうとしている問題の極端版を、先にやってきたことになります。

そこで分かったことのうち、Slack Codeの評価に直結する3つを書きます。

①「終わりました」という報告は、失敗しても同じ形で届く

私の運用では、各ジョブが終了時にチャットへ1行の完了報告を投げます。設計した当初は、これで十分に可視化できていると思っていました。

実際には違いました。ある時期、記事の公開前チェックを担当する自動ゲートが内部的な認証切れを起こし、「判定できませんでした」を返し続けていたことがあります。仕組み上そうなると成果物はすべて安全側に倒れて下書きへ退避されるので、事故にはなりません。ところが完了報告の1行は、正常に回っているときとほとんど同じ見た目で届き続けました。気づくまでに2週間ほど、数十回分の実行を空振りさせています。

ここから学んだのは、報告は可視化ではないということです。報告は「終わった」という事実だけを伝えます。「何をやって終わったのか」は伝えません。そして厄介なことに、失敗の報告と成功の報告は、放っておくと同じ形をします。

Slack Codeがやろうとしているのは、この「同じ形」を壊すことです。計画タブと差分タブが空なら、空だと一目で分かる。1行のテキストでは絶対に見えないものが見えます。

②見えるとは「結果」ではなく「途中」が残ること

可視化と聞くと、多くの人はダッシュボードや成果レポートを思い浮かべます。しかしエージェント運用で本当に必要なのは、結果ではなく途中です。

結果だけを見ても「どこで間違えたか」は分かりません。分かるのは「間違えた」ことだけです。次に同じ失敗を防ぐには、判断が分岐した地点まで遡る必要があり、そのためには計画・試行・やり直しが順番に残っている必要があります。

私の運用では、この反省から、各ジョブが「何を選び、何を捨てたか」を毎回テキストで書き残す形に変えました。書き残す先が台帳でもチャンネルでも構いませんが、選ばなかった選択肢まで残すのが肝心です。採用した案だけ残すと、後から読んでも「なぜ他をやらなかったのか」が復元できず、同じ検討をもう一度やる羽目になります。

無人運用でのログ設計については、こちらで詳しく書いています。

Claude CodeClaude Codeの無人運用ログ設計｜サブエージェント可視化

③ログは、読まれて初めてログになる

Slack Codeの「アーカイブされて監査ログとして残る」という設計は正しい。ただし、残っているだけのログは、無いのとほぼ同じです。

私も一度、失敗の記録を全部ファイルに残す仕組みを作って安心していたことがあります。半年後に振り返ったとき、そのファイルを一度も開いていませんでした。残す設計はできていて、読む設計ができていなかったのです。

いま採っているのは単純な方針です。異常は、能動的に人の目の前へ運ぶ。正常はログに沈めていい。逆にすると、正常の山の中に異常が埋まって、誰も掘り返さなくなります。

Slack Codeを導入するチームも、同じ設計判断が要ります。コードチャンネルを作っただけでは、見られるようにはなりません。「誰がどのタイミングで、どのタブを見るのか」を決めて初めて、可視化は運用になります。

権限は「できること」ではなく「戻せるか」で切る

Slack Codeの立て付け——bot権限を作らない

VentureBeatが伝えている設計思想が、実務的にはいちばん重要です。「Everything is done on behalf of the user, using the user's ACLs, both in Slack and in the systems that they're connecting to. There's no god permissions or bot-level permissions（すべてはユーザーの代理として、Slack側でも接続先システム側でもそのユーザーのアクセス権で実行される。神権限やbot水準の権限は存在しない）」。

エージェント連携でいちばんよくある事故は、「便利だから」と強い権限を持つ共有アカウントを1つ作ってしまうパターンです。誰でも呼べて、何でもできて、記録上は全部そのアカウントがやったことになる。事故が起きたとき、誰の指示だったかを再現できません。

Slack Codeは、そこを最初から潰しています。エージェントは呼んだ人の権限で動くので、見られないものは見られないままです。権限設計を新しく作らなくていい代わりに、既存のSlack権限が雑なら雑なまま引き継がれる、という裏返しもあります。導入前に、いまのチャンネル権限を一度点検しておくのが順番として正しい。

私が自分の運用に置いている3つの線

私の無人運用では、権限を「できること」ではなく「戻せるかどうか」で切っています。具体的には3本の線を引いています。

1. 書き込み範囲を1つのフォルダに限定する。 その外側への変更は、実行を包んでいるシェル側が検出して破棄し、警告を通知します。エージェント自身の判断に頼らず、外側の機械が止める形にしているのが要点です
2. 新規作成は許すが、既存の上書きは手順として禁止する。 私のサイトには600本を超える記事が公開されていて、これが事業の本体です。新規記事が1本壊れても損害は限定的ですが、既存記事が静かに壊れると、数週間後にアクセス数が減ってから気づくことになります。事後監査で救えない領域には、そもそも手を伸ばさせない
3. 既存に触る必要がある操作は、専用の道具経由だけにする。 その道具は、変更前後を突き合わせて意図した追記以外が入っていないことを確認し、確認に失敗したら自動で元へ戻します。人の目視を挟まずに安全性を担保するには、これしかありませんでした

「戻せるか」で切ると、判断が速くなる

この基準の良いところは、迷わないことです。「この操作は危ないか?」で考えると、危険度の見積もりが人によってぶれます。「失敗したとき、元に戻せるか?」で考えると、答えはたいてい一つに決まります。

Slack Codeが「本番へのマージには人間の承認を要求する」という線を引いているのも、同じ発想です。本番マージは戻すのに時間がかかる。だから人を挟む。逆に、ブランチ上の試行錯誤は戻せるので、エージェントに好きにやらせてよい。

この考え方は、開発以外にもそのまま使えます。社内文書の下書き作成は戻せる。顧客への送信は戻せない。データの追加は戻せる。削除は戻せない。境界線は「AIに任せていい仕事かどうか」ではなく「元に戻せるかどうか」に引く——これが、私が1年やって残った一番シンプルな結論です。

導入前に決めておく5つ

Slack Codeを試すのは簡単ですが、チームで運用に載せるなら、先に決めておくべきことがあります。私が自社の無人運用を組むときに躓いた順に並べます。

とくに4番は、実体験として強く言えます。安全側に倒す設計（怪しければ止める・下書きに退避する）は正しいのですが、正しく止まったことと、正しく動いたことは、報告の上では見分けがつきません。止まった回数を別で数える仕組みを、必ず一緒に入れてください。

Claude Codeを使っているチームは、何をチャンネルへ移すか

移すと効く作業

• 仕様が固まりきっていない実装——計画タブで方向を潰せるので、手戻りが減ります
• 非エンジニアが結果を判断する必要がある作業——ライブプレビューがそのまま検品の材料になります
• 複数人で分担している改修——誰が何を投げたかがチャンネルに残るので、二重作業が起きにくい
• 引き継ぎが発生する作業——アーカイブが「何をどう決めたか」の資料になります

移さなくていい作業

• 1人で完結する短い試行錯誤——チャンネルを立てるコストのほうが高くつきます。ターミナルのままでいい
• 探索的な調査——結論が出るまで大量の空振りが出る作業をチャンネルに流すと、ノイズで他の人が見なくなります
• 秘匿性の高い領域——Slackの権限を引き継ぐ以上、チャンネルの設計を先に整えるまでは持ち込まない

すでにSlackとClaude Codeを連携させているチームは、MCP経由の構成と役割が重なる部分があります。既存の連携と何をどう棲み分けるかは、こちらを参照してください。

Claude CodeClaude Code × Slack MCP連携の実践ガイド

複数のエージェントを並行して動かす設計そのものについては、Claude Code Agent Teams｜AIチーム協働術で扱っています。

開発チームがいない会社にとっての意味

ここまで開発の話をしてきましたが、Slack Codeの本質は開発に限りません。「AIに仕事をさせるなら、人が見える場所でやらせる」という原則です。

いま多くの会社で起きているのは、社員一人ひとりが個人のAIチャット画面の中で仕事を進めている状態です。成果は出ているのに、やり方は共有されない。誰がどんなプロンプトで何を作ったのか、隣の席の人は知らない。担当者が辞めた瞬間に、その仕事はゼロに戻ります。

これは、Slack Codeが解こうとしている「1人と1体の密室」と同じ構造です。開発だけの問題ではありません。

開発チームがいない会社でも、いますぐできることがあります。

• AIに投げた依頼と結果を、個人のチャットではなくチームの見える場所に置く（専用チャンネルを1つ作るだけでいい）
• うまくいった依頼文を、成果物と一緒に残す（成果物だけ残すと再現できない）
• 「戻せない操作」をリストにして、そこだけ人の承認を挟む

Slack Codeのような製品が出てきたということは、「エージェントの作業は見える場所でやらせる」という考え方が、業界の標準になりつつあるということです。ツールを入れるかどうかとは別に、この原則だけは先に採り入れておいて損はありません。

一方で、期待だけで進めるのも危険です。VentureBeatは同じ記事の中で、ガートナーが「2027年末までにエージェンティックAIプロジェクトの40%以上が中止される」と予測していることにも触れています。可視化の仕組みを入れること自体が成果を保証するわけではない、という前提は持っておくべきでしょう。

よくある質問

Slack Codeを使うのに追加費用はかかりますか

報道では「どのSlackプランでも当日から利用できる」「各パートナーエージェントへのアクセスは別途購入」とされています。Slack側の追加費用は発表時点では示されておらず、エージェント側（Claude Code、GitHub Copilotなど）の契約は自分で用意する形です。詳細な条件は必ず公式の最新情報を確認してください。

Claude Code以外のエージェントも使えますか

発表時点のパートナーは Anthropic（Claude）、Cognition（Devin）、GitHub（Copilot）、OpenAI（ChatGPT）、Vercel の5社です。ただしChatGPTだけは公式発表に「近日中に対応予定」と書かれており、発表時点ですぐ使えるのは残る4つと読むのが妥当です。加えてSlackは、コードチャンネルのAPIを開発者コミュニティへ開放する方針を示しており、将来的には独自エージェントの持ち込みも想定されています。

エージェントが暴走した場合、止められますか

報道によれば、チャンネルにいる誰もが作業の途中でエージェントを一時停止・方向転換・停止できるとされています。加えて、本番へのマージのような影響の大きい操作には人間の承認が必要な設計です。ただし「止められる」ことと「止める人がいる」ことは別です。誰が見るかを決めておかないと、機能はあっても働きません。

セキュリティ面で新しく設定することはありますか

Slack公式は「Slack Code は Slack 既存の権限と管理者コントロールを継承するため、IT 部門が新たな設定や監査を行う必要はありません」としています。裏を返すと、いまのSlack権限がそのまま効くということです。チャンネルの公開範囲やゲストの扱いが曖昧なままなら、先にそちらを整理するのが順番です。

非エンジニアでも参加する意味はありますか

あります。ライブプレビューのタブがあるため、コードが読めなくても動いている画面で判断できます。仕様の食い違いは、コードの差分よりも動く画面のほうが早く見つかります。「作ったものを社内の誰も検品できない」という状態を崩す入口として有効です。

まとめ

Slack Codeは2026年8月20日に発表された、コーディングエージェントをSlackのチャンネル内で動かす仕組みです。Claude・Devin・GitHub Copilot・ChatGPT・Vercelの5社が最初のパートナーで、このうちChatGPTのみ「近日中に対応予定」とされています。どのSlackプランでも使えますが、エージェント側の契約は別途必要です。

製品として本当に新しいのは、Slackでコードが書けることではありません。エージェントの作業を「1人と1体の密室」から引きずり出し、計画・差分・プレビューという形で途中を残したことです。1年近く無人でエージェントを動かしてきた経験から言えば、ここが運用の生死を分けます。報告は可視化ではなく、結果だけでは失敗の原因まで遡れないからです。

導入するなら、機能より先に決めることがあります。誰が呼ぶか、どこまで触らせるか、誰が差分を見るか、失敗をどう数えるか、記録をいつ読み返すか。そして権限は「できること」ではなく「戻せるかどうか」で切る。この5つと1本の基準さえ決めておけば、ツールが何であってもエージェント運用は破綻しません。

株式会社Fyveでは、AIエージェントを業務へ組み込む際の権限設計・運用ルールづくりを含めて支援しています。自社の業務のどこから任せるべきか迷っている場合は、Claude Code導入支援サービスもあわせてご覧ください。