%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
Slack Workflow BuilderとAI自動化の設計と活用方法とは、Slack上の情報の受付・整理・通知を業務フローにつなぎ、AIの出力を担当者が確認しながら活用するための考え方と手順です。「申請の確認が滞る」「日報を集めても課題を追えない」「問い合わせの回答案を作る時間が足りない」。Slack上の作業を自動化したくても、どの業務までAIに任せ、どこで担当者が確認すべきか迷うことがあります。
Slack Workflow BuilderとAI自動化の設計と活用方法とは、Slack上の情報の受付・整理・通知を業務フローにつなぎ、AIの出力を担当者が確認しながら活用するための考え方と手順です。「申請の確認が滞る」「日報を集めても課題を追えない」「問い合わせの回答案を作る時間が足りない」。Slack上の作業を自動化したくても、どの業務までAIに任せ、どこで担当者が確認すべきか迷うことがあります。
最初に決めるのは設定ではなく、どの業務をSlackのワークフローとAIに載せ、どの業務は載せないかという判断です。次の3つの問いに答えられる業務は、載せる候補になります。
- 入力がSlackに集まっているか。 申請フォームや日報の提出、問い合わせの共有のように、AIに渡す情報がSlack上に出てくる業務か。
- 誤りが出たときの影響が限られるか。 社内の下書きや要約なら、誤りは担当者が見つけて直せる。顧客への送信や金額の確定は、誤りがそのまま外に出る。
- 担当者が原文とAIの出力を見比べられるか。 見比べる人と、結果を残す場所が決まっているか。
3つのうち1つでも答えられない業務は、設定に進む前に担当や記録先を整理します。この記事では、判断の表、自社で試す手順の例、うまくいったかの確かめ方を先に示し、そのあとで承認・日報・問い合わせの設計、外部AIとの連携、設定の要点を説明します。2026年10月時点のSlack公式ヘルプなどの記載を確認したうえで書いています。
経営の視点では、自動化の効率よりも、記録が残るかどうかが重要です。Slack上で行った承認、顧客への回答、対応の判断がチャンネルの流れに埋もれると、顧客対応の履歴がどこにも蓄積されません。担当者が替わったとき、過去の経緯を追えず、同じ確認を顧客に繰り返すことになります。判断と対応の記録を顧客情報と同じ場所に集める設計は、属人化を抑え、対応の質を一定に保つための事業上の投資です。
AI活用完全ガイドでは、AI活用の全体像を確認できます。生成AIそのものの使い方を整理したい場合は「生成AIとは？ビジネス活用の全体像をわかりやすく解説」、関連テーマを探したい場合は生成AI実務活用ガイドをご覧ください。
この記事でわかること
申請、日報、問い合わせの処理をSlack上で整理したい業務担当者や、フローの設定・保守を担う方に向けて、判断から試行、見直しまでの順序を説明します。
- 載せる業務と載せない業務の判断
業務の型ごとの向き不向きと、人が確認する点を表で整理します。
- 自社で試す手順の例と確かめ方
小さく始めるための手順と、うまくいったかを見る指標を示します。
- 申請・日報・問い合わせの設計
入力、AIの出力、担当者の確認、結果の記録をつなぎます。
- 外部AIとの連携と設定の要点
Slackから外部AIへ送る経路と、結果をSlackへ戻す経路を分けて説明します。
どの業務をSlackワークフローとAIに載せるか
まず現在の作業を「開始」「入力」「整理」「判断」「通知」「記録」に分けます。同じ情報を転記している箇所、担当者が原文を確認している箇所、結果が残っていない箇所を書き出してください。そのうえで、業務ごとに載せるかどうかを次の表で見ます。
業務の型ごとの向き不向きと人の確認点
| 業務の型 | AIとワークフローの向き不向き | 人が確認する点 |
|---|---|---|
| 申請の受付と確認材料の整理 | 向く。入力の整理や確認ポイントの提示はAIに任せやすい。承認・却下は任せない | 承認・却下と理由の記録 |
| 日報・定例報告の集約 | 向く。項目別の集約と要約案は材料になる | 課題の優先順位付け、支援の判断 |
| 問い合わせの回答案作成 | 条件付きで向く。参照できる情報源が決まっている場合に限る。顧客への自動送信は載せない | 元の問い合わせと参照情報の照合、修正、送信 |
| 価格・契約条件を含む回答 | 載せない。回答案の作成にとどめ、最新の資料との照合を人が行う | 現在有効な資料との照合 |
| 判断基準が決まっていない業務 | 載せない。先に判断基準と担当を決める | 基準の策定 |
| 個人情報・機密情報を多く含む業務 | 外部AIへ渡す範囲を決めるまで載せない | 渡す項目と保存の扱いの確認 |
| 件数が少なく、例外ばかりの業務 | 載せない。設定の手間が見合わない | 通常どおり担当者が対応 |
判断の分かれ目は、AIの精度よりも、誤りに気づく人がいるかどうかです。要約や回答案は担当者が確認する材料であり、どの出力を採用するか、例外を認めるか、顧客へ何を送るかには業務上の判断が伴います。処理ごとに確認担当を置き、判断した結果をどこに残すかまで決めてください。
判断の例：同じAIでも、載せる業務と載せない業務が分かれる
次は、3つの問いを当てはめた架空の例です。
| 場面 | 3つの問いへの答え | 判断 |
|---|---|---|
| 社内の経費申請の確認材料を整理する | 入力はSlackに集まり、誤りは承認者が原文で見つけられ、結果の記録先も決まっている | 載せる。承認・却下は人が行う |
| 見積条件を含む顧客への回答を自動で送る | 誤りがそのまま顧客に出る。価格資料の最新版を照合する担当が決まっていない | 載せない。回答案の作成にとどめ、送信は人が行う |
| 週に数件、例外ばかりの依頼を処理する | 判断基準が決まっておらず、設定の手間が見合わない | 載せない。先に基準と担当を決める |
手作業をそのまま自動化しない
申請内容を別の場所に転記して承認を依頼しているなら、転記の設定を始める前に、承認者が必要とする入力項目と記録先を確認します。判断に使わない項目は入力負担になります。一方、判断に必要な項目を省くと、承認者が申請者へ確認し直すことになります。
最初に通常の案件を追い、どの情報を誰が使うかを書き出します。次に入力不足などの例外を追い、差し戻し先を決めます。両方の経路を担当者が説明できれば、フォームや通知の設定に進めます。説明できない場合は、入力項目か担当の決め方を先に見直します。
自社で試す手順の例とうまくいったかの確かめ方
載せる候補を選んだら、小さく試します。次は、日報の要約を例にした手順です。期間の区切りは仮の例なので、チームの業務量に合わせて変えてください。
試行の手順の例
- 対象を1つに絞る。 日報の要約のように、元の入力とAIの出力を担当者が見比べられる業務を選び、開始条件、入力項目、確認担当、記録先を決めます。
- テスト用の場所で動かす。 本番のチャンネルとは別に、テスト用のチャンネルで通常の入力と例外の入力を試します。
- 原文と出力を照合する。 担当者が元の入力とAIの出力を見比べ、誤りと手戻りの原因を記録します。
- 原因に対応する箇所を直す。 入力欄、参照情報、AIへの指示、引き継ぎ先のうち、原因に当たる箇所だけを直します。
- 範囲を広げる。 通常の処理が完了し、例外も担当者へ渡せることを確認してから、対象者や処理範囲を広げます。
うまくいったかの確かめ方
確かめる軸は3つです。数値の基準は業務ごとに異なるため、最初の数週間は目標値を置かず、実績を記録して基準を決めます。
| 確かめる軸 | 見るもの | 読み方 |
|---|---|---|
| 正しさ | 担当者が原文と見比べて見つけた誤りの件数と種類 | 誤りの原因が入力・参照情報・AIへの指示のどれかを分けて記録する |
| 手戻り | 修正して使った件数、使わなかった件数 | 修正の中身が事実の誤りか、表現の調整かで直す先が変わる |
| 記録 | 判断と理由が所定の場所に残っているか | 記録が残っていない処理は完了扱いにしない |
問い合わせの回答案では、次の指標を使えます。
| 指標 | 計算方法 | 読み方 |
|---|---|---|
| 回答案採用率 | そのまま送信された件数 / 全件数 | 低い場合は、参照情報かAIへの指示が業務に合っていない可能性を疑う |
| 修正率 | 修正して送信された件数 / 全件数 | 修正内容の妥当性は、この指標だけでは判断できない |
| 却下率 | 回答案を使わなかった件数 / 全件数 | 高い場合は、問い合わせの種類ごとに却下の理由を分けて調べる |
| 初回応答時間 | 問い合わせ受信→初回返信の時間 | 短縮だけを追わず、修正理由の記録と合わせて品質が保たれているかを見る |
回答案がそのまま送られたとしても、その内容が正しかったとは限りません。誤りの原因が古い参照情報なら情報源を更新します。参照情報は正しいのに回答案が不適切なら、検索対象やAIへの指示を見直します。
申請確認を支援する承認フロー
承認フローでは、申請の受付、確認材料の整理、承認者への通知、結果の記録をつなぎます。AIを使う場合も、要約や確認ポイントの提示までを任せ、承認・却下と理由の記録は承認者が行います。
次の図は、申請情報をAIで整理し、人が判断して結果を残す流れを示します。設定する際は、入力不足なら申請者へ、通知先が不明なら管理担当へ戻すなど、各段階で処理が止まった場合の引き継ぎ先も決めてください。
申請から結果通知までを設計する
申請フォームでタイトル、金額、理由、カテゴリを受け付ける場合、まず承認者がそれぞれを判断に使うか確認します。送信後はAIが内容を整理し、承認者へ原文と確認ポイントを渡します。承認者の判断後、申請者へ結果を知らせ、申請内容、結果、理由を所定の場所に残します。
入力が不足していれば、AIの推測で埋めずに申請者へ差し戻します。内容がそろっていれば承認者へ進め、通知先が決められない場合は管理担当が確認する経路に戻します。結果と理由が記録されて初めて、申請を完了として扱います。
承認者が確認する情報をそろえる
通知には、申請者が入力した内容とAIが作った要約を区別して表示します。要約だけでは判断できない場合、承認者が原文を確認できるようにします。
| 通知に含める情報 | 目的 | 判断・運用の分かれ目 |
|---|---|---|
| 申請内容と申請者 | 何を誰が申請したかを把握 | 必須情報が欠けていれば差し戻す |
| AIの要約と確認ポイント | 長文を読み始める手がかりにする | 元の申請と食い違えばAI要約を採用せず原文を確認 |
| 承認・却下の結果とコメント | 判断理由を後から追えるようにする | 理由が記録されていなければ完了扱いにしない |
通常の申請が最後まで進むことを確認したら、入力不足、想定外のカテゴリ、通知先を決められない申請を試します。それぞれの案件について、止まった理由と次の担当者が分かれば利用範囲を広げる判断ができます。
日報収集をチームの状況把握につなげる
日報では、集めた後の使い方を先に決めます。マネージャーが進捗を確認したいのか、支援が必要な課題を見つけたいのかによって、フォームに必要な項目と要約の形式が変わります。
入力項目と集約後の使い方を対応させる
成果、予定、困っていること、気づきや学びを分けて入力できるようにします。必須にする項目はチームの判断に必要なものに絞り、補足が必要な内容は任意欄で受け付けます。次の表は、各欄を集約後にどう使うかを対応させた例です。使われない設問や、判断に必要なのに集めていない情報を見つける手がかりになります。
| 項目 | 入力方法 | 集約後の使い方 |
|---|---|---|
| 今日の成果 | 短いテキスト | チームの進捗を把握 |
| 明日の予定 | 短いテキスト | 支援や調整が必要な予定を確認 |
| 困っていること | 任意のテキスト | 相談先や対応担当を決める |
| 気づき・学び | 任意のテキスト | チーム内で共有する情報を選ぶ |
収集から要約配信までの担当を決める
次の表は、収集から配信までの担当を整理した例です。送信時刻はチームで決める設定例であり、提出しやすい時間と要約を確認する人の業務に合わせて決めます。
| ステップ | 処理内容 | 担当 |
|---|---|---|
| 1. 収集 | 毎日17:00にフォームを各メンバーに送信（スケジュールで開始） | Workflow Builder |
| 2. 蓄積 | 回答を専用チャンネルに投稿 | Workflow Builder |
| 3. 要約 | 全員分の日報をAIが要約 | 外部AI（次の「外部AIとの連携」で扱う経路） |
| 4. 配信 | マネージャーに要約を送信 | Workflow Builder |
AIには成果、課題、次の予定を区別して要約させます。未提出の人について内容を補完しないよう、提出済みと未提出を分けます。要約から個別の日報に戻れるようにして、担当者が気になる記述を確かめられる状態にします。提出内容がばらばらで要約しづらい場合は、AIへの指示を増やす前に設問を見直します。入力がそろっているのに課題の担当者を取り違える場合は、要約時の指示と出力形式を見直します。
マネージャーは要約を元の日報と見比べ、抜けや誤った紐付けがないか確認します。対応が必要な課題を見つけたら、相談先、対応担当、次に確認する機会を決めます。
問い合わせの回答案を人が確認できる形で作る
問い合わせ対応では、回答案の作成と顧客への送信を分けます。まず問い合わせを担当者が確認できる場所へ届け、AIには許可した情報を使って回答案を作らせます。担当者は元の問い合わせと参照情報を照合し、必要な修正をしてから送信します。
メールやフォームから届いた内容をSlackのサポート用チャンネルに共有し、AI処理につなぐ構成が考えられます。連携方式を選ぶ前に、問い合わせ本文のどの項目が回答案に必要か、どの情報を外部へ渡せるかを確認します。必要な情報を渡せない場合は、回答案を作る範囲を狭めて担当者が対応します。
回答案の根拠をたどれるようにする
RAG（検索拡張生成）は、質問に関係する情報を検索し、その内容を生成AIに渡して回答案を作る方法です。使う情報源を選ぶ際は、回答に必要な事実があるか、誰が更新するか、担当者が出典に戻れるかを確認します。次の表は、情報源ごとの回答案での役割と見直すきっかけの例です。格納先や更新頻度は固定の要件とせず、現在の管理方法と更新責任に照らして選びます。
| 情報源 | 回答案での役割 | 見直すタイミング |
|---|---|---|
| 製品FAQ | よくある質問への基本説明 | 製品情報や説明の変更時 |
| 過去の問い合わせ対応 | 対応の背景や類似ケースの確認 | 対応方針を見直したとき |
| マニュアル・ヘルプページ | 操作や仕様の案内 | 内容の改訂時 |
| 価格表・サービス仕様 | 条件に関わる事実の参照 | 条件の変更時 |
同じ種類の情報が複数ある場合は、参照する版と更新担当をそろえます。根拠が見つからない場合は、回答案を推測で完成させず、担当者へ確認を促します。価格や契約条件を含む場合は、現在有効な資料と照合してから送信を判断します。照合できなければ送信へ進めず、資料の管理担当に確認します。
Slackと外部AIをつなぐ構成を選ぶ
Workflow Builder内のステップだけでは必要な処理を組めない場合、外部のAIとつなぐ構成を検討します。ここで混同しやすいのは、通信の向きです。Slackのワークフローから外部AIへ情報を送る経路と、外部で作った結果をSlackのワークフローへ戻す経路は、別の仕組みで組みます。
送る経路と戻す経路を分ける
| 向き | 仕組み | 役割 |
|---|---|---|
| Slack → 外部AI（送信側） | Deno Slack SDKのカスタム関数。外部のAPIを呼び出し、結果をワークフローの変数として返す | 問い合わせ本文や日報をAIへ渡し、出力を後続のステップで使えるようにする |
| 外部 → Slack（戻し側） | Webhookで開始するワークフロー | 外部で処理した結果を、HTTP POSTでSlackのワークフローへ渡して開始する |
Webhookは外部サービスからSlackへリクエストを送ってワークフローを開始する仕組みで、Slackから外部AIへ送る経路ではありません。「Webhookを使えばAIを呼べる」と整理すると、送信側の実装が抜けます。外部AIを呼び出すには、後述のカスタム関数のほか、中間サーバーや連携サービスを使う構成を選びます。
送信側の例：Deno Slack SDKのカスタム関数
Slackの公式チュートリアル「Check the weather using a custom step in Workflow Builder」（確認日2026年10月24日）は、カスタム関数で第三者のAPIを呼び出し、その結果をWorkflow Builderのステップとして使う例を示しています。題材は天気情報の取得ですが、外部APIを呼ぶ形はAIでも同じです。チュートリアルでは、フォームの入力、外部APIを呼ぶカスタム関数、結果を送るメッセージの3つのステップでワークフローを組みます。
設計の判断に関わる要点だけを挙げます。コマンドやコードの詳細は公式チュートリアルに従ってください。
- 関数の入出力を先に決める。 関数には入力の項目と出力の項目を定義します。AIの場合は、渡す本文と、返ってくる回答案の形にあたります。
- 呼び出し先を許可する。 外部のAPIを呼ぶ関数は、アプリのマニフェストに呼び出し先のドメインを
outgoingDomainsとして加える必要があります。許可する先は担当者が把握できる範囲に絞ります。 - APIキーは画面に出さない。 チュートリアルでは、キーを環境変数のファイル（
.env）に置いています。ワークフローの画面やチャンネルには貼りません。 - 試す環境と本番を分ける。
slack runで動かすローカル版と、slack deployで配備する本番版は別のアプリです。公式は、Workflow Builderのステップを本番の関数に切り替え、入力の変数を結び直すよう案内しています。
AIのAPIに置き換える場合は、呼び出し先のドメイン、入力に渡す項目、返す出力の形を、各提供元の公式ドキュメントで確認して自社で定義します。この記事は、AIのAPIを呼ぶコードそのものは扱いません。
戻し側：Webhookで開始するワークフロー
2026年10月時点のSlack公式ヘルプ（確認日2026年10月24日）では、Webhookで開始するワークフローに次の条件があります。外部で作ったAIの結果をこの条件に合わせて整えられるかを確かめます。SlackのWebhookでは、外部サービスからHTTP POSTリクエストを送信してワークフローを開始できます。変数を追加したらHTTP本文のプレビューを確認し、外部サービスのJSON出力が本文内の値と一致することを確かめてください。
設計に影響するのは次の点です。
- 渡す項目は20個まで、平らな形にする。 変数は最大20個で、ネストされたJSONは使えません。外部側で、キーと値の組に整えてから送ります。
- 失敗を空の値で隠さない。 設定した変数がリクエストに含まれないとワークフローが失敗します。回答案の生成に失敗した場合は、空の値ではなく失敗を知らせる経路を用意します。
- リクエストURLを共有しない。 リンクを知っていれば誰でも開始できるため、共有チャンネルやチケットに貼りません。
- 送信は1秒に1件まで。 多数の問い合わせを一度に流す場合は、送信間隔を空けます。
（出典：SlackでWebhookから開始するワークフローを作成する）
公開前には、投稿先をテスト用チャンネルにして変数が意図どおり入るかを確かめ、確認できてから本番のチャンネルに切り替えます。手順の詳細は上記の公式ヘルプに従ってください。
中間処理の置き場所を選ぶ
カスタム関数を使わず、外部の処理でAIを呼び、結果をWebhookで戻す構成もあります。どの仕組みを選ぶかは、接続先の数だけでなく、データの変換方法と障害時の調査方法で判断します。
| 選択肢 | 適する状況 | 導入前に確認すること |
|---|---|---|
| Deno Slack SDKのカスタム関数 | Slackのステップとして外部APIを呼びたい | 開発とデプロイを担う担当者、Slack CLIの利用環境があるか |
| クラウドの関数（AWS Lambda、Cloud Run functions（旧Cloud Functions）など） | 独自の処理やデータ変換を組み込みたい | 保守担当と障害時の確認方法があるか |
| ノーコードの連携サービス | 画面上で連携の流れを組み立てたい | 必要な接続先とデータの受け渡しに対応するか |
| 自社管理の仕組み | 実行環境やデータ管理を自社で扱いたい | 環境の更新や監視を担う担当者がいるか |
料金は提供元の改定やプランで変わるため、金額は載せていません。検討する方式を絞った後、必要な機能、利用量、データの扱い、現在の利用条件と見積もりを、AWSやGoogle Cloudなど提供元の公式情報で確認します。条件を確認できない方式は選定を保留します。Google Cloudの関数はドキュメント上「Cloud Run functions」の名称で案内されています（出典：Functions overview、確認日2026年10月24日）。
データの受け渡しと失敗時の引き継ぎ
問い合わせ本文や申請内容から、AIの処理に必要な項目を選びます。個人情報や機密情報が含まれる場合は、連携先へ渡す範囲と保存の扱いを確認してから入力を設計します。必要な情報を渡せない場合は、AIに任せる処理を縮め、担当者が原文を確認する経路を残します。
AIの応答が得られない、結果がSlackへ戻らない、同じ内容が再送される、といった場合の扱いも決めます。受付済みの案件を識別できる情報と処理状態を記録し、担当者が原文を見て手動で対応できるようにします。処理に時間がかかる場合は、受付と結果通知を分ける方法があります。通常の処理だけでなく、失敗後の再実行も試し、受付済みの案件と再実行した案件を担当者が区別でき、重複処理を避けられることを確認してから利用範囲を広げます。
ワークフロー設定の要点
ここまでの判断が済んだら、Workflow Builderの設定に進みます。詳しい操作は公式ヘルプに従い、ここでは設計に影響する要点に絞ります。
開始方法を選ぶ
開始方法は、業務のきっかけに合わせて選びます。開始方法が決まっても、必要な情報が次の処理へ渡せるとは限りません。実際の入力項目と受け渡し先を確かめてから、後続のステップを組み立てます。
| 業務のきっかけ | 向く開始方法 |
|---|---|
| メンバーが申請や問い合わせを出す | リンクから（Slack内でのみ開始でき、Slackの外でリンクをクリックしても動作しません） |
| 外部のフォームや、外部で処理した結果を受け取る | Webhookから |
| 日報の提出依頼など、決まった時刻に動かす | スケジュールにもとづく |
| 投稿やリアクションを起点に確認を依頼する | 指定したキーワードを含む投稿、絵文字リアクション |
（出典：Slackでワークフローを作成する、確認日2026年10月24日）このほかにも開始方法があります。利用できる機能はプランやワークスペースの設定で変わるため、必要な開始方法とステップが使えるかを管理者と照合してください。
人の確認を挟む
確認を飛ばして次の処理が走らないように、AIの出力を担当者が見てからボタンで次へ進める形にします。Slackのヘルプでは、ボタンを置くとメンバーがクリックするまでワークフローが先に進まず、クリックできるメンバーの限定や有効期限も設定できると案内されています。ただし、制限できるのは自分のワークスペースのメンバーに対してだけで、Slackコネクトで参加している外部の人は制限リストに追加できません（出典：同上）。外部サービスのアクションを使うコネクタや、組織専用のカスタムステップは、アプリの承認や開発者の許可が必要です。操作の手順は公式ヘルプに従ってください。
公開前に管理者と権限を決める
ワークフローには、作成者と同じ権限を持つワークフローマネージャーを追加できます。申請や問い合わせのように扱う情報が限られる業務では、公開前に使える人の範囲を確認し、保守を引き継げるマネージャーを複数人置きます。Webhookで開始するワークフローは、オーナーと管理者が作成できるメンバーを制限できるため、作成を担う担当者には事前に権限を依頼します。
Slackでの対応結果をCRM（HubSpot）に残す
Slack上の承認や回答案は、その場では便利でも、顧客や取引と結び付いていなければ後から探せません。CRMのHubSpotにはSlack連携があり、Slackでの作業とCRMの記録をつなげられます。2026年10月時点のHubSpot公式ナレッジベース（確認日2026年10月24日）に記載されている範囲を整理します。
| できること | 公式ナレッジの記載 | 記録の設計での使い方 |
|---|---|---|
| レコードの作成 | Slackのメッセージから、HubSpotのタスク、チケット、メモを作成できる | 問い合わせへの対応方針をメモに、要対応の依頼をタスクやチケットに残す |
| 関連付け | 作成したタスクやチケットに、コンタクトや会社を関連付けられる（取引では「関連付けを追加」は使えず、取引ステージの更新が表示される） | 対応履歴を顧客の画面から追えるようにする |
| 通知 | メンションやフォーム送信、タスクの割り当て・リマインダーなどの通知をSlackで受け取れる。非公開チャンネルで受け取るには、先にHubSpotアプリをそのチャンネルに追加する | 担当者がSlackを見ながら、対応の抜けを防ぐ |
| Breeze Assistant | Slack上で、CRMレコードやSlackスレッドの要約、タスクやメモの作成ができる | 長いやり取りを要約し、記録として残す |
（出典：HubSpotとSlackを連携する、Slackでレコードを管理する、Slackで通知を管理する。いずれも英語版の記載に基づく）
連携の設定には、HubSpotのスーパー管理者またはアプリマーケットプレイスの権限と、Slackワークスペースの管理者権限が必要です。また、この連携で接続できるSlackワークスペースは1つだけです。
この記事で扱う申請、日報、問い合わせは、いずれも「誰の、どの案件の記録か」が後から問われる業務です。たとえば問い合わせの回答案を担当者が確認して送ったら、その内容と判断をHubSpotのメモとして顧客に関連付けます。Slackでの作業を、顧客の履歴に残るところまでを1つの流れとして設計すると、チャンネルを遡らなくても対応の経緯を確認できます。HubSpotでの顧客情報の整理や、Slack以外の接点も含めた記録の設計を検討する際は、StartLinkにご相談ください。
継続して使える運用ルールを整える
ワークフローは作成後の変更も業務の一部です。入力項目、参照情報、担当者が変わったときに、誰がフローを見直すかを決めておきます。フローの作成者、変更担当、問い合わせ先を共有し、変更する際は、何を変えたかだけでなく、どの問題を解決するための変更かも残します。処理が止まったときに調べられるよう、入力、連携先、処理結果、エラーを確認する方法を決めておきます。
条件分岐を増やしたくなったら、先に既存のフローを担当者が説明できるか確かめます。説明できない場合は、条件と例外の扱いを整理してから追加します。
AIの出力に誤りがあれば、元の入力が足りないのか、参照情報が古いのか、指示や分類ルールが曖昧なのかを分けて調べます。入力の問題はフォーム、情報の問題は更新担当、出力の問題は指示や検索方法を見直します。直した後に同じ種類のケースを確認し、担当者が使える状態になったか判断します。
よくある質問
Slack Workflow Builderは無料プランで使えますか？
2026年10月時点で、Slackのヘルプはワークフローの作成を有料プランで利用できる機能として案内しています。無料プランでの可否や設定条件は、Slackのプラン案内とワークスペースの設定で確認してください。使いたい開始方法とステップを先に書き出し、管理者と利用可否を照合してからフローを設計します。
Workflow BuilderからAI APIを呼び出せますか？
Slackの公式チュートリアルには、Deno Slack SDKのカスタム関数で外部のAPIを呼び出し、その結果をWorkflow Builderのステップとして使う例があります（天気情報の取得が題材）。AIのAPIを呼ぶ場合も、この形で呼び出し先と入出力を定義する構成が考えられます。外部で処理した結果をSlackへ戻すときは、Webhookで開始するワークフローを使います。構成を選ぶ前に、保守担当と障害時の手動対応も決めます。
問い合わせの回答をAIに自動送信させてもよいですか？
まず回答案として担当者へ渡し、元の問い合わせと参照情報を照合してから送信する運用を設計します。根拠がない、情報が古い、条件が異なる場合は送信へ進めず、担当者が確認します。見つかった誤りは情報源やAIへの指示の見直しに使います。
日報要約の精度をどう改善できますか？
入力欄と要約の出力項目をそろえ、担当者が元の日報と比較します。情報自体が入力されていなければフォームを、入力されているのに要約から抜けるならAIへの指示を見直します。修正後に同じ観点で比較し、対応に使えるか確かめます。
Webhook連携で気を付けることは何ですか？
受け渡す項目と形式、処理が失敗した場合の通知先、再実行時の扱いを確認します。Webhookは外部からSlackのワークフローを開始する仕組みで、1秒につき1件のリクエストに制限されています。想定する受信量に対応できない場合は、送信間隔を空けるか、受付と後続処理を分ける構成を検討します。
まとめ
Slack Workflow BuilderとAIを組み合わせるときは、最初に載せる業務と載せない業務を判断し、そのうえで開始条件、入力、AIの処理、人の判断、結果の記録を順に決めます。申請では承認理由を残し、日報では要約から対応担当を決め、問い合わせでは根拠を確認してから回答を送ります。外部AIとの連携では、Slackから送る経路と結果を戻す経路を分けて設計します。
StartLinkは、AI活用を人の判断を置き換えるものではなく、判断の質を上げる投資として捉えています。業務への組み込みも、最初に確認する担当を決め、結果を見て段階的に広げる進め方が、定着と安全性の両面で効果的です。
最初の一歩として、自社の業務を判断の表に当てはめ、載せる候補を1つ選んでください。通常の処理と入力不足などの例外をたどり、原文とAIの出力を比較して、問題が入力・参照情報・AIへの指示のどこにあるかを見極めます。担当者が結果を確認でき、例外を引き継げるなら利用範囲を広げます。どちらかが曖昧なら、該当する箇所を直して再度試します。企業様によって最適な形は異なります。あわせて、Slackでの対応結果をCRMに記録する場所を1つ決めると、どの業務でも履歴が残ります。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
業務のフローを決めた後、AIに外部の情報を渡す仕組み、データを分析に使う方法、日常的な表計算の作業への取り入れ方を検討する際は、次の記事も参考にしてください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
