公式Slack MCPを使ってチームの日報を自動収集してみた — Chrome DevTools MCPを使ったスクレイピングから卒業した話
どーも、産業支援グループ小売流通ソリューション部の髙野です。
私がEMとして日々やっていることの一つに、デイリーミーティング前のチーム状況の把握があります。私のチームでは、Slackbotのリマインダーで日報スレッドを立てて、メンバーがスレッドに返信する形で日報を共有しています。
デイリーミーティングの前にこの日報スレッドの内容を手元に集めておくと、ミーティングでの議論がスムーズになります。そこで以前から日報の自動収集をClaude Codeを使って仕組み化していたのですが、最初に採用したChrome DevTools MCP方式にはいくつかの課題がありました。
そんな中、AnthropicがClaude Codeの公式プラグインとしてSlack MCPのサポートを追加しました。SlackのMCP専用エンドポイント（https://mcp.slack.com/mcp）にHTTP Streamable接続で直接つながり、チャンネルやスレッドの読み書きがAPIベースで行えます。
これを使えばChrome DevTools MCPの課題をすべて解消できると考え、日報収集の仕組みをSlack MCP方式に移行しました。その結果、驚くほどシンプルかつ安定した仕組みになったので、導入手順とBefore/Afterを交えて紹介します。
Chrome DevTools MCP方式の課題
もともとはChrome DevTools MCPを使い、ブラウザ経由でSlackの画面をスクレイピングして日報を取得していました。
Chrome DevTools MCPはブラウザの操作をプログラムから制御できるMCPサーバーで、Webページのナビゲーション、スクリーンショット取得、DOM操作などが可能です。「ブラウザで見えるものはすべて取れる」という万能感はあるのですが、日報収集という用途には過剰でした。
具体的には以下の課題がありました。
ブラウザの起動とログインが前提条件になる
Chrome DevTools MCPはブラウザプロセスに接続して動作するため、Chromeが起動していてSlackにログイン済みでないと動きません。定期実行時にブラウザが未接続だと日報収集コマンドがスキップされてしまい、「取れているときと取れていないときがある」という不安定な状態でした。
Slackの仮想リストとの戦い
Slackのメッセージ一覧は、画面に表示されている範囲外のメッセージをDOMからアンロードする仮想リスト方式を採用しています。そのため、単純にDOMを読むだけではスレッド内の全メッセージを取得できず、スクロール操作を挟みながらDOMを解析する必要がありました。
JavaScriptによるDOMパースのメンテナンスコスト
evaluate_script でJavaScriptを書いてDOMセレクタを指定し、メッセージを抽出していました。Slackの画面構造が変わると壊れるリスクがあり、実際に何度かセレクタの修正が必要になりました。
処理の流れとしては、navigate_page でSlackチャンネルを開き、take_snapshot でDOM構造を確認し、click でスレッドを開き、scroll でメッセージを読み込み、evaluate_script でDOMからメッセージを抽出する、という5ステップ以上の工程が必要でした。動くことは動くのですが、「正しい抽象度ではない」という感覚がずっとありました。
公式Slack MCPの導入
Anthropic公式マーケットプレイスの追加
まず、Claude CodeにAnthropicの公式プラグインマーケットプレイスを追加します。
Slackプラグインのインストール
マーケットプレイスを追加したら、claude-plugins-officialマーケットプレイスからSlackプラグインをインストールします。
これによりSlack MCPサーバーへの接続が設定されます。
OAuth認証
インストール直後、Slack MCPは △ Enter to auth の状態で表示されます。
Enterキーを押すと、認証を促す選択が表示されます。
「Authenticate」を選ぶと、ブラウザでSlackの認証が行われ、「Claude」Slackアプリに対して権限の許可を求める画面が開きます。
ここで対象のワークスペースを選択して「許可する」をクリックすると認証が完了し、そのセッションからSlackのチャンネルやスレッドにアクセスできるようになります。
利用可能なツールの確認
認証が完了すると、以下のようなツールが利用可能になります。
(Claude Codeの/mcpコマンドで確認できます)
slack_list_channels— チャンネル一覧の取得slack_read_channel— チャンネルの最新メッセージ一覧を取得slack_read_thread— スレッド内の全返信を取得slack_send_message— メッセージの送信slack_search_messages— メッセージの検索
今回の日報収集で使ったのは slack_read_channel と slack_read_thread の2つだけです。
公式Slack MCPへの移行
プラグインの追加と認証が完了すれば、あとは移行作業です。日報収集コマンドの定義ファイルの書き換えはClaude Codeにそのままやってもらいました。
実装の流れ
日報収集の処理は、以下の2ステップで完結します。
ステップ1: チャンネルからリマインダーを探す
slack_read_channel に対象チャンネルのIDと当日0時のタイムスタンプを渡して、チャンネルの最新メッセージを取得します。取得したメッセージの中から、Slackbotリマインダーの投稿を探し、その message_ts（タイムスタンプ）を取得します。
日報収集コマンドの定義ファイルでは、以下のように記述しています。
1. `slack_read_channel` でチャンネルの最新メッセージを取得
- channel_id: 対象チャンネルのID
- oldest: 当日 00:00 のUnixタイムスタンプ（JST）
- limit: 100
2. 取得したメッセージから当日のSlackbotリマインダーを探す
- リマインダーの `message_ts` を取得する
ステップ2: スレッドの全メッセージを取得する
slack_read_thread にチャンネルIDとリマインダーの message_ts を渡すだけで、スレッド内の全返信が取得できます。
3. `slack_read_thread` でスレッド内の全メッセージを取得
- channel_id: 対象チャンネルのID
- message_ts: ステップ2で取得したリマインダーの `message_ts`
- limit: 1000
4. 各メッセージから投稿者名、時刻、本文を抽出し、マークダウンファイルとして保存
取得した結果は以下のようなマークダウン形式で保存しています。
# 日報スレッド — 2026-03-25
- チャンネル: #project-channel
- 取得方法: Slack MCP (slack_read_thread)
- 取得時刻: 11:00
- 返信数: 5件
---
## メンバーA (10:15)
今日はNNNN機能の実装を進めます。昨日のレビュー指摘は対応済みです。
---
## メンバーB (10:22)
調査タスクの続き。午後にチームに共有予定です。
Chrome DevTools MCP方式では5ステップ以上必要だった処理が、公式Slack MCP方式では read_channel と read_thread の2ステップで完結しています。
Before / After
Chrome DevTools MCP方式から公式Slack MCP方式への移行で、以下のように改善しました。
| 観点 | Chrome DevTools MCP方式（Before） | 公式Slack MCP方式（After） |
|---|---|---|
| 前提条件 | ブラウザ起動 + Slackログイン済み | 不要（API直接通信） |
| 取得安定性 | DOM構造依存で壊れやすい | API直接アクセスで安定 |
| 定期実行 | ブラウザ未接続でスキップ頻発 | 確実に実行 |
| メンテナンスコスト | JS記述 + DOMセレクタ管理 | ツールを呼ぶだけ |
| 速度 | 数十秒（スクロール待ち含む） | 数秒 |
| 処理ステップ数 | 5ステップ以上 | 2ステップ |
特に定期実行の安定性は大きな改善でした。Chrome DevTools MCP方式では「ブラウザが起動していなかった」という理由で日報が取れていないことがあり、デイリーミーティング直前に手動で確認し直すことがありました。公式Slack MCP方式ではこの問題が完全に解消されました。
活用シーン
私は日報収集コマンドを1日3回、定期的に実行しています。
朝（9:00）: 前営業日の日報を最終回収
前日の夕方以降に追加された投稿を含めた最終版を取得します。朝イチで前日の状況を振り返り、当日の優先順位を考える材料にしています。
昼前（11:00）: デイリーミーティング前に当日の日報を取得
11:30のデイリーミーティングの前に、当日分の日報を取得します。メンバーが何に取り組んでいるかを事前に把握しておくことで、ミーティングでの議論をブロッカーの解消や意思決定に集中させることができます。
夕方（17:00）: 追加投稿の回収
日中に追加された投稿を回収します。その日の振り返りに活用しています。
3つの日報収集コマンドすべてを公式Slack MCP方式に移行しました。
注意点: OAuth認証とワークスペースの制約
公式Slack MCPを利用するには、
- 「Claude」Slackアプリの対象ワークスペースへのインストール
- OAuth認証によるSlackワークスペースへの接続
が必要です。
業務で利用する場合、ワークスペース管理者の承認が事前に必要になるため、導入を検討する際は管理者への事前相談を忘れずに行ってください。
また、公式Slack MCPのOAuth認証はワークスペース単位です。セッションごとに認証したワークスペースのチャンネルにしかアクセスできません。
組織によっては「全社」ワークスペースと「部門・プロジェクト」ワークスペースが分かれているケースがあります。私の部門もそのケースで、日報が投稿されるワークスペースと全社ワークスペースが異なるため、日報収集コマンドを実行するClaude Codeセッションで、対象ワークスペースへの再認証が必要でした。
複数のワークスペースを使い分けている方は、公式Slack MCPを使うClaude Codeセッションが、どのワークスペースで認証されるかを意識しておく必要があります。
まとめ
Chrome DevTools MCPによるブラウザ操作の自動化から、公式Slack MCPによるAPI呼び出しへの移行は、「正しい抽象度」への移行でした。
当初のブラウザ操作の自動化は「人間がやっていることをそのまま再現する」アプローチでした。一方、API呼び出しは「必要なデータを直接取得する」アプローチです。目的が「日報の内容を取得すること」である以上、後者のほうが適切な抽象度です。
MCP対応のツールが増えていくことで、これまでスクレイピング的な手法に頼っていた自動化が、よりシンプルで安定した形に置き換えられる場面は、他にもたくさん出てくるでしょう。
私としては、EMの情報収集を自動化することで、判断や意思決定に集中する時間を作ることに価値があると考えています。日報収集の自動化はその一歩です。チームの状況を把握するための「仕込み」を自動化して、デイリーミーティングという限られた時間をより価値の高い議論に使う。そのための道具として、公式Slack MCPへの移行は「摩擦を減らす」意味でおすすめです。
参考リンク
- Model Context Protocol（MCP）
- Connect Claude Code to tools via MCP - Claude Code Docs
- Slack MCP Server
- Anthropic公式プラグインマーケットプレイス（claude-plugins-official）
- Chrome DevTools MCP
（この記事は、ブログ作成AIエージェントを使って下書きを生成し、筆者が加筆・修正したものです）
