Shopifyテーマ更新の保守｜アプリ更新の担当と時期の決め方

「テーマを更新したら、作り込んだトップページの一部が元に戻った」「使っていたアプリから提供終了の案内が来たが、誰も気づいていなかった」——Shopifyの運用で実際に困るのは、更新のたびに誰が何をすべきかが決まっていないことです。制作会社の保守に入っているつもりでも、契約書に「テーマ更新」「アプリ更新」の文字がなければ、その作業は誰の担当でもありません。この記事では、テーマ更新でカスタマイズが消えうる仕組みを公式ヘルプで確かめられる範囲で確認し、アプリの更新・廃止通知、Shopify本体の仕様変更への追従を含めて、月次点検の表（担当・頻度・確認項目）に落として「誰がいつやるか」を決める方法を整理します。

テーマ更新でカスタマイズが消えうる仕組み｜公式ヘルプで確かめられること

まず確かめたいのは、テーマ更新で「何が引き継がれ、何が引き継がれないか」です。ここが曖昧なまま「更新は怖いから放置する」と、セキュリティや機能の改善を受け取れないまま古いテーマを使い続けることになります。本記事執筆時点のShopify公式ヘルプ（テーマの更新）では、次の点が案内されています。

• 更新の対象：更新を受け取れるのはShopifyテーマストアからインストールしたテーマのみで、ファイルをアップロードしたテーマ（制作会社が独自に作ったものなど）は自動更新の対象外
• 通知の出方：更新があると、管理画面でテーマのバージョン番号の代わりに通知が表示される。最新であれば「このテーマは最新です」の表示になる
• 更新を実行すると：更新版が「Updated copy of」を頭に付けた名前で下書きテーマとして追加され、公開中のテーマはそのまま変わらない
• 引き継がれるもの：テーマエディタで行ったカスタマイズ（テーマ設定の変更、セクションやブロックの追加・設定、テンプレートの追加、アプリ埋め込みの設定など）は更新版にコピーされる
• コード編集の扱い：自社や制作会社、アプリがテーマのコードを編集していた場合、その編集が更新と競合しなければ更新版に含まれ、競合すると「コード編集を含められなかった」旨が表示される。公式ヘルプは、更新前にカスタマイズしたコードのコピーを必ず保存するよう案内している

つまり「カスタマイズが消える」のは、テーマエディタでの設定ではなく、コードを直接編集した箇所が更新と競合したケースです。テーマエディタで完結している変更は更新版にコピーされるので、怖がる必要はありません。本当のリスクは、制作会社がどのファイルのどこをコード編集したかを自社が把握しておらず、「含められなかった」と表示されても何が抜けたのか分からない状態です。更新作業を誰がやるかより先に、コード編集箇所の一覧を制作会社から受け取り、保守の納品物に含めておくことが出発点になります。

更新の前に必ずやること｜テーマの複製（バックアップ）と確認の流れ

テーマ更新は、公開中のテーマを直接書き換える操作ではなく、「更新版を下書きとして追加し、確認してから公開する」という流れで進めると安全です。その前提になるのがテーマの複製で、本記事執筆時点の公式ヘルプでは、テーマの横のメニューから「複製」を選ぶと「Copy of」が付いた名前のコピーが下書きに追加され、カスタマイズ前のバックアップとして使える、管理画面に追加できるテーマ数には上限（20個）がある、と案内されています。更新の流れを5つの段階にまとめます。

①管理画面でテーマの更新通知を確認します。②公開中のテーマを複製し、更新前の状態を下書きに残します。③更新を実行すると更新版が下書きに追加され、公開中のテーマはそのままです。④更新版について、コード編集が含まれたかどうかの表示を確認し、プレビューでトップページ・商品ページ・カート・購入手続きまでを通します。コード編集が含められなかった場合は、ここで制作会社がコード編集箇所の一覧をもとに移植します。⑤問題がなければ更新版を公開し、旧テーマは一定期間下書きに保管してから整理します。この流れなら、どの段階で問題が見つかっても公開中のテーマに影響はなく、「更新したら表示が崩れた」という事故は起きにくくなります。

アプリの更新はテーマと違い、開発者側で行われるため、ストア側で「更新ボタンを押す」場面は多くありません。その代わり、ストア側で見逃せない変化が3つあります。アプリが新しい権限を求めてきたとき、料金プランが変わるとき、そしてサービス終了（廃止）の案内が来たときです。本記事執筆時点の公式ヘルプでは、インストール後もアプリの権限と活動履歴はいつでも確認でき、アプリのサポートはShopifyが開発したアプリについてはShopifyサポート、第三者が開発したアプリについては機能・請求・返金ともアプリ開発者に直接連絡する、と案内されています。つまり、第三者製アプリの不具合や終了に関する一次窓口は制作会社でもShopifyでもなく開発者であり、誰がその連絡を受け取り、誰が開発者とやり取りするかを決めておく必要があります。

アプリをやめるときにも、公式ヘルプが注意を促している点があります。アプリによってはテーマにコードを追加しており、アンインストールしても自動では削除されないことがあるため、削除前にアプリの案内や開発者に追加手順の有無を確認する。有料アプリをアンインストールすると今後の継続課金は止まるが、現在の請求サイクル分は請求される可能性がある。Shopify外で契約した課金はアンインストールでは解除されない。再インストールしても以前の設定やデータが復元されない可能性があるため、必要なデータは事前にエクスポートする——いずれも「誰かがやってくれているはず」で抜けやすい項目です。備えとして、次の項目を持つアプリ台帳を自社で管理します。

