AIエージェントにLinkedInの営業DMを任せ、会話の記録はBusabaseに残す

LinkedInのDMで商談が進んでいるのに、その経緯を知っているのは担当者の受信箱だけ——という状態は、珍しくありません。

先週どの会社に声をかけたか。誰が何と返してきたか。価格の話はどこまでしたか。次にいつフォローすべきか。本人に聞けば分かりますが、チームには見えません。担当が休めば止まります。そしてAIエージェントに下書きを手伝わせても、エージェント自身は何も覚えていません。毎回まっさらな状態から書き始めるので、昨日あなたが直した言い回しも、先週却下した表現も、次の下書きには反映されません。

問題はチャネルではありません。記録がないことです。

この記事では、LinkedInの営業DMをAIエージェントと一緒に回すための、具体的な運用の組み立て方を紹介します。中心になるのは、次の分担です。

• LinkedInは、会話が起きる場所です。
• AIエージェントは、読んで、分類して、下書きする実行者です。
• あなたは、承認する人であり、判断に責任を持つ人です。
• Busabaseは、すべての会話と判断が残る記録の場所です。

チャネルと記録は、別のものです

まず、この区別をはっきりさせます。

LinkedInはチャネルです。つながり申請も、DMも、InMailも、すべてLinkedInの中で起きます。しかしLinkedInの受信箱は、チームの営業記録として設計されたものではありません。検索はできても、「承認待ちの返信が何件あるか」「7日以上止まっているスレッドはどれか」「あのとき、なぜこの表現に直したのか」は残りません。

Busabaseは記録です。AIエージェントのための記録システム（System of Record）として、構造化された表（レコード）、文書（ドキュメント）、再利用できる手順（スキル）、そして画面（アプリ）を一つの場所に置きます。エージェントはClaude Codeでも、Codexでも、Cursorでも構いません。MCPやAPI、CLIを通じて、同じ記録につながります。エージェントが変わっても、記録は残ります。

もう一つ大事な点があります。Busabaseでは、エージェントの書き込みはChange Requestとして提出されます。どのフィールドがどう変わるのか、誰が提出したのか、誰が承認したのかが残ります。商談ステージの前進や金額のような、後々効いてくる変更を、エージェントが一人で決めて正式記録にしてしまうことはありません。

つまり役割はこうなります。接続のための道具が会話を運び、エージェントが作業し、人が判断し、Busabaseが覚えている。 チャネルは後から差し替えても、この記録の層があれば運用は崩れません。

用意するもの：既存テンプレートと五つの表

ゼロから作る必要はありません。Busabaseのテンプレートには、すでに骨格があります。

• Busa CRM：会社、連絡先、商談、そしてやり取り（interactions）を扱うテンプレートです。エージェントがすべての接点を記録し、次のフォローを下書きする前提で作られています。会社と商談の表は、まずこれを使います。別に「AI専用の顧客リスト」を作って二重管理にしないことが大切です。
• Busa Sales Outreach：ポジショニング、理想的な顧客像（ICP）、対象アカウント、連絡先、そして個別化した最初のアプローチを扱うテンプレートです。名簿づくりの出発点になります。

この二つに、DM運用のために次の五つの表を組み合わせます。フォルダ名は「LinkedIn Sales Desk」とでもしてください。

この台は、そのままテンプレートにもなっています。Busa LinkedIn Desk——五つの表、運用スキル、承認デスクを一つのインストール可能なパッケージにまとめたものです。

1. 連絡先表（Contacts）

人の層です。照合の鍵は名前ではなく、LinkedInのプロフィールURLです。同姓同名は別人として扱い、URLで人を特定します。

2. メッセージ表（Messages）

すべての入口です。届いたメッセージも、送ったメッセージも、1行に1件記録します。

3. 返信表（Replies）

「送ろうとしている返信」1件につき1行です。承認はこの表で起きます。そして承認のときに書かれた意見こそが、後述する経験の原料になります。原文のまま保存してください。

図：テンプレートの返信レコード。下書き、承認コメント原文、送信本文、送信メッセージIDが同じ画面に並ぶ（サンプルデータ）

4. 処理表（Actions）

返信以外の「やること」を1件1行で持つ表です。フォロー、資料送付、面談調整といった後続の約束が、チャットの中に流れて消えないようにするための場所です。

なお、CRMの項目更新はこの表から直接書き換えるのではなく、Change Requestとして提案します。ステージや金額のような判断は、差分を見て人が承認する形が安全です。

5. 経験表（Experience）

この仕組みの心臓部です。承認の場面で生まれた意見を、1件ずつ「経験」として貯めていきます。

図：テンプレートの候補経験。どの返信と承認コメントから生まれたか、たどれる（サンプルデータ）

この五つを支える文書と手順も置いてください。ドキュメント「ICPと言い回しの基準」には、言ってよいこと・言ってはいけないこと、価格と約束ごとの線引き、人へ上げるルールを書きます。スキル「LinkedInアウトリーチ運用」には、分類のルール、フォローの間隔、重複を防ぐ鍵、送信前のチェックリスト、書き戻しの決まりを書きます。

