Slack Codeとは｜コードチャンネルの仕組み・対応エージェント・料金・他社比較・導入の注意点

Slack Codeとは、Slackのチャンネルの中でAIコーディングエージェントに開発作業を任せ、チームの全員が同じ場所で計画・変更内容・プレビューを確認し、修正指示と承認をできるようにする機能です。 Slack(Salesforce傘下)が2026年8月20日(現地時間)に発表し、同日から無料プランを含むすべてのSlackプランで提供が始まりました(段階展開中)。公式の定義は「コードチャンネルは、エージェントと人間が連携してAIで構築を行うことができるSlackのスペース」で、タスクごとに専用の「コードチャンネル」が作られ、会話・計画・コードの差分・HTMLのライブプレビューをタブで見ながら作業が進みます。対応エージェントはClaude(Anthropic)・Devin(Cognition)・GitHub Copilot・Vercel Agentの4つで、ChatGPT(OpenAI)は近日対応です。この記事では、公式ヘルプと各エージェント提供元のドキュメントを一次情報として、仕組み・承認の設計・料金と必要なプラン・従来のSlack連携や他社の仕組みとの違い・セキュリティ上の論点・発表直後の評判・導入の進め方までを整理します。

対応状況はSlackの英語版公式ヘルプで確認できます。2026年9月6日の確認時点でも、承認済みエージェント一覧はClaude・Devin・GitHub Copilot・Vercelの4つです。発表ブログでの言及と、実際の対応一覧は区別してください。

Slack Codeとは何か — 「ターミナルの中の開発」を会話の場に出す

従来の生成AIによるコーディングは、開発者1人とAIの間で(多くはターミナルやエディタの中で)進み、途中経過がチームから見えませんでした。Slackはこれを「プライベートなタブの中の開発を、オープンな場に出す(brings software development out of private tabs and into the open)」と表現しています。中核は「コードチャンネル」と呼ばれる、タスク専用の寿命が決まったチャンネルです。

コードチャンネルの仕組み — 作り方・タブ・ステータス・寿命

作り方は2通り

公式ヘルプの基本手順は「エージェントをメンションし、コードチャンネルを始めたいと伝えて、作りたいものを説明する」です。チャンネルでもDMでもメンションできます。もう1つ、サイドバーの「コードチャンネル」セクションから手動で作る経路もあります。Slackのヘルプでは「エージェントとツール」→「コードチャンネル」→「新規」でエージェント・可視性(パブリック/プライベート)・最初のプロンプトを指定する手順(Enterpriseはワークスペースの選択も)、Vercel Agentの公式ドキュメントでは「Code channels」の「More actions」→「Create a code channel」→エージェントにVercelを選ぶ手順として案内されています(発表を伝えた一部メディアは「エージェントしか作れない」と報じていますが、公式ヘルプとパートナーのドキュメントは手動作成の手順を載せています)。Devinのように、スレッドでの会話が本格的な作業に発展したときにエージェント側の判断でコードチャンネルへ移す動きや、@Devin !new のようなコマンドで最初から作る方法を用意しているエージェントもあります。

チャンネル名はエージェントが最初の依頼内容から自動で付けます。元の会話にはコードチャンネルへのリンクカードが残り、チャンネルの最新情報が開始元のメッセージへ通知されます。

タブと生成物 — 何が見えるか

発表文の表現は「会話・計画・コードの差分・ライブプレビューが、それぞれのタブに」です。ヘルプではこれらを「セッションの生成物(Artifacts)」と呼び、次の4種類を挙げています。

ライブプレビューはHTMLが対象です。Vercelの場合はこれに加えて、変更が反映された時点でデプロイのプレビューURLがスレッドに投稿されます。メッセージ欄の上には「クイックアクション」として、プルリクエストの作成など、そのエージェントの機能に直結する操作へのリンクが並びます。

ステータスと寿命

チャンネルは人が閉じることも、7日間動きがなければサイドバーから自動で消えることもあります。アーカイブ後も履歴は閲覧・検索でき、GitHub Copilotのドキュメントでは「必要なら再開もできる」とされています。発表文が「監査ログとして残る」と呼んでいるのはこの検索可能な履歴のことで、Enterpriseの監査ログAPIとの連携を意味する記述は現時点で確認できません。

参加者と可視性

