Shopifyアプリを削除した後の残存コードを安全に監査する｜App embeds・テーマ・計測タグを分ける削除判定台帳

Shopifyのアプリを管理画面でアンインストールしても、作業が必ず完了するとは限りません。Shopify公式は、アプリによってはオンラインストアテーマへ追加したコードがアンインストール時に自動で削除されず、追加の削除手順を確認する必要があると案内しています。アプリに依存する自動化、外部サービス連携、ストア機能も停止し得ます。［確認日：2026年10月1日］

ここで避けたいのは、「使っていなさそうだから全部消す」と「怖いから何年も残す」の二択です。残存物ごとに、設置経路、現在の利用有無、削除根拠、復元手段、テスト結果を記録すれば、削除の判断を担当者個人の記憶に依存しにくくなります。

本記事では、アプリを利用終了した後に行う監査と削除の進め方を扱います。導入前のテストや切り戻し計画ではなく、削除後のテーマと計測設定を安全に整理するための実務です。

先に分けるべき4つの管理対象

「アプリのコード」という言葉で一括りにすると、確認漏れと誤削除が起きやすくなります。少なくとも次の4層に分けて台帳化してください。

テーマアプリ拡張は、app blocks、app embed blocks、assets、snippetsで構成されます。App embedsはテーマのheadまたはbodyへレンダリングされ、分析・トラッキング目的にも使われます。つまり、テーマファイルに貼り付けたJavaScriptだけを探しても、確認は完結しません。［確認日：2026年10月1日］

一方で、過去に手動で設置したコードや、テーマを直接編集する形式のアプリは、テーマファイル側の確認が必要です。設置方式はアプリと導入時期で異なるため、「App embedsが見当たらないから残存物はない」とは判断しないでください。

アンインストール前に確保する情報

すでに削除済みでも監査はできますが、削除前ならアプリ画面で情報を控える工程を入れてください。アプリ名だけではテーマ中の識別子と一致しないことがあるためです。

アプリ提供元の削除手順とデータの扱いを確認する

最初に、アプリ一覧の案内や提供元のヘルプで次を確認します。

• アンインストールとは別に必要なテーマコード削除の手順
• アプリ内で作成した設定、テンプレート、メタフィールド等の扱い
• 外部サービスとの連携解除、APIキー・Webhook・自動化の停止要否
• 請求やサブスクリプションの終了状況
• 将来再利用する可能性があるデータのエクスポート可否
• 問い合わせ先と、削除手順を確認した日時

Shopify公式は、追加の削除手順についてアプリ一覧またはアプリ開発元へ確認するよう案内しています。テーマ側で候補を見つけても、提供元の固有手順がある場合はそちらを先に確認するのが安全です。

検索に使う識別子を控える

次の情報を、削除前のアプリ画面、導入時の作業記録、テーマ内の既存コードから収集します。

• アプリ名、開発元名、旧サービス名
• ドメイン名、CDNのホスト名、JavaScriptファイル名
• snippet名、Liquidのタグ名、設定ID
• CSSクラス名、HTMLのdata-*属性、埋め込み用のコメント
• 計測ID、ピクセルID、コンテナID、イベント名

例えば、アプリ名ではなくCDNドメインやsnippet名で設置されているケースがあります。この段階で「検索語一覧」を作り、後段のテーマ確認とタグ確認で同じ一覧を使います。

公開テーマを編集せず、複製テーマを監査環境にする

テーマコードの削除は表示や購入導線を壊す可能性があります。Shopify公式も、テーマコード編集前にテーマを複製してバックアップを作成すること、テーマファイルの削除にはリスクがあることを案内しています。［確認日：2026年10月1日］

作業対象は公開テーマの複製です。複製テーマに監査日と目的が分かる名称を付け、誰が何を変更したかを台帳と結び付けます。

作業開始時の記録

最低限、以下を残します。

• 公開テーマ名と、複製したテーマ名
• 作業開始日時、作業者、確認担当者
• 削除対象アプリと、アンインストール日時
• 現行テーマで有効なApp embeds・アプリブロックの一覧
• 商品、コレクション、カート、顧客関連の重要導線
• 比較用の画面キャプチャまたは確認URL

