App-owned メタオブジェクトが アクセススコープ無しで使えるように

図解 ： App-owned メタオブジェクトがアクセススコープ無しで使えるように Admin GraphQL API / 2026-04 App-owned メタオブジェクトが アクセススコープ無しで使えるように $app:example のような型を持つアプリ所有のメタオブジェクト（宣言的定義で作ったものを含む）を、所有アプリ自身が追加のアクセススコープ要求なしで読み書きできるようになった。インストール時の権限同意が一段シンプルに。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： スコープ判定が分岐する場所 「app-owned メタオブジェクト」とは 従来 vs 新仕様の比較 利用条件 境界線 ： 何が対象で何が対象外か 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか アプリが自分で所有するメタオブジェクト（ $app:example のような型。宣言的定義で作ったものも含む）を読み書きするのに、 これまで必要だった追加のアクセススコープが要らなくなった 。 開発者は余計なスコープ申請から解放され、マーチャント側の権限同意の摩擦も減る。 従来 ： スコープ申請が必要 アプリ専用のデータでも、メタオブジェクト系のアクセススコープを要求しないと読み書きできなかった。インストール時の権限同意が増える。 新仕様 ： スコープ不要 app-owned メタオブジェクトは、所有アプリ自身からなら追加スコープ無しで利用可能。 2026-04 以降の Admin API を使うだけ。 2 仕組み図解 ： スコープ判定が分岐する場所 分岐の判定軸は 「誰がそのメタオブジェクトを所有しているか」 。アプリ所有（ $app: 型）ならスコープ不要、マーチャント所有なら従来どおりスコープが必要。同じ「メタオブジェクト」でも所有者で扱いが変わる点がキモ。 3 「app-owned メタオブジェクト」とは $app: プレフィックスの型 型名が $app:example のように $app: で始まるメタオブジェクトが、アプリ所有として識別される。 宣言的定義も対象 declarative metaobject definitions（宣言的メタオブジェクト定義）で作成したものも、この対象に含まれる。 「所有アプリ自身」が利用 スコープ不要で使えるのは、そのメタオブジェクトを所有するアプリが利用する場合。 4 従来 vs 新仕様の比較 項目 従来 新仕様（2026-04 以降） app-owned（ $app: ）の読み書き スコープ要 追加スコープの申請が必要 スコープ不要 所有アプリなら追加要求なし 宣言的メタオブジェクト定義 追加スコープを意識して採用 気にせず採用可 merchant-owned の読み書き read_metaobjects 等が必要 変わらず必要 従来どおりスコープ要 必要な API バージョン — 2026-04 以降 マーチャント側の摩擦 権限同意の項目が増える 低減 余計なスコープ要求が消える 5 利用条件 Admin API 2026-04 以降 app-owned メタオブジェクトをスコープ無しで読み書きするには、Admin API バージョンが 2026-04 以降であることが条件。 対象は所有アプリによる利用 対象は $app: 型および宣言的定義で作られた、そのアプリ所有のメタオブジェクト。所有アプリ自身が利用するケースが前提。 既存アプリの移行手順（スコープ削除の具体的フローや再認可の要否）についての記載はなし。スコープを実際に外す際の挙動は、対象 API バージョンで事前に検証すること。 6 境界線 ： 何が対象で何が対象外か スコープ不要 app-owned メタオブジェクト $app:example のような型を持つ、アプリ所有のメタオブジェクト。宣言的メタオブジェクト定義で作成したものも含む。所有アプリが読み書きする限りスコープは要らない。 従来どおりスコープ要 merchant-owned メタオブジェクト型 マーチャント所有のメタオブジェクト型を扱う場合は、 read_metaobjects や write_metaobject_definitions などの個別スコープの付与が引き続き必要。 つまり 「アプリ専用のデータは app-owned に寄せればスコープ要求を消せる」 が、 「マーチャントのデータを触る部分はスコープが残る」 。両者が混在するアプリでは、コードのどこが何を触っているかの切り分けが前提になる。 7 技術者が押さえるべき5つのポイント 1. 対象は $app: 型のみ スコープ不要になるのは $app: プレフィックスのアプリ所有メタオブジェクト。merchant-owned は対象外で、扱いは何も変わらない。 2. API バージョンが分岐点 スコープ不要の挙動は 2026-04 以降で有効。古いバージョンに固定したままだと従来どおりスコープが要るので、まず version pin を確認。 3. 宣言的定義も含まれる declarative metaobject definitions で作成したアプリ所有メタオブジェクトも対象。宣言的アプローチを採用する際、スコープ申請の心配が不要になる。 4. merchant データはスコープ継続 read_metaobjects / write_metaobject_definitions 等は merchant-owned 型を触る限り必要。app-owned と混在する箇所を取り違えない。 5. インストール時の権限同意を減らせる ＝ 設計の見直し余地 アプリ専用の状態・設定を app-owned メタオブジェクトに寄せれば、要求スコープの数そのものを減らせる。ただし移行の具体手順（既存スコープの外し方・再認可の要否）の明記はないので、削除前にサンドボックスで検証するのが安全。 8 業務に活かせる3つのユースケース USE CASE 1 アプリのインストール摩擦を下げ、導入率を上げる 課題 アプリが設定・状態の保存にメタオブジェクトを使うため metaobject 系スコープを要求しており、インストール時の権限同意画面が重く、離脱の一因になっている。 打ち手 アプリ専用データを $app: 型の app-owned メタオブジェクトに寄せ、Admin API を 2026-04 以降に上げて、該当する追加スコープ要求を外す。 効果 権限同意項目が減り、インストール完了率の改善が見込める。マーチャント側の不安も軽減。 技術メモ merchant-owned 型を触る箇所は別途スコープが残る。app-owned に閉じたデータだけが対象。 USE CASE 2 宣言的メタオブジェクト定義で新規アプリを素早く立ち上げる 課題 アプリ独自のデータモデルを宣言的に定義したいが、追加スコープの申請・管理が新規開発の足かせになりそう。 打ち手 declarative metaobject definitions で app-owned のデータモデルを定義し、最初から 2026-04 以降の API で構築する。 効果 スコープ申請・再同意フローを前提にしないので設計がシンプルになり、リリースまでの工程が短縮できる。 技術メモ 宣言的定義で作ったものもスコープ不要の対象に含まれる。型は $app: 前提で設計する。 USE CASE 3 既存アプリのスコープ棚卸しと最小権限化 課題 既存アプリが read_metaobjects 等を要求しているが、実際にはアプリ所有データしか触っていない可能性があり、過剰な権限を保持している。 打ち手 コードを監査し、app-owned だけを触っている箇所を特定 → API を 2026-04 以降へ → 不要になった追加スコープ要求を削減する。 効果 最小権限の原則に沿った構成になり、アプリ審査やセキュリティ面で有利。マーチャントへの説明もしやすい。 技術メモ merchant-owned 型を触る経路が1つでも残ればそのスコープは外せない。削除前に対象 API バージョンで挙動を検証する。 9 提案で使える1行サマリ 「アプリ所有（ $app: 型・宣言的定義含む）のメタオブジェクトは、 Admin API 2026-04 以降なら追加スコープ無しで読み書きできる 。 アプリ専用データを app-owned に寄せればインストール時の権限要求を減らせる。 ただし マーチャント所有の型は従来どおりスコープが必要 なので、混在箇所の切り分けだけは要注意。」 source ： shopify.dev / changelog / metaobject-scopes-not-required-for-app-metaobjects 公開日 2026-04-30 ／ Developer Changelog