営業AIエージェント｜5型比較と自分で組む承認ゲート3つ

営業AIエージェントとは：チャットAI・SFA・RPAとの違いは「判断する範囲」と「人に戻す場所」

上位の解説記事はどれも、生成AI（ChatGPT）との違いを「生成AIは人が指示して下書きで止まる、エージェントは目標を与えると送信やタスク登録まで自分で実行する」と書いています。この説明は正しいのですが、営業の現場で判断に効くのはもう1段先です。私は4つの道具を、「判断する範囲」と「人に戻す場所」の2軸で分けています。

4行目の「設計した人が決めた場所だけ」が、エージェントの便利さと怖さの両方です。チャットAIは出力を毎回人が読むので、間違いは目に入ります。RPAは判断しないので、間違った判断をしません。エージェントは判断して動くので、止める場所を決めていなければ、間違った判断のまま送信します。

Gartnerの定義を引いた記事（AIエージェントナビ）は「支援（Copilot）か代行（Agent）か」で製品を分けています。私はこれに「代行なら、どこで止まるか」を足して見るようにしました。例えば、米国のAI BDR製品 Artisan の公式トップページ（「You set the guardrails, Ava runs the rest」の節）には「Approval mode」という設定が載っています。返信を毎回下書きして人のクリックを待つか、送らせるかを選ぶ設定です。Mazrica Sales も2026年5月に「商談内容から案件情報の更新をAIが提案し、担当者が承認する」機能を足しました。製品側も、止める場所を設定項目として持ち始めたということです。

営業の6段階のどこにエージェントを置くかの地図はClaude営業活用の記事に書いたので、ここでは「エージェントとして動かす部分」の設計だけを扱います。

営業AIエージェントの型別比較（5型・代表製品・公開料金・承認機能の有無）

比較記事で名前が挙がる製品を、私は5つの型で見ています。表は2026年11月7日時点で公式サイトと比較記事（tovira・slide lib・AIエージェントナビ）に公開されている範囲です。私はこの表の製品を契約して使っていないので、精度や使い勝手は書けません。書けるのは、どの工程を代行するか、料金が公開されているか、人が承認する設定が公開情報にあるか、の3つです。

検索候補に出る「sapeet」は、東大発の株式会社Sapeetの製品名です。営業AIエージェントのWebアプリをα版で提供しつつ、企業ごとに構築するサービスを出している段階です（AIsmiley）。料金は非公開で、型としては⑤の構築代行に近いと見ています。

料金の相場は、slide libの記事に「営業特化型（アプローチ・リサーチ）は月5〜15万円程度、SFA/CRM一体型は1ユーザー約5,000円〜」とあります。私が見た範囲では①型の国内製品は金額非公開が多く、問い合わせないと分かりません。

表から私が読み取っているのは2つです。1つ目は、①型（新規接触の代行）が一番「送信」に近く、承認設定の有無が製品で分かれていること。2つ目は、③型と④型は人が読む前提の設計が多いことです。間違った判断のまま送信する心配は小さい代わりに、代行の範囲も狭くなります。どの型を選ぶにしても、次の節の「止める場所3つ」を先に決めておくと、ベンダーへの質問が具体的になります。

受ける側のエージェントは自分でも試作している

②型（サイト常駐）については、私自身が「営業担当者本人の顔をしたAIが一次商談をする」仕組みを2026年9月から自分で作っています。会話→1問聞き返す→裏のヒアリングシート（規模・課題・時期・決裁・今のやり方）の空欄を埋める→日程予約を提案する、という型です。2026年11月7日時点で試作の段階で、サイト経由の予約件数のような数字はまだ出せません。製品の宣伝ではなく、「受ける側」のエージェントも「答えたら1つ聞き返す」という営業の型が核で、技術は買える部品だ、という見方の根拠として書いておきます。

営業AIエージェントで人が止める場所は3つ（送信・削除・空欄）

上位の記事は「失敗パターン」の1行で「人が判断する領域とAIに任せる領域を明文化する」と書いています。明文化する中身を、私は3か所に固定しています。営業エージェントでもブログエージェントでも同じ3つです。

3つのうち、一番よく落ちるのは③です。①と②は権限の設定で機械的に止められますが、③はAIの性質そのものなので、手順書に「埋めない」と明記して、しかも「埋まらなかった項目」を出力の必須の節にしないと、ごく自然な文章で架空の数字が入ります。この記事の後半に、ブログエージェントが実際に作り話を書いて審査役に止められた記録を載せています。

