SlackAdvent Calendar 2022

Slack 次世代（オートメーション）プラットフォーム機能のご紹介

Last updated at 2024-09-28Posted at 2022-11-30

こんにちは、Slack の公式 SDK 開発と日本の Developer Relations を担当している瀬良 (@seratch) と申します

この記事では、この記事投稿時点で Slack がパブリックベータとして提供している「次世代プラットフォーム機能（英語では next-generation platform とか Run on Slack とか呼ばれています）」の概要について紹介します。

この記事では概要のみを説明しますが、今後も今年（2022 年）の Advent Calendar の空いている枠をお借りして、より詳細な記事も投稿していきます。なお、この Advent Calendar への投稿はどなたでも大歓迎ですので、ぜひお気軽に登録いただければと思います！

それでは、さっそく本題に入っていきたいと思います。

Slack の次世代プラットフォーム機能とは？

Slack の「次世代（オートメーション）プラットフォーム機能」とは、より簡単でセキュアなアプリ開発体験を提供する新しいアプリ開発・実行基盤のことです。そして、それを用いて開発されたアプリの中では、これまで Slack が提供してきた chat.postMessage API などの既存の機能の多くも利用することができます。

この記事では「ざっくりどういうものなのか？」「これまでとはどんな違いがあるのか？」「今まで作ったアプリとはどう共存していくと良いのか？」「どのような用途に利用できるのか？」といった疑問にお答えしていきたいと思います。

なお、技術ドキュメントにつきましては、こちらの公式ドキュメントページ（この記事投稿時点では英語のみ）にアクセスしてみてください。また、全体像の理解には「Slack 新プラットフォームの開発者用オープンベータ版が利用可能に（Slack 公式ブログ）」も併せてご参照ください。また、この記事投稿時点では情報が少ないのですが、日本語のコンテンツも今後増やしていきますので、こちらのページもぜひブックマークしておいていただければと思います。

新しいプラットフォーム機能に関する注意点

まずはじめに、この新しいプラットフォーム機能に関するいくつかの重要な注意点を説明します。この記事投稿時点で、すべての利用者の方に関係する基本的な注意点は、以下の 4 点です（最新の情報は必ずヘルプページをご参照ください）：

この機能は Slack のフリープランでは利用できません。有料プランのワークスペースでお試しください。
ベータ期間中、この機能はデフォルトでは有効になっていません。ワークスペースの管理者が管理画面でこの機能を有効にする必要があります。
正式リリースまでのベータ期間中は、機能の内容や設定方法が変更される場合があります。破壊的変更はメールで事前にお知らせする場合もありますが、できる限り変更履歴を定期的にご確認いただくようお願いします。
正式リリース後、このプラットフォーム機能の利用には使用量に応じて料金が発生する場合があります。料金プランの詳細は正式リリースのタイミングに合わせて発表されます。 2024/9/26 追記: 米国時間 2024/9/25 以降、全ての機能は Slack の有料プランに含まれ、一切の追加請求は行わないというポリシー変更が発表されました。

繰り返しとなりますが、最新の内容はヘルプページをご参照ください。また、サービス内容についてのお問い合わせは、カスタマーサポートへのご連絡をお願いいたします。

次世代プラットフォーム機能が提供する新しい仕組み

英語のドキュメントを眺めてみると、様々なコンポーネントが紹介されていることに気づくと思います。しかし、そのうちの多くは、基本的なものだったり、実はすでに次世代プラットフォーム以前から利用できたものがより使いやすく統合されているものだったりします。

ということで、これまで Slack アプリを作ったことがある開発者の方々にとって今回新しく提供される目玉機能だけに絞り込むと、以下の二点が重要なポイントになります：

Slack CLI を使ったコマンド操作による開発体験
Slack が管理するアプリ・データのホスティング環境

それでは、一つずつ説明していきます。

Slack CLI を使ったコマンド操作による開発体験

Slack CLI はこの次世代プラットフォームのために新しく開発されたツールで、これだけあればアプリのローカル実行、設定変更、デプロイなど全ての操作を行うことができます。インストール手順はこちらのページを参照してください。

アプリのローカル実行（local というラベルがついた開発版のアプリが生成されます）では、Slack のサーバーに WebSocket で接続するため、以前のように ngrok などのツールを使って公開された URL を用意する必要はありません。また、ローカルで動く Deno のアプリは自動で変更が反映されるようになっています。コードを書き換えると再起動することなく最新の挙動をすぐに確認できるので、快適に開発することができるでしょう。・・ところで、この WebSocket で接続する方式、実は 2021 年初頭からすでに現行のプラットフォームでも利用可能でした。ご興味のある方はこちらのソケットモードの入門記事もぜひ読んでみてください。

