最終更新2026年8月21日 21:17

Slack Codeは協働かノイズか

Slackは、ClaudeやDevinなどの作業用人工知能を専用チャンネルで動かすSlack Codeを発表した。いつもの仕事場に出せるのが強いという歓迎と、過程の実況はノイズで本拠はギットハブだという拒否、権限と人間承認が先という留保が技術者層で割れている。

拡散の起点2026-08-21 午後

不要論が技術者から出る

過程は要らず成果物だけ見たい、コードの本拠はギットハブだ、という反論が独立した。

期間直近10時間の続報

信頼度(公式発表は前日。窓内は不要論と初動レビュー)

応援35%
中立25%
反対40%

Slack Code午後に何が起きたか

  1. そーくん

    Slack Codeの話題、第2回ですね。昼の発表から空気が動いてますか。

  2. ボス

    経緯は昼の発表で、仕事場に出せる歓迎と壊れる警戒、権限が先という留保が割れてたよね。

  3. そーくん

    第1回は歓迎がまだ多めだった印象です。午後になって何か増えたんですか。

  4. ボス

    不要論が技術者から独立して広がった。過程は要らず成果物だけ、という反論だ。

  5. そーくん

    発表の解説と不要論が同時に走るんですね。時系列で整理した方がいいですか。

  6. ボス

    じゃあ何が起きたか、おさらいしよう。拡散の起点つきで時系列を見てみよう。

何が起きたか

  1. 2026-08-21 昼

    Slack Code発表の日本語解説

    専用チャンネルと人間承認、各社エージェントは別契約、という整理が日本語で広がった。

  2. 拡散の起点2026-08-21 午後

    不要論が技術者から出る

    過程は要らず成果物だけ見たい、コードの本拠はギットハブだ、という反論が独立した。

歓迎と不要論のどちらが軸か

  1. そーくん

    歓迎の声は残ってるんですか。それとも不要論がもう主流になってる感じですか。

  2. ボス

    主流は個人の別タブからチームのチャンネルへ移す、という説明が歓迎の軸だ。

  3. そーくん

    別タブからチームの場へ、ですか。拒否する人はどこが気に食わないんですか。

  4. ボス

    拒否は一枚岩じゃない。過程がうるさい、本拠が違う、もうある、と理由が分かれる。

  5. そーくん

    拒否の理由が複数あるんですね。歓迎の軸と並べて見ないと、偏りそうです。

  6. ボス

    じゃあ議論の現在地を見てみよう。いまの主流と、それ以外の見方を並べてある。

議論の現在地

主流派の視点
個人の別タブからチームのチャンネルへ移す、という説明が歓迎の軸
その他の視点
  • 過程の実況はすぐノイズになる
  • エンジニアの本拠はギットハブ
  • 既存の常駐機能と重複する
  • モブ作業や記録には向く
目立つ論者
  • 不要と書く実務者
  • 初動で触ったエンジニア
  • 機能解説の情報アカウント
  • GitHub本拠を守る層

陣営の厚みはどこに寄ったか

  1. そーくん

    見方が3つあるなら、人数の偏りも気になります。どの派がいちばん厚いんですか。

  2. ボス

    第1回は歓迎がまだ厚かった。今回は不要派が前に出て、厚みが逆転気味だ。

  3. そーくん

    歓迎より不要の方が厚いんですか。中間の承認先行はどこに残ってるんですか。

  4. ボス

    承認先行という中間も残ってる。厚い薄いと、賛成か反対かは別の切り口だ。

  5. そーくん

    厚い薄いと、賛否の割合は別なんですか。分布を数字で見た方が早そうですね。

  6. ボス

    じゃあ世論の分布を見てみよう。陣営のシェアと、賛否の割合が並んでいる。

世論の分布

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

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

  • 不要・ノイズ派30–40%
  • 見える化歓迎25–35%
  • 承認先行20–30%
推定下限推定上限

応援 / 中立 / 反対 集計

陣営をスタンス別に統合 · 歓迎を35に寄せ合計100

