新しい Dev Dashboard アプリとストアの「司令塔」が 1 か所に

図解 ： 新しい Dev Dashboard（アプリ開発の司令塔） Dev Dashboard / 開発者向けアップデート 新しい Dev Dashboard アプリとストアの「司令塔」が 1 か所に 売上・アラート・ストア管理・コラボレーター権限・ログを、全アプリ／全ストア横断で 1 画面に集約。「マーチャントに言われる前に」アプリの問題に気づけるようにするリニューアル。 このページの構成 そもそも何が変わるのか（30秒で理解） 新しい Home ： 売上・ビジネス状況・Changelog Apps index とアプリ別メトリクス エラー率は「件数とセット」で読む Stores index ： 3 タブ → 1 リスト Logs ： マーチャントの問い合わせに答える場所 今後のロードマップ 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか コラボレーター権限の管理やアプリの健全性確認など、日常の作業が「あちこち行き来しないとできない」状態だった。 新しい Dev Dashboard は ストア管理・コラボレーター権限・アプリの健全性 を 1 か所にまとめ、全アプリ・全ストア横断で「今どうなっているか」と「何に対応すべきか」がすぐ分かるようにした。 これまで ： 行き来が多い ストアは 3 つのタブに分散。権限管理やアプリの状態確認は複数画面をまたぐ必要があった。 これから ： 1 か所で完結 Home で売上と要対応事項を確認し、Apps / Stores / Logs に 1 クリックで降りていける構成。 2 新しい Home ： サインイン直後に 2 つの問いに答える Revenue 全体の売上 全アプリの売上合計を表示。表示権限は既存の権限設定に従うので、追加の設定は不要。 Business status エラー・警告の集約 全アプリ・全ストアのエラーと警告を 1 つの表に、緊急度の高い順に並べる。 Changelog 開発者 Changelog API の更新や破壊的変更を、普段作業している Home の中で確認できる。 3 Apps index とアプリ別メトリクス Installs カードの数え方 今日時点でアプリが入っている全ストアを数える。 自分の開発ストアや有効なプランがないストアも含む 。数字を選ぶとインストール済みストアの一覧が見られる。 リリース後の落ち込みを切り分け 火曜にリリースして金曜に Installs が減った ── インストール／アンインストールのグラフで「マーチャントが離れたのか」「新規が鈍っただけか」を区別できる。 4 エラー率は「件数とセット」で読む 各グラフは エラー率と、その下にあるリクエスト量を重ねて表示 する。さらにグラフから その API・失敗分だけに絞り込まれた Logs へ直接リンクしているので、グラフのスパイクから原因のリクエストまで 1 クリック。 5 Stores index ： 3 タブ → 1 リスト クライアントワーク 1 日の起点になる画面 クライアント向けに構築している場合、ここが毎日の作業の出発点、と記事で明言されている。 アクセス申請 その場でアクセス申請 アプリを入れたマーチャントから相談が来たら、インストール済みストア一覧からそのままアクセス申請できる。ドメインを調べに行く必要なし。Stores index からも同じ手順で申請可能。 6 Logs ： 「アプリが実際に何をしたか」に答える API リクエスト インストール済みの全ストアにまたがって記録。 Webhook 配信 失敗した Webhook を 1 件探すのに、午後の全ログを読む必要はもうない。 アプリイベント エラーにはフラグが付き、検索とフィルタで調査対象の呼び出しに絞れる。 記事の例 ： ある 1 マーチャントでだけ Function による割引が効かなくなったら、そのショップの Function 実行にフィルタし、失敗した実行を開く。Logs ページはアーリーアクセス時より大幅に高速化されている。 7 今後のロードマップ（予告） 領域 予告されている機能 内容 Apps すべてを 1 か所で 配布の管理、アプリ審査の進行、リスティングと料金設定の作成を Dev Dashboard 内で完結 Apps アプリ履歴 インストール・アンインストール・課金イベントの完全なログ Apps アクセス申請 保護されたスコープへのアクセス申請を、Partner Dashboard に切り替えずに Dev Dashboard から Stores 紹介ストア 紹介ストアをストア一覧に表示し、各紹介の収益へ直接アクセス Organization 支払いと請求 収益、支払日の確認、請求管理を Dev Dashboard から ロードマップ項目の提供時期は 記載なし 。現時点では Partner Dashboard 側の作業（スコープ申請・支払い確認など）が残る前提で運用を組むこと。 8 技術者が押さえるべき5つのポイント 1. エラー率は分母と一緒に見る グラフは率と量を重ねて表示。4 件中 50% はノイズ、4 万件中 50% はインシデント。アラート基準も「率」単独ではなく量込みで考えるのが記事の示す読み方。 2. Logs は 30 日保持・窓は最大 7 日 30 日を超える調査は不可。長期の追跡が必要なら、自前のログ基盤への保存が別途必要（Dev Dashboard からのエクスポート手段は記載なし）。 3. Installs には開発ストアも含まれる 自分の開発ストアや有効プランなしのストアもカウント対象。「実利用マーチャント数」として報告する際は、一覧から内訳を確認してから使う。 4. Functions の実行も追える API・Webhook だけでなく Function の実行もショップ単位で絞り込み、失敗した実行を個別に開ける。割引 Function の「特定店舗だけ効かない」系の切り分けに直結。 5. 非推奨 API の呼び出しが警告として浮上する Business status に 非推奨 API の呼び出し が警告として並び、Home には開発者 Changelog も表示される。API バージョン移行の「どのアプリが古い呼び出しをしているか」を Home で拾える。Revenue の表示は既存権限に従うため、チームの権限設計がそのまま見える範囲になる点にも注意。 9 業務に活かせる3つのユースケース USE CASE 1 アプリ保守の「朝イチ トリアージ」を定型化 課題 複数アプリを運用していると、Webhook 失敗やアプリ停止にマーチャントからの問い合わせで初めて気づく。 打ち手 毎朝 Home の Business status を緊急度順に確認 → 重大（停止・Webhook 失敗）から対応 → 警告（非推奨 API）は次のスプリントに積む。 効果 「マーチャントに言われる前に気づく」体制。保守契約の SLA を守りやすくなる。 技術メモ アプリ一覧をアラート順に並べ替えると、どれも開かずに今日見るべきアプリが決まる。 USE CASE 2 「うちの店だけ割引が効かない」問い合わせの一次切り分け 課題 割引 Function や Webhook 連携の不具合報告が来ても、ストアのドメイン確認・アクセス申請・ログ探しで初動に時間がかかる。 打ち手 ① インストール済みストア一覧から該当店にそのままアクセス申請 → ② Logs をそのショップの Function 実行に絞り込み → ③ 失敗した実行を開いて原因を確認。 効果 問い合わせから原因特定までの往復が短縮。サポート回答の初動が早くなる。 技術メモ ログは 30 日保持・1 窓 7 日まで。発生日をヒアリングしてから窓を合わせると探索が速い。 USE CASE 3 リリース後の健全性チェックを「売上・インストール・エラー」で一括確認 課題 アプリのリリース後、インストール数の変化が「離脱」なのか「新規の鈍化」なのか、エラー増加と関係あるのか判断しづらい。 打ち手 アプリ詳細でインストール／アンインストールのグラフと、API リクエスト量・エラー率を同じ期間で並べて確認。スパイクがあれば Logs に 1 クリックで降りる。 効果 リリース判断の振り返りをデータで説明でき、クライアントや社内への報告根拠になる。 技術メモ Installs には開発ストア・プランなしストアも含まれるため、報告用の数字は一覧で内訳を確認してから使う。 10 提案で使える1行サマリ 「新しい Dev Dashboard は、全アプリ・全ストアの 売上・要対応アラート・ストア権限・ログ を 1 か所に集めた開発者の司令塔。 マーチャントに言われる前に問題に気づき、グラフから原因のリクエストまで 1 クリック で辿れる。」 source ： shopify.dev / changelog / the-new-dev-dashboard 公開日 2026-09-25（Shopify Developer Changelog）