01 文脈と問題
クライアントはリース重視の BNPL 商品を提供していました。顧客は承認された支出上限を申請し、対象となる購入をファイナンスし、全額支払わずに分割払いで返済するというものでした。この商品は家具、テレビ、家電などのリース可能な品目のみを対象としており、ペン、ノート、文房具などの低価値消耗品は含まれていませんでした。クライアントは、支払いオプションを各小売業者のウェブサイトに直接統合することで成長しました。営業が小売業者にアプローチし、小売業者がサンドボックスを提供し、チームがゲートウェイを統合し、エンジニアリングとQAがチェックアウトを担当し、両者が本格リリースを調整します。
このモデルは5〜7店舗で通用し、ネットワークの拡大とともに崩れました。小売業者はShopify、Magento、BigCommerce、カスタムプラットフォームの異なる組み合わせ、異なるチェックアウト、異なる決済処理業者、異なるサンドボックスやリリース手順を運用していたため、すべての統合が独自の恒久的な実装とサポートライフサイクルとなりました。小売業者のプラットフォームのアップグレードやチェックアウトの変更は、クライアントに統合の再構築、回帰テストのやり直し、新しい共同リリースのスケジュールを強制する可能性がある。約6か月後、プログラムは60〜70人の約15店舗をサポートし、翌年には200+小売店を導入する計画でした。線形の拡大は数百人、場合によっては千人近くの人を意味していました。本当の問題は開発能力ではありませんでした。このアーキテクチャは新しい小売業者を外部依存機構にし、クライアントは小売店の成長がエンジニアリングやサポートの比例的な成長を必要としないモデルを必要としました。
02 役割と制約
AI Product Manager、私はエンドツーエンドのソリューションを担当していました。製品戦略、問題定義、カスタマージャーニー設計、AIユースケース定義、ソリューションアーキテクチャ、小売業者支援戦略、製品データとラベリングの要件、エンジニアリングとAI/MLの調整、APIおよびバックエンド要件、バーチャルカード統合、モバイルおよびブラウザ拡張機能の体験、セキュリティとコンプライアンスの調整、分析とモデルパフォーマンス要件、展開計画とステークホルダー管理。最も重要な判断の一つは、AIをどこで使うべきか、どこで使えないかの範囲設定でした。モデルはリース可能製品ポリシーの下で製品が適格かどうかのみ回答しました。信用力の判断、信用限度の設定、本人確認、返済条件の定義、SSNの確認やアカウントの承認は行われず、すべてクライアントの既存の承認、身元、契約システムにとどまりました。
制約は具体的でした。小売店側の実装依存を排除する:どの小売業者も支払い方法の追加、サンドボックスアクセスの提供、チェックアウトの変更、カスタムAPIの公開、開発者の割り当て、共同QAの実施を義務付けるべきではありません。小売業者はリース可能な商品と非リース商品の両方を販売できるため、システムは小売業者全体ではなく個々のカート商品を分類し、混合カートは対象部分のみを融資して扱いました。異なる小売店の技術を連携させ、DOMの変更を管理する必要があります。なぜなら、拡張機能は小売店のページを読み込み、ページの更新がHTML構造、セレクター、商品カード、価格、チェックアウトフィールドを変える可能性があるからです。分類精度は許容範囲を維持し、目標は90以上、95%に近づくと一般的に85〜90パーセントに抑えてください。顧客情報(名前、住所、携帯電話番号、SSN、OTP)を暗号化、トークン化、アクセス制御、監査ログで保護します。そして後には、各店舗のPOSシステムに統合せずに実店舗の小売をサポートできるようにしましょう。
03 プロダクトアプローチ
より効率的な小売業者と統合チームを構築する代わりに、統合の場所を変更しました。元のモデルでは、顧客の資金調達能力を小売店のレジに置いていました。再設計されたモデルは、ファイナンス体験をクライアントが管理するチャネル内に置き、eコマース用の Chrome 拡張と実店舗向けのクライアントのモバイルアプリを導入しました。これにより、多くの小売業者間で共有され独立したプラットフォームが生まれ、どの小売業者もクライアントの支払い方法を導入しませんでした。
オンラインでは、 Chrome の延長が小売業者を特定し、顧客にファイナンス可能であることを伝え、カートと合計を読み、製品詳細をバックエンドに送信し、各商品をリース可能か非リース可能かに分類し、不適格な商品を除外し、対象金額を顧客の限度額と照合し、登録と確認をサポートし、契約書を提示し、使い捨てまたは限定使用のバーチャルカードを作成しました。 そして自動で小売店の標準レジに入力しました。新しい小売業者の導入は、6か月間の二者間統合ではなく、社内で管理されるプロセスとなりました。小売業者の公開カタログデータを収集し、クライアントの方針に従ってリース可能・非リース可能な商品にラベルを付け、数千件のレコードで分類器を訓練または更新し、既知のラベルに対する正確性の検証を行い、製品名、価格、数量、カテゴリ、カート総数のDOM抽出を設定すること、 エンドツーエンドのフローをテストし、その後小売店を有効化します。サンドボックスやレジの変更、ゲートウェイ展開は不要です。
店舗では同じ機能をモバイルアプリにも拡張しました。アプリは顧客が店舗のジオフェンス内にいることを検知しました。請求カウンターでは、顧客が明細書を写真に収めました。 OCR 製品名、数量、価格を抽出し、項目は正規化され、同じ適格モデルに引き継がれました。アプリは対象商品と不適格商品を分けて、リース不可の商品は別々に支払うことができました。対象となる合計は制限と照合され、顧客はその合意を受け入れ、対象金額のバーチャルカードが作成され、店舗の通常のカード受付プロセスを通じて使用されました。もしお客様がカードを使用する前にジオフェンスを離れると、自動的に期限切れとなりました。ジオフェンシングは取引を処理するのではなく、バックエンドがカードのライフサイクルステータスを変更するトリガーとして機能していました。
クライアントはより大きな統合チームを必要としているように見えました。本当の問題は、成長が数百の外部小売システムや発売スケジュールに依存していたことです。体験をクライアント制御の拡張機能とモバイルアプリに移行し、仮想カードを相互運用性レイヤーとして使うことで、その依存関係は変わりました。小売店の商品データがカスタム決済統合に代わり、すべての商品が独立して決定されるようになりました。
製造機能
サポート小売業者検出
この拡張機能は利用可能な小売店サイトを認識し、顧客の融資が利用可能であることを示します。
DOMベースのカート抽出
小売店固有のDOMロジックは、ページから商品およびカート情報を引き出します。
AI製品の適格性
すべてのカート商品は共有モデルによってリース可能か非リース可能かに分類されます。
混合カート扱い
対象外の項目は除外されるため、対象部分のみがローンで支払われます。
延長内登録
新規顧客はショッピングの途中でアカウントを作成できます。
バーチャルカード+チェックアウト自動入力
使い捨てまたは使用限定のカードが生成され、小売店のレジに自動入力されます。
モバイル店内移動
既存のクライアントアプリは、適格な実店舗購入の資金調達のために拡張されました。
ストアジオフェンシング
アプリは、対応店舗の設定エリア内に顧客がいるかどうかを検知します。
ビルキャプチャー+ OCR
顧客は明細書を写真に収め、 OCR 画像から行項目を抽出します。
受領正規化
OCR アウトプットは構造化された製品、数量、価格レコードに変換されます。
適格/非適格の分割
アプリは何がファイナンスできるか、何が別々に請求または支払うべきかを表示します。
ジオフェンスによる失効
使用前に店舗の境界線を離れると自動的にカードが失効します。
また、承認されたリミットバリデーション、モバイルOTP認証、クライアントの既存アイデンティティシステムに対するリアルタイムSSN検証、契約提示と受理(拡張機能内およびアプリ内)、製品トレーニングとDOM設定によるリピート可能な小売業者のイネーブルメント、両チャネルでの共有商品分類再利用、そして適格性、顧客検証、契約、バーチャルカード、分析のための単一のオムニチャネルバックエンドも提供されています。
05 アーキテクチャ
2つの顧客チャネルが一つのバックエンドに収束しました。オンラインチャネルは Chrome 延長と小売業者のDOM抽出です。店内チャネルはモバイルアプリに加え、ビル写真撮影、 OCR 、ジオフェンシングです。両社は、製品の正規化、リース可能な商品分類、顧客IDおよびクレジット限度額の検証、契約作成、バーチャルカード発行、カードライフサイクル管理、分析および監査ログなど、同じコアサービスを使用しています。 Python バックエンドは REST APIを公開します。外部のPCI DSS準拠カード提供者が単一使用または限定使用の仮想カードを発行します。
建築は膨張単位を変えました。以前は各小売業者が商業契約、技術リソース、サンドボックスアクセス、支払い統合、共同QA、調整リリース、継続的なプラットフォームサポートを必要としていましたが、新しいオンライン小売業者は主に製品データの準備、ラベリング、モデルトレーニングまたは検証、DOM設定、チェックアウトテスト、拡張機能の有効化を必要としています。新しい実店舗は主に店舗配置、製品データのカバレッジ、レシートフォーマットの検証、 OCR テスト、適格性テスト、カード受理の検証を求めます。セキュリティは暗号化、トークン化、制限付きアクセス、監査ログ、OTP検証、リアルタイムのSSN検証、管理された契約実行、単回または限定使用カード、位置情報による有効期限、PCI DSS準拠プロバイダーに及びます。信頼性はサーフェスごとに監視されます:DOMのオンライン破損(製品の欠失、無効なセレクター、オートフィルの失敗)、店舗内の OCR 変動(照明の不良、ぼやけ、折り目、略語、税金および割引ライン)、ジオフェンスの制限(許可拒否、屋内精度、GPSドリフト、終了イベントの遅延、OSのバックグラウンド制限)、バーチャルカードの結果(発行失敗、プロバイダーのタイムアウト、アクティベート、有効期限、認可)。トレードオフは明確です:小売業者の独立性は依然として小売業者のDOMに依存します。POSの独立性はレシートの品質に依存します。共有モデルは2つの非常に異なる入力タイプにまたがっています。位置管理は位置精度に制限されます。また、外部カードプロバイダーはインフラ負荷を軽減しつつ、ベンダー依存性を高めます。
06 アナリティクスと観測性
拡張されたプラットフォームは、オンラインレジ、 OCR 性能、モデルの精度、位置情報の挙動、支払い結果に関する別々の測定が必要でした。なぜなら、単一の失敗がいずれかのどこからでも発生し得るからです。 OCR 精度と分類精度は別々に測定されました。分類失敗は誤った OCR 文、誤ったレシート解析、不十分な製品文脈、あるいは本物のモデルエラーから生じる可能性があります。eコマースのファネル(小売業者が→→の延長を検知し、カート→分類された→適格な金額→カード→オートフィル→購入→→契約を検証)と、店舗内のファネル(店舗がジオフェンス入力→→請求書の写真→→ OCR →ラインアイテム分類→非リース、分離→対象、承認済み→契約→カード→支払いまたは有効期限検出)の両方が、エンドツーエンドで計測されていました。サポートプロファイルも変わりました。小売店の統合、サンドボックス、ゲートウェイの欠陥から、請求、契約、返済、 OCR や請求書読み取り、DOMの変更、位置情報許可、カード認証の質問へと移行しました。
オンライン小売業者の指標
小売店検出、カート抽出、DOMエラー、自動入力とレジ成功、承認から購入への変換。
分類指標
小売業者、カテゴリー、チャネルごとの精度、誤貸出・非貸し利の料金、信頼度分布。
OCR 指標
キャプチャと処理成功、ラインおよび価格抽出、総照合、再キャプチャおよび手動修正率。
ジオフェンス計量
侵入検出、許可拒否、退出イベント、退出後のカードの有効期限、生成から支払いまでの時間などです。
バーチャルカード指標
リクエスト成功率、生成遅延、プロバイダーエラー、アクティベーション、認可結果、未使用カードレート。
07 AI意思決定層
このモデルは、両チャネルに共通する一つの狭い問いに答えました。それは、この商品はクライアントのリース可能商品ポリシーの対象となるのか?オンライン入力は、製品名、画像、カテゴリー、小売店の文脈、利用可能な説明、価格と数量、さらにリース可能/非リース可能のトレーニングラベルを組み合わせていました。店頭での入力は OCR、抽出された説明、レシートの項目文、数量、価格、店舗の文脈、過去の小売店の製品データであり、これらはしばしばeコマースページほど説明的でないため、店内フローでは商品正規化が最も重要でした。パイプラインはDOMやレシートから商品情報を取得し、小売店固有のテキストを正規化し、既知のカテゴリにマッピングし、リース可能性を評価し、結果を返し、対象となる総額を計算し、モデルの結果とバージョンを記録して監視しました。トレーニングでは、構造化されたスプレッドシート形式のデータ(名前、画像、カテゴリー、小売店、ラベル)を使い、小売業者や小売業者グループごとに数千の例を用いる監督付き商品分類モデルが用いられました。報告された正確度はおおよそ85〜90パーセントで、90を超えて95に近づくことを目標としていました。これはクライアントのプロジェクトレベルの指標であり、個別の精度、リコール、F1、独立監査評価は提供されていません。
AIは製品の適格性のみに答えました。信用力の判断、信用限度の設定、本人確認、返済条件の定め、SSNの確認や承認されたアカウントの実施は一切行われず、すべてはクライアントの既存システムにとどまりました。既知の失敗モード(リース可能と評価される非リース可能な品目、誤って拒否されたリース可能な品目、簡略化されたレシートラインの誤マッピング、バンドル商品または新品商品、小売業者の分類が変更された、または不良な OCR)は推奨される次のステップを示しています。すなわち、自信があると自動的に継続する信頼度に基づく意思決定、中程度の信頼度で決定論的カテゴリールールを適用し、低い信頼度で顧客に再取得を求めること、 未解決の場合は除外または審査ルートを設けます。
08 状況と結果
Chrome延長により、100+小売業者が約4か月でサポートされ、元のモデルでは約6か月で15店舗が対応されていました。最終的には300+オンライン小売店でファイナンス商品を利用できるようになり、15小売店の基準から約20倍の増加となりました。新しい小売業者はもはや技術リソース、サンドボックスアクセス、ゲートウェイ統合、共同QA、小売店側の展開、または調整リリースを必要としませんでした。内部制御のデータ準備、ラベリング、モデルトレーニング、DOM設定、チェックアウトテスト、アクティベーションを通じて実現可能でした。元々の60〜70人のチームはほぼ変わらず、データ準備、モデルトレーニング、精度作業のために約4〜5人のAI/MLエンジニアを加えたため、旧モデルが示唆する比例的な人員増員を回避しました。小売店との連携作業、カスタム開発、サンドボックス作業、共同テスト、プラットフォーム固有の決済保守は削除されました。クライアントは、承認された上限を受け入れる店舗が増えたため、チェックアウト取引量が増加したと報告しました(定性的報告で正確な数値は提供されていません)。プラットフォームはモバイルアプリを通じて物理的な小売にも拡張され、コアモデルがウェブチェックアウトに限定されないことを証明し、繰り返しの統合、サンドボックス、ゲートウェイ開発、共同QA、リリース調整、比例サポートの成長にかかるコストが改善され、バーチャルカードプロバイダーが主な外部依存基盤となりました。
300+
オンライン小売業者がサポートしています
20×
小売業者の補償拡大
4 mo
100+の小売店へ(15ヶ月で6ヶ月かかるのに対し)
85-90%
報告されたモデルの精度
09 リフレクション / 次は何だ
効果があったのは、スタッフ問題ではなく依存関係の問題を解決することでした。1つの適格性機能でウェブページ、ショッピングカート、 OCR抽出請求書、バーチャルカードで顧客が既にサポートしている決済フローを通じてクライアントが操作できるようになり、各チャネルには独自のコントロール(DOM抽出とオンラインオートフィル、 OCR、ジオフェンシング、ストア内のカード有効期限)が一貫した共有プラットフォーム上で追加されました。次に改善したい点は、小売店のエンイブルメントを社内運営の製品として正式化すること(アップロード、ラベリング、トレーニング、検証、DOMおよび店舗設置、リリース承認、健康監視);最終請求書と合計、割引、税金照合を算出するための領収照合を加えます。低信頼度レビュー方針の導入;ジオフェンス管理の有効期限、取引額および単一取引の制限、承認後の即時閉鎖強化;スケジュールされた合成テストによる自動DOM変化検出を構築し、ダッシュボード上での OCR とAIによるエラー報告の別個、モデルガバナンスのトレーサビリティ向上(チャネル、小売業者、モデルおよびトレーニングデータバージョン、入力、 OCR および分類信頼度、合意バージョン、カードアウトカム);また、権限やバックグラウンド位置情報の挙動が異なるため、AndroidとiOSで慎重に拡大しています。その最終的な成果は、小売業者の製品データがカスタム決済統合に代わり、AIが適格性を決定し、既存システムが身元とクレジットを管理し、仮想カードが相互運用性を生み出し、ブラウザとモバイルで顧客が流通をコントロールできるようになり、ビジネス成長とエンジニアリングの努力が切り離されたオムニチャネルプラットフォームとなりました。