営業の暗黙知を、組織知へ。
AI時代にServiceNowでCPQをやる意義。

CPQの評価を、
AIが業務を進める基盤として読む。

ServiceNowは2026年10月20日、The Forrester Wave™: Configure, Price, Quote Solutions, Q4 2026でLeaderとCustomer Favoriteに選ばれたと発表しました。ServiceNowとして初参加の評価であり、2025年に買収したLogik.aiの技術・事業が現在のCPQにつながっています。^[1]

CPQはConfigure・Price・Quoteの略です。顧客の条件に合う商品やサービスの組み合わせを決め、価格を計算し、見積もりへつなぐ領域です。複雑な製品では、必須部品や互換性、数量の制限、契約ごとの条件など、多くの判断が見積書の前段にあります。

CPQの歴史：複雑な製品を売るための仕組みから、AIが動く基盤へ

原記事の著者Christopher Shuttsは、約25年前にBigMachinesを立ち上げ、産業機器の販売を容易にするための仕組みを開発したと振り返っています。現在のOracle CPQにつながる事業で、当時はCPQという呼び方自体がまだ一般的ではなかったといいます。出発点は、複雑な仕様や部品の組み合わせを扱い、営業が販売可能な構成と見積もりを作れるようにすることでした。^[1]

その後CPQは幅広い製品・サービスに使われるようになります。一方、長期化する導入、ルールの保守負担、営業現場への定着が課題だったというのが、Shuttsによる振り返りです。そこで立ち上げたLogik.aiが2025年にServiceNowへ加わり、現在は構成エンジンとAI、業務ワークフローを組み合わせる展開につながっています。^[1]

この歴史で押さえておきたいのは、Logik.aiは、Salesforce CPQのアドオンとして高度な見積構成エンジンを担っていたという点です。Logik.io名義の2021年の発表では、Salesforce CPQ上にコンフィギュレーターを重ね、AppExchangeで提供する構成を説明しています。Salesforceの見積もり業務を、複雑な商品構成の計算で補完する立場でも使われてきた技術です。^[7]

ServiceNowが2025年に取り込んだのは、このように既存の販売基盤と組み合わせて使われてきた構成技術です。私は、営業側の構成エンジンを、ServiceNowの生産・提供・サポートへとつながる業務基盤の中に位置付け直す動きとして注目しています。Logik.aiがSalesforce専用の製品だった、という意味ではありません。

私は、この流れを「営業が知識を入力して使う仕組み」から、「AIが対話を読み、蓄積された知識とルールを使って業務を進める仕組み」への発展と捉えています。製品構成や価格計算の重要性は続きます。その入口にある営業の判断と、出口にある提供・運用までをどうつなぐかが、新たな論点になります。

今回の記事で注目したいのは、複雑な構成を扱うエンジン、販売チャネルを横断する共通ロジック、そして見積もり業務を実行するAIを組み合わせている点です。会話の記録などから見積もり案を作り、受注へ引き継ぐ方向が示されています。^[1]

製品ページでも、構成・価格ルール、見積もりと承認、契約変更や更新、受注後への構造化データの引き渡しが説明されています。^[3] 私は、この一連の接続こそが、AIエージェントを活用する今、ServiceNowでCPQに取り組む意義になると考えています。

日本の営業の「経験と勘」を、
組織知として使えるようにする。

営業担当者が顧客から受け取る情報は、完成した商品コードの一覧とは限りません。「拠点を増やしたい」「止まらない構成にしたい」「今の契約に保守を追加したい」といった、目的や制約を含む対話から始まります。これを商品知識と照らし合わせ、販売できる構成と条件に変換する作業には、経験と時間が必要です。

AIエージェントが活用されると、この入口が変わります。議事録やRFPから用途・容量・設置環境・予算などを取り出し、構成の入力候補へ変換する。その候補を構成エンジンで検証し、価格計算や承認へ進める流れが考えられます。

ベテランが「何を確かめ、なぜそう提案したか」を残す

日本の営業現場で「経験と勘」と呼ばれてきたものには、顧客の事情を読み、必要な確認をし、適切な提案へ導く知識が含まれています。私は、それを組織で共有し、再利用すべき知識と捉えています。現状では個人に閉じていても、判断の根拠を取り出すことで、組織知として使える形にしていけます。

ベテランの営業は、顧客の言葉をそのまま商品に置き換えているわけではありません。「この用途なら先に設置環境を聞く」「この契約条件なら保守も見直す」「この組み合わせは後から問題になる」といった判断を、経験から行っています。こうした暗黙知は、最終的な見積書だけを保存しても十分には残りません。