通常のチャンネルと同じく、パブリック(誰でも参加)かプライベート(元の会話のメンバーが参加)かを選べ、メンバーになれば他の人や他のエージェントを追加できます。ただしエージェント側の制約があります。GitHub Copilotはリポジトリへの書き込み権限を持つ人しか変更を指示できず(意見を言うだけなら誰でも可)、ワークスペースのゲストやリポジトリの外部コラボレーターはセッションを開始・操作できません。Vercel Agentは外部共有(Slack Connect)チャンネルでは応答しません。

承認と停止 — 人がどこで止めるか

製品ページの見出しは「あなたのサインオフなしには何も出荷されない(Nothing ships without your sign-off)」です。公式の説明は「本番へのコード反映のような重要度の高い操作では、エージェントが作業をまとめて専門家のサインオフに回す。チャンネルの中で」というもので、参加者の誰でも「脱線したら一時停止・方向転換・停止できる」とされています。停止の操作は「処理中」バッジにカーソルを合わせて「[エージェント名]を停止」です。

ただし、承認の細部はSlackではなく各エージェント側で決まっていることに注意が必要です。

つまりSlack Codeの承認は「チャンネル内で止める・確認する場」を提供するもので、マージの最終関門はGitHubのプルリクエストレビューや各社のガードレールです。作業の途中に人の確認を挟むヒューマンインザループの設計が二重になっている、と理解すると実態に近くなります。稟議で言えば、Slack Codeは「起案から決裁までの回覧を一つの部屋で見える化する」仕組みで、決裁印そのものはこれまで通りの場所で押される形です(稟議書の書き方の「決裁者が見る観点」はそのまま承認者の確認項目に転用できます)。

実行場所 — コードはSlackの中では動かない

Slack Codeを理解するうえで最も誤解されやすいのがここです。エージェントの作業はSlackの中ではなく、各提供元のクラウド環境で行われます。

各エージェントの実行環境は、提供元のドキュメントに明記されています。Claude(Claude Tag)は「Anthropicがホストする一時的なサンドボックスで動き、リポジトリをサンドボックスに複製し、変更をブランチまたはプルリクエストとしてGitホストに戻す」、プルリクエストは「Claude GitHub App」名義です。GitHub Copilotは「安全なクラウドサンドボックスで非同期に作業を続け」、チャンネルに対象リポジトリ・ブランチ・Issue/PRのリンク・ステータス・使用中のモデルを表示します。Vercel Agentのコミットとプルリクエストは「Vercel Agent GitHub App」が作成・署名し、依頼者がGitの共同作成者として追加されます。DevinはクラウドのVMで実行し、!windows でWindows環境も選べます。

この構造から導かれる実務上の意味は2つあります。第一に、Slack Codeを入れても、コードやリポジトリが新たにSlackへ渡るわけではないこと。渡る先はこれまで通り各エージェント提供元で、その扱いは各社の規約に従います。第二に、エージェントを動かす権限とリポジトリの権限は、呼び出した人のものだということ。強い権限を持つ人がメンションすれば、その範囲でエージェントが動きます。

対応エージェントと必要なプラン

Slack側は無料でも、エージェント側の契約が必要です。各社のドキュメントから必要条件を整理します。

このほか、Slackは「Add to Slack」でワンクリック追加できるビルダーとしてNanoClaw・Lovable・Hyperagent・Superhuman・n8n・LangChain・Runlayer・Skydiveなどを挙げていますが、これらは「Slackにエージェントを追加できる」という話で、コードチャンネルで動く承認済みエージェントはヘルプ記載の4つ(近日5つ)に限られます。Slackは「近くコードチャンネルAPIを広く開放し、どんなカスタムエージェントでも、どんな種類の仕事でもコードチャンネルに参加できるようにする」と予告し、マーケティングキャンペーン・法務の契約レビュー・ITのオンボーディングへの拡張を示唆しています。

費用面で見落としやすいのは、Slack Codeは無料でもエージェントの利用料は従量や席料として別に発生することです。Claude Tagは組織の使用量残高から引き落とされ、Vercelは依頼ごとの従量、Copilotは席あたりの有料プランです。AIコストの管理の考え方はAIコストの管理で解説しています。

従来のSlack連携・他社の仕組みとの違い

「SlackからAIコーディングエージェントに依頼する」こと自体は、2025年から可能でした。CursorのBackground Agents(2025年6月)、GitHub Copilot coding agent(Teams 2025年9月、Slack 2025年10月)、Claude Code in Slack(2025年12月)などです。Slack Codeが新たに加えたのは「器」です。

