🧵 Slack Codeは共有セッション面であって要件と承認の正本ではない

Slack は 2026-08-20 に Slack Code を発表しました。チームとコーディングエージェントが一時的な code channel で計画・差分・プレビューを共有する、新しいチャネル種別です。

この記事では、Slack Code を導入する側の判断材料を整理します。読み終えると次が分かります。

• Slack Code が出荷しているものと、出荷していないものの境界
• Slack の会話を GitHub の Issue / PR / ADR へ結ぶときに、自分で足す必要があるもの
• パートナー (Claude / Devin / GitHub Copilot / Vercel) ごとに分かれる権限とマージ責任
• 公式ドキュメント間で記述が食い違う箇所と、運用上どちらを正本にするか

結論を先に置きます。Slack Code はエージェント作業の「共有セッション面」として採用してよく、要件定義の正本・判断来歴のストア・マージゲートとしては採用しない、が現時点の妥当な線引きです。

この記事の全体像。以下、順に解説します。

Slack Code は何で、何ではないか

Slack Code はコーディングモデルでもエージェント runtime でもありません。サポート対象のエージェントをメンションすると立ち上がる、専用のチャネル種別と操作面です。

公式が挙げる問題意識は 2 つあります。

• 個人の IDE / ターミナルタブでエージェント作業が孤立すること
• 逆に通常スレッドへマルチターンの対話を詰め込み、チャンネルがノイズになること

code channel はこの中間に置かれます。作業ごとに部屋を切り、終わったら閉じる、という発想です。

一方で「何ではないか」がこの製品を評価する上では重要です。

出荷されているステータスは、処理中 / アイドル / 対応が必要 / 完了 / 非アクティブ / アーカイブ済み、という作業の進行状態です。意思決定の状態ではありません。

この差は、会話を要件の入力資料にしようとした瞬間に効いてきます。GitHub Copilot はスレッド全体を成果物の意思決定コンテキストとして取り込みますが、そのスレッドの中で何が採用され何が却下されたかの区別は、製品側では持ちません。

code channel のライフサイクルと生成物

起動から終了までの流れは次のとおりです。

• 起動: サポート対象エージェントをチャンネルまたは DM でメンションする。Slack Help はデスクトップの「エージェントとツール」タブからの手動作成も案内している
• 生成物タブ: コード diff、canvas、ライブ HTML ビュー、共有ファイル / リンク。開発者向け changelog は Block Kit ビューも列挙する
• 操作: 自然言語での指示、クイックアクション (PR 作成など)、停止ボタン、行コメント、バッチでのレビュー送信
• 寿命: 作業終了で閉じる / アーカイブする。非アクティブが 7 日続くとサイドバーから消える。アーカイブ後も検索・閲覧はできるが、新規メッセージは投稿できない
• 対象: メンバー全員、Slack の全プラン。サポート対象エージェントのインストールが必要で、ゲストは Agents 機能を使えない

構造としては、起動元スレッド・code channel・GitHub 側の正本、という 3 層に分かれます。

注意したいのは、確立後の操舵面が code channel 側へ移ることです。GitHub Docs は、セッション確立後は code channel だけで操舵する前提で書かれています。起動元スレッドの permalink だけを記録に残すと、その後の判断が追えなくなります。

会話と Issue / PR / ADR を結ぶには何を自分で足すか

「Slack の会話を要件の入力にしたい」という要望に対して、製品が公式に提供しているものと、提供していないものを整理します。

つまり、双方向の ID スキーマは公開されていません。結べるのは次の 3 経路だけです。

1. code channel に表示される repo / branch / Issue または PR の URL
2. Copilot changelog が書く「PR を開き、レビュー用に会話リンクを付ける」経路
3. 運用で残す Slack permalink (channel_id + thread_ts から生成)

識別子と作者 identity の対応関係は次のようになります。

実務で最低限そろえておく組は 4 つです。

1. Slack permalink (起動元スレッドと code channel の両方)
2. GitHub Issue / PR の URL
3. 作者が個人か Copilot app か Claude Tag か (PR の author を見て分岐する)
4. 最終 merge の承認者 (GitHub の review / ruleset ログ)

そして運用ルールとして重要なのが、スレッドをそのままプロンプトにしないことです。採用 / 却下 / 承認者を canvas か Issue 本文に構造化してからエージェントへ渡します。製品はこの構造化を自動ではやってくれません。

権限とレビュー責任はパートナーごとに分かれる

「Slack で呼んだ人の権限をエージェントが継承する」という単一の物語は成り立ちません。パートナーごとに identity と権限の設計が異なります。

ここからレビュー責任を再設計すると、次の切り分けになります。

• 非技術職の役割は、問題の自然言語化とプレビューへのコメントまでとする
• 変更のトリガーは repo の write 権限を持つ人に限る (Copilot の設計に合わせる)
• 出荷の承認は GitHub 側のゲートに置く。Slack の絵文字や「完了」ステータスを merge と読まない
• 未帰属 Copilot PR の追加承認をオフにしない
• Slack Connect / ゲスト中心の案件では、この面を共有プロセスの正本にしない

