見積AI導入に必要な商品マスタの整え方

Hiway編集部·
見積AI導入に必要な商品マスタの整え方

見積AIを試すと、最初の数件はそれらしく動くのに、その先で急に手戻りが増えることがあります。原因がAIモデルにあるように見えて、実際には商品名の表記ゆれ、販売単位の不統一、価格表の散在、例外値引きの属人運用が先に効いている。見積業務では、この順番が珍しくありません。

Key Takeaways

  • 見積AIの成否は、モデル調整より先に、商品カタログ、価格表、単位、割引、税、構成ルールをどこまで構造化できているかで決まりやすいです。Dynamics 365 Salesの見積仕様も、これらを前提にしています。
  • 商品マスタは「品番一覧」では足りません。SKU、別名、販売単位、価格表、バンドル、代替関係、有効期間、公開状態までそろって、初めて見積の根拠として使いやすくなります。
  • 自由記述の見積行はゼロにしなくて構いません。重要なのは、例外理由、承認者、根拠、後日マスタ反映要否を残せることです。
  • 営業企画・RevOpsでは、商品そのものの管理と、顧客別・チャネル別価格の管理を分けて設計した方が運用しやすくなります。
  • AIネイティブCRMや見積エージェントを業務に載せるなら、問い合わせ、見積、人間レビュー、CRM更新までを一連の文脈として扱えるかが導入判断の分かれ目です。

> 見積AIにおける商品マスタとは、単なる品名一覧ではなく、商品ID、販売単位、価格表、適用条件、構成関係、有効期間、公開状態、例外時の上書きルールまでを含む、見積判断のための構造化データです。

Microsoft LearnのDynamics 365 Salesでは、見積が product catalog、price list、line items、pricing rules、discounts、taxes を前提に動くと説明されています。見積AIで先に整えるべきなのは、「AIに何を聞くか」より「何を正解データとして参照させるか」です。 参考: Microsoft Learn - Create or edit quotes in Dynamics 365 Sales

商品マスタがあるのに見積AIが安定しないのは、売り方の定義が抜けているからです

商品マスタはある。そう答えられる会社でも、見積段階になると止まることがあります。登録されているのが商品名や品番だけで、単位、価格、構成、適用条件まで定義されていないからです。

Microsoft Learnの価格設定の説明では、価格表を作る前提として units と products の準備が必要で、価格表アイテムは unit・product・pricing details を結びつけます。SKUがあっても、販売単位が定義されていなければ、見積にそのまま使いにくいということです。 参考: Microsoft Learn - Define product pricing

一部のSalesforce製品、特にRevenue Management文脈の price book では、有効期間や active の設定が扱われています。ここから読めるのは、価格を商品そのものと一体で持つより、誰に・いつ・いくらで売るかを分けて管理する考え方です。Salesforce全体の一般論として広げるより、価格管理機能を持つ製品群で共通する設計と捉えるのが安全です。 参考: Salesforce Help - Define Prices in Price Books

営業企画の仕事として見ると、これは単なるデータ整備ではありません。商品管理部門、営業企画、チャネル責任者、CRM管理者のどこが何を管理するかを決める設計です。責任分界が曖昧だと、AI以前に見積の正解が揺れます。

商品マスタは「商品本体」と「販売条件」を分けて考えます

見積AIに渡すデータは、少なくとも次の4層に分けて考えると整理しやすくなります。これは各製品の公式仕様を踏まえた、実務向けの提案例です。

1. 商品実体層

  • 内部一意ID
  • 外部向けSKU・品番
  • 商品名
  • 旧品番
  • 別名、通称、代理店呼称
  • 商品ファミリー
  • 公開状態

HubSpotの見積作成では、製品ライブラリから製品を追加する運用が前提になります。少なくとも、見積で使う製品をライブラリ側で識別・管理できる状態は必要です。quote rules もその製品ライブラリを前提に設定されます。したがって、見積ルールを先に作るより、まず製品ライブラリに載せる識別子と公開対象をそろえる方が実務では効きます。 参考: HubSpot Knowledge Base - Create and send quotes 参考: HubSpot Knowledge Base - Configure and manage quote rules

見積AIに必要な商品マスタを4層構造で示した図。商品実体、販売条件、構成関係、時間と統制の各要素が分かれて整理されている。

2. 販売条件層

  • 販売単位
  • 最小数量
  • 端数可否
  • 通貨
  • 標準価格
  • 顧客別価格
  • チャネル別価格
  • 地域別価格
  • 税区分
  • 値引き条件

Dynamics 365では、価格表を複数持つ前提があります。実務では、価格表を無理に1つへ寄せるより、どの条件差を正式な価格表として持つかを決める方が重要です。 参考: Microsoft Learn - Define product pricing

