Slack連携の限界突破へ！iPaaS活用ガイド（第3回：Zapier実践編！ノーコードで実現するSlack承認フロー、生成AI連携）

s-sato

はじめに

対象読者

本記事は、Slackと他サービスとの連携に関して課題を感じている方、Slackをハブにした業務フローを検討している方を主な対象としています。

本記事の前提知識として、SlackアプリやWebhookに関する基本的な知識、何かしらのワークフローツールの基礎知識があることを想定しています。

記事のゴール

本記事は複数回に分かれていますが、全体を通じて、読者は以下の点を達成することを目指したいと思います。

  • Slackと他サービスとの連携方法について、改めておさらいする
  • iPaaS(Integration Platform as a Service)の Zapier と Make のサービス概要を把握する
  • Zapierによる実際のフロー構築のイメージをつかむ、Makeとの違いを把握する（今回の範囲）

Zapierによるワークフロー構築

今回は、Zapierによるワークフロー構築について記載していきたいと思います。
なお、トリガーやアクション内に登場する各サービスとの連携は設定済みの前提として、連携設定に関する記載は割愛していますが、Zapierは公式Slackアプリが提供されているので連携設定は非常に簡単です。

Makeの場合:
公式ドキュメントを見ながら自分でSlackアプリを作成して、さらにあちこち設定する必要があるので、連携設定の難易度が高いです。

例1: フォームからの申請をSlackに通知し、承認したら実際の処理を実行

まず最初の例として、以下のようなありがちなワークフローを作成していきたいと思います。

今回はサンプルとして、社内GitLabユーザーの追加・削除申請というシナリオに沿って作成していきます。

まず事前準備として、Googleフォームに以下のようなフォームを作成しておきます。

トリガー設定: Googleフォームへの送信を検知

まずワークフローの起点として、先頭に以下のようなトリガーを作成します。

  • App: Google Forms
  • Trigger event: New Form Response
  • Form: 事前に作成しておいたフォームを指定

この状態で、作成しておいたフォームに何かサンプルとして1件の回答を記入して送信します。

その後、Zapier画面に戻り Test ステップで Find new records をクリックします。

そうすると下の方に新しい Form Response が表示されるので、そこをクリックしてみると、先ほどフォームに記入した内容が表示されるはずです。

この後作成していくアクション内で、フォームにどういう記入欄があるかの情報が必要となるため、このように一度サンプルデータを送信して、Zapierに認識させておく必要があります。
認識させたら、下部の Continue with selected record をクリックして次に進みましょう。

Makeの場合:
Googleフォームへの送信を直接検知することができないため、Googleフォーム側で回答をGoogleスプレッドシートに出力するように設定しておき、スプレッドシートへの行の追加を検知するトリガーにします。

アクション: Slackチャンネルへ通知と承認待ち

次にSlackへの通知と、承認を受け取るためのアクションを定義していきます。
この一連の制御が、アクション1つでできるところはZapierの非常に優れた点です。

  • App: Slack
  • Action event: Request Approval
  • Approval request message:
    以下のような感じで文章を作っていきます。
    この際、申請区分 や emailアドレス など、前段のトリガーやアクションで取得した値は、右上の[＋]ボタンでプレースホルダーとして埋め込むことができます。
  • Channel: 通知したいチャンネル

※その他は色々試してみて、お好みの設定を見つけてください。

設定が済んだら、Test ステップで下部の Test step をクリックします。
成功すると設定したチャンネルに以下のような通知が投稿されるはずです。

ここのワークフロー動作を説明すると、承認ボタンが押されるまでワークフローが一時停止した状態になり、後続のアクションは実行されません。(ちなみに、承認できるユーザーを限定することも可能です)
このフロー動作を利用して、未承認の変更がそのまま反映されるのを防ぐことができます。

いったん設定とテストは済んだので、下部の Continue をクリックして後続のアクションを作成していきます。

Makeの場合:
ワークフローの一時停止ができないため、Slackへの通知を行うワークフローと、承認ボタンが押されたことをトリガーに後続処理をする2つのワークフローに分ける必要があります。
また、ワークフローが分かれることでプレースホルダーの値が引き継げないため、DataStore機能などを利用してデータの引継ぎもする必要があります。

