Slack Code登場｜チャットの中で、人とAIが一緒に開発する時代へ

2026年8月20日、Slackが新機能「**Slack Code**」を発表した。 チャットの中で、人とAIが一緒にものを作る機能である。 発表の中で目を引く数字がある。 Slack社内の実績として、この機能で立つプロジェクト用のチャンネルの7割超が、アイデアが出てから成果物の反映まで1日以内に終わっているという。 7割が、その日のうちに片づく。 これだけを聞くと、開発が速くなる画期的なツールの話に聞こえるかもしれない。 しかし、この発表の核心はそこにはない。 よく読むと、これはエージェントの受け入れ手続きの話である。

誰も中身を知らない道具が増える副作用

「**バイブコーディング**」という言葉がある。 2025年にAndrej Karpathyが提唱した、コードの存在を忘れて動けばよしとする開発手法である。 AIに頼めば、コードを読めなくても雰囲気でシステムを作れてしまう。 Slack Codeは、その速さをさらに加速させるものだろうか。 実は、逆である。 バイブコーディングは、何をどれだけ速く作れるかという出力の話だ。 対してSlack Codeは、それがどこで作られたかという場所の話である。

現場が勝手に作ったExcelマクロを想像してほしい。 動くし、業務にもよく効く。 作った本人は英雄である。 しかし、その人が異動した瞬間、誰も直せなくなる。 中身を知らないため、壊れても壊れたことに気づかない。 作れる人が増えるほど、誰も中身を知らない道具が増えていく。 AIを使えば、それが桁違いの速さで増殖する。 Slackが用意したのは、もっと速く作れるようにする機能ではなく、作ったものが見える場所に置かれる仕組みだった。

差分とプレビューが承認の形を変える

Slack Codeでは、エージェントにメンションを飛ばすと、そのタスク専用のチャンネルが立つ。 これが「コードチャネル」である。 1チャンネルにつき1プロジェクトであり、終わればアーカイブされて監査ログとして残る。 チャンネルの中には、会話、計画、コードの差分、動くプレビューの4つのタブがある。

差分は、前の行に取り消し線が引かれ、新しい行が横に並ぶ。 AIが勝手にやっておきました、ではなく、1行単位で全員が同じ画面を見る。 さらに、プレビュータブでは実際の画面がその場で動く。 壊れていないかを、世に出す前に全員が触って確かめられる。 これなら、エンジニアでなくても判断できる。

本番環境に出すような重要な操作では、エージェントが作業をひとまとめにし、詳しい人にチャンネルの中で承認してもらう。 共有フォルダに置いて、承認印を押させる。 AIで作れることが当たり前になった次に困るのは、必ず作ったものの管理である。 Slackはそこに先回りしている。

情シスに頼むほどではない毎月30分の作業

コードと言われた瞬間に、自社には関係ないと感じるかもしれない。 しかし、Slack自身が「ソフトウェア開発は、ほんの始まりに過ぎない」と述べている。 近くAPIが開放され、どんなエージェントでも参加できるようになる。 例として挙がっているのは、マーケティングのキャンペーン制作と、法務の文書レビューである。 完全にバックオフィスの実務の話だ。

ここで効くのは、システム部門に依頼書を出すほどではないが、毎月30分取られているような作業である。 毎月の請求書をフォルダから拾って一覧表にまとめる小道具。 勤怠の打刻漏れと、残業が基準を超えそうな人を洗い出すチェック。 経費精算の申請前チェックリストを、入力できる画面として作る。 これまでは自分で作れないため、手作業でやり続けていた滞留分である。

この手の小道具は、作ってもらったあとに「思っていたのと違う」と揉めやすい。 そこにプレビュータブが効く。 現場の担当者が、動くものを見ながら「この項目はいらない」と指摘できる。 要件定義の文書で往復するのではなく、動いている画面を指差して直す。 違和感を早い段階で伝えられることが、実務への定着を左右する。

エージェント台帳という新しい実務

今回の発表では、Slack全体でエージェントの扱いそのものも変わっている。 エージェントとのダイレクトメッセージに「これはエージェントです」というラベルが付き、スレッドに名前が付く。 新しくエージェントタブができ、誰が動いていて誰が止まっているかを確認できる。 さらに、外部で作ったエージェントを数クリックで自社に入れられるようになった。

エージェントはSlackの権限設定や管理者の統制を初日から引き継ぐ。 IT部門の追加作業はいらない。 ラベルは身分証であり、エージェントタブは勤怠管理である。 終わったチャンネルが監査ログとして残るのは業務記録の保存であり、本番への反映を人が承認するのは決裁権限規程だ。 これらは、派遣スタッフや業務委託を受け入れる際の手続きとまったく同じである。

エージェントは労働者ではない。 労務管理の話ではないが、管理項目の形は驚くほど一致している。 形が同じなら、実務も同じになる。 ソフトウェアの契約台帳を作ってきたのと同じ理屈で、次はエージェント台帳が必要になる。 どのエージェントが、誰の依頼で、どの権限で、いつから動いているか。 Slackのマーケットプレイスにはすでに500以上のAIアプリが並び、数クリックで導入できる。 入れるのは簡単だが、自社に何体いるかを把握している会社はほとんどない。 これは、シャドーITの次の波である。

人とAIが同じ場所で働く時代の価値

Microsoftも6月のイベントで、Teamsにエージェントを乗せる仕組みを発表している。 業務チャットが、AIエージェントの作業場になる。 人が入る場所と、エージェントが入る場所が同じになった。 近いうちに、業務を外注する際「人を出しますか、エージェントを出しますか」という選択になるだろう。

そこで値づけが割れる。 人は時間で契約できるが、エージェントは寝ずに働き、7割の作業を1日で終わらせる。 時間を売っている限り、速く終わるほど売上が減るため、成果で値づけするしかなくなる。

では、そこで人がいなくなるのだろうか。 そうではない。 速さのために目を離してはいけないと、発表文にも記されている。 本番に出す前には、詳しい人が承認する。 作業する人が減り、承認する人が残る。 頼み方がわからない人の手元では、エージェントは何体いても動かない。 最後に「これでいい」と判断する人の価値が、これまで以上に高まっていく。

まとめ

• 開発の速さではなく「場所」の提供：Slack Codeは、バイブコーディングによる「誰も中身を知らない道具」の増殖を防ぎ、差分・プレビュー・承認・監査ログという統制の仕組みを提供する。
• バックオフィスでの活用と修正の容易さ：情シスに頼むほどではない毎月30分の作業を自動化する小道具作りに効く。動くプレビューを見ながら直せるため、現場の意図とずれない。
• エージェント台帳の必要性：エージェントに身分証、勤怠、権限、記録、決裁が与えられた。派遣スタッフの受け入れと同じ管理項目が求められ、自社で稼働するエージェントを把握する実務が急務となる。