Slack Codeが加えたものを5点にまとめると、①差分・計画・プレビューをSlack内のタブに持ち込んだこと(従来は外部リンク)、②タスクごとの寿命が決まったチャンネルという器、③参加者全員の停止・方向転換権、④チャンネル自体が検索可能な記録になること、⑤複数ベンダーのエージェントが同じチャンネル仕様に乗ること、です。Slackは、Claude CodeやCodexのようなターミナル系のツールは「深いアーキテクチャ作業で併存する」という見方を示しており(VentureBeat)、置き換えではなく「チームで見る必要がある作業」の受け皿という位置づけです。

同じ週にxAI(SpaceXAI)が出したGrok Bot(クラウド上の作業用PCで業務アプリを操作する常駐型エージェント)とは、「AIに実務を渡し、人は確認と承認に回る」という方向は同じですが、Slack Codeは実行環境を持たず、可視化と承認の場に徹している点が対照的です。

なぜ承認必須なのか — 背景にある事故と、Slack Codeが防げるもの・防げないもの

Slack・Salesforceの発表文は具体的な事故に言及していませんが、発表を伝えた海外メディア(Gizmodo、The Next Web)は、コーディングエージェントが本番環境を壊した事例を引き合いに出しています。公開情報で確認できる主な事例を挙げます。

これらの事故に共通するのは、「人が途中で見ていなかった」「エージェントが強すぎる権限を持っていた」「本番と検証が分かれていなかった」の3点です。Slack Codeが効くのは1点目で、参加者全員が途中経過を見られ、誰でも止められる設計は「見ていなかった」問題への直接の答えです。一方で2点目と3点目はSlack側では防げません。エージェントは呼び出した人の権限で動くので、強い権限のトークンをエージェントに渡していればSlack Codeを使っていても同じ事故は起きますし、環境分離はリポジトリとインフラ側の設計の問題です。

もう1つ、公開チャンネルならではの論点があります。Claude Code in Slackの公式ドキュメントは「Claudeは文脈内の他のメッセージに含まれる指示に従う可能性があるため、信頼できる会話でのみ使うこと」と警告しています。チャンネルの会話全体がエージェントへの入力になる以上、第三者の書き込みが指示として働く(プロンプトインジェクション)経路が構造的に存在します。コードチャンネルをパブリックにするか、プライベートで参加者を絞るかは、この観点で決めるべきです。

管理者・セキュリティ担当が確認すべきこと

Slack側の統制は既存の仕組みの延長です。公式の記述を整理します。

確認すべきは、Slack側よりもむしろエージェント側と開発ツール側の設定です。①どのエージェントを誰に許可するか(Slack側)、②そのエージェントがどのリポジトリにどの権限で接続しているか(各社側)、③プルリクエストの保護ルールと必須レビュー人数(GitHub側)、の3層が揃って初めて「承認なしには出荷されない」が成立します。社内ルールとして明文化する際の枠組みは生成AIの社内ガイドラインの作り方を参照してください。

発表直後の評判 — 肯定と批判

発表から2日の時点で、実際にSlack Codeを動かしたレポートはまだ確認できません。反応は主に発表内容への評価です。

• 肯定的な見方: Salesforce CEOのMarc Benioff氏は「Don’t code alone(1人でコードを書くな)」と投稿。Cognition(Devin)のJeff Wang氏は「社内でマージされるPR数が数か月で10倍になった」とコメント。The New Stackは「エージェントしか開けないチャンネル」という新しいチャンネル種別に注目し、Hacker Newsでも「非開発者も入れる仕様駆動の公開チャンネルに可能性がある」という声があります
• 批判的な見方: Hacker Newsのスレッドは否定的な意見が優勢で、「Slack経由だとトークン消費が制御できない、レビューはGitHubのほうがよい」「LLMのコードは読めなくなり、システムの理解をAIに依存する」「これだけ多様な仕組みを全部試す時間が誰にあるのか」といった実務的な指摘が並びました。The Next Webは「チャットでの承認はスピードと可視性を優先する分、コードレビューの厳密さを下げるリスクがある」と論じています
• 市場の見方: ForbesはMicrosoft Teamsとの競争を主題にし、調査会社Info-Techのアナリストの「開発者に今のプラットフォームを捨てさせられるかは答えにくい」というコメントと、技術的負債の加速や脆弱性混入の懸念を伝えました。VentureBeatはGartnerの「エージェントAI案件の40%超が2027年末までに中止される」という予測を併記しています

共通するのは、「見える化と承認の場」という方向性には賛同が多い一方、レビューの質・費用の制御・ツールの乱立という実務の課題は残る、という評価です。