分岐処理: ユーザー追加と削除を分岐

今回は申請区分にユーザー追加と削除があり、それによって後続のアクションが変わってくるため、「Paths」という機能でフローを分岐させていきます。
Pathsを追加すると以下のようにフローが2つに分岐する形になるので、分岐後の Path conditions のブロックに、それぞれの分岐条件を設定していきます。
例えば今回の場合は、フォームの申請区分が「追加」か「削除」になっていることが、それぞれの分岐条件になります。

アクション: GitLabユーザーの追加/削除

あとは分岐先でそれぞれGitLabユーザーの追加、または削除のアクションを設定していきます。
ただし前回の他サービスとの連携でも少し触れたのですが、残念ながら現時点では、GitLabやGitHubに対するユーザー操作は標準機能で提供されていませんでした。
ただし、GitLabやGitHubではユーザー操作に関するAPIは提供されていますので、以下のような感じでリクエストBODYを定義して、APIを実行することで対応できると思います。
※今回は時間の都合上、実際には試していません

Makeの場合:
MakeでもGitLabやGitHubに対するユーザー操作は標準機能で提供されていません。

アクション: Slackへ完了通知

あとは仕上げとして、ユーザーの追加・削除が完了したことをSlackに通知します。
なお、Zapierは分岐後の合流ができない仕様なので、ちょっと面倒ですが分岐後の両方にこの完了通知のアクションを追加する必要があります。(完了通知するだけのサブワークフローを作り、それを呼び出すという手もあります)

  • App: Slack
  • Action event: Send Channel Message
  • Channel: 今回の場合は元の通知の投稿先と同じ
  • Message text: 前回と同様、プレースホルダーを使いながら以下のような感じで文章を作っていきます。
  • Thread: ここに投稿元のTs(Slackの投稿を一意に表す値)を指定することで、投稿元のスレッド返信にすることができます。(※右側の[...]ボタンをクリックしてCustomを選択すると、投稿元のTsを選択できるようになります)

※その他は色々試してみて、お好みの設定を見つけてください。

設定が済んだら、Test ステップで下部の Test step をクリックします。
成功すると投稿元のメッセージにスレッドとして返信されると思います。

あとは、このワークフローを保存してアクティブにすれば、その後は自動で動作するようになります。

Makeの場合:
Makeでは分岐後の合流が可能です。

例2: Slackの投稿内容を生成AIに渡して、プロンプトで処理した回答をもらう

次の例として、ここ数年進化が目覚ましい生成AIと連携するワークフローを作成していきたいと思います。

この利用法は、以下のようなメリットもあり、なかなか利便性の高いものだと思います。
　・いちいちChatGPTやGeminiなどの画面を開かずに、Slackからワンアクションで生成AIと連携できる
　・複数のユーザーが、共通のプロンプトを利用できる
　・普段から使っているSlack上で、生成AIの回答を元にしたコミュニケーションができる


トリガー設定: リアクション(reacji)を検知

ワークフローの起点として、先頭に以下のようなトリガーを作成します。

  • App: Slack
  • Trigger event: New Reaction Added
  • Conversation ID: 検知したいチャンネル
  • Reaction: 任意のreacji (今回は eyes を使用)

この状態で、検知したいチャンネルにある適当なメッセージに、:eyes:スタンプを押します。

その後、Zapier画面に戻り Test ステップで Find new records をクリックします。

そうすると下の方に新しい Reaction が表示されるので、そこをクリックしてみると、リアクションした投稿の内容が表示されるはずです。

これも先ほどのワークフロー同様、次のステップ以降で作成していくアクション内で必要となるため、サンプルデータを送信して、Zapierに認識させておきます。
認識させたら、下部の Continue with selected record をクリックして次に進みましょう。

Makeの場合:
前回記事にも書いた通り、リアクションをトリガーとしたワークフローがあるとクレジット数を大量に消費してしまう可能性があります。
また細かいですが、リアクション検知時にスタンプを押した投稿の Message Ts を受け取れないため、それを抽出するためのモジュールが追加で必要になるという点もあります。

アクション: 文字列を加工

