【ITニュース解説】Taking Over a Shopify Store: What Our First Audit Looks For

Shopifyストアの運用や引き継ぎでは、表面上の機能だけでなく、その裏側でどのようなコードが動いているかを正確に把握することが非常に重要だ。特に、複数の開発会社が関わったり、様々なアプリを試したりしてきたストアでは、使われなくなったアプリのコードの残骸が蓄積されている可能性が高い。Shopifyの公式ヘルプセンターでも指摘されているように、一部のアプリはアンインストールされても、テーマに組み込まれたコードが自動的に削除されないことがある。そのため、新しいシステムエンジニアや開発者がストアを引き継ぐ際は、まずストアが現在どのように動作しているのか、それぞれのコードがどこから来たものなのかを徹底的に「監査」することが、今後の開発作業や改善を円滑に進めるための不可欠な第一歩となる。この監査によって、後で発覚するかもしれない多くの問題を防ぎ、効率的な作業計画を立てることが可能になる。

Shopifyストアのフロントエンド（ユーザーが見る部分）を構成するコードは、主に三つの種類に分けられる。この区別を理解することが、問題の特定と解決に役立つ。一つ目は「テーマコード」だ。これはLiquid、JavaScript、CSSといったウェブサイトを構築するための言語で書かれており、ストアのデザインやレイアウト、特定の機能を提供する核となる部分で、テーマファイル内に直接存在する。このコードはテーマを編集した開発者によって管理され、明示的に削除されない限り残り続ける。二つ目は「アプリ注入コード」で、ストアにインストールされたアプリが追加するコードのことだ。最近のアプリは「テーマアプリ拡張機能」として提供され、そのコードやリソースはShopify側で管理されるため、アプリがアンインストールされると関連するコードも自動的にテーマから削除される仕組みになっている。しかし、以前のアプリの中には、Shopifyの管理APIを通じてスクリプトタグを登録し、テーマファイルを直接変更せずにコードを注入したり、開発者がテーマファイル（特にtheme.liquidという主要なファイル）に直接コードを貼り付けたりする形式もあった。三つ目は、最も注意が必要な「置き去りの残骸」だ。これは、アプリがアンインストールされたにもかかわらず、そのアプリが以前テーマに貼り付けたコードスニペットなどが残り続けてしまう状態を指す。アプリが削除されると、そのアプリはストアへのアクセス権を失うため、自身のコードをクリーンアップすることができない。結果として、残されたコードは引き続き動作し、場合によっては不要な外部サーバーへのリクエストを送り続け、ストアのパフォーマンスに悪影響を与える可能性がある。これら三種類のコードの区別が重要なのは、それぞれのコードに対して取るべき対応策が異なるためだ。テーマコードはレビューし、必要に応じて修正する。新しい形式のアプリ埋め込みはテーマエディタで簡単に有効・無効を切り替えられる。しかし、置き去りの残骸は、それが本当に不要なコードであると確認された後に、手動で削除する必要がある。

監査の最初のステップは、テーマファイルが参照しているコードと、実際にウェブページが読み込んでいるコードを比較することだ。まず、Shopify CLIという開発者向けのコマンドラインツールを使って、現在公開されているテーマのファイルを自分のコンピューターにダウンロードする。ダウンロードしたら、Gitというバージョン管理システムを使って、その時点のテーマの状態を最初の履歴として保存する。次に、ダウンロードしたテーマファイルの中から、外部のスクリプト（プログラム）を呼び出している記述を全て抽出し、リストを作成する。これは、grepコマンドなどのファイル内検索ツールを使って行える。もう一つのリストは、実際にストアのページがブラウザに読み込まれた際に、どのスクリプトが実行されているかを把握するものだ。これは、ウェブブラウザの開発者ツールを使い、performance.getEntriesByType("resource")というJavaScriptの機能を利用することで取得できる。顧客がCookie（ウェブサイトの情報を保存するデータ）の使用に同意した状態を再現し、ホームページ、商品一覧ページ、商品ページ、カートページなど、複数のページでこの情報を収集することが重要だ。なぜなら、アプリによっては特定のページでのみスクリプトを読み込む設定になっている場合があるからだ。これら二つのリストを比較することで、テーマファイルには記載がないのにページが読み込んでいるスクリプト（古いアプリの注入コードなど）や、テーマファイルには記載があるものの、もはやどのアプリにも紐づいていない可能性のあるスクリプト（置き去りの残骸の候補）を特定できる。さらに、Shopify Theme Checkというツールを実行すれば、テーマ内のLiquidコードの品質を素早く評価し、潜在的な問題点を見つけることができる。

