Slackを導入していないIT企業の方が少ないでしょう。Slackの知識は身につけておいて損はありません。
そう思ってSlackのBotを作って会社のワークスペースで動かしていますが、最初はかなり戸惑ったのでSlack Bot制作の初学者向けに色々書き残しておきます。
作ったbot
Bot作りの経験者であることを明記しないと説得力が無いと思いましたのでデモ動画を載せておきます。
Gmail, Googleカレンダーと連携してメールチェックや予定の確認ができます。
最初の壁
事前知識無しにSlackのBot作りに挑むと案外戸惑います。
「SlackBot 作り方」とかでググるとSlackの日本語公式ページが見つかリますが初心者向けには書かれていません。イベントAPIを有効化しろとかいきなり出てきます。
そしてよくわからないままワークスペースの管理画面からEvents APIを有効化しようとするとリクエスト用のURLを入れろとか言われてもう訳がわかりません。
私がBot制作を始めたときに戸惑ったのは主に以下です。
- Getting Startedの日本語ページはない。読むのに時間がかかる。
- Events APIを有効化するときにリクエストURLを要求される。何のことだろう。
- 他にもBotに使えそうなAPIがある。どれを使えばいいのかがわからない。
この記事ではコーディングには触れず、最初の壁であるAPI選びについて解説していきます。
Slack Botの実現手段
大きく分けて4つあると思います。
- Incoming Webhook
- Outgoing Webhook
- Events API + Web APIの組み合わせ
- Real Time Message API
この記事ではそれぞれの向き不向きに着目して順番にざっくり解説します。
Incoming Webhook
Incoming WebhookはSlackのAppディレクトリで公開されているアプリです。ワークスペースにインストールして使用します。
特徴まとめ
- Slackから指定されるエンドポイントに対するHTTPリクエストを送信することでBotユーザーに発言させることができる
- 発言の内容はHTTPリクエストのbodyに含めることができる
最大の特徴はプログラムを作成する必要がないことです。
概要
端的に書くと、最も簡単なSlackへの情報出力手段です。Slackからの入力を受け付ける必要がないならこれを使いましょう。
プログラミングを必要とせず、Slackから提供されるURLに対してPOSTリクエストを発行するだけで特定のチャンネルへの発言ができます。
公式からcurlのサンプルも提供されており、bodyの部分を変えるだけで自由なテキストをSlackに表示させることができます。
Bot経由の発言として扱われ、Botの名前やアイコン画像はワークスペース管理画面から自由に変えられるので、第三者から見ればBotと見分けがつきません。
エラーログ監視レポートや、CIジョブの異常終了などをSlackに通知したければIncoming Webhookで十分でしょう。
Outgoing Webhook
こちらもSlackのAppディレクトリで公開されているアプリです。ワークスペースにインストールして使用します。
Slackのチャンネル内でトリガーとなる言葉が発言されると、SlackからWebhookが送信されます。
特徴まとめ
- Web APIを作成し、Slackサーバーからのリクエストに対してレスポンスを返すことでBotに発言をさせる
- Slackのワークスペース管理画面からAPIに対してリクエストを送るトリガーとなる言葉を登録できる
概要
Incoming Webhookは我々がSlackに対してリクエストを送信するのに対し、Outgoing WebhookはSlackが我々の用意するサーバーに対してリクエストを送信してきます。
ワークスペースの管理画面からトリガーとなるワードとトリガーを受け付けるチャンネルを登録し、リクエスト先のURLを登録すれば使用できます。
「最初の壁」で述べたEvents APIのリクエストURLとはこれと同じもので、Slackからのリクエストを受け付けるAPIサーバーのエンドポイントのことです。
つまり、Slack Botを作る = WebAPIサーバーを作るです。前情報無しの初心者はこれを知らないので躓きがちです。
Slackから送信されるリクエストの内容、こちらが返すべきレスポンスの内容はOutgoing WebhookのApp管理画面から確認できます。
引用: Slack Outgoing Webhook Appディレクトリ画面
Events API + Web APIの組み合わせ
Outgoing Webhookと基本は同じですが、トリガーの幅はこちらの方が広く持たせられます。
Slack Botの最も一般的な実現方法だと思います。
特徴まとめ
- Slack上のメッセージだけでなく、チャンネル入退場、チャンネル作成などのイベントをトリガーとして動作することができる
- Appの管理画面からどのイベントをトリガーとするか設定できる
- Botに何か発言させたい時はSlack Web APIに対してリクエストを送信する
概要
Outgoing Webhookと同様に、Slackが特定のトリガーに反応してWeb APIに対してリクエストを送信してきます。
Bot制作当初はSlackイベントを取り扱う予定がなくても、運用していく過程でイベントへの反応が欲しくなることがあるでしょう。
実装の手間は多少膨らみますが、Outgoing WebhookよりもEvents APIで制作を始めることを個人的にはおすすめします。
Events APIはSlack Appを作成し、Events Subscriptionsを設定することで有効化できます。
引用: Slack AppのBasic Information画面
Events APIでの開発は公式でBoltというフレームワークが提供されています。
日本語ドキュメントが用意されており、非常に見やすいのでWeb APIの制作経験がない方でも取っ付きやすいかもしれません。
Real Time Messaging API
いわゆるRTM APIです。SlackのサーバーとWebsocketで通信し、Slack上のイベント発生通知を受け取ります。
特徴まとめ
- Web APIを用意する必要がない。公開サーバーを用意しなくてもローカルマシンでSlack Botを動かせる
- Websocket通信でSlackのサーバーと通信する。大きなワークスペースと接続するとリソースの消費が大きい。
最大の利点はローカルマシンでSlack Botを動かせる手軽さです。
概要
RTM APIでBotを作成する場合はOutgoing WebhookやEvents APIと違ってAPIサーバーを必要としません。
ワークスペースにBotを登録するとトークンが配布され、それを利用してSlackとWebsocketで接続します。
インターネットに繋がる環境であれば何処でも動かすことができ、開発PCでそのまま動かすことができるので、間違いなく手軽さはNo.1です。
一応、欠点としてはリソース消費の大きさが挙げられます。
Events APIと異なり、トリガーとなるイベントを絞り込むことができないので、大きいワークスペースでは大量のイベントが送信されてくることになります。
複数のワークスペースとコネクションを確立することもできますが、その分多くのリソースを消費することになります。
注意点として、new Slack appsではRTMは利用できないようです。
下記のページ最下部にあるCreate a classic Slack appのボタンからV1 OAuth認証のSlack Appを作成する必要があります。
Real Time Messaging API
APIの選び方まとめ
私が考える目的別のAPIの選び方はこんな感じです。
| やりたいこと | API |
|---|---|
| エラーログ監視、ジョブの失敗などをSlackに通知させたい | Incoming Webhook |
| 定期的にBotユーザーに発言させたい | Incoming Webhook |
| 公開Webサーバーを用意せずにBotを作りたい | Realtime Message API |
| ユーザーからの特定の単語に反応するBotを少ない実装で作りたい | Outgoing Webhook |
| チャンネル参加 チャンネル作成などのイベントに合わせて発言させたい | Events API |
| 拡張性も考慮してとりあえず無難にBotを作りたい | Events API |
以上、誤りや改善点などありましたらコメントください。