35%
25%
40%
応援 25–35%(見える化歓迎)中立 20–30%(承認先行)反対 30–40%(不要・ノイズ派)
テーブルビュー(グラフと同じデータ)
陣営スタンスシェア中心的主張
不要・ノイズ派ネガティブ30–40%過程を全部流すより成果物だけ共有したい。本拠はギットハブで、Slackは足りない(@yutkat@osamu1203@ai28hide)
見える化歓迎ポジティブ25–35%指示も途中も承認もチームの記録に残る。個人の画面に閉じないのが前進だ(@masahirochaen@ryu_f_web)
承認先行中立20–30%本番反映に人の承認が要る設計は良いが、権限と契約が先で、流行るかは別だ(@osamu1203)

過程公開と本拠は噛み合うか

  1. そーくん

    不要が厚いなら、もう結論は出た感じですか。まだ争点は残ってるんですか。

  2. ボス

    結論は出てない。過程を出すのが得か、コードの本拠はどこか、が残ってる。

  3. そーくん

    過程を出すのが得、ですか。成果物だけ見たい側とは、何が噛み合わないんですか。

  4. ボス

    残るかノイズかの話で、チームにとっての得の定義が最初からすれ違ってる。

  5. そーくん

    本拠の話も同じ感じですか。片方の言い分だけ聞くと、また偏って見えそうです。

  6. ボス

    じゃあ進行中の論争を見てみよう。噛み合っていない論点を両側で並べてある。

進行中の論争

論点1

過程の公開はチームの得か

A側 ·

指示と途中経過が残れば、誤処理の相互確認と記録になる。

B側 · ノイズ

過程の実況はすぐノイズで、成果物と人が判断した点だけ共有すれば足りる。

根拠: 見える化の解説と、よしだ氏の過程不要

論点2

コードの本拠はギットハブか

A側 · ギットハブ

品質管理の場所はギットハブで、Slackに置き換えるほど機能は無い。

B側 · Slack

いつもの会話の場に出せるのが導入の壁を下げる。

根拠: 西山氏の本拠論と、実地でモブ作業向きとした記事

主なポスト

yutkat@yutkat·不要論Slack Code絶賛している人多いけど、いらなくね…? AgentをSlackに常駐させたいならClaudeやChatGPTにもうその機能あるし、コード書きたいだけならローカルの方が速いし、いろいろ連携してて便利だぞ チームで使うにしろ個々のやってる過程なんていらなくてアウトプットで検討したい絶賛の隣で、過程は不要だと切った
osamu1203@osamu1203·本拠論Slack Codeは、Slack上でコーディング修正をAgentと実行して、コード差分などを確認できる機能拡張とのこと。 触ったわけではないですが、たぶん、、、流行らないでしょう😅 非エンジニアが開発に参加したい要望として、LP修正とかならアリかもですが。 エンジニアが基本的にコード品質について管理、コミュニケーションする場所はGithubです。それを置き換えるほど、Slackには機能は足りていない。 私たち開発者がどこに情報を残すかはとても重要ことなので、Githubと併用してSlack Codeでやり取りするのは好まないのではと想像しています。品質管理の本拠はギットハブだと拒否した

編集部まとめ

不要論が厚くなった意味は何か

  1. そーくん

    ここまでの話を踏まえると、第1回より空気が厳しいですね。何が変わったんですか。

  2. ボス

    第1回は歓迎が40から55だった。今回は不要派が30から40で、厚みが前に出た。

  3. そーくん

    歓迎が減ったというより、午後に不要論が独立して広がったのが大きいんですか。

  4. ボス

    独立したのは解説への反論だ。ただ実地で触った投稿は、まだほとんど乗っていない。

  5. そーくん

    触ってない人が不要と言うなら、流行らない予測は想像の比重が大きいですか。

  6. ボス

    未使用の想像も混ざる。少数の不要論が、全体の空気に見えてしまうことがある。

  7. そーくん

    それ、まさに今回の不要論ですね。実地が少ないのに空気だけ先に決まる感じです。