CLI でのオペレーションは CI/CD との相性が良いです。例えば GitHub リポジトリの main ブランチに変更がマージされたら GitHub Actions のジョブで自動デプロイを行う、といった自動化もできるようになります。また、ファンクションの単位であれば簡単にユニットテストを書くことができます。プルリクエストが来たら CI ビルドでテストを実行する、といった一般的な開発プラクティスを実践することも可能です。

Slack が管理するアプリ・データのホスティング環境

二つ目のアプリ・データのホスティング環境は、長らく多くのご要望をいただいてきた機能でした。slack deploy コマンドでアプリをデプロイする先は Slack が管理するサーバーレスのインフラであり、別途 AWS などのクラウド環境をセットアップする必要はありません。

また、アプリごとに利用できるデータストアも提供されており、アプリの利用設定やワークフローの実行履歴などを保存しておくことができます。

全てがサーバーレスなサービスとして提供されるため、もうカスタムアプリの運用を自前で行う必要はありません。開発者の利便性だけでなく、管理者の目線で見てもより扱いやすいプラットフォームとなりました。

次世代プラットフォームで動くアプリの構造を理解する

次に、少し詳細に踏み込んで、このプラットフォームで実行されるアプリの構成について説明していきます。

次世代プラットフォームで動作するアプリには、いくつか重要な要素が存在しています。それらを正しく理解することが、このプラットフォーム機能を理解する上で重要です。まずは以下のテーブルをざっと読んでみてください。

名称	説明
アプリ（App）	Slack 内で「アプリ」として表示される単位。ルートディレクトリにある `manifest.ts` で表現される。アプリが実際に動作する際には App Manifest データに変換され、デプロイ時に自動でメタデータを更新する。アプリとしての見え方（アイコンなど）、許可する権限のセットを変えたい場合は、別のアプリとして開発することが推奨される。
ボット（Bot）	ボットの権限（ボットとしてメッセージを送信など）を利用する場合、アプリをインストールした時点で、これまでのアプリと同様にアプリに対して 1 ボットユーザー（アプリを代弁するバーチャルな Slack ユーザー）がワークスペースに作られる。
ワークフロー（Workflow）	アプリには n 個のワークフローが含まれる。それぞれのワークフローは独立しているが、ファンクション・データストア・メッセージイベントを共有することが可能。
トリガー（Trigger）	ワークフローに紐づく形で n 個定義することができる。ワークフローが要求する inputs を提供できるトリガーの種別であれば、自由にワークフローの起動方法として追加することができる。この記事投稿時点では、リンクトリガー、イベントトリガー、スケジュールトリガー、ウェブフックトリガーの 4 種類が提供されている。トリガーの作成にはソースコードを定義して CLI でコマンドによって登録するか、ファンクション内で API 呼び出しをして登録するという二つの方法がある。
ファンクション（Function）	ワークフローの中の一つ一つの処理。あらかじめ定義しておいた名前・型の inputs の値を受け取り、外部サービスの連携を含む何らかの処理を行い、後続の処理のために決められた outputs を返す。Slack 内でのよくある操作を提供する組み込みファンクションは、ワークフロー定義の中で inputs を適切に設定するだけで利用することができる。外部通信を行うファンクションは `manifest.ts` にその接続先ドメインを明示する必要がある。
データストア（Datastore）	キーバリューストアのテーブルを n 個定義して、CLI のコマンドやファンクションからデータを登録したり、クエリを実行することができる。
メッセージイベント（Event）	（Slack の UI 上は表示されない）メッセージのメタデータが投稿されたイベントをトリガーとして何らかのワークフローを実行することができる。複数のワークフローが協調して動作するようなユースケースで利用する。

上記の全てをフルで利用する必要はありません。用途に合わせて必要なものだけを利用することができます。例として、リンクトリガーで起動する問い合わせ管理を考えてみましょう。

ヘルプデスクへの問い合わせチャンネル・キャンバスにリンクトリガーのボタンを配置（エンドユーザーがこれをクリックしてワークフローを開始する）
標準ファンクションを使ってフォームを表示、依頼者からの情報入力を受け取る
チームが利用する外部サービスに新しい問い合わせとして登録
標準ファンクションを使ってヘルプデスクチームのチャンネルに新規問い合わせが来た旨通知

といった形になるかもしれませんし、外部サービスの部分をデータストアに置き換えることも可能でしょう。最後の通知のところでメッセージメタデータを含めるようにしておけば、後続のワークフローに処理を連携させることもできたりします。

ボットユーザーをメンションしたらイベント通知する、といったこれまでにも存在した仕組みはこの新しい基盤でも用意されています。ワークスペースのメンバーがボットとの会話のスタイルに慣れている場合は、そこから返信にボタンを含めるなどしてモーダルでのやり取りに誘導するのもよいでしょう。

