AIのスピード、CPQの安全性：2層コンフィグレーションモデル

「チャットボットに一次対応を任せられないか」と営業部門から提案がありました。それに対し、製造部門は「製造できないものを売ってしまうリスクがないと保証できない限り、無理だ」と返答しました。

どちらの意見も正しいと言えます。AIの柔軟性を活用して、顧客からの雑多な要求を迅速に吸い上げたい。一方で、すべての見積もりが製造可能で、価格設定可能で、かつ正当性を説明できるものであるためには、ルールの確実性も必要です。これはどちらか一方を選ぶ問題ではありません。両者を二階層に重ねることで、これが可能になります。

多くのチームが見過ごしているシンプルな考え方があります。それは、決定論的なルールの層の上に、対話型の層を置くことです。AIに対話をさせ、ルールに判断を任せるのです。

単層よりも二層構造が優れている理由

CPQをめぐる問題の多くは、UIや機能不足が原因ではありません。根本にあるのは「信頼」の問題です。営業担当者は、提示する製品構成が有効であることを確信したい。経理部門は、その価格が妥当であることを確認したい。そして製品開発部門は、納期が迫ったからといって、ルールがこっそり迂回されることがないようにしたいのです。

生成AIは、メールやPDF、書きかけのメモから、顧客が何を望んでいるかという一貫したストーリーを組み立てるのが得意です。しかし、同じ問いかけに対して、日によって異なる答えを返すこともあります。ガートナー社もこの点を明確に指摘している通り、生成AIは確率論的に動作するため、本番の業務フローで使うにはガードレールが必須です。この非決定論的な性質は、要件の洗い出しには有用ですが、見積もり作成においてはリスクとなります。

一方、ルールベースのコンフィギュレーターはその逆です。一貫性があり、監査可能ですが、時に融通が利かないほど厳格です。推測はせず、ただルールに反するものをブロックします。

AIは顧客の「意図」を汲み取り、ルールは「事実」を保証します。

この二つを組み合わせることで、正確性を犠牲にすることなく、スピードを手に入れることができるのです。

二層式CPQの仕組み

私は、複雑な製品を販売するチームでこのアプローチを実践してきました。そのプロセスは意図的に退屈なものにしています。金額の大きな取引では、退屈であること、つまり予測可能であることが重要だからです。

第1層：対話による要求の取得 LLM（大規模言語モデル）が、対話や資料の読み込みを通じて情報を整理します。ニーズ、制約、好み、トレードオフといった、曖昧な初期段階の情報を扱います。平易な言葉で確認の質問をしたり、矛盾点を指摘したりすることが可能です。そして最終的に、構造化された要求セットを作成します。

第2層：決定論的な検証 ルールエンジンが、厳格な制約と価格設定ルールを適用します。第1層で作成された要求セットを、許容される組み合わせ、依存関係、価格ロジックに照らしてテストします。そして、有効な製品構成を返すか、あるいは解決すべき矛盾点を正確に指摘します。

これはAI対ルールの話ではなく、ルールの前にAIを置く、という順序の話なのです。

この仕組みを実務で機能させるためには、いくつかの設計上の重要な判断があります。

• 関心事の分離： 要求の取得は自由形式で行い、構成の検証は厳格に行います。この二つを明確に分離し、実装都合の仕様が顧客の要求定義に紛れ込まないようにします。
• 説明可能性の担保： 承認された、あるいは却下された全ての選択について、その「理由」を記録します。LLMは、ルールエンジンからのメッセージを人間が理解できる言葉に翻訳できます。説明がなければ、現場での定着は進みません。
• 組み合わせ可能なインターフェース： 二つの層の間にシンプルなAPIを設けることで、対話用UIやルールエンジン、価格設定方式などを、スタック全体を再構築することなく容易に交換できるようになります。
• デモではなく、テストスイート： ルールをコードのように扱います。バージョン管理し、テストを行い、リリースごとにテスト結果を公開します。デモが成功したからといって、システムが安全であるとは限りません。

システムが自身の判断を説明できなければ、営業担当者はシステムを無視して独自の解釈で説明を始めてしまいます。

ここで重要なのは、LLMに互換性や価格を「推測」させてはいない、という点です。LLMにはあくまで顧客の意図を表現させ、ユーザーを導く役割に徹してもらいます。そして、月曜日でも火曜日でも同じように動作するルールエンジンに、全ての厳密なチェックを委任しているのです。

安全で高速なハイブリッド方式のための実践ルール

これらのルールは、システム導入後も実際に機能し続けている、現実のプロジェクトから得られたものです。