3つの言い分はどこが違うか

  1. ボス

    不要派の言い分は単純だ。過程を全部流すより、成果物だけ共有したい、と。

  2. そーくん

    本拠はギットハブで足りる、というのも同じ陣営なんですか。Slackが足りない、と。

  3. ボス

    そう。品質管理の場所はギットハブで、Slackに置き換えるほど機能は無い、と。

  4. そーくん

    じゃあ歓迎側は、何を得だと見てるんですか。指示も途中も残るのが前進、ですか。

  5. ボス

    指示も途中も承認もチームの記録に残る。個人の画面に閉じないのが前進だ、と。

  6. そーくん

    承認先行はどちらにもつかないんですか。良い設計だと言いつつ、流行りは別、と。

  7. ボス

    本番反映に人の承認が要る設計は良い。ただ権限と契約が先で、流行るかは別だ。

過程を出す得がすれ違う理由

  1. そーくん

    なんで過程を出す側と、出さない側で、得の意味がそんなに割れるんですか。

  2. ボス

    出す側は誤処理の相互確認と記録を守る。出さない側は注意力の方を守ってる。

  3. そーくん

    同じチームの得なのに、守るものが違うから対立に見える、ということですか。

  4. ボス

    そう。記録が増えるほど後から追えるが、今のチャンネルはすぐ埋まってしまう。

  5. そーくん

    モブ作業や記録向き、という声は、埋まる前提を先に受け入れてる人なんですか。

  6. ボス

    向き不向きの話だ。常時実況を全員に流す運用と、作業部屋に閉じる運用は別だ。

コードの本拠を置く場所の力学

  1. そーくん

    なんで本拠の話になると、ギットハブかSlackかで、また別の対立になるんですか。

  2. ボス

    品質を見る場所と、相談する場所は、もともと別の道具として分かれてきたからだ。

  3. そーくん

    じゃあ今回のこれは、相談の場に品質管理まで持ち込もうとしてる、ですか。

  4. ボス

    Slack側はいつもの会話の場に出せるのが、導入の壁を下げると考えてる。

  5. そーくん

    導入しやすいことと、品質管理に足りることは、別の評価なんですね、それ。

  6. ボス

    各社のエージェントは別契約だ。機能が無料でも、本体の利用料は別問題になる。

  7. そーくん

    じゃあ今回の無料に見える部分は、箱だけで中身の契約は別、ということですか。

  8. ボス

    既存の常駐機能と見た目が似るのも大きい。新しい箱に見えないと、重複に見える。

  9. そーくん

    新しい発表なのに、もうある機能の延長に見えると、不要論が出やすいんですか。

  10. ボス

    出やすい。仕事場の道具は、増えること自体がコストだと見られがちなんだ。

この読みがいつひっくり返るか

  1. そーくん

    この読みはどこまで持っていけるんですか。公式発表はまだ新しいですよね。

  2. ボス

    公式発表は前日だ。直近10時間の日本語は、解説と不要論が中心のサンプルだ。

  3. そーくん

    対立がある話題だけ拾ってる、という注意も、今回は効いてくる感じですか。

  4. ボス

    効いてくる。Xで拡散した全体ではなく、割れている声を厚く見ている読みだ。

  5. そーくん

    じゃあ不要論が弱まる条件は何ですか。現場で使い始めたら、空気は変わるんですか。

  6. ボス

    現場で差分レビューがSlackに残る運用が広がれば、不要論の方は弱まる。

  7. そーくん

    逆に、承認先行が拒否に変わる条件もあるんですか。何が起きると折れるんですか。

  8. ボス

    重大な権限事故が1度出れば、人の承認がある設計でも、拒否の側へ転じうる。

  9. そーくん

    承認があるから安心、とは限らず、事故が権限の話を先に連れてくる、ですか。

  10. ボス

    その通り。流行りの前に、誰がどこまで触れるかを決めていないと、事故が定義になる。

  11. そーくん

    結局いまは、箱の話と中身の契約と、権限の話が、同じ土俵に乗ってるんですか。

  12. ボス

    乗ってる。見える化の得と、ノイズの損と、権限の不安が、1つの発表に重なってる。

  13. そーくん

    読み終えたいまは、歓迎か不要かより、どの損を先に見ているかの差ですね。

  14. ボス

    そーくんの作業ログ、全部チャンネルに流したら、編集部は何分でミュートするかな。

  15. そーくん

    実況は自分じゃ見たくない、って今のは口が滑りましたね。まいりましたー。

FOLLOW & TALK

この話題を追う、話す