これ一つで全てが理解できる Slack ワークフローの基礎と実践

N 高グループ・N 中等部・N Code Labo Advent Calendar 2025 15日目の記事です

探せばすぐ出ると思いますが 第 4 期生徒会役員 をやっています
学園生には私のプロフィールを渡した上で本記事を読んでいただければと思います
https://n-highschool.slack.com/team/U06NJCN81SA

そして今日は私の誕生日です
9 月から発足した第 4 期生徒会役員として色々なこともありましたが、16歳という年齢で過ごした一年はとても楽しかった です

はじめに

生徒会の運用で Slack を使っていると、問い合わせが増えるにつれて「誰が担当するか分からない」「返信漏れが起きる」「進捗が追えない」といった問題が出てきました

最初は普通にチャンネルで問い合わせを受けていたんですが、件数が増えるにつれて管理が破綻しかけたので、Slack のワークフローとリストを組み合わせてチケット管理システムを作りました

この記事では、Slack のワークフローの基本から、実際に 問い合わせをチケット化して管理する方法 まで、生徒会で運用してみて分かったことをまとめます

目次

• ワークフローでできることを最初に全部俯瞰する

• まず押さえる基本

  • ワークフローの構造
  • トリガー
  • ステップ
  • 変数
  • 権限と管理

• 実務で詰まりやすいポイント

  • うまく動かない原因の切り分け
  • 設計で事故を防ぐ

• 実践編

  • 問い合わせをチケット化する全体設計
  • Slack リストの設計
  • ワークフローを組み立てる
  • 運用ルール
  • 改善の回し方

• 目的別レシピ集

ワークフローでできることを最初に全部俯瞰する

Slack のワークフローは、雑に言うと「Slack 内のイベントやクリックをきっかけに、決めた手順を毎回同じ形で実行する仕組み」です

できることの代表例

• フォームを出して入力を集める

  • 企画申請、問い合わせ、レビュー依頼、欠席連絡、相談窓口など

• 入力結果を、決まった場所に自動で流す

  • チャンネルに投稿
  • スレッドに投稿
  • DM で通知

• 情報を「作業対象」として管理する

  • Slack のリストにアイテムを作る
  • リストのステータス更新に反応して通知する

• 条件でルートを分岐させる

  • 緊急なら #urgent へ、通常なら #triage へ
  • 委員会ごとに通知先を変える
  • 相談内容の種類で担当を変える

• 外部サービスとつなぐ

  • Google Sheets や Google Calendar、GitHub、Jira などのコネクターで開始したり、更新したり
  • Webhook で外部の出来事からワークフローを開始する

「フォーム + 通知」だけでも強いですが、リストと組み合わせる と「入力が流れて終わり」ではなく、管理できる状態 になります

まず押さえる基本

ワークフローの構造

ワークフローは基本的に次の 2 つでできています

1. トリガー

   • 何をきっかけに開始するか

2. ステップ

   • 開始したあとに何をするか

ここに 変数 が加わると一気に強くなります

• フォームの回答
• トリガーの情報
• リストアイテムの情報

これらを「変数」として受け取って、次のステップに差し込めます

トリガーについて

Slack のワークフローは、開始方法が重要です
設計の 8 割は「どのトリガーを選ぶか」で決まると言っても過言ではありません

代表的なトリガー

1. リンクから開始

• チャンネルに貼ったリンクや、ショートカットのボタンから開始
• 使いどころ
  • 申請フォーム
  • 問い合わせフォーム
  • 毎回人が押す必要のある開始点

2. スケジュールで開始

• 毎日、毎週など定期実行
• 使いどころ
  • 週次の進捗リマインド
  • 締切前の催促
  • 定期レポート

3. 絵文字リアクションで開始

• 特定の絵文字が付いたら開始
• 使いどころ
  • :white_check_mark: が付いたらタスク化
  • :rotating_light: が付いたら緊急フローへ

4. キーワードで開始

• 特定のキーワードに反応して開始
• 使いどころ
  • よくある質問への自動回答
  • 「緊急」「至急」などの言葉が含まれる投稿でアラート
  • 特定ワードでサポート担当へ振り分け

5. チャンネル参加で開始

• 誰かがチャンネルに入ったら開始
• 使いどころ
  • オンボーディング
  • 自己紹介依頼
  • チャンネルの使い方案内

6. リストのアイテム更新で開始

