Deno Slackアプリを複数人で更新できるようにする
この記事で書くこと
Slack Platform、つまり Deno Slack SDK で作ったアプリを運用していると、複数人で同じデプロイ済みアプリを更新したくなることがあります。
複数人で更新するには、ソースコードだけでなく、Slack 側の collaborator 設定、Slack CLI のログイン状態、ローカルプロジェクトとデプロイ済みアプリの紐付けを確認します。
Deno Slack SDK のアプリは、初回デプロイしたユーザーだけに更新権限が固定されるわけではありません。
更新する人が対象 Workspace にログインでき、対象アプリの collaborator になっていて、ローカルプロジェクトがデプロイ済みアプリに紐付いていれば、同じアプリに対して slack deploy できます。
この記事では、2026年6月時点の Slack CLI / Deno Slack SDK の公式ドキュメントを前提に、複数人でデプロイ済みアプリを更新するときの確認項目を整理します。
前提
この記事では、次のような状況を想定します。
- Deno Slack SDK で作った Slack Platform アプリがある
- すでに対象 Workspace に
slack deploy済み - 複数人で同じデプロイ済みアプリを更新できるようにしたい
- ソースコードは Git などで共有している
Bolt で作ったアプリや、自前サーバーにデプロイしている Slack アプリではなく、Slack のインフラ上で動く Deno Slack SDK アプリを対象にします。
確認する条件は4つ
複数人で同じアプリを更新するときに確認する条件は4つです。
- 更新する人が対象 Workspace のメンバーか
- 更新する人が対象アプリの collaborator になっているか
- 更新する人の Slack CLI が対象 Workspace にログイン済みか
- 更新する人のローカルプロジェクトが対象のデプロイ済みアプリに紐付いているか
この4つがそろっていれば、初回デプロイ担当者と同じアプリに対して更新できます。
「ソースコードを持っている」だけでは足りません。
Slack 側の collaborator 設定と、手元の Slack CLI / プロジェクトの紐付けが必要です。
apps.json と apps.dev.json の違い
Deno Slack SDK のプロジェクトでは、.slack ディレクトリ配下にアプリ情報が保存されます。
ここで区別する必要があるのが、apps.json と apps.dev.json です。
apps.json
.slack/apps.json は、デプロイ済みアプリの情報を持つファイルです。
公式ドキュメントでは、slack deploy により .slack フォルダ内に apps.json が作成され、インストール先 Workspace、アプリ名、App ID、Team ID などの情報が含まれると説明されています。
また、複数人が同じ Workspace 上の同じデプロイ済みアプリを更新したい場合、apps.json の内容をそろえる必要があるため、バージョン管理に含めることが案内されています。
つまり、チームでデプロイ済みアプリを運用するなら、基本的に .slack/apps.json は共有対象です。
apps.dev.json
一方、.slack/apps.dev.json はローカル開発用です。
slack run で各開発者が手元のローカルアプリを動かすときの情報が入ります。これは人ごと、環境ごとに違うため、バージョン管理に含めません。
整理すると、次のようになります。
| ファイル | 用途 | Git管理 |
|---|---|---|
.slack/apps.json |
デプロイ済みアプリの共有情報 | 含める |
.slack/apps.dev.json |
各自のローカル開発用アプリ情報 | 含めない |
この違いを押さえると、デプロイ済みアプリの共有情報とローカル開発用の情報を分けて扱えます。
collaborator を追加する
更新する人を対象アプリの collaborator に追加します。
既存のデプロイ担当者、または対象アプリの collaborator が Slack CLI で実行します。
slack auth list
slack collaborator list --app deployed
slack collaborator add <email-or-user-id> --permission-type owner --app deployed
slack collaborator add は、メールアドレスまたは Slack ユーザーIDで collaborator を追加できます。
--permission-type には owner または reader を指定できます。公式リファレンス上のデフォルトは owner ですが、更新権限を持たせるなら、明示的に owner を指定しておくと意図が残ります。
追加後は、次のコマンドで確認します。
slack collaborator list --app deployed
ここで対象ユーザーが出てくれば、Slack アプリ側の collaborator 設定はできています。
不要になった collaborator を外す
不要になった collaborator は、slack collaborator remove で外せます。
slack collaborator remove <email-or-user-id> --app deployed
slack collaborator list --app deployed
公式ドキュメントでは、collaborator を削除したりアクセスを取り消したりしても、その人が OAuth token や app-level token を保持している可能性があるため、削除後は secrets や tokens のローテーションが推奨されています。
更新する人の Slack CLI をログインさせる
次に、更新する人の端末で Slack CLI が対象 Workspace にログインできているか確認します。
slack auth list
対象 Workspace が表示されない場合は、ログインします。
slack auth login
slack auth login では、ターミナルに表示された /slackauthticket ... を対象 Workspace の Slack に貼り付け、表示された challenge code をターミナルへ戻す流れになります。
ログイン後、もう一度確認します。
slack auth list
ここで対象 Workspace の Team ID が見えていれば、Slack CLI 側のログインはできています。
ローカルプロジェクトをデプロイ済みアプリに紐付ける
更新する人のローカルプロジェクトに .slack/apps.json があり、対象の App ID / Team ID が入っていれば、そのまま使えることがあります。
ただし、新しい端末や別ルートで取得したソースでは、アプリ情報が欠けていることがあります。その場合は slack app link で既存アプリをプロジェクトに紐付けます。
slack app link --team T0123456789 --app A0123456789 --environment deployed
--team には対象 Workspace の Team ID、--app には対象アプリの App ID を指定します。
公式リファレンスでは、slack app link は既存アプリをプロジェクトに追加し、指定した App ID と Team ID を .slack/apps.json または .slack/apps.dev.json に保存すると説明されています。
デプロイ済みアプリを共有して更新する場合は、--environment deployed を付けます。
共有して更新するデプロイ済みアプリを扱うなら deployed、ローカル開発用なら local です。既存のデプロイ済みアプリに紐付けたいなら、deployed にします。
deploy 前に確認する
ここまでできたら、追加した collaborator の端末でデプロイできます。
ただし、slack deploy する前に、次の点を確認します。
- 対象 Workspace の Team ID が合っているか
- 対象 App ID が合っているか
- collaborator に更新する人が入っているか
- ローカルのブランチが対象アプリへ反映したい内容になっているか
- テストや lint が通っているか
たとえば、次のような流れです。
git pull
slack auth list
slack collaborator list --app deployed
deno fmt --check
deno lint
deno check <entrypoint.ts>
deno task test
slack deploy
複数のアプリや環境を扱っている場合は、slack deploy のプロンプトで選ばれている App ID / Workspace を確認します。
この確認を省くと、違う Workspace や違うアプリを更新するリスクがあります。slack deploy の直前に、対象の App ID / Workspace を確認します。
複数人で deploy できることの注意点
collaborator を追加すると、複数人が同じデプロイ済みアプリへ slack deploy できるようになります。
この状態では、デプロイの上書きに注意が必要です。
公式ドキュメントでも、複数人が同じアプリへ deploy する場合、あとから実行した deploy が先の deploy を上書きする可能性があると説明されています。
つまり、権限としては複数人が deploy できても、運用としてはリリース担当を1人に決めたほうが安全です。
運用例としては、次のようにします。
- 対象アプリへの反映は main ブランチへのマージ後に行う
- deploy 担当をその都度1人に決める
- deploy 前に App ID / Team ID を確認する
- deploy 後に動作確認とログ確認をする
- いつ、誰が、どのコミットを deploy したかを残す
権限を渡すことと、リリース運用を緩めることは別です。
この2つは分けて扱います。
更新前チェックリスト
最後に、複数人で更新するときに確認する項目をまとめます。
- 更新する人は対象 Workspace のメンバーになっている
- 更新する人は対象アプリの collaborator になっている
- 更新する人には必要に応じて
owner権限を付けている - 更新する人の Slack CLI で
slack auth listに対象 Workspace が出る -
.slack/apps.jsonに対象 App ID / Team ID が入っている -
.slack/apps.dev.jsonは Git 管理していない - 必要に応じて
slack app link --environment deployedを実行している -
slack deploy前に App ID / Team ID を確認している - 複数人が同時に deploy しない運用にしている
- 不要な collaborator を外し、必要に応じて secrets / tokens を見直している
これらを確認すると、Deno Slack アプリを複数人で更新するときの抜け漏れを減らせます。
まとめ
Deno Slack SDK のデプロイ済みアプリを複数人で更新するには、次の4つをそろえます。
- 対象 Workspace のメンバーである
- 対象アプリの collaborator である
- Slack CLI が対象 Workspace にログインしている
- ローカルプロジェクトが対象 App ID / Team ID に紐付いている
そのうえで、.slack/apps.json は共有し、.slack/apps.dev.json は各自のローカル用として扱います。
あとは slack collaborator list、slack app link、slack deploy の前後で、対象の App ID / Team ID を確認すればよいです。
参考
使い倒せ、テクノロジー。(MAX OUT TECHNOLOGY)をミッションに掲げる、株式会社リバネスナレッジのチャレンジを共有するブログです。Buld in Publichの精神でオープンに綴ります。 Qiita:qiita.com/organizations/leaveanest
Discussion