こんにちは、Slack の公式 SDK 開発と日本の Developer Relations を担当している瀬良 (@seratch) と申します 
今週、Slack プラットフォームチームより以下のアナウンスメントが出ました。
要点をまとめると以下の三点となります。
- 2024 年 6 月 4 日以降、"classic app" と呼ばれる RTM API や旧式の bot scope を持つアプリは新規で作成できなくなります
- これまでに作成されたアプリは引き続き動作しますが、RTM から イベント API への早めの移行をおすすめします
- Hubot やその他の RTM を使ったアプリは、ソケットモード + イベント API を有効にした Bolt アプリへの移行をおすすめします
以下でもう少し補足します。
"classic app" の新規作成が停止されます
これまで数年間、どうしても作成する必要があるユーザーのためだけに用意されたアクセス方法が現行の仕組みへのマイグレーションガイドのところにあるだけでしたので、最近新しく作ったことがある人はほとんどいないと思いますが、10 年近く前から提供されてきた初期の Slack アプリ設定を新しく作成することがついにできなくなります。
これ自体が影響する方はほとんどいないと思います・・・が、どうしてももうしばらくは RTM アプリを運用する必要があるという場合は、5 月中にテスト用アプリを作成して組織の中で共有しておく方がよいと思います。
紛らわしいのですが、Bolt アプリを作る仕組みが非推奨になったわけではありません！ それよりも遥か昔に作られた初期の仕組みが非推奨となっただけです。
既存アプリは直ちに停止するわけではありません
"classic app" の新規作成が完全に停止されるだけで、現在動いている RTM などのアプリが動作しなくなるわけではありません。
ただ、いよいよ完全に非推奨という段階にはなりますので、今後も長期で運用を継続したいアプリについては、
- イベント API + ソケットモードの Slack アプリ
- 新しいオートメーションプラットフォーム
のいずれかへの移行をおすすめします。これらの移行先については以下の記事を参考にされてください。
Hubot / RTM API からの現実的な移行先
最新の機能であるオートメーションプラットフォームは、オートメーションのためのワークフローを作成することに最も適した機能です。
そのため、プラットフォームがチャットボット向けの機能しか持たなかった頃につくられた RTM API アプリや Hubot については、そのままの機能を有したままで移行するには必ずしも最善の手段とは言えないかもしれません。また、オートメーションプラットフォームでは、カスタムコードで機能を実装した場合はワークフロー実行回数に基づく従量課金となる点もユースケースに合わないことが多々あるかと思います。
多くの場合、ソケットモードとイベント API を有効にしたアプリを Bolt for JavaScript で再実装することが最も現実的であると思います。
新しく Bolt アプリを開発するにあたっては、ぜひ先日リリースされたサンドボックス環境を Slack CLI とともに利用してみてください。
Hubot については Bolt for JS のドキュメントに移行ガイド（日本語）がありますので、こちらも参考にされてください。
終わりに
私たち Slack のプラットフォーム開発チームでは、長年動き続けているボットをリプレイスするタスクのプライオリティを上げることは容易でないことを理解しており、過去数年間、古い機能を非推奨とはしつつも、動作する状態を継続してきました。しかし、ついにこれらの機能を完全に非推奨とせざるをえない時期が来ました。
お手数をおかけいたしますが、何卒よろしくお願いいたします 