AIがチェックアウトの設計で犯す間違い（とその解決策）

AIがチェックアウトを設計する際、予測可能なある間違いを犯します。それは、「1万回目の取引」ではなく「デモ」のために設計してしまうことです。AIアプリビルダーにチェックアウトの作成を依頼すれば、数分で説得力のあるものが出来上がります。すっきりとしたカート、整然としたボタン、分かりやすい決済画面。しかし、失敗の原因はスクリーンショットには写らないすべての部分に潜んでいます。返金、分割払い、税則、あるいは土曜日の正午に行列を作る顧客への対応といったフローを、そのシステムがどう処理するかという点です。\n\n解決策は、プロンプトを工夫することではありません。チェックアウトのどの部分をAIに任せ、どの部分には絶対に即興での処理を許さないかを決めることです。ここでは、AIが生成したチェックアウトが実際に破綻するポイントと、それぞれの対処法を紹介します。\n\n## なぜAIが設計したチェックアウトは、見た目は良くても実際の運用で失敗するのか？\n\n理由は2つあります。1つ目は、AIが既存のチェックアウトから設計を学習しているためであり、その既存 of チェックアウトの質が平凡だからです。Baymard Instituteによると、記録されているオンラインの平均カート放棄率は70.22%に達し¹、米国の平均的なチェックアウトでは、理想的なフローが12〜14個の入力項目で済むところを23.48個も表示していることが分かっています¹。平均的なデータでトレーニングされたモデルは、その間違いも含めて平均的なものを再現してしまいます。\n\n2つ目は、「ハッピーパス（正常系）への偏り」です。生成されたソフトウェアは、デモと同じように「通常のケースが機能するかどうか」で評価されます。しかし、チェックアウトはレジスターと同じように「お客様が見ている前で、あらゆるケースが毎回確実に機能するかどうか」で評価されます。これらは全く異なる基準であり、そのギャップは、実際のお金が動くようになるまで表面化しません。\n\n\n\n## AIはチェックアウトにおいて実際に何を間違えるのか？\n\n5つの失敗が繰り返し発生します。（その背景にある、より深刻なインフラ面のギャップについては、LovableやReplitでPOSを構築できるか？をご覧ください。このリストはチェックアウト自体に関するものです。）\n\n- 計算処理。生成されたコードは、通貨の計算を浮動小数点数（端数処理が不安定な十進法計算）で行うことが多く、割引、税金、分割払いの処理で1セント単位のズレが生じます。その症状は一日の終わりに現れます。売上合計が日計レポートと1セント単位で一致（照合）しなくなるのです。\n- 税金。AIは1つの税率をハードコードしがちです。実際の売上税（消費税）は、管轄区域、商品の種類、非課税措置、日付によって異なり、コードに通知されることなく変更されます。税金を推測で処理するチェックアウトは、チェックアウトとは呼べません。見た目が良いだけの「負債」です。\n- アンハッピーパス（異常系）。返金、取引取消、一部支払い、価格の手動変更、決済途中の接続切断など。デモではこれらがテストされることはありませんが、店頭では毎日発生します。大半のAI生成チェックアウトには、これらの処理がそもそも備わっていません。\n- レジ係の操作スピード。AIは、1回しか決済しない買い物客向けに設計されたECのパターンをコピーしてしまいます。レジ係は1回のシフトで同じフローを何百回も実行するため、タップ数が1回増えるだけで、それが積み重なって行列の原因になります。些細な選択であっても店頭の動線に影響を与えます。チップの入力画面をどこに配置するかだけでも、慎重な決定が必要です。\n- 決済。「支払う」ボタンを配置するだけでは決済は完了しません。対面でカード決済を受け付けるには、決済プロセッサー、PCI準拠（カード業界のデータセキュリティ基準）、および認定されたリーダー端末が必要です。これらはプロンプトから生成できるものではなく、あらかじめ存在していなければなりません。決済インフラに実際に含まれるものは、大半の人が予想するよりもはるかに多岐にわたります。\n\n\n\n## AIが設計したチェックアウトをどのように修正するか？\n\n作業を2つに分割します。AIは、レイアウト、フローの順序、文言、店舗の実際の販売方法に合わせた画面構成といった「デザイン面」において非常に優れています。その部分はAIに任せましょう。一方で、「お金に関する部分」（計算、税金、決済処理、取引記録）は、プロンプトごとに生成されるコードではなく、決定論的（常に同じ正しい答えを返す）なコマースインフラから提供されるべきです。\n\n「税金を正しく処理するようにプロンプトで指示する」だけでは、この問題は解決しません。なぜなら、それが正しく機能しているかどうかは見た目では判断できないからです。チェックアウトの計算が1取引あたり数セントずれていることに、何ヶ月も誰も気づかないということも起こり得ます。そのため、解決策は構造的なものである必要があります。\n\n- プロンプトに頼るのではなく、制約を設ける。合計金額、税金、支払い方法が最初から組み込まれており、AIはそれらを再発明するのではなく、配置の調整のみを行えるプラットフォームを使用します。\n- ローンチ前にアンハッピーパスをテストする。返金、取消、分割払い、決済途中のキャンセルを実行してみます。これらのいずれかが欠けている場合、それはチェックアウトではなく、単なるデモ画面です。\n- 初日から照合を行う。実際の販売初日の終了後に、チェックアウトの合計金額と決済プロセッサーの記録を比較します。数セントのズレは、すぐに現れるか、あるいは全く現れないかのどちらかです。\n- 回避策に注意する。最初の週にスタッフがフローを回避するような独自のやり方を編み出している場合、その設計は失敗しています。その回避策がシステムとして定着してしまう前に修正してください。\n\n\n\n## では、AIがチェックアウトの設計で犯す間違いとは何か？\n\n見た目は正しく作れても、裏側の仕組み（配管）が間違っている点です。正常系のフロー、即興の計算処理、推測による税金、および返金、分割、対面でのカード決済への対応不足などが挙げられます。これらはプロンプトを改善しても解決しません。すでにお金を処理できるインフラの上にAIを載せることで解決します。経験則として、フローの設計はAIに任せ、お金の処理を即興で任せてはなりません。\n\nこの役割分担こそが、Finalの「Build」のようなプロンプトベースのビルダーの背景にある考え方です。ここでは、希望するチェックアウトを言葉で説明するだけで、その裏側にある合計金額、税金、Final Payの取引は、常に正確に計算されるシステムによって処理されます。実際に体験するには、約10分で最初のフローを構築するか、ビジネス向けAI：できることとできないことで視野を広げてみてください。