いま多くの会社で、社内の情報が最初に流れる場所は、メールでも会議でもなくSlackです。だからこそ、データの異常や商談の動きをSlackに自動で流し込むこと、そして逆にSlack上の会話を業務データとして取り込むことに、大きな価値があります。この記事では、PassworkのSlackコネクタで「実際にできること」を、マニフェストに定義された操作に厳密に沿って整理し、BigQueryやSalesforceとつなぐデータ連携ユースケースまで紹介します。

01　Slackとは ── 社内の「神経網」になったツール

Slackは、チャンネルとスレッドを中心にしたビジネスチャットツールです。部署・プロジェクト・案件ごとにチャンネルを切り、会話をスレッドにぶら下げて整理する ── この構造のおかげで、Slackは単なる雑談の場ではなく、「いま社内で何が起きているか」が最初に流れ込む情報の神経網になりました。エンジニアからバックオフィス、経営層まで、業種や職種を問わず一日中開かれているのが実態です。

Slackの中には、実は二種類の価値あるデータが流れています。ひとつは、人が書き込む会話・問い合わせ・意思決定の記録。もうひとつは、各種システムが投げ込む通知・アラートです。つまりSlackは「人の声」と「システムの声」が同じ場所で交わる、数少ない接点なのです。

ところが現場では、この接点が十分に活かされていません。BIで異常を検知しても、それをSlackに届けるのは結局だれかが手作業。逆に、Slackに溜まった問い合わせや報告は、チャンネルの流れに沈んでいくだけで、集計や分析の対象になっていない ── 「気づくべき情報」と「Slack」のあいだに、まだ人手が挟まっているのです。ここを自動でつなぐのが、PassworkのSlackコネクタの役割です。

02　PassworkのSlackコネクタでできること

PassworkのSlackコネクタは、Slackへの「書き込み（出力）」とSlackからの「読み取り（入力）」の両方に対応しています。フローの出口にも入口にも置けるのが、通知系コネクタとしての強みです。実際に用意されている操作は、次の3つです。

出力：Slackへ「届ける」2つの操作

メッセージ投稿（slack_post_message）は、最も基本となる出力操作です。channel と text を指定すれば、フローの処理結果を任意のチャンネルへ一通の通知として送れます。「集計が終わったら担当チャンネルに結果を投げる」「条件に合致した行が見つかったら警告を出す」── フローの終端に置く“発射口”として使います。

スレッド返信（slack_reply_message）は、すでにあるスレッドへ続報をぶら下げる操作です。返信先のスレッドは thread_ts で指定しますが、ここがSlackコネクタのPasswork的に賢いところで、前段ノードが投稿したメッセージのタイムスタンプを、そのまま返信先として引き継げる設計になっています。たとえば「最初に概要を投稿 → 詳細を同じスレッドに返信」といった、一連の報告を一本のフローで時系列にまとめられます。チャンネルが通知で埋め尽くされず、関連情報がスレッド単位で整理されるのが利点です。

入力：Slackから「拾う」操作

メッセージ取得（slack_read_messages）は、Slackを“データソース”として扱う操作です。channel と取得件数 limit を指定すると、そのチャンネルの履歴をまとめて取得できます。取得できるのは本文だけではありません。投稿者・投稿時刻・リアクション・返信数・スレッドの紐づきといった情報も行データとして取り出せるため、「どの投稿が反応を集めたか」「いつ何が報告されたか」を後続の集計・保存ノードに渡して扱えます。Slackに沈んでいた会話を、分析できる構造データに変える入口です。

03　ユースケース：通知・連携・ログ取得

3つの操作が、業務のなかでどう効いてくるか。Slackらしい具体的なシーンで見ていきます。いずれも、Slackを単独で使うのではなく他のシステムと掛け算することで価値が立ち上がります。

① Slack × BigQuery／Tableau ── 異常を“待たずに”知る日次アラート

データ基盤に売上やKPIが溜まっていても、ダッシュボードは「見に行かないと気づけない」性質を持っています。そこで、DWH（BigQueryなど）から日次で数値を取得 → 前日比やしきい値で異常を判定 → 該当したものだけをSlackに投稿（slack_post_message）するフローを組みます。

たとえば「特定店舗の客単価が前週比で15%以上落ちた」「広告のCPAが目標を超えた」といった、本当に見るべき変化だけが毎朝Slackに流れてくる状態を作れます。全店舗のダッシュボードを毎朝めくる代わりに、Slackが「今日見るべきはこの店です」と先に教えてくれる ── そのDWH側をどう読むかはBigQuery連携 ── DWHを読む・SQLで引く・書き戻すで解説しており、異常検知の考え方はエラーの自動分析とも地続きで、Slackはその“出口”を担います。

② Slack × Salesforce ── 商談の動きを、その場で共有しスレッドで追う

営業現場では、SFAの中で起きた変化（大型商談がステージ進行した、重要なリードが新規登録された等）を、いかに早くチームへ共有できるかがスピードを左右します。Salesforceから対象レコードを取得 → 条件に合うものをSlackの営業チャンネルへ投稿（slack_post_message）しておけば、誰かがSFAを開いて気づくのを待つ必要がなくなります。Salesforce側の取り出し方はSalesforce連携 ── SOQLで取り出し外部キーでUpsertにまとめています。

さらに、続報があるたびに同じスレッドへ返信（slack_reply_message）を重ねれば、「この商談の経緯」がスレッド単位でまとまります。前段の投稿のタイムスタンプを引き継いでスレッドに紐づけられるので、フローを組むだけで案件ごとのタイムラインがSlack上に自然と積み上がっていきます。SFAの数字とSlackの会話が、はじめて同じ流れの上でつながります。

③ Slackを“データソース”に ── 問い合わせログを取得して蓄積・分析する

3つ目は、Slackを入力側に使うパターンです。社内の問い合わせチャンネルやカスタマーサポートのチャンネルには、「どんな質問が、どれくらいの頻度で来ているか」という貴重なデータが日々流れ込んでいます。しかし通常、それはチャンネルの履歴に沈んだまま分析されません。

slack_read_messagesでチャンネルの履歴を取得 → 投稿時刻やリアクションを含む行データとして、BigQueryやスプレッドシートへ蓄積するフローを組めば、Slackの会話が分析できる資産に変わります。「問い合わせの多い曜日・時間帯」「反応（リアクション）を集めた告知」などを後から振り返れるようになり、サポート体制やナレッジ整備の判断材料になります。蓄積したデータをさらにBIやAIに渡していく流れは、セグメントを配信チャネルへ戻すリバースETLとちょうど逆向きの「現場の声を集める」配管です。

04　まとめ：Slackを「業務フローの末端」にする

Slackは、人の声とシステムの声が交わる社内の神経網です。PassworkのSlackコネクタは、その神経網に対して「書き込む（投稿・スレッド返信）」と「読み取る（メッセージ取得）」の双方向をフローでつなぎます。

• 投稿（slack_post_message）で、データの異常や商談の動きを“待たずに”Slackへ届ける
• スレッド返信（slack_reply_message）で、続報を同じスレッドに重ね、案件ごとのタイムラインを残す
• メッセージ取得（slack_read_messages）で、Slackに沈んでいた会話を分析できるデータに変える

そしてその価値は、BigQueryやSalesforceなど他システムとの掛け算で最大になります。Passworkは単なる「Slack通知ツール」ではなく、業務データの流れの末端にSlackを置く連携の配管です。気づくべきことに、人が探しに行く前に気づける ── その状態を、フロー一本で作れます。