Slack

Slack Workflow Builder の使い方と権限設定、活用事例まとめ

ⓘ本ページはプロモーションが含まれています

スポンサードリンク

Slack Workflow Builder の概要とアクセス方法 {#overview}

Workflow Builder は、Slack のサイドバーから数クリックで開けるビジュアルエディタです。
必要なのは「ワークフローの作成・管理」権限さえ付与されていれば、Workspace のプランに関係なく誰でも利用できます（無料プランでも標準的なトリガーとステップは使用可能）。有料プランで追加できる機能としては、カスタム関数や 外部アプリ連携 がありますが、基本フローの作成自体に料金は不要です。

アクセス手順

  1. Slack クライアント（デスクトップ・ウェブ）を開く。
  2. 左サイドバー下部にある 「Workflow Builder」 をクリック。
  3. 「新しいワークフローを作成」ボタン → テンプレート選択または空白から開始。

権限が不足している場合は、管理者に「Workflow Builder の使用許可」を依頼してください。管理画面の Settings > Permissions でロールごとに細かく設定できます。

基本コンポーネント：トリガー・ステップ・フォーム {#components}

Workflow Builder は以下の三要素で構成されます。これらを組み合わせるだけで、シンプルから複雑まで幅広い自動化が実現します。

コンポーネント 役割
トリガー ワークフローの開始条件（時間・メッセージ・ショートカット）
ステップ 実行するアクション（メッセージ送信、フォーム表示、条件分岐など）
フォーム ユーザーから入力を取得し、次のステップで変数として利用可能

トリガーの種類と設定例

  • スケジュールトリガー – 毎日・毎週・特定日時に実行。例：毎週月曜 9:00 にリマインダー送信
  • メッセージ受信トリガー – 指定キーワードやリアクションが付いたときに発火。例：「#report」 が含まれる投稿を検知
  • ショートカットトリガー – ユーザーがメニューから手動で起動。例：右クリック → 「経費精算を開始」

ステップの代表例

ステップ 主な用途
メッセージ送信 チャンネルや DM へ通知・リマインダー
フォーム表示 テキスト、日付、プルダウンなどの入力フィールドを作成
条件分岐 前ステップの変数に基づきフローを分岐
カスタム関数呼び出し（有料プラン） 外部 API を直接叩く高度なロジック

フォーム作成の流れ

  1. ステップ追加 → 「フォームを表示」
  2. フィールド定義 – ラベル、必須設定、プレースホルダーを入力
  3. 変数名の付与 – 例：achievement_text、next_week_plan

作成した変数は以降のステップで ${variable_name} の形で参照できます。

主なトリガー活用シナリオ {#trigger-use-cases}

トリガー 推奨ユースケース
スケジュール（毎日/毎週） 定期リマインダー、週次報告依頼、スタンドアップ自動配信
メッセージ受信（キーワード） 「#help」 でヘルプボット起動、FAQ 自動返信
ショートカット 手動承認フロー、臨時アンケート、経費申請開始

実装ポイント
- 時間帯は必ず Slack のタイムゾーン設定（Workspace Settings > Timezone）に合わせる。
- キーワードトリガーは誤検知を防ぐため、できるだけ固有の文字列（例：/report-submit）を使用する。

代表的ユースケースとテンプレート作成手順 {#use-cases}

1. 週次報告リマインダー

手順 内容
トリガー スケジュール → 毎週月曜 9:00（日本時間）
ステップ① メッセージ送信 → #weekly-reports に「今週の業務報告をお願いします」
ステップ② フォーム表示 →

  • 達成事項（必須・テキスト）
  • 来週の課題（必須・テキスト）
ステップ③ メッセージ送信（DM） → 申請者へ「ご提出ありがとうございます」
保存 完了後に「このワークフローをテンプレートとして保存」し、他チャンネルでもインポート可能

2. シンプル承認フロー

  1. トリガー：ショートカット → 「経費精算」ボタンをメニューに追加
  2. ステップ①：フォーム表示（金額・用途）
  3. ステップ②：条件分岐 – 金額 ≤ 5,000 円は自動承認、超える場合はマネージャへ通知
  4. ステップ③（マネージャ向け）：メッセージ送信に「承認 / 却下」ボタンを添付
  5. ステップ④：結果通知（申請者と会計チャンネル）

テンプレート化すれば、部門ごとの予算上限だけ変えて再利用できます。

3. 新入社員オンボーディング質問票

  • トリガー：新規メンバーが #general に参加した瞬間（「メッセージ受信」トリガーで welcome キーワードを検知）
  • ステップ①：ウェルカムメッセージとアンケートフォーム送付
  • ステップ②：回答内容を Google Sheets へ自動保存（外部ツール連携参照）

ノーコードツールとの連携方法 {#nocode-integration}

Workflow Builder の標準ステップだけでは実現できないシナリオは、Zapier や Make（旧 Integromat）、n8n などのノーコード/ローコードプラットフォームで補完できます。以下では 信頼性が高く、公式ドキュメントでも推奨されているツール に絞って解説します。

1. Zapier を使った多段階承認フロー

Zap の構成要素 内容
Trigger Slack – 「ショートカット」または「新しいリアクション」
Action 1 Google Sheets – 申請内容を行として追加（ステータス = Pending）
Action 2 Gmail – 承認依頼メールに「承認 / 却下」リンク付きで送信
Action 3 Webhooks by Zapier – メール内リンクがクリックされたらシートのステータスを更新
Action 4 Slack – ステータス変更を検知し、申請者へ結果メッセージ送信

実装上のポイント

  • Zap のエラーハンドリング：各 Action で「Retry on Failure」オプションを有効化。
  • データ保護：Google Sheets の共有設定は「組織内のみ」に限定し、機密情報が外部に漏れないようにする。

2. Make（Integromat）で条件分岐とループ処理

Make はビジュアルフローエディタが特徴で、複雑なロジックやバッチ処理 に向いています。

  • シナリオ例：Slack のショートカット → フォーム入力取得 → 金額判定（5,000 円以上は承認者へ転送） → 承認結果を Slack と Google Drive に同時保存。
  • ループ処理：複数の承認ステップが必要な場合、Iterator モジュールで承認リストを順次処理できる。

3. n8n（セルフホスト型）で社内向けカスタム連携

自社サーバー上にデプロイすれば 完全プライベート な連携が可能です。API キーやシークレット情報を外部 SaaS に送信せず、社内ネットワークだけで完結させられます。

  • 利用例：Slack → 社内 ERP の REST API へ POST → 結果 JSON を Slack に返す。
  • メリット：オープンソースなので自由にノードを拡張でき、社内規約に合わせた認証方式（OAuth2, JWT）を実装可能。

注意：本記事では「Gluegent Flow」や未確認の情報源は使用しません。上記3ツールはいずれも公式ドキュメントが充実しており、導入リスクが低いことが確認されています。

カスタムアクション：Incoming Webhook と Slack API の実装ガイド {#custom-actions}

標準ステップだけでは対応できない「外部システムからのプッシュ通知」や「双方向データ連携」は、Incoming Webhook と Slack Web API を組み合わせて実装します。

1. Incoming Webhook の取得手順

  1. Slack 管理コンソール → Apps > Manage
  2. 「Custom Integrations」から Incoming Webhooks を選択
  3. 「Add to Workspace」→ 対象チャンネルを指定し、Webhook URL を生成

取得した URL は機密情報です。Git リポジトリや共有ドキュメントに平文で保存しないよう注意してください。

2. 基本的な HTTP POST の例（cURL）

3. Slack Web API（chat.postMessage）への置き換え

Webhook はシンプルですが 認証・リトライ機構がない 点が弱点です。API を利用すればステータスコードの取得やエラーハンドリングが可能になります。

必要なスコープ

スコープ 説明
chat:write メッセージ送信全般
chat:write.public（任意） パブリックチャンネルへのメッセージ送信
incoming-webhook（Webhook 用） Webhook の作成・管理

4. エラーハンドリングと再送戦略

  1. ステータスコード確認
  2. 200 系 → 成功、レスポンスの ok: true を必ずチェック。
  3. 4xx 系 → パラメータエラーや認証失敗。ログに残し、管理者へアラート。

  4. 5xx 系 → Slack 側障害。指数バックオフ（1, 2, 4, 8 秒）で最大 3 回再試行。

  5. 通知チャンネルへのエラー報告
    json
    {
    "channel": "#error-monitoring",
    "text": ":warning: Webhook 送信失敗 (status: 500) – 再試行中..."
    }

  6. ロギング

  7. 外部サービス（CloudWatch、Stackdriver、Datadog 等）に request_id, payload, response_body を保存。

運用上のベストプラクティスとチェックリスト {#best-practices}

項目 推奨アクション
権限管理 「Workflow Builder を使用できる」ロールは最小化し、chat:write 以外のスコープは付与しない。
プラン確認 無料プランでも標準トリガー・ステップは利用可能。有料プランが必要なのは「カスタム関数」や一部サードパーティ連携のみ。
テスト環境の確保 本番導入前にステージング用チャンネルで全フローを実行し、メンション漏れや誤送信を防止。
バージョン管理 ワークフローテンプレートは JSON エクスポートして Git に保存し、変更履歴を追跡。
監視・アラート Webhook / API の失敗は専用のエラー通知チャンネルへ自動投稿。外部モニタリングツールと連携することも推奨。
ドキュメント整備 各フローの目的、トリガー条件、ステップ構成、担当者を Markdown でまとめ、社内 Wiki に掲載。
セキュリティ Webhook URL や OAuth トークンは環境変数またはシークレットマネージャに保存し、コード上にハードコーディングしない。
定期レビュー 3〜6か月ごとにフローの利用状況を分析し、不要なステップや権限を削除。

まとめ

Slack の Workflow Builder は プラン非依存で基本的な自動化が可能 なツールです。
- トリガー・ステップ・フォームというシンプルな構造を理解すれば、週次報告や承認フローといった日常業務は数分で実装できます。
- 複雑なロジックや外部システム連携が必要な場合は、Zapier・Make・n8n といったノーコードプラットフォームを組み合わせるのが安全かつ拡張性の高い方法です。
- カスタムアクションは Incoming Webhook と Slack API を正しく使い、認証・エラーハンドリング・ロギングを徹底すれば、信頼性の高い双方向連携が実現します。

上記ガイドラインとベストプラクティスに沿って設計・運用すれば、チーム全体の生産性向上と情報共有の最適化が期待できます。

スポンサードリンク

-Slack