• アプリ名と用途（どの業務・どのページで使っているか）
• 契約名義と課金の経路（Shopifyの請求に含まれるか、開発者と直接契約か）
• テーマへのコード追加の有無（削除時に手作業の除去が要るか）
• 開発者の連絡先と、連絡を担当する人
• 通知メールの受信先（自社のアドレスになっているか）
• 最終確認日と、権限・料金・終了案内の有無

アプリの数が増えるほど台帳の価値は上がります。目的別にアプリを選ぶ際の考え方はShopify BtoBアプリの選び方｜目的別5カテゴリと費用で扱っているので、台帳の「用途」欄を書くときの区分として使えます。

Shopify本体の仕様変更への追従｜期限付きの移行を見落とさない

テーマとアプリに加えて、Shopify本体の機能追加・変更・廃止があります。購入手続き（チェックアウト）のカスタマイズ方式やテーマの仕様のように、古い方式に期限が設けられ、期限までに新しい方式へ移行する必要が生じることがあります。これらは管理画面の通知やメール、公式の変更履歴で案内されますが、通知の受信先が制作会社のアドレスになっていたり、ストアオーナーが日常的に管理画面を見ていなかったりすると、期限の直前まで誰も気づかないことがあります。対応の中身は制作会社に任せるとしても、「案内を読む人」と「影響範囲の確認を依頼する人」は自社側に置くのが基本です。具体的にどの機能がいつ変わるかは時期により異なるため、本記事では個別の仕様には触れず、月次の点検項目に「本体の変更案内の確認」を入れることを提案します。

月次点検の表｜担当・頻度・確認項目を決める

ここまでの内容を、月次の点検表にまとめます。ポイントは、「気づく」役割を自社に、「直す」役割を制作会社に置くことです。更新の通知を受け取り、点検表を回すのは自社の担当者でも十分にできますが、コードの移植や障害の復旧は専門性が要るため外注に残します。頻度は一般的な目安で、キャンペーンの前後やアプリの入れ替え時には臨時で回します。

この表の「一次担当」が制作会社に偏っている場合、保守契約の作業範囲にそれらの項目が入っているかを確認してください。入っていなければ、点検は誰の仕事でもなく、問題が起きてから都度見積もりで対応することになります。逆に自社に偏っている場合は、担当者が月に一度、表の上から順に見るだけで回る状態にしておきます。

「誰がいつ」を契約と運用に落とす

点検表を作っても、契約と日々の運用に反映されていなければ、担当者が変わった時点で止まります。次の点を契約書と運用ルールに書き込みます。

• 保守契約の作業範囲に「テーマ更新の適用（複製・更新・確認・公開）」「アプリの権限変更・終了案内への対応」「Shopify本体の変更への追従」を明記し、作業枠に含まれるか都度見積もりかを決める。契約で決める項目の全体はShopify保守契約の内容｜範囲・対応時間・契約書で決める項目を参照
• テーマ・アプリ・Shopifyからの通知メールの受信先を自社のアドレスにし、制作会社には転送または共有で届ける
• コード編集箇所の一覧と、複製テーマの命名ルール（日付・目的）を保守の納品物に含める
• 点検表の実施記録（日付・担当・結果）を残し、月次の定例で制作会社と見る
• 契約終了時には、テーマのエクスポート・コード編集箇所の一覧・アプリ台帳を引き渡し対象にする。引き渡しの一覧はShopify保守の解約と引き渡し｜契約終了時に受け取るもの一覧を参照

点検の「気づく」部分を自社に置くことは、運用の内製化の第一歩でもあります。どの作業を自社でやり、どの作業を外注に残すかの分け方はShopify運用の内製化｜自社の作業と外注に残す作業の分け方で扱っています。

まとめ｜更新は「放置」でも「即適用」でもなく、点検表で回す

Shopifyのテーマ更新で消えうるのは、テーマエディタの設定ではなく、更新と競合したコード編集の箇所です。だから、更新の前にコード編集箇所の一覧を受け取り、公開中のテーマを複製し、更新版を下書きで確認してから公開する、という流れを決めておけば、更新を怖がる理由はなくなります。アプリは権限・料金・終了案内の3つを台帳で追い、Shopify本体の変更案内は自社の担当者が読む。これらを月次点検の表にして「誰がいつ」を決め、契約の作業範囲と納品物に反映することが、更新に振り回されない保守の形です。

点検表の項目を保守契約に書き込むときはShopify保守契約の内容｜範囲・対応時間・契約書で決める項目、点検の「気づく」役割を自社で持つ体制づくりはShopify運用の内製化｜自社の作業と外注に残す作業の分け方、契約終了時にテーマやアプリ台帳を受け取る手順はShopify保守の解約と引き渡し｜契約終了時に受け取るもの一覧で扱っています。テーマ・アプリの更新を含む保守運用から、マーケ・データ分析まで一気通貫で伴走する体制を検討したいときは、awai Buildのサービス詳細でご確認いただけます（料金は構築費＋月額（3プラン）＋売上連動の構成です）。