CPQ実践

大規模言語モデル（LLM）は「トラック」が何かは知っていますが、貴社の「トラック」については何も知りません。これこそ、SKUや属性、ルールテーブルだけで構成された既存のCPQにAIを導入しようとする多くのチームが直面する壁です。AIが生成する回答は一見流暢に見えますが、その根拠は非常に薄弱です。営業担当者が「なぜこのスリーパーキャブが推奨されるのか」と尋ねても、システムは意味のある回答を返せません。 これは、私自身がワークショップで何度も目にしてきた光景です。しかし、各オプションが存在する「時」と「理由」、つまり明確なコンテキストをモデルに与えると、AIとの対話は一変します。システムは単なる推測をやめ、的確な助言を始めるようになります。これはAIの魔法ではありません。「背景情報（ナラティブ）」を持つデータがもたらす変化なのです。 既存データに欠けている要素 ルールテーブルは、システムに「何が有効な組み合わせか」を教えることはできますが、「なぜその選択が賢明なのか」「どのような状況で適用すべきか」「いつ選択すべきでないか」は教えてくれません。この情報ギャップを埋めるために、結局はメールや個別のスプレッドシート、担当者の頭の中にある属人的な知識に頼らざるを得なくなります。そして、私たちはそれを「システムが導入・定着しない問題」と呼ぶのです。 AIの推論層が必要としているのは、これ以上のデータ項目ではありません。各オプションに関する、以下のような機械が読み取れる「意図」です。 仕様だけでなく目的を平易な言葉で説明する記述 トレードオフを明確にするメリットとデメリット 具体的な利用シーンを示すポジティブシナリオとネガティブシナリオ コスト、リードタイム、サービス、リスクへの影響 ここで発想の転換が必要です。これまでWebサイトのコピーだと考えられてきた製品マーケティングのコンテンツは、これからは製品コンフィギュレーションモデルへの重要な「入力情報」となります。このコンテンツを構造化して初めて、AIはそれを用いて推論できるようになります。構造化されていなければ、AIはもっともらしい嘘を自信満々に生成するだけです。 PIMからナレッジベースへ 多くの製品情報管理（PIM）や価格表は、ID、階層構造、価格設定といった...

複雑な機器を販売する企業には、必ず一人は誰よりも製品を熟知しているエース担当者がいます。他の担当者がまだスプレッドシートを開いている段階で、彼女は混沌とした顧客の要望を、製造可能でクリーンな仕様にまとめ上げることができます。彼女はヒーローです。しかし同時に、高速道路における一車線の橋のような、ボトルネックそのものでもあります。 あるグローバル展開の案件を思い出します。大規模な見積もりはすべて、一人の専門家のレビュー待ちで行列を作っていました。案件は停滞し、承認プロセスは山積みです。製品部門は営業部門に、特殊な事例の案件をこれ以上受けないでほしいと懇願する始末でした。ツール自体は問題ありませんでしたが、業務の流れが滞っていたのです。 一人の頭脳に成長が依存している状態は、もはや営業プロセスとは呼べません。それは、名前のついたボトルネックです。 我々に必要なのは、より高性能な計算機ではなく、「翻訳機」です。 多くのチームは、すべてのルールをコード化した大規模なCPQプロジェクトが解決策だと考えがちです。それは安全な道に聞こえますが、結果として遅く、高価で、脆いシステムになることがほとんどです。数ヶ月かけて例外的なルールをモデル化しても、現場はすでに新しい例外を生み出しています。 真の問題は、見積もりの背後にある計算ではありません。顧客の状況を、有効な製品構成へと「翻訳」するプロセスにあります。あのエース担当者は、計算を解いて答えに辿り着くわけではありません。顧客の話に耳を傾け、問題を整理し、本質を突く2つの質問を投げかけ、早い段階で不適切な選択肢を排除します。彼女は顧客の「意図」を「構造」に翻訳しているのです。 我々はこれまで、より賢い「翻訳機」が必要な場面で、より高性能な「計算機」を作ろうとしてきました。 CPQの本質は自動化ではなく、正しさの担保にあります。 正しさとは、販売する製品が、いつでも問題なく製造・価格設定・納品できることを意味します。混乱を自動化することは、信頼を失う最速の方法です。逆に、複雑なものを理解しやすくすることこそ、信頼を得るための最短距離です。 現代の営業コンフィギュレーターが本当にすべきこと 営業コンフィギュレーターは、誘導型の販売支援システムです。それは顧客の課題に関する「対話」を、価格設定と納品が可能な「製造できる仕様」へと変換する役...

先日、あるお客様から、利用中のチャットボットがモデルの更新後、急に慎重になり、推奨の都度、確認を求めるようになったという相談を受けました。製品もルールも同じなのに、挙動が変わってしまったのです。まさにこれが問題の本質です。つまり、営業ロジックは、その時々のAIモデルの都合で変化してはならない、ということです。 複雑な製品を販売する場合、システムの「正しさ」は必須条件です。営業部門は迅速な回答を求めますが、後工程の部門は間違いのない保証を求めます。どちらか一方を犠牲にすることはできません。「純粋なルールベース」か「純粋なLLM」かという二者択一は、そもそもが間違った問いなのです。 なぜ今が転換点なのか LLMは、対話や説明、パターン発見能力に長けています。買い手の言葉を理解し、様々なシナリオを提示できます。しかし、その動作は確率的です。同じ入力でも、明日には違う結果を返す可能性があり、情報が不十分な場合はもっともらしい推測で補おうとします。 一方、制約ベースのCPQはその逆です。決定的で、テスト可能であり、どのバージョンでも安定して動作します。ある意味で退屈なほどに安定しているのです。しかし、対話は硬直的で、推奨や説明のロジックまでルールで表現しようとすると、維持コストが膨れ上がります。 どちらか一方を選ぶのではありません。それぞれが得意な仕事を担当させるのです。 ガートナー社の調査によれば、CPQ導入の失敗の多くは、ツールそのものではなく、製品データやガバナンスに起因するとされています。これは示唆に富む指摘です。つまり、ボトルネックは機能ではなく、ナレッジをどう表現し、変更を管理し、そして販売や納品に関わる人間にどう判断を説明するか、という点にあるのです。 「審判役」と「アドバイザー役」 私たちのワークショップでは、このパターンを「CPQ推論」と呼んでいます。すべての見積もりプロセスにおいて、2つの役割が順次連携して機能するイメージです。 「審判役」 は、シンボリックエンジンです。禁止事項や必須事項を定義し、互換性を担保し、構成を検証し、決定論的に価格を算出し、部品表（BOM）を生成します。決して推測はしません。 「アドバイザー役」 は、LLMインターフェースです。曖昧な要求を扱うフロントエンドの役割を担います。シナリオに関する質問を投げかけ、デフォルト値を提案し...