商談の値引き・契約例外を「判断」として扱う──Asterion Deal Desk デモ

🎥 YouTubeでも公開しています

Asterion Deal Desk｜AIが支える商談条件の判断・承認・実行の一連プロセス

Books:『Decision Trace Model 実践導入ガイド』: ― 製造・医療・リテール・マルチエージェントで学ぶAI意思決定システム ―

商談の値引き、支払サイト、無償導入支援、SLAの例外。これらは営業だけで完結する条件ではない。売上機会を逃したくない営業、粗利と回収を守りたい財務、契約リスクを抑えたい法務、そして将来の顧客戦略を担う事業責任者が、それぞれ正当な観点を持つ。

問題は、どの部門が正しいかではない。根拠、代替案、未確認事項、承認経路がメールやチャットに散らばることで、「なぜこの条件で受注したのか」を後から十分に説明できなくなることである。

今回制作した Asterion Deal Desk は、この課題を題材にした商談判断支援のデモである。AIが値引きを自動で許可する仕組みではない。AIは複数の条件案とその根拠を提示し、人が権限に基づいて判断する。その一連の過程を Decision Trace として残し、実行後の結果まで次の判断へつなげる。

商談を「一つの承認」に押し込まない

商談の承認では、価格だけを見ても十分ではない。たとえば、値引き率が大きくても、将来の展開可能性、支払条件、導入支援の負担、契約例外の内容によって意味は変わる。

デモでは、Northstar Retail Group に対する次世代店舗分析プラットフォームの提案を扱う。初回申請には、次のような論点が含まれている。

• 値引き率は 28% で、通常の価格ポリシーを超える
• 想定粗利率は 49.7% で、基準の 55% を下回る
• 支払サイトは検収後 90 日で、回収リスクが高い
• 導入支援は無償で、採算を押し下げる
• SLA の一部を標準条件の例外としている
• 一方で、競合との最終選定段階にあり、将来の複数拠点展開という戦略的な可能性がある

こうした案件に必要なのは、「承認」か「否認」かを急ぐことではない。受注機会を保ちながら、どの条件を変え、何を追加で確認し、誰の承認を得れば進められるかを具体化することである。

AIは一案を断定せず、比較できる条件案を提示する

Asterion Deal Desk は、初回申請をそのまま通すのではなく、複数の提案を比較する。

この例では、AIは案Bを提案する。初年度の値引きは 22% に抑え、2年目以降は標準価格へ段階的に戻す。支払サイトは 60 日へ短縮し、無償の導入支援は有償オプション化する。SLAの例外は価格判断と混ぜず、限定条項として法務レビューへ切り出す。さらに、将来の3拠点展開については確定事実として扱わず、顧客の意思確認を承認条件に加える。

ここで大切なのは、AIの推奨を「正解」として出さないことだ。案Bは、3年間の期待粗利、受注可能性、回収リスク、契約リスクを見比べられる一つの提案である。採用するかどうか、条件をどこまで修正するかは、人が決める。

根拠・仮説・未確認を混ぜない

AIによる提案がもっともらしく見えても、その内訳が分からなければ判断材料にはなりにくい。そこでデモでは、各解釈を次のように区別している。

• 確定したルール：価格ポリシー、与信ポリシー、SLA標準条件など
• 証拠に基づく推計：類似案件の粗利実績、支払サイトによる回収損失の見積りなど
• 仮説・未確定事項：将来展開の可能性、競合価格の情報、SLA例外の具体的な範囲など

たとえば「90日サイトは回収リスクを高める」という判断には、与信ポリシーと条件差による損失見積りが結び付く。一方、「将来3拠点への展開が期待できる」は戦略的な価値を持つが、確認済みの事実ではない。後者を前者と同じ重さで扱えば、もっともらしい期待が判断を歪める。

画面上では、参照した証拠、AIの解釈、そして人が確認すべき未確認事項を分けて表示する。これは、AIが知らないことを「問題なし」とみなさないための設計でもある。

権限を画面の外に置かない

商談の条件変更には、役割ごとに扱える範囲がある。営業担当者は案件の起案、根拠の追記、条件修正と再申請を行える。しかし、価格・支払・契約例外までを一人で承認することはできない。

デモでは、条件付き承認を選ぶと、必要な承認者が案件内容に応じて明示される。

• 事業責任者：値引きおよび戦略例外
• 財務レビュー担当：支払サイトと与信条件
• 法務レビュー担当：SLAなどの契約例外

役割を切り替えた画面では、利用者ごとに可能な操作が変わる。権限外の承認は画面上でブロックされ、必要な順序で承認依頼が送られる。重要なのは、権限を運用ルールとして文章に書くだけでなく、実際に判断と実行の境界で強制することである。

Decision Traceは「ログ」より広い

このデモの中心にあるのが、Decision Traceである。単なる操作履歴ではなく、判断に至る因果関係をたどれる形で残す。

案件シグナル
  → 根拠の収集
  → 解釈（リスク・機会・未確認事項）
  → 複数案の提案
  → 人による条件修正と判断
  → 権限に基づく承認
  → 実行
  → 結果と学習

画面では、顧客プロファイル、類似案件、競合情報、価格ポリシー、与信ポリシー、SLA標準条件といった証拠が、提案・人の判断・各承認に結び付けられる。後から見た人は、「誰が承認したか」だけでなく、「どの根拠を参照し、何を未確認として残し、どの条件に変えたのか」を確認できる。

この構造があれば、監査や引き継ぎのためだけでなく、営業・財務・法務の間で判断の前提を共有しやすくなる。次に似た案件が来たときにも、結果だけではなく、その結果に至った条件を参照できる。

受注後も、AIの正しさを演出しない

受注時点の推計だけでAIを評価すると、後から見て都合のよい説明になりがちである。Asterion Deal Desk では、実行後に入金、初年度の粗利、利用部門数、追加展開の可能性などを記録し、判断時点の期待値と照合する。

ただし、実行されなかった案A・案Cについては実績がない。その比較値は、あくまで当時の推計モデルによる参考値である。この区別も重要だ。実績と反実仮想のシミュレーションを混同しないことで、「AIが常に正しかった」という見せ方を避けられる。

結果はDecision Traceへ追加され、類似案件の判断材料へ戻される。ここでの学習は、ブラックボックス的にモデルを自動更新することだけを意味しない。どの条件の組み合わせが採算、回収、契約、顧客戦略にどう影響したかを、組織が検討できる状態にすることでもある。

商談AIに必要なのは、値引き率の最適化だけではない

商談支援AIを「最適な値引き率を出す機能」として設計すると、現実の判断はこぼれ落ちる。実務で扱うべきなのは、価格、粗利、支払、契約、戦略価値、証拠の強さ、未確認事項、承認権限、実行後の結果の関係である。

Asterion Deal Desk は、AIを判断者に置き換えるためのデモではない。人がより良い判断を行い、その判断を組織の知識として残すためのワークスペースである。

AIは提案する。人が責任を持って判断する。そして、根拠・判断・権限・実行・結果を一つの流れとして残す。商談の自動化を考えるとき、この順序を崩さないことが、速さと統制を両立する出発点になる。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance