こんにちは、プレイドのProduct Specialistのgami（ @jumpei_ikegami ）です。プレイドでは主にテクニカルサポートや外部連携の検証をしています。趣味はポッドキャストの配信です。

プレイドでは、KARTEというリアルタイムユーザー解析プラットフォームを提供しています。このたびKARTEでは、公式のSlack AppをSlack AppディレクトリにPublishしました！

その過程で、Slack APIが2019年から今年にかけて大きく変化していることを知りました。せっかくなので、Slack Appを開発するエンジニアに向けて、Slack APIがどのように変化してきたのか、Slack App界隈がこれからどう変わっていくのか、簡単に紹介したいと思います。Slack側の公式発表もたくさん出ていますが、ここでは一人のSlack App開発者の目線で話します。

忙しい人のための要約

3行で言うと以下です。

2019年から2020年にかけて、Slack APIに "the Slack app toolkit" と総称される4つの大きな機能群が追加された
特にBlock Kitと呼ばれる新しいUIフレームワークに乗っかって、様々なUIをSlack上で表現できるようになった
Slack Botに "Granular permissions" と呼ばれる権限モデルが登場し、App Directoryに掲載されている全てのSlack Botは2020年中に新しい権限モデルに移行する必要がある

KARTEとSlack

Slack APIの変化について話す前に、僕の立場を明確にする意味でも、KARTEがなぜSlack Appを作るに至ったかについて簡単に説明します。

最初はIncoming Webhookで連携していた

そもそもSlack Appを作る前から、KARTEとSlackはIncoming Webhookという汎用的なSlack Appを使って一部で連携していました。Slackに通知を流し込むだけであれば、Incoming Webhook使えば実現可能だったからです。

Incoming WebhookのWebhook URLをKARTEの管理画面に登録してもらうことで、たとえば下記のようなSlack通知を実現していました。

エンドユーザーから受け取ったチャットをSlackに流して、オペレーターがチャットに気付きやすくする
特定の条件に合致するユーザーがWebサイトに来たときに、営業担当にSlackでメンションする

Slack Appを開発することを決めた

そんなわけで、KARTEのSlack Appを作らなくても上記のような通知は実現できていたわけですが、主には下記の理由から、KARTEのSlack Appを新しく開発することになりました。

今後Slackとの連携を強めるにあたり、Appとして実装した方ができることが広がる
- Slackとのインタラクティブなやりとりや、Home tabを使った表現などが可能となる
KARTEとSlackを連携させるならSlack Appを一度インストールするだけでよくなる
- Slack Appにすることで、通知先を増やす度にWebhook URLを発行する必要がなくなる

また、Slack Appディレクトリに掲載されることで、サービスとしての認知が広がるかもしれないという期待もありました。

ただし、最初から機能を盛り盛りにしてしまうとリリースが遅れてしまうので、まずは下記のような最低限のシステム通知系機能だけをSlack Appとして実装しました。

KARTE側のジョブ実行ログやシステムアラートなどをSlackに通知する
レポートを定期的にSlackに通知する

リリースされたのは2020年1月で、Slack App ディレクトリにも掲載されています。また同タイミングで、プレスリリースも出させていただいてます。

KARTEとSlackが連携を開始 | 株式会社プレイド

"the Slack app toolkit" という大きな変化

さて、KARTEのSlack Appを作るに当たって、Slack App実装のトレンドについて事前に色々と調べました。すると、Slack APIのさまざまな仕様が、2019年から2020年にかけて大きな変化を迎えていることがわかりました。

この「大きな変化」は、Slack社のブログの中で "the Slack app toolkit" と表現されています。

Introducing the Slack app toolkit - Slack Platform Blog - Medium

"the Slack app toolkit" の構成要素は以下の4つです。

Permissions
Block Kit
Surfaces
Actions

toolkitという呼称からも分かるように、一つの大きな機能ではなく、「同時期にたくさんの新機能を出すのでまとめて紹介するね！」という感じで様々な機能がまとめられています。

1. Permissions

上記のSlack Platform Blog記事を読むと、"the Slack app toolkit" の各構成要素には、それぞれ「二つ名」的なフレーズが付けられています。

"Permissions" の「二つ名」は、 "Building enterprise-ready apps" です。セキュリティ要件が厳しいエンタープライズにもSlackが導入されるようになってきたことを受けて、Slack Bot周りの権限モデルを見直すことになったと想像します。

具体的には、 "Granular permissions" と呼ばれる権限モデルが2020年1月に正式リリースされ、Slack Appの権限をより細かく管理できるようになりました。

これまでは、Slack AppにBot権限を付与すると、Slackに参加している人間と同様の広範な権限がデフォルトで与えられてしまうような仕様でした。ただし、Slack AppにはBot権限が無いと使えない機能が多く、「単機能のSlack Appにも関わらず大量の使わない権限を保持してしまうことがある」という問題がありました。

今回の "Granular permissions" の登場によって、その問題が解消されました。Slack Botの権限をかなり細かく付け外しできるようになり、セキュリティ要件の厳しい企業であってもSlack Appをインストールしやすくなります。

Slackからの発表によると、App Directoryに掲載されている既存のSlack Appについても2020年中に "Granular permissions" に移行する必要があります。今後は権限モデルが "Granular permissions" に一本化されるわけです。

KARTEのSlack Appでは、リリース時点から "Granular permissions" に対応しました。KARTE自体がBtoB SaaSなので、クライアントに安心感を与えられるという意味でとてもありがたい権限モデルでした。なお、 "Granular permissions" への具体的な対応方法については後述します。

2. Block Kit

"Block Kit" とは、Slackの新しいUIフレームワークです。2019年2月に、正式リリースされました。Slack Platform Blogにも専用の記事が出ています。

Block party - Slack Platform Blog - Medium

それまで、Slack Appから送信できるメッセージのUIは限定的でした。主に、Attachmentと呼ばれる「添付」のための仕組みを使って表示のフォーマットを整えるというHackが横行していた印象です。そのAttachmentすら、表示形式が決まっており表現の自由度が低かったです。

Attachmentの使用例

上記画像のような、左にカラーバーが表示されているUIがAttachmentです。比較的新しいSlack AppでもこのAttachmentが使われているので、みなさんもきっと見覚えがあるんじゃないかと思います。

一方、 "Block Kit" ではblockと呼ばれるUI部品を自由に組み合わせて、Slackのメッセージを構成することができます。blockには表示のためのものだけではなくユーザー入力を受け取るための要素もあります。ユーザー入力については、Slack Appに登録したエンドポイントで受け取ってサーバーサイドで自由に処理することができます。

"Block Kit" を体験してみたい方は、Block Kit Builderを使うのがおすすめです。APIを叩かなくても "Block Kit" で可能な表現を確認できます。

Block Kit Builder画面

また、API経由で使う場合も、chat.postMessageへのリクエストbodyのblocksに送りたいBlocksに対応したJSONを入れるだけで使えます。

なお、「実際にAPI経由で送られたメッセージの定義をJSONで見たい」という場合には、Slack Developer Toolsを使うと可能になります。他のイケてるSlack Appのmessageで使っているBlocksを参考にカスタマイズしたい、という場合は、下記の手順でできます。

Slack Developer Toolsをworkspaceにインストール
参考にしたいmessageのActionから、Slack Developer ToolsのInspectを呼び出す
そのmessageに対応する生のJSONが表示される
ありがたいことに[Open in Block Kit Builder]というボタンも表示されるので、押す
JSONが格納された状態でBlock Kit Builderが開くので、好きなように編集してUIをカスタマイズする
編集したJSONを生成できるように、Slack Appを実装する

（こうした開発ツールが豊富に提供されている点が、Slackが世界中のDeveloperに愛される理由だと思います。）

3. Surfaces

"Surfaces" の「二つ名」は、 "Your app in more places" です。その名の通りSlack Appの表現方法をMessage以外にも広げるようなもので、以下の2つの機能の総称となっています。

App home
- App home画面では、これまでSlack AppのBotとの間で、messageのやりとりをすることができた
- それに加えて、 "Home tab" が新たに追加された
- "Home tab" のUIはApp側で独自に構築され、Appの情報を表示したりAppを操作するためのUIを提供したりできる
Modals
- ユーザーのアクションをトリガーに、Slack Appから "Modal" を開くことができるようになった
- Modalの中では、Text inputを含む様々な入力用のComponentが使える