3. 構成関係層

  • バンドル
  • 必須部材
  • 任意オプション
  • 同時購入制約
  • 代替品
  • 付属品
  • 上位品

Dynamics 365のバンドル機能では、optional component や単位整合、同一価格表などの前提があります。複合商材を扱うなら、構成制約までマスタ化しないと見積は安定しません。 参考: Microsoft Learn - Set up product bundles

関連商品の定義として、accessory、cross-sell、substitute、up-sell を持てる点も重要です。代替品や付属品の関係を営業個人の記憶に置いたままでは、AIも同じ曖昧さを引き継ぎます。 参考: Microsoft Learn - Define related products

4. 時間・統制層

  • 有効開始日
  • 有効終了日
  • active / inactive / draft などの状態
  • 改定版SKU
  • 上書き理由
  • 承認者
  • 最終更新日時
  • 更新元システム

ここは見落とされがちです。価格やSKUがいつ有効かを曖昧にすると、AIは古い情報を現在の見積に混ぜる可能性があります。AIの問題に見えて、実際にはマスタの状態管理不足というケースです。

PoC前に最低限そろえたい10項目

全部を完璧にしてから始める必要はありません。ただし、PoC前に欠けていると、AIの評価ではなく元データの欠陥を見て終わる項目があります。

以下は導入前の確認に使いやすい提案例です。

項目PoC前に最低限本番前に必須ない場合に起きやすいこと
商品識別内部ID、SKU、主要な別名、旧品番代理店呼称・表記ゆれ辞書まで整備同じ商品を別物として扱う
販売単位default unit、許容単位最小数量、端数可否、丸め規則単価計算や数量変換で誤りが出る
価格標準価格、主要価格表顧客別/地域別/チャネル別/通貨別まで整理見積ドラフトが使い物にならない
価格状態active、有効期間旧価格終了日、改定履歴旧価格・未公開価格の混在
構成関係バンドル有無、主要オプション必須/任意、代替品、同時選択制約複合商材で誤提案が起きる
例外運用write-in条件、承認要否理由コード、後日マスタ反映責任自由記述が常態化する
税・値引き税区分、基本値引き条件値引き上限、送料行、検証ルール手修正が増えて統制が崩れる
SoR商品と価格の正本システム同期頻度、失敗時アラート、更新元記録更新競合と二重管理が起きる
根拠資料価格表、FAQ、主要提案資料過去見積、承認ルール、参照リンクAIが理由を返しにくい
人間レビュー承認ポイント差し戻し条件、監査ログ、CRM還流項目自動化してもレビュー負荷が下がらない

この10項目の中でも、最初に外しにくいのは「商品識別」「販売単位」「価格」「価格状態」です。ここが曖昧だと、PoCの失敗原因をAIとデータで切り分けられません。

PoCの進め方自体は、見積業務のPoCの進め方｜小さく始めて見極める もあわせて確認しておくと、対象SKUの切り方や評価観点をそろえやすくなります。

見落としやすい落とし穴

商品は登録済みでも、価格が0になることがあります

Dynamics 365 Project Operationsの説明では、default price list が未設定だと、商品ベースの見積行で価格が 0 になる場合があります。特定製品の文脈ではありますが、「商品登録済み」と「見積可能」は別だとわかります。 参考: Microsoft Learn - Product-based quote lines overview

ゼロ円は単なる入力漏れでは済みません。営業現場では、その場しのぎの手入力や過去見積の流用を増やします。RevOpsとしては、レビューで拾うより、価格未設定をマスタ状態として検知した方が運用しやすくなります。

見積AI導入前のチェックリスト図。PoC前に最低限必要な項目と本番前に必須の項目が並列で比較できる。

円建てと外貨建てをまたぐと、丸め規則が問題になります

Oracle Docsでは、価格の小数桁は通貨に依存し、表示時の丸めも起こると説明されています。円建て中心の会社でも、外貨見積や海外仕入れがあるなら無視しにくい論点です。 参考: Oracle Docs - Manually add prices to products and SKUs

CRM管理者が小数桁ルールを持たずに運用すると、AIが正しい価格を参照しても、提示金額の表示で違和感が出ます。見積は計算結果であると同時に、顧客提示物でもあります。

旧SKUを残すだけでは足りず、使ってよい状態を分ける必要があります

Salesforce HelpではRevenue Management文脈の price book に有効期間や active の設定があり、Microsoft Learnでは product や bundle の publish 状態が確認できます。少なくとも、価格や商品を使える状態かどうかを管理する仕組みは主要製品にも存在します。実務では、旧SKUを「残す」だけでなく、「候補として出してよいか」を分けて扱う必要があります。 参考: Salesforce Help - Define Prices in Price Books 参考: Microsoft Learn - Publish a product or bundle

