2026.10.23 業務システム

Slackワークフローの業務別の使い方10例：申請・日報・問い合わせ受付の組み方と限界

Slackのワークフロービルダーを使うと、休暇申請の承認依頼、営業日報の回収、社内問い合わせの振り分けといった定型の依頼を、コードを書かずにSlackの中で回せます。ただし、承認の段数が増えたり監査で証跡を求められたりすると、Slackだけでは手に負えない場面もあるため、適用範囲の見極めが必要です。この記事では、総務・人事・営業・情シス・経理の10例をトリガーとステップの組み合わせで整理し、主な4例の組み方を公式ヘルプの仕様に沿って説明します。後半では、Slackワークフローで行き詰まる4つの場面と、ワークフローシステムの導入や開発へ切り替える判断基準を示します。

まとめ：Slackワークフローは依頼の受付と通知に使い、決裁の記録は別の仕組みへ

Slackワークフローが力を発揮するのは、「誰かがフォームで依頼し、担当者がボタンで受けて、結果を本人とチャンネルに知らせる」という1〜2段の流れです。休暇申請、備品の購入依頼、日報、問い合わせ受付、障害の一次報告がこの形に収まります。有料プランなら追加費用なしで始められ、業務部門の担当者が自分で作り直せる点も強みです。

反対に、金額や部署で承認者が変わる多段の決裁、規程に沿った代理承認、監査で提出する承認履歴の保管は、Slackワークフローに載せないでください。その部分はワークフローシステムか社内システムに持たせ、Slackは依頼の入口と通知の窓口に回すのが、後から作り直さずに済む分担です。社内システムへの書き込みまでSlackから行いたい場合は、カスタムステップの開発が選択肢になります。

Slackワークフローで自動化できる範囲：トリガー7種とステップ3種類の組み合わせ

使い方の例を見る前に、ワークフローがどの部品でできているかを押さえておくと、自社の業務に当てはめやすくなります。

トリガー・ステップ・変数・ボタンの4部品と有料プランで使える条件

Slackヘルプセンターの「ワークフローを作成する」によると、ワークフローは開始のきっかけになるトリガー、実行するアクションであるステップ、前のステップの情報を後ろへ渡す変数、押されるまで処理を止めるボタンで組み立てます。既定では有料プランのメンバー全員が作成でき、作成のメニューが見えない場合は、オーナーや管理者がアクセスを制限しています。

トリガーは次の7種類から選びます。

リンクから（「ワークフローを開始」ボタンを押して始める）
Webhookから（外部のシステムからの通知で始める）
スケジュールにもとづく（日時と頻度を指定）
リスト項目が更新された時
指定したキーワードを含むメッセージが投稿された時
誰かがチャンネルに参加した時
指定した絵文字リアクションが使用された時

ステップは3種類あります。メッセージ送信などSlack内の操作、Googleスプレッドシートへの行の追加のような他社サービスへのコネクタ、そして開発者が自社向けに作るカスタムステップです。前の2つは既定で全員が使え、カスタムステップを使えるのはアプリのコラボレーターです。部門別の例は、この組み合わせの違いとして読むと整理しやすくなります。

2025年8月の条件分岐対応で組めるようになった最大10条件の振り分け

以前のワークフローは一本道で、問い合わせの種類によって送り先を変えるには、種類ごとに別のワークフローを作る必要がありました。Slack公式ブログの2025年8月8日の発表で、ワークフロービルダーは条件分岐に対応しました。条件は最大10個まで設定でき、メッセージには最大5つの継続ボタンを置いて、押されたボタンごとに別の分岐へ進めます。

同じ発表では、Salesforceを含む70以上のアプリにコネクタが用意されていると説明されています。「承認」「却下」「差し戻し」の3ボタンを並べ、押されたボタンで後続の処理を変える、という承認の基本形がコードなしで組めるようになったのは、この時点からです。分岐の追加方法はヘルプセンターの「ワークフローに分岐を追加する」にあり、ステップの追加画面のユーティリティから選びます。

部門別のSlackワークフロー使い方10例：トリガーとステップの組み合わせ

ここからは、部門ごとの使い方の例を具体的な組み合わせで示します。まず全体を表で見てから、組み方に注意が要る4例を掘り下げます。

総務・人事・営業・情シス・経理の10例をトリガーとステップで比べる表

10例を、使うトリガーと主なステップ、担当部門で並べます。上ほど作りやすく、効果も見えやすい例です。

