公開アプリは 「IP アローリスト」の設定が必須に

図解 ： 公開アプリで IP アローリストの設定が必須に Admin API / セキュリティ / 必須対応 公開アプリは 「IP アローリスト」の設定が必須に Admin API を呼べるネットワークを限定し、トークンが漏れたときの被害を小さくする。一括処理（bulk operations）を使うアプリは 2026/11/12、それ以外の公開アプリは 2026/11/20 が期限。間に合わなければ一括処理の停止、App Store からの掲載取り下げまで起こる。 このページの構成 そもそも何が変わるのか（30秒で理解） 2 つの期限と、間に合わなかった場合 対象になるアプリ／ならないアプリ なぜ必要なのか ： トークン漏洩の被害を絞る 設定方法 ： 固定 IP と 動的 IP で分かれる マーチャント側のインフラから API を呼んでいる場合 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか マーチャントをより強く守るため、 公開アプリ（public apps）には IP アローリストの設定が要件として追加される 。 設定は Dev Dashboard で行い、アプリが Admin API を呼べるネットワークをあらかじめ決めておく。 これまで ： どこからでも呼べた トークンさえあれば、どのネットワークからでも Admin API を呼べる。トークンが漏れると、どこからでも悪用されうる。 これから ： 許可したネットワークだけ IP・CIDR、またはホスティング事業者の ASN と国で、呼び出し元を絞る。公開アプリはこの設定が必須になる。 2 2 つの期限と、間に合わなかった場合 期限（米国東部時間） 対象 未設定のときに起きること 2026/11/12 23:59 ET bulk operations 利用アプリ IP アローリストの無い公開アプリからの一括処理が 実行に失敗 2026/11/20 23:59 ET すべての公開アプリ Shopify App Store から 掲載取り下げ 、 新規インストールをブロック 日本時間に直すと、 11/12 期限は 11/13（金）13:59 頃、11/20 期限は 11/21（土）13:59 頃 （米国東部標準時 EST＝UTC-5 として換算）。発表から最初の期限まで 約 1 週間 しかない。 11/20 以降に 既にインストール済みのストアで Admin API 呼び出しがどうなるかは記載なし 。 3 対象になるアプリ／ならないアプリ 対象 公開アプリすべて App Store 掲載などで複数ストアにインストールされる public app。bulk operations の有無で期限が変わる。 対象外 カスタムアプリ Custom apps は今回の要件の対象外。 対象外 マーチャント自作アプリ マーチャントが Dev Dashboard または管理画面で作ったアプリは対象外。 4 なぜ必要なのか ： トークン漏洩の被害を絞る 記事の説明 ： 漏れたトークンは、どのネットワークからでも使われてしまう 。IP アローリストでアプリが Admin API を呼べるネットワークを限定すれば、 認証情報が漏れたときの被害を小さくできる 。 漏洩そのものを防ぐ仕組みではなく、漏れた後の被害を抑える「多層防御」の一層と考えるとわかりやすい。 5 設定方法 ： 固定 IP と 動的 IP で分かれる パターン A 送信元 IP が固定 Shopify を呼ぶ送信元が固定 IP なら、 固定 IP アドレス または CIDR 範囲 でアローリストを作る。 例 NAT ゲートウェイの固定 IP、専用サーバーの IP など パターン B 送信元 IP が動的 送信元 IP が変わる場合は、 ホスティング事業者の ASN を許可 し、 アプリが動いている国 を列挙する。 例 サーバーレス／PaaS など送信元 IP が固定できない環境 作業の流れ 1 送信元 IP を調べる Admin API を呼ぶすべての処理（バッチ・Webhook 処理・ワーカー等）の送信元が固定か動的かを確認。 2 Dev Dashboard で設定 アプリの許可 IP を登録。固定なら IP／CIDR、動的なら ASN と国。 3 期限前に動作確認 bulk operations を含む主要な API 呼び出しが通るか確認する（確認方法の詳しい手順は記載なし）。 詳しい手順は公式ドキュメント 「Restrict API access with an IP allowlist」 を参照するよう案内されている。登録できる件数の上限や IPv6 の扱いは、この記事には記載なし。 6 マーチャント側のインフラから API を呼んでいる場合 状況 アプリの Admin API 呼び出しが、アプリ事業者のサーバーではなく マーチャント側のインフラ から行われている。 Shopify の案内 Admin API トークンが外に出る範囲をより絞れる構成へ、 できるだけ早く移行すべき 。上記の期限について 延長申請を出すこともできる 。 延長申請の窓口・手順・認められる期間・審査の基準は 記載なし 。延長はあくまで一時的な措置で、トークンをマーチャント側に置かない構成への移行が前提になっている。 7 技術者が押さえるべき5つのポイント 1. bulk operations を使うかで期限が 8 日違う 一括処理を使うアプリは 11/12 が期限で、過ぎると一括処理が失敗する。商品・注文の一括同期やエクスポートが止まるので、 まずコードベースで bulk operations の使用箇所を探す 。 2. 制限されるのは Admin API の呼び出し元 記事は「アプリが Admin API を呼べるネットワーク」を絞ると説明している。Storefront API など、他の API に影響するかは記載なし。 3. 動的 IP でも ASN と国で対応できる 固定 IP が用意できない環境でも、ホスティング事業者の ASN と稼働国で指定できる。ただし ASN 指定は 同じ事業者を使う第三者も許可範囲に入る ので、固定 IP より絞り込みは粗い。 4. 11/20 を過ぎると掲載取り下げ＋新規インストール不可 新規獲得が完全に止まる。既にインストールしているストアで API が使えるかは記載なしなので、「既存ストアは大丈夫」と決めつけない。 5. トークンをマーチャント側に置く構成は見直しの対象 マーチャントのインフラから Admin API を呼ぶ構成は、トークンが出回る範囲を絞れる構成へ できるだけ早く移行すべき とされている。延長申請はできるが手順は記載なし。 オンプレ連携・基幹システム直結型のアプリは今すぐ設計の見直しに入る のが安全。 8 業務に活かせる3つのユースケース USE CASE 1 受託・自社の公開アプリを棚卸しして、11/12 の一括処理停止を防ぐ 課題 自社やクライアントの公開アプリが bulk operations で商品・在庫・注文を同期している。11/12 を過ぎると一括処理が失敗し、データ同期が止まる。 打ち手 ① 保有する公開アプリの一覧化 → ② bulk operations の使用有無を確認 → ③ 使っているアプリを最優先で Dev Dashboard にアローリスト登録。 効果 期限切れによる同期停止・データ不整合を防げる。期限の違いで優先順位がはっきりする。 技術メモ 期限は米国東部時間 23:59。日本時間では翌日の昼過ぎになるので、時差を考えて前倒しで設定する。 USE CASE 2 サーバーレス／PaaS 上のアプリの送信元 IP 設計を見直す 課題 送信元 IP が動的に変わる環境でアプリを動かしていて、固定 IP でのアローリスト登録ができない。 打ち手 短期 ： ホスティング事業者の ASN と稼働国で登録して期限に間に合わせる。中長期 ： 送信元を固定 IP にまとめる構成を検討し、IP／CIDR 指定に切り替える。 効果 期限は守りつつ、最終的にはより絞り込んだ許可範囲でトークン漏洩時の被害を小さくできる。 技術メモ ASN 指定は同じ事業者を使う他者も許可範囲に入る点に注意。送信元を固定する方法（NAT 構成など）は記事には記載なし。インフラ側の仕様を確認すること。 USE CASE 3 マーチャントのオンプレ連携型アプリを、トークンを集約する構成へ移す 課題 マーチャントの基幹システムや倉庫システムから直接 Admin API を呼ぶ構成になっていて、トークンが各マーチャントの環境に置かれている。 打ち手 ① 期限に間に合わない場合は延長申請を出す → ② API 呼び出しをアプリ事業者側のサーバーにまとめ、マーチャント側からはそこを経由する構成に作り直す → ③ まとめた送信元 IP をアローリストに登録。 効果 トークンが出回る範囲が狭まり、アローリストも管理しやすくなる。Shopify の推奨方向に沿う。 技術メモ 延長申請の窓口・認められる期間は記載なし。延長に頼らず、移行計画とスケジュールを先に固めておく。 9 提案で使える1行サマリ 「公開アプリは Admin API を呼べるネットワークの登録が必須に。 一括処理を使うアプリは 11/12、それ以外は 11/20（米国東部時間）までに Dev Dashboard で設定しないと、一括処理の停止や App Store からの掲載取り下げになる。 まず自社アプリの送信元 IP の棚卸しから。」 source ： shopify.dev / changelog / ip-allowlists-are-now-required-for-public-apps 公開日 2026-11-05（Developer Changelog）