こんにちは
AIチームの戸田です
先日開催されたNLP2026で、「B2B商談対話における階層的Dialogue Actスキーマの提案」という題目で発表させていただきました（P3-3）。ざっくり説明すると商談対話の構造をPhase層（商談の進行段階）とAct層（個々の発話の機能）の2層のスキーマで捉えよう、という提案です。
Phaseの遷移確率やActの出現パターンを明示的に制御することで、高品質な合成データの生成を目指すことが目的なのですが、本記事では、その実践に向けて、まず実データを分析して見えてきた商談対話の構造的な特徴と、そこから得た生成設計の方針を紹介します。
背景
AI ShiftではB2B商談を支援するAI Agentを開発しています。プロダクトを改善・評価するために、溜まった商談データを活用したいところですが、商談データは顧客情報や企業機密を含むため外に持ち出すことができず、活用できていないのが現状です。また、人工的に作るにしても、1商談は30〜50分・300ターンを超える長丁場となっており、アノテーションやマスキングにコストがかかってしまうため、スケールしにくいという課題があります。このデータ不足を合成データで解決できないか、というのが今回の取り組みの出発点です。
ただし、ここで重要なのは「合成できれば何でもよい」わけではないという点です。学習や評価に使う以上、実際の商談とかけ離れたデータを大量に作ってしまうと、モデルは現実にはあまり現れない振る舞いを学習してしまったり、評価でも不自然なデータにだけ強い“見かけ上の高性能”を示したりします。特にB2B商談では、短い相槌が頻繁に挟まること、Phaseごとに会話の進み方が異なること、営業と顧客の役割が非対称であることなどが対話全体の性質を大きく左右します。だからこそ、単に文として自然なだけでなく、商談としての構造まで含めてリアルであることが重要になります。
Dialogue Actスキーマの2層構造
詳細は論文を参照していただきたいのですが、本記事を読むにあたり、必要になる範囲で簡単に紹介します。
このスキーマは商談の対話をPhase層とAct層の2層で捉えます。Phase層は商談の進行段階（Opening → Situation → Proposal → Objection → Closing の5段階）、Act層は個々の発話の機能（Question、Respond、Acknowledgeなどの9種類）です。
ポイントは、Phase層とAct層が階層的に紐づいている点です。たとえばPresent（製品説明）はProposal Phaseに、Raise（懸念提起）はObjection Phaseに集中する一方、Acknowledge（相槌）やQuestion（質問）はどのPhaseでも出現します。この制約構造が、後述する合成データ生成で重要な役割を果たします。
以下に論文で定義したDialogue Actスキーマの定義を転記しておきます。
| 表1 Phase層の定義 | 表2 Act層の定義 |
|---|---|
 |
 |