部門	使い方の例	トリガー	主なステップ
総務・人事	休暇・時間休の申請	リンクから	フォーム・上長へDM・承認ボタン
総務	備品の購入依頼	リンクから	フォーム・承認ボタン・チャンネル投稿
営業	営業日報の回収	スケジュール	フォーム・リストへ記録
全部門	週次の進捗確認	スケジュール	フォーム・まとめてチャンネル投稿
情シス	社内問い合わせの受付	リンクから	フォーム・条件分岐・担当チャンネル投稿
情シス	アカウント発行の依頼	リンクから	フォーム・承認ボタン・担当者へDM
人事	入社者への案内	チャンネル参加	案内のDM・資料のリンク送付
開発・情シス	障害の一次報告	Webhookから	チャンネル投稿・担当者メンション
経理	請求書の発行依頼	リンクから	フォーム・経理チャンネル投稿・担当ボタン
全部門	対応済みの記録	絵文字リアクション	リストやスプレッドシートへ転記

表のうち、承認ボタンを含む例は「1段の承認で済むか」を先に確かめてください。2段以上になる業務は、後述の限界の章に当たる可能性があります。

休暇・備品購入の申請を上長の承認ボタンで回す総務・人事の組み方

申請系の基本形は、リンクから開始し、フォームで日付や理由を入力してもらい、上長へ承認ボタン付きのメッセージを送る流れです。宛先の上長はフォームの選択項目にするか、申請者が指名します。結果は変数を使って申請者にDMで返し、総務のチャンネルにも記録として投稿します。

ボタンの設定で事故を防げます。公式ヘルプでは、1人が押した後にボタンを無効にする「シングルクリック」、押せるメンバーの限定、指定日時でボタンを無効にする有効期限が設定できると説明されています。上長以外が承認を押せる状態や、2人が同時に押して二重承認になる状態を防ぐには、この3つの設定が必要です。承認待ちを放置させない工夫は承認を止めないリマインドと催促の設計の考え方がそのまま使えます。

営業日報をスケジュール起動のフォームで集めてリストに残す手順

日報は、毎営業日の17時などにスケジュールで起動し、営業担当者へフォームを送って回収します。訪問件数、商談の進捗、翌日の予定のように項目を固定するのは、自由記述の日報より読み手が内容を比べやすくするためです。回答はSlackのリストに1行ずつ記録するか、コネクタでGoogleスプレッドシートに追記します。

回収の結果はフォームの回答としてダウンロードでき、作成者とワークフローマネージャーは実行の履歴やエラーも画面で確認できます（ワークフロービルダーガイドより）。集計まで自動化したくなったら、スプレッドシート側の関数かBIツールに任せ、ワークフローは回収だけに留めるほうが壊れにくい構成です。

社内問い合わせを種類別に担当チャンネルへ振り分けるヘルプデスク

情シスや総務への問い合わせは、DMや雑談チャンネルに散らばると、誰が受けたのか分からなくなります。問い合わせ用のワークフローを1本用意し、フォームの「種類」の選択肢で条件分岐させると、PCやアカウントの件は情シスのチャンネル、請求の件は経理のチャンネルへ届きます。この振り分けは、公式ブログでも例として示されている構成です。

受け付けた側は「対応します」ボタンを押して担当を明示し、押した人の名前を変数で依頼者に返します。担当の偏りや未対応の件数を見たい場合は、絵文字リアクションをきっかけにリストへ「対応済み」を記録しておくと、後から件数を数えられます。月に数百件を超えて対応時間の管理まで求められるなら、問い合わせ管理ツールへの移行を検討する段階です。

監視ツールのWebhookで障害報告を起票する開発・情シスの組み方

トリガーの「Webhookから」を選んでワークフローを公開すると、そのワークフロー専用のリクエストURLが発行されます。Slack外部で開始されるワークフローのヘルプによると、URLは https://hooks.slack.com/triggers で始まり、外部から送るデータを後続のステップで使う際の変数の上限は、最大20個です。監視ツールのアラートをこのURLへ送るように設定すれば、障害チャンネルへの投稿、当番へのメンション、「対応開始」ボタンの表示までを1本のワークフローで済ませられます。

送る側の設定は、変数のキーと同じ名前を持つJSONをPOSTするだけです。動作確認は次のようなリクエストで行えます。

curl -X POST "https://hooks.slack.com/triggers/（発行されたURLの残り）" \
  -H "Content-Type: application/json" \
  -d '{"severity": "高", "incident_description": "決済APIの応答が5秒を超過"}'

