メタフィールド宣言に owner_type を追加 2027-01 からは書いていないとデプロイ不可

図解 ： Checkout / Customer Account UI 拡張のメタフィールド宣言に owner_type が追加、2027-01 から必須 Developer / UI Extensions / 破壊的変更予告 メタフィールド宣言に owner_type を追加 2027-01 からは書いていないとデプロイ不可 Checkout と Customer Account の UI 拡張で、 shopify.extension.toml のメタフィールド宣言に「どのリソースのメタフィールドか」を書けるようになった。2026-10 では任意、2027-01 以降は必須。Shopify は必要なリソース分だけ取得するので拡張のパフォーマンスが上がる。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： owner_type で取得範囲が絞られる タイムライン ： 2026-10 は任意、2027-01 は必須 影響を受ける拡張／受けない拡張 記述イメージと同一 namespace/key の扱い 移行手順（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまでのメタフィールド宣言は namespace と key だけ で、どのリソース（商品？顧客？）のものかは書いていなかった。 今回 owner_type プロパティ が追加され、「このメタフィールドの持ち主はどのリソースか」を宣言できるようになる。 API バージョン 2027-01 からは必須 。 これまで ： 持ち主の指定なし メタフィールド宣言は namespace / key で指定。どのリソース種別のものかは宣言に含まれていなかった。 これから ： owner_type で持ち主を明示 PRODUCT や CUSTOMER のように持ち主を宣言。Shopify は拡張が必要とするリソース種別のメタフィールドだけを取得する。 2 仕組み図解 ： owner_type で取得範囲が絞られる 記事にある狙いは 「拡張が必要とするリソース種別のメタフィールドだけを取得し、拡張のパフォーマンスを上げること」 。どれだけ速くなるかの数値は記載なし。 3 タイムライン ： 2026-10 は任意、2027-01 は必須 メタフィールド宣言が 1 つでも owner_type を欠いていると、2027-01 以降ではデプロイ自体がブロックされる 。アップグレード前に全宣言へ追加しておくこと。2026-10 の時点で先に入れておける。 4 影響を受ける拡張／受けない拡張 条件 影響 補足 Checkout UI 拡張 で、toml にメタフィールドを宣言し、API 2027-01 以降を使う 影響あり 全宣言に owner_type が必要 Customer Account UI 拡張 で、toml にメタフィールドを宣言し、API 2027-01 以降を使う 影響あり 全宣言に owner_type が必要 上記拡張で API 2026-10 を使う 任意 指定可能。先行対応の推奨タイミング toml にメタフィールドを宣言していない拡張 影響なし 対応不要 対象のセクション 1 [[extensions.metafields]] 拡張全体レベルのメタフィールド宣言。owner_type プロパティを受け付ける。 対象のセクション 2 [[extensions.targeting.metafields]] ターゲット単位のメタフィールド宣言。こちらも owner_type プロパティを受け付ける。 5 記述イメージと同一 namespace/key の扱い 以下は記事の説明をもとにした記述イメージ。namespace / key の値は説明用。owner_type の取り得る値は記事中では PRODUCT ・ CUSTOMER が例として挙がっているのみで、全一覧は記載なし（関連ドキュメント参照）。 2027-01 ではブロック [[extensions.metafields]] namespace = "custom" key = "example" # owner_type が無い OK [[extensions.metafields]] namespace = "custom" key = "example" owner_type = "PRODUCT" 同じ namespace / key を複数リソースから読みたい場合 [[extensions.metafields]] namespace = "custom" key = "example" owner_type = "PRODUCT" [[extensions.metafields]] namespace = "custom" key = "example" owner_type = "CUSTOMER" 6 移行手順（3ステップ） 1 toml に owner_type を追加 拡張の shopify.extension.toml を開き、各メタフィールド宣言に適切な owner_type を書き足す。 2 複数リソースなら宣言を分割 同じ namespace / key を複数のリソース種別から使う場合は、owner_type ごとに別の宣言を作る。 3 再デプロイして確認 拡張を再デプロイし、メタフィールド宣言に関するバリデーションエラーが出ずに完了することを確認。 2026-10 のうちに追加しておけば、2027-01 へのアップグレードと切り離して対応できる 。API バージョンを上げる作業とメタフィールド宣言の修正を同時にやらずに済む。 7 技術者が押さえるべき5つのポイント 1. 警告ではなくデプロイブロック 2027-01 以降、owner_type が 1 つでも欠けていればデプロイが通らない。CI/CD で拡張をデプロイしている場合はパイプラインが止まる前提で備える。 2. 2 か所の宣言セクションが対象 [[extensions.metafields]] と [[extensions.targeting.metafields]] の両方。ターゲット側の宣言の追加漏れに注意。 3. 1 宣言 = 1 owner_type 同じ namespace / key でも複数リソースから読むなら宣言を分ける。既存宣言が実際どのリソースのデータを読んでいるかの棚卸しが前提になる。 4. 目的はパフォーマンス Shopify が必要なリソース種別のメタフィールドだけを取得するための情報。owner_type を正しく書くことが、そのまま拡張の取得量を絞ることにつながる。 5. 値の全一覧・ランタイム挙動は記事に記載なし 記事で例示されている owner_type は PRODUCT と CUSTOMER のみ。指定可能な値の全一覧や、owner_type を間違えた場合に拡張側でどう値が返るかは記載なし。関連ドキュメント「Configure metafields for Checkout UI extensions」「Configure metafields for Customer Account UI extensions」で確認すること。 8 業務に活かせる3つのユースケース USE CASE 1 受託・保守中の UI 拡張の一斉棚卸しと先行対応 課題 複数クライアントの Checkout / Customer Account UI 拡張を保守していて、2027-01 に上げた瞬間にデプロイが止まる拡張がどれか把握できていない。 打ち手 全リポジトリの shopify.extension.toml からメタフィールド宣言を洗い出し、2026-10 のうちに owner_type を追加して再デプロイ。 効果 2027-01 へのアップグレード時のデプロイブロックを未然に防ぎ、API 更新作業を計画どおりに進められる。 技術メモ メタフィールドを宣言していない拡張は影響なしなので、まず宣言の有無で対象を絞り込むと工数が読める。 USE CASE 2 CI/CD パイプラインでの「デプロイ停止」リスク回避 課題 拡張を CI から自動デプロイしており、API バージョン更新の PR がマージされた後にデプロイが失敗して本番反映が止まるリスクがある。 打ち手 API バージョンを 2027-01 に上げる PR とは別に、先に owner_type 追加だけの PR を 2026-10 でデプロイしておく。 効果 変更を 2 段階に分けることで、デプロイ失敗時の原因切り分けが容易になり、リリース停止を避けられる。 技術メモ 再デプロイ後に「メタフィールド宣言に関するバリデーションエラーが出ないこと」を確認するのが記事上の完了条件。 USE CASE 3 メタフィールド依存の重い拡張の見直し 課題 商品・顧客などのメタフィールドを多数参照する拡張があり、どのリソースのデータを本当に使っているかが曖昧になっている。 打ち手 owner_type 追加の機会に、各宣言が参照するリソース種別を明確化し、不要な宣言を整理する。 効果 Shopify が必要なリソース種別だけを取得するようになり、拡張のパフォーマンス向上につながる（向上幅は記載なし）。 技術メモ 同一 namespace / key を複数リソースで使っている箇所は宣言分割が必要。棚卸し時に一緒に洗い出す。 9 提案で使える1行サマリ 「Checkout / Customer Account UI 拡張のメタフィールド宣言に、持ち主を示す owner_type が追加。 2026-10 から指定でき、2027-01 からは欠けているとデプロイ不可。 今のうちに toml へ追記して再デプロイしておけば、拡張は軽くなり、アップグレードも止まらない。」 source ： shopify.dev/changelog / metafield-owner-types-required-for-checkout-and-customer-account-ui-extensions published 2026-10-08