次に、特定されたすべてのスクリプトに対して「所有者」を割り当てる作業を行う。それぞれのスクリプトが、現在インストールされているアプリが使用しているものか、ストアの担当者が分析ツールやチャットウィジェットなどの目的で意図的に追加したものか、あるいは「誰にも紐づかない、不要なもの」のいずれであるかを判断していく。Shopify管理画面のインストール済みアプリリストが、この作業の出発点となる。また、テーマエディタ内にある「アプリ埋め込み」パネルでは、どのアプリ埋め込みが有効になっているかを確認できる。管理画面のアプリリストに表示されないアプリの名前が付いたコードスニペットは、典型的な置き去りの残骸であり、多くの場合、theme.liquidというテーマの共通ファイルからすべてのページで実行されていることが多い。ダウンロードしたテーマファイル内で、アンインストールされた可能性のあるアプリ名や、そのアプリのスクリプトが読み込まれる元となるURL（ホスト名）を検索し、もしあればアプリ開発者が提供しているアンインストール手順も確認することが重要だ。開発者は、自身のコードがどこに配置されたかを最もよく知っているため、残骸の場所を特定する上で有用な情報となる。アプリリストを確認する際には、請求情報も合わせて確認する必要がある。Shopifyによれば、アプリをアンインストールしても、Shopifyプラットフォーム外で課金されるアプリの請求は自動的にキャンセルされない場合があるため、ストアが1年以上前に削除したアプリに、今も料金を支払い続けている可能性も考えられる。この段階では、まだコードを削除してはならない。すべてのスクリプトの所有者が特定され、それが本当に不要なものであると確認されてから、複製したテーマの上で、一つずつ慎重に削除作業を行うべきである。

ストアの動作が遅い主な原因の一つは、もはや使われていないスクリプトが多数読み込まれていることにある。アプリのスクリプトは、それがどのページで本当に必要なのかを常に最適に判断しているわけではない。例えば、商品ページでのみ必要な商品レビューウィジェットのスクリプトが、ホームページ、ブログ記事、カートページなど、本来必要のない場所でも無駄に読み込まれてしまうことがある。このような不要なアプリの残骸がいくつも残っている場合、それぞれのスクリプトが独自の処理を実行し、外部サーバーへのリクエストを行うため、結果としてストアは存在しない機能のためにすべてのページで動作が遅くなってしまう。この問題の状況を客観的に確認するには、ShopifyのWebパフォーマンスレポートが非常に有効だ。このレポートは、実際の訪問者データに基づいて、読み込み速度、ユーザーとの対話性、視覚的な安定性を、デスクトップとモバイルに分けて詳しく表示してくれる。さらに、アプリのインストールやテーマの更新といったイベントがグラフ上に線で示されるため、ストアが遅くなった時期と、その時期にインストールされたアプリを照らし合わせることで、パフォーマンス低下の直接的な原因を特定できる場合が多い。サーバー側でのLiquidコードの処理コストについては、shopify theme profileコマンドで特定のページのレンダリング状況を詳細に分析することが可能だ。このような理由から、私たちは「ストア高速化アプリ」を最初に導入することには慎重な立場を取っている。なぜなら、スクリプトを最適化するアプリ自体も、ストアに一つ追加されるスクリプトだからだ。それよりも、何も機能していない不要なスクリプトをいくつか削除する方が、通常ははるかに効果的で、かつコストもかからない解決策となることが多い。

