この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、アプリを増やしてきて表示速度が気になり始めた運用担当者
読了時間: 約12分
Shopifyのストアが重い、という相談で最初に見るのはテーマではありません。アプリです。テーマがどれだけ丁寧に組まれていても、アプリが管理画面のスイッチひとつで全ページにスクリプトを差し込んでくると、その分だけ確実に遅くなります。しかもアプリは「入れた瞬間」ではなく「積み上がったあと」に効いてくるので、原因に気づくのが遅れます。この記事では、Shopifyの表示速度がアプリで遅くなる仕組み、入れる前に判断するための軸、そして削除したあとに残る痕跡の消し方までを、制作側の視点で整理します。
Shopifyの表示速度がアプリで遅くなる仕組み
アプリは「テーマの中」に入り込んでいる
Shopifyのアプリと聞くと、管理画面の中だけで動く独立したツールを想像しがちです。実際にはそうではありません。フロント側で何かを表示するアプリは、必ずストアのページに自分のコードを載せます。載せ方は主に3種類あります。
| 載せ方 | 何が起きるか | 削除時の挙動 |
|---|---|---|
| アプリブロック / アプリ埋め込みブロック | テーマエディタ上でセクション内に配置される。読み込み位置を管理できる | アプリを消すとブロックも表示されなくなる |
| Script Tag（スクリプトタグ） | 全ページの共通部分に <script> が自動で差し込まれる |
削除時に消える設計だが、消え残ることがある |
| テーマファイルへの直接書き込み | theme.liquid や各セクションにコードが追記される |
アプリを消してもコードは残る |
Online Store 2.0 以降のテーマでは1番目のアプリブロック方式が推奨されていますが、古いアプリや、他社サービスとの連携ツールには、いまだに2番目・3番目の方式で入り込むものがあります。速度の問題と、後述する「消したのに残る」問題は、どちらもここから生まれます。
遅くなるのは「数」ではなく「読み込み方」
アプリの数だけで速度が決まるわけではありません。10本入っていても軽いストアはありますし、3本で明らかに重いストアもあります。差が出るのは、そのアプリのスクリプトがどう読み込まれるかです。
- 同期読み込み（
asyncもdeferも付かない<script>） — ブラウザはそこで一度止まり、スクリプトを取りに行って実行し終わるまで先へ進みません。<head>に同期スクリプトが増えるほど、画面が出るまでの時間が伸びます - 外部ドメインへの接続 — アプリのスクリプトはたいてい自社ドメインではなく、そのアプリのCDNから配信されます。ドメインが増えるほどDNS解決・TLS handshake の往復が増えます
- 描画後にDOMを書き換えるタイプ — レビュー星、在庫アラート、ポップアップなど。読み込みが済んだあとに要素を挿し込むため、レイアウトがガタッとずれます（Core Web Vitals の CLS が悪化する典型）
- 全ページに載るのに、使うのは1ページだけ — 商品ページでしか使わないレビューアプリのスクリプトが、トップにも会社概要にも載っている、という状態
つまり重さの正体は「アプリを入れたこと」ではなく、使わないページにも同期で外部スクリプトが載っていることです。ここが分かると、対策の方向も自然に決まります。
止まっている時間は1本あたりでは短くても、これがアプリの本数だけ直列に積み上がります。1本あたりの体感が小さいので、増やしている最中は気づけません。
「アプリが原因」と言い切る前に切り分けること
アプリの話に入る前に、除外しておくべき要因が3つあります。ここを飛ばすと、アプリを削っても何も変わらないという結果になります。
- 画像のサイズと形式 — 商品画像が原寸のまま載っていれば、アプリを全部外しても遅いままです。Shopifyは
image_urlフィルタで幅を指定すれば自動で変換・配信します - テーマ本体のJS — 海外製の多機能テーマは、標準でスライダーやアニメーションのライブラリを抱えていることがあります。DevToolsで自ストアのドメインから来ているJSの量を見れば分かります
- 測っている回線と端末 — PageSpeed Insights のモバイルスコアは低速回線・低性能端末を想定した値です。手元のPCで速く見えるのは当然なので、体感と数字が食い違ってもモバイル側の数字を正とします
この3つを見たうえで、それでも外部ドメインのJSが積み上がっているなら、そこからがアプリの話です。
表示速度を計測する｜どのアプリが重いかを特定する手順
「なんとなく重い」で改修に入ると、テーマの画像最適化のような的外れな作業に時間を使うことになります。原因を数字で押さえてから動きます。
1. Shopify管理画面のオンラインストアの速度レポート
管理画面の「オンラインストア」から見られる速度スコアは、他ストアとの比較が出るので、自店が相対的にどの位置かを掴むのに向いています。ただしこのスコアは代表的なページの計測をまとめた値で、どのアプリが原因かまでは分かりません。出発点として使い、深追いはしないのが正解です。
2. PageSpeed Insights を「ページ種別ごとに」かける
トップだけ測って終わりにしないでください。アプリの影響はページ種別で大きく変わります。最低でも次の4つは別々に測ります。
- トップページ
- 商品詳細ページ（アプリが最も集中する）
- コレクションページ
- カート／チェックアウト直前
「商品ページだけ極端に遅い」なら、レビュー・バンドル・サイズ表あたりが候補です。「全ページ均一に遅い」なら、theme.liquid に載っている全ページ共通のスクリプトが疑わしい、という切り分けができます。
同じページでも計測ごとに数字は振れます。1回の結果で判断せず、時間を空けて2〜3回測り、その範囲で見てください。改修の前後を比べるときは、必ず同じページ・同じ条件で測り直します。
3. ブラウザの開発者ツールで犯人を名指しする
ここが本番です。Chrome の DevTools を開き、Network タブでページを再読み込みします。
- Network タブ を開き、フィルタを JS に絞る
- Domain 列を表示する（列見出しを右クリック → Domain にチェック）
- Size と Time で並べ替える
- 自ストアのドメイン以外のものを、上から順に見ていく
外部ドメインから来ている重いJSが、そのまま容疑者リストになります。ドメイン名でそのまま検索すれば、どのアプリのものかはたいてい分かります。
このとき Disable cache にチェックを入れるのを忘れないでください。2回目以降の読み込みはキャッシュが効いて軽く見えるため、初回訪問者の体験を再現できません。あわせて、上部のスロットリング設定を「Fast 4G」などに落とすと、スマートフォンで見たときの詰まり方が再現できます。
もうひとつ有効なのが Performance タブでの確認です。記録して読み込みを再現すると、メインスレッドがどのスクリプトの実行で埋まっていたかが色分けで見えます。「ネットワークは速いのに表示が遅い」ときは、ダウンロードではなく実行時間が原因なので、こちらでしか見つかりません。
4. 疑わしいアプリを止めて、差分を取る
特定できたら、そのアプリを一時的に無効化（またはテーマエディタ上でブロックを外す）して、同じページをもう一度計測します。入れる前・入れたあとの差分が、そのアプリの実コストです。
このとき、一度に複数のアプリを止めないでください。まとめて止めれば数字は大きく動きますが、どれが効いたのかが分からず、戻す判断ができなくなります。1本ずつ止めて、1本ずつ測ります。手間はかかりますが、これをやった記録だけが次回の判断材料になります。
この差分を取る習慣がないまま運用していると、「アプリが10本あるが、どれをやめれば何秒戻るのか誰も知らない」という状態になります。減らす判断ができない状態は、増やす判断もできない状態です。
【画像挿入: Chrome DevTools の Network タブで、Domain 列を表示し外部ドメインのJSを並べ替えた画面のスクリーンショット】
アプリを削除してもコードが残るケース
ここが実務でいちばん厄介な論点です。管理画面からアプリを削除すれば、そのアプリが載せていたものは全部消える——そう思って運用していると、遅い理由が説明できなくなります。
残るのはこの3パターン
1. テーマファイルに直接書き込まれたコード
インストール時に theme.liquid や商品テンプレートへタグを追記するタイプのアプリは、アンインストールしても追記部分をそのままにします。読み込み先のスクリプトが404を返すだけの、無意味なリクエストが残り続けます。これが数本たまると、誰も使っていない機能のために毎回外部への接続が発生している状態になります。
2. 別テーマに残っているコード
アプリを入れたときのテーマと、いま公開しているテーマが違う場合。あるいは、公開テーマを複製してから改修した場合。複製元にあったアプリのコードは、複製先にそのまま引き継がれます。アプリ側は「そのテーマにはもう関与していない」ので、削除処理も走りません。
3. アプリが作った metafield や自動タグ
商品やコレクションに付けた metafield、自動生成されたタグ、追加されたスクリプトの設定値。これらは表示速度には直接響きませんが、データとして残ります。別のアプリに乗り換えたときに、古いデータが表示に紛れ込むことがあります。
消し方の手順
要点は最初のステップです。削除する前に、そのアプリが使っているドメイン名を控えておくこと。消したあとでは検索するキーワードが分かりません。DevTools の Network タブでドメインを確認するのは、この目的でも使えます。
テーマのコード検索は、管理画面の「テーマ → コードを編集」から各ファイルを開いて Ctrl+F でも可能ですが、ファイル数が多いテーマでは Shopify CLI でローカルに落として一括検索するほうが確実です。
# テーマをローカルに取得
shopify theme pull --store your-store.myshopify.com
# アプリ名や配信ドメインで全ファイルを横断検索
grep -rn "example-app-cdn.com" ./
# script タグの一覧を出して棚卸しする
grep -rn "<script" ./layout/ ./sections/ ./snippets/
shopify theme pull は Shopify CLI 3系のコマンドです。ストアへの認証が必要なので、初回はCLIのログインを先に通してください。ローカルで編集した内容は shopify theme push --unpublished で未公開テーマとして上げ、プレビューで確認してから公開に切り替えます。いきなり公開テーマへ push しない、というのは事故防止の基本です。
検索してヒットしたコードを、確認せずにまとめて消さないでください。アプリ名が含まれていても、後から人が手を入れて別の用途で使っている場合があります。1ブロックずつ、消して、プレビューで見て、次へ進む。複製テーマで作業していれば、間違えても公開側には影響しません。
削除したコードの記録を残す
消したコードは、消した理由とセットでどこかに残しておきます。半年後に「この機能がなくなっている」と言われたとき、意図的に外したのか、事故で消えたのかが判別できないと、調査からやり直しになります。テーマのバージョン管理をしていない運用では特に効いてきます。
残す形式は凝らなくて構いません。スプレッドシートに「日付・テーマ名・消したファイルと行の内容・理由・作業者」の5列があれば足ります。削除前のテーマを複製したまま消さずに残しておけば、それ自体がバックアップになります。
サイトを引き継ぐ・引き渡す場面での記録の残し方は、この記事にまとめています。
アプリで足りる範囲と、テーマ改修が要る範囲
速度を落とさない一番確実な方法は、そもそも入れないことです。ただし何でも自作すればいいわけではありません。線引きの基準を持っておきます。
アプリで足りる
- 外部サービスとの連携が本体（決済・配送・会計・メール配信）
- データを蓄積して管理画面が要る（レビュー・在庫連携）
- Shopifyの仕様変更に追随が必要な領域
- 使うのが一時的（セール期間だけのバナー等）
テーマ改修が向く
- 見た目だけの機能（バッジ・タブ・アコーディオン）
- 常時全ページで動く必要があるもの
- ブランドの世界観に直結する表現
- データを持たず、表示を切り替えるだけのもの
判断の芯はひとつです。そのアプリが「データを持つ」か「見た目を足すだけ」か。データを持つもの（レビューの投稿内容、顧客のポイント残高、在庫の同期状態）は、自作すると管理画面から仕様変更対応まで全部抱えることになるので、アプリに任せたほうが総コストは下がります。逆に、商品ページにタブを付ける、バッジを表示する、といった見た目だけの機能に月額を払い続け、そのために外部スクリプトを毎回読ませるのは割に合いません。
アプリ側に寄せるべき代表例
- 決済・配送まわり — 法令や事業者側の仕様が変わる領域。追随を自前でやる意味がない
- レビュー機能 — 投稿の受付、スパム対策、メール依頼、構造化データ出力まで含めると自作の範囲が広すぎる
- メール／LINE配信 — 配信基盤そのものが本体で、Shopifyは顧客データの供給元にすぎない
- 多言語・多通貨 — Shopify本体の機能と絡むため、独自実装は保守負債になりやすい
テーマ側で組んだほうがいい代表例
- 商品ページのタブ・アコーディオン — Liquid と
<details>要素で完結する。外部JSは不要 - バッジ・ラベル表示 — 商品タグや metafield を条件分岐で出せば済む
- セクションの並び替え — Online Store 2.0 のセクション機能でテーマエディタから可能
- お知らせバー — Dawn 系テーマなら標準セクションがある
たとえば商品説明のアコーディオンは、この程度のコードで動きます。
{%- comment -%} 商品ページの折りたたみ。JSもアプリも使わない {%- endcomment -%}
<div class="ts-accordion">
{%- for block in section.blocks -%}
{%- if block.type == 'collapsible' -%}
<details class="ts-accordion__item" {{ block.shopify_attributes }}>
<summary class="ts-accordion__head">
{{ block.settings.heading | escape }}
</summary>
<div class="ts-accordion__body">
{{ block.settings.body }}
</div>
</details>
{%- endif -%}
{%- endfor -%}
</div>
/* details/summary の標準マーカーを消して自前の見た目にする */
.ts-accordion__head { cursor: pointer; list-style: none; padding: 1rem 0; }
.ts-accordion__head::-webkit-details-marker { display: none; }
.ts-accordion__item[open] .ts-accordion__head { font-weight: 600; }
.ts-accordion__body { padding-bottom: 1rem; }
実装のポイント: <details> / <summary> はブラウザ標準の開閉要素なので、JavaScript を1行も書かずに動きます。主要ブラウザの現行版で動作し、JSが無効でも中身が読めるためSEO上も安全です。{{ block.shopify_attributes }} を入れておくと、テーマエディタ上でブロックを選択したときに正しくハイライトされます。
つまずきやすい点: list-style: none だけでは Safari のマーカーが消えません。::-webkit-details-marker の指定を併記してください。また、複数の <details> を「ひとつ開いたら他を閉じる」動作にしたい場合は name 属性でグループ化できますが、この属性は比較的新しいため、対応状況を確認してから使ってください。
こうした「見た目だけの機能」をアプリで賄うと、月額に加えて表示速度と解約時の残骸まで背負うことになります。テーマ側の実装は初期費用がかかりますが、そこから先は増えません。
判断がつかないときの決め方
線引きに迷うケースは実際にあります。そのときは順番に3つ問いを立てます。
- その機能を止めたら、注文は減るか — 減らないなら、そもそも入れる判断を保留してよい
- 設定を触るのは、最初の1回か、毎週か — 毎週触るならアプリの管理画面が要る。1回きりならテーマ側で足りる
- 1年後、誰がこれを保守するか — 社内に触れる人がいないなら、アプリのほうが安全。テーマ改修は、直せる相手がいて初めて資産になる
3つ目が一番効きます。テーマ改修は「安く済む」から選ぶものではなく、保守できる体制があるから選べるものです。ここを見誤ると、月額は消えたが誰も直せないコードだけが残ります。
Shopifyアプリを選ぶときに見る箇所
導入を決める前に確認しておくと、後で困らない項目です。機能一覧やレビュー点数は、どのアプリも良く見えるように書かれています。見るべきはその外側です。
最終更新日
アプリページに表示される更新履歴を必ず見ます。Shopify は管理画面もテーマ仕様も継続的に変わるため、長く更新されていないアプリは、次のプラットフォーム変更で動かなくなる可能性があると考えたほうが安全です。ストアの根幹に関わる機能ほど、この項目の重みが増します。
読み込み方式が選べるか
速度の観点で最も効くのに、見落とされやすい項目です。アプリページやドキュメントで、次のどれに当たるかを確認します。
- アプリブロック／アプリ埋め込みブロックで入る — テーマエディタから配置とオン・オフを管理できる。最も扱いやすい
- Script Tag で全ページに入る — テーマ側から止められない。全ページに載ることを前提に判断する
- テーマファイルへの追記を求められる — 手動で入れるぶん、消すときも自分で消せる。ただし記録を残さないと忘れる
前の章で書いた「削除しても残る」問題も、ここでほぼ決まります。インストール前の10分の確認が、解約後の数時間を減らします。
日本語対応の中身
「日本語対応」と書かれていても、対応の範囲はまちまちです。
- 管理画面が日本語なのか、ストアフロントの表示だけなのか
- メール文面のテンプレートが日本語で編集できるか
- 日付・住所・氏名の並びが日本の形式に合うか
- サポート対応が日本語か（英語のみのものも多い）
日本語UIが無いアプリでも、設定が一度きりなら実務上は困りません。問題になるのは、運用担当者が毎日触る画面が英語のみというケースです。誰が管理するのかを先に決めてから判断します。
サポート体制と時差
障害時に何時間で返事が来るかは、ストアの規模によって許容度が変わります。売上が立っているストアで、海外アプリのメールサポートに丸1日待たされるのは現実的ではありません。導入前にサポートへ質問を1本投げてみて、返信までの時間と内容を確かめておくと精度が上がります。
自社テーマとの相性
同じアプリでも、テーマによって表示が崩れます。特に、テーマを大幅にカスタマイズしている場合や、海外製の有料テーマを使っている場合は要注意です。必ず複製テーマでテストしてから公開テーマに入れる、を運用ルールにしてください。
テーマの選び方自体を検討中なら、この記事が判断の材料になります。
料金の考え方
Shopifyアプリの料金は、無料枠のあるものから月額課金のものまで幅があります。注意したいのは、注文数や顧客数に応じて段階的に上がる従量課金型で、導入時の月額と、事業が伸びたあとの月額が別物になることです。
判断するときは「いま払う額」ではなく、「想定する成長後に払う額」で見ます。数本入れて、それぞれに月額が発生すれば、年間では無視できない固定費になります。同じ額でテーマ改修をしたほうが安く済む機能はないか、という比較を一度は挟んでください。
最新の料金は各アプリのページで確認してください。 プラン体系は予告なく変わります。
固定費の考え方そのものは、Web全般に共通する論点です。
入れる前と入れたあとに確認する指標
アプリ導入を「入れるか入れないか」の一度きりの判断にせず、記録を残す運用に変えます。やることは単純です。
導入前に取っておく数字
| 指標 | 取得元 | なぜ必要か |
|---|---|---|
| LCP（最大コンテンツの表示時間） | PageSpeed Insights | 体感速度に最も直結する |
| CLS（レイアウトのずれ） | PageSpeed Insights | 後から要素を挿すアプリで悪化する |
| JSの合計転送量 | DevTools の Network | 増分がそのままアプリのコスト |
| 外部ドメインの数 | DevTools の Network（Domain列） | 接続確立の往復回数に効く |
商品ページとトップページの2種類で取っておけば十分です。スプレッドシートに日付とアプリ名を添えて記録します。
導入後、1週間おいてから測り直す
インストール直後ではなく、設定を一通り終えて実運用の状態にしてから測ります。多くのアプリは初期状態では何も表示せず、設定を入れた分だけスクリプトが重くなるためです。
差分を見て、次の基準で判断します。
- LCPの悪化が体感できるレベルなら、設定で読み込み範囲を絞れないか探す — 「このページでのみ表示」の設定があるアプリは多い
- CLSが悪化したら、要素が入る場所の高さを先に確保する — テーマ側でプレースホルダの領域を作れば改善することがある
- どうにもならず、その機能が売上に直結していないなら外す — これが一番効きます
年に一度は棚卸しをする
運用が続くほど、「誰も理由を説明できないアプリ」が増えます。年に一度、入っているアプリを全部並べて、次の3つを埋められるか確認してください。
- このアプリは何を解決しているか
- 止めたら誰が困るか
- 直近3ヶ月で管理画面を開いたか
3つとも答えられないアプリは、外して様子を見る候補です。外す前に必ず複製テーマで検証し、削除後にテーマファイルへ残骸がないか検索する——この記事の前半で挙げた手順をそのまま使います。
棚卸しは、担当者が変わる前にやるのが理想です。入れた本人がいるうちなら「何のために入れたか」を聞けます。いなくなってからでは、請求書とアプリ名だけを見て推測することになります。
コーポレートサイト兼用のストアで特に注意すること
Shopifyをコーポレートサイトと兼用する構成では、アプリの影響範囲がさらに広がります。EC機能のために入れたアプリのスクリプトが、会社概要や採用ページにも載るためです。商品を1件も表示しないページで、レビューアプリのJSが読み込まれている、という状態は珍しくありません。
兼用の設計そのものについてはShopifyをコーポレートサイトと兼用する考え方の記事で詳しく扱っていますが、速度の観点では対策はシンプルです。
- アプリ側に「表示するページ」の設定があるなら必ず絞る — アプリ埋め込みブロックなら、テンプレート単位で外せる
- Liquid のテンプレート判定で読み込みを分岐させる — テーマにコードを書ける場合はこれが最も確実
{%- comment -%}
商品ページとコレクションページでだけスクリプトを読む。
template.name は 'index' 'product' 'collection' 'page' などが入る。
{%- endcomment -%}
{%- if template.name == 'product' or template.name == 'collection' -%}
<script src="{{ 'ts-product-extra.js' | asset_url }}" defer></script>
{%- endif -%}
なぜこう書くのか: template.name はページ種別を返す Liquid のオブジェクトで、条件分岐の判定に使えます。defer を付けることでHTMLの解析を止めずに読み込ませ、解析完了後に実行させます。同期読み込みで描画が止まる問題は、これだけで回避できます。
つまずきやすい点: アプリが自動で差し込むスクリプトは、この分岐の外側（Script Tag として）に入るため、テーマ側から制御できません。制御したいなら、アプリブロック方式で入るアプリを選ぶ、という選択がインストール前の段階で必要になります。ここが「選ぶときに見る箇所」に速度の観点が入ってくる理由です。
もうひとつ、兼用構成でよくあるのがページ種別の判定を細かくしすぎて破綻するパターンです。page.handle で1ページずつ条件を書いていくと、ページが増えるたびにテーマを触ることになります。テンプレート自体を分ける（page.company.json のような代替テンプレートを作る）ほうが、後から増えても構造が崩れません。
コーポレートサイトとして必要なページ構成については、こちらも参考にしてください。
よくある質問
Shopifyアプリは何本まで入れて大丈夫ですか？
本数の上限で判断するものではありません。全ページに同期スクリプトを載せるアプリなら3本でも重く、必要なページでだけ非同期に読み込むアプリなら10本入っていても問題にならないことがあります。判断するなら本数ではなく、導入前後で計測したLCPの差分を見てください。
アプリを削除したのに表示速度が戻りません。なぜですか？
テーマファイルに直接書き込まれたコードが残っている可能性が高いです。アプリのアンインストールでは、theme.liquid などに追記されたタグは消えません。読み込み先が存在しないスクリプトへのリクエストが残り続けます。テーマのコードをアプリ名や配信ドメインで検索し、残骸を手で削除してください。
管理画面の速度スコアが低いのですが、どこから直せばいいですか？
まず PageSpeed Insights を、トップ・商品詳細・コレクションの3種類で別々に測ってください。ページ種別ごとの差が原因の切り分けになります。商品ページだけ極端に遅ければアプリ、全ページ均一に遅ければ全ページ共通のスクリプトかテーマ本体、という当たりが付きます。
機能をアプリで入れるか、テーマ改修で作るかの判断基準はありますか？
その機能がデータを持つかどうかで分けます。レビュー投稿や在庫同期のようにデータを蓄積して管理画面が要るものはアプリ、タブやバッジのように表示を切り替えるだけのものはテーマ側が向きます。あわせて、1年後に社内で保守できるかも見てください。触れる人がいないなら、テーマ改修は資産になりません。
アプリのテストはどこでやればいいですか？
必ず公開テーマを複製し、複製テーマで検証してからプレビューURLで確認します。アプリによってはインストール時点でテーマにコードを書き込むため、公開テーマに直接入れると、外したときに元へ戻せなくなります。複製テーマでの検証と、公開前の再計測をセットで運用ルールにしてください。
まとめ
Shopifyの表示速度は、テーマの品質よりもアプリの積み上がりで決まる場面が多いです。押さえる点を整理します。
- 重さの正体は本数ではなく読み込み方 — 使わないページに同期で外部スクリプトが載っている状態を疑う
- 犯人はDevToolsのNetworkタブで名指しできる — Domain列を出して外部JSを並べ替えれば特定できる
- 削除してもテーマファイルのコードは残る — 消す前に配信ドメインを控え、あとで検索して手で消す
- データを持つ機能はアプリ、見た目だけの機能はテーマ側 — 保守できる相手がいるかまで含めて決める
- 導入前後で必ず計測して記録する — 差分の記録がないと、減らす判断も増やす判断もできなくなる
アプリを入れないことが目的ではありません。何を得て、何を払っているかを説明できる状態にしておくことが目的です。年に一度の棚卸しで、答えられないアプリを外す。それだけで、ストアは静かに軽くなっていきます。
