営業やマーケの業務にAIを入れてみたものの、結局は出てきた下書きを人が全部書き直している。そんな話をよく聞きます。
逆に、任せすぎて冷や汗をかいた話も出てきました。
この二つは、根っこが同じです。どこまでを機械に任せ、どこで人間が止めるのかを先に決めていないという一点に集約されます。
この記事では、GTMの業務にAIエージェントを組み込むときの設計を扱います。GTMとは Go-To-Market の略で、製品を市場へ届けるためのマーケティング・営業・カスタマーサクセスの一連の活動をまとめた言い方です。
流行り言葉の紹介はしません。承認をどこに残すか、何を評価するか、外れたときにどう止めるか。
運用に耐える形だけを書きます。
エージェントは、画面の中ではなく業務フローの中に置く
まず言葉を揃えます。ここで言うAIエージェントとは、指示を受けて複数の手順を自分で進め、外部のシステムを読み書きするプログラムのことです。
チャット画面に質問を打ち込む使い方とは、置き場所が違います。
うまく回っている例を見ていくと、共通点があります。AIを画面の外に出して、出来事が起きたら自動で走る形にしていることです。
たとえば資料請求が入った、商談が特定の段階に進んだ、解約の兆候が出た。そうしたイベントを引き金に、CRM（顧客管理システム）やチャット、ヘルプデスク、データ基盤をまたいで処理が走ります。
この差は小さく見えて、成果に直結します。人が思い出して開きにいくツールは、忙しい週から順に使われなくなるからです。
便利機能を足すのではなく、フローを引き直す
よくあるつまずきが、既存の業務はそのままで、途中にAIの下書きボタンだけを足すやり方です。
一見すると導入できています。でも人の手順は一つも減っていません。
効いているのは逆の順番です。まずその業務を今の形でやる必要があるのかを疑い、手順そのものを引き直してから、空いた場所にエージェントを埋めています。
たとえば問い合わせ対応なら、担当者が内容を読んで分類して担当を割り振る、という三手をまとめて置き換えます。ボタンを一つ足すのとは、削れる時間の桁が違います。
どの業務から手をつけるかの考え方はGTM自動化はどこから始めるか｜浅く広くより、深く狭くでまとめました。全社一斉より、狭く深くのほうが結局は早く着地します。
トップパフォーマーの判断手順を、先に文章にする
フローを引き直したら、次にやることがあります。その業務でいちばん成果を出している人が、何をどの順で見て、どう判断しているかを書き出すことです。
面倒に見えますよね。でもここを飛ばすと、たいてい失敗します。
理由は単純で、書けない判断は指示にもできないからです。なんとなく筋が良さそうな問い合わせ、という感覚は、そのままではエージェントに渡せません。
書き出すときは、正解だけでなく捨てる基準も一緒に残してください。優秀な人ほど、追わない案件を素早く見切っています。
手順書は、観察してから書く
自己申告だけで書くと、実際の動きとずれます。人は自分の判断を、あとから整理しすぎて説明してしまうからです。
だから実際の記録を並べて確かめます。成約した案件とそうでない案件を10件ずつ持ってきて、初回接触の前に見ていた情報を洗い出す。
このとき、サイト上の行動履歴が残っていると精度が上がります。Strideのセッションリプレイや、訪問者ひとりの動きをセッションをまたいで時系列で追うN1分析は、担当者が勘で言っていた判断の裏側を確かめるのに向いています。
一人の行動から仮説を立てる進め方はN1分析とは｜一人の行動から改善のヒントを得るに詳しく書きました。
書き上がった手順書は、エージェントの指示文になるだけではありません。新人教育の資料としてもそのまま使えます。
承認をどこに残すかは、二つの軸で決める
ここが本題です。人間の承認は、多いほど安全ですが、多いほど自動化の意味が薄れます。
全部に承認をつけたら、それはただの下書き生成ツールです。
判断の軸は二つで足ります。取り返しがつくかどうかと、間違えたときに外部へ露出するかどうかです。
この二軸で、承認の形を分けます。整理するとこうなります。
| 業務の例 | 取り返し | 承認の形 |
|---|---|---|
| 商談メモの要約・CRMへの記録 | つく | なし（事後の抜き取り確認） |
| リードの優先度づけ・担当割り当て | つく | なし（週次で分布を確認） |
| 顧客への返信・提案文の送信 | つきにくい | 送信前に人が承認 |
| 値引きや契約条件の提示 | つかない | 人が作成、AIは下書きまで |
社外に出るもの、お金に関わるもの、消えると戻らないもの。この三つには承認を残す、と覚えておけば大きく外しません。
承認は三段階で考えると運用しやすい
承認をつける・つけないの二択にすると、現場が窮屈になります。あいだの段階を用意してください。
実務では、次の三段階に整理すると回りやすくなります。
- 事前承認：エージェントが下書きし、人が確認してから実行する
- 事後レビュー：エージェントが実行し、一定件数を人が後から抜き取って見る
- 例外承認：普段は自動、条件を外れたときだけ人に上げる
多くの業務は、最初は事前承認で始めて、精度が見えたら事後レビューへ落とすのが安全です。いきなり全自動にする理由はありません。
三つ目の例外承認は、条件の書き方が肝になります。金額が一定以上、既存顧客ではない、過去に苦情がある。
こうした条件を明文化しておけば、判断の一貫性が保てます。
承認する人の負荷も、設計の対象
見落としがちなのが、承認者の疲労です。たとえば1日に80件の承認依頼が飛んでくれば、人はいずれ中身を見ずに押すようになります。
それは承認が存在しないのと同じです。むしろ承認したという記録が残るぶん、たちが悪い。
だから承認の件数にも上限を置きます。1人あたり1日20件を超えたら、承認の範囲が広すぎるサインとして設計を見直す、といった目安を決めておくといいですよ。
部門の合意は、並走期間で取る
MQL（マーケティングが見込みありと判断したリード）の優先度づけをエージェントに任せる、と提案したとします。営業からはまず反発が来ます。
自分の商談の入口を、中身のわからない仕組みに握られるのですから当然です。
ここで理屈を並べても平行線になります。効くのは、最初の1か月は人の判断と並走させて、食い違った案件だけを一緒に見るやり方です。
食い違いを見ていくと、たいてい両側に発見があります。エージェントの見落としが直り、同時に人の判断基準もはっきりします。
合意は説得ではなく、共同で基準を作る作業だと考えると進みます。並走の記録がそのまま、引き継ぎ基準の文書にもなります。
出す前に評価する — シャドーモードとテストセット
エージェントを本番に出す前に、必ず答え合わせをします。ここを飛ばした導入は、たいてい現場の不信で終わります。
やり方は二つあります。
一つはテストセットです。過去の案件から50件ほど選び、正解ラベルをつけて、エージェントの出力と突き合わせます。
もう一つがシャドーモードです。本番と同じ入力を流すが、出力は誰にも届けず記録だけする運転の仕方を指します。
シャドーモードの結果は、そのまま判断材料になります。仮の数字で見てみましょう。
シャドーモード運転（2週間・対象=新規問い合わせ 400件）
エージェントの優先度判定 vs 実際の商談化
高と判定 120件 → 商談化 42件（35.0%）
中と判定 180件 → 商談化 27件（15.0%）
低と判定 100件 → 商談化 4件（ 4.0%）
人間（現行運用）の優先度判定
高と判定 150件 → 商談化 45件（30.0%）
判断: 高判定の精度は人間と同等以上。ただし低判定に4件の取りこぼし
対応: 低判定は自動で落とさず、日次で一覧を人が眺める運用にする
数字が出ると、議論の質が変わります。任せていいかという曖昧な問いが、どこまで任せるかという具体的な問いに変わるからです。
評価する指標を、最初に決めておく
評価をあとから決めると、都合のいい数字を探す作業になります。だから運転を始める前に書いてください。
見るのは精度だけではありません。最低限、次の四つは記録しておきます。
- 一致率：人の判断と同じ結論になった割合
- 修正率：出力を人が直した割合
- 修正時間：1件あたり直すのにかかった平均時間
- 例外率：条件を外れて人に上がってきた割合
三つ目の修正時間が、いちばん忘れられます。そして、いちばん現場の実感を左右します。
仮に月400件を処理するとしましょう。精度85%なら修正は60件、1件30分かかると月30時間です。
一方で、人が全件を1件8分で処理していたなら月53時間。差は23時間しかありません。
修正が1件45分に伸びれば45時間になり、効果はほぼ消えます。
精度だけを見ていると、この逆転に気づけません。指標の定義が部門間でずれる問題も同じ根で、揃え方はKPI定義のすり合わせ｜同じ指標なのに数字が食い違う理由に整理しました。
ガードレールは、権限・範囲・停止の三点で組む
評価が済んでも、本番では想定外が起きます。だから事前に囲いを作ります。
ガードレールとは、エージェントができることの外枠をシステム側で固定する仕組みのことです。指示文でお願いするのではなく、そもそもできなくしておくのが要点です。
指示文だけで縛るのは危ういと考えてください。うまく書けば守ってくれる、では事故は防げません。
囲い方は、定義として一枚に書くと抜けが見つかります。
agent: inbound_triage
trigger: form_submit（資料請求フォーム）
reads: crm.contact(読み取り), analytics.session(読み取り)
writes: crm.lead.priority, crm.lead.owner # これ以外は書き込み不可
forbidden: メール送信 / 値引き提示 / 顧客レコードの削除
approval: なし（priorityのみ）／ owner変更は事後レビュー
rate_limit: 200件/日
stop_if: 30分あたりの処理件数が平常の3倍を超えたら自動停止
audit: 入力・出力・判断根拠を90日保存
writes の行に書いていない項目は、権限そのものを与えません。読み取りと書き込みを分けて設計するだけで、事故の範囲はかなり狭くなります。
stop_if の行も忘れずに。暴走はたいてい件数の急増として現れるので、しきい値を超えたら自動で止まるようにしておきます。
誰が止められるかまで決めておく
技術的な停止スイッチがあっても、押す人が決まっていないと止まりません。当番と連絡経路を書いておいてください。
止めたあとの復旧手順も一緒に。止めることが大ごとになるほど、現場は止めるのをためらいます。
そして監査ログ。何を入力として、何を出力し、なぜそう判断したか。
あとから経緯をたどれない自動化は、問題が起きたときに原因を特定できません。
土台がないと、エージェントは正しく動けない
ここまで承認と囲いの話をしてきました。でも実は、その手前でつまずくケースのほうが多いのです。
参照するデータがバラバラだと、エージェントは自信満々に間違えます。
必要な土台は三つあります。用語と手順をまとめたナレッジベース、部門をまたいで同じ意味を持つKPI定義、そしてセマンティックレイヤー。
三つ目は、売上や商談といった言葉が社内のどのデータのどの計算式を指すのかを一箇所に決めておく仕組みだと思ってください。
土台の作り方そのものはGTMデータ基盤｜AIが正しく動くための土台づくりで扱っています。
サイト側の行動は、独立した層として揃える
土台のうち、意外と抜けているのがウェブサイト上の行動データです。CRMには商談が入っていても、その前に何を見て何で迷ったかは残っていないことがよくあります。
ここでのStrideの立ち位置は、サイト側の匿名の行動を正しく測る層です。ファネル分析、流入元の自動分類、エンゲージメント計測までを担いますが、Cookieを使わず氏名やメールも取りません。
つまり個人を特定してリードに紐づける機能や、メール配信、商談管理はありません。個人に紐づく情報はCRMやMAツールの担当で、行動の層と組み合わせて使う前提になります。
境界を曖昧にしないほうが、結局は設計が楽です。どこにどの情報があるかが決まっていれば、エージェントに渡す参照先も自然に決まります。
なおStrideはMCPに対応しているので、ClaudeなどのAIから自然言語で分析を呼び出せます。エージェントの判断材料としてサイト行動を参照させたいとき、専用の連携を作らずに済むのは実務では効きます。
着手の順番と、空いた時間の行き先
最後に進め方です。順番を間違えると、労力のわりに何も変わりません。
選ぶ業務の条件は三つ。頻度が高いこと、手順の再現性が高いこと、そして遅れることのコストが大きいことです。
三つ目が特に大事です。半日遅れても誰も困らない業務を自動化しても、体感は変わりません。
逆に、問い合わせから初回接触までの時間のように、遅れがそのまま失注につながる業務は効果がすぐ見えます。反応が数分で返るか翌営業日になるかで、相手側の温度はまるで違ってきます。
空いた時間を、どこに戻すか決める
自動化の成果は、実は削減した時間そのものでは決まりません。空いた時間を何に使ったかで決まります。
仮に1人あたり週5時間空いて、対象が8人だとします。月に換算すると約160時間です。
その160時間が既存顧客との対話や失注理由の掘り下げに回れば、翌四半期の数字が動きます。会議が増えただけなら、何も起きません。
ここを決めずに始めると、効率化はできたのに売上が動かない、という結果になりがちです。導入の企画書に、再投資先を一行だけでも書いておいてください。
入力作業を減らすと、データが貯まりはじめる
もう一つ、順番の話をします。データが揃ってから自動化する、と考えると永遠に始まりません。
実際の順序は逆になることが多いです。人の入力作業をなくした結果として、データが貯まりはじめます。
商談メモの手入力をやめて自動記録に切り替えると、記録率が上がります。すると翌四半期には、分析にも判断にも使えるデータが手元にある。
この順序を知っていると、最初の一手を選びやすくなります。判断を任せる前に、記録を任せる。
まとめ
AIエージェントの導入は、賢いモデルを選ぶ作業ではありませんでした。どこで人間が止めるかを設計する作業です。
やることは五つです。フローを引き直す、判断手順を書き出す、二軸で承認の形を決める、シャドーモードで評価する、権限と停止をシステム側で固定する。
どれも派手さはありません。でもこの五つが揃うと、任せる範囲を安心して広げていけます。
まずは一つの業務を選んで、いま人がやっている手順をそのまま書き出してみませんか。書けない部分が見つかったら、そこが最初に向き合う場所です。