Claudeのタスクで営業パイプラインを維持

結論から：Claude のスケジュール実行タスク（Tasks）は、誰も会話を開始しなくても進行中の案件を定期的に見直せます。マルチエージェントの Dispatch は、多数の案件を一件ずつ直列に処理するのではなく並行して処理できます。この組み合わせはパイプライン衛生に本当に効きます——ただしエージェントは変更を提案し、書き込みは人間が承認する場合に限ります。

営業マネージャーなら誰でも、フォーキャストの数字が部分的にフィクションであることを知っていますし、その理由もだいたい分かっています。最終接触から三週間経った案件が「交渉中」のまま止まっている。進行中案件の三分の一で「次のアクション」が空欄。クローズ予定日はとうに過ぎ、誰も動かしていない。誰も怠けてはいません。パイプライン衛生は締め切りが決して来ない仕事なので、締め切りのある仕事に毎週負けるのです。

よくある対処は月曜のリマインドと四半期ごとの大掃除です。これは保ちません。劣化は連続的なのに、介入が周期的だからです。

本シリーズでこの回だけが、チャット＋API 連携ではなく Claude 自身のエージェント機能を軸にしています。パイプライン衛生に必要なのが、まさにその機能が提供する二つ——誰もチャット画面を開いていないときにも動くもの、そして九十件の案件を九十ターンかけずに見られるもの——だからです。

パイプライン衛生が、営業が手で直すより速く劣化する理由

CRM レコードはごく普通のかたちで古くなります。電話をして、メモは手帳に書かれる。見込み客が「三月の予算レビューの後にまた連絡します」と言い、誰もクローズ予定日を動かさない——その瞬間はフォーキャストの事実ではなく事務作業に感じられるからです。案件担当者が退職し、その案件が、一度も話したことのないマネージャーに一括で付け替えられる。

どれも二分で直せます。それが八十件あり、途切れなく発生し、発生した日にはどれも緊急ではない。これが問題の形であり、定番の対策が効かない理由でもあります。必須項目のルールは、営業に「何か」を入力させるだけで「本当のこと」を入力させません。四半期の大掃除は実施日に滞留を片づけ、その後八十九日かけて劣化します。

実際に効くのは、頻繁に走る地味な確認です。一〜二日ごとに、進行中案件すべてを対象に、「この十件はおかしい、理由はこう」という短いリストを出す。華やかさが皆無で反復が多い——無人実行のエージェントに向く典型です。

Claude の Tasks と Dispatch が実際にすること

ここでは二つの機能を正確に区別する価値があります。どちらを使っているかで価値が変わるのに、エージェント AI のマーケティング表現は両者を混ぜがちだからです。提供範囲はプランによって異なり、どちらも急速に進化しています。どちらかを前提に設計する前に、Anthropic の最新ドキュメントで自社プランの内容を確認してください。

スケジュール実行タスク——単発プロンプトではなく、定期的な無人実行

Task は、誰も会話を始めなくてもスケジュールどおりに走る指示です。些細に聞こえますが、そこが要点です。パイプライン衛生が失敗する理由は、古い案件の調べ方を誰も知らないからではなく、他に四件燃えている火曜日に誰も思い出さないからです。

無人実行で変わるのは能力ではなくリスクの性質です。自分で走らせるプロンプトは、出力を自分で読みます。誰が見ていようといまいと朝七時に走るプロンプトは、「誰も丁寧には読まない」前提で書く必要があります。つまり範囲は狭く、既定値は保守的に、出力は人が実際に見る場所——誰も開かないログではなく、メールや Slack チャンネル——に届けること。

Dispatch——多数の案件を並行して見るサブエージェント

二つ目はオーケストレーションです。調整役のエージェントがサブエージェントを立ち上げ、別々の部分を同時に処理させ、結果を集約します。パイプライン点検にはきれいに対応します。案件ごと（あるいはパイプラインの区分ごと）に一つのサブエージェントを割り当て、それぞれがその履歴を読んで見解を作り、直列ではなく並行で走ります。

実利は速度だけではありません。一件だけを担当するサブエージェントは、その案件の文脈だけを持つので、九十件を同時に頭に置こうとする一回の処理より判断が鋭くなります。代わりに各サブエージェントは自分の案件しか見ないので、「今四半期に本当に重要なのはどの三件か」のようなパイプライン横断の比較は、サブエージェントではなく調整役の工程に置きます。

