Slack Codeはチーム公開か混乱か

Slack Codeは何が始まったのか

そーくん
Slack Codeって、チャットに作業用の人工知能を置く話ですよね。
ボス
昨日、Slackとベニオフ氏が発表した。人と機械が同じチャンネルでコードを書く。
そーくん
初日はクロードやデビンが対応なんですよね。もう実機の報告も出てますか。
ボス
実機の報告はまだ少ない。いま広がっているのは専用チャンネルと人間承認の整理だ。
そーくん
発表は昨日なのに、もう実務の人のメモまで日本語で広がってる感じですか。
ボス
何が起きたかを、時系列でおさらいしよう。拡散の起点もそこに書いてある。

何が起きたか

拡散の起点2026-08-20
Slackとベニオフ氏が発表
人間と作業用人工知能が同じチャンネルでコードを書く。クロード、デビン、GitHub Copilot、Vercelが初日対応。
2026-08-21
日本語メディアと実務メモが拡散
ITmediaが伝え、専用チャンネル・差分・見た目確認・人間承認という整理が広がった。

この発表の議論はどこで割れるか

そーくん
要するに、個人の画面で終わっていた作業を全員の会話に出すことが本体ですか。
ボス
主流の見方はそこだ。別の見方は、GitHubの課題管理と何が違うのかと問う。
そーくん
依頼が複数で矛盾したら、人工知能が作り壊すんじゃないかって話もありますよね。
ボス
人間の承認が前提だ、という見方もある。先に確認の手順を整えろ、という留保だ。
そーくん
ものづくりのどこまでをチームの競技にすべきか、って話にもなってますか。
ボス
ものづくりをどこまで共同作業にするか、という問いも含めて本文で見よう。

議論の現在地

主流派の視点: 個人の画面で完結していた作業を、全員が見える会話の場に出すのが本体
その他の視点: GitHubの課題管理と何が違うのか
複数の依頼が矛盾したら作り壊す
人間承認が前提なので、先に確認の手順を整える
ものづくりのどこまでをチーム競技にすべきか
目立つ論者: ITmedia
エンジニア転職・実務アカウント
権限設計を気にする開発者

3つの陣営はどう分かれるか

そーくん
歓迎が多いのか、壊れるぞという警戒の方が大きいのか、そこが気になります。
ボス
チーム公開派、混乱警戒派、権限設計派の3つに、実務層の声が割れている。
そーくん
権限設計派って、会話は共有していいけどファイルは別、みたいな話ですか。
ボス
近い。その立場がどれだけ厚いかは、本文の割合のレンジと一緒に見た方が早い。
そーくん
中立の厚みも含めて、どの声が多いかは本文の分布を見た方が早そうですね。
ボス
ポジ、中立、ネガの割合もそこに並んでいる。世論の分布を本文で確認しよう。

世論の分布

意見陣営別シェア(推定レンジ)

Xサンプル上の可視的な言論に占める割合 · 下限—上限

チーム公開派40–55%
混乱警戒派20–30%
権限設計派20–30%

推定下限推定上限

応援 / 中立 / 反対集計

陣営をスタンス別に統合 · camps中央値

45%

30%

25%

応援 40–55%(チーム公開派)中立 20–30%(権限設計派)反対 20–30%(混乱警戒派)

テーブルビュー(グラフと同じデータ)

陣営	スタンス	シェア	中心的主張
チーム公開派	ポジティブ	40–55%	依頼も途中も結果も、全員がいる場所に出す。引き継ぎのコストが下がる(@sakamoto_582、@yagiryuuu、@marreta27_jp)
混乱警戒派	ネガティブ	20–30%	複数の依頼が重複・矛盾したら壊す。GitHubで足りるのでは(@akira_x_kanou、@tama_program)
権限設計派	中立	20–30%	同じ会話の場はよくても、同じファイルまで共有するかは設計判断(@keitaro_aigc、@hiro_y)

いま噛み合っていない2つの論点

そーくん
得だという人と、場所を増やすだけだという人で、話がすれ違ってますよね。
ボス
進行中の論点は2つある。チャットに出す得失と、人間の承認で足りるかだ。
そーくん
A側とB側で、守ろうとしてるものが違う感じがします。そこが見どころですか。
ボス
噛み合っていない芯はそこにある。双方の言い分を、本文で並べて確認しよう。

進行中の論争

論点1

コード作業をチャットに出すのは得か

A側 · 得

非技術者も差分と見た目確認を見て承認できる。記録がチームの資産になる

B側 · 混乱

依頼の重複と矛盾で作り壊す。課題管理の場所を増やすだけ

根拠: @sakamoto_582の歓迎 vs @akira_x_kanouの重複懸念

論点2

人間承認があれば安全か

A側 · 安全

本番反映は人間必須。まず確認手順と枝運用を整えればよい

B側 · 不十分

複数の作業体が同じ領域を触ると妨害し合う研究がある

根拠: @yagiryuuuの整理 vs @keitaro_aigcの権限論

主なポスト

itmedia_news@itmedia_news·日本語報道Slack、AIとチームで協働する「Slack Code」を発表　ClaudeやDevinを専用チャネルで操作リンク日本語での入口。引用が実務メモを呼んだ。

SlackHQ@SlackHQ·公式発表Say hello to Slack Code in Slack. 👋 AI work isn’t a solo task anymore, it’s multiplayer. With code channels, you and your team can guide AI agents like @claudeai Code, Claude Tag, Devin from @cognition, @github Copilot, @ChatGPT, and @vercel agents together in real time.公式の起点。日本語解説がこれを引用する。

