Slackの報告・申請を自動集計！スプレッドシート活用の公式ワークフロー

「Slackで報告や申請を集めているが、後から探せない」
「重要メッセージを台帳化したいが、手作業で転記している」
「リアクションで受付したいが、集計が面倒」

Slackは日々のやり取りが集まる一方で、情報が流れやすく、あとから「いつ・誰が・何を言ったか」を追うのが大変になりがちです。特に、報告や申請のように“後で参照することが前提”の情報は、スレッドやリアクションだけで運用すると、後から苦労しやすくなります。

この記事では、Slackの情報をGoogleスプレッドシートに自動で集計し、台帳として使える状態に整える方法を解説します。

▼Slackの情報が流れて困るなら、workrunで“台帳化”がはじめやすい
Slackはスピード感のある共有に強い一方で、重要な情報ほど流れて埋もれやすいという弱点があります。
「依頼がどこにあるか分からない」「報告が追えない」「対応状況が見えない」など、情報が蓄積されないことで起きるムダは意外と無視できません。その結果、結局スプレッドシートに転記して一覧化するといった作業が発生しがちです。

workrunなら、Slackとスプレッドシートを含む複数ツールをつないで、記録・通知などをワークフローとして自動実行できます。

Slackとスプレッドシートをつなぐと、「流れる情報」を「使えるデータ」に変えられます。単にログを残すだけでなく、申請の一覧化や集計、担当割り当ての起点にできるため、“後工程が止まらない運用”を作りやすくなります。

Slackの投稿は便利ですが、チャンネルが増えるほど過去ログの探索コストが上がります。たとえば #daily-report に毎日報告を書いていても、「今月分だけ集計したい」「誰が未投稿か確認したい」となった瞬間に、検索だけでは限界が出ます。

投稿をスプレッドシートへ行追加しておけば、日付・投稿者・本文を列で持てるので、後からフィルタや集計がしやすくなります。問い合わせ対応の履歴を残す用途でも、「どの問い合わせが未完了か」「誰が担当したか」を可視化しやすくなり、Slackの“流れ”に依存しない状態が作れます。

Slack運用では、完了マークや確認中マークなどを用い、リアクションをステータス代わりに使うことがよくあります。ただ、リアクションは便利な反面、「誰がいつ押したか」を後で一覧にしようとすると、確認が手間になりがちです。

リアクションを起点にスプレッドシートへ記録できると、受付の証跡を“台帳として残す”運用に寄せられます。たとえば、申請投稿に完了マークが付いた時点で受付済みにして担当へ通知し、同時にシートに受付日時と対応者を残す、といった形にすると、抜け漏れの確認がラクになります。

Slackのワークフロービルダーで入力フォームを作っておくと、申請や報告を“型”で集められます。自由記述のメッセージと比べて、項目が揃うため、あとから検索や集計をする前提の業務に向きます。

入力内容をそのままスプレッドシートの列に割り当てれば、「申請→一覧化→集計」が最短で成立します。たとえば備品申請で「申請者」「品目」「理由」「希望日」などをフォーム化し、回答を台帳にしておくと、月次の集計や差し戻しが圧倒的にやりやすくなります。

スプレッドシートは台帳として優秀ですが、“見に行かないと気づけない”問題が起きがちです。締切が近いタスクや在庫数の変化など、重要な変化ほど、更新を起点にSlackへ通知できると見落としが減ります。

たとえば「在庫が閾値を下回ったらSlackへ通知する」「対応ステータスが未完了のまま一定時間経過したらアラートする」といった形にすると、シートを開く頻度を増やさずに運用の安定性を上げられます。Slackに“見る場所”を寄せることで、台帳運用が回りやすくなります。

Slack×スプレッドシート連携は、大きく「Slack公式で作る」か「ノーコードでつなぐ」かの2択で整理すると迷いが減ります。
まずは公式機能で“最短で動く形”を作り、要件が増えたらノーコードで分岐や通知、記録の拡張をする、という順番が現実的です。