"Home tab" や "Modal" のUIについても、 "Block Kit" のblockを組み合わせて構築できます。 "Block Kit" という共通のフレームワークでmessage以外のUIも表現できるのは、とてもわかりやすくて感動します。

また、 "Home tab" や "Modal" では、viewをAPI経由で更新することで簡易的な画面遷移を実現することが可能です。messageの場合はやりとりの履歴が残ってしまいますが、 "Home tab" や "Modal" を使いこなせばサービスを操作するための簡単な管理画面をSlack上に実装できそうです。

Slack Appの実装に慣れていない人はイメージしにくいかもしれませんが、実際に "Home tab" や "Modal" を使う場合は、下記のようなサーバーサイド処理を実装する感じです。

"Home tab" や "Modal" を描画するきっかけとなるユーザーのアクションが発生すると、SlackからAppサーバーにリクエストが飛ぶ
受け取ったリクエストの内容を元に、viewの内容をBlocksで定義し、APIを叩いてviewを表示する
- "Home tab"
  - views.publishを呼ぶ
- "Modal"
  - views.openを呼ぶ
その後、表示した "Home Tab" や "Modal" に対してさらにユーザー操作が発生したらそれもリクエストとして飛んでくるので、必要に応じてviewを更新していく
- "Home Tab"
  - 作成時と同様に、views.publishで更新
- "Modal"
  - validationエラーなどが起きたらviews.updateで更新
  - 条件分岐が発生した場合など、views.pushで画面をスタックすることもできる

なお、Slackには以前からDialogsと呼ばれるモーダル表示機能がありましたが、Modalsへの移行に伴い非推奨になったようです。

4. Actions

"Actions" の「二つ名」は、 "Apps in context" です。 "Surfaces" はAppの表現の広がりを意味していましたが、 "Actions" はAppをトリガーする方法が広がったことを表しています。

"Actions" 自体は2018年5月からリリースされていました。ただしこの時点では、「特定のmessageからAppのActionを呼び出せる」という機能に限定されていました。

Introducing Actions: A simple shortcut attached to every Slack message

少しSlack Appから話は飛びますが、2019年10月に「ワークフロービルダー」という強力な機能がSlackに追加されました。

ワークフロービルダーが新登場 : Slack で簡単にタスクを合理化 | The Official Slack Blog

「ワークフロービルダー」では、簡易的なIFTTTやZapierといった感じで、「Slack内のあるイベントをトリガーに、指定したメッセージを送ったり、Modalで入力を受け付けたりする」というルールをchannelに追加することができます。たとえば、チャンネルに参加した人に自動メッセージを送信したり、社内の簡易的な申請フォームをSlack上で送信したりを想定した機能のようです。要は、Slack Appを実装しなくても簡単なアプリケーションをGUIで作成できますよーということです。

この「ワークフロービルダー」のトリガーの中に、「メンバーの誰かがチャンネルのアクションメニューからワークフローを選択」というものがあります。重要なのは、 "message" ではなく "channel" からアプリケーションをトリガーできるということです。

残念ながら、2020年2月現在、通常のSlack Appをchannel単位のアクションメニューからトリガーするということはできないようです。

Enabling interactivity with Actions | Slack

ただし、このアクションメニューを「ワークフロービルダー」に限定して提供する理由も無いと思うので、おそらくSlack Appについても「channelのアクションメニューを選択した」というeventを受け取れるようになると予想します。もしかしたら、messageやchannelに続いて、workspaceなど他のオブジェクトに対してアクションメニューを呼び出せるようになるかもしれません。

ちなみにSlack Appには、初期の頃からSlash Commandsという起動方法が提供されていました。CLIライクに、/から始まるコマンドをSlackのチャットtextareaに入力するというものです。開発者にとって、Slash Commandsは社内ツールを提供する上でとても簡単かつ便利な手段でした。しかし、Slash Commandsを実装したことがある人はわかると思いますが、「コマンドを打つ」というUIに馴染みがない人が多く、非エンジニアの社内メンバーに自作Slash Commandsを広めるのは難しいケースが多い印象です。channel単位のアクションメニューがSlack Appに導入されれば、これまでSlash Commandsが提供してきたような機能は、Actions + Modalで実装するのがベストプラクティスになりそうです。