AIエージェントが対話と業務の流れに入れば、追加で確認した質問、選択肢を除外した理由、採用した構成、例外の承認理由、その後の納入やサポートの結果を関連付けて記録できます。人が妥当性を確かめた知識を、次の案件での質問や提案、構成ルールの改善へ戻す。営業のAIエージェントは、個人の営業の経験と勘を組織知へ変える可能性を秘めていると考えます。

これは会話を保存するだけで実現するものではありません。再利用してよい判断と、その案件だけの事情を分け、知識の管理者と更新手順を設ける必要があります。提案が採用されたか、受注後に問題がなかったかまで振り返ることで、経験を組織の判断材料にしていけます。

組織知を、検証できる構成と業務へ渡す

図：業務設計例。ピンクの枠がAIエージェントの介在を想定する工程。構成検証、承認、基幹連携と役割を分ける。全工程の自律実行や標準提供を示すものではありません。生産・請求・入金の実行には必要に応じてERP等を組み合わせます。

AIに、すべての正しさを判断させない

LLMは曖昧な言葉を扱うことに向いています。一方、「この組み合わせで提供できるか」は、製品の制約や業務ルールに照らして検証すべきです。Logik.aiを取り込んだ構成エンジンの価値は、AIが作った候補を、明示したルールに基づく検証へ渡せることにあります。

私が重要と考えるのは、AIの解釈、構成ルールの検証、業務の承認と記録をつなぐことです。この役割分担によって、顧客との会話を、実際に進められる見積もり業務へ変えていけると考えます。

営業・生産・サポートの、
データモデルを共通にする意味。

私は、ServiceNowでCPQ領域を実現する真の意味は、営業→生産・提供→カスタマーサポート＆アップセルの各場面で利用するデータモデルを共通化できることにあると考えます。
既存のCRM及びCPQの仕組みではデータモデルの分断が発生してしまうのです。営業と見積もりの範囲を超え、納入、請求・入金、その後の支援や追加発注まで、同じ顧客・製品・契約とその関係をたどれるようにすることです。そこで重要になるのが、顧客に販売する単位と、実際に提供・運用する単位を分けて管理し、関係を追えるようにする設計です。

見積書の「一式」と、現場が納めるものは粒度が違う

例えば、顧客への見積もりでは「拠点ネットワーク導入・保守パッケージ 一式」と表現していても、提供側では機器、ライセンス、設置作業、回線設定、継続保守などに分かれます。納入先、担当部門、開始日、完了条件も異なります。見積明細をそのまま現場の作業一覧として使うと、この違いが部門間の手作業に埋もれてしまいます。

ServiceNowでは、見積もりの明細・ヘッダーデータから受注を作成する連携が説明されています。さらに受注分解では、カタログの仕様・関係・ルールに基づき、商用の受注を製品・サービス・リソースのオーダーへ分解し、履行へつなぎます。^[4][5]

つまり、見積明細と納入する物販・サービスの明細を、同じものとして押し込む必要はありません。別の粒度で持ち、対応関係を残すことで、「何を約束したか」と「何を届け、提供し続けているか」をつなぐ土台になります。受注分解の具体的な対象や機能範囲は、採用する製品・業界ソリューション・リリースに応じた確認が必要です。

表：設計例。請求・入金を含む全工程がCPQ単体で完結するという意味ではありません。会計・ERP・決済等との連携、データの対応付けと権限設計を含みます。

共通化とは、すべてを同じ明細にすることではない

営業には販売の単位、生産には部品や工程の単位、カスタマーサポートには導入済み製品やサービスの単位があります。必要な粒度を保ちながら、どの販売明細がどの提供明細・契約・問い合わせへつながるかを共通のモデルで表現することが重要です。生産計画や製造実行をすべてServiceNowへ移すという意味ではなく、ERP・MES等と識別子や状態の意味を揃え、業務を横断して追えるようにする設計です。

最終目的地は、カスタマージャーニーの継続的な高度化

例えば、サポートへの問い合わせから容量不足が判明した場合、対象機器と契約をたどり、増設の構成案と追加見積もりへつなげる。保守更新時には、過去の提供内容と変更履歴を前提に提案する。こうした循環ができれば、AIは営業の会話だけでなく、実際の納入・利用・支援の事実を踏まえて次の行動を組み立てられます。

