Developer Dashboard で カスタムアプリの「健康状態」まで見えるように

図解 ： カスタムアプリのログと健全性指標が Developer Dashboard で見られるように Apps / 改善 Developer Dashboard で カスタムアプリの「健康状態」まで見えるように API リクエスト量・エラー率・Webhook 配信の健全性・埋め込み管理画面の表示速度を、しきい値付きで一目で確認できる。API リクエスト・Webhook・アプリイベントは 1 本のログストリームにまとまり、絞り込んで原因を追える。 このページの構成 そもそも何が変わるのか（30秒で理解） アプリごとに見られる 4 つの指標 ひとつにまとまったログストリーム 新しいホーム画面と共有範囲 従来 vs 新しい Developer Dashboard 使い始める手順 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか Developer Dashboard はこれまで、カスタムアプリの 「どう設定されているか」 を見る場所だった。 今回から 「ちゃんと動いているか（パフォーマンス）」 まで見られるようになる。 これまで ： 設定が見える アプリがどのように構成されているかを確認する画面が中心だった。 これから ： 動き方も見える 指標・しきい値・絞り込み可能なログ・全アプリ横断のホーム画面で、問題の発見から原因調査までダッシュボード内で完結。 2 アプリごとに見られる 4 つの指標 任意のカスタムアプリを開くと、以下が表示される。 各指標には明確なしきい値 があり、良いか悪いかが一目でわかる。 API リクエスト量 どれだけ API を叩いているか エラー率 失敗しているリクエストの割合 Webhook 配信の健全性 Webhook が届いているか 埋め込み管理画面の読込速度 admin 内ページの表示速度 しきい値の具体的な数値（例 ： 何 % 以上のエラー率で警告か、何秒以上で遅いか）は Changelog には 記載なし 。上の図は概念イメージ。 3 ひとつにまとまったログストリーム API リクエスト・Webhook 配信・アプリイベント のすべてが、 絞り込み可能な 1 本のストリーム に入る。アプリが動かなくなったときに原因を探せる。 どの項目で絞り込めるか（ステータス、トピック、期間など）や、ログの保持期間・エクスポート可否は Changelog には 記載なし 。詳細はドキュメント側で確認が必要。 4 新しいホーム画面と共有範囲 全アプリ横断で「要対応」がわかるホーム 新しいホーム画面で、すべてのアプリの中から注意が必要なものがまとめて表示される。 制作パートナーとも同じデータ カスタムアプリを作っている代理店や開発者にも、同じデータが表示される。 5 従来 vs 新しい Developer Dashboard 項目 従来 今回から 見られるもの 設定 アプリの構成 設定＋動作 パフォーマンスも 健全性の指標 記載なし 4 指標 API 量／エラー率／Webhook／読込速度 良し悪しの判断 記載なし しきい値付き 一目で判断 ログ 記載なし 統合 API・Webhook・イベントを 1 本で絞り込み 全体俯瞰 記載なし 新ホーム 全アプリの要対応を表示 制作パートナーとの共有 記載なし 同じデータ を代理店・開発者も参照 ※ 対象は記事上「カスタムアプリ」。公開アプリへの適用有無は記載なし。料金・プラン条件も記載なし。 6 使い始める手順 1 dev.shopify.com/dashboard を開く 新しい体験はここから。ホーム画面で要対応のアプリを確認。 2 カスタムアプリを開いて指標を見る API 量・エラー率・Webhook・読込速度をしきい値と照らし合わせる。 3 ログを絞り込んで原因を探す 不調があれば統合ログストリームで該当リクエスト／配信を特定。 詳しい使い方は公式ドキュメントにある（Changelog の「Read more in the docs」から）。有効化の設定作業が必要かどうかは 記載なし 。 7 技術者が押さえるべき5つのポイント 1. 3 種のログが 1 本に統合 API リクエスト・Webhook 配信・アプリイベントを同じストリームで追える。別々の画面や自前ロギングを行き来せずに時系列で突き合わせられる。 2. Webhook 配信の健全性が Shopify 側から見える 「Webhook が来ない」問題を、受信側サーバーのログだけでなく送信側（Shopify）の配信状況から確認できる。 3. 埋め込み管理画面の読込速度が指標化 admin に埋め込んだアプリページの表示速度が計測対象。フロント側のパフォーマンス改善の効果確認に使える。 4. 数値・API 取得・アラートは記載なし しきい値の具体値、ログの保持期間、外部へのエクスポートや API 取得、アラート通知の有無は Changelog に記載なし。監視基盤に組み込みたい場合はドキュメントで要確認。 5. マーチャントと制作側が同じ画面で会話できる 代理店・開発者もマーチャントと同じデータを見る。 障害報告時に「どのリクエストが、いつ失敗したか」を共通の事実として共有 でき、スクショの往復や再現待ちを減らせる。 8 業務に活かせる3つのユースケース USE CASE 1 「連携が止まった」障害の一次切り分けを速くする 課題 在庫・受注連携のカスタムアプリが急に動かなくなっても、API エラーなのか Webhook 未着なのかの切り分けに時間がかかる。 打ち手 Developer Dashboard で該当アプリのエラー率と Webhook 配信の健全性を確認し、統合ログストリームを絞り込んで失敗したリクエスト／配信を特定する。 効果 原因の場所（Shopify 側の配信か、アプリ側の処理か）を早く絞り込め、復旧までの時間を短縮。 技術メモ API リクエスト・Webhook・アプリイベントが同じストリームにあるため、時系列で前後関係を追える。絞り込み条件の詳細は docs で確認。 USE CASE 2 複数カスタムアプリを抱える保守運用の定期点検 課題 1 つのストアに複数のカスタムアプリがあり、どれが不調か気づくのが顧客からの問い合わせ後になりがち。 打ち手 新しいホーム画面で全アプリ横断の「要対応」を定期的に確認し、しきい値を超えた指標のアプリから優先対応する。 効果 問い合わせ前に不調を把握でき、保守の優先順位付けが明確になる。 技術メモ アラート通知機能の有無は記載なし。現時点では「ダッシュボードを見に行く」運用を前提に、点検頻度を保守契約に組み込むのが安全。 USE CASE 3 受託開発の品質報告を「共通のデータ」で行う 課題 代理店がマーチャント向けにカスタムアプリを納品・保守しているが、稼働品質を示す根拠がなく、報告がスクショや口頭頼みになる。 打ち手 マーチャントと代理店が同じ Developer Dashboard のデータを見られることを前提に、エラー率・読込速度などを定例報告の共通指標にする。 効果 双方が同じ数字を見て議論でき、改善提案（読込速度の改善など）の説得力が増す。 技術メモ しきい値で良し悪しが示されるため、非エンジニアのマーチャントにも状態を説明しやすい。数値の書き出し可否は記載なし。 9 提案で使える1行サマリ 「Developer Dashboard が、カスタムアプリの『設定画面』から『健康診断画面』へ。 しきい値付きの 4 指標と、絞り込める統合ログで、不調の発見から原因特定までを一画面で。 マーチャントと制作パートナーが同じデータで話せる。」 source ： changelog.shopify.com / filterable-logs-and-health-metrics-for-custom-apps-are-now-in-the-developer-dashboard 公開日 2026-09-25