逆に、この3つ以外は止めません。CRMへの作成・更新は無人でも実行させます。間違いは更新で直せるからです。「全部人が承認する」設計にすると、承認の手間がAIを使う前と変わらず、結局呼ばなくなります。

自分で組んだ営業AIエージェントの設計（朝の承認キューの手順書全文）

私が営業用に組んでいるのは、「前日の商談の後処理と、放置案件の検知を、朝にまとめて処理する」エージェントです。専用のソフトは書いていません。Claudeに手順書（スキル）を2本登録し、Google Calendar・Gmail・HubSpot・Notion のコネクタをつないでいるだけです。各工程のプロンプトは、既に別の記事に全文があります。

• 議事録の3プロンプトとスキル登録: 商談議事録の記事
• お礼メール・返信の下書き: Gmail連携の記事
• HubSpotへの反映と照合・承認ゲート: HubSpot連携の記事

ここでは「それらを束ねてエージェントとして動かす側」の手順書を全文載せます。

手順書1: 朝の承認キュー（afterdeal-morning）

次が、私が登録しているスキルの本文です。別事業の問い合わせフォームを確認する節だけ、この記事とは関係がないので省きました。

# 朝の承認キュー

商談後の実務（お礼メール・CRM反映・次アクション・放置検知）を毎朝まとめて処理し、
人がやることを「Gmailの下書きを見て送信ボタンを押すだけ」にする。

## 中核の思想（変えない）

- 承認キュー = Gmailの下書きフォルダ。専用UIは作らない。承認＝送信ボタン。
- メールは自動送信しない。下書きまで。無人実行でも同じ。
- HubSpotは作成・更新のみ（削除しない）。無人実行時は反映まで行い、結果を報告する。
- 抽出できない項目は勝手に埋めない。空欄で残してサマリーに挙げる。

## 前提

Google Calendar / Gmail / HubSpot / Notion の各コネクタが接続済みであること。
いずれかが未接続なら、その工程をスキップしてサマリーに「未接続でスキップ」と明記する（黙って飛ばさない）。

## 手順

### 1. 今日の商談予定を取る

Google Calendar で今日のイベントを取得。
社外の相手が含まれるもの（自分以外の参加者にドメインが異なるメールがある）を「今日の商談」とする。
→ サマリーの冒頭に出す。

### 2. 前日以前の商談を処理する

Notion「商談メモ受信箱」DB の未処理行を処理する。
処理そのものは deal-inbox-process スキルの手順に完全に従う（案件ごとの分岐・二重処理防止・書き戻しルールを含む）。ここで再定義しない。

追加でやること:
- 録画漏れの検知: 昨日のカレンダーに商談があったのに、受信箱に対応する行が無い場合は
  「録画/文字起こしが取れていない商談」としてサマリーに挙げる。ここが一番よく落ちる。

### 3. 放置案件を検知する

HubSpot のオープンな取引（ステージが closedwon / closedlost 以外）を対象に、
最終接触からの経過日数で仕分ける。

| 経過日数 | 区分 | やること |
|---|---|---|
| 14〜20日 | 注意 | サマリーに載せるだけ |
| 21日以上 | 要対応 | 追いメールをGmail下書きに作る |

- 経過日数は notes_last_contacted を使う。取得できない/空の場合は hs_lastmodifieddate で代用し、
  代用したことをサマリーに明記する。プロパティ名でエラーが出たら discover_hubspot_schema で確認してから再実行する。
- 追いメールは用件のある文面にする。「その後いかがでしょうか」だけの文面は作らない。
  直近の商談メモ（HubSpotのnote）を読み、そこで出た論点か次アクションを必ず1つ引いて本文に入れる。

### 4. サマリーを1枚出す

最後に必ずこの形式で出力する。件数がゼロの節も「0件」と明示する（省略しない）。

■ 今日の商談（N件）
  10:00 A社 田中様 / 初回

■ 承認待ち（Gmail下書き・N件）
  □ A社 田中様  お礼メール
  □ B社 佐藤様  追いメール（最終接触から24日）

■ HubSpot反映済（N件）
  ・A社 田中様 … コンタクト更新 / 取引を「提案中」へ / タスク 9/2 見積提出