代理店営業では特に重要です。社内では切り替え済みでも、代理店資料や通称が旧SKUのまま残ることがあるからです。

複合商材ほど、営業個人の暗黙知に依存しやすくなります

オプションの同時選択制約や、代替品の優先順位が人によって違う。この状態では、AIが不安定に見えるのも無理はありません。

複雑な商材ほど、AIに期待する前に、バンドルと関連商品のルールをマスタへ移す方が効果が出やすくなります。見積AIは、暗黙知を自動的に正解化する仕組みではありません。

自由記述の見積行は、禁止よりも「例外として管理」します

現場では custom line item や write-in product を完全にはなくせません。HubSpotもMicrosoftも例外経路を持っています。例外の存在そのものより、例外が通常運用になっている方が問題です。 参考: HubSpot Knowledge Base - Create and send quotes 参考: Microsoft Learn - Add products to quotes, orders, or invoices

実務では、少なくとも次の4点を残せるようにしておくと、あとから改善しやすくなります。

  • 例外理由コード
  • 承認要否と承認者
  • 原価または売価の根拠
  • 後日マスタ反映の要否

この設計なら、自由記述行を「禁止できない例外」として囲い込みやすくなります。CRM管理者にとっても、入力項目を増やす話ではなく、どの例外を標準化すべきかを見つける話に変わります。

営業企画・RevOps・代理店営業で確認したい役割分担

商品マスタ整備が長引く会社では、データ形式より先に、責任の所在が曖昧なことが少なくありません。

営業企画が持つべき論点

  • どの価格を標準価格として扱うか
  • 顧客別・チャネル別価格を誰が承認するか
  • 値引き上限をルール化できるか
  • 例外見積の再発防止をどこまでKPI化するか

CRM管理者が持つべき論点

  • 商品・価格のSoRはどこか
  • CRMに同期する最小項目は何か
  • active / inactive / draft をどう表現するか
  • 例外行の入力必須項目を何にするか

代理店営業責任者が持つべき論点

  • 代理店呼称や通称を別名辞書として管理しているか
  • チャネル別価格を正式データとして持てているか
  • パートナー向け提案資料とSKUが結びついているか
  • 誤提案時に、どこまで根拠追跡できるか

ここが整理できると、商品マスタ整備は単なる台帳修正ではなく、問い合わせから見積、承認、CRM更新までをつなぐ運用設計になります。関連する業務設計は、見積作成AIとは？ や Partner Revenue Operationsとは？代理店営業の問い合わせ・見積・CRMをつなぐ新しい運用の考え方 も参考になります。

実装時の設計要件

見積AIを業務に組み込むなら、プロンプト調整だけでは足りません。Anthropicの解説でも、AIエージェントは限られた文脈を設計し、実行中に ground truth を取りに行き、人間のチェックポイントを挟むことが重要だとされています。 参考: Anthropic - Effective context engineering for AI agents

見積業務に引き直すと、設計要件は次の通りです。

参照データの範囲を狭く定義する

  • 全商品を一気に対象にしない
  • まずは標準価格と構成ルールが安定している商材群から始める
  • 代理店向け、直販向け、更新向けなど用途を分ける

正本データを明確にする

  • 商品本体のSoR
  • 価格のSoR
  • FAQや提案資料の保管先
  • 過去見積の参照範囲

根拠付きで返せるようにする

  • 見積ドラフトに参照価格表や適用条件を紐づける
  • 代替品提案時に、その理由を返せるようにする
  • 旧SKUを除外した根拠を追えるようにする

人間レビューを前提にする

  • 特値
  • 例外単位
  • 複合構成
  • 契約更新時の個別条件

このあたりは初期から自動確定させるより、レビュー対象として分離した方が安全です。見積AIで目指すべきなのは、完全無人化ではなく、レビュー対象を絞って業務速度を上げることです。関連論点は、AI見積に人間レビューが必要な理由 や エンタープライズAIエージェントとは？権限・承認・監査ログで業務に組み込む統制設計 でも詳しく整理しています。

AIネイティブCRMとして見ると、商品マスタは「AIが扱える営業文脈」の土台です

問い合わせ起点で見積を作る場合、AIは商品名だけを引ければ十分というわけではありません。顧客区分、代理店区分、過去見積、FAQ、承認ルール、CRM上の案件文脈とつながって初めて、実務で使える候補になりやすくなります。

