セールスエンジニアのワークフローにおけるAI：役立つ場面と崩れる場面
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
私が知るあるセールスエンジニアは、先四半期に40万ドルの案件を失いました。デモでもなく、POCでもなく、RFPでです。
彼は180問にわたるセキュリティ質問票をAIにかけ、自信に満ちた回答を下書きさせました。ざっと目を通して、そのまま提出したのです。94問目で、AIは存在しないきめ細かい権限機能を説明していました。完全な作り話です。
買い手側のエンジニアがこれを指摘しました。「デモで再現できなかった機能を主張している。他もすべて検証する価値がある」。彼らは見直しに入りました。さらに2つの捏造が見つかりました。案件は停滞し、そして消えました。
これがSE業務におけるAIの非対称性です。AIが節約する時間は本物です。嘘がばれたときに失う信頼性も本物であり、そのコストは節約分よりも大きいのです。
なぜ今これが重要なのか
セールスエンジニアリングは奇妙な交差点に位置しています。あなたはGTMのほぼ誰よりも、純粋なリサーチや下書きの作業を多くこなします。商談前の準備、RFP回答、デモ後のまとめ、社内向けの資料、統合についての書き起こしです。これらはまさにAIが加速する領域です。
同時に、あなたはAEやCSMとは違うかたちで技術的な正確性を問われます。買い手の主任エンジニアが同時実行モデルについて尋ね、あなたの回答が間違っていれば、その関係は権威を失います。そしてSEが買い手の技術評価者に対して一度権威を失うと、それは二度と戻りません。
ほとんどのSEチームは、これを感覚で何とかしようとしています。完全にAI一辺倒に振り切り、静かに信頼性を失い続けているチームもあります。原則としてAIを敬遠し、必要の倍も働いているチームもあります。正解はその中間にあります。AIを一つのスイッチのように扱うのが間違いなのです。
AIが役立つ場面：使うべきところ
顧客の信頼をリスクにさらすことなく、AIが本当に時間を返してくれる領域です。共通点は、AIに与えた元資料を要約しているか、提出前に入念にレビューする何かを下書きしているか、のどちらかであるという点です。
デモ前のリサーチ
ディスカバリーコールの前には、見込み客のビジネスを把握する必要があります。決算説明会、CEOのLinkedIn、エンジニアリングブログ、先四半期に変わったプロダクトなどです。これにはかつて90分かかっていました。AIを使えば10分です。AIは何も創作していません。あなたが元資料を与え、それを抽出するよう指示しているだけです。
プロンプト1：ディスカバリー前のリサーチ統合
[COMPANY] とのディスカバリーコールの準備を手伝ってください。
以下に元資料を貼り付けます。それを読んで、次を作成してください：
1. ビジネスの背景（3～5文）：何をしている会社か、誰を顧客にしているか、最近の戦略的な動き。
2. 表明されている優先事項：資料に言及された目標、施策、課題。
3. スタックのシグナル：言及されたツール、プラットフォーム、技術的な選択。
4. 上記を検証または拡張するために、コールで尋ねるべきオープンな質問を3つ。
元資料にあることだけを使ってください。資料にない場合は
「資料に記載なし」と書いてください。推測や憶測はしないでください。
[貼り付け：直近の決算説明会の要約、最近のブログ記事、経営陣のLinkedIn、
G2レビュー、その他関連するもの]
「元資料にあることだけを使ってください」という一文が重要です。これがないと、AIは自信ありげな一般論で隙間を埋めてしまいます。これがあれば、きれいな抽出結果が得られます。
デモ後のまとめの下書き
45分のコール録音が、2分で構造化されたまとめになります。あなたはそれをレビューし、編集して送ります。決して自動送信してはいけません。
プロンプト2：コール後のまとめの下書き
以下は [PROSPECT] とのディスカバリーコールの文字起こしです。
次を含むフォローアップメールのまとめを下書きしてください：
- コールで決まったこと（箇条書き2～4個）
- 私が回答を負っているオープンな質問（私の担当者名を付けて）
- 相手が回答を負っているオープンな質問（相手の担当者名を付けて）
- 合意した次のステップと日付
トーン：プロフェッショナルだが堅苦しくない。段落は短く。マーケティング的な言い回しはなし。
私が言及していない約束や機能を創作しないでください。何かがコミットされたか
確信が持てない場合は、断定せず「[要確認]」とフラグを立ててください。
[文字起こしを貼り付け]
「[要確認]」という指示が肝心な部分です。AIは物事を切り上げて大きく言いがちです。「おそらく検討できる」という曖昧な発言が、「必ず提供する」という確定的なものに変わってしまいます。不確実性にフラグを立てるよう強制すると、きれいに見える下書きに埋もれさせず、そうした箇所を表に出せます。
RFPの下書き着手
どのRFPでも、質問の60～70%は手垢のついた定番です。SSO、監査ログ、データ保持のデフォルト、基本的なセキュリティ体制などです。これらは回答が安定していて文書化されているので、AIでもうまく下書きできます。
残りの30～40%が案件の勝敗を決めます。そこには人間が必要です。簡単な60～70%をAIで片付けて、難しい30～40%にしっかり時間を使うために使ってください。全部を雑にやるためではありません。
プロンプト3：RFPの初回下書き
以下はRFPの質問です。各質問を次のように分類してください：
- TIER A：標準的／定番（SSO、基本的なセキュリティ、一般的な統合）
- TIER B：自社プロダクト固有（上限値、スケールの数値、統合の挙動、roadmap）
- TIER C：戦略的／オープンエンド（ビジョン、差別化、リスク）
TIER A の質問についてのみ、以下に提供する元資料を使って回答を下書きしてください。
TIER B と TIER C については「SE/PM のレビューが必要」と出力し、
どの専門家が回答すべきかを記してください。
いかなる場合も TIER B や TIER C の回答を下書きしないでください。
「これは概算です」と書いた下書きでさえ、最終回答に漏れ込みかねません。
[元資料を貼り付け：プロダクト文書、セキュリティ体制文書、直近3件の完了したRFP]
[RFPの質問を貼り付け]
このプロンプトがしていないことに注目してください。難しい部分の回答を生成してはいません。作業を仕分けているのです。AIの役割はトリアージであって、重要な質問への執筆ではありません。
デモストーリーボードの発想
技術的ディスカバリーの後には、見込み客が何を気にしているかが分かっています。あなたにはデモの流れが必要です。ここでAIは有用な発散思考のパートナーになります。あなたが思いつかなかった切り口を提案してくれます。中には間違ったものもあり、それがあなたに自分の選択を弁護させてくれます。
プロンプト4：デモフローのブレインストーム
[PROSPECT] とのデモがあります。ディスカバリーで分かったことは次のとおりです：
[ディスカバリーのメモを貼り付け]
実行できそうなデモフローを3つ、異なるものを提案してください。各フローについて：
- ナラティブの弧（どんなストーリーか）
- 見せる4～6個の具体的な瞬間
- 各瞬間がどのディスカバリーポイントに結びつくか
- このフローのリスク（何がうまくいかないか、何を過小に扱うか）
これらはアイデアであって、スクリプトではありません。特定のUI画面、正確な
機能名、現在のプロダクトの挙動を前提にしないでください。デモを組み立てる前に、
すべて実際のプロダクトと照合して検証します。
出力はブレインストーミングの素材です。3つのうち1つは捨て、別の半分を採り、自分の判断と組み合わせることになります。もしこれらのどれかをそのまま実行できるスクリプトとして扱っているなら、このツールを読み違えています。あわせて、買い手の課題を中心に据えたデモ設計も参照してください。
非同期の文書と社内向けの資料
ワンページャー、battlecard、社内FAQ、新人SE向けのオンボーディング文書。どれも低リスクで、社内向けで、反復しやすいものです。ここはAIの得意な場所です。何を出すかをあなたが管理でき、読み手は寛容で、修正は調達の意思決定ではなくSlack上で起こります。
プロンプト5：社内利用のための競合分析
[COMPETITOR] についての社内向け battlecard を作っています。以下は元資料です：
公開ウェブサイト、最近のG2レビュー、アナリストレポート2本、
この競合に言及された顧客コール3件の文字起こし。
次を作成してください：
1. 彼らの公開ポジショニング（彼ら自身の言葉で、2～3文）。
2. 彼らが得意とすること3つ（それぞれ出典を引用）。
3. 顧客が不満を持つこと3つ（どのレビューまたはコールかを引用）。
4. 買い手が最も気にする観点で、私たちが彼らと比べてどこに位置するか。
5. この競合が案件にいるとき、AEが陥りがちな罠を3つ。
これは社内利用限定です。すべての主張に出典を引用してください。出典を
引用できない場合は、その主張を含めないでください。
[元資料を貼り付け]
「すべての主張に出典を引用する」は、AIを自信ありげなデタラメ屋からリサーチアシスタントへと変えます。出力はより有用になり、失敗の仕方も見えるようになります。
AIが害になる場面：使わないところ
非対称性があなたに不利に傾く領域です。節約できる時間は小さく、AIが間違えたときのコストは大きく、しかも「間違い」がレビューで検出しにくいのです。
顧客向けRFP回答を未編集で
RFPのすべての言葉は書面でのコミットメントです。AIは、先のスプリントで何が出荷されたか、どの機能が見送られたか、統合がデモでは「動く」が本番では既知の信頼性問題を抱えていることを知りません。疲れたSEが金曜の午後4時に行うざっとしたレビューでは、幻覚を捕まえられません。全行をレビューするか、重要度の高いものはゼロから書き直すか、どちらかです。
技術的な正確性を伴う主張
上限値、スケールの数値、SLA条件、セキュリティ認証、統合の挙動。これらは決してAIで。これらはプロダクト文書、PM、またはセキュリティチームから来るものです。PMが「同時10,000ユーザーを200ミリ秒未満の応答時間で対応できる」と言うなら、それは主張してよい内容です。AIが言うなら、あなたは当て推量をしているだけです。
統合アーキテクチャの図
AIはもっともらしい図を描きます。もっともらしいことは正しいことではありません。一本の矢印の誤りが調達上の赤信号になります。セキュリティチームは機能一覧よりもアーキテクチャを慎重に精査するからです。統合アーキテクチャは手で描き、実際のプロダクトと照合して検証してください。
「それは可能ですか？」という質問
見込み客が「あなたのプロダクトはXができますか？」と尋ねたら、決してAIに答えさせてはいけません。AIが「はい」と言ってそれが本当なら、あなたは30秒節約しました。AIが「はい」と言ってそれが嘘なら、あなたはチームが実現できないコミットメントをしてしまったのです。正しい答えは常にこうです。「プロダクトチームに確認して、[日付] までにお返事します」。
よくある落とし穴
人間のレビューが1回だけの完全AI製RFP。 幻覚は流暢に見えます。正しいプロダクト名、正しい言い回し、正しいリズムを使います。間違っているのは、それ以外はきれいに読める段落に埋もれた1つの事実主張です。流し読みでは捕まえられません。全行をレビューするか、技術的な精度が要る箇所は手で書き直すか、どちらかです。
AIのデモストーリーボードをそのまま実行できるものとして扱う。 AIは、あなたのプロダクトの実際の画面、最新のUI変更、前回リリースで並べ替えられたワークフローを知りません。ストーリーボードは発想です。スクリプトは、稼働中のプロダクトに対して手で作り込むものです。
AIに「Xは自社プロダクトで可能か？」と尋ねる。 AIは自信を持って推測します。プロダクトの能力に関する主張は、常に実際のプロダクトか、それに携わる人から取ってください。
隠れたAI利用が社内の信頼を壊す。 PMがあなたのフォローアップメールにAI生成のコミットメントを見つけたとき、その後始末はAIが節約した時間より大きくなります。どこでAIを使っているか、チームにオープンにしてください。
「時間を節約した」を「良い出力」と混同する。 AIは時間を節約します。出力が良いかどうかは別の問題です。受注率や技術的正確性のレビュー通過率を測らずに、節約時間だけを根拠にチームがAI導入を称賛しているなら、計器なしで飛んでいる状態です。セールスエンジニアのよくある落とし穴も参照してください。
「ここでAI、そこではAIなし」の意思決定ツリー
どのタスクでもAIを使う前に、3つの質問をしてください。
- これは顧客に届くか？ いいえなら、AIはおおむね問題ありません。はいなら、続けてください。
- 技術的な主張を含むか？ いいえなら、AIで下書き＋軽いレビュー。はいなら、続けてください。
- 間違った回答が案件を失わせ得るか？ いいえなら、AIで下書き＋入念なレビュー。はいなら、AIなし。手で書き、主張は直接出典から取ってください。
正直に言えば、もっと単純です。リスクが高く技術的な主張が具体的であるほど、AIは使うべきではありません。リスクが低く元資料の抽出が主であるほど、AIを使うべきです。
AI出力レビューのチェックリスト
AIが下書きしたコンテンツを社外に出す前に。
- すべてのプロダクト能力の主張が、文書または専門家から裏付けられている
- 創作された機能がない（見覚えのない機能名を文書で検索する）
- すべての数値を検証済み：上限値、SLA、性能ベンチマーク、顧客数
- 内容が最新リリース時点のものである（廃止された挙動についての主張がない）
- トーンがチームの声に合っている（AIっぽさやチームらしくない冗長な動詞を取り除く）
- 捏造された顧客リファレンスがない（AIはロゴや引用を創作することがある）
- エッジケースの回答を該当するPMがレビュー済み
- 「[要確認]」とフラグが立ったものは、実際に確認済みになっている
- どの一文も、買い手の技術評価者に対してたじろがず弁護できる
ある一文が、将来の会話で表に出たときに顔をしかめそうなものなら、今のうちに直してください。
成果を測る
SEチーム全体でAIを展開しているなら、毎月3つを追跡してください。
商談あたりのリサーチ時間の節約。 デモ前準備の時間は意味のある幅で減るはずです。最初の四半期内に50%削減を目標に。
RFPの所要時間と、RFPの受注率。 受付から最初の社内下書きまでの時間は減るはずです。RFPの受注率は維持または改善するはずです。所要時間が改善する一方で受注率が下がるなら、スピードと正確性を引き換えにしています。引き戻してください。
技術的正確性のレビュー通過率。 AIが下書きした顧客向けコンテンツのうち、書き直しなしでSEレビューを通過する割合はどれくらいか。90%超なら、AIを使い足りていません。50%未満なら、間違った場所でAIを使っています。健全な範囲は60～80%です。
目標はAIをあらゆる場所で使うことではありません。AIが元を取る場所で使うことです。
本当に重要なスキル
プロンプトエンジニアリングは、SEのAIスキルとして過大評価されています。肝心なスキルはレビュアーの判断力です。何を信頼し、何を検証し、何を捨てて書き直すかを見極める力です。それはプロダクト知識、現場での時間、そして一度間違った回答を出してしまった傷跡から生まれます。
優れたプロンプトを持つがプロダクトの深みがないジュニアSEは、自信があってもっともらしく、たまに間違った仕事を生み出します。平凡なプロンプトでも深いプロダクト知識を持つシニアSEは、嘘を見抜いてきれいな出力を出します。後者のプロフィールで採用してください。ツールは簡単です。判断力は難しいのです。
その判断力が、より広いSEのツールとtech stackを形づくります。AIは一つのレイヤーであり、プロダクト知識、ディスカバリーのスキル、デモの技芸の上に乗っています。そのどれもAIで置き換えられるものではありません。
Rework が SE×AI のワークフローをどう支えるか
AIを使うSEチームの多くは、プロンプトをNotionに、まとめの下書きを文書に、RFP回答を別のツールに、そして信頼できる唯一の情報源であるプロダクト情報をConfluenceやSlack、PMの頭の中に散らばらせています。結局AIは不完全な元資料から下書きし、SEだけがそれを突き合わせることになります。
Rework Work Ops は、AIが必要とするものを集約します。精査済みのプロダクト回答の共有ライブラリ、「[要確認]」項目のトラッカー、そしてデモ後のメモをRework CRM内の商談に直接ひも付けるまとめテンプレートです。承認されたまとめは、SlackのDMではなく案件のそばに置かれます。Work Ops は1ユーザーあたり月額6ドルから、CRM は1ユーザーあたり月額12ドルからです。
ポイントは「Reworkがあなたの代わりにAIをやる」ことではありません。AIは、元資料とそれを取り巻くレビューの質を超えることはない、ということです。
持ち帰ってほしいこと
これからの2年で勝つSEは、最も多くのAIツールを持つ人ではありません。彼らは、自分の1週間のうちどの30%をAIがうまく扱い、どの70%がいまだ自分の判断を必要とするかを知っている人たちです。彼らはAIを使って下書き作業を片付け、案件を決める仕事、つまりディスカバリー、デモ設計、買い手の信頼を築く技術的精度の高い回答にもっと時間を割きます。
AIが優れたSEを作るのではありません。優れたSEがAIを数あるツールの一つとして使い、それがどこで元を取り、どこで密かに勝ったはずの案件を失わせるかを、はっきりとした目で見極めるのです。
さらに詳しく
Principal Product Marketing Strategist