Notion・Slack・Googleを機能表だけで見なかった理由
このテーマは比較表だけでは終わりません。Slackで受け、Google Sheetsで状態を見て、Notionで判断を残すAI業務自動化の流れを、担当者、例外、レビュー基準まで現場前提で具体化します。実務では最初の答えより、その答えをどこまで信じて次へ渡せるかが重要でした。
Notion・Slack・Googleの判断材料にした仕事
基準にした仕事は具体的にしました。Slack依頼がNotionタスク、Google Sheetsの状態行、担当者と期限付きのフォロー文につながるサポート引き渡し。そのうえで、入力、AIが触る範囲、確認する人、次に渡す場所を分けて見ました。Notion、Slack、Google Sheets、Google Apps Script、AI workflow automationは、その流れを短くし、確認を重くしない場合にだけ意味があります。
Notion・Slack・Googleで確認した項目
| 見た点 | 判断基準 | 失敗のサイン |
|---|---|---|
| 入力 | AIが扱えるだけの材料がそろっているか | 足りない文脈を質問せずに推測する |
| 人の確認 | 承認、修正、差し戻しが短時間でできるか | 担当者が最初から読み直す |
| 引き渡し | 文書、表、チケット、業務flowへ渡せるか | 次の人が形式や意味を直す |
| 再現性 | 別の材料でも同じ手順で動くか | 1回目だけよく、2回目から崩れる |
Notion・Slack・Googleの確認中に残したもの
| 根拠 | 確認したこと | なぜ重要か |
|---|---|---|
| 入力 | Slack依頼がNotionタスク、Google Sheetsの状態行、担当者と期限付きのフォロー文につながるサポート引き渡し。 | 仕事はツール名ではなく、入ってくる材料から始まります |
| 確認点 | 誰が確認し、何を差し戻せるかを見ました | 確認者がいないと、自動化に見えるだけです |
| 失敗メモ | テキスト転記は成功しても、重複行と古い担当者が残り、結局Slackで再確認する状態になりました。 | うまくいかなかった実行を一つ残すと、範囲を絞れます |
Notion・Slack・Googleでよく崩れるところ
弱いのは最初の回答ではありません。回答の後にある引き渡しです。このテーマでよく起きる失敗は、テキスト転記は成功しても、重複行と古い担当者が残り、結局Slackで再確認する状態になりました。きれいな下書きは開始点であって、運用可能という証拠ではありません。
Notion・Slack・Googleなら私ならこう残す
私なら、まずSlack依頼、Notionプロパティ表、Sheets行形式、重複チェック、エスカレーション規則を残します。そのうえで、人が短時間で確認できるかを見ます。確認に毎回時間がかかるなら、モデルを変える前に自動化する範囲を狭めます。
Notion・Slack・Googleの適用前チェックリスト
- AIに渡す入力を一文で書く。
- 結果を承認、修正、却下する人を決める。
- 出力が次に行く場所を決める。
- 成功例だけでなく、失敗例を一つ残す。
- 生成速度ではなく確認時間を見る。
- 次の人が毎回作り直すなら、その自動化はいったん止める。
確認した資料
変わりやすい情報は、公式文書、製品ページ、変わりやすい主張を支える出典メモを基準にしました。価格、モデル提供範囲、機能は動くので、意見と根拠を分けて扱います。
現場で使うなら、まず役割を分ける
Notion、Slack、Google SheetsをAIでつなぐと聞くと、最初に「どのツールを中心にするか」を考えがちです。けれど、そこから入るとだいたい散らかります。Slackには通知が増え、Sheetsには古い状態が残り、Notionにはきれいだが読まれないページがたまります。
私なら先に役割を決めます。
Slackは仕事が入ってくる場所であり、人に戻す場所です。Google Sheetsは今どうなっているかを見る運用台帳です。Notionはなぜそう判断したのかを残す場所です。AIはその間に入り、依頼を分類し、スレッドを短くし、不足情報を出し、次に送るメッセージの下書きを作ります。
派手ではありません。ただ、業務自動化はこのくらい地味な分担のほうが残ります。
現場での判断
「SlackとNotionを連携しました」という報告だけでは、仕事がよくなったかどうかは分かりません。
見たいのは別のことです。依頼が入ったとき、どこから来たのか、誰が持っているのか、今どの状態なのか、どの根拠で判断するのか、次に何をするのかが見えるか。
これが見えないなら、自動化ではありません。作業場所が増えただけです。
この組み合わせでは、Slackに即時性、Sheetsに状態管理、Notionに判断記録を持たせるのが扱いやすいです。Slackに全部残すと流れます。Sheetsに全部書くと文脈が薄くなります。Notionだけでキューを回すと、更新が重くなることがあります。
まず作るならこの流れ
最初から全社の仕組みにしないほうがいいです。私は「社内依頼の受付」から始めます。プロダクト要望、顧客影響のある問い合わせ、データ修正、ベンダー確認、運用上の例外など、誰かが引き受けて判断しなければならない仕事です。
流れはこうです。
- 決めたSlackチャンネルまたはスレッドに依頼が入る。
- AIがメッセージと必要な直近スレッドを読む。
- AIが一行要約、依頼種別、緊急度、不足情報、担当者候補を作る。
- Google Sheetsに一行を追加し、運用台帳に残す。
- 判断が必要な案件だけNotionページを作る。
- Slackには担当者、次アクション、SheetまたはNotionリンクだけ返す。
- 定期チェックで止まった行、担当者のない行、根拠不足の行を拾う。
この構成を選ぶ理由は、会話、状態、判断を一つのツールに押し込まないからです。
各ツールに任せる範囲
| ツール | 任せること | 任せないこと | 実務ルール |
|---|---|---|---|
| Slack | 受付、短い確認、引き継ぎ、例外通知 | 長く残す運用記録の全部 | 明日も必要ならSlackの外に出す |
| Google Sheets | キュー、状態、担当者、日付、優先度、指標 | 長い判断理由と最終決定の履歴 | 進行中の仕事は一行で見えるようにする |
| Notion | 文脈、判断メモ、根拠リンク、変更履歴 | 早い雑談や大量通知 | 判断が必要なときだけページを作る |
| AI | 要約、分類、不足情報の確認、返信下書き | 最終承認、顧客向け返信、静かな権限変更 | AIは準備し、人が受け取る |
こう分けると、「最新版はどこですか」という質問が減ります。状態はSheets、理由はNotion、元の会話はSlackです。
Google Sheetsの運用台帳
最初の台帳は退屈なくらいでいいです。AIが埋められるからといって列を増やすと、運用側が見なくなります。
| 列 | 目的 | 例 |
|---|---|---|
| request_id | Slack、Sheets、Notionを結ぶ番号 | OPS-2026-0619-004 |
| source_channel | どこから来た依頼か分かる | #customer-ops |
| source_ts | 元のSlackスレッドに戻る | 1718764720.000300 |
| request_type | ルーティングと集計に使う | billing, bug, vendor, data, policy |
| one_line_summary | 一行で内容を思い出す | 契約金額とCRMランクが食い違う |
| owner | 担当者不在を防ぐ | Sato |
| priority | うるさい仕事と危ない仕事を分ける | P1, P2, P3 |
| status | 動いているかを見る | new, waiting, reviewing, done |
| missing_info | 不確実な点を出す | 契約IDがない |
| risk_flag | 自動送信してはいけない案件を示す | customer impact |
| notion_url | 判断ページに飛ぶ | notion.so/… |
| next_action | 担当者の次の一手 | 15時までに契約ID確認 |
| updated_at | 止まった行を見つける | 2026-06-20 10:40 |
大事なのは凝ったAI列ではありません。担当者、状態、不足情報、リスク、次アクションです。ここが曖昧なら、つないでも仕事は軽くなりません。
Slack通知は短くする
Slackの自動通知は、長くなった瞬間に嫌われます。長文が何度も流れると、人は通知を見なくなります。
私はまず三種類だけにします。
| 通知 | 送るタイミング | 形 |
|---|---|---|
| 受付完了 | 行が作られたとき | 「OPS-004として登録。担当候補: Mina。不足: 契約ID。」 |
| レビュー依頼 | リスクや不確実さがあるとき | 「顧客返信前に確認が必要。返金額と文言が曖昧です。」 |
| 停滞通知 | 状態が動かないとき | 「OPS-004が24時間waitingです。次アクションが未入力です。」 |
よいSlack自動化は、AIっぽく話しません。落ち着いた運用担当者のように、必要なことだけ伝えます。
Notionは判断があるときだけ作る
Notionは判断の記録に向いています。ただし、Slackの依頼すべてにNotionページを作ると、すぐに二つ目の受信箱になります。
最初のテンプレートはこれで足ります。
| セクション | 内容 |
|---|---|
| Context | 何が起きたか、なぜ重要か |
| Source links | Slackスレッド、Sheet行、根拠資料、顧客記録 |
| Decision needed | 人が決めるべきこと |
| AI draft | AIが作った要約や返信案 |
| Human decision | 承認、差し戻し、修正、追加確認 |
| Follow-up | 担当者、日付、次の運用行動 |
| Change log | レビュー後に変わったこと |
このページは行動を変えるときだけ価値があります。誰も読まないなら、作らないほうがましです。
具体例
顧客に誤った更新金額のメールが送られたとします。営業はCRMに古いランクが残っていると言い、経理はSheetsから出したファイルで請求書を作ったと言います。顧客は今日中に修正版を求めています。
仕組みがないと、Slackの長いスレッドと個別DMで仕事が崩れます。
この流れなら、AIはスレッドを読み、billing / customer impactに分類します。SheetsにはP1、customer-facing risk、担当候補、契約ID不足を入れます。顧客に出す文面が関わるので、Notionページを作ります。Slackには「契約IDと現行価格ランクを確認するまで顧客返信は送らない」と短く返します。
AIが顧客対応を完了したわけではありません。誰が何を確認するかを早く見えるようにしただけです。現場ではそれが効きます。
AIが止まるべきところ
AIは要約だけではもったいないです。ただ、最終運用まで任せると危ないです。
| AIの作業 | 任せる | 止める |
|---|---|---|
| 依頼分類 | 信頼度メモ付きの下書き分類 | 敏感なグループへの静かなルーティング |
| Slack要約 | 元スレッドリンク付きの要約 | 元スレッドの代わりに扱う |
| 優先度提案 | 下書き値として入力 | 法務、財務、顧客影響案件の最終判断 |
| Notion文脈作成 | 下書き作成 | 承認済みにする |
| Slack返信下書き | 内部確認用の草案 | 顧客へそのまま送る |
| Sheets行更新 | 状態や不足情報の更新 | 行の削除や非表示 |
| フォロー通知 | 見える通知 | 期限をこっそり変える |
戻せない仕事、顧客、金額、権限、法務につながる仕事は、人の担当とレビュー跡を残す。これは譲らないほうがいいです。
失敗基準
この自動化は、接続の数ではなく運用状態で判断します。
- Slack通知は増えたが完了行が増えない。
- まだ「誰が担当ですか」と聞かれる。
- Sheetsのstatusを誰も信じていない。
- Notionページはあるが、決定は個別DMで行われる。
- AI要約が肝心な一文を落とす。
- 担当者がフィールド修正ばかりしている。
- 停滞通知が多すぎて無視される。
- 顧客向け文面は毎回ほぼ書き直しになる。
2週間でこれが三つ出たら、範囲を狭めます。Slack通知を減らす、Notion作成条件を上げる、AIが行を作れる条件を厳しくする。だいたいそこから立て直します。
導入順
一度に大きく入れると、失敗したときに理由が見えません。チャンネル一つ、依頼種別一つ、Sheet一つ、Notionテンプレート一つで始めます。
| 期間 | 目的 | 合格ライン |
|---|---|---|
| 1週目 | Slack依頼をSheetsに残す | 実依頼の90%が5分以内に行になる |
| 2週目 | AI要約と不足情報を出す | 担当者が全文を読まずに状況をつかめる |
| 3週目 | リスク案件だけNotion化 | ページ数は少ないが重要な判断は残る |
| 4週目 | 停滞通知を入れる | 通知が不満ではなく更新につながる |
| 5週目 | 指標を見る | 処理時間、手戻り、担当明確性、引き継ぎ漏れが改善する |
見るべき指標はAI精度だけではありません。依頼が消えないか、担当が早く決まるか、レビュー時間が減るか、後から判断を追えるかです。
自動化前に聞くこと
ツールをつなぐ前に、会議で五つだけ確認します。
- どのSlackチャンネルからだけ仕事を作るのか。
- 状態の正本はどのSheetなのか。
- どの条件でNotionページが必須なのか。
- AIが承認なしに書いてよいフィールドはどこまでか。
- AIの結果が怪しいとき、どこで止めるのか。
ここに答えられないなら、連携は早いです。ツールの準備と運用ルールの準備は別物です。
よくある質問
NotionとGoogle Sheetsのどちらを正本にするべきですか？
最初はSheetsを状態の正本、Notionを判断の正本にします。Sheetsはキューを見やすく、Notionは文脈と根拠を残しやすいからです。
コードなしで作れますか？
作れます。ノーコード自動化ツールと固定テンプレートだけでも始められます。ただし設計は同じです。Slack受付、Sheets台帳、Notion判断ページ、人のレビュー、戻り道が必要です。
AIはどこから使うべきですか？
分類、要約、不足情報確認、引き継ぎメッセージの下書きからです。時間は減らせますが、モデルが業務判断を持っているように見せないことが大事です。
いつ人に渡すべきですか？
顧客影響、金額、法務文言、アカウント権限、削除、根拠が曖昧な案件では止めます。遅くするためではなく、危ない部分を見える場所に出すためです。
最小構成は何ですか？
Slackチャンネル一つ、Sheet一つ、依頼種別一つ、担当者フィールド一つ、状態フィールド一つ、不足情報フィールド一つ、週次レビュー一つです。これで効かないなら、大きくしても効きにくいです。
業務フロー
このガイドがつながる業務フロー
読んでいるガイドが、どの業務フローに関係するのかを確認できます。
自動化プラットフォーム、アプリビルダー、エージェントビルダー、会計ツール、汎用AIアシスタントを比較するルートです。
関連トピックを見る- 向いている場合
- 単体ツール購入、社内ワークフロー構築、広いプラットフォーム導入で迷うチーム
- 向かない場合
- 繰り返しのきっかけ、担当者、入力がまだ決まっていない場合は、自動化より先に業務の形を整える方がよいです。
参照した公開情報
報道内容、公式文書、政策背景、製品情報、変わる可能性のある主張を確認するために参照した公開情報です。
- Notion API introduction Notion
- Notion API create a page Notion
- Notion API query a database Notion
- Slack sending and scheduling messages Slack
- Slack chat.postMessage Slack
- Slack conversations.history Slack
- Google Sheets API values guide Google for Developers
- Google Sheets API append values Google for Developers
- Google Apps Script triggers Google for Developers
