Admin GraphQL API / 2026-04

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

$app:example のような型を持つアプリ所有のメタオブジェクト(宣言的定義で作ったものを含む)を、所有アプリ自身が追加のアクセススコープ要求なしで読み書きできるようになった。インストール時の権限同意が一段シンプルに。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 仕組み図解 : スコープ判定が分岐する場所
  3. 「app-owned メタオブジェクト」とは
  4. 従来 vs 新仕様の比較
  5. 利用条件
  6. 境界線 : 何が対象で何が対象外か
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

アプリが自分で所有するメタオブジェクト($app:example のような型。宣言的定義で作ったものも含む)を読み書きするのに、これまで必要だった追加のアクセススコープが要らなくなった
開発者は余計なスコープ申請から解放され、マーチャント側の権限同意の摩擦も減る。

従来 : スコープ申請が必要

アプリ専用のデータでも、メタオブジェクト系のアクセススコープを要求しないと読み書きできなかった。インストール時の権限同意が増える。

新仕様 : スコープ不要

app-owned メタオブジェクトは、所有アプリ自身からなら追加スコープ無しで利用可能。2026-04 以降の Admin API を使うだけ。

2仕組み図解 : スコープ判定が分岐する場所

所有アプリ Admin API 2026-04+ 対象の メタオブジェクトは? $app:… app-owned スコープ不要で読み書き merchant 所有 merchant-owned read_metaobjects 等が必要 ※ 2026-04 未満の API では従来どおりスコープが要る
分岐の判定軸は 「誰がそのメタオブジェクトを所有しているか」。アプリ所有($app: 型)ならスコープ不要、マーチャント所有なら従来どおりスコープが必要。同じ「メタオブジェクト」でも所有者で扱いが変わる点がキモ。

3「app-owned メタオブジェクト」とは

$app:

$app: プレフィックスの型

型名が $app:example のように $app: で始まるメタオブジェクトが、アプリ所有として識別される。

宣言的定義も対象

declarative metaobject definitions(宣言的メタオブジェクト定義)で作成したものも、この対象に含まれる。

「所有アプリ自身」が利用

スコープ不要で使えるのは、そのメタオブジェクトを所有するアプリが利用する場合。

4従来 vs 新仕様の比較

項目従来新仕様(2026-04 以降)
app-owned($app:)の読み書き スコープ要 追加スコープの申請が必要 スコープ不要 所有アプリなら追加要求なし
宣言的メタオブジェクト定義 追加スコープを意識して採用 気にせず採用可
merchant-owned の読み書き read_metaobjects 等が必要 変わらず必要 従来どおりスコープ要
必要な API バージョン 2026-04 以降
マーチャント側の摩擦 権限同意の項目が増える 低減 余計なスコープ要求が消える

5利用条件

2026-04

Admin API 2026-04 以降

app-owned メタオブジェクトをスコープ無しで読み書きするには、Admin API バージョンが 2026-04 以降であることが条件。

対象は所有アプリによる利用

対象は $app: 型および宣言的定義で作られた、そのアプリ所有のメタオブジェクト。所有アプリ自身が利用するケースが前提。

既存アプリの移行手順(スコープ削除の具体的フローや再認可の要否)についての記載はなし。スコープを実際に外す際の挙動は、対象 API バージョンで事前に検証すること。

6境界線 : 何が対象で何が対象外か

スコープ不要

app-owned メタオブジェクト

$app:example のような型を持つ、アプリ所有のメタオブジェクト。宣言的メタオブジェクト定義で作成したものも含む。所有アプリが読み書きする限りスコープは要らない。

従来どおりスコープ要

merchant-owned メタオブジェクト型

マーチャント所有のメタオブジェクト型を扱う場合は、read_metaobjectswrite_metaobject_definitions などの個別スコープの付与が引き続き必要。

つまり 「アプリ専用のデータは app-owned に寄せればスコープ要求を消せる」が、「マーチャントのデータを触る部分はスコープが残る」。両者が混在するアプリでは、コードのどこが何を触っているかの切り分けが前提になる。

7技術者が押さえるべき5つのポイント

$app:

1. 対象は $app: 型のみ

スコープ不要になるのは $app: プレフィックスのアプリ所有メタオブジェクト。merchant-owned は対象外で、扱いは何も変わらない。

2026-04

2. API バージョンが分岐点

スコープ不要の挙動は 2026-04 以降で有効。古いバージョンに固定したままだと従来どおりスコープが要るので、まず version pin を確認。

3. 宣言的定義も含まれる

declarative metaobject definitions で作成したアプリ所有メタオブジェクトも対象。宣言的アプローチを採用する際、スコープ申請の心配が不要になる。

scope

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 に寄せればインストール時の権限要求を減らせる。
ただし マーチャント所有の型は従来どおりスコープが必要なので、混在箇所の切り分けだけは要注意。」