営業のAIは「万能な1体」では広がらない。商談レビューから育てるエージェント設計

営業の現場には「この案件、ちょっと誰かに見てほしい」という相談が毎日あります。 その相手をAIに担わせる取り組みが増えてきましたが、何でもできる1体のAIを作ろうとすると、たいてい広がりません。 ベテランの「見るポイント」を取り込んだ商談レビューのエージェントと、社内のチャットボットを部門横断のエージェントへ育てる方法を、実例とあわせて整理します。

営業の「ちょっと相談したい」が満たされない理由

商談の前に誰かに見てもらいたい。この小さな要望が満たされないのは、立場ごとに別々の事情があるからです。

• 担当者：相談したい相手が忙しく、つかまらない。結局、準備が足りないまま商談に入ってしまう
• マネージャー：レビューに使える時間が限られ、毎回同じ指摘をくり返している
• 組織：成果を出しているベテランの知見が、本人の頭の中に閉じたまま広がらない

目指したいのは、ベテランの代わりを1人増やすことではありません。 いつでも・誰でも・複数の観点から、案件を見直せる状態をつくることです。

ベテランを複製せず、「観点」を取り込む

商談レビューのエージェントで取り込むのは、ベテランの人格や話し方ではなく、案件のどこを見て、どう判断しているかです。 将棋の棋士が、盤面のどこに目をつけるかを言葉にして弟子に教えるのに近いかもしれません。

観点は、次の3つから集めます。

• 普段の発言の記録：社内チャットや日報で、ベテランが後輩に返しているコメント
• 案件相談や会議の記録：実際の案件について、どこを指摘し、何を確認しているか
• 本人へのインタビュー：「この案件を見て、最初に気になるのはどこですか」を言葉にしてもらう

集めた観点は、「提案の筋が通っているか」「顧客を十分に理解できているか」「受注までの道筋が見えているか」のような問いの形に整理します。 エージェントはそれぞれの問いで案件を見て、1つの助言にまとめて返します。 過去の似た事例を探して並べるだけの仕組みとは、ここが違います。

小さく試して分かった、効く場面と広がらない理由

ある企業の営業部門は、営業担当6名とマネージャー5名で、3週間の試行を行いました。 題材は実際の商談や提案です。

効いた場面の一つは、若手の「顧客からメールの返信がもらえない」という相談でした。 エージェントは「自分が聞きたいことではなく、相手が自分事として答えたくなる問いかけになっているか」という観点を返しました。 若手は文面を顧客の立場で書き直しています。 相談して気づき、次の行動が変わる。狙いどおりの使われ方です。

ところが、この部門は営業部全体への展開を見送りました。 試行中に「根拠を示してほしい」「顧客のことを事前に調べてほしい」「提案資料まで作ってほしい」「切り返しのトーク例がほしい」と、要望が次々に出てきたからです。

要望を、営業のプロセスに並べ直す

出てきた要望を営業のプロセスに並べ直すと、理由が見えてきます。

• 顧客を理解する（事前の情報収集、過去の取引の確認）
• 仮説を立てる（課題の見立て、提案の骨子）
• 提案前にレビューする（商談レビューのエージェントが担うのはここだけ）
• 提案する（資料、過去事例、競合との比較）
• 受注へ進める（切り返しのトーク、条件の調整）

レビューは大事な工程ですが、仕事の一部にすぎません。 前後の工程とつながっていなければ、利用者は「結局、自分で調べて自分で作る」ことになり、満足しません。 木（商談レビュー）を見ていたけれど、課題は森（営業業務の全体）にあった、ということです。

かといって、要望をすべて1体に詰め込むのも失敗のもとです。 何でも屋になったエージェントは、どの仕事でも精度が落ちます。 要望をかなえることと、課題を解決することは別物です。 誰の、どんな課題を解きたかったのかに立ち返り、役割ごとにエージェントを分けて考えます。

既存のチャットボットを土台にする：狭く深く作って精度を出す

役割を分けたエージェントを育てる土台として、すでに社内で使われているチャットボットはよい出発点になります。

ある企業の技術支援の部門は、他部門から来る製品の技術的な問い合わせに時間を取られ、本来の顧客対応ができずにいました。 そこで、社内チャットで質問するとAIが答え、参照した資料のURLを添えて返す仕組みを自分たちで作りました。 月200件を超える問い合わせに対応し、1件15分として年間約600時間の削減になっています。 数字に出ない効果として、先輩や上長が相談に乗る時間も減りました。

精度を上げたのは、モデルの性能ではなくデータの整え方でした。

• 参照する資料を絞る：社外に公開してよい資料だけを対象にする
• 資料に目印を付ける：取り込むたびに、タイトル・カテゴリ・製品名・URLを自動で付ける
• 製品ごとに絞り込んで探す：この絞り込みを入れただけで、回答の精度はおよそ5割から8〜9割に上がった
• 根拠を必ず添える：回答に参照元を付けて、利用者が自分で確かめられるようにする

「深める」と「広げる」を分けて設計する

チャットボットの評判が広がると、ほかの部門からも使いたいという声が上がります。 ここで、深めると広げるを別の課題として扱うのがポイントです。

• 深める（回答の精度を上げる）：データの問題。資料の質・新しさ・網羅性で決まる
• 広げる（使う部門や用途を増やす）：構造の問題。既存のエージェントに手を入れずに増やせるか

先ほどの企業は、既存のエージェントは改修せず、その上にまとめ役のエージェントを置きました。 まとめ役は利用者の質問を受け取り、複雑な質問は分割して、製品ごとの専門エージェントに問い合わせます。 簡単な質問は安く、難しい質問には手間をかけるという、コストのかけ分けもできるようになりました。

• 部門ごとに振る舞いを変える：営業向けは速さを優先し、技術支援向けは正確さを優先する
• 権限を部門で分ける：過去の問い合わせ履歴のような顧客の機微な情報は、サポート部門の社員だけが使えるようにする
• 利用量とコストを見える化する：エージェントごと・部門ごとに利用回数と費用を集計し、拡大の判断と費用の負担先を決める材料にする
• くり返しに上限を設ける：検索と回答のやり直しの回数に上限を設け、コストの青天井を防ぐ

入口が1つで振る舞いも1つの構造では、どの部門にとっても「まあまあ使える」止まりになります。 大きく強い1体を作るより、狭く深いエージェントを、まとめ役を通じて広く使うほうが、結果的に早く全社に広がります。

効果の広がり方も段階的です。 まず個別の業務が楽になり（点）、次に業務のプロセスがつながり（線）、最後に組織全体の生産性が上がる（面）。 商談レビューのエージェントも、この「点」の一つとして位置づけると、次に何をつなぐべきかが見えてきます。

まとめ：営業向けエージェントを作る前の確認リスト

• 誰の、どんな課題を解くのかを、担当者・マネージャー・組織の視点で言葉にしているか
• ベテランの「見るポイント」を、発言・会議の記録・インタビューから集めているか
• 観点を問いの形に整理し、助言として返す設計にしているか
• 試行で出た要望を、営業のプロセスに並べ直して優先順位をつけているか
• 1体に詰め込まず、役割ごとのエージェントに分けているか
• 回答に根拠を添え、利用者が確かめられるようにしているか
• 部門ごとの権限と、利用量・コストの見える化を、広げる前に用意しているか

営業のAIは、作ることより、使われ続けることのほうが難しい仕事です。 小さく試し、出てきた要望を業務の流れに置き直して、役割ごとに育てていく。 私たちは、営業の現場と一緒にこの手順を進め、日々の商談で使われるエージェントづくりをお手伝いしています。