編集部まとめ

結局、公開は得なのか混乱なのか

そーくん
ここまでの話を踏まえると、得か混乱かで止まらず、設計の話まで割れてますね。
ボス
チーム公開派の言い分は、依頼も途中も結果も、全員がいる場所に出せ、だ。
そーくん
引き継ぎのコストが下がる、ってことですか。途中経過が見えるからですか。
ボス
そう。個人の画面で完結すると、次の人が同じ説明を最初から聞くことになる。
そーくん
非技術者でも、差分と見た目の確認を見て承認できる、という利点もあるんですか。
ボス
公開派はそこも言う。途中の記録が残るので、チームの資産になる、という言い分だ。
そーくん
混乱警戒派は、そこを得と見ないんですか。むしろ壊れる側に振る理由は何でしょう。
ボス
複数の依頼が重複したり矛盾したら、人工知能が作り壊す、というのが警戒の芯だ。
そーくん
GitHubで足りるのでは、というのも同じ陣営なんですか。場所を増やす無駄、ですか。
ボス
同じだ。課題管理の場所が増えるだけで、本体の仕事は前に進まない、という見方だ。
そーくん
権限設計派は、その2つの間に立つ感じですか。会話とファイルを分ける、と。
ボス
同じ会話の場はよくても、同じファイルまで共有するかは設計判断だ、と留保する。
そーくん
なんで公開と混乱が、同じ発表で同時に立つんですか。得なら警戒は薄まりませんか。
ボス
見える化は引き継ぎを楽にする。同時に、依頼の窓口が1つに集まるから衝突も増える。
そーくん
窓口が集まるほど、矛盾した指示が同じ人工知能に届きやすい、ということですか。
ボス
その通りだ。得になる理由も壊れる理由も、同じ『全員の場所に出す』から出ている。

人間承認だけでは足りない理由

そーくん
人間の承認があれば安全、という側は、本番反映だけ人を必須にすれば足りる、と。
ボス
まず確認の手順と、本番に入れる前の流れを整えればよい、が安全側の言い分だ。
そーくん
不十分だという側は、承認の前に人工知能同士が妨害し合う、と見ているんですか。
ボス
複数の人工知能が同じ領域を触ると妨害し合う、という研究を、不十分側は根拠にする。
そーくん
なんで承認の有無で、安全の話が終わらないんですか。最後に人が見れば足りそうですが。
ボス
承認は最後の確認だ。その前に、複数の作業が同じファイルを同時に書き換えることがある。
そーくん
確認を置けば足りる話と、置く前の衝突を防ぐ話が、混ざっているんですか。
ボス
ソフト開発では、依頼、変更、確認、本番反映で、残す場所が分かれているのが普通だ。
そーくん
じゃあ今回のこれは、その分かれた場所を、チャット1つに寄せる話なんですか。
ボス
だからGitHubと何が違うのか、がすぐ出る。記録の本体をどこに置くかの争いでもある。
そーくん
Slack側は会話の場に仕事を残したい。GitHub側はコードの履歴側に残したい、ですか。
ボス
利害の位置はそう読める。同じ見える化でも、どこで見せるかが製品の違いになる。

日本語の熱量が高くない意味

そーくん
注意点で気になったのは、日本語サンプルが実務層に偏っている、という話です。
ボス
一般のタイムラインの熱量は高くない。いま見えている声は、使う側の声に寄っている。
そーくん
使う人の会話だけが目立つと、全体が盛り上がっているように見えませんか。
ボス
ごく少数の声が、全体の空気に見えてしまうことがある。発信している層が厚いとは限らない。
そーくん
それ、まさに今回の日本語の実務メモが、全体の熱量に見えてしまう話ですね。
ボス
本番運用の事故例はまだない。混乱論は、起きうる形の予想であって、起きた話ではない。
そーくん
壊れるという警戒が先に立つのは、事故が無い今でも、衝突の形が見えているからですか。
ボス
そう。対立がある話題だけを拾っているので、静かな歓迎はここにはあまり出てこない。
そーくん
ChatGPT対応は近日で、初日の実機報告も少ない。体験談より設計の議論が先行してますね。
ボス
顔ぶれはクロード、デビン、GitHub Copilot、Vercelが初日対応だ。実機はこれから増える。

この読みがひっくり返る条件

そーくん
この読みが変わる条件も気になります。事故が1件出たら、警戒側が一気に厚くなりますか。
ボス
専用チャンネルでの誤反映や情報漏洩が報じられれば、公開の得より権限の話が前に出る。
そーくん
人間の承認を外す設定が既定だと分かった場合も、安全側の前提が崩れますよね。
ボス
崩れる。承認が必須、が安全側の土台なので、既定で外れると留保が警戒に寄る。
そーくん
GitHub側が同じ見える化を出したら、チャットに出す意味そのものが薄れますか。
ボス
差分が消える。残るのは、会話の場で書くか、コードの履歴側で書くかの好みだけだ。
そーくん
見える化の中身が同じなら、場所の違いは習慣の差になる、ということですね。
ボス
そーくんの下書きも、チームのチャンネルに全部出すか。途中の試行錯誤まで見えるぞ。
そーくん
まいりましたー。下書きくらいはまだ自分の画面の中で完結させておきますよ。

この記事をポスト