Claudeでフィードバックを複数チャネル横断で分析する

Coworkに複数チャネルのフィードバックをまとめて渡す

顧客の声は1か所に集まりません。通話の文字起こし、Slackの雑談、CRMの失注メモ、Linearのバグ報告。担当者が別々に読むと、同じ不満が4回別の顔で現れているだけなのに、4つの小さな声にしか見えません。Claude Cowork(以下Cowork)は、これらのソースを同時に読み、頻度とチャネルをまたぐ重なりから優先度を出す作業に向いています。

Coworkは複数のフィードバック源に同時接続し、並行してパターンを探せます。ローカルフォルダの通話記録、Slack、CRM、Linearを一度の指示でまとめて読ませ、テーマの頻度・チャネル横断のパターン・代表的な引用を整理させる、という使い方です。Pro・Max・Team・Enterpriseの有料プランで利用できます。

指示文はソースの列挙と出力形式を分けて書く

指示文で決まるのは「何を集めるか」だけでなく「何が返ってくるか」です。効果が出る指示文には共通の型があります。ソースを個別に列挙し、欲しい出力の形(頻度・チャネル横断パターン・引用・優先順位)を明示します。

複数ソースからのフィードバックを統合して、顧客が本当に求めているものを理解したい。 ソース: 通話記録(ダウンロードフォルダに散在)、Slackの#customer-feedbackと#support-questions、Salesforceの商談メモと失注理由、Linearの機能要望とバグ報告。 全ソースを横断する主なテーマとパターンを見つけてほしい。ソースごとの件数、チャネル横断パターン、代表的な引用を出し、頻度とビジネスインパクトで製品アイデアに優先順位をつけてほしい。

この指示文を投げると、Coworkはまず集計軸や重視するテーマについて質問し、サイドバーに作業計画を出してから実行に移ります。手を止めて質問に答えるほど、後段の集計が使える形に整います。

集計はソースごとの内訳まで返る

実際の出力は「モバイルアプリの不具合(計57件、通話11・Slack31・CRM1・Linear14)」のように、テーマごとにソース別の件数が並ぶ形になります。チャネルをまたぐパターンも別枠で出ます。4ソース全てに現れるモバイルアプリの不満は「高シグナル」、CRMの失注メモに偏って出るSSO連携の不足は件数こそ少なくても「収益シグナル」として扱われる、という分け方です。件数の少なさだけを見て切り捨てると、失注に直結する声を落とします。

優先順位づけの最終行は「モバイルアプリの安定性」「Okta SSO連携」「レポートのカスタマイズ」のように、頻度とビジネスインパクトの両方から数件に絞られた形で返ってきます。

サブエージェントが複数ソースを並列に読む

Coworkには、1つの依頼を複数の作業に自動分割し並列処理するサブエージェントの仕組みがあります。通話記録・Slack・CRM・Linearを同時に読ませる場面はこの仕組みと相性がよく、指示文に「並列でサブエージェントを立てて」と書き添えると、ソースごとの読み込みが同時に走ります。呼び出しはユーザーが直接操作するものではありません。複雑なタスクを渡したときにClaudeが必要に応じて組み立てます。「この契約書を要約して」のような単発の依頼では分割する材料がなく、サブエージェントは動きません。ソースが4つに分かれているフィードバック分析は、まさに分割の材料が揃っている依頼です。仕組みの詳細はCoworkサブエージェントの使い方にまとめました。

サブエージェントを使う複合作業は、通常のチャットより使用量の消費が大きくなります。4ソース横断の分析を日常的に回す運用にするなら、Settings > Usageで消費の推移を確認しておくと、制限に引っかかる前に気づけます。

接続元ごとの扱いを早見表で確認する

ソースによって、接続の重さも読み取れる範囲も違います。

Connectorの承認モードはManual・Auto・Skipの3段階です。フィードバック分析のように読み取りが中心の作業ではAutoでも実務上の摩擦は小さく、書き込みを伴う作業に切り替えるときだけManualに戻す使い分けが安全です。Connectorの権限設計はClaude CoworkのConnectors一覧で扱っています。

『高シグナル』をどう見極めるか

件数だけを見て優先順位を決めると、単に発言量が多いチャネルの声が過大評価されます。Slackで日常的に愚痴を言う文化のあるチームなら、Slackの件数は他チャネルより自然に膨らみます。見るべきは件数の絶対値ではなく、複数のソースに独立して現れているかどうかです。通話でも、Slackでも、Linearの起票でも同じ不満が出ているなら、それは特定チャネルの発言量に引きずられた数字ではなく、複数の経路で別々に観測された事実です。

