ブランド公式サイトで NFC 認証を完結させるには

安全な NFC 封印ラベルを付けた限定商品を例に考えてみましょう。商品を受け取った購入者が、対応するスマートフォンを封印ラベルに近づけ、表示されたリンクを開きます。このリンクは最初にブランドのドメインへアクセスするため、確認はブランドのサイトから始まります。

ブランドのサイトのサーバー（バックエンド）は、今回タグから読み取った情報を BrandGuard に送ります。BrandGuard は暗号による認証情報と、登録された個体との対応を確認し、その結果をブランドのサーバーに返します。ブランドのサーバーは受け取った結果をページに表示できるように処理し、個体を識別できた場合には、その商品の情報も結び付けて案内します。

サイトは、検証が終わってからページを表示することも、先に「確認中」と表示して結果を待つこともできます。どちらの場合も、今回の判定を受け取ってから結論を示します。結果を取得できない場合は「検証を完了できませんでした」と案内し、購入者が通信の不具合を偽物の証拠と受け取らないようにします。

「今回の読み取りは認証を通過したのか。手元にある商品の情報と一致しているか」。結果を表示する欄では、まずこの二つを確認できるようにします。API は読み取り情報を処理した後に判定を返し、取得できる場合には個体識別情報、受け付けられた検証の回数、封印情報も返します。タグを識別できない場合や検証を通過しなかった場合は、一部の情報が得られないこともあるため、その状態に合わせて表示します。

個体を識別する番号が得られれば、サイト側でブランドの記録と照合し、結果の横に商品写真や型番、使い方を配置できます。API が提供するのは検証に関する情報で、商品コンテンツはブランドが用意します。個体との対応が確認できていない場合に、掲載中の商品情報まで検証によって結び付けられたかのように表示してはいけません。

検証の回数は、BrandGuard が有効な検証として受け付け、記録した数です。購入者数や販売数ではありません。回数や検証時刻を表示する場合は、今回の応答で取得できたデータを使います。ページの再読み込み、同じ依頼の再送、過去の記録の参照は、実物のタグを新たに読み取ったことにはなりません。

購入者は商品を手に持ち、すでにブランドのサイトを訪れています。認証結果の横に、コレクション商品のシリーズ紹介やお手入れ方法を置いたり、部品の取り付け手順を案内したりできます。保証登録のサービスがあれば、そこへのリンクも用意できます。別のサイトを探したり、型番をもう一度検索したりする手間を減らせます。

こうした内容やサービスはブランドのサイトが用意し、その中で API の検証情報を活用します。ブランドらしいデザインを保ちながら、疑問がある購入者をサポートへ直接案内できます。保証の対象条件、購入証明の確認、会員特典は、引き続きブランド自身の業務ルールに沿って扱います。

BrandGuard は、商品や包装に適した安全な NFC タグを用意し、選んだ方式に合わせて各タグに安全に書き込みを行い、検証サービスを運用します。BrandGuard の結果ページを使う場合も、検証後にブランドのサイトへ案内する場合も、サイトから API で依頼する場合も、検証を担うのは BrandGuard です。タグの最初のアクセス先は、選んだ方式に合わせて準備します。

ここで紹介する API 接続では、サイトの担当者がサーバーからの検証依頼と応答の受信、結果の表示、商品情報との対応付けを実装します。既存のサイトも利用できます。静的なサイトには、開発担当者が同じドメインで動くサーバー処理を追加できます。一方、BrandGuard の結果ページを選ぶ場合は、自社サイトも、ブランド側での API 接続開発も必要ありません。

この検証で確認するのは、タグの暗号による認証情報と、登録された個体との対応です。商品そのものを検査するわけではありません。ブランド側では、正しい商品に正しいタグを取り付け、記録を正確に管理する必要があります。成分、品質、来歴について説明するには、それぞれを裏付ける証拠が必要です。

まず、購入者にどこで結果を確認してもらうか、サイトの開発や運用を担当する人がいるかを考えます。自社サイトがない場合や、用意済みの結果ページを使いたい場合は、BrandGuard のページを利用できます。既存の商品ページへ案内したい場合は、認証成功後にそのページへ移動する構成にできます。最初から自社のドメインで確認を始めたい場合は、Live Verification API を利用します。

Solution C では、この三つを C1、C2、C3 として案内しています。どの方法でもタグの検証は BrandGuard が行います。違うのは、最初のアクセス先、結果を確認する場所、そしてサイト側で必要な準備です。

横にスワイプして表全体をご覧ください

各タグは選んだ方式に合わせて書き込みます。サイトの設定を変えるだけでは、タグに書き込まれた最初のアクセス先は自動では変わりません。

C2 の移動先には、静的・動的のどちらの商品ページも利用でき、サイトの構成と移動先のアドレスに合わせて接続を設定します。そのページにも今回の認証結果を表示したい場合は、公式の認証コンポーネントを使います。WordPress や WooCommerce には公式プラグインもあります。リダイレクトでページを開くだけでは、そのページに認証情報は表示されません。

封印された商品の購入者は、包装がすでに開けられていないかも気になります。これは、タグが認証を通過するかとは別の確認です。正規のタグであっても、封印を破った後は、タグの認証を通過すると同時に開封や変化を報告する場合があります。

検証用環境での接続テストでは、Secure E 設定の NTAG® 424 DNA TT タグ一枚を、Android スマートフォンでその都度新たに三回読み取りました。最初の二回は開封の報告がなく、封印を破った後の三回目に開封が報告されました。受け付けられた検証の回数も 1、2、3 と進みました。このテストで、サイトからの検証依頼、判定の受信、封印の変化の表示を確認しています。確認した範囲は、そのタグ、スマートフォン、検証用環境での動作です。

サイトでは、タグの認証結果と、取得できた封印の状態を分けて表示します。そうすることで購入者は、包装を詳しく調べるか、ブランドに連絡するかを判断しやすくなります。通常の NTAG® 424 DNA には、DNA TT の電子的な開封検知機能はありません。購入者に包装状態も確認してもらいたい場合は、開封検知用の封印ラベルの取り付け位置と開封時の動作も、実物サンプルで試してください。

導入を検討する際は、サイトの URL、商品、購入者に見せたい情報を共有し、サイトの担当者にもご参加いただきます。BrandGuard と担当者でタグ、アクセスする順序、表示内容を決めた後、少量のサンプルで一連の流れを試します。

確認するのは、一回の読み取りが成功することだけではありません。タグを識別できない場合、一時的に結果を取得できない場合、ページを再訪問した場合、対応する封印を開けた場合も確かめます。結果が分かりやすく、表示情報が正しい個体に対応し、次の行動が明確であれば、購入者は何が確認できたのか、疑問があれば誰に相談すればよいのかを理解できます。