米国CPSC電子申告（eFiling）義務化に伴う越境EC事業者への影響について

2026年7月8日より、米国へ輸入される米国消費者製品安全委員会（CPSC）の規制対象製品に対し、電子申告（eFiling）が義務化されました。 主な規制対象商品は12歳以下の子ども向けの製品、および、自転車、バッテリー、ライター等です。 （詳細は下記の参考資料や後述のサイトでご確認をお勧めします。）

対象となる商品を米国へ発送する際、通関業者が米国税関システムへ「CPSCパートナー政府機関（PGA）メッセージセット」を送信できるよう、出荷のタイミングで必要なデータ項目を提供することが求められています。要件を満たさない場合、米国側での通関遅延や日本への返送などの影響が生じる可能性があります。これらの規制の内容と具体的な対応方法について整理します。

1. 課題（Situation / Task）

米国における規制要件の変更

これまでも、これらの対象製品に対して安全基準を満たしていることを証明する「適合証明書（CPCやGCC）」を作成・保管することは、2008年から法律で義務付けられており、十数年かけて法整備とシステムの実証実験を繰り返したうえで今回の規制が施行されました。 最近の突発的な関税政策などとは異なる文脈で進められてきた、米国における長期的な消費者保護とデジタル化政策によるものです。今回の規制変更の背景や目的は以下のようなものです。

従来の仕組み（事後チェック）の限界 これまでは、証明書はあくまで「手元で保管しておき、CPSCから提出を求められたらPDFなどで提出する」というバックオフィス的な要件でした。しかし、近年の越境ECの普及などにより輸入貨物が激増する中、このアナログな手法では、鉛を含んだおもちゃや発火リスクのある製品がチェックをすり抜けて米国内に入り込んでしまうケースが後を絶ちませんでした。

新しい仕組みの狙い：リアルタイムのリスク評価 対策として、CPSCは米国税関・国境警備局（CBP）の通関システム（ACE）と連携する「eFiling」を立ち上げました。 これにより、輸入業者が通関手続きをする際、事前に製品の安全証明データを電子的に送信させ、システム上でリアルタイムにリスク評価を行おうとしています。

ご参考： CPSC - eFiling Overview https://www.cpsc.gov/s3fs-public/eFiling-Overview-Presentation-April-2024.pdf CPSCが定期的にトレードコミュニティ（輸入業者や通関業者）向けに発表している公式のプレゼン資料。「なぜeFilingが必要なのか？（リアルタイムのデータ取得とプロセス合理化）」や「フェーズごとのアプローチ（2023年からのBeta Pilotなど）」が図解入りで解説されています。

CPSC Plan to Create an eFiling Program for Imported Consumer Products https://www.cpsc.gov/s3fs-public/CPSC-Plan-to-Create-an-eFiling-Program-for-Imported-Consumer-Products.pdf 「2008年の消費者製品安全改善法（CPSIA）に基づく12年間の経験から、危険な輸入消費財を国境で水際阻止（intercept）するためにeFilingプログラムが不可欠であると結論付けた」という、制度導入の根底にある問題意識と目的が記載されています。

2. 対応方針（Action）

具体的な対応策として、米国へ輸出を行う事業者へは以下のような対応が求められると考えられます。

ステップ1：対象商品の識別

取り扱い商品が規制対象か否かを確認し、規制対象に該当する場合はシステム上で判別・管理する仕組みが必要です。 まずはCPSCのオンライン判定ツール（Regulatory Robot）や、対象となるHTSコード（関税分類番号）リストを参照し、取り扱う商品が対象/非対象を判別します。

CPSC’s Regulatory Robot https://business.cpsc.gov/robot/

eFiling Document Library https://www.cpsc.gov/eFiling-Document-Library HTSコードがわかっている場合はこちらで検索が可能です。

ステップ2：API（PGA Message Set）の連携仕様の策定

該当商品が含まれる場合、データ提出方法は2つあり、「オプション1：CPSCプロダクトレジストリへの事前登録」「オプション2：完全なCPSCメッセージセットを通関業者へ提出する」となります。それぞれについて解説します。

オプション1：CPSCプロダクトレジストリへの事前登録

オプション1を利用するには、CPSCのシステムにアカウントを作成し、「Certifier ID（証明者ID）」を発行する必要があります。その後、発行された証明者IDに紐づけて対象となる製品の適合証明書（GCCまたはCPC）のデータを下記のポータルサイトから登録します。

CPSCのeFiling専用ポータルサイト https://efiling.saferproducts.gov/efiling/

尚、オプション1が利用できるケースは事実上、 米国の法人（BtoBの納品先）が存在するか、自社で輸入申告を行う場合（FBA納品など）に限られます。 BtoCの個人輸入のケースの場合、法律上の輸入者（責任者）は「米国の消費者（購入者）」となりますが、一般の消費者に米政府のシステムでアカウントを作らせ、発行された証明者IDに紐づけて対象となる製品の適合証明書（GCCまたはCPC）のデータをシステムに登録し、さらに取得したIDを日本のECサイトへ入力してもらうような運用は現実的に困難です。

