Partner アプリの Bulk Operations は 「事前に許可した場合だけ」実行できるように

図解 ： Partner アプリは Bulk Operations を事前に有効化しないと使えなくなった GraphQL Admin API / 仕様変更 Partner アプリの Bulk Operations は 「事前に許可した場合だけ」実行できるように bulk クエリと bulk ミューテーションは、それぞれ Partner Dashboard でアクセスを有効化しないと access denied エラーになる。全 API バージョンが対象。直近 31 日使っていない種類はアクセスを失う。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： bulk operation が実行されるまで bulk クエリと bulk ミューテーションは別々に許可 影響を受けるアプリ／受けないアプリ 既存アプリの扱いと「31日ルール」 有効化の手順（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまでは GraphQL Admin API の bulk operations をどのアプリでもそのまま呼べた。 今日からは Partner Dashboard で「bulk operations へのアクセス」を有効化したアプリだけ が bulk クエリ／bulk ミューテーションを実行できる。 これまで ： 呼べば動く bulk operation を始めるのに、Partner Dashboard 側での事前許可は不要だった。 これから ： 事前許可が必要 bulk クエリ・bulk ミューテーションそれぞれにアクセスが必要。無いまま開始すると access denied エラー。 2 仕組み図解 ： bulk operation が実行されるまで アクセスは アプリ単位 で付与され、そのアプリをインストールしている すべてのストア に適用される。ストアごとの設定は不要。 エラーの具体的なエラーコード・レスポンス形式は記事に記載なし。 3 bulk クエリと bulk ミューテーションは別々に許可 読み取り系 bulk クエリ bulkOperationRunQuery を実行するには bulk クエリへのアクセス が必要。 Partner Dashboard のボタン名 ： 「Allow bulk queries」 書き込み系 bulk ミューテーション bulkOperationRunMutation を実行するには bulk ミューテーションへのアクセス が必要。 Partner Dashboard のボタン名 ： 「Allow bulk mutations」 片方だけ有効でも、もう片方は使えない。 アプリが実際に使う操作種別すべて を有効化しておく必要がある。 4 影響を受けるアプリ／受けないアプリ 対象 Public アプリ Partner として開発し、bulk operations を実行する公開アプリ。 対象 Partner が作る Custom アプリ Partner として開発し、bulk operations を実行するカスタムアプリ。 現時点で対象外 マーチャントが作るアプリ Shopify 管理画面や Dev Dashboard でマーチャントが作成したアプリ。「現時点では」影響なし。 項目 内容 対象 API GraphQL Admin API（bulk クエリ／bulk ミューテーション） 対象 API バージョン 全バージョン 古いバージョンに固定していても対象 開始時期 公開日（2026-11-06）当日から 未許可時の挙動 access denied エラー アクセスの適用範囲 アプリをインストールしている全ストア 5 既存アプリの扱いと「31日ルール」 すでに bulk を使っているアプリ Shopify 側でアクセスを有効化済み。Partner Dashboard で状態を確認できる。 31 日以上使っていない操作種別 直近 31 日に bulk クエリ／bulk ミューテーションを実行していないアプリは、その操作種別へのアクセスを失う。再度有効化すれば戻せる。 6 有効化の手順（3ステップ） 1 Apps からアプリを選択 Partner Dashboard の「Apps」を開き、対象アプリを選ぶ。 2 「API access requests」をクリック サイドバーにあるメニューから開く。 3 「Run bulk operations」で許可 「Allow bulk queries」「Allow bulk mutations」の必要な方（または両方）をクリック。 アプリ設定の変更・新バージョンのリリース・マーチャントへの再インストール依頼は不要。 すでに有効な操作種別は、そのセクションに「有効」と表示される。 7 技術者が押さえるべき5つのポイント 1. Query と Mutation は別権限 bulkOperationRunQuery と bulkOperationRunMutation で必要なアクセスが分かれる。コードベースでどちらを呼んでいるか棚卸しする。 2. API バージョン固定では回避できない 要件は GraphQL Admin API の全バージョンに適用。古いバージョンを使っていても同じく access denied になる。 3. 低頻度ジョブは「休眠失効」に注意 直近 31 日未使用の操作種別はアクセスを失う。月次・四半期の移行バッチなど、たまにしか走らない処理は実行前に Partner Dashboard で状態確認が必要。 4. エラーハンドリングを明示的に 未許可だとリクエストが access denied で返る。エラーの具体的なコードや形式は記事に記載なしのため、ログ・アラートで bulk 開始失敗を検知できるようにしておく。 5. 対応はダッシュボード操作だけで完結 アプリ設定の変更・新バージョンリリース・マーチャントの再インストールは不要で、許可はインストール済みの全ストアに効く。 デプロイを伴わない運用タスク として扱える。マーチャント作成アプリ（管理画面／Dev Dashboard）は現時点で対象外。 8 業務に活かせる3つのユースケース USE CASE 1 自社 Partner アプリ群の「bulk アクセス棚卸し」 課題 複数の Public／Custom アプリを Partner として保守しており、どのアプリが bulk クエリ／ミューテーションを使っているか把握しきれていない。 打ち手 コード上の bulkOperationRunQuery ／ bulkOperationRunMutation 呼び出しを洗い出し、各アプリの Partner Dashboard「API access requests」で有効状態と突き合わせる。 効果 access denied による突発的なバッチ停止を未然に防げる。 技術メモ Query と Mutation は別判定。片方しか有効でないケースを見落とさない。 USE CASE 2 月次・季節バッチの「実行前チェック」を運用手順に組み込む 課題 月末の一括価格更新や年次の大量データエクスポートなど、間隔が 31 日を超える bulk 処理があり、実行時にアクセスが切れている恐れがある。 打ち手 バッチ実行の Runbook に「Partner Dashboard で Run bulk operations の有効状態を確認、無効なら Allow をクリック」を前段ステップとして追加。 効果 セール前などクリティカルなタイミングでの一括更新失敗を回避。 技術メモ 再有効化はアプリ設定変更・新バージョンリリース・再インストール不要。手順は数クリックで完結する。 USE CASE 3 bulk 開始失敗の監視・アラート整備 課題 bulk operation の開始が拒否されても、非同期処理のためエラーに気付くのが遅れ、データ同期の欠落が後から発覚する。 打ち手 bulk 開始リクエストのレスポンスで access denied を検知したら、通知チャンネルへアラートし「Partner Dashboard で再有効化」を案内する。 効果 アクセス失効からの復旧時間を短縮し、マーチャントへの影響を最小化。 技術メモ エラーの具体的なコード・メッセージ形式は記事に記載なし。実際のレスポンスを確認してから検知条件を決める。 9 提案で使える1行サマリ 「Partner アプリの bulk クエリ／bulk ミューテーションは、Partner Dashboard で事前許可しないと全 API バージョンで拒否される。 既存利用アプリは自動で許可済み、ただし 31 日使わないと失効。 対応はダッシュボードの数クリックだけ、デプロイも再インストールも不要。」 source ： shopify.dev / changelog / partner-apps-must-enable-bulk-operations-before-use 原文公開日 2026-11-06