Slack公式のワークフロービルダーでは、Googleスプレッドシートのステップを追加して、ワークフローからデータ送信や取り込みを行えます。特に「フォーム入力→スプレッドシートに行追加」の導線は、申請や報告を台帳化する用途と相性がよく、まず試しやすい方法です。

一方で、公式機能は“できる範囲が明確”なので、後工程の通知分岐や例外対応まで作り込むと限界が出やすいこともあります。まずは「入力を揃えて台帳に残す」をゴールに据えると、失敗しにくくなります。

ノーコード連携は、「トリガー（きっかけ）→アクション（処理）」を組み合わせて、複数ツールを横断した運用に拡張しやすいのが特徴です。
たとえば、Slack投稿をシートに書くだけでなく、条件に応じて担当へDMしたり、別チャンネルへ要約を共有したり、台帳に受付番号を振ったり、といった“運用として必要な一手”を足しやすくなります。

Slack公式で最初の型を作り、運用上の詰まり（通知漏れ、担当不明、記録不足）が見えてきたタイミングでノーコードツールへ移ると、過不足なく設計できます。

ここでは、Slack公式のワークフロービルダーで「入力→スプレッドシート行追加」を作る流れを解説します。

ワークフロービルダーのGoogleスプレッドシート連携を使うと、ワークフローのステップとして「スプレッドシートの行を追加（Add a spreadsheet row）」を設定できます。これにより、Slack側のフォームで入力した値を、そのままスプレッドシートの列へ割り当てて記録できます。

たとえば、日報で「案件名」「今日やったこと」「詰まり」「明日の予定」を入力させ、そのまま日付と投稿者名と一緒に台帳にする、といった形が作れます。自由投稿よりも項目が揃うので、あとから“集計する前提の運用”がやりやすくなります。

まずはサイドバーから「ワークフロー」にアクセスし、右上の「新規」から「ワークフローを構築する」を選択します。

ワークフローのトリガーとなるイベントを選択します。

今回は、Slackの「キーワードを含むメッセージが投稿された時」をイベントに設定します。

対象となるチャンネルを選択し、トリガーにしたいキーワードを入力します。

トリガーとなるイベントが設定できたので、次はステップを追加します。

サイドバーから「Google Sheets」を探し、「スプレッドシートに追加する」を選択します。

初回はGoogleアカウントとの連携が必要となります。画面の案内にしたがい、内容を確認したうえで承認を進めてください。

アカウント連携が完了したら、Slackと連携するスプレッドシートとそのシートを選択します。

スプレッドシートに追加する値を、右の｛｝マークから選択します。メッセージのテキストの他、メッセージ送信者などが選択できます。

最後に、右上の「公開する」を選択すれば完了です。ワークフローを編集したあとも、必ず公開ボタンを押すようにしてください。

指定したSlackのチャンネルにトリガーとなる「スプレッドシート」を含めてメッセージを投稿したところ、無事、指定したシートに投稿者とメッセージ内容が記録されました。

Slack公式のスプレッドシート連携は、データが「空の行」にのみ追加される仕様です。スプレッドシートに書式設定済みのセルやドロップダウンがある場合は、その“最後の書式セルの直下”が追加位置になるため、見た目上の空白行があっても、思った場所に入らないことがあります。

もう一点の注意は、スプレッドシートに追加される日時がUTC+0で扱われ、現時点ではタイムゾーン調整ができない点です。日本時間で運用していると「深夜に記録されたように見える」などのズレが起きるため、台帳の日時列は“表示形式”や補助列で補正する、といった対策を前提に考えるのが安全です。

ここでは、Slack公式で作った“入力→記録”を起点に、もう一段運用へ寄せたい場合の考え方を整理します。ポイントは「記録できる」だけで満足せず、「次に誰が動くか」「いつまでに動くか」「例外はどうするか」まで含めて回せる状態を作ることです。

Slack投稿を台帳に残すだけなら公式機能で足りることも多いですが、実務では“その後”が問題になります。たとえば、申請が台帳に残っていても、担当が気づかない、対応期限が曖昧、完了の定義がない、という状態だと結局回りません。

