新人の営業がAIに顧客役をさせて商談のロールプレイを行い、ヒアリングの抜けと提案の順番を振り返りのコメントにする

処理の起点を決める

新人が練習用の画面で「商談を始める」を押したときに始まります。 決まった時刻に動く処理ではありません。新人が空いた時間に何度でも練習できることが、この構成のいちばんの利点です。

会話の途中は、新人が1発言を送るたびに顧客役を1回呼びます。 採点は、「商談を終える」を押したときに1回だけ動かします。会話の途中で採点を動かさないのは、第1章に書いたとおり、顧客役と採点役を混ぜないためです。

押し忘れに備えて、30分たっても終わらない会話は自動で終わらせて採点します。 画面を閉じただけの会話も、記録表の「未採点」の列に残し、翌朝の時間主導型の処理でまとめて採点します。採点されない練習を出さないことで、指導役の見る記録表に抜けを作りません。

入力データを集める

質を決めるのは、いちばん上の「事実を話す条件」です。 「予算は来年4月から取る予定」という事実に、「予算や費用の取り方を尋ねられたら話す。製品の価格を聞かれただけなら、まだ決まっていないとだけ答える」という条件を付けます。条件が無いと、顧客役は話の流れで事実を先に出してしまい、聞けたかどうかの判定が意味を失います。

隠す事実は1枚に7つまでにします。 現在のやり方、困りごと、困りごとの影響の大きさ、決裁する人、導入の時期、予算、比べている他社。社内のヒアリングの項目と1対1で対応させ、項目の名前をそのまま事実の見出しにします。 対応させておくと、採点の結果を新人ごとに項目別で集計できます。

データの取得方法を決める

カードと項目は、スクリプトがスプレッドシートを読むだけです。新人が画面でカードを選ぶとき、画面に出すのは業種と規模だけにし、隠す事実はスクリプトの側だけで扱います。画面の HTML に事実を書き込むと、新人がブラウザから中身を見られてしまいます。

会話の全文は、採点の前に番号を振った形に並べ直します。 新人の発言に S1、S2、顧客役の発言に C1、C2 と番号を付け、採点役にはこの番号で根拠を答えさせます。 番号があるので、第5章の6番目の順番の判定が機械的にできます。

AIへ渡す前に整形する

1. カードの点検 … 隠す事実の見出しが「項目」シートのいずれかと一致しているかを確かめます。一致しないカードは選べない状態にします
2. 実在の名前の点検 … カードの社名・人名に、自社の顧客管理にある名前が混ざっていないかを照合します。練習に実在の顧客を使わないためです
3. 発言の長さの確認 … 新人の1発言が極端に長いときは、要点を絞るよう画面で促します。台本の貼り付けを防ぎます
4. 会話の番号付け … 採点の前に、発言に S と C の番号を振ります
5. 短すぎる会話の除外 … 新人の発言が5つ未満で終わった会話は採点せず、「練習として短すぎる」と記録します

2番目を軽く見ないでください。 先輩が顧客役をしていたころは、実際の商談相手を思い浮かべて設定を作ることがよくありました。同じことをカードでやると、顧客の情報を外部のサービスへ送ることになります。 カードは架空の会社で作ると、研修の担当と最初に決めておきます。

AIに処理させる

顧客役にさせるのは、カードの性格で話し、条件を満たした質問にだけ事実を答えることです。 採点役にさせるのは、会話の全文を読み、隠した事実ごとに、会話に出てきたかどうかと、その事実を引き出した新人の発言の番号を返すことです。

右端の volunteered が、採点役の仕事でいちばん大事な区別です。 顧客役が条件を外れて事実を話してしまうことは、どれだけ指示を書いても起こりえます。そのときに「聞き出せた」と数えると、新人は聞いていないのに合格になります。 事実を引き出した新人の発言番号が無いものは、すべて volunteered にします。

1行目は、最初に研修の担当と決めておきます。 採点の結果を並べると点数のように見えますが、この構成は「どの事実を聞き逃したか」を本人に返すためのもので、比べるためのものではありません。

指示内容を固定する

顧客役への指示です。

あなたは法人向けの勤怠管理の製品について、初めて営業の説明を受ける会社の担当者です。
下のカードに書かれた人物として話してください。あなたは営業の練習の相手役です。

【カード】{card_public}
【隠している事実と、話してよい条件】{card_hidden}

【守ること】
- 隠している事実は、条件を満たす質問をされたときだけ答えてください。
  条件を満たさない質問には、その事実に触れずに短く答えてください。
- 自分から困りごとや予算や決裁の話を始めないでください。
- カードに書かれていないことを聞かれたら「分からない」「社内で確認する」と答え、
  新しい事実を作らないでください。
- 営業の進め方について助言したり、次に何を聞くべきかを教えたりしないでください。
- 1回の返答は3文以内にしてください。
- 営業担当が製品の説明を始めたら、カードの性格に合わせて聞いてください。
  ただし、そこで隠している事実を話してはいけません。

採点役への指示です。

あなたは営業研修の記録係です。下の会話は、新人の営業（S）と、
練習の顧客役（C）の初回商談です。顧客役は事実を隠し持っていました。

【隠していた事実の一覧】{card_hidden}
【会話（発言に番号付き）】{numbered_transcript}