実データの分析
分析対象は論文で使っていない新しい3件のロールプレイ商談で、いずれもAI Shift社内で行われたものになります。
| 商談 | 商談ターン数 | 時間 |
|---|---|---|
| A | 1301 | 約50分 |
| B | 2393 | 約50分 |
| C | 395 | 約20分 |
まず印象的だったのは、発話長の分布です。商談における各発話の文字数を集計すると、以下のような分布になりました。
- 短文（〜9文字）: 37%
- 「はい」「なるほど」「ええ」「そうですね」などの相槌、フィラー
- 中文（10〜59文字）: 34%
- 質問、短い回答
- 長文（60文字〜）: 31%
- 製品説明、状況説明（最長7,361文字）
発話の約4割が、たった数文字の相槌だったんですね。
実際の対話イメージはこちらになります。
営業: 弊社のAIエージェントはですね、まず貴社のCRMデータを分析して、
お客様ごとの最適なアプローチ方法を自動で提案するんですね。
導入企業様では商談化率が1.5倍に向上しておりまして… (約200字)
顧客: はい。 (2字)
営業: お客様ごとの最適なアプローチを自動で提案するんですね。 (約30字)
顧客: ああ、なるほど。 (6字)
営業が200字の説明をしても、顧客は「はい。」の2文字で応じています。こうしたやり取りが何十回と繰り返されることで、商談は300ターンを超える長さになります。この「2文字の相槌」と「200字超の長い説明」の共存こそが、後述するLLMによる合成を難しくしている主因だと考えました。
もうひとつの重要な発見は、各Phaseに固有の「リズム」があることです。たとえばSituationでは、営業が質問し、顧客が答え、営業が「なるほど」と相槌を打ってから次の質問に移る、というキャッチボール型の進行が多く見られました。他のPhaseにも同様のパターンがありました。以下に典型的な遷移パターンを図示します。
B2B営業の経験がある方なら、直感的にも「そうだよな」と感じるパターンなのかもしれません。重要なのは、こうしたパターンが統計的に再現可能だということです。
分析から設計へ
ここまでの分析から、B2B商談には少なくとも次の2つの特徴があると分かりました。
- 発話長に極端なばらつきがある（2文字の相槌〜7,000字超の長文説明が共存する）
- Phase内のAct遷移に統計的に再現可能なリズムがある
これらの特徴を持つ商談データをLLMで合成することは容易ではありません。シンプルに「300ターンのB2B商談を生成して」と頼んでも、LLMはある程度の長さの発話を好む傾向があり、「はい。」だけの2文字ターンをなどが入ることはほとんどありません。逆に500文字超の長い説明も出にくいです。
そこで、Dialogue Actを生成の制御をするための骨子として使えないか、と考えました。
設計原則はシンプルで、構造を作る部分と、テキストを書く部分を分離します。
- 構造（誰が・何のActで・何文字で話すか） → プログラム的に決定する。LLMは使わない
- テキスト（具体的にどう話すか） → LLMに生成させる
こうすることで、LLMは「何を話すべきか」を考える必要がなくなり、「決められた制約の中で自然な日本語を書く」ことに集中できるはずです。
この方針に基づいて、構造側では以下の3つの工夫を入れることを考えています。
① マルコフ連鎖によるAct列サンプリング
実データの遷移確率を直接使って、Phase内のAct列（営業:Question → 顧客:Respond → 営業:Acknowledge → …）を確率的に生成します。ルールベースのように多様性が失われることもなく、LLM生成のように実データのパターンから乖離することもない、ちょうどいいバランスになるのではないか、と期待しています。
② 動的計画法による発話長バケットの最適配分
生成した各Actに対して、short（〜9文字）/ medium（10〜59文字）/ long（60文字〜）の発話長バケットを割り当てます。実データを分析すると、Act種別ごとに「どの長さになりやすいか」の分布が大きく異なります。
| Act | short | medium | long |
|---|---|---|---|
| Acknowledge | 78% | 19% | 3% |
| Present | 6% | 22% | 72% |
| Handle | 7% | 25% | 68% |
| Question | 5% | 54% | 41% |
| Respond | 8% | 50% | 42% |
この分布と全体の比率制約（short 37%、medium 34%、long 31%）を同時に満たす割り当てを動的計画法で求めます。
③ Phase別逐次生成とコンテキスト要約
300ターンを一度に生成するのではなく、Phase単位で逐次的に生成します。Phase間の文脈断裂を防ぐため、完了したPhaseの内容をLLMで要約し、次のPhase生成時にコンテキストとして引き渡します。
ここまでの設計を一言でいうと、商談対話を最初から最後まで一気に生成させるのではなく、まず「どのような流れで、どのような長さの発話が並ぶか」という骨格を先に作り、そのうえで各発話を自然な日本語として肉付けしていく、という方針です。
実データの分析で見えてきたのは、商談らしさが単なる文の自然さだけでは決まらず、相槌の多さやPhaseごとの遷移パターンのような構造にも強く支えられている、ということだったので、合成でもまず構造を押さえにいく必要があると考えています。
まとめ
本記事では、B2B商談の合成データ生成に向けた問題分析と設計方針を解説しました。
実データの分析からは、「発話の4割が相槌」のような発話長分布の偏りと、Phase固有のAct遷移リズムの存在が明らかになりました。これらはLLMが単純なプロンプトで再現するのが難しい一方、統計モデルで忠実にモデル化できる性質のものです。
この知見に基づき、Dialogue Actを「生成の骨子」として捉え直し、構造の決定（マルコフ連鎖＋動的計画法）とテキストの生成を分離するアプローチを設計しました。
今回は分析と設計までの紹介でしたが、今後はこのアプローチを使った商談対話の合成にも取り組む予定です。実際の生成結果や評価についても、機会があればあらためて共有したいと思います。
最後までお読みいただきありがとうございました！
Discussion