CRMの失注メモのように、そもそも発生件数が少ないソースに出るシグナルは軽視しやすい落とし穴です。失注メモは商談が壊れた案件だけに残るので母数が小さく、件数の多い他チャネルに埋もれます。それでも収益への影響を判断するなら、件数の少なさより「何に紐づいて出ているか」を優先して読む場面があります。

出てきたテーマをさらに掘り下げる

最初の集計で終わらせず、同じ会話の中で掘り下げる指示を重ねられます。

• 特定テーマの全件を引く: 「モバイルアプリの言及を4ソース全てから全件引いてほしい。誰が、いつ、何をしようとしていたか、どれくらい困っていたかまで含めて」
• ロードマップ案を書かせる: 「この分析をもとに、Q1のロードマップ案を1ページで。チャネル横断のシグナルの強さとビジネスインパクトで優先順位をつけ、根拠になる引用も入れて」
• 特定顧客の発言を追う: 「Acme社が全ソースでどう言っていたか教えてほしい。通話・Slack・CRMメモから全部引いて、直接フォローアップできる形にして」

進捗パネルには、どのソースを読んでいるか、何が見つかっているかがリアルタイムで表示されます。特定のソースからの収穫が薄いと感じたら、作業の途中でも軸を足したり絞ったりできます。

ソース同士の言い分が食い違ったらどうするか

通話では「価格が高い」という理由で失注したと語られていたのに、CRMの失注理由欄には「機能不足」と記録されている、といった食い違いは珍しくありません。営業担当が本音を拾いきれず記録を簡略化することも、顧客側が担当者には言いにくい理由を話すこともあります。Coworkはこうした食い違いを自動で解消してくれるわけではなく、集計上は両方が別々のテーマとして計上されます。

食い違い自体を無視せず、指示文に「ソース間で説明が食い違っている場合は両方を並べて出してほしい」と加えておくと、矛盾を勝手に一本化されずに済みます。矛盾が見えたら、それ自体が「営業の記録と顧客の本音がずれている」という、集計結果よりも価値のある発見になることがあります。

実務で気をつけたいこと

ローカルの通話記録フォルダを渡す場合、Coworkはアップロードを経由せず、共有したフォルダの中身をそのまま読みに行きます。フォルダを閉じたり別の場所に移したりすると参照が切れるため、分析の間はフォルダを動かさないようにします。

Slack・CRM・LinearはConnector経由なので、事前に接続と権限付与が済んでいる必要があります。CRMのオブジェクト権限がユーザー個人のアクセス範囲に紐づく場合、Coworkから見える商談メモも同じ範囲に絞られます。全社の失注理由を横断したいときは、権限を持つアカウントで接続するか、管理者に組織単位の接続を依頼します。個人アカウントの接続範囲のまま分析すると、一部のチームの声しか拾えていないのに全社の傾向であるかのように見えてしまう点に注意します。

集計結果はあくまで1回の読み取りの切り取りです。Slackのメッセージが後から編集・削除された場合や、CRMのオブジェクトが更新された場合は、次に分析をやり直すまで反映されません。四半期ごとの優先順位づけのように定期的に使う運用なら、Coworkスケジュールタスクの作成方法で同じ指示文を定期実行に載せる方法もあります。手作業で集計していた頃の頻度をそのまま踏襲する必要はありません。

分析を1回きりで終わらせず、四半期ごとに同じ指示文で回すなら、前回結果との差分も見たくなります。「前回の分析結果を覚えているなら、今回増えたテーマ・減ったテーマも教えてほしい」と付け加えておくと、単発の集計が定点観測に変わります。同じ会話を続けている間は、前回の出力をClaudeが参照できるためです。

まとめ

Coworkに複数チャネルのフィードバックをまとめて渡すと、単独のソースでは埋もれていた、複数チャネルに横断的に出ている不満が可視化されます。指示文でソースと出力形式を明示し、サブエージェントで並列に読ませ、出てきたテーマをフォローアッププロンプトで深掘りする。この3段階が基本の型です。件数が少なくても複数ソースに偏って出るシグナルは、優先順位づけで見落とさないよう注意します。担当者の勘に頼っていた優先順位づけを、ソース横断の裏付け付きで説明できる状態に変えるのが、この使い方の実質的な価値です。会議で「なぜこれが最優先か」と聞かれたときに、根拠となる件数と引用をその場で示せます。