製品リコール通知サービスの作り方：リコール告知のスクレイピングから対象ロットの照合まで

製品リコールデータはすでに公開されているのに、なぜ消費者や販売事業者は自分に関係するリコールを見逃すのでしょうか。告知が答えるのは「何が起きたか」ですが、通知サービスは「この告知は自分の手元にある製品に該当するか、今何をすべきか」に答える必要があるからです。その間には、製品の特定、ロットの照合、根拠の格付け、継続的な改訂、確実な配信があります。

r/newproductsに投稿されたリコール通知製品の紹介では、購入した製品を写真で登録し、関連するリコールが発表されたときにユーザーへ通知する仕組みが提案されています。この投稿は仮説段階のユーザータスクを示しているにすぎず、認識精度、即時性、支払い意欲を証明するものではありません。本当に検討すべきなのは、「自分が持っている製品」を規制当局が公表したリコール対象範囲にどうすれば確実に結びつけられるかです。

課題は告知のスクレイピングではなく該当判定にある

リコールのタイトルには通常、ブランド、カテゴリ、製品シリーズが含まれますが、対象品かどうかを実際に決める条件は、型番、製造日、ロット、シリアル番号、UPC、パッケージサイズ、販売地域、販売期間に隠れていることがあります。製品名だけで全文マッチングを行うと、類似しているが対象外の商品がユーザーに通知されてしまい、逆に条件を厳しくしすぎると、フィールドが不完全なレコードを取りこぼすおそれがあります。

CPSCのリコールAPIは、公開されているリコール情報にJSONまたはXMLの機械可読形式でアクセスでき、タイトル、説明、製品名による検索に対応しています。これは安定したデータ収集の入り口になりますが、APIで検索できるからといって、すべてのレコードに統一された商品識別子が含まれているわけではありません。製品側では「フィールドの欠落」や「手動確認が必要」を通常の状態として扱えるようにする必要があります。

最初のバージョンでは、写真からすべてを自動判定できると約束すべきではありません。より現実的なのは、次のような約束です。ユーザーが提供できる識別子を保存する。新しい告知が出たときや既存の告知が改訂されたときに照合を実行する。確度の高い一致はすぐにユーザーへ通知する。一致の疑いがある場合は型番やロットの確認をユーザーに依頼する。判定できない場合は、何が不足しているかを明示する。

異なる規制当局のソースを1つの汎用フィールド表に平坦化しない

消費財、食品、医薬品、車両、さらに国や地域ごとのリコールレコードは、それぞれ異なるソースと法的背景を持っています。openFDAの食品APIエンドポイントはenforcementなどのデータセットを分けて提供しており、食品enforcementレポートのクエリ例では日付範囲やカテゴリによる絞り込みが示されています。これらは食品のenforcementレポート検索には対応していますが、あらゆる製品リコールを扱う統一的なリアルタイムAPIとして書き換えるべきではありません。

内部のデータ層では、共通の外枠を使いながら、ソース本来の表記をそのまま残せます。共通フィールドは検索と配信に、ソースのフィールドは検証に使います。

• 統一識別子、発出機関、ソースのレコードID、告知日、最終確認日時。
• 製品名、ブランド、型番、コード、ロット、販売地域、販売期間。欠損値は空のままにする必要があります。
• リスクの説明、対処方法、消費者向けの問い合わせ窓口、元の告知へのリンク。
• 現在のステータス、以前のバージョン、フィールドの変更内容、データ収集の失敗状況。
• 標準化の過程で重要な限定条件が失われないよう、元のレコードまたは追跡可能なスナップショット。

共通の枠組みを使っても、異なるソースに同じ精度を求めるわけではありません。レコードに自然言語の説明しかない場合は、自然言語としてラベル付けした状態を保つべきです。データベースを整然と保つためだけに、存在しないSKUを推測してはいけません。

照合結果は「確定」「疑い」「根拠なし」に分類する

リコール通知システムには、根拠を説明できる段階的な照合基準が必要です。最も強い根拠は通常、UPCとロットの両方が一致する場合や、型番とシリアル番号の範囲の両方が一致する場合など、正確な識別子の組み合わせです。次の段階は、型番と販売期間は一致するものの、ロットが欠けているケースです。ブランドが類似し、名称があいまいに一致するだけの場合は、「お使いの製品はリコール対象です」と断定せず、要確認の手がかりとして扱うべきです。

照合結果は、次の3つに分類できます。

1. 確定一致：レコードの主要な識別子がユーザーの登録情報と一致しており、検証用に元の告知も添付されています。
2. 一致の疑い：一部の条件は一致するものの、ロット、日付、地域の情報が欠けています。通知では、不足している識別子がどこで確認できるかをユーザーに直接伝えます。
3. 判定不能：ソースに十分な構造化フィールドがない、または写真の認識結果が安定しません。結論を出さずに観察を続けます。

「一致なし」は「安全」と同じ意味ではありません。対象ソース、現時点のデータ、既存の識別子の範囲で一致する根拠が見つからなかった、というだけです。この表現は慎重すぎるように見えるかもしれませんが、ユーザーが誤って確認をやめてしまうかどうかを直接左右します。

画像認識は、ユーザーがラベルを書き写す作業の補助に向いており、最終的な判定には向きません。OCRで型番やバーコードの候補を提示し、ユーザーに確認してもらう形にします。低画質の写真、パッケージの変更、似た文字などはいずれも誤認識の原因になります。プロダクトでは、毎回古い写真から推測し直すのではなく、ユーザーが確認したフィールドを保存すべきです。

