アプリ申請体験が刷新 レビューのやり取りが「ダッシュボード内」で完結

図解 ： アプリ申請体験が刷新（Partner Dashboard の新しいアプリ申請フロー） Shopify App Store / Partner Dashboard アプリ申請体験が刷新 レビューのやり取りが「ダッシュボード内」で完結 アプリの審査フィードバックがメールから Partner Dashboard へ移行。要件ごとにステータスが付き、AI セルフレビューと自動プレ提出チェックで「差し戻される前に直す」運用に。審査・公開の高速化が狙い。 このページの構成 そもそも何が変わるのか（30秒で理解） 3つの変更点の全体像（図解） ① Partner Dashboard でのレビュー管理 ② AI セルフレビューツール ③ 自動プレ提出チェック 審査中のアプリはどうなる？（ステータス別） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか アプリ審査のフィードバックが メールベースから Partner Dashboard（App ＞ Distribution）へ移行 。 要件ごとにステータス・レビュアーのコメント・質問導線が付き、 提出前の AI セルフレビュー と 自動チェック で、差し戻しの往復を減らして審査・公開を速くするのが狙い。 従来 ： メールで往復 レビューのフィードバックはメール経由。何が未解決か、どの要件で止まっているかを自分で追う必要があった。 新 ： ダッシュボードで完結 App ＞ Distribution で要件ごとの状況・コメント・質問を一元管理。全部解決してから再提出する設計。 2 3つの変更点の全体像 3 ① Partner Dashboard でのレビュー管理 審査フィードバックが App ＞ Distribution に集約。各要件に個別のステータス・レビュアーコメント・質問導線が付き、何が未解決かが一目でわかる。 新 要件単位のトラッキング 対応が必要な要件ごとに独立したステータストラッカー。 何が不合格になったか と、それに紐づくレビュアーのフィードバックが見える。 新 構造化された修正ワークフロー 要件を1つずつ個別に対応し、 「解決済み」とマーク してから再提出する流れ。 制約 再提出のブロック 特定された すべての問題が解決されるまで再提出できない 。中途半端な状態での再提出をシステム側で防ぐ。 レビュアーへの 質問もダッシュボードから直接 行える。メールスレッドを掘り返さずに、要件単位で「何が outstanding か」を把握して、全解決後に再提出する運用になる。 4 ② AI セルフレビューツール 提出前にアプリを自己診断 提出する前に、AI がアプリを App Store 要件に照らしてチェックしてくれる。 所要約2分 で、後から数週間の差し戻しを招く「明らかな問題」を先に拾う。 Shopify AI toolkit から利用可能 この機能は Shopify AI toolkit 内で提供される。提出フローに入る前のセルフチェック工程として組み込める。 料金・対応範囲・チェック項目の網羅度など、ツールの詳細仕様は元記事に 記載なし 。「明らかな問題を2分で拾う」位置づけであり、人手レビューを置き換えるものとは書かれていない。 5 ③ 自動プレ提出チェック 自動のプレ提出チェックを拡張。レビュアーがアプリを手に取る前に、 修正が必要な箇所を即座に通知 する。記事で明示されている拡張対象は次の2つ。 Theme app extensions の要件 テーマアプリ拡張に関する要件を自動チェックの対象に追加。 App Store Listing の要件 App Store 掲載情報（リスティング）に関する要件を自動チェックの対象に追加。 レビュアーが評価に入る前に問題を返すので、 「人手レビューの順番待ち→差し戻し」の長いラグ を、提出時点の即時フィードバックに前倒しできる。 6 審査中のアプリはどうなる？（ステータス別） 現在のステータス どうなる 必要なアクション Reviewed （未解決の問題あり） これまで通り 既存のメールベースのプロセス で審査が継続。新しいダッシュボードフローは このサブミッションには適用されない 。 従来通り メールでの対応を続ける Submitted （レビュー待ち） レビュアーが評価する際、フィードバックは 新しいダッシュボード体験に表示 される。 不要 何もしなくてよい つまり 移行はステータスで切り分け られる。すでにフィードバック往復中（Reviewed）の案件はメールのまま、レビュー待ち（Submitted）の案件は新フローに自動的に乗る。 7 技術者が押さえるべき5つのポイント 1. フィードバックの単一の置き場は Dashboard 審査のやり取りは App ＞ Distribution に集約。チームでメール転送して状況共有していた運用は、ダッシュボード参照に切り替えられる。 2. 修正は「要件単位」で潰す 要件ごとにステータスと解決済みマークがある。 1件ずつ resolve していく前提でタスク分解すると、進捗管理と相性が良い。 3. 全解決まで再提出はブロック 未解決が1つでも残ると再提出不可。 部分的に直して様子見 の戦略は取れない。提出前に全件クリアする計画が必要。 4. 提出前チェックを工程に組み込む AI セルフレビュー（約2分）＋自動プレ提出チェックを 提出前の必須ゲート にすると、明らかな差し戻し要因を事前に除ける。 5. 既存案件は「ステータスで」新旧フローが分かれる Reviewed（未解決問題あり）はメール継続 ・ Submitted（レビュー待ち）は新ダッシュボード 。社内で複数アプリを並行申請している場合、案件ごとにどちらのフローかを確認しておくと混乱しない。自動チェックの拡張対象として現時点で明示されているのは Theme app extensions と App Store Listing の2要件で、それ以外の網羅範囲は記載なし。 8 業務に活かせる3つのユースケース USE CASE 1 アプリ申請を「提出前ゲート」付きの定型フローにする 課題 申請するたびに思わぬ要件で差し戻され、メールの往復で数週間ロスしていた。 打ち手 提出直前に AI セルフレビュー（約2分）＋自動プレ提出チェック を必須ステップ化。要件単位の指摘を全部 resolve してから提出する運用に。 効果 「明らかな差し戻し要因」を事前に除去し、審査の往復回数を削減。公開までのリードタイム短縮。 技術メモ 自動チェックの明示対象は Theme app extensions 要件と App Store Listing 要件。リリース前チェックリストにこの2点を組み込む。 USE CASE 2 受託アプリ開発の「審査進捗」をチーム・顧客と共有 課題 レビューフィードバックが担当者個人のメールに届き、チームや発注元への状況共有が属人化していた。 打ち手 審査のやり取りを App ＞ Distribution に集約。要件ごとのステータス（解決済み／要対応／不合格）を見ながら、残タスクをそのままチケット化。 効果 「あと何が outstanding か」が一目で共有でき、レビュアーへの質問もダッシュボードから直接。報告コストの削減。 技術メモ 再提出は全要件の解決が前提。残件をすべて潰すまで「提出ボタンが押せない」前提でスケジュールを引く。 USE CASE 3 複数アプリ並行申請の「新旧フロー」を取り違えない管理 課題 同時に複数アプリを申請中で、どれがメール対応・どれが新ダッシュボード対応かが分からず対応漏れが起きそう。 打ち手 各申請のステータスを確認し、 Reviewed（未解決あり）＝メール継続／Submitted（待ち）＝新フロー で対応窓口を仕分け。 効果 対応チャネルの取り違えによる返信漏れ・遅延を防止。移行期の混乱を最小化。 技術メモ Submitted の案件は「何もしなくてよい」が正解。レビュー時にフィードバックが新ダッシュボードへ自動で出るのを待つ。 9 提案で使える1行サマリ 「アプリ審査のフィードバックが Partner Dashboard（App ＞ Distribution）に集約 。 要件単位でステータス管理し、 全解決するまで再提出はブロック 。 提出前の AI セルフレビュー（約2分）＋自動プレ提出チェック で差し戻しの往復を減らし、審査・公開を高速化する。」 source ： shopify.dev / changelog / new-app-submission-experience-in-the-partner-dashboard Developer Changelog ／ 公開日 2026-04-21