Hiwayの公開情報では、公式トップで営業AIエージェントの全体像、CRMページでCRM連携、公式ブログで見積作成AIの考え方が説明されています。見積の文脈では、商品マスタ、価格表、過去見積、CRM情報を照合しながら、AIが下書き作成や次の確認行動を支援する形が導入イメージになります。 参考: Hiway公式トップ 参考: Hiway CRM 参考: Hiway公式ブログ - 見積作成AIとは？

向いているのは、複数の価格条件や承認フローがあり、問い合わせから見積、CRM更新までが分断されているケースです。逆に、商品数が少なく、価格も固定で、例外がほぼない業務なら、まずは既存CRMやCPQの設定見直しだけで足りる場合もあります。

AIネイティブCRMとは？従来CRMとの違いと、現場に根づく選び方 もあわせて読むと、見積AIを単体機能ではなく、営業文脈を扱う基盤として判断しやすくなります。

導入相談の前に確認したい質問

社内で次の質問に答えられると、PoCの見極めが早くなります。

  • 商品と価格のSoRはどこですか
  • SKUの別名辞書や旧品番対応はありますか
  • 顧客別・代理店別の価格は何種類ありますか
  • write-in product や自由記述行は、どんな条件で発生しますか
  • バンドルやオプション構成は、どこまでルール化されていますか
  • 見積レビューで人が見るポイントは、価格、構成、契約条件のどれですか
  • 見積後にCRMへ戻したい項目は何ですか

ここまで答えが出るなら、単なるAIデモではなく、自社に合う導入可否の相談に進みやすくなります。

FAQ

商品マスタはSKU一覧だけあれば足りますか？

足りません。Microsoft LearnのDynamics 365 Salesでは、見積に販売単位、価格表、割引、税、ラインアイテムが関わります。SKUだけでは見積判断の根拠が不足します。 参考: Microsoft Learn - Create or edit quotes in Dynamics 365 Sales

自由記述の見積行はなくすべきですか？

完全になくすより、例外として統制する方が現実的です。HubSpotやMicrosoftも custom line item / write-in product を持っています。理由コード、承認、根拠、マスタ反映要否を残せる設計が重要です。 参考: HubSpot Knowledge Base - Create and send quotes

価格表は1つに統一した方がよいですか？

一概には言えません。Dynamics 365では価格表を複数持てますし、一部のSalesforce製品でも price book による価格管理があります。地域、顧客区分、チャネル、通貨が異なるなら、分けて管理する前提で責任分界を決める方が実務的です。 参考: Microsoft Learn - Define product pricing 参考: Salesforce Help - Define Prices in Price Books

見積AIのPoCは、どこまで整っていれば始められますか？

最低限、対象商材について商品識別、販売単位、価格、価格状態、主要な例外条件が整理されていることが望ましいです。判断しやすい目安としては、対象SKUに主要な別名がひもづいていること、使う価格表に有効期間があること、自由記述行の発生条件が説明できることが挙げられます。全社全商品を一度に整える必要はありませんが、PoC対象の範囲だけは ground truth を明確にした方が評価しやすくなります。 参考: Anthropic - Effective context engineering for AI agents

代理店営業でも同じ考え方で進められますか？

基本は同じです。ただし、代理店呼称、チャネル別価格、パートナー向け資料、誤提案時の根拠追跡が加わるため、別名管理と価格条件の切り分けはより重要になります。問い合わせから見積、CRM更新までをつなぐ運用の考え方は、Partner Revenue Operationsとは？代理店営業の問い合わせ・見積・CRMをつなぐ新しい運用の考え方 や 代理店の問い合わせ対応をAIで効率化する方法 も参考になります。

デモ・導入相談

見積AIを導入できるかどうかは、画面デモだけでは判断しにくいテーマです。実際には、商品マスタ、価格表、例外見積、承認、人間レビュー、CRM還流をどこまでつなげるかで向き不向きが分かれます。

導入相談では、次のような論点を持ち込むと、自社に合うかどうかを判断しやすくなります。

  • 商品と価格のSoRがどこにあるか
  • write-in比率や自由記述行をどこまで例外運用として囲い込めるか
  • PoC対象SKUをどの範囲で切るべきか
  • 承認分岐やレビュー観点をどこまでルール化できるか
  • CRMへ戻すべき見積データをどこまで定義するか
  • デモ・導入相談はこちら
  • 資料ダウンロードはこちら

参考文献・一次情報

顧客接点の構造化からCRM更新までAIが支援

自社の営業・パートナー業務への活用を相談する

現在のCRM、代理店との情報共有、見積対応の流れをもとに、デモで支援できる範囲や導入条件を確認できます。

デモ・導入相談資料ダウンロード