• リストのアイテムが更新されたら開始
• 使いどころ
  • ステータスが変わったら通知
  • 担当が入ったら担当者へ DM
  • 期限が入ったらリマインドを組む

7. Webhookで開始

• Slack 外部から HTTP リクエストで開始
• 使いどころ
  • Web サイトの監視
  • 学内システムの更新通知
  • 自作ツールからの通知

8. コネクターのイベントで開始

• 外部サービスのイベントで開始
• 使いどころ
  • GitHub で Issue が立ったらチケット化
  • Google Forms の入力を Slack に流す

トリガー選びのコツ

• 申請・問い合わせ は「リンクから開始」

  • 誰がいつ押すか分かりやすい

• 状態変化に反応 するなら「リスト更新」

  • チケット運用の核になる

• 人が忘れるやつ は「スケジュール」

  • 週次レポートや締切

• 現場のトリアージ は「リアクション」

  • 手触りが良い

ステップについて

ステップは「実行する動作」です
生徒会の運用でよく使っているのは次のカテゴリです

1. フォーム

• フォームを表示して入力を集める
• ここで集めた内容が 変数 になります

フォーム設計のコツ

• 入力項目は「運用に必要なものだけ」に絞る
• 迷う項目は選択式にする
• 必須と任意をはっきり分ける

2. メッセージ

• チャンネルに送る
• DM で送る
• スレッドに返信する

メッセージ設計のコツ

• 受け手が次にやることを 1 行で書く
• その場で押せるリンクを置く
• 情報は「短く、でも不足しない」

3. リスト

• リストにアイテムを追加する
• 既存アイテムを選択する
• アイテムを更新する

ここが「問い合わせ → チケット化」の主役です

4. Canvas

• Canvas を作成する
• Canvas を更新する
• 他のユーザーに Canvas を共有する

運用ノートを自動で育てるのに向いています

5. 条件分岐

• 条件に一致したときだけ、その先のステップを実行
• 複数の条件を組み合わせられる

6. 外部アプリのステップ

• Google Sheets に行を追加
• GitHub で Issue を作る
• Jira でチケットを作る

外部連携は強いですが、まずは Slack 内完結で設計するのが分かりやすいです

変数について

ワークフローが「自動化」になるか「ただの定型文」になるかは変数で決まります
ここが理解できると、ワークフローの設計がグッと楽になります

変数はどこから来るか

• トリガー由来

  • 誰が開始したか
  • どのチャンネルからか
  • どのメッセージか

• フォーム回答

  • テキスト
  • 選択肢
  • メンバー
  • 日付

• リスト由来

  • アイテムのリンク
  • ステータス
  • 担当者
  • 期限

変数を使うと何が嬉しいか

• フォームの「相談内容」を、そのままチケット本文に入れる
• 申請者の名前を自動でメンションする
• 期限や担当をメッセージに差し込んで取りこぼしを減らす

変数の設計で大事なこと

• 「運用で必要な情報」は必ず変数として取れる形にしておく
• 後から必要になる情報を見積もって、最初からフィールドを用意する
• ただし、入力項目を増やし過ぎると提出率が落ちるので、迷ったら
  • 初期は少なく
  • 足りなくなったら足す

権限と管理について

ワークフローは「作って終わり」ではなく、運用で育てます
生徒会のように担当者が変わる組織では、この管理の仕組みが特に重要です

ワークフローマネージャー

• 作成者以外にも編集権限を渡せる
• 生徒会の運用だと「担当が変わる」ので必須

誰が使えるか

• 実行できる人の範囲
• コピーできる人の範囲

これを雑に広げると、同じ目的のワークフローが乱立して地獄になります

変更管理

• トリガーは公開後に変えにくい
• 大きく変えたいときは「コピーして新しい版」を作る

名前の付け方

• 迷わない命名は運用コストを下げます

おすすめの形式

• 【用途】 + 【対象】 + 【動作】

例

• 問い合わせ 受付フォーム
• 企画 申請フォーム
• チケット ステータス更新通知
• チケット 期限リマインド

実際に詰まったポイント

運用していて「あれ？動かない」となったことを共有します

うまく動かない原因あるある

• 実行権限がない
• トリガーの対象チャンネルが違う
• フォームの項目が更新されて変数が消えた
• リストのフィールド名を変えてマッピングが崩れた（これは何回かやらかしました）

設計で事故を防ぐ

最初に全部やろうとすると失敗します

• まず「人がやりたくない作業」を 1 つだけ自動化する
• その後で分岐や外部連携を足す
• いきなり全部やると、誰も理解できない状態になる

