>
>
公開日
Slackは2026年8月20日（現地時間）、AIコーディングエージェントとチームが同じ画面で開発を進める新機能「Slack Code」を発表しました。会話の中でエージェントにメンションするだけで専用の「コードチャネル」が自動生成され、計画・コード差分・プレビューをチーム全員が見ながら開発を進められる仕組みです。エンジニア以外の従業員も開発プロセスに関わるようになる分、情シスとしては権限継承や承認フロー、監査ログの扱いを事前に押さえておく必要があります。本記事では、Slack Codeの仕組みと対応エージェント、導入・運用時に確認すべき統制ポイントを整理します。
Slack Codeとは何か
Slack Codeは、AIコーディングエージェントとの共同作業を「コードチャネル」という専用スペースに切り出し、チーム全員が進捗を見ながら開発できるようにする新機能です。
従来はエンジニアが個人のブラウザタブでエージェントと1対1でやり取りし、完成した成果物だけがチームに共有される「一人プレイ」的な使い方が中心でした。Slack Codeはこの働き方を、会話・計画・コード差分・プレビューがすべて1つのチャネルに集まる「マルチプレイヤー（チーム参加型）」の開発体験に変えることを狙っています。
コーディングエージェントを会話中にメンションすると、そのタスク専用のコードチャネルが自動で立ち上がり、関係者が招集されます。チャネル内には会話・計画・コードの差分（diff）・動作中のHTMLプレビューがそれぞれタブとして表示され、参加者は進捗を見ながらフィードボックスを入れたり、途中でエージェントを止めたり方向修正したりできます。作業が完了するとチャネルは自動でアーカイブされますが、検索可能な監査ログとしてSlack内に残り続けます。
なぜSlackはコードチャネルを打ち出したのか
Slackがコードチャネルを開発した背景には、自社のエンジニアリング組織が抱えていた課題があります。複雑で複数ターンにわたるエージェントの実行を通常のスレッドに詰め込むと情報が埋もれてしまう一方、開発者が個人のブラウザタブに閉じこもって作業すると、Slackが大切にしてきた「オープンな場での協働」が失われてしまうというジレンマです。
Slackはこの課題への回答として、必要に応じて拡張し、適切なタイミングで人を巻き込み、作業が終われば自然にフェードアウトする専用スペースを設計しました。Slackの説明によると、同社内のコードチャネルは70％以上がアイデア出しからプルリクエストのマージまで1日以内に完結しているといいます。バグ報告や細かなUI修正がその場で対応されるようになり、レビューに必要な文脈共有の手間も減っているとのことです。
情シスの観点で重要なのは、この「チーム全体に見える形で開発を進める」という設計思想そのものが、シャドーAI化対策の文脈と親和性が高い点です。個人のブラウザタブで完結していたエージェントとのやり取りが、承認・レビューの記録が残るチャネルに集約されることで、可視性という面ではむしろ統制しやすい方向に働く可能性があります。
Slack Codeの仕組みと主要機能
Slack Codeの核となるのは、プロジェクト単位で自動生成・自動アーカイブされる「コードチャネル」と、その中で完結する差分レビュー・プレビュー機能です。情シスが確認すべきポイントは、権限継承の仕組みと、本番反映時に人間の承認を挟む設計になっているかどうかです。
機能 | 内容 | 情シスが見るべき観点 |
|---|---|---|
コードチャネルの自動生成・アーカイブ | エージェントをメンションすると専用チャネルが立ち上がり、完了後は自動アーカイブされ監査ログとして残る | アーカイブ後のログ保存期間・検索権限・エクスポート可否 |
コード差分（diff）の可視化 | 変更前後の行を並べて表示し、チャネル参加者全員がレビュー可能 | 誰が承認権限を持つか、レビュー担当者の明確化 |
ライブHTMLプレビュー | 実際に動作する画面をチャネル内で確認できる | 社内データや顧客データがプレビュー環境に露出しないか |
既存の権限・管理者設定の継承 | Slackの既存の権限管理・管理者設定をそのまま引き継ぐ設計 | 継承元となるSlack側の権限設計がそもそも適切か |
本番反映時の人間承認 | 本番環境へのコードプッシュなど重要操作はチャネル内で人間の承認を経る | 承認フローがチャネルのオーナーやレビュアーに限定されているか |
柔軟なAPI | アカウントの自動プロビジョニングや認証、ワークフローの自動化を組織に合わせて設計可能 | API経由で付与する権限の範囲、書き込み権限の限定 |
「既存の権限管理をそのまま継承する」という設計は運用負荷を抑える一方で、継承元となるSlackワークスペース自体の権限設計が甘い場合はそのリスクごと引き継がれる点に注意が必要です。Claudeを組織に安全に組み込むための権限設計は、Claudeのエンタープライズ認証・権限管理の実践ガイドでも詳しく解説していますので、あわせて参考にしてください。
対応エージェントと連携状況
Slack Codeは特定のAIベンダーに閉じた機能ではなく、複数の外部エージェントパートナーとともに提供される「オープンな受け皿」として設計されています。記事執筆時点で、Claude（Anthropic）、Devin（Cognition）、GitHub Copilot、Vercelのエージェントが利用可能で、ChatGPT（OpenAI）は近日対応予定とされています。
パートナー | 提供元 | コードチャネルでの主な役割 |
|---|---|---|
Claude | Anthropic | Claude Tagがコードチャネルを起動し、要約機能で進捗を共有しながらチームと一緒に変更を仕上げ、完了後は自動でアーカイブ |
Devin | Cognition | 会話の流れの中で自律的に応答し、バグ報告を受けて修正とプレビュー提示までを完結 |
GitHub Copilot | GitHub | 非エンジニアが自然言語で問題を説明し、修正案の作成からエンジニアによるレビュー依頼までを1つの会話内で完結 |
Vercelのエージェント | Vercel | 変更が入るとその場でライブプレビューを生成し、共有可能なリンクをチャネルに投稿 |
ChatGPT | OpenAI | 近日対応予定（記事執筆時点） |
利用にあたっては、Slack Codeの利用自体はすべてのSlackプランで可能である一方、各パートナーのエージェントを実際に使うには、それぞれ個別のアカウントやサブスクリプションが別途必要になる点も確認しておきましょう。Claudeそのものの基本的な仕組みや料金体系については、Claude（クロード）とは？読み方・料金と企業活用で整理していますので、社内説明資料の土台としてご活用ください。
Slack上でClaudeをチームの一員として扱う「Claude Tag」の仕組みそのものについては、日々の開発ガバナンスとも関わりが深いため、Claude Codeの企業導入・ガバナンス実践ガイドもあわせてご確認ください。
既存の連携方式との違い
Slackでコーディングエージェントを呼び出す仕組み自体は、Slack Codeが初めてではありません。個別のエージェント連携を、コードチャネルという共通の枠組みに統合した点がSlack Codeの特徴です。
方式 | 概要 | Slack Codeとの違い |
|---|---|---|
Cursor（Anysphereが2025年提供開始） | Slackで「@Cursor」とメンションすると、スレッドの文脈を読んで作業しGitHubにPRを作成 | 専用チャネルではなくスレッド単位の連携。複数エージェントを横断する共通基盤ではない |
Codex（OpenAI） | Slackからタスクを起動し、Codex側で処理を実行 | 同じくスレッドベースの起動が中心で、diffやプレビューを1画面に集約する設計ではない |
Microsoft Teams + Copilot/Cursor/Linear/Rovo（2026年6月Microsoft Build発表） | Teamsのチャットやチャネル内で複数エージェントが会話の文脈をたどって作業 | チャットツール上でエージェントを動かす発想は共通するが、プラットフォームが異なりSlack上のワークフローとは別管理になる |
Slack Code | 複数パートナーのエージェントを「コードチャネル」という共通の枠組みで扱う | 会話・計画・diff・プレビューを1つのチャネルに集約し、権限継承と人間承認をセットで設計 |
複数のコーディングエージェントが並行して社内に入り込む状況は、承認されていないツールがなし崩し的に広がる「シャドーAI化」のリスクにもつながります。この論点は、Meta「Muse Code」ベータ版公開｜機能・料金と情シスが備える統制ポイントでも扱っていますので、複数エージェント時代の統制方針を検討する際にご参照ください。
情シスが導入前に確認すべきチェックポイント
Slack Codeは「既存の権限管理をそのまま継承する」ため導入のハードル自体は低く見えますが、継承する権限設計や承認フローの実態を事前に確認しておかないと、想定より広い範囲にエージェントの操作権限が及ぶ可能性があります。導入前には次の観点をチェックしておきましょう。
権限継承の実態確認：コードチャネルが継承するのは「そのSlackワークスペースの既存権限」であるため、対象チャネルの参加者・投稿権限・外部共有設定が想定通りかを事前に棚卸しする
承認フローの設計：本番環境へのプッシュなど重要操作について、誰が承認者になるのか、承認者不在時のエスカレーション先を明文化する
監査ログの保存期間とアクセス権：アーカイブされたコードチャネルが監査ログとしてどの程度の期間保持されるか、閲覧・エクスポートできる担当者の範囲を確認する
パートナーエージェントごとの契約・利用権限：Claude・Devin・GitHub Copilotなど各エージェントの利用には個別のアカウントやサブスクリプションが必要なため、契約主体と支払い元、利用可能な部署を整理する
プレビュー環境への機密情報露出リスク：ライブHTMLプレビューに社内データや顧客データが表示される構成になっていないかを事前に確認する
非エンジニアの参加範囲：PMやデザイナーなど非エンジニアもコードチャネルで指示を出せる設計のため、どこまでの操作を許可するかの運用ルールを定める
これらの確認項目は、社内で利用しているSaaSやツールの棚卸しがそもそも済んでいることが前提になります。未承認ツールの利用実態を洗い出す方法は、情シスのための生成AI利用状況可視化ガイドでも解説していますので、Slack Codeの導入検討と並行して社内のAI利用実態を確認しておくと安心です。
導入後の運用・統制のポイント
導入後は、コードチャネルが「便利だから」という理由でなし崩し的に権限が広がっていかないよう、定期的な棚卸しの仕組みを組み込んでおくことが重要です。
まず、コードチャネルで誰がどのエージェントをどの権限で使っているかを、Slackのワークスペース管理画面と突き合わせて定期的に確認する運用を決めておきましょう。エージェントが人間の承認なしに広範な操作を行ってしまった事例は他社でも報告されており、承認フローの形骸化がどのようなリスクにつながるかは、OpenAIのエージェント暴走インシデントから学ぶ教訓が参考になります。
また、Slack上でのAIチャットボット・エージェント活用全般に共通するセキュリティ設計の考え方は、Slackチャットボットの構築手法と選定基準・セキュリティ対策にまとめています。Slack Codeに限らず、Slack上でエージェントを動かす際の共通チェックポイントとして活用できます。
社内で利用するAIエージェントが増えるほど、「どのエージェントを誰が使っているか」を横断的に把握する必要性も高まります。複数の生成AIツールを比較・選定する際の観点は、情シス向けAI3大ツール比較と導入選定基準、GPT系モデルの企業導入観点はGPT-5.6の企業導入ガイドでも整理していますので、Slack Codeとあわせてツール選定の材料にしてください。
よくある質問（FAQ）
Q. Slack CodeはすべてのSlackプランで使えますか？
Slack Code自体はすべてのSlackプランで利用できます。ただし、Claude・Devin・GitHub Copilot・Vercelなど各パートナーのエージェントを実際に使うには、それぞれのエージェントの利用権限（アカウントやサブスクリプション）が別途必要です。
Q. コードチャネルの中身は誰でも見られますか？
コードチャネルはSlackの既存の権限管理・管理者設定をそのまま継承する設計です。そのため、誰が閲覧・参加できるかは、対象となるSlackワークスペースやチャネルの既存の権限設定次第です。導入前に対象チャネルの権限範囲を確認しておくことをおすすめします。
Q. 本番環境へのコード反映もエージェントが自動で行ってしまうのですか？
いいえ。本番環境へのプッシュなど高リスクな操作については、チャネル内で人間の承認を経る設計になっています。ただし、誰が承認者になるか、承認者不在時にどう対応するかは組織側で運用ルールを定める必要があります。
Q. 非エンジニアの従業員もコードチャネルを使えますか？
使えます。Slack CodeはPMやデザイナーなど非技術者でも自然言語で問題を説明し、エージェントに修正案を作らせ、エンジニアにレビューを依頼するところまでを1つの会話内で完結できるよう設計されています。そのため、どこまでの操作を非エンジニアに許可するかという運用ルールの整備が重要になります。
Q. ChatGPTはいつからSlack Codeで使えますか？
記事執筆時点では、Slackの発表で「近日対応予定」とされています。最新の対応状況は、Slackおよび各社の公式情報でご確認ください。
まとめ
Slack Codeは、AIコーディングエージェントとの共同作業を「コードチャネル」という専用スペースに集約し、チーム全体で進捗を見ながら開発を進められるようにする新機能です。Claude・Devin・GitHub Copilotなど複数パートナーのエージェントに対応し、既存のSlack権限管理を継承したうえで、本番反映などの重要操作には人間の承認を挟む設計になっています。
情シスとしては、便利さの裏にある「権限継承の実態」「承認フローの明文化」「監査ログの保存・アクセス権」「複数エージェント併用時のシャドーAI化リスク」を導入前後で継続的にチェックすることが欠かせません。社内のSaaS・AI利用実態の可視化とあわせて、Slack Codeの活用ルールを早めに整備しておきましょう。
社内のSaaS・デバイス利用状況を一元的に可視化し、未承認ツールの利用実態を継続的に把握したい場合は、AdminaのシャドーIT検知機能やデバイス管理機能もあわせてご検討ください。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