ノーコードツールが向いているのは、「Slack投稿→シート記録」に加えて、条件に応じた通知、担当者の割り当て、未対応のリマインド、完了時の更新など、運用の“つなぎ”をまとめて設計したいケースです。現場のやり方に合わせて後から調整しやすい点も、継続運用では有効となります。

ノーコード連携では、Slackメッセージをスプレッドシートへ追加するだけでなく、スプレッドシートの新規行を検知してSlackへ通知する、といった双方向の連携も組みやすくなります。これにより、「入力したら記録される」だけではなく、「記録されたら誰かが動く」状態まで作りやすくなります。

また、リアクションをトリガーにして台帳へ書き込む、特定のキーワードやフォーム項目で通知先を分岐する、といった“現場あるある”の要件にも寄せられます。Slackは運用が増えるほど例外が増えがちなので、最初から完璧を目指すより、運用の詰まりを1つずつフローに吸収していくほうが定着につながるでしょう。

Slackとスプレッドシートの連携は、作った瞬間よりも“運用が回り続けるか”で価値が決まります。通知や台帳化が個人の工夫で止まってしまうと、担当者が変わった途端に運用が崩れてしまうためです。
workrunのようにフローとしてつなげておくと、判断や手作業が混ざりやすい運用ほど、継続しやすくなります。

workrunを導入することで、以下3つのメリットが受けられます。

・Slackの投稿を自動で記録・蓄積できる
・報告・申請・問い合わせを台帳化できる
・「行の追加」「シート更新」から、Slack通知・共有までを自動化できる

各メリットについて、詳しく解説します。

Slackは投稿が流れやすく、あとから必要な情報を探したり、手作業で記録したりする運用では抜け漏れが起きがちです。

workrunなら、特定チャンネルへの投稿や指定したキーワード、特定のリアクションをトリガーに、スプレッドシートへ自動で行を追加できます。
たとえば「対応依頼」「障害報告」「確認が必要」といった投稿だけを自動で拾い上げ、日時・投稿者・内容を整理した形で蓄積することも可能です。

重要な情報を人が判断して転記する必要がなくなるため、記録の精度を保ったまま、運用の負担を増やさずに情報管理を続けられます。

報告や申請をスプレッドシートで管理しようとしても、手作業での転記が前提だと忙しい時期ほど未記録が増えやすくなります。

workrunを使えば、Slackのワークフロー入力や定型フォーマットでの投稿を起点に、台帳への登録までを自動化できます。
入力された内容はそのまま決められた列に反映されるため、形式のばらつきや書き漏れを防ぐことができます。

報告や申請が送信された時点で記録が完了するため、「あとでまとめる」作業をなくし、常に最新の状態で台帳を維持できます。

スプレッドシートに記録しても、更新に気づかなければ対応が遅れてしまうことがあります。

workrunなら、スプレッドシートの行追加や特定列の更新をトリガーに、関係者のSlackへ自動で通知できます。
たとえばステータスが「未対応」から「対応中」に変わったタイミングで担当者へ通知したり、新しい行が追加されたらチーム全体に共有したりといった使い方も可能です。

台帳の更新がそのまま次のアクションにつながるため、確認漏れを防ぎながら、対応スピードの底上げにつなげられます。

Slackは“動きやすい入力の場”として、スプレッドシートは“整って残る台帳”として、それぞれ役割を分けると運用が安定します。最初は「報告・申請の自動集計」から始めると効果が見えやすく、チームにも定着しやすいでしょう。

慣れてきたら、次は通知やアラートを整えて「見落としゼロ」に近づけていくのがおすすめです。台帳の更新をトリガーにSlackへ共有できるようになると、情報共有が早くなり、対応の遅れや連絡のムダも減らしやすくなります。

▼「人が集計する」運用を減らして、チームで回すならworkrun
Slack×スプレッドシート運用で失敗しやすいのは、便利そうに見えても“誰かが手で整える前提”になっていることです。

workrunなら、Slackやスプレッドシートを起点に、定型の流れをワークフローとして自動実行できます。AIワークフローで判断・実行を支える形にすれば、ルールに沿った処理を継続しやすく、少人数でも運用が止まりにくい仕組みづくりに役立ちます。