DESIGN PRINCIPLE / TYPED JUDGMENT
AIに、
注文を決めさせない。
ContactX OrderでAIが担当するのは、顧客の発話が何を意味するかという「判断」です。金額・数量・配送先・注文確定は、検証可能なコードと業務ルールが担当します。
現在のデモ注文フロー
GENERATIVE CONVERSATION ≠ ORDER AUTHORITY
自然に話せることと、
安全に確定できることは別です。
曖昧な言葉から意味の候補と確からしさを返す
＋CODE業務ルールに沿って、許可された操作だけを実行する
SYSTEM BOUNDARY
一つのAIへ、
全部を任せない。
入力、意味判断、業務処理、最終確認を分離します。各層が受け取れる値と、実行できる操作を限定することで、判断の揺らぎがそのまま誤発注にならないようにします。
顧客の発話
音声認識テキストと最大5件の代替候補、直近の会話、現在の質問を渡します。
speech hypotheses意味を型へ変換
ChoiceとNoulで、用件・回答種別・次の操作・独立シグナルを並列判定します。
probability + confidenceコードで検証
数量、郵便番号、支払方法、商品、在庫、現在の会話状態を照合します。
allow-list + validation許可された結果
次の質問、聞き直し、確認待ち、有人引き継ぎ、または復唱確認へ進みます。
never skip confirmationTYPED JUDGMENT
文章ではなく、
有限の選択肢で受け取る。
AIへ「次に何をすべき？」と自由回答させるのではなく、あらかじめ定義した候補から確率分布を返させます。判定結果が期待する型から外れた場合、アプリケーションは処理を進めません。
serviceIntentreplyKindstepActionidentityEvidenceDETERMINISTIC WORKFLOW
判断のあとに、
業務ルールが待っている。
AIの主判定が合っていても、その値をそのまま注文へ書き込みません。形式、範囲、販売状態、現在の会話ステップをもう一度コードで確かめます。
- 01
数量
1〜99の整数か上限を超えたら注文を作らない
- 02
郵便番号
7桁として読めるか番地と混ぜず、足りなければ聞き直す
- 03
支払い
許可された選択肢か未対応の方法を勝手に補わない
- 04
商品・在庫
商品コードと販売状態在庫切れ・販売停止は登録しない
- 05
注文確定
復唱への明確な承認曖昧な返答では確定しない
SAFE FAILURE
賢く進むより、
正しく止まる。
不確かな状況で処理を続けることは、自動化ではなく事故の先送りです。ContactX Orderは、止まった理由と次の確認を明示します。
「たぶん、あの詰め合わせ」
商品候補を保持せず、商品名または条件を聞き直す
「同じものを200個」
デモ上限を説明し、注文データを作らない
「担当者に代わってください」
それまでの会話を残したまま有人対応へ渡す
「この商品はアレルギー対応ですか？」
答えを作らず、確認が必要な質問として残す
接続できない時ほど、できることを増やさない。
現在のデモではJevへ接続できない場合、安全な文字列一致へ縮退し、発話確定まで長めに待ちます。外部障害を会話ロジックの修正理由にも使いません。
TRY THE EVIDENCE
設計は、画面とテストで確かめられます。
デモでは架空データだけを使います。会話判定の確率分布、実際の注文フロー、43本のシナリオを同じブラウザで確認できます。
本番では、さらに境界を増やします。
この記事は公開デモの設計を説明しています。本番導入では、認証、権限、監査ログ、個人情報の保存期間、外部ECの再送と二重登録防止、モデル更新時の受入試験を、導入先の業務規程に合わせて追加します。
DESIGN YOUR SAFE BOUNDARY