事実ごとに、次の status を1つ選んでください。
- elicited ..... 新人の質問によって、その事実の中身が会話に出た
- partial ...... 事実の一部だけが出た（例：時期は出たが予算の取り方は出ていない）
- volunteered .. 新人が尋ねていないのに、顧客役が自分から話した
- missed ....... 会話に出てこなかった

【厳守事項】
- elicited と partial には、その事実を引き出した新人の発言番号（S の番号）を必ず入れてください。
  番号を示せないものは elicited にしないでください。
- 顧客役の発言だけを根拠にしないでください。新人がその前に何を尋ねたかで判断してください。
- 新人が製品の機能や価格の説明を最初に始めた発言番号を first_pitch_turn に入れてください。
  無ければ null にしてください。
- 改善の一言は、事実ごとに1文までにし、根拠の発言番号を添えてください。
- 点数、順位、新人の人柄についての意見は書かないでください。

「番号を示せないものは elicited にしない」が、採点役の指示の要です。 何も言わなければ、採点役は「会話の中に予算の話が出てきた」ことを根拠に elicited を付けます。出てきたかどうかではなく、新人が引き出したかどうかを見ることを、番号を求めることで強制します。

顧客役の「1回の返答は3文以内」も効きます。 長く話させると、顧客役は話の流れで事実を漏らします。短く答える相手のほうが、実際の初回商談の担当者にも近くなります。

出力形式を固定する

採点役からは、次の形のJSONで受け取ります。

{
  "session_id": "",
  "card_id": "",
  "facts": [
    { "item": "current_process", "status": "elicited | partial | volunteered | missed",
      "evidence_turn": "S4", "comment": "" }
  ],
  "first_pitch_turn": "S6",
  "turn_count": { "sales": 0, "customer": 0 },
  "summary_comment": ""
}

facts には、カードの隠す事実の数だけ要素を並べます。item は「項目」シートの見出しに対応する current_process ／ pain ／ impact ／ decision_maker ／ timeline ／ budget ／ competitor です。

1つ目の理由は、形を固定できることです。 Responses API では、text: { format: { type: "json_schema", strict: true, schema: ... } } の形でスキーマを渡し、required と additionalProperties: false で項目を固定します。status は enum で4つに絞れます。記録表の列に、そのまま書き出せます。

2つ目は、順番の判定をAIの外に出せることです。 スクリプトが次の規則で判定します。

規則はスプレッドシートの側に置きます。 「影響の大きさを確かめる前の提案も誤りとするか」は会社ごとに違い、研修の担当が後から変えられるようにしておきます。

3つ目は、拒否と途中切れを検知できることです。 安全上の理由で拒否された場合は refusal が返り、スキーマに沿わない形になります。出力の上限で切れた場合は status が incomplete、incomplete_details.reason が max_output_tokens になります。どちらも記録表に書かず、「要確認」として指導役に回します。

システムへ連携する

API を呼ぶのは、すべてスクリプトの側です。 画面からは発言だけを送り、API のキーとカードの隠す事実は画面に出しません。 スクリプトから外部へ要求を送る回数には1日の上限があり、Google Workspace のアカウントでは URL Fetch が1日100,000回、1回の実行は6分までとされています。月120回の練習で、1回に新人の発言が20ほどなら、上限には届きません。

顧客管理のシステムにはつなぎません。 練習で使うのは架空のカードだけで、実在の顧客の情報を取りにいく経路を作らないことが、この構成の安全の前提です。

人が確認する

指導役は、すべての練習の記録を見ます。 ただし、見る順番を決めておきます。

1. volunteered が多い回を先に見る … 顧客役が条件を外れて事実を話している。カードの条件の書き方を直す材料です
2. missed の項目と、新人の発言を読み比べる … 本当に聞けていないのか、聞いたのに採点役が拾えていないのかを確かめます
3. 順番の規則判定を確かめる … pitch_before_pain が出た回は、新人の first_pitch_turn の発言を読みます
4. 一言を足す … 下書きのコメントを直し、次の練習で何を1つ試すかを書きます
5. 判定を覆したら記録する … どの事実の status を、どちらに変えたかを残します

2番目を省かないでください。 新人が遠回しに予算を尋ね、顧客役がそれに答えているのに、採点役が missed を付けることがあります。その判定のまま返すと、新人は聞けていたことを聞けなかったと覚えてしまいます。

目標は、1回あたり6分です。 会話の全文を頭から読むのではなく、判定の根拠の発言番号から該当の発言だけを読むことで収めます。

例外に対処する

3行目が、運用の初めにいちばん多く出ます。 カードの条件の書き方は、何度か練習を回して直すものです。最初の1か月は、指導役が volunteered の数を毎週数えてください。

記録を残す

• 会話の全文（番号を振った形）と、使ったカードの ID、そのときのカードの内容
• 採点役が返したJSONの全文と、順番の規則判定の結果
• 指導役が足した一言と、判定を覆した記録
• 新人ごとの、項目別の missed の回数の推移
• カードごとの volunteered の回数

1つ目で「そのときのカードの内容」を残すのは、カードを後から直すためです。 条件の書き方を変えると、同じ ID のカードでも聞き出しやすさが変わります。当時のカードが残っていないと、新人の成長とカードの変更の区別がつきません。

API 側に残る記録は、別に決めます。 API へ送ったデータは、明示的に共有を選ばない限りモデルの学習に使われず、不正利用の監視のログは既定で最大30日保持されるとされています。練習の記録の正本はスプレッドシートの側に置き、API 側の会話は採点が済んだら消します。