リコールレコードは改訂されるため、通知にもバージョンが必要

CPSCのリコールページには、対処方法に関する情報が変わる可能性があると明記されています。対処方法、事業者の連絡状況、適用範囲が更新された後も、古い通知を唯一の答えとして使い続けるべきではありません。そのため、収集層では初回の検出、内容の改訂、ソースの一時的な利用不可を区別する必要があります。同じ告知を毎日新しいリコールとして扱ってはいけません。

リコールレコードに適したイベントキーは、通常、発出機関とソースのレコードIDの組み合わせです。確認のたびに内容の要約と重要なフィールドの差分を保存します。範囲が拡大された場合は関連する商品をすべて再照合し、レイアウトだけの変更であればユーザーに知らせる必要はありません。対処方法が変わった場合は、以前に通知を受け取ったユーザーへ訂正を送るべきです。通知そのものにも、どのバージョンから生成されたかを記録しておく必要があります。

ソースページが一時的に取得できなかった場合、画面には「新しいリコールはありません」ではなく「今回の確認は完了していません」と表示すべきです。サイト内のAPIエラーと自己修復のガイドでは、タイムアウト、レート制限、権限、データソースのエラーをそれぞれ分けて扱う必要がある理由を解説しています。リコールのシナリオに当てはめると、特に情報収集が中断した状態を安全な状態に見せかけてはいけません。

ユーザーが求めているのは要約ではなく次の行動

効果的な通知では、最も重要なアクションを冒頭に置きます。使用を中止する、ロットを確認する、販売店に連絡する、返金を申請する、修理する、続報を待つ、などです。アクションは現行の公式告知に基づくものでなければならず、モデルに独自の対処方法を補わせてはいけません。リスクの高いケースでは、要約のすぐ後に元のソースと公式の問い合わせ窓口を示すべきです。

通知のタイミングも、深刻度と照合の確度によって分ける必要があります。確定一致かつリスクの高いレコードはすぐに送信できます。確度が低い「一致の疑い」は確認待ちキューに入れ、ユーザーが識別子を補った後に更新するのが適切です。日次ダイジェストは通常の監視に適していますが、メッセージ数を減らすために、明らかに関連する安全上の通知を遅らせてはいけません。

事業者向けのプロダクトでは、社内タスクも必要です。関連商品の販売停止、在庫の特定、注文の検索、影響を受ける顧客への連絡、処理結果の記録などです。データ収集はタスクのきっかけになるだけで、注文、倉庫、顧客情報に対する事業者側の権限管理を代替することはできません。結果をワークフローに組み込む際は、サイト内の統合データAPI設計ガイドを参考に、元の根拠、標準化されたフィールド、業務上のアクションを階層化できます。

商品リストそのものが機密性の高い資産

家庭が所有する商品からは、健康状態、乳幼児の有無、住まい、消費傾向がわかる場合があります。また、事業者の在庫や注文は業務データにあたります。リコール通知のプロダクトは、「安全のため」という理由だけで、写真、レシート、注文の全情報を無期限に保存することをデフォルトにすべきではありません。

最初のバージョンでは、照合に必要な最小限のフィールドだけをユーザーが保存し、いつでも削除できるようにします。メール、注文、小売店のアカウントから自動でインポートする場合は、個別の明示的な許可、アクセス範囲の表示、同期停止後も保持されるデータについての明確な説明が必要です。認識完了後も写真を保存し続けるかどうかも、明確なプロダクトルールで定めるべきです。

事業者向けには、リコールのソースデータ、社内のSKUマッピング、顧客の連絡先情報を階層化し、それぞれに権限を設定すべきです。リコールの確認を担当する人が顧客プロファイルの全体を見る必要があるとは限らず、通知を担当する人がソースの根拠を変更できるべきではありません。監査記録には、少なくとも誰が一致を確定したか、どの告知バージョンを使ったか、どの対象にどのアクションを実行したかを残す必要があります。

MVPで検証すべきは告知の件数ではなく照合のループ

管理しやすいパイロットでは、規制当局のソース1つ、製品カテゴリ1つ、ユーザーが任意で登録した少数の商品だけを対象にすれば十分です。まずすべての候補を手動でレビューし、どのフィールドがシステム上の問題を引き起こすかを観察します。この段階では、何年分の過去の告知をインデックス化したかよりも、関連する通知を正確に説明できるかどうかのほうがはるかに重要です。

指標は4つのカテゴリに分けることをおすすめします。照合可能なレコードの割合、「一致の疑い」の判定に必要なフィールド、確定一致の通知の配信・閲覧状況、通知から対処完了までのステータスです。誤検知と見逃しは別々にレビューし、ソースフィールドの欠落、製品登録の誤り、照合ルールの誤りも区別する必要があります。そうして初めて、後続の自動化でデータ、操作、ルールのどれを修正すべきかが分かります。

本記事はデータプロダクトの設計手法を論じるものであり、EveryInfraがリコール通知サービスをリリースしたことを意味するものではありません。真の製品リコール通知サービスとは、より多くの告知を収集することではなく、「公式記録—特定の品目—明確なアクション—その後の訂正」という検証可能なつながりを形成することです。システムが不確実性を明示できて初めて、通知は長期的に信頼されるものになります。