Slackワークフローは、ワークフロービルダーでトリガーとステップを組み合わせ、申請の受付や承認依頼といった定型作業をSlackの中で自動で回す機能です。この記事では、新規作成、フォームと承認ボタン、変数、条件分岐、Webhookでの起動、権限の設定までを画面の操作順に説明し、ビルダーで足りない処理をBolt for Pythonのカスタムステップで開発するコードと、開発へ進むかの判断基準を示します。仕様と数値は2026年10月時点のSlack公式ヘルプと開発者向けドキュメントで確認したものです。
まとめ：Slackワークフローの作り方はトリガー・フォーム・分岐の3つの設定で決まる
Slackワークフローの作り方は、どこから始めるか（トリガー）、何を入力させるか（フォーム）、入力や押されたボタンでどう道を分けるか（分岐）の3つを決めれば、残りは画面の指示に従うだけです。有料プランならメンバー全員が既定で作成でき、分岐だけはビジネスプラス以上のプランが必要です。
設定の段階で事故が起きやすいのは2か所です。WebhookトリガーのURLは知っている人なら誰でもワークフローを起動できるため秘密として扱うこと、コネクタの認証を作成者の認証情報で通すと利用者全員が作成者の権限で外部サービスを操作できてしまうことです。
社内システムへの書き込みが必要になったらカスタムステップを開発して部品として足し、承認経路が何通りにも分かれる・決裁の記録を監査に出すといった要件はSlackの外のワークフローシステムに持たせます。
Slackワークフローとは何かとワークフロービルダーで組める範囲と利用条件
トリガー・ステップ・変数・ボタンとワークフローマネージャーの役割
Slackヘルプセンターの「ワークフローを作成する」では、ワークフローを次の5つの要素で説明しています。作り始める前に、画面のどこで何を決めるかを対応づけておくと迷いません。
| 要素 | 役割 | 設定する例 |
|---|---|---|
| トリガー | ワークフローを始めるきっかけ | リンク・Webhook・スケジュール |
| ステップ | 実行する処理 | メッセージ送信・フォーム表示 |
| 変数 | 前の情報を後ろへ渡す | 開始した人へのメンション |
| ボタン | 押されるまで処理を止める | 承認・却下の受付 |
| ワークフローマネージャー | 編集・公開停止・削除の権限 | 作成者と保守担当 |
ステップはSlack内の操作、Googleスプレッドシートへの行追加のような外部サービスのコネクタ、開発者が作るカスタムステップの3種類です。前の2つは既定で全員が使え、カスタムステップを使えるのはそのアプリのコラボレーターです。部門ごとの使い方の例はSlackワークフローの業務別の使い方10例にまとめているので、この記事では組み立ての操作に絞ります。
有料プランが前提で条件分岐はビジネスプラス以上という利用条件
ワークフロービルダーは有料プランの機能です。既定では有料プランのメンバー全員（フロントラインメンバーを除く）が作成でき、作成のメニューが出ない場合は、オーナーや管理者がアクセスを制限しています。
条件分岐はさらに条件が厳しく、ヘルプセンターの「ワークフローに分岐を追加する」では、ワークスペースがビジネスプラスの新しいバージョンで動いていることを求めています。対象はビジネスプラスプランとエンタープライズ向けプランで、プロプランは対象外です。ビジネスプラスなのに分岐が見当たらない場合は、Slackのサポートへの連絡が案内されています。
作る前に、自社のプランと、管理者がワークフローの作成やコネクタの追加を制限していないかを情シスに確かめてください。
ワークフロービルダーでフォーム付きの申請ワークフローを作る手順
エージェントとツールから新規作成しリンクのトリガーを選ぶ操作
例として、備品購入の申請をフォームで受け、承認者へボタン付きのメッセージを送るワークフローを作ります。最初の画面操作は次のとおりです。
- デスクトップ版のサイドバーで「エージェントとツール」を開く（表示されない場合は「ツール」、または「その他」の中を探す）
- 「ワークフロー」の右上にある「新規」から「ワークフローを構築する」を選ぶ
- 「ワークフローを開始する」の「イベントを選択する」で「リンクから」を選び、「次へ」で進む
トリガーは7種類あり、申請のように人が自分の都合で始めるものはリンクが向きます。リンクで始めるワークフローはSlackの中でしか開始できず、Slackの外でリンクを押しても動きません。社内ポータルから起動させたい場合は、後述のWebhookトリガーを使います。
フォームで申請内容を集め承認者へボタン付きメッセージを送る設定
トリガーを決めたら「ステップを追加」で処理を並べます。備品購入の申請なら、次の順で3つのステップを置きます。
- フォームを表示するステップで、品名・金額・購入理由・希望納期を質問として並べる
- 承認者へメッセージを送るステップで、フォームの回答を本文に差し込み、「承認」と「却下」のボタンを付ける
- ボタンが押された後に、申請者へ結果を送り受付チャンネルへ記録を残す
ボタンは「ボタンを追加する」から作り、「動作」のドロップダウンで続行・別のワークフローの開始・リンクを開くのどれかを選びます。承認ボタンでは「シングルクリック」をオンにして、1人が押したら無効になるようにしてください。「詳細設定」では押せるメンバーを限定でき、有効期限を設定すると指定の日時にボタンが無効になります。押せる人を承認者に絞らないと、申請者が自分で承認を押せてしまいます。
チャンネルへ投稿するステップは、作成者自身にそのチャンネルの投稿権限が無いと設定できません。
変数の挿入で申請者のメンションとフォームの回答を後ろへ渡す方法
変数は、前のステップで得た情報を後ろのステップへ差し込む仕組みです。ステップの設定画面で「変数を挿入する」（括弧のアイコンだけの場合もある）を押し、一覧から選ぶと、実行時に実際の値へ置き換わります。
使える変数は、それまでにワークフローへ渡された情報で決まります。「このワークフローを使用した人」を承認者へのメッセージに入れると申請者へのメンションになり、結果を返すメッセージの宛先に使えば申請者ごとに送り先が変わります。
フォームより前のステップでは、フォームの回答は一覧に出てきません。使いたい情報を集めるステップを先に置きます。
条件分岐を設定して承認・却下や金額別に後続の処理を振り分ける手順
ユーティリティの分岐を追加から条件を選び最大15分岐を組む操作
分岐を使うと、承認なら発注手順を送り、却下なら理由の入力を求める、といった振り分けができます。
- 分岐を入れたい位置で「ステップを追加」を押す
- サイドバーの「ユーティリティ」から「分岐を追加」を選ぶ
- 「次を満たす時のみ続行 :」で、どのボタンが押されたか・フォームでどの回答が選ばれたかといった条件を選ぶ
- 必要なら分岐に名前と色を付けて「保存」し、その分岐の中にステップを足す
ヘルプセンターの記載では、1つのワークフローに追加できる分岐は最大15個です。フォームで分岐させる場合は、回答を自由記述ではなく選択式の質問にしておかないと、条件として選べません。金額で分けたいときも「5万円未満／5万円以上」のような選択肢を用意します。
ネストは5つまでで3段目は組めない制約と代替手段の分岐の置き方
分岐の中にさらに分岐を入れるネストは、プライマリ分岐の下に最大5つまでです。ネストした分岐の下にもう一段入れることはできません。つまり「部署で分け、その中で金額で分け、さらに品目で分ける」という3段の判定は、ビルダーでは組めません。
どの条件にも当てはまらないときに進む「代替手段」の分岐も用意し、管理者へ「未対応の回答が来た」と知らせるメッセージを送らせます。選択肢を後から足して分岐を足し忘れた申請が、どこにも進まず止まるのを防げます。
3段目が必要になった時点が、ビルダーで組める承認経路の上限です。
Webhookトリガーで外部システムからワークフローを起動する設定例
カスタム変数を定義してhooks.slack.comへPOSTするcurlの例
監視ツールや社内システムからワークフローを始めたいときは、トリガーで「Webhookから」を選びます。ヘルプセンターの「Slack外部で開始されるワークフローを作成する」によると、変数は最大20個まで定義でき、型はチャンネルID・ユーザーID・ユーザーのメール・テキストの4種類から選ぶ形式です。ワークフローを公開すると、https://hooks.slack.com/triggers で始まる固有のリクエストURLが発行されます。
障害報告を起票するワークフローで、user（ユーザーID型）、severity と incident_description（テキスト型）の3つの変数を定義した場合、外部から送るリクエストは次の形になります。
curl -X POST "https://hooks.slack.com/triggers/T00000000/0000000000000/xxxxxxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"user": "U0123ABCD",
"severity": "高",
"incident_description": "注文APIの応答が5秒を超えています"
}'JSONのキーはビルダーで定義した変数名と一致させます。定義した変数が1つでも欠けるとワークフローは失敗し、入れ子のJSONは変数として受け取れないため、監視ツールの送信形式が入れ子なら間に変換の処理を挟みます。
1秒1リクエストの上限とURLを知る人が誰でも起動できる点の対処
Webhookのワークフローは1秒につき1リクエストに制限されています。監視ツールは障害時に同じアラートを連続送信しがちなので、送信元でまとめるか再送を抑止し、1秒1件を超えない設計にします。
もう1つの注意点は起動できる人の範囲です。ヘルプセンターは、リンクを持つユーザーであれば誰でもワークフローを開始できるとして、リクエストURLを常に安全に保持するよう求めています。URLはパスワードと同じ扱いで秘密管理の仕組みに置き、ソースコードやチャット、チケットに貼らないでください。オーナーと管理者は、Webhookでワークフローを作れるメンバーを制限できます。
決まった文面の通知をチャンネルへ送るだけなら、ワークフローを挟まずIncoming Webhookで足ります。違いと送信コードはSlack Incoming Webhookの実装手順で扱っています。
ワークフローの権限設定と公開後の管理で事故を防ぐための設定項目
見つけて使える人・コピーできる人・マネージャーを決める設定画面
公開前に、右上の3つのドットアイコンから「設定」を開き「編集」で権限を決めます。既定では、ワークスペースまたはOrGのすべてのメンバーがワークフローを見つけて使え、コピーできるのはワークフローマネージャーだけです。
- 「誰がこのワークフローを見つけて使用できますか？」のドロップダウンで、利用できる範囲を選ぶ
- 「このワークフローは誰がコピーできますか？」で、複製して改変できる人を決める
- 「ワークフローマネージャー」に保守の担当者を追加し、作成者と同じ編集権限を持たせる
マネージャーを作成者1人のままにすると、作成者の不在時に誰も編集も公開停止もできません。Slackコネクトの社外の人に使わせるには「つながっている外部のオーガナイゼーションも検索と実行に含める」にチェックを入れ、管理者側でも外部の人による実行を許可しておく必要があります。
コネクタの認証を作成者の認証情報で通すと利用者全員に広がる権限
Googleスプレッドシートやカレンダーなどのコネクタステップは、外部サービスのアカウントを認証しないと動きません。このとき作成者は、ワークフローを使う各メンバーに本人のアカウントで認証させるか、作成者自身の認証情報で実行させるかを選べます。
作成者の認証情報で実行させると、利用者は自分にアクセス権の無いスプレッドシートにも作成者の権限で書き込めます。全社公開のワークフローなら、作成者の権限を全員に貸し出すのと同じです。書き込み先は申請記録用のシートだけに分けてください。
アプリの承認が有効なワークスペースでは、コネクタやカスタムアプリの追加にも管理者の承認が要るため、作る前に申請しておきます。
フォームの回答をCSVでダウンロードしAPIで書き出すまでの手順
フォームで集めた回答は、ワークフローの作成者とマネージャーがCSVでダウンロードできます。ヘルプセンターの「ワークフローのフォーム形式の回答をダウンロード」の手順では、「エージェントとツール」の「ワークフロー」から「あなたが管理」を開き、鉛筆アイコンでビルダーを開いて、3つのドットアイコンの「フォーム形式で回答をダウンロードする」を選びます。ファイルのリンクの受け取り先はDMです。
開発者が作ったワークフローでは、APIで書き出します。functions.workflows.steps.list でフォームを含むステップを一覧し（フォームの組み込み関数OpenFormのfunction_idはFn010N）、控えたstep_idを functions.workflows.steps.responses.export に渡す流れです。CSVの送信時刻の末尾にあるZはUTCを表すため、日本時間で集計するなら9時間ずらします。
ビルダーで足りない処理をカスタムステップとして開発する実装手順
Manifestでカスタムステップの入力と出力を宣言する設定例
ビルダーの部品に無い処理、たとえば社内のチケット管理システムへの起票は、カスタムステップとして作ってビルダーに足します。Slack開発者ドキュメントのWorkflow stepsによると、カスタムステップはアプリに定義する関数で、Boltで作れば自社のサーバーで動かすSelf-hosted、Deno Slack SDKで作ればSlack上で動かすSlack-hostedになります。
Boltで作る場合は、アプリ設定のApp Manifestに、イベントfunction_executedの購読と、ステップの入出力を宣言します。申請者と件名を受け取り、起票したチケット番号を返すステップの例です。
settings:
event_subscriptions:
bot_events:
- function_executed
socket_mode_enabled: true
functions:
create_ticket:
title: 社内チケットを起票
description: 申請内容から社内のチケット管理システムへ起票する
input_parameters:
requester:
type: slack#/types/user_id
title: 申請者
is_required: true
name: requester
summary:
type: string
title: 件名
is_required: true
name: summary
output_parameters:
ticket_id:
type: string
title: チケット番号
is_required: true
name: ticket_idアプリ設定の「Workflow Steps」の「Add Step」から画面で作っても、内容はManifestに反映されます。キーのcreate_ticketが次のコードのcallback_idになり、output_parametersの値はビルダーで後ろのステップの変数として選べます。
Boltのapp.functionで起票しcompleteかfailを返すコード
PyPIのslack-boltは2026年10月時点で1.30.0（2026年7月15日公開・Python 3.7以上）が最新です。Bolt for Pythonのカスタムステップの解説では、app.function()にcallback_idを渡してリスナーを登録し、処理の最後に必ずcomplete()かfail()を呼ぶよう定めています。Socket Modeのアダプタを含むフレームワーク本体はGitHubのbolt-pythonリポジトリで公開されています。
import json
import os
import urllib.request
from slack_bolt import App
from slack_bolt.adapter.socket_mode import SocketModeHandler
app = App(token=os.environ["SLACK_BOT_TOKEN"])
@app.function("create_ticket")
def create_ticket(inputs, complete, fail, logger):
try:
payload = {"requester": inputs["requester"], "summary": inputs["summary"]}
req = urllib.request.Request(
os.environ["TICKET_API_URL"],
data=json.dumps(payload).encode("utf-8"),
headers={
"Content-Type": "application/json",
"Authorization": f"Bearer {os.environ['TICKET_API_TOKEN']}",
},
method="POST",
)
with urllib.request.urlopen(req, timeout=10) as res:
ticket_id = str(json.load(res)["id"])
# outputs のキーは Manifest の output_parameters と一致させる
complete(outputs={"ticket_id": ticket_id})
except Exception as e:
logger.exception("チケットの起票に失敗")
fail(f"チケットの起票に失敗しました: {e}")
if __name__ == "__main__":
SocketModeHandler(app, os.environ["SLACK_APP_TOKEN"]).start()completeもfailも呼ばずに終わると、ワークフローはそのステップで止まったままになるため、例外の経路でもfailの呼び出しが必須です。ボタンで人の操作を待つステップでは、function側ではcompleteを呼ばず、ボタンのアクションを受けるリスナーの中で呼びます。トークンの種類やSocket Modeでの起動手順はSlack APIとは？Web API・Events API・Boltの違いと実装手順で整理しています。
Freeプランでは開発できず公開配布もできないカスタムステップの制約
Workflow stepsのドキュメントにある制約のうち、設計前に確かめたいのは次の4点です。
- Freeプランではカスタムステップを開発できない
- コードで書いたワークフロー全体はビルダーへ持ち込めず、持ち込めるのはステップ単位の関数だけ
- 公開配布とSlack Marketplaceへの掲載はできず、単独のワークスペースでは同じワークスペースにだけインストールして使う
- Slackコネクトでつながる社外ユーザーは、自社が作ったコネクタステップやカスタムステップを含むワークフローを使えない
Enterpriseのオーガナイゼーションでは、アプリをorg-readyにして組織レベルでインストールし、1つ以上のワークスペースへアクセスを付与しないと、ビルダーにステップが出てきません。取引先と共同で使う受付フローに社内システム連携を足す計画は、4点目の制約で成り立ちません。
ワークフロービルダーで済ませるかAPIの開発へ進むかを決める判断基準
ノーコードのまま運用してよい3条件と開発を見送る失敗パターン
次の3条件をすべて満たすなら、ワークフロービルダーのまま運用して構いません。
- 承認が1段か2段で、分岐のネストが5つ以内に収まる
- 書き込み先がSlackのリストやスプレッドシートなど、標準のステップかコネクタで届く場所にある
- 利用者が社内メンバーだけで、社外のSlackコネクト参加者に使わせない
反対に、「1つのワークフローに全部の承認経路を入れたい」という理由だけでカスタムステップを作るのは見送ります。分岐の上限を超える判定をコードへ逃がしても、規程が変わるたびに開発者の手が要る状態になるだけです。話しかけて答えさせる双方向の処理が欲しいなら、ワークフローではなくSlack Botの作り方のようにBotを組む方が向いています。
社内システムへの書き込みや決裁の記録が要るときの開発範囲と構成
カスタムステップの開発が見合うのは、Slackの受付画面はそのままに、裏側で社内システムを読み書きしたいときです。社員マスタから承認者を引く、承認後に基幹システムへ発注データを登録する、といった処理です。Bolt製のステップは自社でホスティングするため、開発範囲は関数と、それを動かす常駐プロセスかサーバーレス環境の運用までになります。
一方、部署や金額や品目で承認者が何通りにも変わる、代理承認や差し戻しの規程がある、承認履歴を監査に提出するといった要件は、Slackワークフローに載せない判断をします。決裁はワークフローシステムに持たせ、Slackは申請の入口と通知の窓口に回す構成です。製品の選び方はワークフローシステムとはで比較しています。既製品で自社の承認規程に合わない場合や、Slackの受付と社内システムを一体で作り直したい場合は、ワークフローシステム開発として承認経路の整理から相談できます。
よくある質問
Slackワークフローの作り方や設定でよく出る質問に、2026年10月時点のSlackヘルプセンターの記載をもとに答えます。
Slackワークフローは無料プランでも使えますか？
ワークフロービルダーは有料プランの機能で、カスタムステップの開発もFreeプランではできません。プロプランでもワークフローの作成とフォーム・ボタン・コネクタは使えますが、条件分岐はビジネスプラス以上が対象で、申請の種類ごとにワークフローを分ければ分岐なしで運用できます。
条件分岐の「分岐を追加」が表示されないのはなぜですか？
主な原因はプランです。分岐はビジネスプラスの新しいバージョンとエンタープライズ向けプランでのみ使えるため、プロプランではユーティリティの一覧に出てきません。ビジネスプラスなのに出ない場合はSlackのサポートへの連絡が案内されています。フォームの回答で分岐させる場合は、その質問を選択式にしてください。
Slackワークフローの回答をスプレッドシートに自動で記録できますか？
できます。Googleスプレッドシートのコネクタステップをフォームの後ろに置き、行を追加する設定にすると、回答を列ごとに書き込めます。最初にGoogleアカウントの認証が必要で、全社で使うワークフローを作成者の認証情報で動かす場合は、書き込み先を記録専用のシートに分けてください。
Webhookトリガーのワークフローと Incoming Webhook は何が違いますか？
どちらも外部からURLへPOSTしますが、Incoming Webhookは決めたチャンネルへメッセージを1件送るだけです。Webhookトリガーのワークフローは、受け取った値を変数として承認ボタンや分岐など後続のステップへ渡せる代わりに、有料プランが必要です。通知だけならIncoming Webhook、担当者の受付ボタンを付けて対応を記録したいならワークフロー、と分けます。
ワークフローを作れる人やWebhookを使える人を情シスだけに絞れますか？
絞れます。Slackワークフロービルダーガイドでは、管理者がワークフロービルダーへのアクセス権、メンバーが追加できるコネクタステップとカスタムステップ、社外のオーガナイゼーションでの利用可否を管理できると説明しています。Webhookでワークフローを作れるメンバーも別途制限できるため、作成は全員に開放し、Webhookと外部コネクタだけを情シスに限る分け方が現実的です。
関連記事
- スラッシュコマンドとは？Slackでカスタムコマンドを自作する手順と3秒ルール：決まった操作をコマンドで呼び出す場合の受付の作り方
- iPaaSとは？仕組み・RPAとの違い・料金の数え方と導入判断：コネクタに無いSaaS同士をSlackの外でつなぐ場合の選択肢
- AWS Lambdaとは？仕組み・料金体系とコールドスタート対策：Bolt製のカスタムステップをサーバーレスで動かす場合の基盤
