Slackを仕事で使っていると、依頼がDM、チャンネル投稿、口頭連絡に散らばりやすくなります。
内容が同じでも書き方が毎回違うと、担当者は「期限は？」「対象は？」「優先度は？」と聞き直すことになります。
Slack Workflow Builderを使うと、受付フォーム → チャンネル通知 → 後続リマインドという定型フローをSlack内で作れます。
情報の基準日：2026年8月11日
Workflow Builderの利用条件、画面、開始条件、コネクタ、外部連携機能は変更される場合があります。設定前にSlack公式Workflow Builderガイドを確認してください。
先に結論：依頼の入口を1つにするだけでも効果がある
最初から複雑な自動化を作る必要はありません。
たとえばWeb更新依頼なら、次のようにします。
- Workflow Builderのフォームから依頼
- 必須項目を同じ形式で取得
#web-requestに自動投稿- 担当者がリアクションやスレッドで着手を宣言
- 一定時間後または期限前に確認用リマインド
- 完了報告は人が行う
これだけでもDMに埋もれる依頼を減らせます。
Workflow Builderでできること
Slack公式では、Workflow Builderを日常的な業務を自動化するノーコード機能として案内しています。
代表的な使い方には、フォームでの情報収集や繰り返しリマインドがあります。
ワークフローの開始方法は、リンク、スケジュール、絵文字リアクション、チャンネル参加など複数あります。利用できる開始条件やステップはワークスペースの設定やプランによって異なります。
受付→担当通知→リマインドの簡単な使い方【2026年8月時点】
1. 受付対象を1種類に絞る
最初は「サイト修正依頼」「記事確認依頼」「経費確認」など1種類だけ作ります。
複数業務を1フォームへ詰め込むと、入力項目が増えて使われにくくなります。
2. フォーム項目を決める
Web修正依頼なら次の程度から始めます。
- 依頼タイトル
- 対象URL
- 依頼内容
- 希望期限
- 緊急度
- 補足
「担当者」は依頼者が決めるより、受付後にチーム側で決めるほうが安全な場合があります。
3. Workflow Builderでフォームを作る
SlackのWorkflow Builderを開き、テンプレートまたは新規ワークフローから開始します。
フォームステップを追加し、先ほど決めた項目を設定します。
入力必須にする項目は、本当にないと作業できない情報だけに絞ります。
4. 受付内容を専用チャンネルへ投稿する
フォーム送信後に、回答内容を #request などの専用チャンネルへ投稿するステップを追加します。
投稿には次を含めます。
- 依頼者
- タイトル
- 対象
- 期限
- 詳細
フォーム回答全文をそのまま広いチャンネルへ出すのではなく、機密情報や個人情報を含む場合は通知先を限定します。
5. 担当開始ルールを決める
自動で担当者を確定する前に、チームで簡単なルールを決めます。
例：
- 👀 リアクション = 確認中
- 🙋 リアクション = 担当します
- ✅ リアクション = 完了
リアクションを開始条件にできる環境では、後続ワークフローへつなげることもできます。
6. リマインドを追加する
毎週の確認や期限前確認など、定型のリマインドを追加します。
ただし、すべての依頼を同じ間隔で通知するとノイズになるため、最初は「未処理一覧を毎朝確認する」程度でも十分です。
7. 実際の依頼を1件流して確認する
公開前に次をテストします。
- フォームの項目が分かりやすいか
- 通知先チャンネルが正しいか
- 非公開情報が見えていないか
- メンションが多すぎないか
- スマートフォンからも入力できるか
- リマインドが重複しないか
フォーム回答は後から確認・ダウンロードできる
Slack公式では、Workflow Builderで作成したフォーム回答を管理画面からダウンロードできる手順を案内しています。
長期的な集計が必要なら、Slack内だけに情報を閉じず、必要に応じて台帳へ整理する設計も検討します。
ただし、外部スプレッドシートやCRMへ自動転送する場合は、コネクタの権限と送信先を確認してください。
Workflow Builderの利用条件
Slack公式ガイドではWorkflow Builderは有料プランで利用できる機能として案内されています。
契約中プラン、管理者設定、利用できるコネクタやカスタムステップによって、作れるワークフローは変わります。
画面にWorkflow Builderがない場合は、Tools または Automations の表示と、ワークスペース管理者の設定を確認します。
Slack Connectでは公開範囲を確認する
外部企業と共有しているSlack Connectチャンネルでワークフローを使う場合、社内だけの情報が外部参加者に見えないか確認します。
Slack管理者は、外部組織がワークフローを利用できるかなどの設定を管理できます。
受付チャンネルは、必要なメンバーだけが参加する社内チャンネルへ分ける方法が安全です。
自動化しないほうがよい部分
担当者の最終決定
案件の難易度や稼働状況によって担当を変えるチームでは、人が確認して割り当てるほうが現実的です。
外部顧客への返信
フォーム内容だけで顧客返信を自動送信せず、まず社内通知までに留めます。
削除・公開・権限変更
ファイル削除、公開設定変更、アカウント権限変更など不可逆性の高い操作は、別の確認ステップを設けます。
通知疲れを防ぐ設計
自動化を増やすと、今度はSlack通知が増えすぎる問題が起きます。
次の順番で減らします。
- 受付チャンネルを分ける
- 全員メンションを避ける
- 担当者だけに通知する
- 毎回通知ではなく定時まとめにする
- 完了済み案件にはリマインドしない
「通知を増やす自動化」ではなく、「確認先を1つにまとめる自動化」を目指します。
向いている人
- Slack内で依頼が散らばっている
- 聞き返す項目が毎回ほぼ同じ
- 複数人で受付を担当している
- 定例の確認やリマインドが多い
まだ不要な人
1人でSlackを使っていて依頼数も少ない場合、Workflow Builderを作るより、固定メッセージやCanvasに受付テンプレートを置くだけで足りることがあります。
まとめ
Slack Workflow Builderは、「人の仕事を全部自動化する」より、依頼の入口と通知形式を揃える用途から始めると扱いやすいです。
最初の形は次で十分です。
- フォームで受付
- 専用チャンネルへ通知
- 人が担当を決める
- 定型リマインドだけ自動化
この流れが安定してから、外部アプリ連携や追加ステップへ広げてください。
次に読む記事
今のテーマから次の行動へ進むときは、以下の記事も参考にしてください。
- Slack以外も含めて業務自動化を広げる — フォーム・メール・スプレッドシートなど複数サービスをつなぎたい人向けです。