ヘルプには注意点が3つ書かれています。変数に入れ子のJSONは使えないこと、Webhookのワークフローは1秒に1リクエストまでに制限されること、URLを知っていれば誰でも起動できるため秘密として扱うことです。アラートが一度に大量に出る監視ツールでは、送る前に集約する設定を入れておかないと取りこぼしが起きます。

単にメッセージを投稿したいだけなら、ワークフローを使わずIncoming Webhookで十分です。送り方の違いと実装はSlack Incoming Webhookの実装手順で扱っています。ワークフローを選ぶ理由は、投稿の後にボタンで担当を決めたり、対応結果をリストへ残したりといった後続の手順を持たせたい場合に限られます。

Slackワークフローで申請・承認を回すときの限界：行き詰まる4つの場面

手軽に作れる反面、業務の要件が増えると無理が出ます。導入前に知っておきたいのは次の4つの場面です。

多段承認と金額別の経路が増えると分岐10条件で管理しきれない理由

「5万円未満は課長、50万円未満は部長、それ以上は役員」のような金額別の経路は、分岐を使えば組めます。ただし部署ごとに承認者が違い、さらに代理承認や差し戻し後の再申請まで加えると、分岐とボタンの組み合わせはすぐに膨らみます。条件の上限が10個である以上、部署数×金額帯の経路を1本のワークフローで表すことはできません。

もう1つの問題は承認者の持ち方です。ワークフローの中に上長の名前を固定で書くと、人事異動のたびに全ワークフローを手で直すことになります。組織と役職から承認者を自動で決める仕組みは、ワークフローシステムが持つ機能です。承認経路の考え方は承認フローの仕組みとシステム化の判断基準で整理しています。

ワークフローの作成者が異動・退職すると保守できなくなる所有者問題

ワークフローを作った人は自動でワークフローマネージャーになり、編集・公開停止・削除の権限を持ちます。業務部門の担当者が1人で作り、マネージャーを追加しないまま異動すると、手順を変えたくても直せる人がいない状態に陥ります。公開前に、同じ部署の2人目と情シスの担当者をマネージャーへ加えておくのが最低限の備えです。

コネクタのステップでも、認証情報の引き継ぎは確認が必要です。公式ヘルプでは、他社サービスの認証を各メンバーにさせるか、作成者の認証情報を使うかを作成者が選べるとされています。作成者の認証情報を使う設定は利用者には楽ですが、作成者のアカウントに依存するため、退職の手続きより前に付け替えておく必要があります。

承認の証跡を監査で求められたときにSlackの記録だけでは足りない場面

Slackワークフローでも、フォームの回答はダウンロードでき、実行の履歴も画面で確認できます。しかし、決裁番号の採番、規程のどの条項に基づく承認かの記録、承認後に内容が書き換えられていないことの保証といった、監査で問われる要素は持っていません。メッセージの保持期間もワークスペースの設定次第で変わります。

稟議や支払申請のように、後から第三者に「誰がいつ何を承認したか」を示す必要がある申請は、Slackに載せないと決めてください。証跡に残す項目と保存の考え方は操作ログに残す項目と保存年限の解説にまとめています。

Slackコネクトの社外メンバーがコネクタやカスタムステップを使えない制約

取引先とSlackコネクトでつながっている場合、外部の人にもワークフローを使ってもらえる設定はあります。ただしSlack開発者ドキュメントのワークフローステップの解説には、自社が作ったコネクタステップやカスタムステップを含むワークフローは、自社の組織外のユーザーが使えないと書かれています。

そのため「取引先がフォームで発注し、自社のスプレッドシートへ記録する」といった社外を含む流れは、そのままでは組めません。社外向けの受付は、Webフォームなど自社側のシステムで受け、Slackには社内向けの通知だけを流す設計に切り替えます。

ワークフローシステム導入・受託開発へ切り替える判断基準と構成

限界に当たったときの選択肢は、Slackワークフローを続ける、カスタムステップを開発する、ワークフローシステムを入れるの3つです。

ワークフロービルダーのまま続けてよい条件と切り替えを考える目安

次の条件をすべて満たすなら、Slackワークフローのまま続けて構いません。承認が1段で、承認者が申請者の指名か固定の担当窓口で決まる。監査に提出する証跡が不要。利用者が社内のSlackメンバーに限られる。この3つです。