「Slack Code なら非技術職も開発に参加できる」という説明は、ゲストを含まない点で注意が必要です。外部パートナーや業務委託がゲストアカウントの組織では、期待した参加が起きません。

提供状況の食い違いと、運用上の正本

発表直後のため、公式資料の間でも記述が一致しない箇所があります。採用判断で踏まないよう、どれを正本とするかを決めておきます。

運用の正本は Slack Help のサポート対象リストに置くのが安全です。特に ChatGPT を day-one のワーカーとして手順書に書かないでください。ブログ本文だけを読むと使える前提になりますが、Help には掲載されていません。

API とレート制限の前提

自前のエージェントを載せたい場合、まず押さえるべき制約です。

• code channel を作成する Web API メソッドは未公開。現時点ではパートナー限定で、Help は将来 Slack プラットフォームの開発者へ開くと未来形で書いている
• セッション状態とストリーミングの API サンプル (Bolt / REST) はある
• 認証は Agents 機能で assistant:write、sessions は chat:write。Marketplace 経由のインストールが必要
• レート制限は Slack Code 専用のものは無く、既存の Web API の Tier に従う

超過時は ratelimited / rate_limited エラーと Retry-After ヘッダが返ります。あわせて、未クリアの processing は 1 時間で timeout し、Copilot の cloud agent 側には 59 分のハードリミットがあります。長時間ジョブを code channel のセッション状態だけで管理する設計は避けてください。

なお、公開 API が無いということは、自前の状態機械を公式のチャネル種別に載せられないことを意味します。カスタムエージェントを作るなら、API 公開を待つより、通常チャンネル + agents.sessions で足りるかを先に判断するほうが早く進みます。

採用判断: 何を試し、何を止めるか

ここまでを実行可能な形に落とします。

試すこと

1. Slack Code を「見える作業部屋」として試す。要件・ADR・merge の正本にはしない
2. 会話をエージェントへ渡す前に、採用 / 却下 / 承認者 / 対象 repo を Issue か canvas に固定する
3. 永続リンクの組 (Slack permalink + Issue/PR URL + author identity の種類) を運用ルールにする
4. GitHub 側で未帰属 Copilot PR の追加承認を維持する

止めること

1. チャンネル内の承認を merge と読むこと
2. ゲスト / Slack Connect 中心の案件で、この面を共有プロセスの正本にすること
3. ChatGPT を起動パートナーとして手順書に書くこと
4. フルスレッドをそのままエージェントのコンテキストにすること

この判断を見直す条件は明確です。Help が構造化フィールド (採用 / 却下 / 承認者) と、公開の双方向 ID スキーマを出荷したときです。そのとき初めて「会話が要件の入力資料である」という設計を製品側へ寄せられます。

未解決のまま残っている点も挙げておきます。いずれも採用判断そのものは止めません。

• ChatGPT がいつ Help のサポート対象に入るか
• Agents タブから作成したチャンネルに、エージェントセッションが必ず付くか
• PR に付く conversation link の URL 形式 (permalink か code channel URL か)
• ゲストがエージェント UI 無しで diff を閲覧できるか (現時点では不可と仮定するのが安全)
• 本番障害・顧客離脱の有無 (発表から数日で、観測期間が足りない)

セキュリティ面では、Slack Code に固有の CVE は 2026-08-24 時点で NVD に登録されていません。隣接する CVE-2025-34072 は deprecated な Slack MCP に対するもので、Slack Code に帰属させるべきではありません。

まとめ

• Slack Code は、チームとコーディングエージェントが計画・差分・プレビューを共有する専用チャネル種別であり、モデルでも runtime でもない
• 出荷されているのは作業の進行ステータスだけで、採用 / 却下 / 承認者という意思決定の状態モデルは無い
• Slack 会話と GitHub Issue / PR を結ぶ双方向の公開スキーマは無い。permalink + Issue/PR URL + author identity の組を運用で残す
• 権限モデルはパートナーごとに分裂する。出荷の承認は GitHub 側のゲートに置き、チャンネル内の sign-off と混同しない
• 提供状況の記述は公式間で食い違う。Slack Help を運用の正本とし、ChatGPT を前提にした手順書を書かない
• code channel の作成 API は未公開。カスタムエージェントは通常チャンネル + agents.sessions で足りるかを先に検討する

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

一次資料:

• Announcing Slack Code (docs.slack.dev changelog)
• Slack コードを使ってチームとして AI で構築する (Slack Help)
• Slack Code: Where Your Team and Agents Build Together (Slack Blog)
• Slack Code 機能ページ
• Introducing Slack Code (Salesforce)
• Developing an agent (Slack)
• Web API rate limits (Slack)
• Integrating Copilot cloud agent with Slack (GitHub Docs)
• The new GitHub Copilot experience in Slack (GitHub Changelog)
• CVE-2025-34072 (NVD)

二次資料 (報道・インタビュー):

• The New Stack: Slack Code agent channels
• VentureBeat: Slack wants to drag AI coding into the group chat
• Computerworld: New Slack Code turns AI coding into a team activity
• Shared agentic work with GitHub Copilot in Microsoft Teams (GitHub Changelog)