最終目的地は、CPQの導入や見積もりの高速化で終わりません。カスタマージャーニーのEnd-to-Endを高度化し、継続的に改善し続けることです。どの確認が提案の質を上げ、どの構成が納入や利用で問題を生み、どの対応が更新・追加発注につながったかを振り返ります。

営業で得た知識を生産・提供と支援へ渡し、その結果を次の営業へ戻す。この循環を、業務を横断するデータとワークフローで支えることが、私がServiceNowに見いだす価値です。既にServiceNowでサービス運用を管理している企業では、その情報を営業の判断へどう生かすかが具体的な検討点になります。

Salesforceとの比較は、End-to-Endの実現方法で見る

なお、「Salesforceではできない」という切り分けは正確ではありません。SalesforceもRevenue Managementの公式資料で、見積もりから受注、請求、入金、契約や購入済み商品・サービスの管理を説明しています。^[6] End-to-Endという言葉だけで、ServiceNow固有の優位性を断定することはできません。

私が比較で重視したいのは、販売の明細と提供・運用の明細をどう関連付け、カスタマーサポートや追加発注まで、どれだけ一貫した業務として設計できるかです。既存のCRM、ERP、サービス管理の配置を踏まえ、必要な製品・連携と運用負担を比べる。その上でServiceNowを中核に据える意義を判断すべきだと考えます。

自社で運用するために、
まず整えること。

1. 過去案件から、End-to-Endのユースケースを抽出・分析する

リード、商談、見積もり、請求、入金、サポート、追加発注まで、同じ顧客・案件の流れをたどれる過去案件を集めます。途中にある受注、生産・納入・検収も含め、どこで情報が切れ、誰が何を確認し直しているかを整理します。

受注して終わった案件だけでなく、見積もりの差し戻し、納入時の変更、請求の訂正、サポートから追加発注へ進んだ案件なども比較します。工程ごとの効率だけでなく、顧客の待ち時間や繰り返しの説明、販売時の約束と提供内容のずれを見つけ、改善したいユースケースを選びます。

2. 商談議事録と作成見積もりのデータセットを用意する

営業AIエージェントの効果を最大限に引き出すために、商談議事録と、そこから実際に作成した見積もりを対応付けたデータセットを用意します。要望がどの構成・数量・条件に変換されたか、追加の質問で何を確認したか、担当者がどこを修正したかを残します。

日本の営業の「経験と勘」を組織知として使うための出発点です。最終見積もりだけでは分からない判断根拠を、営業担当者のレビューで補います。参照する価格・商品ルールの版、案件固有の例外も分けて記録します。

まずは検索・参照と効果検証に使える形を目指します。モデルの追加学習を必須とするものではありません。議事録や価格情報の利用範囲・閲覧権限を整え、評価用の案件を分けて、AIが要件を正しく読み取れるか、確認事項を挙げられるか、妥当な見積もり案へつながるかを確かめます。

3. 先行導入範囲を決める

分析したユースケースから、対象の商品群、営業チーム、顧客層、AIに任せる工程を絞ります。例えば、定型的な追加発注について、議事録から要件を抽出し、構成を検証して見積もりの下書きを作るところまでを先行する方法があります。確定や顧客への送付は、必要な人の確認・承認を組み込みます。

小さく始めても、将来の生産・提供、請求・入金、サポートへつながる顧客・製品・契約・明細の識別子と関係は意識して設計します。初回見積もりまでの時間、修正率、確認待ち、後工程の手戻りを測り、結果をデータセットと業務ルールへ戻して、次の範囲へ広げます。

日本の現場が積み重ねた創意工夫を、AIで次の力へ

私は、日本は暗黙知が蓄積されやすい環境にあると思います。それは、各部門や現場が責任感を持って業務に取り組み、それぞれの場所で「創意工夫」を積み重ねてきた結果でもあります。その蓄積は、素晴らしいものだと考えています。

これまでは、暗黙知が溜まりやすい日本の文化や商習慣は、属人化や非効率といった否定的な文脈で語られることが多くありました。しかし、AIの実用化によって、その知識を取り出し、共有し、業務に生かすための環境は大きく変わりました。

現場の創意工夫を言葉やデータとして残し、AIを介して他の担当者や次の案件でも使えるようにする。これまで個人や部門の中にあった経験と勘を、組織全体の力へ広げていく機会です。

私は、日本の営業プロセスは、AIの活用によって大いに飛躍すると考えています。現場が積み重ねてきた知識の価値を認め、その力を次の顧客体験へつなげていきましょう！