Slackのエージェント戦略の中での位置づけ

Slack Codeは単発の機能ではなく、2年がかりの布石の上にあります。

MCPの仕組み自体はMCPとはで解説しています。なお発表文自体はMCPサーバーやHeadless 360との関係に直接触れておらず、上の整理は時系列から見た位置づけです。開発者向けには、2026年9月15〜17日のDreamforce 2026でコードチャンネルのセッションとライブデモが予告されています。

非エンジニアのチームには何が変わるか

Slack Codeが注目に値するのは、開発の様子が「エンジニアの画面の中」から「チームの会話の場」に出てくることです。営業・マーケティング部門の実務では、たとえば次のような使い方が考えられます。

• 問い合わせフォームの項目追加や、LPの文言・構成の修正をエージェントに依頼し、HTMLプレビューで実物を確認してから承認する
• 展示会のリード一覧を整形する集計スクリプトのような、小さな社内ツールの作成を依頼する
• 依頼から承認までの記録がチャンネルに残るため、「誰の指示でこの変更が入ったのか」を後から追える

これまで情報システム部門や外部ベンダーへの依頼書を書いて数週間待っていた小さな改修が、依頼・確認・承認までチャットで完結する可能性があります。Slack社内の実績として示された「コードチャンネルの70%超が1日以内に開いて閉じる」という数字は、この規模感を裏づけるものです。営業・マーケティングの実行工程全体をエージェントに移す流れはAgentic GTMで整理しています。

導入の進め方 — 最初の2週間の設計

1. エージェントを1つに絞る。 最初はすでに社内で契約があるエージェント1つ(多くの場合GitHub CopilotかClaude)で始めます。複数を同時に試すと、権限・費用・レビュー基準の比較ができなくなります
2. 対象リポジトリと権限を決める。 エージェントは呼び出した人の権限で動くため、本番に直結するリポジトリは最初の2週間は対象外にします。社内ツール・LP・ドキュメントサイトのような、壊れても戻せるリポジトリから始めます
3. プルリクエストの保護ルールを先に確認する。 「承認なしには出荷されない」を実現しているのはGitHub側の設定です。必須レビュー人数と、エージェント名義(Claude GitHub App等)のPRを誰がレビューするかを決めます
4. コードチャンネルはプライベートで始める。 会話全体がエージェントへの入力になるため、参加者を関係者に絞り、慣れてからパブリックにするか判断します
5. 承認者と確認項目を決める。 「何が変わるか」「元に戻せるか」「本番に触れるか」の3点を承認前に確認する、と決めておきます。diffを読まずに承認するなら、承認フローがない状態と同じです
6. 費用を週次で確認する。 Slack側は無料でも、エージェント側は従量(Claude Tag・Vercel)か席料(Copilot)です。誰がどのエージェントをどの予算で使うかを決めずに展開すると、部門ごとに費用がばらばらに発生します

この「生成と確認を分け、人の承認を関所にする」設計は、AIに作業を任せるときの一般原則でもあります。仕組みとしての考え方は自己修正ループで解説しています。

よくある誤解

1. 「Slackがコードを書いたり実行したりする」→ 違います。 実行は各エージェント提供元のクラウドで、Slackは会話の文脈を渡し、進捗・差分・プレビューを表示する場です。
2. 「無料で使える」→ Slack側だけです。 エージェントの契約(Claude Tagの従量課金、Copilotの有料プラン、Vercelの従量など)は別に必要で、ゲストは使えません。
3. 「ChatGPTも使える」→ 近日対応です。 発表時点で使えるのはClaude・Devin・GitHub Copilot・Vercel Agentの4つです。
4. 「Slack内で承認すれば安全」→ 最終の関門はGitHub側です。 Slack側の承認は「止める・確認する場」で、マージの保護ルールや必須レビューが甘ければ機能しません。
5. 「自社のエージェントも入れられる」→ まだです。 現時点ではMarketplaceの承認済みエージェントに限られ、API開放は「近く」と予告されている段階です。

Slack Codeは「AIが開発する」こと自体の発表ではなく、AIの開発作業をチームの確認と承認の下に置くための仕組みです。効果を決めるのはSlack側の機能よりも、どのエージェントにどの権限を渡し、どこで誰が承認するかという自社の設計です。エージェントに仕事を任せる流れは営業・マーケティングにも同じ構造で来ているため、確認・承認・記録をどう設計するかという論点ごと押さえておくことをおすすめします。