具体例からワークフロー・トリガーの存在意義を理解する

ここまで読んで「なぜトリガーやワークフローといった仕組みが必要なのか？」と疑問に思っている方も多いかもしれません。その疑問にお答えするために、また別のユースケースを説明してみたいと思います。

以下は、あるアプリとそれに含まれる二つのワークフローを図示したものです。この図を見ていただければ、なぜトリガーというものがワークフローから独立した形で存在しているのかがご理解いただけるかもしれません。

この新しいプラットフォーム基盤は、モジュールの再利用性を非常に重視して設計されています。つまり、「同じワークフロー・ファンクションを別の場所でも流用したい」という場合に、非常に柔軟に対応できるようになっています。

ご覧の通り、上の図にある「メンバーデータ更新ワークフロー」は、Slack 内に配置されたリンクトリガーのボタンから即時実行もできますし、新しいメンバーが参加したタイミングでも、日次処理として毎朝実行することもできます。

その横にある「問い合わせワークフロー」は、フォームを使ったエンドユーザーとのインタラクションが必要なので、定期実行トリガーなどでは実行できません。しかし、複数のチャンネルにリンクトリガーを配置することで、どこでも簡単に流用することができるようになっています。

次世代プラットフォーム機能は、一見構成要素が多いように見えるかもしれませんが、上記の図のように整理してみるとスッキリとした構造になっていることがわかります。

どのような用途で利用できるのか？

上で少しだけ具体的なユースケースに触れましたが、一般的にこの次世代プラットフォーム機能は実際にはどのような用途に向いているのでしょうか？この記事では、以下の二つの観点から解説していきたいと思います。

次世代プラットフォーム機能は Slack 内でワークフローを作るための仕組みである
次世代プラットフォーム機能は全ての既存機能を置き換えるものではない

次世代プラットフォーム機能は Slack 内でワークフローを作るための仕組みである

この次世代プラットフォームは、「Slack との連携をネイティブにサポートした、再利用性の高いワークフローエンジン」として設計されています。ですので、技術的にはどんなワークフローでも自由に実装することが可能です。極端な話、Slack のチャンネルのメッセージなどに一切タッチしない汎用のワークフロー実行基盤として利用することさえ可能です。

別の視点から見ると、上の図でも説明した通り、ワークフローやファンクションのレベルでは Slack UI の都合・制約とは完全に切り離されているという点が非常に特徴的です。上の図示した例でも見たように、ユーザーとの同期的なインタラクションを必要としないワークフローは、定期実行であっても、Slack 内のイベント起因であっても、Incoming Webhooks へのデータ送信であっても、リンクトリガーのクリックイベントであっても、同じように実行が可能です。個々のファンクションは、あらかじめ定義された inputs が提供される限りはどんなワークフローにも組み込むことができます（もちろん「そのトリガーが何か？」も一切関係ありません）。この設計ポリシーによって、高い再利用性が実現されているのです。

こちらのブログ記事にもあるように、このプロジェクトの最終的なゴールは「ワークフロービルダーのさらなる進化」です。現在はまだリリースされていませんが、近い将来、デプロイしたファンクションはワークフロービルダーの画面上から自由に任意のワークフローに組み込むことができるようになる予定です。

ということで、この次世代機能を使ってアプリを設計する際には、ぜひこの再利用性を活かしたデザインを意識してみてください。それによって、より利便性の高いワークフローやファンクションの提供を実現できるはずです。

次世代プラットフォーム機能は全ての既存機能を置き換えるものではない

一方で、次世代プラットフォーム機能には、これまでの Slack アプリとは異なる点がいくつかあり、結果としてあまり向かない領域があるのも事実です。ここでは、この点に焦点を当てながらもう少し詳しく説明していきます。

この記事投稿時点で、次世代プラットフォーム機能は、以下の機能をサポートしない方針となっています（ただ、多くのフィードバックをいただいていますので、正式リリースまでに何らかの変更が入る可能性は依然としてあります）。

スラッシュコマンドでのワークフロー起動はサポートされない
グローバル/メッセージショートカットでのワークフロー起動はサポートされない
アプリのホームタブの利用はサポートされない
メッセージ送信のための Incoming Webhooks はサポートされない
トリガー以外の仕組みでイベント API はサポートされない
イベント API とは異なり、チャンネルにボットユーザーを招待するだけでイベントトリガーが有効にならない

一つずつ、補足説明をしていきます。

次世代機能では、スラッシュコマンド、ショートカットでの起動の代わりに、リンクトリガー（Link Trigger）を提供しています。これは Slack 内でのみ動作する permalink のような URL を発行し、これを Slack のチャンネルのブックマークやキャンバス内に埋め込むことでエンドユーザーが簡単にワークフローを起動する仕組みです。これまでのショートカットのようにアプリがワークスペースにインストールされたらグローバルで有効になるのではなく、指定された場所でのみ起動するという用途を想定しています。