コストは現実的な論点です。九十の並行サブエージェントは概ね九十件分のトークンを消費し、毎日実行なら月二十営業日分になります。範囲は意図的に絞ってください。毎晩システム全体を舐めるのではなく、金額がしきい値を超える進行中案件、あるいは十四日以上動きのない案件に限定します。

実務的なワークフロー：古びたパイプラインを日次更新に変える

この順番で組み立て、読み取り専用の段階を飛ばさないこと。

まず読み取り専用で、二週間続ける。CRM の読み取り権限だけを与え、書き込み権限は一切与えません。スケジュールタスクを毎朝走らせ、サブエージェントを進行中案件に展開し、ダイジェストを一本出す。どの案件が古びて見えるか、具体的に何がおかしいか、何を変更するつもりか。営業マネージャーにメールで届けます。

二週間続ければ、書き込み権限を与える前に知るべきこと——指摘が当たっているか——が分かります。三分の一が外れているなら、プロンプトを直すか、CRM のデータが想像より悪いかです。それを読み取り専用のダイジェスト段階で知るのはタダです。

判定基準を明示的に書く。「古い」は自明ではなく、モデルに定義を発明させるべきではありません。21 日間活動記録なし、クローズ予定日が過去、同一ステージの滞留がそのステージ平均の二倍超、金額しきい値以上なのに次アクションが空欄、と具体的に指定します。明示的な基準は実行のたびに一貫した出力を生み、それがダイジェストを行動に値するものにします。

項目ではなく履歴を渡す。ここでの言語モデルの価値は、レコードに紐づくメモ・メール・通話サマリーを読み、最後の会話が「これは第3四半期まで保留」で終わっているのにステージが「契約手続き中」のままだと気づくことです。項目レベルのルールにはこれが見えません。同時にここが、会話の内容をどこまで読ませるかを意図的に決めるべき地点でもあります。

書き込みを許すなら狭く、あるいは許さない。ダイジェストが二週間安定したら書き込みを検討してもよいですが、書き込み面は小さく保ちます。「AI 指摘済み」項目の更新、メモの追加、担当者へのタスク作成は、ステージやクローズ予定日の変更とはまったく別物です。フォーキャストに効く項目は恒久的に人間に残します。通用する原則はこうです——エージェントは人を促すものは書いてよい、数字を報告するものは書いてはいけない。

出力を権限のある人に届ける。誰も所有しない共有メールボックス宛のダイジェストは、静かに意味を失う仕事です。営業マネージャーに送り、既存の会議に名前のついた五分の議題として置きます。

Claude Tasks＋Dispatch vs CRM 標準のワークフロールール vs Zapier や API 連携

Claude Tasks と Dispatch は三つの中で唯一、非構造の内容——通話メモ、メールのやりとり、議事要約——を読み、レコードが実際に起きたことと合っているかを判断します。それが価値のすべてであり、リスクのすべてでもあります。判断は誤りうるし、誤った判断が本番レコードに書かれるのは更新漏れより悪い。必要な手がかりが文章の中にある場合に最適です。
CRM 標準のワークフロールール（Salesforce Flow、HubSpot workflows）は決定論的で、すでに払っているライセンスに含まれ、監査可能で、その範囲内では完全に信頼できます。21 日間活動がないことは教えてくれますが、最後のメールで先方が案件を棚上げしたと言っていたことは決して教えてくれません。項目条件で表現できる確認は、こちらを使ってください。同じ仕事なら AI エージェントより厳密に優れています。
Zapier や直接の API 連携はその中間です。トリガーでシステム間のデータを動かすのは得意、判断は苦手、そして作った本人より長く残る保守対象を生みます。AI 点検の *下* にある配管層——ダイジェストを Slack に届ける、承認済みフラグを書き戻す——としては妥当で、点検役としては不適です。

これで成果を出しているチームはたいてい三つとも使います。決定論的な確認は CRM ルール、判断は AI の点検、その間を運ぶ配管として単純な自動化。

うまくいかなくなる場所

もっともらしい推測を本番レコードへ自動で書く。信頼をいちばん速く壊す失敗は、読み違えたメモに基づいてエージェントがクローズ予定日を書き換え、営業がそれに気づき、チーム全体が「このツールは当てにならない」と結論することです。目に見える誤書き込み一件は、正しい書き込み五十件が積む信用より重く効きます。提案してから承認する方式の根拠はこれに尽きます。

