Admin API の IP 許可リスト アプリのトークンを「自社サーバー以外から使えない」状態にする

図解 ： Admin API アクセスを IP 許可リストで制限できるように Admin API / セキュリティ Admin API の IP 許可リスト アプリのトークンを「自社サーバー以外から使えない」状態にする Dev Dashboard で自社サーバーの IP アドレス（または CIDR 範囲）を登録して制限を有効化すると、それ以外の場所からアプリのトークンを使った GraphQL Admin API／REST Admin API へのリクエストを Shopify が 403 で拒否する。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： リクエストが通る／弾かれる流れ 対象になる API ／ 記事に記載のないこと 導入前 vs 導入後の比較 誰が使うべきか（静的 IP とサーバーレス） 設定手順（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまでは、アプリの Admin API アクセストークンを持っていれば どこからでも API を呼べた。 今回から、トークンを 登録した IP アドレスからの呼び出しに限定 できるようになった。 これまで ： トークンさえあれば通る トークンがどこから使われても API は受け付けていた。 これから ： トークン＋送信元 IP で判定 許可リスト外から届いたリクエストは 403 で失敗する。トークンが漏れても、許可された IP の外からは使えない。 2 仕組み図解 ： リクエストが通る／弾かれる流れ CIDR 範囲 とは ： 203.0.113.0/24 のように「IP アドレス＋プレフィックス長」で連続したアドレス範囲をまとめて書く記法。サーバー 1 台ずつではなく、ネットワーク単位で許可を登録できる。 3 対象になる API ／ 記事に記載のないこと 制限の対象（記事に明記） 対象 GraphQL Admin API アプリのトークンを使ったリクエストが許可リストで判定される。 対象 REST Admin API 同じく、許可リスト外からの呼び出しは 403 で失敗する。 記事に記載がないこと 記載なし 他 API の扱い Storefront API など Admin API 以外への適用は記載なし。 記載なし 登録数の上限・IPv6 登録できるアドレス数の上限や IPv6 対応は記載なし。 記載なし 料金・プラン条件 利用可能なプランや追加料金の有無は記載なし。 詳細仕様は記事内でリンクされているガイド「Restrict API access with an IP allowlist」に委ねられている。導入前にそちらを確認すること。 4 導入前 vs 導入後の比較 項目 許可リストなし 許可リストを有効化 トークンが使える場所 どこからでも 登録した IP／CIDR のみ 範囲外からのリクエスト 通常どおり処理 403 で失敗 トークン漏えい時の影響 漏えいしたトークンがそのまま使える 許可された IP の外からは使えない 設定場所 — Dev Dashboard ＞ アプリの Settings ＞ IP allowlist 事前検証 — 可能 直近のトラフィックで登録内容をテスト 5 誰が使うべきか（静的 IP とサーバーレス） 静的 IP から Shopify を呼ぶアプリ Shopify は利用を 強く推奨 している。固定 IP のサーバーや NAT ゲートウェイ経由で API を呼んでいるなら、すぐに導入できる。 サーバーレス（動的 IP）のアプリ 動的 IP のサーバーレス環境でホストしているアプリへの対応は 「近日対応予定」 。現時点では対象外と考えておく。 サーバーレス環境向けの対応時期や方式は記載なし。送信元 IP が変わる環境で制限を有効化すると、正規のリクエストまで 403 になるので注意。 6 設定手順（3ステップ） 1 アドレスを入力 Dev Dashboard のアプリ Settings ページにある IP allowlist に、サーバーのアドレスまたは CIDR 範囲を入力。 2 直近のトラフィックでテスト 登録した範囲を最近の実際のトラフィックと照らし合わせて確認する。 3 制限を有効化 enforcement を ON にすると、範囲外からのリクエストが 403 で失敗するようになる。 「入力 → テスト → 有効化」の順番 になっているので、いきなり本番トラフィックを遮断せずに済む。テストで漏れている送信元が見つかったら、有効化前に追加しておく。 7 技術者が押さえるべき5つのポイント 1. トークン漏えいへの多層防御 「トークン（持っているもの）」に「送信元 IP（いる場所）」が加わる。トークンが流出しても、許可リスト外からは Admin API を叩けない。 2. 失敗は 403 で返る 範囲外からのリクエストは 403。アプリ側のエラーハンドリングや監視で「権限不足」と区別して検知できるよう、ログやアラートの見直しを。 3. 有効化前に必ずテスト 直近のトラフィックに対するテスト機能がある。バッチ・ワーカー・ステージング環境など、見落としがちな送信元をここで洗い出す。 4. サーバーレスは近日対応 動的 IP のサーバーレス環境は今は対象外。そうした構成では、固定の送信元 IP を持つ構成にするか、対応を待つ判断が必要。 5. 単位は「アプリ」、対象は GraphQL と REST の両方 設定はアプリの Settings ページ単位で、そのアプリのトークンを使う GraphQL Admin API と REST Admin API の両方に効く。 インフラ変更（サーバー移転・NAT 変更・IP 追加）の手順に「許可リストの更新」を必ず入れる こと。忘れると本番の API 呼び出しがすべて 403 になる。 8 業務に活かせる3つのユースケース USE CASE 1 カスタムアプリ・自社連携基盤のセキュリティ強化 課題 基幹システムや WMS と Shopify をつなぐ自社アプリのトークンが、設定ファイルや CI のシークレットなど複数箇所に置かれていて、漏えい時のリスクが大きい。 打ち手 連携サーバーの固定 IP を許可リストに登録し、直近トラフィックでテストしてから制限を有効化する。 効果 トークンが漏れても社外から Admin API を操作されない状態にでき、セキュリティ審査や監査で説明しやすくなる。 技術メモ 範囲外は 403 になる。ステージングや開発者のローカル環境から本番トークンを使っていた場合は、その時点で通らなくなる。 USE CASE 2 公開アプリ開発会社の「出口 IP の棚卸し」と制限導入 課題 複数のサーバー・ワーカーから Shopify を呼んでいて、どの IP から API が出ているか全体像が見えていない。 打ち手 送信元を CIDR 範囲で整理して登録 → テスト機能で直近トラフィックと照らし合わせ、漏れを潰してから有効化する。 効果 API の出口がはっきりし、マーチャントへのセキュリティ説明材料にもなる。 技術メモ 静的 IP の構成なら Shopify が強く推奨している。動的 IP のサーバーレス部分は近日対応予定なので、構成ごとに導入の可否を分けて判断する。 USE CASE 3 インフラ移行・リプレイス手順書への組み込み 課題 クラウド移行やサーバー入れ替えで送信元 IP が変わると、許可リストを有効化しているアプリは移行直後から 403 で止まる。 打ち手 移行チェックリストに「新 IP を許可リストに追加 → テスト → 切替 → 旧 IP を削除」を入れる。 効果 セキュリティを保ったまま、API 停止事故を防いで移行できる。 技術メモ 切替期間は新旧両方の IP を登録しておく運用が安全。403 の急増を監視アラートに入れておくと早く気づける。 9 提案で使える1行サマリ 「アプリの Admin API トークンを、自社サーバーの IP からしか使えないようにする新機能。 Dev Dashboard で登録 → 直近トラフィックでテスト → 有効化の3ステップ、範囲外は 403。 静的 IP のアプリならすぐ導入すべき。サーバーレスは近日対応予定。」 source ： shopify.dev / changelog / restrict-admin-api-access-to-your-app-with-an-ip-allowlist 公開日 2026-10-27