「生成AIが普及すれば、営業は不要になるのでは？」——この問いへの答えは、すでにかなりはっきりしてきました。営業の一部業務は強く自動化されるが、営業そのものは“再定義”される。つまり、置き換えではなく、役割の選別が起きている、という整理が現状に合っています。
その実態を数字で示しているのが、HubSpot Japanの「日本の営業に関する意識・実態調査2026」です。BtoB購買で情報源として生成AIを使う買い手は、2024年の4.3%から2025年には11.7%へと約2.7倍に増加しました。一方で、買い手の約8割は営業担当者に 「生成AIにはない価値」 を期待しており、その中身は「個別事情を汲んだ提案」「潜在ニーズの引き出し」「共感・気配り」でした（HubSpotが「日本の営業に関する意識・実態調査2026」の結果を発表）。一般情報の提示はAIに寄り、文脈理解と意思決定支援は人に寄る——その構図が、調査からはっきり見えてきています。
IT技術者の目線で言い換えると、こうなります。FAQ的説明や情報整理・候補比較の初期工程はLLMに寄せやすく、顧客固有の要件定義・利害調整・組織内合意形成・導入障壁の除去は人間に残る。したがって、営業DXの本丸は「営業をAIで置き換える」ことではなく、営業が人間にしかできない部分へ集中できるように業務OSを作り直すことになります。この認識があるかどうかで、AI導入の設計思想はかなり変わります。
本記事では、その前提をふまえ、営業部門における生成AI活用を現状分析 → 使い方のアイデア → 実装できるシステム設計まで、IT技術者が明日の設計会議で使える形でまとめます。音声を業務データにつなぐ設計は別記事「文字起こしで終わらせない——音声を業務データに変える設計と現場で使えるアイデア」、RAGやエージェントの設計は「RAGとAgentic Search——安い検索から重い探索へ」「AIを使うから任せるへ——社内システム設計とエージェントアーキテクチャ」で扱っているので、あわせて参照してください。筆者の記事一覧からも探せます。
買い手も売り手も動いている——押さえておきたい「変わったこと」
「役割の選別」が現場でどう表れているか。設計の前提になるので、買い手と売り手の両方の変化を、まず数字で押さえておきましょう。
買い手は、商談の前からAIで候補を絞り始めている
同調査では、購買検討時に生成AIを活用したことがある買い手は36.7%で、その多くが直近1年以内の利用でした。主な用途は、自分の課題やニーズの整理、製品・ベンダー情報の収集、候補の洗い出しです。さらに、生成AIを使った買い手の52.4%が「当初想定していなかった製品を候補に追加」、55.3%が「最終意思決定に影響を受けた」と答えています（同上）。営業が気づかない場所で、候補選定の前段がAIによって書き換わり始めているわけです。
この変化をエンジニアの感覚で言い換えると、検索時代のSEOが、生成AI時代の 「AIに参照される情報設計」 に変わってきた、という話に近いです。営業資料や製品情報は、人間向けのPDFだけでは足りません。AIが解釈しやすく、誤解しにくく、比較に耐える構造化情報が必要になってきています。
では、売り手である営業側はどうか。こちらも、すでに実務段階に入っています。
営業側の活用は「週1回以上」が当たり前になりつつある
営業担当者・営業責任者の生成AI活用率は1年で28.9%から43.4%に上昇し、活用者の55.6%は週1回以上利用しています。利用ツールはChatGPTが75.4%で最多、Gemini、Copilotが続きます。有料版AIツールに対して「リターンを感じる」とした人は合計83.4%でした（同上）。
利用頻度が高いほど効果実感も高く、ほぼ毎日使う人は週平均3.6時間を削減し、有料ツールのROI実感率は71%でした。月1回程度の利用者では削減時間1.3時間、ROI実感率25%にとどまっています。ここから読み取れるのは、生成AIは“導入しただけ”では効かず、ワークフローに埋め込まれて初めて効くということです。
では、営業のどの業務で、とくに効果が出ているのか。調査結果は「入口」をはっきり示しています。
まず効くのは「記録とリスト」——ここから始めるのが筋
特に効果が高かった業務は、CRM/SFAへの活動記録入力と、アプローチ先のリストアップや優先順位付けでした。削減時間もROI実感も高い領域です。逆に言えば、最初のAI導入はここから始めるのが筋がいいという示唆になります。
重要なのは「余った時間を何に使ったか」です。もっとも多かったのは「提案の質を高めるための思考時間」で、次いで「休憩や労働時間の短縮」「振り返りや改善」「顧客との対話・関係構築」でした（同上）。うまく回っている営業組織では、AIで削った時間を、より人間的な価値の高い仕事へ再投資しているのです。この「記録系で時間を取り戻し、その先の提案や対話に振り向ける」流れが、後述するシステム設計の狙いとも一致します。
チャットで終わらせない——5つのレイヤーで設計の全体像をつかむ
「定型・記録系から始める」と前のセクションで書きました。その先、どこまで広げるかを決めるために、営業でのAI活用を5層に分けて考えると設計しやすくなります。ただのチャット利用で終わらせないための地図として、以下を押さえておきましょう。
記録自動化レイヤー——手を止める入力作業を減らす
商談録音から要約生成、次回アクションの抽出、CRM活動履歴の自動下書き、メール・議事録・タスクの自動生成、面談内容から案件ステージ候補を提案——いずれも最もROIが出しやすい領域です。技術的には、音声認識、話者分離、要約、項目抽出、CRM API連携の組み合わせで実装できます。音声を業務データにつなぐ設計の詳細は、前述の「文字起こしで終わらせない」記事を参照してください。
記録の次に効くのが、顧客理解を短時間で深めるレイヤーです。
リサーチ支援レイヤー——「この会社に持っていく理由」まで変換する
企業サイト・IR・採用情報・ニュースからアカウントブリーフ生成、顧客業界のトレンド要約、類似顧客の導入事例抽出、組織図・意思決定者仮説の生成、競合比較表の自動作成などが該当します。ここで重要なのは、ただWeb検索して要約するだけでは足りない点です。実際の営業現場では「この会社に今この提案を持っていく理由」が必要なので、ニュース要約ではなく、自社商材の訴求軸に変換したアカウントインテリジェンスが求められます。
その先が、提案そのものの質を上げるレイヤーです。
提案設計レイヤー——「それっぽい」ではなく「刺さる」提案を
顧客属性別の提案書ドラフト生成、業界別・課題別の導入シナリオ生成、稟議向け説明資料の下書き、顧客の反論予測と回答案生成、提案書の論点漏れチェック——この領域ではRAGが効きます。過去の提案書、導入成功事例、失注理由、FAQ、法務テンプレートなどを参照させることで、汎用LLMの弱点である“自社文脈の薄さ”を補えます。RAGの段階的な設計は「RAGとAgentic Search」で整理しています。
効率化だけでなく、営業力そのものを高めるレイヤーもあります。
対話コーチングレイヤー——営業力をデータ化して伸ばす
商談音声のレビュー、質問量・傾聴比率・競合言及・価格交渉の分析、トップセールスとの比較、ロールプレイ自動生成、次回商談の質問設計支援などが該当します。単なる効率化ではなく、営業力そのものをデータ化する領域です。ソフトウェアエンジニアで言えば、コードレビュー、Lint、テスト、CIの仕組みを営業対話に持ち込むイメージに近いです。
最後のレイヤーは、組織としての判断を支えるところです。
意思決定支援レイヤー——営業OSの一部としてのAI
パイプラインの異常検知、失注予兆の抽出、案件優先度の提案、商談停滞理由のクラスタリング、AI生成サマリーによる週次レビュー——ここまで来ると、AIは単なるアシスタントではなく、営業オペレーティングシステムの一部になります。5つのレイヤーを実現するには、AIをどこにどう配置するかが効いてきます。次に、そのシステム設計の考え方を整理しましょう。
単なるチャットではなく「業務のなかに差し込む」——システム設計の考え方
営業部門向けの生成AIシステムは、単一のチャットUIではなく、業務イベント駆動型のAIプラットフォームとして設計した方が、現場に刺さります。前のセクションで触れた「ワークフローに埋め込む」「業務プロセスへの組み込み」を、アーキテクチャでどう形にするかを押さえます。
全体は5層——AIを“別アプリ”にしない
基本構成は次の5層です。
-
業務システム層
CRM/SFA、MA、メール、カレンダー、Web会議、CTI、ナレッジベース、BI -
データ統合層
ETL/ELT、イベントバス、CDC、データレイク/ウェアハウス -
AI実行層
LLM推論、Embedding、RAG、ワークフローエンジン、評価基盤、ガードレール -
アプリケーション層
営業向けCopilot、管理者ダッシュボード、提案書生成、商談レビュー、CRM埋め込みUI -
ガバナンス層
認証認可、監査ログ、PIIマスキング、プロンプト管理、モデルルーティング、コスト監視
重要なのは、AIを“別アプリ”にしないことです。営業はCRM、メール、会議、Slack/Teamsの間を行き来しながら仕事をしているので、AIは専用画面よりも既存業務のなかに差し込まれている方が使われます。HubSpot調査でも、生成AI活用の定着は「許可」や「研修」より 「業務プロセスへの組み込み」 が最も効いており、週1回以上の利用率は74.8%まで上がっています（同上）。
この5層を支えるデータをどうまとめるか。営業AIでは、次のエンティティを中心にしておくと扱いやすくなります。
推奨データモデル——構造化と非構造化をひとつの文脈で束ねる
営業AI基盤では、最低でも次のエンティティを中心に設計したいです。
- Account / Contact / Opportunity / Activity
- Meeting Transcript / Email Thread / Proposal
- Product/Plan / Competitive Intelligence / Playbook
- Outcome / Win-Loss Reason
ポイントは、構造化データと非構造化データを一つの業務文脈で束ねることです。例えば Opportunity に対して、商談録音、メール、提案書、社内メモ、過去案件類似度、プロダクト制約を紐づける。これができると、AIは「一般論」ではなく「この案件について」の支援ができるようになります。
アーキテクチャとデータモデルを前提に、実際の実装をどう進めるか。次の3パターンを組み合わせるのが現実的です。
実装パターン——インライン、バックグラウンド、エージェントの3段階
実装は、次の3パターンの組み合わせが現実的です。
A. インライン支援
CRM画面の横にAIパネルを出す方式です。面談後の記録下書き、次回アクション生成、案件要約、リスク要因抽出などに使います。もっとも導入しやすく、ユーザー行動を変えすぎない一方、高度な自動化には限界があります。
B. バックグラウンド自動処理
会議終了、メール受信、案件更新などをトリガーに、裏でAIを動かす方式です。商談終了後の要約生成、次回アクションの自動起票、顧客ニュース検知、失注予兆スコアの更新などが該当します。体感価値が高く継続利用されやすい反面、誤作動時のUX設計が重要です。
C. エージェント型業務実行
複数ステップをまたいでAIがタスクを進める方式です。新規ターゲット候補の抽出、企業調査から初回メール素案作成、提案書の骨子生成、稟議資料のドラフト生成などで威力を発揮します。高い生産性向上が見込める一方、権限管理・品質保証・監査性が難しくなります。
実務上は、A → B → Cの順で進めるのが安全です。最初から完全自動化を狙うと、現場が信用しません。「任せる」設計の段階については「AIを使うから任せるへ」を参照してください。
ひとつ具体化すると——「商談後オートメーション」の設計例
ここまでアーキテクチャとパターンを述べてきました。最後に、もっとも導入しやすく効果が見えやすいユースケースを1つ、処理フローとコンポーネントまで具体化しておきます。記録自動化と提案支援の接点になる「商談後の自動記録＋次回提案支援」です。
このユースケースで実現すること
Web会議終了後に、以下を自動で行います。
- 録音データを文字起こし
- 商談要約を生成
- BANT/MEDDICなどの営業フレームで整理
- 宿題・懸念事項・競合情報を抽出
- CRM活動履歴を下書き
- 次回提案の論点を提案
- フォローアップメール案を生成
上記を実現する処理の流れは、次のとおりです。
処理フロー
- 会議終了イベントを受信
- 録音データを音声認識へ送信
- Transcriptを保存
- LLMで情報抽出
- CRMスキーマにマッピング
- ナレッジベースから類似案件・事例をRAG取得
- 次回提案論点を生成
- 営業へ確認UIを表示
- 承認後にCRMへ反映、メールドラフト生成
このフローを支える主要コンポーネントは以下のとおりです。
主要コンポーネント
- Meeting Connector：Zoom/Teams/Meet連携
- Transcription Service：音声認識
- Orchestrator：ワークフロー制御
- Extraction LLM：項目抽出・要約
- Retrieval Service：ベクトル検索＋メタデータフィルタ
- CRM Adapter：Salesforce/HubSpot/Dynamics連携
- Human Review UI：承認・修正
- Audit Logger：入出力履歴保存
PoCを本番に近づけるうえで、技術的に押さえておきたい点がいくつかあります。
技術的な注意点
出力を自由文だけにしない
LLM出力は、最終的にはJSON Schema準拠に寄せるべきです。後続処理や分析に使いやすくなります。
{
"summary": "商談要約",
"pain_points": ["課題1", "課題2"],
"decision_makers": ["担当者名"],
"budget_signal": "予算の言及有無",
"next_action": "次回アクション",
"competitor_mentions": ["競合名"],
"risk_flags": ["リスク要因"]
}
人手承認を前提にする
営業支援では、完全自動書き込みは危険です。最初は必ず「下書き保存＋人間承認」に寄せた方がよいです。
RAGの参照元に優先順位をつける
社内ナレッジは品質がまちまちです。成功事例、正式FAQ、製品仕様、法務テンプレートなど、信頼度ランク付きで検索対象を分けるべきです。
評価指標を事前に決める
PoCで終わる典型は、精度指標しか見ないことです。活動記録入力時間の削減、次回アクション記載率、CRM入力漏れ率、提案書初稿作成時間、商談準備時間、AI出力修正率、継続利用率、受注率や商談前進率への影響——業務KPIと利用実態の両方を見るようにしましょう。
機能より効いてくる——営業AIで押さえたい非機能要件
設計の後半に、営業データを扱ううえで機能以上に効いてくる要素をまとめておきます。ここを怠ると、せっかくの設計が現場で受け入れられなかったり、運用で詰まったりしがちです。
セキュリティ
営業データは顧客名、案件内容、価格、契約条件を含みます。PIIや機密情報のマスキング、テナント分離、監査ログ、アクセス制御は必須です。
説明可能性
営業マネージャーは「なぜその優先順位なのか」「なぜその提案を出したのか」を知りたがります。根拠リンク、引用元表示、参照ドキュメントの明示が必要です。
コスト制御
営業はイベント数が多いため、全商談を高価なモデルで毎回処理するとすぐに高コストになります。小型モデルで抽出、大型モデルで提案生成など、モデルルーティングが必要です。
ガードレール
提案文面に未提供機能、誤った価格、法務上危険な表現が入ると事故になります。製品カタログや許可済み表現集で制約をかける仕組みが必要です。
運用性
プロンプトはコードです。プロンプトバージョン管理、A/Bテスト、モデル更新時の回帰評価、フィードバック収集の仕組みが不可欠です。
現場に広げるには——現実的な3つのPhase
ここまでの設計を、実際にどうロールアウトするか。営業部門へのAI導入は、次の順が現実的です。
Phase 1：記録自動化
商談要約、CRM入力下書き、フォローアップメール生成。まずはここで「楽になった」を作る。
Phase 2：提案支援
顧客調査、提案骨子生成、類似事例検索。次に、営業品質を上げる。
Phase 3：マネジメント支援
パイプライン分析、停滞要因抽出、Win/Loss分析。最後に、組織学習へ広げる。
単なる「使っていいよ」ではなく、業務フローのどこで、何に使い、その結果をどう測るかまで設計しないと広がりません。HubSpotの調査でも、活用定着には組織支援、とくに業務プロセスへの埋め込みが有効でした（同上）。
まとめ——営業は消えない。技術者が作るのは「支える基盤」
ここまで、現状・5つのレイヤー・システム設計・具体例・非機能要件・導入の順で整理してきました。最後に、論点をひとつに絞ります。
生成AIは、情報の整理・比較・言語化・候補抽出には強い。しかし営業の本丸は、顧客の言葉になっていない不安を拾う、組織内の利害を読む、何を先に決めるべきか整理する、導入後の現実を一緒に描く、意思決定コストを下げるといったところにあります。この部分は、単純な検索や一般的な要約では代替しにくい。だから営業は消えません。ただし、説明中心の営業、資料を送るだけの営業、御用聞き型営業は急速に価値を失うでしょう。
生成AI時代の営業に必要なのは、人間らしさの強調ではありません。文脈理解を土台にした高解像度の意思決定支援です。そしてIT技術者の役割は、その営業を支えるシステムを作ること——単なるAIチャットボットではなく、営業が人間として価値を出すための時間と認知資源を取り戻すシステムです。
設計で押さえるのは、チャットを配ることではなく、CRMや会議基盤とつながること、構造化データと非構造化データを束ねること、RAGとワークフローで業務に埋め込むこと、人手承認と監査性を確保すること、時間削減だけでなく提案品質向上を測ること。営業部門のAI活用は、PoC向きのテーマに見えて、実はかなり本格的な業務システム設計の領域です。だからこそ、IT技術者が入る価値が大きい。ここで求められているのは、AIを動かすことではなく、人間の営業が強くなる業務基盤を設計することです。
作成日：2026年3月12日