反対に、承認者を組織と役職から自動で決めたい、決裁の記録を保管したい、のどちらかが出てきた時点で切り替えを検討します。目安として、同じ種類の申請を部署ごとにコピーしたワークフローが5本を超えたら、それは組織マスタを持つ仕組みが必要になっている兆候です。無理に分岐を足して延命すると、直せる人がいないワークフローが残ります。

カスタムステップ開発で社内システムとつなぐ場合の構成と開発の前提

Slackの操作感は変えずに、承認結果を社内の基幹システムへ書き込みたい場合は、カスタムステップを開発します。開発者ドキュメントによると、カスタムステップはFreeプランでは開発できず、Bolt（Python・JavaScript・Java）で作って自社のサーバーで動かすか、Deno Slack SDKで作ってSlackの基盤で動かすかを選びます。処理の最後には成功か失敗を返すメソッドを呼ぶ決まりがあり、他社へ公開配布することはできません。

見積りで確かめたいのは、社内システム側のAPIがあるかどうかと、書き込みに失敗した場合の再実行の方法です。Slack APIの全体像とBoltでの実装はSlack APIとは？Web API・Events API・Boltの違いと実装手順で詳しく扱っています。コードを書かずに他社サービスとつなぐだけなら、先にiPaaSの仕組みと料金の数え方で足りるかを比べてください。

ワークフローシステムに決裁を任せてSlackは通知の窓口に回す併用構成

多段承認と証跡が必要な申請は、ワークフローシステムに移し、Slackには承認依頼の通知と「システムで開く」リンクだけを流す構成が扱いやすい形です。利用者はこれまでどおりSlackで依頼に気付き、決裁の記録はシステム側に残ります。休暇申請や問い合わせ受付のような軽い依頼は、Slackワークフローのまま残して構いません。

製品の選び方はワークフローシステムの機能と選び方の解説で比べられます。既製品では自社の承認規程や基幹システムとの連携に合わない場合は、ワークフローシステム開発として、Slack通知との連携を含めて要件の整理から受託で進められます。

よくある質問

Slackワークフローの使い方を検討する担当者から寄せられやすい質問に答えます。

Slackの無料プランでもワークフローは使えますか？

Slackヘルプセンターでは、ワークフロービルダーは有料プランで利用できる機能として案内されています。既定では有料プランのメンバー全員が作成でき、ゲストも作成されたワークフローを利用できます。カスタムステップの開発も、開発者ドキュメントの記載ではFreeプランは対象外です。プランの内容は改定されることがあるため、契約前にSlackの料金ページで最新の対象機能を確認してください。

Slackワークフローで承認フローは作れますか？

作れます。フォームで申請を受け、承認者へ「承認」「却下」のボタン付きメッセージを送り、押されたボタンに応じて分岐させる形です。押せる人の限定、1回押したら無効にする設定、有効期限も付けられます。ただし向いているのは1段の承認までです。金額や部署で承認者が変わる多段の決裁や、監査で示す承認記録が必要な申請は、ワークフローシステムに任せたほうが運用が安定します。

Slackワークフローの回答をスプレッドシートに自動で記録できますか？

できます。コネクタのステップにはGoogleスプレッドシートへ行を追加するものがあり、フォームの回答を変数で各列に入れられます。コネクタを使うには、サードパーティのアカウントの認証が必要です。ワークスペースでアプリの承認が有効な場合は、管理者の承認を得てから追加します。作成者の認証情報を使う設定にしたときは、作成者の異動や退職の前に付け替えることを忘れないでください。

ワークフローを作れる人を情シスだけに絞れますか？

作成できる人を情シスだけに絞る設定は可能です。既定では有料プランのメンバー全員が作成できますが、オーナーや管理者がワークフロービルダーへのアクセス権を管理し、使える機能やメンバーが追加できるコネクタ・カスタムステップを制限できます。管理者は公開済みのワークフローをダッシュボードで一覧できるため、全員に作成を許したうえで定期的に棚卸しする運用もあります。業務部門の自主性と統制のどちらを優先するかで決めてください。

スラッシュコマンドとワークフローはどちらで依頼を受け付けるべきですか？

依頼の受付が目的なら、まずワークフローを選びます。フォームと承認ボタンまでコードなしで作れ、業務部門が自分で直せるからです。スラッシュコマンドはアプリの開発が前提で、入力をその場で社内システムへ問い合わせて結果を返す、といった処理が必要な場合に向きます。作り方と応答の決まりはSlackでカスタムコマンドを自作する手順で解説しています。