テーマを入れ直して初期化する方法は、残存物の原因を追いにくくする場合があります。テーマ内の変更だけでなく、商品データ、メタフィールド、ナビゲーション、各種設定、外部タグとの関係も別途確認が必要になるためです。まずは複製テーマで候補を一つずつ判定し、全面的なテーマ移行は別の変更として見積もるほうが、影響範囲を管理しやすくなります。

復元手段を削除前に決める

復元方法は「困ったら元に戻す」ではなく、候補ごとに記録します。

• 複製元テーマへ戻して差分を確認する
• 削除するコードを、変更前後が分かる形で別途保管する
• テーマの変更履歴（Timeline）で復元できる範囲を確認する
• App embedなら、有効状態と設定値を記録する
• 外部タグなら、タグ設定のエクスポートや変更履歴を確保する

Shopifyはテーマコードの既存変更をTimelineから復元できる場合があると案内しています。ただし、これを唯一のバックアップにせず、どの候補をどの日時に変更したかは台帳にも残してください。

App embedsとアプリブロックをテーマエディタで確認する

テーマエディタでは、App embedsとアプリブロックをテーマの設定として確認します。App embedsは、画面上のウィジェットだけでなく、分析・トラッキングなど見えないコードを追加する用途にも使われます。

App embedsの確認手順

複製テーマを開き、テーマエディタでApp embedsを確認します。ここでは、削除済みまたは削除予定のアプリに対応する項目について、次を台帳へ記録します。

1. 表示名とアプリ名が一致するか
2. 有効・無効の状態
3. 設定項目と設定値
4. 対象テーマが公開テーマか複製テーマか
5. 無効化した場合に失われる機能
6. 無効化後に確認する画面とイベント

アプリ削除後に項目が見えない場合も、それだけでテーマへの直接記述がないとはいえません。App embedsで管理されていた部分と、過去に手動設置された部分は別に確認します。

アプリブロックは配置箇所と代替手段を見る

商品情報、カート、セクション内などに置かれたアプリブロックは、単にブロック名を消すだけでは判断できません。削除候補ごとに、以下を確認してください。

• どのテンプレート・セクションにあるか
• 商品ページ、カート、ブログ等のどこで表示されるか
• 価格、在庫、配送、レビュー、定期購入など購入判断に関係するか
• 別アプリまたはShopify標準機能へ移行済みか
• 空白、見出しだけの残存、レイアウト崩れが起きないか

アプリブロックの削除は、該当ページだけでなく、同じテンプレートを使う複数商品でも確認します。商品固有のテンプレートや代替テンプレートがある場合、代表商品1件だけの確認では不足することがあります。

テーマファイルとCustom Liquidの残存候補を判定する

次に、複製テーマのコードを確認します。ここでの目的は、文字列を見つけた順に削除することではありません。「その記述が現行ストアで何をしているか」を特定し、削除可否を記録することです。

優先して確認する場所

検索語一覧を使い、少なくとも次の種類を確認します。

• layout内のtheme.liquidなど、サイト全体で読み込まれる箇所
• snippets内のアプリ名・開発元名・用途名を含むファイル
• sections、templates、JSONテンプレート内のブロック参照
• assets内のJavaScript、CSS、画像、フォント
• 商品・カート・顧客関連のテンプレート
• テーマエディタのCustom Liquidに貼り付けたHTML、Liquid、script

コード上では、script src、外部ドメイン、render、include、コメント、ID、クラス名を手掛かりにします。ただし、一般的なライブラリ名や共通のCSSクラスだけではアプリ由来と断定できません。アプリ提供元の手順、導入記録、コード周辺のコメント、読み込み先ドメインを合わせて判断します。

削除してよいと判断するための条件

候補を削除可能とするには、少なくとも次の4点を確認します。

