【非エンジニアのためのClaude/Claude Codeシリーズ】 SlackとHubSpotに散らばった案件情報を、Coworkで一発で「読める資料」にした話
はじめに
クラスメソッドで営業をしている菊地と申します。
営業をやっている方なら共感してもらえると思うのですが、案件の情報ってあちこちに散らばりまくっています。
Slackの案件チャンネルにはヒアリング内容やキックオフ議事録がテキストで流れていて、提案書はPDFで共有されていて。さらにHubSpotには取引情報やお客様のコンタクト情報が入っていて、見積もりはスプレッドシートで......。
ツールも形式もバラバラです。
自分が担当している案件なら頭に入っているので、普段の業務では困りません。でも問題は、その案件の情報を「支援に入っていない人」に共有しなければならない場面です。
営業をやっている方だとこのような場面は多くあるかと思います。
たとえばこんなケースです。
- 担当者の異動で案件を引き継ぐことになった
- 上司に案件状況を報告するための資料を作りたい
- 他部門の協力を仰ぐために、案件の背景や経緯をまとめて共有したい
自分の頭の中にはあるけど、それを人に伝えられる形に整理するのが大変です。案件チャンネルを遡って、PDFを開いて、Canvasも確認して、必要な情報をピックアップして資料にまとめて......という作業に平気で30分〜1時間かかります。
今回、まさにこの状況が発生しました。営業部長が打ち合わせに同席することになったのですが、部長はこの案件の支援に入っていません。
打ち合わせ前に案件の内容をインプットしてもらう資料が必要
─ そこで「散らばった情報を集めて整理する」作業を Claude Desktop の Cowork モード にやらせてみたところ、形式がバラバラの情報を横断的に読み取って、5分でWordの資料にまとめてくれたので、その過程を紹介します。
前提：Cowork と MCP 連携（Slack + HubSpot）
Cowork は Claude Desktop に搭載されている、ファイル操作やツール連携をしながら作業を進められるモードです。MCP（Model Context Protocol）コネクタを接続すると、Cowork から外部ツールの情報を直接読み取れるようになります。
今回は以下の2つを接続しています。
- Slack MCP：案件チャンネルのメッセージ、PDF、Canvas を読み取り
- HubSpot MCP：取引（Deal）情報、コンタクト情報、取引ステージの履歴などを読み取り
MCP連携の設定方法は、シリーズの過去記事「営業ツールをClaude Codeにつないでみた（MCP連携編）」をご覧ください。
シチュエーション
架空の案件を使って説明します。（※実際に業務で使ったものと同じ手順ですが、お客様情報保護のためデモ用のチャンネルを用意しています）
- お客様：株式会社△△（アウトドア用品EC企業）
- 案件：ECサイトのオンプレミス → AWS マイグレーション支援（4ヶ月）
- 状況：支援は完了済み。営業部長が次回打ち合わせに同席予定。ただし部長はこの案件の支援に入っていないので、事前にインプットが必要。
案件に関する情報が、複数のツール×複数の形式で散らばっています。
Slack 案件チャンネル内：
- テキストメッセージ：ヒアリング内容、キックオフ議事録、進捗報告、課題共有、クロージング報告......
- PDF：提案書（3ページ、背景・構成比較表・スケジュール・見積もり・体制）
- Slack Canvas：AWS構成情報（VPC設計、EC2/RDS/S3構成、監視設定、コスト情報）
HubSpot：
- 取引情報：案件名、金額、クローズ日
- コンタクト：お客様の担当者名、役職、メールアドレス
- 会社情報：業種、従業員数、URL
これを手動で全部追いかけて資料にまとめようとすると、1時間コースです。Slackだけでも大変なのに、HubSpotまで開いて情報を突き合わせるとなると......。
やってみた
1回目：シンプルに投げてみる
まずは深く考えず、こう投げてみました。
△△様の打ち合わせに営業部長が同席します。部長はこの案件に入っていないので、事前インプットが必要です。以下の案件チャンネルの情報とHubSpotの取引情報を読み取って事前インプット資料を作って
（案件チャンネルの Slack URL）
すると Cowork が動き始めます。
- Slack チャンネルのメッセージを時系列で読み込み
- チャンネル内で共有されている PDF（提案書）を検出して中身を読み取り
- Slack Canvas（AWS構成情報）も検出して読み取り
- HubSpot から会社名で取引情報・コンタクト情報を検索して取得
- 全部まとめて Word ドキュメントとして出力
出てきたのがこれです。
ここで一番驚いたのが、ツールも形式もバラバラなのに全部読んでくれるということです。
Slackのテキストメッセージ、PDF、Canvas、そしてHubSpotの取引情報。人間だったら「まずSlack遡って → PDFダウンロードして開いて → Canvas開いて → HubSpot開いて取引検索して」と何ツール・何画面も行き来するところを、Cowork は全部シームレスに処理してくれました。
しかもSlack URLしか渡していないのに、メッセージ内の会社名からHubSpotの取引を自動で探しに行ってくれました。「この情報は足りないからHubSpotも見てみよう」と自分で判断している感じです。
数分後、Word ファイルが出力されました。
お客様概要、案件概要、支援内容、経緯のタイムラインなど、一通りの情報はちゃんと入っています。PDFの提案書に書かれていた構成比較表の情報も、Canvasに記載されていたAWSリソースの詳細も、テキストメッセージの進捗報告も、そしてHubSpotの取引金額やお客様の担当者情報も、全部一つの資料にまとまっています。
ただ、「多くの案件に関わっている営業部長が限られた時間で読む」という目的を考えると、ちょっと情報量が多すぎる感じがしました。技術的な構成情報が細かすぎて、営業目線ではどこに注目すればいいかが分かりにくい。
2回目：読み手を意識したプロンプトに改善
そこで、プロンプトをこう変えてみました。
△△様の打ち合わせに営業部長が同席します。部長はこの案件に入っていないので、事前インプットが必要です。
以下の案件チャンネルとHubSpotの取引情報から、営業部長が打ち合わせ前の5分で読める事前インプット資料を作ってください。
ポイント：
- 技術詳細よりも「お客様が何に困っていて、何を実現して、どう喜んでいるか」のストーリーが伝わることを重視
- 当日に部長が会話に入れるよう、お客様のフィードバックや成果を分かりやすく
- AWS構成の詳細は不要。ただし「どんなAWSサービスを使ったか」のサマリーはほしい
- HubSpotの取引情報から、契約金額やお客様担当者の役職も入れて
（案件チャンネルの Slack URL）
2回目の結果：格段に良くなった
出てきた資料がこちらです。
1回目と比べて、明らかに「読み手が営業部長」であることを意識した構成になりました。具体的な変化はこんな感じです。
構成の変化：
| 項目 | 1回目 | 2回目 |
|---|---|---|
| 冒頭 | お客様基本情報の表 | 「3行で分かるこの案件」のサマリー |
| 技術情報 | VPC設計やEC2スペックまで詳細 | 「EC2+RDS+S3を使ったAWS移行」程度のサマリー |
| 成果 | タイムラインの中に埋もれている | 独立したセクションで強調（コスト30%削減、セール時ダウンゼロ） |
特に良かった点：
- 冒頭の「3行サマリー」のおかげで、部長が「要するにどういう案件か」を一瞬で把握できる
- お客様のフィードバック（セール時のサーバーダウンがゼロに/運用の属人化が解消/コスト約30%削減）がクロージングMTGのメッセージから抽出されて、成果セクションに整理されている
- 提案書PDFに記載されていた構成比較表は、技術詳細を省きつつ「Before/Afterが分かる」レベルに要約されている
プロンプトの工夫で分かったこと
2回やってみて気づいたのは、「誰が読むか」と「何のために読むか」をプロンプトに入れるだけで、出力が劇的に変わるということです。
1回目のプロンプトは「情報を読み取って資料を作って」とだけ書きました。これだとCoworkは「チャンネルの情報を漏れなく整理する」方向に動きます。結果として、情報は正確だけど全部盛りの資料になる。
2回目は「営業部長が」「5分で読める」「ストーリーが伝わる」と書きました。すると、同じ情報源から作っているのに、取捨選択と強弱のつけ方がまったく違う資料になります。
「形式がバラバラ」が強みに変わる
今回の案件では、情報が ツール × 形式 の2軸で散らばっていました。
- Slack：テキストメッセージ + PDF添付 + Canvas
- HubSpot：取引情報 + コンタクト + 会社情報
人間がやる場合、これは明確に「面倒くさい」要因です。Slackを遡って → PDF開いて → Canvasも見て → HubSpotにログインして取引を検索して → 全部を頭の中でつなげて → Wordにまとめる。ツールと情報ソースが増えるほど、作業時間は増えます。
でも Cowork にとっては、情報ソースが多いほど「良い資料」が作れます。 Slackのメッセージからは経緯やニュアンスを、PDFからは正式な提案内容を、Canvasからは技術的な構成情報を、HubSpotからは契約金額や顧客の組織情報を、それぞれ引き出して組み合わせてくれる。
つまり、人間にとっての「散らばっている」は Cowork にとっての「情報が豊富」といえます。ツールをまたいで散らばっている情報が多い案件ほど、Cowork の威力が発揮されるというのは発見でした。
ちなみに、今回はSlackとHubSpotの2つですが、MCPコネクタを追加すれば Google Drive や Notion なども同じように読み取れます。営業が日常的に使うツールが増えるほど、Cowork の守備範囲も広がるということです。
普段からチャンネルに情報を残すことが大事
良い資料が出てくるかどうかは、チャンネルの情報量に依存します。ヒアリング内容や進捗がこまめに共有されているチャンネルほど、充実した資料になります。
「チャンネルに情報を残す」こと自体が、将来の自分やチームメンバーへの投資だということを改めて感じました。
まとめ
| 項目 | Before（手動） | After（Cowork） |
|---|---|---|
| 所要時間 | 30分〜1時間 | 約5分 |
| やること | Slack遡る → PDF開く → Canvas見る → HubSpot検索 → 頭でまとめる → Word作成 | プロンプト1つ投げるだけ |
| 対応できるソース | 自分で全ツール開いて読む | Slack（テキスト・PDF・Canvas）+ HubSpot を自動で横断 |
| 資料の質 | 時間がないと雑になりがち | プロンプト次第で読み手に最適化できる |
「Slack の案件チャンネルURL を渡すだけ」で、Slack内の情報（メッセージ・PDF・Canvas）に加えてHubSpotの取引情報まで横断的に読み取り、打ち合わせ前の事前インプット資料を自動生成できました。プロンプトに「誰が」「何のために」読むかを入れるだけで、出力の質が劇的に変わるのもポイントです。
営業の仕事は「情報を集めて、整理して、伝える」 の繰り返しです。その「集めて、整理する」 部分を Cowork に任せることで、「伝える」ことにもっと時間を使えるようになりました。ぜひ試してみてください。