"Granular permissions" への対応方法

上述したように、Slack社は "the Slack app toolkit" という総称で新機能を次々と提供し、これまでのSlack App開発の在り方を大きく改善しようとしています。Slack Appで実現できるユーザー体験の幅がどんどん広がってきているので、従来Webアプリケーションとして提供されてきたようなサービスを全てSlack App上で提供するようなスタートアップなんかが、今後はもっと出てくるかもしれません。ワクワクしますね！

そんなワクワクの中にあって恐縮ですが、KARTEではまず最低限のシステム通知系機能だけをSlack Appとして実装しました。今後は "Home tab" でリッチな情報を提示したり、 "Interactive components" を使ってSlack UIからKARTEを操作するような機能提供をしたいところですが、今のところは "Granular permissions" にだけ主に対応しました。

せっかくなので、今回対応した "Granular permissions" について、その対応方法をまとめておきます。前述のように、App Directoryに掲載されている既存のSlack Appについても2020年中に "Granular permissions" に移行する必要があります。過去にOAuth認証を実装しているSlack Appを開発したけれど "Granular permissions" にまだ対応していない方は、ぜひ参考にしてください。

Slack App管理画面側

Slack App管理画面にアクセス
開発したいAppを選択
サイドバーから[OAuth & Permissions]を選択
未対応の場合、[Scopes]のところに[Update Scopes]ボタンが表示されるので、それをクリック
bot tokenとuser tokenについて、必要なscopeだけを選択して保存する
- user tokenは主に「ユーザーに成り代わってメッセージを送る」などに使うtokenなので、普通は要らない

Slack App実装側

OAuth周りの以下の記述を変更
- OAuth URL Path
  - before
    - https://slack.com/oauth/authorize?...
  - after
    - https://slack.com/oauth/v2/authorize?...
- OAuth URL Query
  - befre
    - ?scope=bot
  - after
    - 管理画面で設定したscopeをそれぞれ指定
    - ?scope=channels:read,groups:read,...
- OAuth method
  - before
    - oauth.access
  - after
    - oauth.v2.access
- OAuthのResponse bodyのスキーマも変わるので、たとえばaccess_tokenを取得する部分も変更が必要
  - before
    - response.bot.bot_access_token
  - after
    - response.access_token
すでにSlack AppをインストールしているWorkspace管理者に再認証を依頼
- access_tokenがRefreshされ、 "Granular permissions" への対応が完了する

Slack Platform Blogで事例化されました！

そんなこんなで、KARTEは "Granular permissions" に対応したSlack Appをいち早くリリースしました。

そして、BtoBサービスの "Granular permissions" 対応がグローバルでも珍しかったからか、Slack Japanの@seratchさんにお声がけいただき、なんとSlack Platform Blogに事例として取り上げていただきました！

More precision, fewer restrictions - Slack Platform Blog - Medium

KARTEのロゴを可愛いアニgifにしていただき、感無量です。。。

またそのご縁もあって、2020年2月4日にSlack Platform Community Tokyoのイベントでもこのブログで書いたような内容で登壇させていただきました。

See 2020 Kick-off Meetup @ Slack Japan at Slack Platform Community Tokyo

登壇スライドも公開されていますので、興味があればご覧ください！

まとめ

以上です。この記事で紹介したように、Slack API周りのここ1年間の環境変化はかなり大きかったですが、どれもエンドユーザーの体験を向上するようなありがたい変更でした。これらの変更を俯瞰すると、Slack社がSlack AppたちをSlack Platform上でどのように位置付けていきたいのかが、なんとなく見えてくるような気がします。そうしたSlack Appの新しいパラダイムをきちんと理解してそれに乗っかることで、さらに便利で使いやすいSlack Appが開発できるようになると思います。

これからも、良いSlack App開発ライフを送っていきましょう！

CX（顧客体験）プラットフォーム「KARTE」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。
詳しくは弊社採用ページまたはWantedlyをご覧ください。もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！

2020年のSlack App開発者が知るべき最新のSlack API仕様