※このアクションは、Zapier標準提供のChatGPT(OpenAI)連携やGemini連携を利用する場合は不要かも知れません。
当社環境では筆者にこれらのAPI Keyを直接利用する権限が無いため、APIリクエストを送る形で生成AI連携をしています(次のアクションで出てきます)。その関係で入力文の改行をここで削除する処理をしています。

  • App: Formatter by Zapier
  • Action event: Text
  • Transform: Replace
  • Input: 1.Message Text: (プレースホルダー)
  • Find: [:newline:] (改行を示す予約語)
  • Replace: (半角空白)

Makeの場合:
MakeでもAPIリクエストを送る形で連携する場合は、同様の機能(Text Parser)で文字列の加工が必要になります。

アクション: WebhookでAPIリクエスト送信

先ほども記載した通り、当社環境では権限の問題でOpenAIへのプロキシサービスへAPIリクエストを送る形で生成AI連携をしていますので、ここでAPIリクエストを送信します。

  • App: Webhooks by Zapier
  • Action event: Custom Request
  • Method: POST
  • URL: (OpenAIへのプロキシサービスのエンドポイントURL)
  • Action event: Custom Request
  • Data: 生成AIの振る舞いを示すSystemプロンプトと、入力となるUserプロンプトを、以下のような感じで定義します。
  • Headers:
    • Content-Type: application/json
    • Authorization: (OpenAIを利用するためのAPIキーを設定)

設定が済んだら、Test ステップで下部の Test step をクリックします。
成功すると以下のように生成AIの回答文が生成されると思います。
※ただし今回はテストで入力文が「てすとてすと」なので、少しおかしな回答になっていると思います。

アクション: Slackへ完了通知

あとは仕上げとして、生成された回答文をSlackに投稿します。

  • App: Slack
  • Action event: Send Channel Message
  • Channel: スタンプを押した投稿先と同じ
  • Message text: 3. Choices Message Content: (プレースホルダー)
  • Thread: ここにスタンプを押した投稿の Message Ts を指定することで、投稿元のスレッド返信にすることができます。(※右側の[...]ボタンをクリックしてCustomを選択すると、投稿元の Message Ts を選択できるようになります)

※その他は色々試してみて、お好みの設定を見つけてください。

設定が済んだら、Test ステップで下部の Test step をクリックします。
成功すると投稿元のメッセージにスレッドとして返信されると思います。

このワークフローも保存してアクティブにすれば、その後は自動で動作するようになります。
実際にそれっぽい文章に対してやってみると以下のようになりました。
※文章はAIで生成したサンプルで、会社名や名前は実在のものとは関係ありません。

その他 Zapier と Make を実際に使って感じた違い:
Makeでワークフローを編集していて一番使いづらさを感じた点として、モジュールの詳細を設定している最中に間違って[ESC]キーを押してしまうと、設定内容が全く保存されずに閉じてしまうという点がありました。これは地味にしんどかったです。

まとめ

学んだことの整理

今回の記事を通じて、Zapierによるワークフロー構築について、以下の点を学びました。

  • Zapierの Request Approval アクションを利用することで、フォーム申請後のSlack通知、承認待ちによるフローの一時停止、そして承認後の後続処理実行という一連の複雑な申請・承認フローを1つのワークフロー内で完結できる。
  • Slackのリアクション(Reacji)をトリガーとして設定することで、投稿内容を起点にした生成AIとの連携や、APIを利用した他サービスへの高度な連携が可能になる。
  • ZapierはシンプルなUIと直感的な設定が可能で、高機能なアクションも用意されている。さらに他サービス連携のための専用Slackアプリが提供されているなど、非エンジニアでも複雑な業務フローを比較的容易に構築できる。

今回の連載を通じて、Slackの標準機能では難しかった「緊密な連携」が、iPaaS、特にZapierによってノーコードである程度実現可能なことがお分かりいただけたかと思います。
Zapierは、Slackとの連携も容易なうえに、承認フローも1アクションで実現できるような高度な機能も用意されていたり、非エンジニアがすぐに業務効率化を始めるための大きな強みを持っています。
皆さんもぜひ、業務課題に合わせて最適なiPaaSを活用し、Slackなどをハブとしたストレスフリーな自動化に挑戦してみてください。

新規CTA