現在、Shopifyプラットフォームの二つの大きな変更が進行中であり、これが置き去りの残骸スクリプトを単なる「散らかったもの」から「動作しないもの」へと変える可能性があるため、監査作業を緊急に行う必要がある。一つは「スクリプトタグの廃止」だ。Shopifyの開発者向け変更履歴によると、2026年10月1日以降、新しいスクリプトタグを作成したり既存のものを更新したりするAPIはエラーを返すようになり、さらに2027年3月1日には、Shopifyは完全にストアのフロントエンドページへのスクリプトタグの注入を停止する予定だ。これは、古い形式でスクリプトタグに依存しているアプリは、この期限までに新しい形式のアプリ埋め込みや、分析追跡専用のWebピクセルへと移行しなければ機能しなくなることを意味する。この監査によって、現在ストアで使用しているアプリの中で、どのアプリがスクリプトタグに依存しているかを知ることができ、期限が来る前にベンダー（アプリ開発元）に問い合わせて対応を促すことが可能になる。二つ目は「注文ステータスページの変更」だ。Shopify Plusストアでは2025年8月28日に、その他のプランでは2026年8月26日に、既に注文ステータスページでのスクリプトタグの実行が停止されている。これは、以前の担当者がこのページに直接貼り付けていたコンバージョントラッキングコードなどが、エラーメッセージも表示されずに機能しなくなっている可能性があることを意味する。もしマーケティングチームから、8月下旬以降に購入数のデータが減少したという報告があった場合は、広告アカウントの設定を確認する前に、この注文ステータスページの問題を調査するべきだ。

最終的な、そして非常に重要なステップは、今後の安全な変更作業を保証するための、Gitを使ったテーマのバージョン管理だ。引き継いだストアでは、多くの場合、テーマがShopify管理画面のコードエディタで直接編集されてきた経緯がある。複数の人物が関わったにもかかわらず、誰がいつ何を変更したかの記録が全く残っていないことがよくある。このような状況で問題が発生した場合、原因究明はまるで過去の遺跡を発掘するような困難な作業になるだろう。ShopifyのGitHub連携機能は、この問題の多くを解決してくれる。この機能を使うと、テーマをGitHubのリポジトリの特定のブランチ（開発の分岐点）に接続できる。これにより、そのブランチへのすべてのコミット（変更履歴）がテーマに自動的に反映され、さらに管理画面から行われた変更も、約10秒間に行われた編集を一つのコミットとして、自動的にブランチに記録される。Shopifyの公式バージョン管理ガイダンスも、安定版のテーマをメインブランチに接続して公開し、キャンペーン用のカスタマイズや一時的な変更には別のブランチを使用することを推奨している。この作業の順序も非常に重要だ。まず、現在ライブ公開されているテーマを、その時の状態のまま、たとえ問題のある部分が含まれていても、最初のコミットとしてGitに取り込む。その後のクリーンアップ作業は、新しいブランチ上で個別のコミットとして行い、レビューを経てメインブランチにマージする。これにより、ストアの運営担当者（マーチャンダイザー）はこれまで通りテーマエディタを使って変更できるが、彼らの変更もリポジトリにコミットとして記録されるため、新しいコードのデプロイ（変更の反映）によって彼らの作業が意図せず上書きされることはなくなる。この体制が整えば、もし問題のある変更があった場合でも、簡単に元の状態に戻すことができるようになる。

この一連の監査作業を通じて、ストアが読み込むすべてのスクリプトが「テーマコード」なのか、「アプリによって注入されたもの」なのか、あるいは「ずっと前にアンインストールされたアプリの残骸」なのか、という三つの質問に対する明確な答えが得られる。さらに、2027年3月1日に廃止されるスクリプトタグに依存しているアプリや、すでに機能しなくなった注文ステータスページでのトラッキングコードなども特定できる。これらの情報こそが、今後の修正作業の優先順位を決定し、具体的な開発計画を立てるための貴重な基盤となるのだ。この監査は、ストア全体を俯瞰する標準的なものから、Shopifyアカウントへのアクセスを伴い、テーマファイル、アプリリスト、請求情報、関連する外部サービス連携まで全てを詳細に確認する大規模なものまで、いくつかの形式で提供される。いずれの場合も、短期間の作業で、インフラやユーザーインターフェース・ユーザーエクスペリエンス（UI/UX）に関する問題点が、重要度（クリティカル、ミディアム、ロー）別にリストアップされて提供される。もし特定の目標（例えばストアの高速化など）を持って監査を依頼した場合、その目標達成を阻む具体的な修正点群が明確に示されることになる。最終的には、テーマのコードは常にGitなどのバージョン管理システムの下で管理され、可能であればストア所有者自身のリポジトリに置かれ、Shopify管理画面で直接編集されることは避けるべきだ。なぜなら、誰も完全に理解していないテーマの上に新しい機能を追加していくことは、次の担当者にも同じような混乱や問題を遺すことになるからである。そのため、ストアを引き継ぎ、変更を加える前に、その現状を正確に把握するための監査を行うことが、何よりも重要な最初のステップとなる。