次に、ホームタブがサポートされていません。ホームタブは、アプリの操作への導線を集約したり、ダッシュボードとして情報を表示するために広く利用されています。しかし、次世代機能では上記のリンクトリガーのようにユーザーとのインタラクションが可能なエリアを絞る形を基本設計としているため、少なくともこの記事投稿時点では、ホームタブはサポート対象外となっています。

また、Incoming Webhooks の URL を発行して、それを用いて特定のチャンネルにメッセージを投稿する、というような、ワークフローになり得ない単体で存在する機能もサポートされる予定はありません。ただし、当然ながら Incoming Webhooks が使えなくなるということではありません。次世代プラットフォームのやり方ではなく、これまでと同様に Slack アプリを作成して OAuth フローからインストールをしていただくということになります。

最後のイベント API の相違はどういうことかというと、次世代プラットフォームでは、イベント API の受信はトリガーという新しい仕組みのみに統合されています。そして、トリガーではこれまでのようにボットやインストールしたユーザーの可視範囲でイベントを受信するのではなく、あくまでトリガーに設定された n 個のチャンネルのみを対象としています。上記のリンクトリガーと同様、明に設定（あるいはコード）で表現された範囲のみでイベントを受信できる設計になっています。そのため、これまでと同様にボットがいるチャンネルでイベントを受け取りたいという場合、ちょっとした工夫が必要となるのですが・・・これについては別の記事で詳しく解説したいと思います。

既存のプラットフォームはどうなるの？

まずご安心いただきたいのですが、既存のプラットフォーム機能も引き続き存在し続けます。

この次世代機能は、非常に大規模な機能追加と捉えていただければと思います（ですので、この記事ではできるだけ「機能」と呼称しています）。

もちろん、次世代プラットフォームの仕組みに集約したいということで、既存アプリを移行することは全く問題ありません。ですが、利用している機能が次世代プラットフォームに存在しない場合や、安定して稼働している既存アプリについては、引き続きそのままご利用いただけます。

とはいえ、この記事で見てきたように、次世代機能側には様々な改善・進化が施されています。これから新しい Slack アプリを開発する場合はまずは次世代プラットフォームで実現できないかを検討されることをおすすめします。そして、それが要件に合わない場合は引き続き Bolt でアプリを開発することも可能です。

Bolt と Deno SDK の違いは？

次世代プラットフォーム機能では、アプリの実行環境として Deno のみをサポートしており、新しい Deno 用の SDK を利用します。

Slack はこれまで Bolt というアプリ開発フレームワークを Node.js、Python、Java の実行環境向けに提供してきました（私はこの Bolt の主要なメンテナーの一人で、特に Python と Java についてはほぼ私一人で開発しました）。

Bolt の今後が気になっている方もいらっしゃるかと思います。現時点でお伝えできることとしては「Bolt は今後も重要なツールとして提供され続けますが、Slack が提供するホスティング環境で Bolt を利用できるようになる可能性は将来においても非常に低いです。ですが、別の場所で稼働する Bolt のアプリケーションからファンクションのみを別の形で提供することは可能です。」というメッセージとなります。　

具体的には Bolt の app.function というメソッドにファンションの処理を行うリスナーを渡すことができます。これはイベント API の形式でファンクションが実行されたときに Bolt アプリにリクエストが来て、それに対して処理を実行する形です。既存のワークフロービルダーのカスタムステップ実装をご存知の方であれば、それがより簡潔になったものをイメージしてみてください。

現在、以下のページでこの機能のドキュメントが公開されています。正式リリースのタイミングで日本語訳も提供予定です。

Bolt for JavaScript (Node.js)
Bolt for Python
(Bolt for Java は現在準備中です)

こちらの件については、また別の記事で解説したいと思っていますので、ご興味のある方はぜひご期待ください。

すでに試してくださった方々のブログ記事のご紹介

最後に、すでにこの次世代機能を試してくださった方々のブログ記事をご紹介したいと思います。記事を書いていただき、本当にありがとうございます！

今後の予定とフィードバックのお願い

文字ばかりの記事を最後までお読みいただきありがとうございました。
今月はこれからいくつか記事を公開していきますので、ぜひ Slack の Organization をフォローしていただければと思います

（追記）次世代プラットフォーム機能を少しずつステップバイステップで学ぶことができるチュートリアルシリーズを始めましたので、ぜひこちらの記事をストックして更新を受け取るようにしてみてください！

次世代プラットフォーム機能について、ぜひフィードバックをお寄せください！ https://api.slack.com/automation のページで表されているアンケートは日本語でお答えいただいても大丈夫です（私が都度英訳してチームに伝えています）！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up