Code APIの中核となるのは、エージェントのタスク向けに設計された専用のチャンネル種別です。エージェントは会話からコードチャンネルを作成し、適切なメンバーやファイルを追加して、コードの差分やプレビューを投稿し、重要な成果物をブックマークできます。また、段階的な計画や進捗状況を実行に合わせて共有できます。タスクが完了したらチャンネルをアーカイブでき、ワークスペース既存のアクセス管理、コンプライアンス、検索機能もそのまま適用されます。これは連携のための基盤です。Slackが基本機能を提供することで、エージェントがコラボレーション、承認、レビューの画面を一から作り直す必要がなくなります。

開発者の視点では、エージェントのマニフェストにSlack Codeを追加することが主な作業です。マニフェストでは、チャンネル名、メンバー選定の条件、コマンド、ビューを設定します。タスク用の作業スペースが必要だとエージェントが判断すると、チャンネルを作成し、関係するチームメンバーや関係者を自動招待して、初期計画と必要な成果物を投稿します。実行中は差分、テスト結果、チェックポイントを共有し、チームメンバーはコメントや方針の変更、承認を行えます。実装時には、「開始」「更新」「承認依頼」「アーカイブ」といった明確なライフサイクル通知を設計し、人が確認できる頻度に更新の細かさを調整するのがおすすめです。そうすることで、チャンネルを有用な状態に保てます。

Code APIが明確に選択しているのは、秘匿性よりも可視性です。エージェントにはチャンネルの権限とメッセージのコンプライアンスルールが適用されるため、新たなアクセス管理の仕組みを作らなくても、セキュリティチームが明確な監査経路を確保できます。規制の厳しい企業や、変更の経緯を追跡する必要がある企業にとって重要な点です。一方で、可視性が高まれば、ポリシー上の検討事項も増えます。どのエージェント出力を初期設定で公開するのか、一時的な下書きを非公開にすべきなのはどのような場合か、機密性の高い成果物が広いチャンネルに漏れるのをどう防ぐのか。各チームは、自社のリスク許容度に合ったポリシーやフィルターをAPIと併せて整備する必要があります。

Slackのローンチパートナーは、さまざまな活用例を示しています。Copilotはチームメンバーとの連携が必要なタスクでコードチャンネルを使用し、オブザーバビリティエージェントはインシデント発生時にチャンネルを開いてログを添付できます。デプロイツールはチャンネル内でプルリクエストの承認を依頼できます。こうした活用例から、Code APIが小規模な修正だけでなく、トリアージからマージまでの一連のタスクに対応していることが分かります。ベンダーにとっては、APIを通じてマーケットプレイスのエージェントにSlack内で一貫したUXを提供でき、見つけやすさが高まるとともに、BYOA（独自エージェントの持ち込み）を望む顧客の導入障壁を下げられます。

エージェントの作業を公開すればメリットがある一方、運用上の負担も生じます。エージェントが中間報告を頻繁に投稿すると、通知疲れにつながるおそれがあります。ガバナンス担当チームは、データ流出を防ぎ、最小権限の原則を徹底しなければなりません。高度なカスタムUIや複雑な状態管理が必要な連携では、引き続き外部ツールが必要な場合もあります。また、人間による承認プロセスは、ボトルネックや形だけの承認にならないよう、慎重に設計する必要があります。初期導入チームは、広範なエージェント権限を有効にする前に、小規模な試験導入を行い、通知のしきい値を調整し、明確な承認ルールを整備しましょう。