CRM 権限が広すぎる。いちばん楽な道は、全オブジェクトに読み書きできる連携ユーザーを五分で作り、二度と見直さないことです。仕事に必要なオブジェクトと項目に絞ってください。そしてエージェントはそのユーザーが読めるものすべてを読めます——この件に一度も同意していない部門の案件、取引先担当者、メモを含めて。

監査証跡がない。三か月後に「なぜこの案件のステージが変わったのか」と聞かれて、「AI がやりました」は誰も受け入れません。自動変更はすべて追跡可能であるべきです。個人の資格情報ではなく専用の連携ユーザー、何を何に基づいて変えたかを記録するメモ、そして提案元のダイジェストの保管。

沈黙の停止。止まったスケジュールタスクは、たいてい自分から名乗り出ません。パイプラインは元に戻り、一か月誰も気づかない。ダイジェストが来ないことは「静かな週」に見えるからです。エラーだけでなく、ジョブが走らなかったことにもアラートを出してください。

営業が静かに帳尻を合わせる。ダイジェストが人事評価の点数表になれば、返ってくるのは衛生の改善ではなく見栄えのよいレコードです。法令遵守レポートではなく、マネージャー用の確認リストとして位置づけてください。

これを正しくやるには——CRM 権限の範囲、書き込み前の人手承認、そして IT を呼ぶタイミング

CRM への恒常的なアクセス権を持つ無人エージェントは、チャットセッションとはまったく別のセキュリティ対象であり、それを本業として考える人が範囲を決めるべきです。特に重要な判断が三つあります。

意図ではなく権限を絞る。まず読み取り専用で、仕事に必要なオブジェクトと項目に限定し、独自の資格情報を持つ専用の連携アイデンティティを通す。重要なのは今日のプロンプトが何に触れさせるかではなく、エージェントが何に触れ *うる* かです。プロンプトは変わり、権限は残ります。

何を読ませるかを決める。案件レコードには顧客組織の実名個人、契約条件、価格、ときには見込み客の内部事情に関する商業上機微な記述が含まれます。それを外部サービスに送ることは、顧客の所在地によっては PDPO、PDPA、PIPL、GDPR 上の立場が関わってくるデータ取扱いの判断です。この問いは最初のスケジュール実行の *前* に、データガバナンスの責任者が扱うべきものです。

書き込みには人間を残す。あとで緩める一時的な安全策としてではなく、設計としてです。エージェントの仕事は、人が目を通すべき事項を短く正確に並べることです。人が判断するのはボトルネックではなく、この仕組み全体を説明可能にしている制御点です。

その範囲を設計し、パイプラインのどの部分をエージェントに見せるかを選び、出力が使い物であり続けるように点検基準を書く——これは AI+ サポートの仕事であり、AI 導入準備とユースケース発見の作業です。営業組織では比較的分かりやすいユースケースの一つです。ガバナンス側——AI エージェントにどれだけの恒常的・無人・システム横断のアクセスを持たせるか、誰が見直すか、どう記録するか——は、まさに当社のマネージドサービスが助言する常設の判断であり、その中のセキュリティガバナンスやバーチャル CTO の仕事と地続きです。その下にある ID・資格情報・連携ユーザーの衛生は通常のマネージド IT サポートです。もっと小さな一歩から始めたい場合は、HubSpot での AI 活用リードスコアリングが単発トリガー版を扱っています。どちらが合うかはお気軽にご相談ください。

よくある質問

スケジュールタスクは、誰のレビューもなく CRM に書き込めますか

書き込み権限を与えれば技術的には可能です。フォーキャストに効く項目については悪い考えです。読み取り専用で始め、少なくとも二週間はそのまま維持し、書き込みを許すときも、数字を報告する項目ではなく人を促す項目に限定してください。

実際に必要な CRM 権限は読み取りだけですか、書き込みも要りますか

有用な形は読み取りだけで成立します。レコードと履歴を読み、ダイジェストを作る。書き込みが要るのはエージェントに直接更新させたい場合だけで、多くのチームは最初はそうすべきではありません。いずれにせよオブジェクトと項目で絞り、専用の連携ユーザーを通します。

HubSpot や Salesforce 自身の AI 機能とどう違いますか

CRM 標準の AI はプラットフォームに組み込まれ、外部連携なしにデータを見られ、構造化された信号からのスコアリングや予測に強いのが一般的です。ここでのパターンは種類が違います。自分で設定したエージェントが、非構造の履歴を読み、自分で決めた頻度で具体的な不整合を報告する。両者は補完的で、標準機能ですでに用が足りているなら、そちらが簡単な答えです。