図：五つの表の関係（イメージ図・サンプルデータ）

接続方法：正直な比較

ここは誇張せずに書きます。Busabaseには、LinkedInの公式連携はありません。 会話を運ぶのは、エージェント側の道具の仕事です。選択肢は主に四つあります。

どの経路を選んでも、Busabase側の仕事は変わりません。届いた会話を記録し、承認を残し、結果を書き戻すことです。

方法論：話す・承認する・実行する・記録する・学ぶ

運用の型は、五つのステップの循環です。チャットで話し、人が承認し、承認されたことだけを実行し、すべてを記録し、承認の意見から学ぶ。この循環を回すほど、次の下書きは最初から良くなります。自己改善するエージェントの考え方については、Busabaseで自己改善するエージェントを作るもあわせてご覧ください。

図：五つのステップの循環（イメージ図・サンプルデータ）

1. 話す

すべての起点と終点は、エージェントとのチャットです。新しいメッセージの報告も、下書きの提案も、実行の結果も、チャットに戻ってきます。表を直接眺めて運用するのではなく、会話の中で進めます。

2. 承認する

人のアクションは、三つだけです。

• そのまま承認：良い下書きだったという、正の例になります。
• 直して承認：一番価値のある学習信号です。下書きと送信本文の差分が、そのまま「次はこう書け」という基準になります。
• 理由つきで却下：何が駄目だったのかが残り、負の例と、越えてはいけない線の引き方になります。

承認は、送信前の関門であると同時に、エージェントへのラベル付けでもある、と捉えてください。あなたが直した一文、添えた一言は、捨てられません。経験表の原料になります。

3. 実行する

送信と実行は、承認の後です。価格、約束、納期・日程のような事項は、エージェントが決めません。必ず人へ上げます。下書きであることと、送信済みであることは、別のことです。この区別を曖昧にしないでください。

4. 記録する

メッセージ、返信、処理の結果は、IDで重複を避けながら表に書き戻します。送信が済んだら、送信本文と送信メッセージIDを戻して、はじめて「送った」と言えます。言った言わないの争いは、記録があれば起きません。

5. 学ぶ

承認コメントは、まず「候補」の経験として自動で貯まります。週に一度の振り返りで人が「採用済み」にし、繰り返し成り立つと判断したものは、Change Requestとしてスキルへ昇格させます。差分があり、名前があり、承認した人が残る形です。エージェントは次の下書きの前に、採用済みの経験を先に読みます。だから、同じ直しを何度も受けることが減っていきます。

日々の運用は、チャットの画面を思い浮かべると分かりやすいはずです。左にエージェントの提案と、あなたの修正、右にその結果として生まれた記録が並ぶ。その並びが、そのまま監査の跡になります。

図：Busa LinkedIn Deskの承認デスク。判断待ちの下書きが一つのキューに並ぶ（サンプルデータ）

一通のメッセージの旅：架空の事例で追う

仕組みだけでは実感が湧かないので、架空の事例で一通を追います。以下は例です。人物も会社も実在しません。

物流会社の業務責任者、Alexさんから、月曜日の9時12分にLinkedInで返信が届いたとします。「オンプレミスで動かせますか？ データを社外に出したくないのですが」。

• 9時15分、分類。 定期実行のエージェントが新しい会話を読み、メッセージ表に1行落とします。意図は「質問」、緊急度は「高」。プロフィールURLで連絡先表のAlexさんと照合できました。
• 下書き。 エージェントは、ICPと言い回しの基準を書いたドキュメントと、経験表の採用済みの項目を先に読み、返信の下書きを返信表に作ります（承認待ち）。そしてチャットに提案を持ってきます。
• 9時40分、あなたの判断。 チャットであなたはこう返します。「方向は合っています。導入にかかる期間の目安を一文足してください。ただし、開始日の約束はしないでください」。これは「直して承認」です。
• 実行と書き戻し。 エージェントは修正した本文を送信し、送信本文と送信メッセージIDを返信表とメッセージ表に書き戻します。さらに処理表に「導入資料を送る、期限は水曜日」という1件を作ります。
• その夜、経験の候補が生まれます。 あの承認コメントから、「導入形態の質問には、できるかどうかと期間の目安を先に答える。日付の約束はしない」という候補が経験表に入ります。
• 金曜日の振り返りで、あなたがこれを「採用済み」にします。
• 2週間後、別の相手から似た質問が来たとき、エージェントの下書きには最初から、その2点が入っていました。

あなたがやったことは、チャットで一文添えただけです。でもその一文は消えずに、次の下書きを変えました。

図：一通のメッセージの旅（イメージ図・サンプルデータ）

プロンプト集：そのまま書き換えて使える四つ

手順は、チャットでエージェントに頼む形で回します。以下の四つは出発点です。自社の基準に合わせて書き換えてください。

P0：台を作る

私のワークスペースに「LinkedIn Sales Desk」というフォルダを作り、連絡先、メッセージ、返信、処理、経験の五つの表と、二つの文書（ICPと言い回しの基準／LinkedInアウトリーチ運用のスキル）を用意してください。まず構造だけを見せて、実在の顧客データは入れないでください。

