Slack Codeはエージェントワークフローを共有チャンネルに移行、ただしカスタムエージェントAPIの全面公開はまだ先

Salesforceは[Slack Code](https://www.salesforce.com/introducing-slack-code/)を発表し、従来は個人のターミナルやWebセッション内で動作していたコーディングエージェントを、チーム全体で共同監視・操作できる作業単位へと変えようとしている。ユーザーが既存の会話内で対応エージェントをメンションすると、Slackは単一のプロジェクトに紐づく「code channel」を作成する。このチャンネルでは、会話、エージェントの計画、コード差分、実行可能なHTMLプレビューがタブ形式で表示され、メンバーはエージェントを一時停止したり、方針を修正したり、終了したりできる。タスク完了後、チャンネルは自動的にアーカイブされるが、記録は検索および監査のために保持される。

初期の統合対象には、Anthropic Claude、Cognition Devin、GitHub Copilot、ChatGPT、Vercelのエージェントが含まれる。ここで重要なのは、単なる新しいチャット窓口の追加ではなく、エージェントの状態、成果物、人による承認を共有オブジェクトとして一元化する点だ。プロダクトマネージャーがバグ報告からタスクを開始し、エンジニアがdiffとプレビューを確認したうえで、最終的にPRの作成やデプロイを承認できる。Slackによると、code channel APIはアカウントの自動作成、ユーザー認証、ワークフローの調整に利用できるが、一般開発者向けAPIについては、現時点では将来の公開が予告されているにすぎない。

セキュリティ境界については、明確に区別して考える必要がある。Slackは、エージェントがワークスペースのID、権限、管理ポリシーを継承し、高リスクな操作には人による承認も必要になるとしている。しかし公式資料では、コードが実際にどのようなサンドボックスで実行されるのか、ネットワークの外向き通信がどう制限されるのか、シークレットがどう注入されるのか、リポジトリの認可がチャンネルメンバーにどう対応付けられるのかは説明されていない。各提携エージェントでは引き続き個別のアカウントとアクセス権が必要となるため、企業は導入評価にあたり、各プロバイダーのデータ保持、ブランチ保護、認証情報モデルを個別に検証すべきであり、Slackチャンネル自体を完全なセキュリティ境界と見なすべきではない。