SkillStack Lab（スキスタ）運営者のスタックです。
Slackを毎日使っていると、「あの仕様変更って、結局なぜ決まったんだっけ？」「先月のスレッドで誰かが重要なことを言っていたはず」と、過去ログを探す時間が増えてきませんか。
私も会社の一部プロジェクトや外部ベンダーとのやり取り、副業・ブログ運営、AIコミュニティなどでSlackを日常的に使っています。
Slackはリアルタイムのコミュニケーションには便利ですが、重要な意思決定まで他のメッセージと一緒に流れていくのが悩みでした。
そこで私が実際に試したのが、重要なSlackメッセージだけを選んでGoogle Docsへ蓄積し、Gemini Notebook（旧NotebookLM）で後から横断分析する方法です。
ポイントは、Slackの全メッセージをAIへ送らないことです。
最初は人間が重要情報を選び、必要になったら「リアクション絵文字 → Zapier → Google Docs」という自動集約へ広げます。
スタックSlackとNotebookLMの連携で一番大事なのは「全部自動化すること」ではありません。AIへ渡す前に、人間が“残す価値のある会話”を選ぶことです。
この記事では、私が実際に使ったZapier連携、SlackログのJSON前処理、仕様書や用語集を追加して分析精度を改善した事例、実務で使っているプロンプト、セキュリティ上の線引きまで解説します。
なお、NotebookLMは2026年7月に「Gemini Notebook」へ名称変更されました。本記事では検索で現在も使われているNotebookLMという旧名称も併記します。
- SlackとNotebookLMを組み合わせる現実的な方法
- リアクション絵文字を使ったZapier自動集約の作り方
- 送信者・日時・URLを残すべき理由
- 半年分・数千メッセージのJSONログを分析した実例
- Slackログだけでは文脈不足になる場合の改善方法
- 仕様変更や未解決課題を抽出する実用プロンプト
- 会社のSlackログを扱う際のセキュリティルール
NotebookLMとSlackは直接同期するのではなく「必要な情報だけ渡す」
最初に前提を整理しておきます。
現在のGemini Notebookの通常のソース追加画面には、Slackを直接選んでWorkspace全体を同期する機能はありません。
Gemini Notebookが対応しているGoogle Docs、テキスト、Markdownなどを中継するのが分かりやすい方法です。
私の現在の基本フローは次の通りです。
- Slack上で重要な発言・スレッドを人間が選ぶ
- Google DocsまたはCopied Textへ保存する
- Gemini Notebookへソースとして追加する
- 決定の経緯・未解決課題・変更理由を分析する
- 確定した結論だけNotionやSharePointなどへ戻す
最初からSlack全体を自動取得する仕組みを作る必要はありません。
数件の重要メッセージならコピー＆ペーストでも十分です。
まず手動で「何を残すべきか」の基準を作り、その基準が固まってから自動化する方が失敗しにくいです。
私が使ったSlack→Zapier→Google Docsの自動集約
メッセージ量が増えてから、私はZapierを使って重要メッセージの保存を一部自動化しました。
ただし、チャンネルへ投稿された全メッセージを自動保存していたわけではありません。
Slack上で「これは後から残したい」と判断したメッセージに、:bookmark:や:memo:などのリアクション絵文字を付ける運用にしました。
そのリアクションをZapierのトリガーにして、指定したGoogle Docsへ自動追記します。
Zapierで保存していた5つの情報
Google Docsへ保存する際、メッセージ本文だけを残すのはおすすめしません。
私は次の形式で1メッセージを1ブロックとして追記していました。
保存していた項目は、
- 投稿日時
- 送信者
- チャンネル名
- メッセージ本文
- 元SlackメッセージのURL
です。
特に重要なのが、元メッセージへのURLです。
Gemini Notebookの分析結果を読んで、「本当にこの発言だったのか」と確認したくなったとき、元のSlackスレッドまで戻れます。
スタック本文だけ保存したときは、「誰が・いつ言ったのか」を後から追えず困りました。AI分析以前に、一次情報へ戻れるメタデータを残すことが重要です。
Zapierではリアクションをトリガーにできる
ZapierのSlack連携には、メッセージへリアクションが追加されたことを検知する「New Reaction Added」トリガーがあります。
Google Docs側には既存文書へ文字を追記する「Append Text to Document」があるため、
Slackのリアクション → 必要な情報を取得 → Google Docsへ追記
という構成をノーコードで作れます。
最新の対応トリガー・アクションは、Zapier公式のSlack連携ヘルプで確認してください。
Google DocsをGemini Notebookへ追加して分析する
Slackから重要メッセージを集約したGoogle Docsは、そのままGemini Notebookのソースとして追加できます。
私の場合、ZapierによってGoogle Docsへ新しい情報が追記されたあと、必要なタイミングでGemini Notebook側のGoogle Driveソースを同期して最新状態へ更新していました。
Google公式でも、Driveから追加した対応ソースについて、必要に応じて「Click to sync with Google Drive」から手動更新できると案内されています。
最新のソース仕様は、Google公式「Gemini Notebookにソースを追加する」で確認してください。
ZapierがGoogle Docsへ追記したからといって、分析前の確認を省略しないようにしています。重要な判断をするときは、Gemini Notebook側でも最新ソースへ同期されているか確認します。
半年分・数千件のSlackログはMarkdownへ前処理した
リアクション方式は「これから残す情報」には向いていますが、過去のプロジェクトを振り返りたい場合は別の方法が必要です。
私は過去のプロジェクトチャンネル1〜2本、約半年分・数千件のSlackメッセージを分析したことがあります。
その際は、利用できるSlackログをJSON形式で取得し、Pythonで簡単な前処理をしました。
そのままJSONを入れずノイズを除去する
Slackのログには、分析には不要な情報も大量に含まれます。
私が除外したのは、例えば次のようなものです。
- 「〇〇さんがチャンネルに参加しました」などのシステム通知
- CI/CDの成功通知など大量のBotログ
- リアクションだけで本文のない情報
- 分析目的と無関係な定型通知
そのうえで、タイムスタンプと発言者を付けたMarkdownへ整形しました。
最終的には月単位やトピック単位に分け、2〜5個程度のMarkdownソースとしてGemini Notebookへ入れています。
巨大な全社ログを1ファイルへまとめるのではなく、今回知りたいテーマに関係する期間・チャンネルへ絞るのが私の基本です。
Slackログだけでは文脈不足になることがある
実際に使ってみて気づいたのが、Slackの会話だけでは背景情報が足りないケースです。
例えばSkillStack Labの記事企画やAIツールの検証では、Slack上で、
のような、関係者にしか分からない略称で会話することがあります。
このSlackログだけをGemini Notebookへ入れたところ、「A案」「B案」が何を意味しているのか十分に理解できず、時系列の要約が曖昧になりました。
仕様書と用語集を追加したら経緯を追いやすくなった
そこで、Slackログに加えて、
- ツールの仕様書PDF
- 略称・社内用語をまとめたGoogle Docs
を追加しました。
すると、「Slack上で言っているA案が仕様書上のどの機能を指しているか」を結び付けやすくなり、仕様変更の経緯を追う回答がかなり明確になりました。
Slackログを主役にしながら、その会話を理解するために必要な公式資料だけ補助ソースとして追加するイメージです。
「ログを大量に増やす」より、「ログを理解するための仕様書・用語集を足す」方が役立ったケースもあります。
Slackログ分析で実際に使っているプロンプト
Gemini NotebookへSlackログを入れたら、「要約して」だけではなく、知りたい目的を明確に指定します。
仕様変更の経緯を時系列で追う
実際に使っているプロンプトがこちらです。
「最終決定だけ」ではなく、旧案から変わった理由まで指定するのがポイントです。
これにより、新しくプロジェクトへ参加した人へ経緯を説明するときにも使いやすくなります。
まだ終わっていない課題だけ抽出する
もう一つよく使うのが、未解決課題の洗い出しです。
長いSlackスレッドでは、議論しただけで結論が出ていない項目が残りがちです。
ただし、AIが担当者を推測する可能性もあるため、最終結果は必ず元ログへ戻って確認しています。
Slack BotとNotebookLM分析は役割が違う
旧記事では「NotebookLM APIを使ってSlack Botを作る」という説明もしていましたが、ここは整理します。
私が実際にSlack Botを構築した際に使ったのは、NotebookLMのAPIではなくGemini APIです。
GASやPythonを使い、Slack上でBotへメンションするとGemini APIがその場で回答を返す仕組みを作りました。
これは本記事の「Slackログを後から分析する」用途とは別です。
| 用途 | 向いている仕組み |
|---|---|
| Slack上で質問して即回答 | Gemini API＋Slack Bot |
| 過去ログから経緯を深掘り | Gemini Notebook |
| 重要発言を自動蓄積 | Slack＋Zapier＋Google Docs |
リアルタイムBotの作り方については、GeminiとSlackを連携する方法で扱っています。
初心者は手動選別から始めるのがおすすめ
ここまで読むと、「最初からZapierで全部自動化した方が早いのでは？」と思うかもしれません。
私は逆だと考えています。
最初から全メッセージを自動保存すると、
- 挨拶
- 雑談
- Bot通知
- 途中で撤回された案
- 重複した情報
まで大量に蓄積されます。
その結果、Google Docs自体が「何でも入ったログ置き場」になり、後から何が重要なのか分からなくなります。
私がすすめる2段階の運用
| 段階 | 方法 | 向いている人 |
|---|---|---|
| 基本 | 人間がSlackメッセージを選び、DocsやCopied Textへ追加 | 初めて試す人・ログが少ない |
| 発展 | リアクション絵文字→Zapier→Google Docs | 保存基準が固まり、件数が増えた人 |
まず手動で運用すると、「うちのチームでは、どんな発言を後から残したくなるのか」が見えてきます。
その基準ができてから、リアクション絵文字を保存フラグとして自動化するのが私のおすすめです。
NotebookLMの操作方法だけでなく、生成AIを社内ナレッジ活用や業務改善へどう組み込むかまで体系的に学びたい方は、インターネット・アカデミーの生成AI講座を調査した記事も参考にしてください。NotebookLMを含む生成AIの業務活用や、AIエージェントなどへ学習を広げる場合の料金・講座内容・注意点を整理しています。
会社のSlackログを個人Googleアカウントへ持ち込まない
SlackとGemini Notebookを組み合わせる際、最も重要なのが情報管理です。
私は会社のSlackログを個人用のGoogle AI Proアカウントへ移すことはしません。
便利だからという理由で会社データを個人クラウドへコピーすれば、シャドーITや情報管理規程違反につながる可能性があります。
私がGemini Notebookへ入れないSlack情報
- DM（ダイレクトメッセージ）のログ
- 顧客や取引先の個人情報
- 採用・人事・評価に関する会話
- 未公開の財務情報・売上数値
- 銀行口座などの重要情報
- パスワード、APIキー、認証トークン
- サーバーの接続情報
- NDAの対象となる未公開のやり取り
会社データを分析する場合は、所属組織が利用を認めている会社管理のGoogle Workspace環境を使用し、社内の情報管理ルールを優先します。
Googleは対象となるWorkspaceユーザーについて、Gemini Notebookへのアップロード、質問、モデルの回答を人間のレビュアーによるレビューやAIモデルの学習に使用しないと案内しています。
ただし、これは「会社のどんなデータでも自由に入れてよい」という意味ではありません。
NotebookLMのAI学習・データ保護については、NotebookLMのオプトアウトとデータ学習の記事で詳しく整理しています。
Slack APIで大量取得するなら権限とレート制限にも注意
エンジニア向けには、Slack APIから会話履歴を取得して処理する方法もあります。
SlackのConversations APIには会話履歴を取得するconversations.historyがありますが、利用できるチャンネルはトークンやスコープによって異なります。
また、アプリの配布形態などによってAPIのレート制限も異なるため、「全社Slackを好きなだけ高速取得できる」と考えない方がよいです。
大量ログを扱う場合は、Slackの公式API仕様と所属組織の管理ルールを確認してください。
Slack APIの最新仕様は、Slack公式のconversations.historyドキュメントで確認できます。
NotebookLMとSlackの連携に関するよくある質問
まとめ｜Slackは会話、Gemini Notebookは「後から経緯を調べる場所」
SlackとNotebookLMを組み合わせる目的は、Slackを別のAIチャットへ置き換えることではありません。
私の現在の使い分けは次の通りです。
Slack
リアルタイムに議論する。
↓ 重要な発言だけ選ぶ
Google Docs / Markdown
日時・送信者・チャンネル・本文・URLと一緒に残す。
↓
Gemini Notebook
仕様変更の経緯、最終決定、未解決課題を横断分析する。
↓
Notion / SharePoint等
確定した決定事項を正式なナレッジとして保存する。
Slackは「流れる会話」、Gemini Notebookは「過去の会話から意味を掘り出す調査室」。
この役割分担にすると、すべてのSlackメッセージを無理にナレッジ化する必要はありません。
まずは次に重要なSlackメッセージが出たとき、手動で1件だけGoogle DocsやCopied Textへ残して、Gemini Notebookから経緯を質問してみてください。
「後で探したくなる情報」が分かってから自動化する。これが、私が実際に試して一番扱いやすかったSlack×NotebookLMの進め方です。