オプション2：完全なCPSCメッセージセットを通関業者へ提出する

日本の輸出者が自社を「米国の証明者」として登録することができず、消費者が自ら申告できない場合、通関業者（FedEx等）が消費者に代わって電子申告を行うことになります。そのための元データとして、通関業者は出荷者である日本のEC事業者に対してデータ提供を必要とします。EC事業者は「各製品についての完全なCPSCメッセージセット（製造年月日、テスト機関など7項目のデータ）」を出荷API等経由して毎回電子的に送信することになります。

General Certificate of Conformity (GCC) https://www.cpsc.gov/General-Certificate-of-Conformity-GCC-OLD-1 7項目のデータについてCPSCが求める具体的なサンプルを確認できます。

ステップ3：API（PGA Message Set）の組み込み

APIを経由して米国税関（CBP ACEシステム）に送信される「PGA Message Set」の具体的なデータ仕様は、「オプション1（事前登録）」と「オプション2（毎回フル送信）」によって、APIのリクエストに含めるべきペイロード（データ項目）のボリュームが全く異なります。 FedEx APIの仕様において求められる、それぞれの具体的なデータ項目は以下の通りです。

パターンA：リファレンス・メッセージセット（オプション1：事前登録を利用する場合）

CPSCのプロダクトレジストリ（製品データベース）に事前に製品情報を登録している場合、APIで送信するデータは非常に軽量になります。

送信が必要な主要データ（識別子）は基本的に以下の2〜3項目のみです。

  1. Product ID（製品ID）
  • 事前の製品登録時に設定した一意の識別子（GTIN、UPC、SKU、モデル番号など）。
  1. Certifier ID（証明者ID）
  • CPSCアカウント作成時に発行される、輸入者または製造者を特定するための一意のID。
  1. Version ID（バージョンID）※オプション
  • 製品の仕様変更やテスト更新があった場合に、どのバージョンの証明データかを指定するためのID。

商品マスタに「CPSC対象フラグ」と「Product ID」を持たせておき、出荷APIを叩く際に固定の「Certifier ID」とセットにしてFedExのRegulatoryフィールドにマッピングするだけで要件を満たせます。

パターンB：フル・メッセージセット（オプション2：事前登録を利用しない場合）

事前登録を行わない場合、該当製品が含まれる出荷APIのリクエストのたびに、以下の7つの証明データ（GCC/CPCの構成要素）をすべて構造化データとしてFedEx APIに渡す必要があります。

  1. Product Identification（製品識別情報）
  • GTIN、UPC、SKUなど、製品を特定するコード。
  1. Citation Codes（引用コード）
  • その製品が適合しているCPSC安全基準の条項番号（複数ある場合は配列等で全て送信）。
  1. Manufacture Date and Place（製造年月と場所）
  • Manufacture Date: 製造された月と年（例: MM/YYYY）。
  • Manufacture Place: 製造された都市と国（工場等の所在地）。
  1. Test Date and Place（テスト実施年月と場所）
  • Product Test Date: 安全基準テストを実施した月と年。
  • Test Place: テストを実施した場所。
  1. Testing Laboratory（試験機関情報）
  • テストを実施した機関の名称、完全な住所、電話番号。
  1. Point of Contact（記録保持者の連絡先）
  • テスト結果の記録を保管している担当者の氏名、完全な住所、メールアドレス、電話番号。
  1. Identification of Certifier（証明者の情報）
  • 証明を行う輸入業者または国内製造業者の社名、完全な住所、電話番号。

具体的なJSONやXMLのスキーマ、配列のネスト構造、各フィールドの文字数制限（Max Length）や必須フラグ等の厳密なテクニカルリファレンスについては、FedEx Developer Portalにて提供されている最新のAPIリファレンスドキュメントをご参照ください。

CPSCのPGAフラグ（対象のHTSコード）に該当する商品を出荷する際、APIリクエスト内に上記のPGA Message Setが含まれていない場合、米国税関のシステム（ACE）から警告（Warning）が返却される、あるいはFedEx側でAPIリクエスト自体がエラーとなるように仕様が変更されている模様です。実装時のテスト環境での検証を入念に行うことをお勧めします。

組み込みに際しては「オプション1：CPSCプロダクトレジストリへの事前登録」のほうが圧倒的に工数が少ないですが、越境EC事業者のスキーム上オプション1が利用できないBtoCの多くのケースでは、「オプション2：完全なCPSCメッセージセットを通関業者へ提出する」ケースになるのではないかと予想されます。

3. 今後の展望と留意点（Result）

今回の米国CPSCの規制に伴うPGA連携のように、各国の税関・輸入に関する規制やシステム連携の要件は今後も変化していくことが予想されます。海外配送を支援するシステムとしては、特定の国の現行制度に対応するだけでなく、今後の制度変更や他国への展開を見据え、柔軟にマスタ項目やAPI仕様をアップデートできる設計を意識し、継続的に各国の動向を注視していく必要があるのではないでしょうか。