■ 要対応（N件）
  ! B社 24日放置（案件 80万）
  ! C社 昨日の商談が受信箱に無い＝録画漏れの可能性

■ 埋まらなかった項目
  ・A社 予算が商談で出ていない

### 5. 週次の数字（月曜のみ）

実行日が月曜なら、上のサマリーの末尾に先週分を足す。

- 商談後72時間以内に処理できた率
- 放置案件（14日以上）の件数と金額合計
- 先週の商談数 → 次アポが取れた数

出力するだけでなく週次ログのファイルに追記する（無ければ作る）。

## 無人（cron）実行時の差分

- ユーザーへの確認は行わない。判断に迷ったら処理せずサマリーの「要対応」に回す。
- HubSpot反映は承認を待たずに実行してよい（誤りは後から更新で直せるため）。
- メールの送信だけは、無人でもしない。

設計で効いている箇所を4つだけ補足します。

1. 「中核の思想」を先頭に置き、手順より上に書く。 前の節の止める場所3つがそのまま入っています。AIは長い手順の途中で前提を忘れるので、一番守らせたいことを最初に、短く書きます
2. 未接続は「黙って飛ばさない」。 コネクタが1つ切れていても、残りを処理して「未接続でスキップ」と書かせます。これが無いと、HubSpotが切れていた朝に「反映済 0件」とだけ出て、人は気づきません
3. ゼロ件も「0件」と書かせる。 節を省略させると、処理していないのか0件なのか区別がつきません
4. 放置案件の追いメールは「用件のある文面」に縛る。 「その後いかがでしょうか」を禁止し、直近の商談メモから論点を1つ引かせます。縛らないと、全案件に同じ文面の下書きが並びます

手順書2: 受信箱の処理（deal-inbox-process）と二重処理の防止

手順書1の「2. 前日以前の商談を処理する」が呼んでいる側です。商談の録画ツール（tl;dv）が文字起こしをNotionのデータベースに自動で書き込むので、そこを受信箱として巡回します。

# 商談メモ受信箱の処理

tl;dvが自動で書き込む「商談メモ受信箱」DBを巡回し、未処理の商談を案件ごとに処理する。

## 対象DB
- 主なプロパティ: 案件 / 処理状況(未処理/お礼メール下書き済/HubSpot反映済/完了) /
  相手会社 / 相手氏名 / 相手メール / 要点 / 次アクション / お礼メール(チェック) / HubSpot反映(チェック)
- 文字起こし・要約はtl;dvが各行のページ本文に入れる。処理時は対象行を本文ごと読む。

## 前提
- HubSpot・Gmail・Notionの各コネクタが接続済みであること。
- お礼メールは必ずGmailの「下書き」まで（送信はしない）。送るのは本人が中身を確認してから。
- 無人/手動どちらでも、メール送信とHubSpotの破壊的変更はしない（作成・更新のみ）。

## 手順
1. 未処理の取得: 処理状況が「完了」「お礼メール下書き済」「HubSpot反映済」以外の行
   （= 空 or 未処理。tl;dvは処理状況を空のまま行を作るので、空＝未処理扱い）を対象にする。
   0件なら「未処理なし」と報告して終了。
2. 各行を読む: 本文の文字起こし/要約から要点を把握する。
3. 案件で分岐:

   ### 案件 = 自社の新規営業（フル処理）
   1. 文字起こしから抽出: 相手氏名・役職・会社・メール / 要点(2〜4行) / 次アクションと期日。
   2. 要点・次アクション・相手情報をDBの該当プロパティに書き戻す。
   3. Gmailお礼メールを下書き作成（送信しない）。宛先は相手メール、件名・本文は商談内容に合わせる。
      メールが取れない場合は宛先空のまま下書きし、その旨を報告。
      → お礼メールにチェック、処理状況=「お礼メール下書き済」。
   4. HubSpot反映: コンタクト/取引/メモ/タスクを反映する（必須プロパティは明示指定）。
      → HubSpot反映にチェック、処理状況=「完了」。
   5. 人が見ている時はHubSpot反映前に一覧提示→承認。無人時は反映して結果を報告。

   ### 案件 = 業務委託先の商談（要点整理のみ）
   1. 要点(2〜4行)と次アクションを抽出し、書き戻す。文字起こし本文はそのまま残す。
   2. Gmail下書き・HubSpot反映はしない。
   3. 処理状況=「完了」。

   ### 案件が空欄（tl;dvは案件を空で行を作るので通常はここ。まず判定する）
   - 本文・参加者から案件を判定する。どの委託先でもない新規商談は自社の新規営業とみなす。
   - 判定できたら案件タグを書き込み、上の該当処理に回す。
   - 判定が曖昧なときだけ本人に確認してから処理する。