1. 帰属の根拠：削除済みアプリまたは利用終了サービスのものだと確認できる
2. 利用停止の根拠：現行のページ・運用・連携で必要としていない
3. 依存関係の確認：他のアプリ、テーマ機能、タグがそのコードを参照していない
4. 復元とテストの準備：戻し方と、削除後の確認項目が決まっている

根拠が弱い候補は「保留」にします。保留は失敗ではなく、提供元への照会や担当部署への確認が必要な状態です。とくに注文後処理、会員向け機能、同意管理、広告計測に関わるものは、画面上で見えないため慎重に扱います。

計測タグはテーマ残存コードと別台帳で照合する

計測コードは、テーマ、App embeds、タグ管理ツール、広告媒体側の複数箇所から配信され得ます。そのため、テーマファイルからタグを削除しても、計測が止まるとは限りません。反対に、別経路で必要なタグまで止める可能性もあります。

確認対象には、解析ツール、広告媒体のピクセル、コンバージョンAPI連携、同意管理ツール、レビュー・紹介プログラム等のイベント送信を含めます。

照合時の確認観点

• タグID・ピクセルID・コンテナIDが、どこから読み込まれているか
• 同じIDが複数経路から発火していないか
• 商品閲覧、カート追加、チェックアウト開始、購入など、確認すべきイベントは何か
• 削除対象アプリが送っていたイベントを、現在はどの仕組みが担当するか
• 同意取得の設定と矛盾しないか

ここでは「タグがあるから不要」「イベントが一度見えたから正常」と即断しません。対象アプリの役割を止めることと、必要な計測を維持することを分けて判定します。広告や分析の数値への影響を確認する担当者が別の場合は、公開判定の承認者として台帳に含めます。

削除判定台帳のテンプレートと公開前テスト

削除候補を1行ずつ管理する台帳を作ります。スプレッドシート、チケット管理ツール、変更管理表のいずれでも構いませんが、テーマ変更とテスト結果を結び付けられる形式にしてください。

購入導線の最低限のテスト項目

削除後は複製テーマのプレビューで、削除対象が関わっていた画面を優先して確認します。代表商品だけでなく、テンプレートや販売条件が異なる商品があれば対象に含めます。

• トップ、コレクション、検索結果から商品詳細へ移動できる
• 商品ページで価格、バリエーション、在庫表示、購入ボタンが確認できる
• カートへの追加、数量変更、削除、カート画面への遷移ができる
• 削除したウィジェットの跡として、空白や壊れた要素が残っていない
• 必要な計測イベントが意図した経路で確認できる
• チェックアウト前までの導線にエラーがない

実注文による最終確認が必要かは、利用中の決済方法、テスト環境、社内手順によって異なります。通常の購入者体験へ影響を出さない検証方法を、決済・受注担当と先に決めてください。

公開テーマへの反映は、候補をまとめて大量に変更するより、関連する機能単位で区切るほうが原因追跡をしやすくなります。公開後も、台帳に記載した重要ページ、カート、計測を再確認し、想定外の影響があれば記録した復元手段で戻します。

迷う候補を削除しないための判断基準

残存コードを減らすこと自体は目的ではありません。現在のストアに不要なものを、再現可能な手順で整理することが目的です。

次のような場合は、削除を保留し、アプリ提供元や実装担当へ確認する選択が妥当です。

• 読み込み先のドメインは分かるが、機能との対応が分からない
• 同じsnippetやJavaScriptを別のアプリ・カスタマイズが呼び出している
• 受注、会員、定期購入、同意管理など、画面で完結しない処理に関係する
• すでにアプリを削除しており、設定値や削除手順を再確認できない
• 公開テーマに未整理の変更が多く、対象アプリの差分を特定できない

この場合は、候補の存在、確認できた事実、未確認事項、次の確認者を残します。削除を急ぐより、判断根拠を積み上げるほうが、表示崩れや計測欠損を避けながら継続的にテーマを管理できます。

参考情報

• Shopify Help Center：Uninstalling apps
• Shopify Help Center：Extend your theme with apps
• Shopify Help Center：Editing theme code
• Shopify Developer Documentation：Configure theme app extensions