確認前にバーガー3個と1個の伝票を比較するドライブスルー作業員の概念的イラスト。

人工知能プロダクトマネジメントソフトウェアエンジニアリング

音声AI注文において人間は何を確認すべきか？

Ashutosh Singhal 2026年8月4日6 min

合成音声注文の例において、重複した音声トークンが3個のバーガーになります。システムはもっともらしい修正案を提示します。数量を1に変更することです。製品チームにとって難しい問いは、その提案から注文を送信する許可までの間に何が起きるかです。一見有用に見える置き換えも、顧客が何を望んでいたかを確定させたわけではありません。

開示事項：以下の例は、シミュレートされた厨房ディスプレイの前に構造化ベンダー出力を検証する、VeriprajnaのDrive-Thru Order Firewallにおける合成注文です。実際の音声を認識したり、レストランのPOSシステムに注文を送信したりするものではありません。

私は、人間の確認によって特定の不確実性を解消することを望んでいます。そのためには、顧客は何を意図していたのか、その注文はレストランのポリシーで許可されているか、そして提案された正確な注文がチェックを満たしているかという3つの判断を分離する必要があります。それらの判断を1つの承認ボタンにまとめてしまうと、承認が何を意味するのかを把握することが難しくなります。

修正とは意図に関する仮説である

重複トークンのテスト用データには、乱れた文字起こし、3つの同一の生トークン、および3個のバーガーという数量が含まれています。提供された信頼度スコアは0.71であり、設定されたレビュー閾値0.85を下回っています。そのため、重複ルールと低信頼度ルールにより注文はHOLDとなります。重複ルールはバーガー1個を提案します。

1という数量は、オペレーターに提示する候補として合理的です。しかし、意図された数量の証明ではありません。重複したトークンが構造化出力を説明しているかもしれませんが、重複を検知するルールは顧客に何を意味していたのかを尋ねることはできません。3を自動的に1に置き換えることは、疑問のある解釈を未確認の解釈と交換することになります。

閾値0.85に対する信頼度0.71、キャッシュされたモデルのアドバイス、およびバーガー3個から1個への変更提案を示す合成注文の詳細 — 合成テストデータはバーガー1個を提案しますが、顧客の意図を確定するものではありません。表示されている承認操作はこのデモでのクリックを確認するだけであり、バックグラウンドのタイマーはルールとゲートのみを測定します。

注文を拒否することには別のコストが伴います。明確化を必要とする解釈を、あたかも受け入れ可能な注文を回復できないかのように扱ってしまうためです。私はこの時点では保留を好みます。元の証拠が保持され、意図された数量が開かれたままになるからです。本番の設計において、確認はオペレーターにシステムの全体的な信頼度を支持させるのではなく、数量そのものについて尋ねるべきです。

それは設計上の立場であり、このアプリで完成したワークフローではありません。デモのApprove CorrectionボタンとEscalateボタンはラベルを変更して自身を無効化します。これらは再送信やリリース、人間の行動の記録、レシートの変更を行うものではありません。本番チームは、その回答に実質的な結果をもたらす対話と状態変化を依然として構築する必要があります。

異例のリクエストも正確に理解されている可能性がある

解釈は一時停止を行う理由の1つにすぎません。別の合成テストデータには、提供された信頼度スコア0.97と顧客メニュー価格0のウォーターカップ18,000個が含まれています。この数量は設定されたウォーター上限の8を超えているため、ゲートが保留します。高い入力スコアもゼロの価格も、その数量を進めてよいかどうかには答えません。スコアはテストデータからの入力値であり、許可の調整された確率ではありません。

極端な数量であれば、この区別を容易に確認できます。より難しい製品上の決定は、顧客が実際に求めている異例の数量です。レストランの通常の自動制限を超える仮想のグループ注文を考えてみてください。顧客が数を確認すれば、許可は未解決のまま解釈は確定する可能性があります。通常の上限に減らすことはリクエストを変更することになります。完全に拒否することは正当な需要を破棄する恐れがあります。

私は、ポリシーが例外を認めている場合にレビューをトリガーする例外閾値を使用することを好みます。オペレーターは、場合によっては個別に承認されたルートを通じて、レストランが確認された注文を受け入れられるかどうかを決定する必要があります。自動送信を制限するために設計された閾値が、顧客の意図を書き換えるルールへと暗黙のうちに変わるべきではありません。

これには注意のコストがかかります。より緩やかな自動閾値は、より多くの異例の注文を通過させます。より厳格な閾値は、より多くのレビュー作業を生み出します。デモはレストランのためにそのバランスを選択することはできません。その上限はシードされた合成注文履歴から得られたものであり、分布はその履歴に現れたものを表しています。実際の店舗の収容力や、正当なグループ注文がどの程度の頻度で発生するかを立証するものではありません。そのようなポリシーを採用する前に、チームは受け入れ可能な例外とそれを確認する実際的な負担に関する証拠を必要とします。

確認は正確に次の注文に適用されなければならない

確認された修正であっても無効なままになる可能性があります。大口注文のテストデータは40個のポテトと40個の炭酸飲料から始まります。数量ルールはポテトを4個に減らすことを提案しますが、40個の炭酸飲料はそのまま残します。炭酸飲料の上限は6個です。したがって、ポテト4個が適切な代替であると合意しても、提案された注文には別の数量違反が残ることになります。

承認およびエスカレーションボタンの上に、ポテト4個と炭酸飲料40個の提案を伴う40個のポテトと40個の炭酸飲料を比較する合成注文の詳細 — この提案はポテトのみを変更します。炭酸飲料40個が残るため、提案された注文が合格することは示されていません。UIの「Rate limit」は時間の経過に伴うリクエストではなく、1つの注文内の合計ユニット数をチェックします。その実際の境界は44ユニットです。

これが私が確認と検証を区別し続ける理由です。顧客の確認は意図に対処します。権限を持つオペレーターの例外決定はポリシーに対処します。提案された完全な注文をチェックすることは、次の取引が適用ルールを満たしているかに対処します。それらの答えのいずれも、他から安全に推測することはできません。

本番ワークフローの場合、私は確認された提案が送信前に再度検証を通過することを求めます。オペレーターがポリシーをオーバーライドできる場合、その権限は明示的であり、受け入れられる特定のルールと注文に紐付いている必要があります。包括的な承認が無関係な失敗を消し去るべきではありません。これらは将来の実装に向けた要件であり、現在の修正コントロールによって実証されている機能ではありません。

助言は許可を与えることなく役立つことができる

説明モデルの注記には有用ですがより限定された役割があります。保留の理由を読みやすくすることです。付属の創業者録画では、その注記はキャッシュされた実際のアドバイザリー応答を使用しています。再生ごとの新しい推論ではありません。エンジンは決定論的ルールを使用して最初に決定します。その後のアドバイザリーテキストは決定を変更できません。アドバイザリーの呼び出しは処理内で同期的であるため、この権限の分離はモデル作業によってリクエストのレイテンシが追加されないことを立証するものではありません。

こちらの注文検証の詳細な解説は、この境界と合成例を示しています。これらは検証可能な設計上の主張を裏付けるものであり、初期設定されたポリシーや未完成のオペレーターワークフローが本番運用の準備完了であることを証明するものではありません。

こちらは注文レビューの例に関する創業者の録画です。

私にとって決定的な製品レビューは、提案された注文を次の許可されたアクションまで完全に追跡することです。誰がその意味を確認したのか？誰が例外を受け入れられるのか？何が完全な結果をチェックしたのか？それらの答えがまったく同一の注文を指し示すまで、安心感を与える修正や承認ラベルは取引を未完了のままにします。