4. 報告: 処理した商談ごとに「案件 / 相手 / やったこと / 残課題」を一覧で報告する。

## 制約（守る）
- メールは下書きまで。送信しない。
- HubSpot反映は一括10件まで・削除不可・必須プロパティ明示。
- 同じ行を二重処理しない（処理状況とチェックボックスで判定）。
- 抽出できない項目は勝手に埋めず空欄のまま残し、報告で挙げる。

ここで大事なのは「処理状況」の列です。エージェントには、同じ行を前に処理したという記憶がありません。前回の処理結果をデータの側に書き戻し、次回はそれを見て飛ばす設計にしないと、同じお礼メールの下書きが2通できます。私はNotion側の列（処理状況・2つのチェックボックス）で持たせていますが、スプレッドシートの1列でも足ります。

無人で走らせるときに変えるのは3つだけ

手順書1の末尾にある「無人実行時の差分」が、人が呼ぶ運用と無人運用の違いの全部です。確認しない（迷ったら要対応に回す）、CRMの作成・更新は承認を待たない、送信だけは無人でもしない。この3行があるので、同じ手順書を人が呼んでも定時実行に載せても動きます。

運用記録：営業エージェントは「人が呼ぶ」段階、ブログエージェントは無人で8日回した結果

正直に書きます。上の営業エージェントは、2026年11月7日時点では人が朝に呼ぶ運用で、定時実行には載せていません。手順書の「5. 週次の数字」も、追記先のファイルがまだ存在しないので、72時間以内の処理率などの実数は未測定です。商談が1人分の件数しか無いうちは、呼ぶ側の手間がほとんど無いからです。

代わりに、完全に無人で動かしているエージェントが1つあります。このブログ自体です。毎朝9時にmacOSの定時実行（launchd）からシェルスクリプトが起動し、Claude Code を呼びます。そこからキーワード選定→SERP分析→執筆→別の審査役による審査→採点→図解→HTMLビルド→git push（本番公開）→Slackへの通知までを、人が見ずにやらせています。営業エージェントと設計の思想は同じなので、こちらの記録が実物です。

8日間の実行結果（2026年10月30日〜11月6日）

8日で、公開5本、失敗2日、停止1日です。この表から私が学んだことが3つあります。

1. 審査役を別のエージェントにしたから、作り話が止まった。 公開した5本すべてが1回目の審査で差し戻されています。10/30の差し戻しは、一次情報のファイルを読み直した審査役が「記録は2日分しか無い」と指摘したものでした。書く側のエージェント1体だけなら、この記事はそのまま公開されていました。前の節の「③空欄を埋める」が、営業の数字でなく自分の運用実績で起きた例です
2. 範囲を超える操作は、設計と違う場所で起きる。 10/30・10/31・11/3 の3回、記事を組み立てるプログラムが「触らない」と指示したファイルも書き換えていました。壊れてはいませんが、公開前に差分を見て止める工程（git の差分確認）が無ければ、作りかけのページが本番に出ていました。11/3 は戻す操作が権限で拒否されて変更が残り、翌 11/4 の停止は、その残った変更を安全装置が検知したものです
3. 失敗した日に「失敗した」と分かる設計が要る。 11/1は結果ファイルすら書かれませんでした。スクリプト側で「結果が無ければ失敗として通知する」を入れてあったので、朝のSlackで気づけました。営業エージェントの手順書に「0件も0件と書く」「未接続はスキップと明記する」を入れているのは同じ理由です

営業エージェントの側では、放置案件の経過日数を取るプロパティが空のときに代用値を使って「代用した」とサマリーに書かせる、という設計が同じ考え方です。数字が無いときに黙って別の数字を出すのが、エージェントで一番見つけにくい失敗です。

営業AIエージェントを「買う」か「Claudeで組む」かの分かれ目

製品の表と自作の設計を並べたうえで、私が壁打ちで聞かれたときに使っている分かれ目を書きます。