実践編：問い合わせをチケット化する

ここからが本題です
「Slack で問い合わせを受ける」だけなら簡単なんですが、それだと

• 返信漏れ
• 担当不明
• 進捗が追えない
• いつ終わったか分からない

という問題が出てきました
生徒会で実際にこれで困ったので、Slack のリストとワークフローを組み合わせてチケット管理の仕組みを作りました

全体設計

登場人物

• 起票者

  • 問い合わせフォームを提出する

• 起票共有者

  • 起票者が共有したいメンバー

• 担当者

  • デジタル委員会代表（固定）

流れ

実際に運用している流れです

1. 起票者がフォームを提出
2. 自動でリストにチケットが作られる
3. チャンネルに通知が投稿される
4. スレッドに詳細が投稿される（担当者がアサインされる）
5. 起票者に受付完了 DM が送信される
6. 担当者がスレッドで対応
7. 担当者が「担当者による完了」ボタンを押す
8. 完了報告フォームが表示される
9. リストが更新される
10. スレッドにクローズ通知が投稿される
11. 通知メッセージに完了の絵文字リアクションが追加される

Slack リストの設計

リストは「問い合わせ台帳」として使います
デジタル委員会で実際に運用しているリストを例に紹介します

リスト名の例

• デジタル委員会 問い合わせチケット

実際に運用しているフィールド

実際に運用してみて設計したフィールドです

• ケース番号

  • 自動採番される ID

• タイトル

  • 一瞬で判断できる短いタイトル

• カテゴリ

  • 対応依頼
  • 確認依頼
  • 操作依頼
  • 質問
  • その他

• 詳細

  • フォームの本文（リッチテキスト対応）

• 関連 URL

  • 関連資料などの URL

• 優先度 / 回答期限

  • 低 - 1 週間以内
  • 中 - 3 日以内
  • 高 - 明日まで（至急）

• 起票者

  • メンバー型（自動設定）

• 起票共有者

  • 共有したいメンバーを複数選択可能

• ステータス

  • 完了
  • 保留
  • 取消

• 作業内容

  • 完了報告の内容

ビューを作る

• トリアージ用

  • ステータスが新規だけ

• 担当者別

  • 自分の担当だけ

• 期限が近い

  • 7 日以内

• 完了

  • 完了だけ

ビューが揃うと、管理が「気合」ではなく「仕組み」になります

ワークフロー1：受付フォーム → リストにチケット作成

目的

• 申請者が迷わず問い合わせできる
• 情報が不足しない
• 自動でチケットになる

トリガー

• リンクから開始
  • チャンネルに固定メッセージ
  • チャンネルのブックマーク
  • Canvas にリンク

ステップ構成

実際に運用しているステップです

1. フォームを表示
2. リストにアイテムを追加
3. チャンネルに通知
4. スレッドに詳細を投稿
5. 起票者に受付完了 DM

1. フォームの項目例

実際に運用しているフォームの項目です

• カテゴリ（必須）

  • 対応依頼 / 確認依頼 / 操作依頼 / 質問 / その他

• タイトル（必須）

  • 短くわかりやすく

• 詳細（必須）

  • できるだけ具体的に記述（リッチテキスト対応）

• 関連 URL（任意）

  • 関連資料などがあれば URL を記入

• 優先度 / 回答期限（必須）

  • 低 - 1 週間以内 / 中 - 3 日以内 / 高 - 明日まで（至急）
  • デフォルトは「低 - 1 週間以内」

• 起票共有者（任意）

  • 共有したいメンバーがいれば指定

2. リストにアイテムを追加

• カテゴリ → カテゴリ
• タイトル → タイトル
• 詳細 → 詳細
• 関連 URL → 関連 URL
• 優先度 / 回答期限 → 優先度 / 回答期限
• 起票者 → 起票者（自動設定）
• 起票共有者 → 起票共有者
• ステータス →「完了」（初期値）

ポイント

• フォームとリストのフィールド名を揃えるとマッピングが楽
• フィールド名を後から変えると崩れやすいので慎重に

3. チャンネルへ通知

実際の通知メッセージ例

新しいお問い合わせが送信されました
カテゴリ：{カテゴリ}
ケース番号：{ケース番号}
優先度 / 回答期限：{優先度 / 回答期限}

起票者
{起票者} {起票共有者}

タイトル
{タイトル}

この通知を投稿することで、後から追いやすくなります