ルール1：要求の取得と検証を分離する チャットボットに直接ルールエンジンを操作させないでください。対話層は要求オブジェクトを作成し、ルールエンジンがそれを検証するという流れを守ります。例えば、ユーザーが「長距離輸送、高積載、かつ騒音規制のある都市部での配送」といった要求を伝えたとします。LLMはそれを特定の仕様やパラメータにマッピングし、ルールエンジンがそれらの両立が可能かどうかを判断します。

ルール2：AIには文脈を与え、機密情報は与えない LLMには、モジュールやバリエーション、主要な制約といった読み取り可能なレベルの情報と、平易な言葉で書かれたトレードオフの説明を与えます。詳細な製造ルールやコストデータは、ルールエンジンの背後に隠しておきましょう。目指すべきは役立つガイダンスであり、価格表の漏洩ではありません。

ルール3：人間が読める「なぜ」を維持する 制約違反が発生するたびに、チャットで表示できる短い説明を保存します。例えば、「スリーパーキャブは重量とトルクの要件から、高馬力エンジンが必要です」といった具合です。これにより、単なるエラーが、顧客を導くためのガイダンスに変わります。

ルール4：価格設定は学習させ、検証はルールで行う 価格ロジックはルールエンジンで強制できるものを使います。その上で、対話層に取引の背景情報を捉えさせ、将来の価格設定の改善に役立てます。価格設定は、完璧なデータを待つのではなく、運用を通じて改善していくものです。

ルール5：「腹話術ボット」のパターンを認識し、回避する 最も避けるべきは、LLMがコンフィギュレーターのふりをするアンチパターンです。自信満々に回答しますが、時折ハルシネーション（もっともらしい嘘）を起こし、構成の正しさを保証できません。出力された内容が決定論的なチェックを通過しない限り、それは見積もりではなく、単なる下書きです。

スピードは、チェックを省略することではなく、適切なガイダンスによって生まれるべきです。

ルールを追加するたびに、将来の変更コストが増加します。ルールは小さく、テスト可能な状態に保ちましょう。

この四半期で何をすべきか

これを2年がかりのプラットフォームプロジェクトにしてはいけません。90日間で実現可能な取り組みとして始めましょう。

• 製品コンテキストの棚卸し： まず一つの製品ラインに絞り、モジュール、バリエーション、主要な依存関係、そして平易な言葉で書かれたトレードオフに関する短いメモをまとめた、軽量なカタログを作成します。これは、AIへの指示書のようなものです。
• シンプルなAPIの準備： 対話層が呼び出せる単純なエンドポイントを公開します。「要求を送信すると、有効な構成と価格、あるいは競合リストが返ってくる」というものです。シンプルさを保ち、ログを確実に記録します。
• プロンプトより先にテストを追加： 重要なルールには、必ず決定論的なテストを作成します。リリースごとにテストが成功していることを示しましょう。テストできないものは、本番環境に展開してはいけません。
• 実際のメールでパイロット運用： 実際にお客様から受け取ったメールやRFPの一部を対話層に入力してみます。エンジニアが関与する前に、どれだけやり取りを削減できるかを測定します。

すぐにわかるはずです。AIが曖昧な要求の解釈にかかる負荷を軽減し、ルールエンジンがエラー率を削減します。営業担当者は、不明確な要求を仕様コードに変換したり、専門家による構成のチェックを待ったりする必要がなくなり、より迅速に動けるようになります。

積み重なる優位性

このパターンが一度定着すれば、週を追うごとにあらゆる側面が少しずつ改善されていきます。対話層は、より良い質問の仕方や、より明確なトレードオフの提示方法を学習し続けます。一方、ルール層は、巨大なロジックを一括で投入するのではなく、テスト済みの小さな制約を追加していくため、安定性を保ちます。

成功を収めるのは、「思考」と「検証」を分離できるチームです。思考は顧客と共に行われ、彼らが理解できる言葉で進められます。検証は、舞台裏で静かに、一貫して行われ、監査証跡を残します。一方、遅れをとるチームは、入力フォームの見た目を磨き続け、必須項目をどうするかで議論を続け、結果として最も優秀な営業担当者はそのシステムを迂回するでしょう。

ここにある技術に、何か革命的なものがあるわけではありません。重要なのは、AIを専門家の見習い、ルールエンジンを検査官として扱うという発想の転換です。一方が探索し、もう一方が証明する。この二つが合わさって初めて、信頼が生まれるのです。

結局のところ、真実はシンプルです。最も速い見積もりプロセスとは、関係者全員がその内容を信頼できるプロセスなのです。