新規接触の「量」が課題なら、①型の製品に分があります。フォーム送信や架電の実行基盤は、自分で組むと法律と運用ルールの整理から始まるからです。私はフォーム営業を「文面はAI、送信は人」で線を引いていて、その理由と文面プロンプトはフォーム営業の記事に書きました。リストの作成と採点も、同じく製品を使わずスプレッドシートとClaudeで回していて、26社を採点した実出力は営業リストの記事にあります。

逆に、商談の前後の処理は、自分で組む側に寄せています。理由は、止める場所（送信・削除・空欄）を自分の言葉で手順書に書けるからです。製品の承認設定は「ある・ない」の2択ですが、手順書なら「追いメールは論点を1つ引く」「0件も0件と書く」まで縛れます。

私がやった順番（営業エージェントの場合）

上位の記事にある「準備→要件定義→選定→導入→運用」の段取りは、営業が数人の会社には重すぎます。私が営業エージェントで実際に踏んだ順番は4つで、2026年11月7日時点の現在地も書いておきます。

③で止まっている理由は、商談が1人分の件数しか無く、朝に呼ぶ手間がほぼゼロだからです。④に進むのは、呼び忘れが出るか、商談が週5件を超えてからで足ります。④に進んだ側の記録は、上の「運用記録」の節にあります。

営業AIエージェントでつまずいた失敗5つと直し方

営業エージェントとブログエージェントの両方について、手順書に書き足した行と、ブログの実行ログに残っている失敗だけを書きます。

1. 空欄を架空の数字で埋めた。 ブログエージェントが「5月から毎日回している」と書いた例が上の表にあります。営業側でも、手順書に「抽出できない項目は勝手に埋めない」の行を足す前は、商談で出ていない予算が埋まったことがありました。どの金額だったかは記録していません。直し方は、禁止を書くだけでなく、出力の必須の節として「埋まらなかった項目」を置くことです。書く場所があると、AIはそこに書きます
2. 指示範囲の外のファイルを書き換えた。 ブログ側で、記事を組み立てるプログラムがトップページまで更新していました。実際に取った直しは2段です。トップページの最新記事枠はビルダーが書き換える範囲に入れ（範囲の側を実態に合わせて広げた）、それ以外に変更が残れば公開を止める。エージェントの側に「触らない」と書くだけでは足りず、公開の直前に差分を機械的に確認する工程が要ります。11/4の停止はこの工程が働いた結果で、記事は書けませんでしたが作りかけのページも出ませんでした
3. 途中で止まると、何も残らなかった。 11/1は結果ファイルが無く、放っておけば「今日は書かなかった」ことにすら気づけませんでした。直し方は、呼び出す側のスクリプトで「結果が無い＝失敗」として通知することです。営業側では、サマリーの各節を省略させず、0件も「0件」と書かせています
4. 同じ商談を2回処理した。 受信箱の処理で、前回の処理結果を書き戻していなかった時期に、同じ相手へのお礼メールの下書きが2通できました。直し方は、処理状況の列をデータ側に持ち、「完了」「下書き済」の行は読まない、と手順書に書くことです。ブログ側も「同じ日に結果ファイルがあれば2本目を書かない」を入れています
5. 経過日数のプロパティが取れずに止まった。 HubSpotの「最終接触日」のプロパティ名でエラーが出て、放置案件の検知が丸ごと飛んだことがあります。直し方は、代用のプロパティを決めておき、代用したことをサマリーに書かせることと、エラー時にはスキーマを確認してから再実行する、と手順書に書くことです。「取れないから飛ばす」を黙ってやらせないのが要点です

5つに共通するのは、失敗そのものは製品でも自作でも起きる、ということです。差が出るのは、失敗したことが翌朝に人の目に入るかどうかです。

どの工程を、どこで止めるかを、60分の無料壁打ちで決める

営業AIエージェントで時間がかかるのは、製品を選ぶことでも手順書を書くことでもなく、「どの工程を任せて、どこで止めるか」を自社の言葉で決めるところです。ここが決まれば、製品の承認設定を見る目も、手順書の1行目も決まります。この記事の手順書2本と、議事録・お礼メール・HubSpot反映の3スキルの雛形は、配布フォームで配布中です。私はAIgearで月5枠・60分の無料壁打ちを設けています。今の営業の流れを1枚（商談の前後で誰が何をしているか）持ってきてもらえれば、その場で「任せる工程・止める場所」を一緒に決めて、製品で済むか自分で組むかまで出す時間です。製品で足りる、という判断になった場合は、そのまま伝えて終わりです。