GS1の新標準「TDS 2.3.0」とWeb対応RFIDとは
RFIDは、「現場でモノを一括・高速に読み取れる」点が最大の魅力です。一方で、サプライチェーン全体で使おうとすると、 「読めたEPC（ID）を、どのシステムの、どのデータに結びつければ良いのか？」がボトルネックになりがちです。
そこで登場したのが、GS1のEPC Tag Data Standard（TDS）2.3.0（Release 2.3、2025年10月 Ratified）で追加されたWeb対応（web-resolvable）EPCの考え方です。 RFIDタグの中に、IDだけでなく“Webの行き先（ドメイン名）”も持たせられるようになり、読み取った情報をGS1 Digital Linkを介してURLへ変換しやすくなります。
何が変わった？：EPCに「ドメイン名」を入れられる“++”スキーム
TDS 2.3.0では、従来のEPCスキームを拡張した「++（ダブルプラス）」スキームが公式EPCスキームとして追加されました。 代表例としてSGTIN++ / DSGTIN++があり、既存の「+」スキームをベースにしつつ、シリアル番号の後ろに“カスタムドメイン名”をバイナリで格納できるように拡張されています。
ポイント： TDS 2.3.0では、RFIDタグのEPCエンコード自体に“ドメイン名”を含められる枠組み（“++”スキーム）が標準として規定されました。 その上で、読み取り結果をGS1 Digital Link（URL形式）と組み合わせて運用すれば、RFIDが「現場の識別」だけでなく「Webサービスへの入口」としても機能しやすくなります。 ※「URLへの変換」「Webサービスへの入口化」自体はTDS 2.3.0の標準仕様が直接定義する機能ではなく、Digital Link／リゾルバ／自社実装と組み合わせた活用シナリオとして位置付けられます。
GS1 Digital Linkとの関係
GS1 Digital Linkは、GTIN（JANコード）などのGS1識別コードをURL形式（GS1 Digital Link URI）で表し、 そこから商品情報ページ、取扱説明書、トレーサビリティ情報などの関連する情報・サービスへ誘導するための標準です（Digital Link自体はTDSとは別の独立した標準）。 なお、Digital Link URI自体は「サービスのURL」ではなく、必要に応じてリゾルバ（解決サービス）がリダイレクトすることで、 利用者（消費者/取引先/現場）に合わせて行き先を切り替えられます。TDS 2.3.0の“++”スキームは、このDigital Link運用と組み合わせやすい形でEPCエンコードを拡張しています。
なぜ重要？：「データの取りに行き先」が決まると、共有が一気に楽になる
サプライチェーンでは、荷主・製造・3PL・卸・小売など複数の当事者が関わります。 しかし現実には、「どこにデータがあるのか分からない」「相手のシステムに入りづらい」ことが多く、 せっかくRFIDで“読める”ようになっても、データ共有が進まないケースがあります。
| 観点 | 従来（ID中心） | TDS 2.3.0（Web対応） |
|---|---|---|
| 読み取れるもの | EPC（識別子） | EPC（識別子）＋ドメイン（行き先の手がかり） |
| 次のアクション | システム側で“どのDB/どのAPIか”を個別設計 | URLとして解決しやすく、外部共有の導線を作りやすい |
| データ共有 | 関係者ごとの接続・取り決めが増えがち | 「まずここへ問い合わせる」が明確になりやすい |
| 現場導入 | RFIDは導入済でもデータ連携が停滞しやすい | 軽量な参照（問い合わせ）からスモールスタートしやすい |
活用シナリオ①：物流単位（パレット・ケース・リターナブル容器）でのWeb参照
TDS 2.3.0の“++”スキームは「個品」でも活用できますが、まず効果が見えやすい活用シナリオとしてよく取り上げられるのが「物流単位」（パレット・ケース・リターナブル容器など）です。 例えば、パレットやケースのEPCに自社ドメインを含めて運用すると、Digital Link／自社リゾルバと組み合わせることで、 受領・検品・仕分け・保管・出荷の各地点で「この物流単位の正体は何で、今どんな状態か」を取得しやすくなります。
「問い合わせ先」が一目で分かると、連携が回り出す
読取地点（ドックドア、ゲート、仕分けレーンなど）でRFIDを読み取ったときに、 「このIDに紐づく情報は、どのドメイン（どの窓口）へ問い合わせれば良いか」が明確だと、 関係者が増えても「情報の置き場所」が迷子になりにくくなります。
活用シナリオ②：盗難・誤出荷・不正流通対策の照合用途
物流・小売では、盗難だけでなく、誤出荷や不正な持ち出しなど「正しい流れから外れる動き」を減らすことが重要です。 Web対応RFIDをこれらの用途に活かす場合、TDS 2.3.0の“++”スキームと自社の照合基盤を組み合わせて、 物流単位や商品群の移動を“自動的に記録・参照しやすくする”ことで、抑止・早期検知・事後の照合といった実務を支える設計が考えられます。
- 輸送中・倉庫内：ゲート読取のログを“追跡のパンくず”として活用しやすい
- 店頭以降：未購入のまま持ち出された可能性がある場合に、シリアル単位で照合しやすい
- 回収局面：押収・回収した物品の出所確認を迅速化できる
活用シナリオ③：DPP（デジタルプロダクトパスポート）・トレーサビリティ要件への接続
EUで議論・整備が進むDPPは、製品のライフサイクル情報（原材料、製造、修理、リサイクルなど）を、 標準化された形で参照できるようにする考え方です。TDS 2.3.0自体はDPPを直接規定する標準ではありませんが、 EPCに“ドメイン名”を含められる“++”スキームと、Digital Link／リゾルバを組み合わせることで、 DPPのような「製品ごとに参照先がある」前提の要件と接続しやすいRFID基盤を作れる選択肢が広がります。
さらに、食品分野では各国規制や業界要請により、トレーサビリティの高度化が求められています。 RFIDと、共有可能な参照先（Web）を組み合わせることで、取引先や監督当局への情報提供を効率化できる余地があります。 ※DPP対応・トレーサビリティ高度化はTDS 2.3.0が直接保証する機能ではなく、Web対応EPCを起点に組み立てる活用シナリオです。
導入の考え方：今から準備したい5ステップ
-
対象を決める（個品か、物流単位か）
まずはパレット・ケース・リターナブル容器など、効果が出やすい対象から検討します。 -
ID体系を決める（例：SSCC / SGTIN など）
GS1識別コードのどれを主キーにするかを決め、既存の運用（ラベル、EDI、WMS/ERP）と整合させます。 -
ドメイン/リゾルバ設計（“問い合わせ先”を作る）
自社ドメインで運用するか、パートナーと共同で運用するかを決めます。リゾルバで行き先を切り替える設計も重要です。 -
タグの書き込み（コミッショニング）とデータ連携
エンコード仕様（TDS 2.3.0の“++”）に沿ってタグに書き込み、読取データをどのAPI/DBに接続するかを整理します。 -
運用・権限・セキュリティ
すべてを公開する必要はありません。取引先向け/社内向け/消費者向けで表示を分ける、認証を入れる、ログを取るなどの運用が必要です。
シェン・ヒーローが支援できること
シェン・ヒーローは、RFIDリーダー/アンテナ/タグ選定から、現場要件に合わせたシステム設計・PoCまで支援しています。 TDS 2.3.0のような新標準は「仕様理解」と「現場実装」の間にギャップが生まれやすいため、 現場導線（どこで読むか）→ID設計→データ連携→運用を一気通貫で整理することが重要です。
まとめ
TDS 2.3.0（Release 2.3、2025年10月 Ratified）では、EPCに“ドメイン名”を含められる“++”スキームが公式EPCスキームとして追加されました。 これにより、RFIDを「現場で読む」だけでなく「Webへつなぐ」ことを前提とした設計が組みやすくなります。 ただし、物流単位のWeb参照、盗難照合、DPP対応などは標準仕様そのものが直接定義する機能ではなく、Digital Link／リゾルバ／自社実装と組み合わせて成立する活用シナリオです。 重要なのは、タグやリーダーだけでなく、“問い合わせ先（ドメイン/リゾルバ）”と、共有するデータ設計をセットで考えることです。
