shopify.app.toml に [network_access] 登場 アプリの「外部の行き先」と「通信先」を宣言する

図解 ： shopify.app.toml の [network_access] でアプリの外部通信先を宣言する Developer Changelog / アプリ設定・セキュリティ shopify.app.toml に [network_access] 登場 アプリの「外部の行き先」と「通信先」を宣言する リンク先ホストを宣言すれば、顧客がストア外へ移動する際の警告をスキップできる。通信先サーバーを宣言すれば、Shopify が不審な通信を見つけてアプリを守る材料になる。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： 2つのプロパティの役割 プロパティ比較表 設定例 対象になるアプリ 対応手順（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか shopify.app.toml に新しく [network_access] セクション が追加された。 アプリが「顧客をどこへリンクするか」「コードがどこと通信するか」を宣言でき、 顧客体験（警告の除去） と セキュリティ（不審な通信の監視） の両方に効く。 これまで ： ストア外へのリンクで警告 顧客がストアの外の URL へ移動しようとすると、Shopify は通常、警告を表示する。アプリ自身のサイトのような信頼できる行き先でも同様で、動線に摩擦が生じていた。 これから ： 宣言したホストは警告スキップ 宣言した外部ホストへのリンクは警告がスキップされる。あわせて通信先サーバーを宣言すると、Shopify が不審なアクティビティを見つけてアプリを守るのに使われる。 2 仕組み図解 ： 2つのプロパティの役割 2つは目的が違う。 navigation_hosts ＝ 顧客の「行き先」 （体験の摩擦を減らす）、 sources ＝ コードの「通信先」 （Shopify がストアフロントで悪意あるリクエストを監視するのに使う）。 3 プロパティ比較表 項目 allowed_navigation_hosts allowed_sources 何を書くか ストアフロントからアプリがリンクする外部サイト（例 ： 自社ドメイン） アプリのコードが読み込む／リクエストを送るサーバー（例 ： API、CDN） 書式 ホスト名 リンクに出てくる通りに正確に HTTPS オリジン https:// 付き 上限 20 件 20 件 対象画面 ストアフロント ストアフロント／チェックアウト／Shopify 管理画面（拡張機能・アプリホーム・アプリプロキシのページを含む） 効果 UX 外部遷移時の警告をスキップ セキュリティ アプリ保護・悪意あるリクエストの監視 ワイルドカード 記載なし 記載なし 4 設定例 [network_access] allowed_navigation_hosts = [ "app.example.com" ] allowed_sources = [ "https://api.app.example.com" ] navigation スキームなしのホスト app.example.com のようにホストを書く。リンクに出てくる表記と完全一致させる。 sources https:// 付きのオリジン https://api.app.example.com のように HTTPS オリジンで書く。 5 対象になるアプリ ストアフロント 外部リンク・外部通信のあるアプリ チェックアウト チェックアウト上で外部通信するアプリ Shopify 管理画面 アプリホーム等から外部通信するアプリ 記事上の位置づけは「新しいセクションを 使える 」「 強く推奨 」。対応期限や、未宣言の通信がブロックされるかどうかは 記載なし 。 6 対応手順（3ステップ） 1 リンク先ホストを追加 アプリ自身のサイトなど、顧客をリンクで送る先を allowed_navigation_hosts に。 2 通信先サーバーを追加 API や CDN など、コードが読み込む／リクエストを送る先を allowed_sources に。 3 deploy して release shopify app deploy を実行し、新バージョンをリリース。 具体例は公式ドキュメント「 Declare your app's network access 」に掲載されている（記事内で案内あり）。 7 技術者が押さえるべき5つのポイント 1. 2つの書式は別物 navigation は ホスト （例 app.example.com ）、sources は HTTPS オリジン （例 https://api.app.example.com ）。混同しないようにレビュー観点に入れる。 2. 上限はそれぞれ 20 件 外部ドメインが多いアプリは棚卸しと集約が必要。ワイルドカード指定の可否は記載なし。 3. sources の範囲は広い ストアフロントだけでなく、チェックアウト・管理画面、さらに 拡張機能／アプリホーム／アプリプロキシ のページからの通信も対象。 4. 反映は deploy ＋ release TOML を書くだけでは不十分。 shopify app deploy で新バージョンを作ってリリースするまでがセット。 5. 「宣言しないとどうなるか」は記載なし 未宣言の通信がブロックされる・将来必須化される等の記述はない。現時点は「強く推奨」。ただし sources は 悪意あるリクエストの監視に使われる ため、漏れがあると正規通信と不審な通信の区別材料が欠ける点を意識し、網羅的に列挙しておくのが無難。 8 業務に活かせる3つのユースケース USE CASE 1 会員ポータル／予約サイトへの遷移で「離脱警告」をなくす 課題 ストアフロントのアプリから自社の会員ポータルや予約ページへリンクすると、Shopify の外部遷移警告が出て顧客が不安になり離脱する。 打ち手 遷移先ホストを allowed_navigation_hosts に宣言し、deploy ＋ release。 効果 信頼できる動線から警告が消え、遷移の摩擦が減る。 技術メモ ホストは「リンクに出てくる通りに正確に」書く。サブドメインが複数あれば個別に列挙（上限 20）。 USE CASE 2 アプリの外部通信先を棚卸しして宣言する 課題 テーマ拡張・チェックアウト拡張・アプリプロキシ・アプリホームなどがそれぞれ別の API／CDN を叩いていて、通信先の全体像が誰も把握できていない。 打ち手 拡張ごとに fetch／script 読み込み先を洗い出し、HTTPS オリジン単位で allowed_sources に列挙。 効果 Shopify によるアプリ保護・悪意あるリクエスト監視の対象に乗る。棚卸し自体が通信先のドキュメントとして残る。 技術メモ 上限 20 件に収まらない場合は、API ゲートウェイや CDN への集約を検討する。 USE CASE 3 リリース手順に「network_access の更新」を組み込む 課題 新しい外部 API やドメインを追加しても TOML の宣言が漏れ、警告が復活したり監視対象から外れたりしがち。 打ち手 PR テンプレートやレビューチェックリストに「外部ホスト／オリジンを追加したら [network_access] も更新」を追加し、 shopify app deploy とセットで運用。 効果 宣言漏れを防ぎ、UX とセキュリティの両方を継続的に維持できる。 技術メモ CI で TOML を検査する仕組み等は記事に記載なし。チーム側のレビュー運用で担保する。 9 提案で使える1行サマリ 「 shopify.app.toml の [network_access] に外部の行き先と通信先を書くだけで、 外部遷移の警告が消え、Shopify がアプリへの不審な通信を見張ってくれる。 外部と通信するアプリは今すぐ宣言 → deploy ＋ release を推奨。」 source ： shopify.dev / changelog / secure-your-app-with-network-access-hosts-in-shopify-app-toml 公開日 2026-10-27