P1：毎日の分類（送信はしません）

今日新しく届いたLinkedInの会話を読んでください。プロフィールURLで連絡先表と照合し、合わない相手は「未確認」の候補として作ってください。各メッセージは、メッセージIDで重複しないよう、メッセージ表に1行ずつ記録してください。返信を「関心あり／反論／紹介／今は不要／宛先違い／拒否／質問」に分けて、「関心あり」と「質問」には返信の下書きを作り、ここに提案として見せてください。何も送信しないでください。承認を待ちます。 最後に、今日のまとめをください。新しい会話の件数、私の判断が要るもの、7日以上止まっているスレッドです。

P2：承認のあとに実行する

先ほど承認した3件を、承認された本文のとおりに送信してください。送信したら、各件の送信本文・送信時刻・送信メッセージIDを書き戻してください。必要なフォローは、種別と期限を付けて処理表に作ってください。1件でも送信に失敗したら、その場で止めて報告してください。文面を変えて再試行はしないでください。

P3：週の振り返りと、経験の昇格

今週の返信表と処理表をまとめ、私の承認コメントから生まれた経験の候補を、根拠になった記録と一緒に一覧にしてください。繰り返し成り立ちそうなものについては、スキルへ入れる文章の差分案を作ってください。勝手に入れず、私の確認を待ってください。

運用のリズム：日次と週次

型ができたら、あとはリズムです。

毎日は、分類から始まります。エージェントが新しい会話を読み、記録し、下書きを提案します。あなたはチャットで承認し、直し、却下します。承認されたものだけが送られ、結果が書き戻されます。1日の終わりには、新しい会話の件数、承認待ちの件数、止まっているスレッド、今日の結果がまとまって戻ってきます。朝の数分で、昨日の営業の全体像がつかめる状態が目標です。

毎週は、振り返りの時間です。返信の結果（返ってきたか、面談になったか、断られたか）を見て、経験の候補を採用するかどうか決めます。成り立たなくなった経験は廃止します。繰り返し効いたものは、スキルへの昇格を提案してもらいます。この週次のひと手間が、「学ぶ」を掛け声で終わらせないための要です。

自動化は、この手作業の型が固まってからで構いません。最初は手作業で渡して1周回し、分類の精度と承認の感覚を確かめてから、接続の自動化を検討してください。

シナリオ早見

同じ台の上で、場面ごとに動きが少し変わります。

境界：できないこと、してはいけないこと

最後に、線引きを正直に書いておきます。

• プラットフォームの規約とアカウントのリスク。 LinkedInは自動化されたアクセスを制限しています。どの接続方法を選んでも、そのリスクが消えるわけではありません。使う前に各サービスの最新の規約を確認し、判断は自分の責任で行ってください。
• 送信量は控えめに。 大量送信や一斉送信の道具として使わないでください。少しずつ、相手に合わせた文面で、承認を通して送ることが前提です。
• プライバシーは最小限に。 記録するのは、業務に必要な抜粋と、たどれる参照だけです。センシティブな会話の全文を、あちこちの表にコピーして回すことはしません。
• 下書きは送信ではありません。 提案は承認ではありません。送信済みと言えるのは、送信メッセージIDが書き戻されたときだけです。
• 約束ごとはエージェントにさせません。 価格、納期、契約条件は、人が決めて人が伝えます。

よくある質問

Unipileのような道具がなくても、できますか？ できます。むしろ、最初はそれがおすすめです。会話を手作業で渡して、記録・分類・下書き・承認の型を1周回してください。接続の自動化は、型が固まってからで十分です。

エージェントに自動で送らせることはできますか？ 技術的には、接続の経路によっては可能です。ただし、この記事の運用では既定にしません。送信は承認の後、という順序が、記録の信頼性とアカウントの安全の両方を守ります。

普通のCRMと何が違うのですか？ CRMは顧客の状態を管理する道具です。ここで作っているのは、その手前と周りにある「エージェントの作業と、人の判断」まで含めた記録です。誰に、なぜそう書いたのか、誰が直して、結果どうなったのか。既存のCRMと置き換える必要はなく、会社と商談はBusa CRMの表をそのまま使う前提です。

同じメッセージが二重に記録されませんか？ メッセージIDを重複を防ぐ鍵にしているので、同じ取り込みを繰り返しても二重にはなりません。チャネル側のIDがない場合は、「スレッドID＋時刻」で鍵を組み立てます。

始めるには

まずはテンプレートから始めてください。テンプレートの一覧からBusa CRMとBusa Sales Outreachを複製し、この記事の五つの表と二つの文書を足せば、台は形になります。最初の1週間は手作業で渡して回し、承認の型と経験の貯まり方を確かめてください。

なお、この記事の台は、そのままテンプレートとして公開済みです。Busa LinkedIn Desk——五つの表、運用スキル、承認デスクをまとめたパッケージで、テンプレートのページにはデモ動画もあります。

チャネルは、これからも変わります。でも一度記録の型を作れば、会話がどこで起きても、チームの記憶は消えません。DMは人の受信箱の中だけのものではなく、チームの資産になります。