Slackオートメーションプラットフォーム(次世代プラットフォーム)でSlackアプリを作ってみた
こんにちは。情報システム部の萩原です。
皆さんはSlackオートメーションプラットフォーム(少し前までは次世代プラットフォームとも呼ばれていました)をご存じでしょうか。
2023年4月に正式リリースされ、端的に言うと、これまでSlackアプリを開発する際は、アプリやデータなどをホスティングする環境として別途AWSなどのクラウド環境を用意する必要があったものが、Slack社が管理するインフラにデプロイしてホスティングできるようになったものです。
グリー情報システム部ではリリース当初からオートメーションプラットフォームの検証を重ねており、この度、このプラットフォームを使った社内向けのSlackアプリを開発いたしましたので、開発したアプリの紹介と、そこで得た気付きなどについて解説していきたいと思います。
はじめに - Slackオートメーションプラットフォームについて
冒頭でも軽く触れましたが、Slackオートメーションプラットフォームとは、Slack社が提供する、よりセキュアで簡単なアプリ開発体験が可能なアプリ開発・実行基盤のことです。
https://api.slack.com/lang/ja-jp/automation/announcement
長きに渡るベータ期間を終え、2023年4月に正式リリースされました。
オートメーションプラットフォームと従来のBolt によるアプリ開発の比較
オートメーションプラットフォームと従来のBolt によるアプリ開発の違いとしては、以下になります。
従来 | オートメーションプラットフォーム | |
対応言語 (SDKが提供されている言語) | JavaScript (Node.js), Python, Java | TypeScript(Deno) |
インフラ (ホスティング環境) | AWS,GCP,Azureなど任意のクラウドベンダーで自前で用意 | Slack |
アプリの設定管理 | アプリの構成設定などは基本的にGUIから行う。 | アプリの構成設定含め、全ての設定はコードで管理され、Slack CLIと呼ばれるCLIから反映などを行う。 GUIからの変更は不可。 |
コスト | ホスティング環境として選定したクラウドベンダーの製品毎の維持コスト | 開発したアプリの実行回数による課金(≠時間)。 ワークスペースごと一定回数の無料分が含まれており、無料分を超過した場合にのみコストが発生。 |
オートメーションプラットフォームで開発するメリット
オートメーションプラットフォームでアプリ開発するメリットとしては以下が挙げられます。
- インフラの用意が不要
従来であればアプリのコードを動かす環境として、AWSやGCP、AzureなどのIaaS or PaaSを使って自前で用意するのが一般的でしたが、オートメーションプラットフォームを使えばSlack上に構築されたSlackアプリ専用のセキュアな環境にそのままアプリをデプロイできるため、インフラ準備の作業が不要になります。 - CLIで完結する開発体験
オートメーションプラットフォームでの開発はすべてSlack CLIというコマンドラインインターフェースで行います。エンジニアの方にとってはCLIで完結できることは大きなメリットと言えるでしょう。また、CI/CDといったモダンな開発パイプラインにも取り込みやすいかと思います。 - 再利用可能なモジュラーアーキテクチャ
オートメーションプラットフォームで開発したアプリは機能単位で他のアプリ、もしくはワークフロービルダーのステップとして再利用することが可能です。
オートメーションプラットフォームの注意点
メリットがある一方で、注意点もいくつかあります。
- 有料プランの Slack ワークスペースでのみ利用可能
オートメーションプラットフォームを使うには、有料プラン(プロ以上)の Slack ワークスペースである必要があります。フリープランのワークスペースでは使えないので注意が必要です。 - アプリの設定管理はSlack CLIからしか行えない。
従来だとアプリ管理画面から自分で作成したアプリの構成を変更できますが、Slack CLIで作成されたアプリはGUIから編集することができません。
CLIでの操作に慣れていない人には少々ハードルが高いといえるでしょう。 - 開発したアプリはAppディレクトリに掲載できない
現在のところオートメーションプラットフォームで開発したSlackアプリはAppディレクトリに掲載することができません。 - 従来と比べてできないことがいくつかある
従来のBoltを使った開発に比べて、いくつかできないことがあります。この点については後ほど詳しく紹介します。
開発したアプリについて
ここからは開発したアプリについて紹介させていただきます。
開発したアプリは元々導入していた来客受付システムの来客予約をSlackから行えるようにするものです。アーキテクチャとしては以下になります。
こだわりポイント
アプリの開発にあたってこだわったポイントがいくつかありますので、紹介させていただきます。
- 動的に変化する入力フォーム
フォームの選択肢によっては意味をなさないフォームもあったりします(メール送信しないのにメールアドレスの入力など)。入力しても意味のないフォームをわざわざ入力させられるのはユーザーにとっては体験がよくないですよね。なので、そういったフォームは選択に応じて非表示にするなどの工夫を行いました。 - 会議室の空き状況の確認
来客の方を自社に招待する場合、基本的に会議室を予約することがほとんどですよね。
静的に自社の会議室をリスト選択できるようにするだけなら簡単ですが、指定した時間に空いていないと意味がありません。
グリーでは会議室の空き状況はGoogleカレンダーで管理しているため、作成しようとしているアポイントメントの時間に対してGoogleカレンダーAPIに空き状況を問い合わせし、空いているものだけを選択可能としました。 - 処理を分けることでモーダルのタイムアウト制限を回避
元々は入力~APIで登録~結果返却の処理までモーダル一枚の処理で完結させる予定でした。しかし、Slackのモーダルには処理中の外部API呼び出しからのレスポンスを受領するまでの間に時間制限があり、その時間制限を超えてしまうとタイムアウトしてしまいます。
来客受付システムのAPIは、登録するデータ量によっては時間制限を超えてしまうことがわかり、回避策としてモーダルへのフォーム入力とAPI呼び出しとで処理を分け、時間制約に引っ掛からないようにする工夫を行いました。
オートメーションプラットフォームで開発してみてよかったところ・今後改善してくれると嬉しいところ
ここからはオートメーションプラットフォームで開発してみてよかったところ・今後改善してくれると嬉しいところについて紹介します。
よかったところ
- Slackのインフラ、CLIで完結する開発は想像以上に楽
今回、アプリの作成~開発~デプロイまで、すべてCLIで行いましたが、この体験は想像以上に楽だなと思いました。
従来であれば、まず
1.アプリ管理画面からアプリの枠を作成
2.生成されたトークンをコピー
3.アプリのコードにトークンを設定して開発
4.デプロイ先のインフラを用意してデプロイして動作確認
のようなことが必要でした。
しかしオートメーションプラットフォームであれば、
1.CLIからアプリの作成
2.トークンはSlack上で動作するため自動的に適切なものが設定されるのでコピペなどは不要
3.CLIからデプロイして完了
となります。
これらの要素は、開発生産性の観点でとてもメリットがあったと感じています。 - 開発環境の準備と開発時におけるテストの容易さ
開発にあたっては最低限DenoとSlack CLIのインストールが必要となりますが、MacやLinux、Windowsそれぞれについて必要なもの一式をインストールしてくれるスクリプトが公式で用意されているため、それを実行するだけで開発環境を整えることができます。
https://api.slack.com/automation/quickstart
また、デプロイする前の開発時、オートメーションプラットフォームでは「slack run」というコマンドを実行するだけでローカル上でアプリを実行することができます。コードの変更も再起動することなくリアルタイムで反映してくれるので、動きを確認しながら開発を行うことが可能です。
今後改善してくれると嬉しいところ
- 対応しているトリガーイベントを増えると嬉しい
従来のBolt によるアプリ開発だと、↓に定義されている様々なイベントをキャッチし、アプリをトリガーすることができます。
Events API types | Slack
しかし、オートメーションプラットフォームでは現在のところ、以下のようなイベントでしかトリガーすることができませんでした。
Event triggers | Slack
検討当初は、「ユーザーがアプリインストール時(app_installedイベント)にアプリの使い方を表示する」ようなことをしたいとも思っていたので、今後オートメーションプラットフォームでもそのようなイベントをトリガーにアプリを起動できるようになってほしいですね。 - アプリのホームビューを使いたい
オートメーションプラットフォームで開発したSlackアプリではホームビューが使えないです。
https://api.slack.com/lang/ja-jp/app-home-with-modal
そのため、ホームビューを使ってアプリの使い方などを表示したり、ユーザー毎のアプリの設定を持たせるなどといったことができません。
個人的には特に「ユーザー毎のアプリの設定」を持つ手段は欲しいなと思ったので、最悪ホームビューでなくてもこのあたりの代替手段はあると嬉しいなと思いました。 - Slackコマンドを使えるようしてほしい
オートメーションプラットフォームで開発したSlackアプリではSlackコマンドも使うことができません。代わりにリンクトリガーという仕組みを使ってショートカットから起動することが推奨されております。
代替手段が既に提示されており、かつそちらへの移行が推奨されているため、この機能がオートメーションプラットフォームで使えるようになる望みは薄そうですが、従来できたことがそのままできたほうが新しいものに移行してくれる開発者の方も増えるかと思うので、より開発者の裾野を増やしていくという点では使えたほうがいいのかなと思います。
最後に
いかがでしたでしょうか。
オートメーションプラットフォームを用いたSlackアプリ開発ではCLIのみで開発が完結できたり、インフラの用意が不要などメリットがある一方で、従来のBolt によるアプリ開発に比べてまだまだできないこともあることが今回の開発を通してわかりました。
今後徐々に改善していき、プラットフォーム間の差はなくなっていくかとは思われますが、現時点においては開発するアプリの要件に応じて、適切なプラットフォームの選択が必要と言えそうです。
開発者プログラムに登録すれば、オートメーションプラットフォームでの開発を体験できる個人用のサンドボックス環境を持つこともできるようですので、興味のある方は是非試してみてください。
Developer sandboxes | Slack