商品の「開示事項」フィールド 警告表示を商品説明文に埋め込む時代の終わり

図解 ： Shopify 商品の「開示事項（Disclosures）」フィールド Products / 新機能 商品の「開示事項」フィールド 警告表示を商品説明文に埋め込む時代の終わり Prop 65 や窒息ハザードなどの法定・任意の注意書きを、商品説明やテーマのコードに紛れ込ませず、Shopify 管理画面の専用フィールドに構造化データ（メタフィールド）として登録できるようになった。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： 入力から表示までの流れ 用意されている開示タイプ 従来 vs 新フィールドの比較 テーマ対応とフォールバック 使い始める3ステップ 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか 今までは Prop 65 警告などの注意書きを 商品説明文・テーマコード・独自の回避策 に埋め込んで保存していた。 これからは、Shopify 管理画面の 専用「開示事項（disclosures）」フィールド に構造化データとして直接登録できる。 従来 ： 説明文やコードに混在 警告を商品説明・テーマのコード・カスタムの回避策に書き込んで保存。データとして扱えず、再利用も検索もしにくい。 新方式 ： 専用フィールドに構造化 商品メタフィールドとして保存。タイプ付き（Prop 65・窒息ハザード・カスタム）で管理でき、対応テーマなら専用セクションに自動表示。 2 仕組み図解 ： 入力から表示までの流れ ポイント ： データ（メタフィールド）と表示（テーマ）が分離されている。対応テーマなら入力するだけで「Disclosures」セクションに出る。非対応テーマ・カスタムストアフロントでも、メタフィールドにアクセスして自前で描画できる。 3 用意されている開示タイプ 組み込み California Prop 65 警告 カリフォルニア州プロポジション65に基づく警告表示。専用のタイプとして用意されている。 組み込み 窒息ハザード（Choking-hazard） 小さな部品など、窒息の危険に関する注意表示。こちらも組み込みタイプとして選べる。 カスタム カスタム開示タイプ 上記以外の商品固有の警告・告知を、独自タイプとして自由に追加できる。 責任の所在 ： どの開示が必要か、どんな内容を記載するかの判断は マーチャント自身の責任 。Shopify は入れ物（フィールド）を提供するだけで、要否や文面の正しさは保証しない。 4 従来 vs 新フィールドの比較 項目 従来（回避策） 開示事項フィールド 保存先 混在 商品説明文・テーマコード・独自策 専用 商品メタフィールド データ構造 非構造（自由テキストに埋没） 構造化 タイプ付きで管理 定型タイプ 手作り Prop 65・窒息ハザードを組み込み提供 表示 テーマを都度改修 対応テーマなら「Disclosures」セクションに自動表示 再利用・参照 難しい メタフィールド経由で API・カスタムフロントから参照可 5 テーマ対応とフォールバック 対応 Online Store テーマ 開示事項を入力すると、商品詳細ページに新しい「Disclosures」セクションとして自動で表示される。テーマ側の追加実装は不要。 非対応テーマ・カスタムストアフロント 開示のメタフィールドにアクセスして、自分でレンダリングする必要がある。データはあるので、描画ロジックだけ用意すればよい。 データの入れ方は共通。 表示方法だけがテーマの対応状況で分岐 する。まず管理画面に入れておけば、後でテーマを対応版に替えるだけで表示が有効になる。 6 使い始める3ステップ 1 商品を開く Shopify 管理画面で対象の商品ページを開く。 2 開示タイプを選ぶ Prop 65・窒息ハザード、または独自のカスタムタイプを選択。 3 内容を入力して保存 注意書きの本文を入力。対応テーマなら商品ページに自動で出る。 具体的な設定画面の場所や操作手順の詳細は Shopify ヘルプセンター の該当ガイドに記載。本記事の本文には画面ごとの詳細手順までは記載なし。 7 技術者が押さえるべき5つのポイント 1. 実体は商品メタフィールド 開示事項は商品メタフィールドとして保存される。つまり Admin API / Storefront API 経由で参照・取得できる前提で設計できる。 2. 組み込み型とカスタム型の二系統 Prop 65・窒息ハザードは組み込みタイプ、それ以外はカスタムタイプ。要件に応じて型を使い分ける設計になる。 3. データと表示が分離 対応テーマは自動描画、非対応・カスタムフロントは手動描画。表示ロジックを自前で持つかどうかでフロントの実装方針が分かれる。 4. 要否判断はマーチャント責任 どの開示が必要か・文面が適切かの判断は出店者側。システムは検証しないため、運用ルールやレビュー体制を別途設計する必要がある。 5. 既存の「説明文埋め込み」からの移行余地 これまで商品説明文やテーマコードに警告を書いていたストアは、その内容を専用フィールドへ移し替えることで構造化できる。 移行時は重複表示（説明文と Disclosures セクションの二重掲載）に注意 し、旧記述の撤去とセットで進めるのが安全。具体的な API のフィールド名・スキーマは本記事に記載なしのため、ヘルプセンター／API ドキュメントで確認すること。 8 業務に活かせる3つのユースケース USE CASE 1 米国向け販売の Prop 65 警告を「商品データ」として一元管理 課題 カリフォルニア州 Prop 65 の警告を、これまで商品説明文の末尾やテーマの一部に手書きしており、対象商品の抜け漏れ・表記ゆれが起きやすい。 打ち手 組み込みの Prop 65 開示タイプに移行し、対象商品にフィールドとして登録。対応テーマなら Disclosures セクションに統一表示。 効果 警告の管理を商品データに集約し、表記の一貫性と抜け漏れチェックのしやすさを確保。 技術メモ メタフィールド化されるため、対象商品の一覧抽出や棚卸しを API 経由で行える設計が可能。 USE CASE 2 玩具・食品・化粧品など「商品固有の注意書き」をカスタムタイプで標準化 課題 窒息ハザード、アレルゲン、使用上の注意など、カテゴリ別に必要な注意書きがバラバラに記述され、ブランド横断で統一しづらい。 打ち手 窒息ハザードは組み込みタイプ、その他はカスタム開示タイプを定義してカテゴリ単位で運用ルール化。 効果 注意書きの「型」を社内で標準化でき、新商品登録時の入力ガイドラインとして機能する。 技術メモ カスタムタイプの命名・粒度を最初に設計しておくと、後からの集計やフロント表示の出し分けが楽になる。 USE CASE 3 ヘッドレス／カスタムストアフロントでの開示表示を実装 課題 Hydrogen 等のカスタムストアフロントや非対応テーマで、商品ごとの法定・任意の注意書きを一貫して出したい。 打ち手 開示メタフィールドを取得し、商品詳細ページに専用の Disclosures コンポーネントとして自前でレンダリング。 効果 データ入力は管理画面に集約しつつ、表示はフロントのデザインに合わせて完全制御できる。 技術メモ 表示はマーチャント／開発側の実装責任。具体的なメタフィールドの参照名は本記事に記載なしのため、API ドキュメントで確認のうえ実装する。 9 提案で使える1行サマリ 「Prop 65 や窒息ハザードなどの注意書きを、説明文やテーマコードへの埋め込みから卒業し、 商品メタフィールドの専用『開示事項』フィールドに構造化して一元管理。 対応テーマなら自動表示、カスタムフロントは API 参照で自前描画。要否と文面の判断はマーチャント責任。」 source ： changelog.shopify.com / product-listings-now-support-a-disclosures-field generated 2026-06-22