営業が生成AIを使わない理由と利用率を上げる定着策
営業における生成AI利用率 — 現時点の実態数字
生成AIへの関心は年々高まっており、営業部門も導入を進める動きが広がっています。しかし、「導入した」と「日常的に使われている」のあいだには大きな断絶があります。利用の実態を見ると、積極的に使い続けているのは一部のメンバーに限られており、研修を受けた多くの社員はその後の継続利用に至っていません。「使ったことはある」と「業務に組み込んでいる」は、まったく異なる状態です。使う人と使わない人の二極化が進む一方で、全体の利用率という数字はなかなか上がらない——この構造が多くの現場で繰り返されています。
この記事ではその断絶の原因を、誰もが思い当たる「表層の理由」と、営業という仕事の構造に根ざした「根っこの理由」の2軸から解剖します。表層だけへの対処では定着しない理由と、実際に機能する打ち手を順番に示します。
「利用率」を追いかける組織が陥る落とし穴
多くのAI推進担当者が最初に手をつけるのは「利用率の向上」です。社内ツールへのアクセス数を可視化し、週に何回使ったかをレポートし、「全員が月に一定回数以上使う」という目標を立てる。この方向性は間違いではありませんが、利用率だけを追いかける組織には特有の罠があります。利用回数という指標は「使った」という事実を記録しますが、「業務に何らかの変化が起きた」という事実は記録しません。回数と業務変化は連動しているように見えて、実際には別の現象です。
この章では、利用率を追いかけることの本質的な限界と、代わりに何を見るべきかを示します。
「ツールを導入すれば活用が進む」「研修をすれば使う人が増える」——こうした前提のもとで施策が積み上げられていく現場は、珍しくありません。しかし、利用率が伸び悩んでいる多くの組織で見えてくるのは、施策の量や種類そのものが問題というより、問いの立て方に根本的なズレがある、という構造かもしれません。
問い直すべきは、「利用率を指標にしていること自体」ではないでしょうか。利用回数は、業務変化が起きたときに自然と上がる結果指標です。それを原因として扱い、「回数を増やすための施策」に力を注いでも、業務の中身は変わらないまま数字だけが積み上がっていきます。原因と結果を取り違えたまま施策を重ねても、「定着した」という状態には近づかないでしょう。
「何を変えたいのか」が組織として定まっていない段階では、KPIの設計よりも問いの立て直しが先に来ます。利用率という入口から問題を見ると、施策の選択肢は「どう使わせるか」に絞られます。業務変化という出口から見ると、問いは「どう組み込むか」に変わります。指標を変えることで、施策の方向性そのものが変わります。
回数が増えても業務が変わらない組織の特徴
あるチームのメンバーが週に複数回AIツールを使い始めたとします。数字の上では利用率は改善しています。しかし半年後に確認すると、使っている用途は最初と変わらず、業務にかかる時間もコストもほとんど変化していない——このパターンは、AI推進に取り組む現場でよく見られます。
問題は「使い方の深さ」です。同じタスクを同じ手順でAIに投げ続けていると、「AIを使っている」という感覚は積み上がっていきますが、業務フローそのものは変わりません。「使った感」の蓄積と業務変化は、まったく別のことです。利用率を指標にする組織は、この2つを区別しないまま改善を続けるため、数字が上がっても「何も変わっていない」という感覚が現場に残り続けます。この乖離が蓄積すると、AI推進そのものへの信頼が失われていきます。
利用率から「成熟度」へ — 追うべきKPIの転換
利用率の代わりに追うべきは「成熟度」です。ここでの成熟度とは、「AIが業務フローにどの程度組み込まれているか」を段階的に示したものです。一つの整理として、次の4段階が使いやすいでしょう。
- 未使用: ツールは入っているが、ほぼ使われていない状態
- 個人活用: 一部のメンバーが自分の判断で使い始めている状態
- プロセス組み込み: 特定の業務フロー(報告書作成・メール返信など)にAIが定位置として入っている状態
- チーム共有: プロンプトのテンプレートや活用事例がチームで共有され、組織的な改善が進んでいる状態
「今週の利用回数が増えたか」ではなく、「このチームは先月より1段階上の状態になったか」を問うことで、施策の方向性が変わります。利用頻度を増やすための施策(ツール案内・通知・アクセスしやすい環境整備)から、業務フローへの組み込み施策(テンプレート整備・定例での共有・成功事例の可視化)へとシフトできます。「利用率」という指標を追いかけている限り、施策はツールを開く回数を増やすことにしか向かいません。追うべきKPIを変えることが、定着への第一歩です。
使われない理由の全体構造
生成AIが職場で使われない理由として、さまざまな声が挙がります。「忙しくて試す余裕がない」「何に使えばいいか分からない」「プロンプトの書き方が分からない」「社内ルールが曖昧で使っていいか不安」——これらはいずれも本音であり、実在する障壁です。しかし、こうした表層の理由を一つひとつ解消しても定着に至らないケースが多くあります。理由は、その背後に営業という仕事特有の構造的な問題が潜んでいるからです。表層だけを対処し続けても、根っこが残る限り「使われない」状態は繰り返されます。
表層の理由と根っこの理由を切り分ける視点
表層の理由(忙しい・やり方が分からないなど)は、研修の実施やマニュアルの整備といった対処で軽減できます。しかしそれだけでは十分ではありません。
根っこの理由は3つあります。第一に、営業の価値は「個人の機転・関係性・状況判断」にあるため、何をAIに渡せるかの境界が見えにくいこと(次章で詳述する標準化と属人化の矛盾)。第二に、最初に試した体験が「使えなかった」という失望に終わり、そこで見切られること(後述する見限りのメカニズム)。第三に、推進を担うマネージャー自身がAIを使いこなせていないため、具体的な指示が出せないこと(後述する推進者自身の壁)。これら3つの構造的問題が、表層の対処だけでは解消されない「使われない」状態を生んでいます。
営業特有の矛盾 — 標準化×属人化
営業組織がAI活用を難しくしている根本的な矛盾があります。「標準化したい組織の意図」と「属人化を価値源泉にしている営業の現実」の衝突です。会社はAIを使って業務を標準化し、再現性の高い営業活動を横展開したいと考えます。一方で、営業パーソンの強みは、顧客との関係性・場の読み方・臨機応変な提案など、明文化しにくい「カン」の部分にあります。この矛盾の中でAIを使おうとすると、「自分の何をAIに渡せばいいのか」という根本的な問いに突き当たります。表面上は「プロンプトの書き方が分からない」という声として現れますが、その背後には「自分の仕事が言語化できていない」という構造的な問題が潜んでいます。
「暗黙知の勝ちパターン」がプロンプトにならない問題
成果を上げているベテラン営業パーソンに「AIを使ってください」と依頼すると、興味深いことが起きます。彼ら・彼女らが得意とするのは「この顧客はこういう言い方が刺さる」「この段階では価格より実績を出すべき」といった、状況依存の判断です。これは長年の経験から培われた暗黙知であり、そのままテキストには変換できません。
「AIに何を頼むか書いてください」と求めると、まず「自分が何をやっているか言語化できない」という壁に直面します。プロンプトを書く前に、自分の仕事を言語化しなければならない——これは、AIの使い方研修では解消されません。研修で教えられるのはAIの操作方法であり、「自分の強みを言語化する訓練」ではないからです。暗黙知の豊富なベテランほど、この壁にぶつかりやすいという逆説が生まれます。この問題を無視したまま「プロンプト研修」を繰り返しても、定着には結びつきません。
属人化された営業スタイルとAIの相性
もう一つの問題は、チームとしてのAI活用が難しいことです。営業チームのメンバーはそれぞれ異なるスタイルで動いています。長い信頼関係を武器にするトップ営業もいれば、ロジック重視の提案が得意な人、小まめなフォローで成果を上げる人もいます。こうした多様性がある中で「チーム共通のプロンプトテンプレート」を作ろうとすると、誰にも刺さらないものになりがちです。
横展開できるテンプレートが作れないと、各自が自分用のプロンプトを設計するしかありません。これは取り組める人と取り組めない人の格差を生みます。対処の起点は「全員共通のプロセス」ではなく、「最も属人化しにくい業務」から始めることです。商談後のフォローメール、議事録の整理、社内報告書の定型フォーマット——「誰がやっても似た形になる業務」に限定してAIを差し込むことで、スタイルの違いに関係なくチームとしての成功体験を積み上げられます。
「一度試して見限る」メカニズム
営業部門のAI活用を阻む最も実態的な壁は、「使ってみたけど使えなかった」という一度の失望体験です。研修直後は多くの社員が試しますが、数週間後には使用をやめてしまう——このパターンが繰り返されます。問題の多くは「AIが使えない」のではなく「使い方が間違っていた」ことにあります。しかし本人は「使ったのにダメだった」と判断しており、それがAIそのものへの評価として固定されてしまいます。このメカニズムを理解しないまま再研修を重ねても、同じ結果になるだけです。
最初のAI体験が「期待外れ」になる理由
最初にAIを試すとき、多くの人は「最も解決したいこと」から始めます。営業の場合、それは「提案書全体の作成」「複雑な案件の整理」「顧客の心理を読んだアプローチ提案」といった、難易度の高いタスクです。このような指示をAIに投げると、出力は「的外れ」か「大幅な手直しが必要」なものになります。「こんなもの使えない」という感想は正直であり、その時点の使い方では実際に使えないことが多いです。
しかし問題はAIではなく、インプットの設計です。難しすぎるタスク・曖昧すぎる指示では、AIは力を発揮できません。それでも「AIがダメだった」という結論が生まれるのは、「なぜ使えなかったのか」を問わず、結果だけを評価するためです。プロンプトの不足という本来の原因ではなく、AIの限界として解釈する誤帰属が起きています。この認知パターンが「見限り」の本質であり、最初のタスク選びが間違っている限り何度研修を重ねても同じ失望が繰り返されます。
見限りを防ぐ「最初の1タスク」の設計
見限りを防ぐには、最初に試すタスクを慎重に選ぶ必要があります。良い「最初の1タスク」には2つの条件があります。「インプットが明確であること」と「アウトプットの良し悪しを自分で判断しやすいこと」です。
具体的には次のようなタスクが適しています。
- 商談後のフォローメールの下書き(商談内容を箇条書きで渡し、メールにしてもらう)
- 議事録の要点整理(録音・テキストを渡し、論点と次のアクションをまとめてもらう)
- 社内報告書の構成案(背景・現状・課題・対策の4点を伝え、骨格を作ってもらう)
これらは「自分がすでに持っている情報をAIに整理してもらう」形であり、インプットの設計が比較的簡単です。出力がどの程度使えるかも自分で判断しやすいため、成功体験を得やすいです。最初の1タスクで成功体験を得た人は、次のチャレンジへの動機が生まれます。失敗体験から始めた人との差は、AIの能力差ではなく、最初のタスク設計の差によって生まれています。
推進者自身が壁になるという逆説
AI活用が職場に定着しない理由として「管理職が旗を振らない」という指摘は多くあります。確かに、上の立場の人間が具体的に動かなければ現場の温度は上がりません。ただ、なぜ旗を振れないのかに踏み込んだ分析は少ないです。最も多いパターンは、推進を任された管理職自身がAIを使いこなせていないことです。自分で使えていなければ、部下への指示は必然的に抽象的になります。「積極的に活用していきましょう」「うまく使ってみてください」という言葉は、具体的な行動に落ちません。管理職の「旗振り不足」を問題にする前に、その管理職が旗を振れない理由を見る必要があります。
管理職がAIを使えていない組織でAI化が進まない理由
管理職が「やってみてください」と言うだけでAI化が進まない理由は明確です。現場のメンバーは「何をやればいいか」の具体が見えていないからです。自分でAIを使いこなしている管理職は、「この業務でこの手順を使ったら作業時間が大きく短縮された」「この種の報告書は最初からAIに骨格を作らせると修正だけで済む」といった具体的なユースケースを持っています。この具体が伝わったとき、部下は「自分にもできる」というイメージを持てます。
逆に、管理職自身が「AI化を進めなければならない立場にいる」のに「自分はまだ使えていない」状態では、渡せる具体が存在しません。指示が抽象的なまま現場に降りても、誰も動けません。対処の起点は「推進者自身が自分の業務で1つだけ使い始める」ことです。チーム全体への展開よりも前に、まず自分が1つの具体的なユースケースを持つ。そこから語れる具体が生まれ、部下への指示が実行可能なレベルに変わります。推進者が先に使い始めることは、管理職の義務でありAI定着の起点です。
理由別の打ち手
これまでの章で示した「使われない理由」に対して、対処の方向性を整理します。表層の理由にはシンプルな打ち手が有効ですが、構造的な理由への対処には、やや長い目での取り組みが必要です。自分の組織で当てはまる理由から優先して手をつけることが、最も効率的なアプローチです。
| 理由 | 打ち手 |
|---|---|
| 使い所が決まっていない | 業務の棚卸しで「最も属人化しにくい業務」を1つ絞り込む |
| 仕組みに組み込まれていない | 既存の業務フロー(報告書・メール返信)にAIを差し込む |
| ルールが未整備で不安 | 「使ってよい範囲」を明示し、最初の1タスクを指定する |
| 管理職が動かない | 推進者自身が先に1つのユースケースを持つ |
| 最初の体験が失望に終わった | 最初の1タスクを設計し直す(難しいタスクではなく、インプットが明確なものから始める) |
定着の3原則と効果測定
利用率を追いかけるだけでは定着しないことは、これまでの章で示しました。では、定着を判断するために何を原則として置き、何を測ればよいのでしょうか。定着の取り組みは、3つの原則を守ることで機能しやすくなります。
原則1: 「全員一斉」ではなく、前向きな1人から始める。 一斉に始めると成功体験と失望体験が混在し、失望の声が広がりやすくなります。まず1人の成功体験を作り、それを可視化することで周囲の関心を引くほうが結果的に浸透は早くなります。
原則2: 成功体験を「再現できる形」にして横展開する。 「うまくいった」で終わらせず、そのときのプロンプトをテンプレートとして整備し、チームで共有します。再現可能な形にすることで、次の人が最初の1タスクを試しやすくなります。
原則3: 利用率ではなく「業務変化の有無」で評価する。 前述した成熟度の考え方を評価基準として使います。何回使ったかではなく、業務フローの中でAIが定位置を持ったかどうかを見ます。
何を指標に成熟度を測るか
成熟度を測る指標は、利用回数ではなく「業務フローへの組み込み段階」です。前章で示した4段階(未使用・個人活用・プロセス組み込み・チーム共有)を、定例会議の確認項目に組み込むことで継続的な測定が可能になります。
確認の方法はシンプルで十分です。月1回の定例で「先月と比べて段階が上がった業務や人がいるか」を5分間確認します。上がっていれば何が機能したかを共有し、上がっていなければ何が障壁になっているかを1つ特定します。利用回数という数字は追わず、「誰がどの業務でどの段階にいるか」という質的な状態を継続的に見ます。この問いを定例に組み込むだけで、組織のAI活用は「回数を増やす取り組み」から「業務を変える取り組み」へとシフトします。