4. スレッドに詳細を投稿

スレッドに詳細情報を投稿します

タイトル
{タイトル}

詳細
{詳細}

関連 URL
{関連 URL}

アサイン担当者
{担当者}

優先度 / 回答期限
{優先度 / 回答期限}

ボタン：[担当者による完了]

このスレッドで担当者とやり取りができるようになります

5. 起票者へ受付完了 DM

DM 例

デジタル委員会代表への連絡を受け付けました！
ケース番号は「{ケース番号}」です
下記のリンクから起票内容をご確認ください
{チャンネル投稿へのリンク}

ここは意外と重要です
自分だったら「ちゃんと届いてるか不安」になると思い、受付完了の DM を追加しました
これだけで問い合わせの質が上がったと感じています

ワークフロー2：完了報告

担当者が「担当者による完了」ボタンを押したときに起動するワークフローです

トリガー

• ボタンクリック（インタラクティブコンポーネント）
  • スレッドの「担当者による完了」ボタン

ステップ

1. 完了報告フォームを表示

• 作業内容（必須）

  • リッチテキストで作業内容を記入

• ステータス（必須）

  • 完了 / 保留 / 取消
  • デフォルトは「完了」

2. リストを更新

フォームの内容でリストアイテムを更新します

• 作業内容 → 作業内容
• ステータス → ステータス

3. スレッドにクローズ通知

本件はクローズされました
本件を再開することはできませんが、同様の会話をご希望の場合はケース番号「{ケース番号}」を添えて新規起票してください

4. 完了の絵文字リアクションを追加

チャンネルの通知メッセージに絵文字リアクション（:white_check_mark:）を追加して、完了したことを視覚的に分かりやすくします

ちなみに、完了絵文字には「いらすとや」の 「済」スタンプ を使うのも雰囲気が出ておすすめです！

リスト側の自動化も使う

リストには「リスト内で設定できる自動化」があります
最初は全部ワークフローで組もうとしたんですが、リスト側の自動化の方が簡単なケースも多いです

リスト側の自動化でできること:

• フォーム回答をリストに追加
• フィールド変更時の通知
• 期限通知
  • 担当者へ
  • チャンネルへ
• 期限サマリー

まずは

• 期限通知
• フィールド変更通知

この 2 つを入れるだけでも運用が安定しますワークフローを組む前に、リスト側の自動化を確認するのがおすすめです

運用ルール

仕組みができても、ルールがないと崩れます

最低限のルール

• 新規は 24 時間以内に受付済みとする
• 受付済みになったら担当が必ず入る
• 対応中にしたら進捗コメントを残す
• 完了にしたら完了理由を短く残す

運用ノートを Canvas に作る

• ルール
• よくある質問
• 例外対応
• 改善履歴

これを Canvas で育てると、属人化が減ります

改善の回し方

ワークフローは「最初から完璧」は無理です

おすすめの改善サイクル

1. まず運用開始
2. 週 1 で詰まりポイントを拾う
3. フォームの項目を調整
4. 通知の文章を直す
5. 分岐を追加

「提出しやすい」と「管理しやすい」はトレードオフなので、運用しながらバランスを取ります

目的別レシピ集

1. 新メンバーのオンボーディング

• トリガー

  • チャンネル参加

• ステップ

  • 使い方案内
  • 自己紹介フォーム
  • まとめをチャンネル or スレッドに投稿

2. 週次の進捗回収

• トリガー

  • スケジュール

• ステップ

  • フォーム
  • リストに追加
  • サマリー投稿

3. 企画のレビュー依頼

• トリガー

  • リンク

• ステップ

  • 企画情報フォーム
  • 担当者へ DM
  • 期限設定

まとめ

Slack のワークフローは、使い方をちゃんと設計すると「連絡ツール」から「運用の OS」に変わります

生徒会で実際にこの仕組みを導入してから、返信漏れが減り、進捗が可視化され、担当者の負担も軽減されました

運用してみて学んだこと

• まず「人がやりたくない作業」を 1 つだけ自動化する
• その後で分岐や外部連携を足す
• いきなり全部やると、誰も理解できない状態になる
• リスト側の自動化とワークフローを使い分ける
• 運用しながら改善していく

この記事のゴールは、ワークフローの機能紹介ではなく

• どこをどう触れば
• 何ができて
• どう運用に落とし込めるか

を一気に繋げることでした

もし同じような問題を抱えている方がいれば、参考にしてみてください！