↗付きの用語リンクは、別タブで説明を開きます。
Shopifyの制作会社を変更したいのに、ソースコードの場所や公開手順が分からず、次の依頼先が見積もりを出せない。このような引き継ぎでは、ファイルを受け取るだけでなく、誰が何を変更でき、問題が起きたらどこへ戻せるかまで確認する必要があります。
特にHydrogenで構築したサイトは、オンラインストアのテーマをダウンロードしただけでは公開サイト本体のソースを取得できない場合があります。この記事では、発注前にそろえたい資料と検収条件を整理します。移管や改修による成果を示す事例ではありません。
結論：ソース・権限・公開手順を一組で受け取る
引き継ぎ完了の基準は「ZIPファイルが届いた」ではなく、次の担当者が許可された環境で現行版を確認し、検証環境への反映と復旧手順を説明できることです。見積もりを比較する前に、現行構成、納品対象、権限、運用責任を同じ一覧にします。
- 現在公開されている版とソースコードの対応が分かる
- リポジトリ・Shopify・公開環境の管理者が分かる
- 環境構築、検証、公開、復旧の手順が残っている
- 外部サービスの契約者と継続費用が分かる
- 引き継ぎ後に誰が障害や更新へ対応するか決まっている
契約上の納品範囲や利用権限は、契約書・仕様書・見積書などを当事者間で確認してください。名称が「買い切り」でも、その言葉だけでソースの納品範囲や改変・再委託の条件を確定しないことが重要です。判断が分かれる場合は、専門家へ確認してから移管方法を合意します。
テーマとHydrogenのどちらが公開本体かを確認する
Shopify管理画面にテーマがあることと、そのテーマが現在の公開サイト全体を動かしていることは同じではありません。独自のストアフロントと、別の補助画面が併存する構成も考えられます。まずURLごとに「どのソースから作られ、どこへ公開されているか」を制作担当者へ確認します。
Shopify公式資料では、HydrogenのストアフロントとGitHubリポジトリの接続、環境、デプロイが別々の要素として説明されています。Oxygen以外への公開や独自の自動公開手順もあり得るため、一般的な構成図を現行サイトへそのまま当てはめないでください。公式資料：Hydrogenのストアフロント
| 確認する場所 | 引き継ぎたい情報 | 不足していると困ること |
|---|---|---|
| 公開サイト・補助画面 | URL、用途、実装方式、公開元 | 取得したテーマと公開本体を取り違える |
| Gitリポジトリ | 所有者、公開版のコミット、ブランチ、履歴 | どの版を改修すればよいか判断できない |
| 公開環境 | Oxygen等の環境名、公開手順、実行者 | コードを直しても反映できない |
| 外部サービス | 用途、契約者、管理者、連携先 | 停止・解約によって別の機能まで止まる |
| 運用資料 | 確認項目、連絡先、復旧・変更履歴 | 障害時に判断できる人がいなくなる |
現行ソースと公開版を一致させる
Gitはソースコードと変更履歴を管理する仕組み、コミットは変更を記録した単位です。「最新のファイル」だけでなく、本番に反映されているコミットを確認します。未公開の改修が混ざったフォルダーを本番と誤認すると、診断や見積もりの前提がずれます。
受領資料には、リポジトリの場所、管理組織、既定ブランチ、本番用ブランチ、公開済みの版、作業中の変更を含めます。package.jsonやロックファイル、利用ランタイム、起動・ビルド手順も合わせて確認し、引き継ぎ時点の状態を保存します。
リポジトリの移管・複製・継続招待のどれを採用するかは、契約と管理方針に合わせて決めます。GitHubにも移管権限や移管先による条件があるため、先に新しい管理者と必要権限を確認します。バックアップ取得と権限確認は別の作業です。公式資料：GitHubリポジトリの移管
公開環境と自動反映のつながりを確認する
「GitHubへ変更を保存したら公開される」のか、「担当者が手動で公開する」のかを明確にします。自動反映がある場合は、対象ブランチ、実行条件、承認者、失敗通知の宛先も引き継ぎます。権限の整理中に本番へ意図しない変更が出ないよう、確認作業と公開作業を分けます。
Oxygenでは環境ごとにブランチや変数を管理します。変数を変更しても過去のデプロイに自動で反映されるわけではないため、設定変更と再デプロイを一組で確認します。独自のCI/CDを使っている場合は、そのサービス側の設定も対象です。公式資料：環境と環境変数、独自のCI/CDからの公開
- 本番と検証環境のURL・接続先を区別する
- 自動反映の開始条件と承認方法を確認する
- 失敗した場合に誰へ通知されるかを確認する
- 公開前の確認項目と、戻す判断をする担当者を決める
環境変数は名前と秘密値を分けて引き継ぐ
APIトークンなどの秘密値を、一般的な引き継ぎ表やメール本文へ貼り付けないでください。一覧表には変数名、用途、対象環境、保管先、管理担当、更新時の影響を記録し、値そのものは権限を制限した保管方法で受け渡します。
秘密値を再表示できない仕組みもあります。受領後にそのまま使えるのか、権限を持つ担当者による再発行が必要なのかを確認します。再発行や旧権限の停止は、連携先・公開処理への影響を確認してから行い、移管作業の途中で一斉に失効させないようにします。
GitHub Actionsを利用している場合も、秘密情報はコードへ書き込まず、Secrets等の仕組みで管理します。担当者の個人アカウントだけに依存しない、必要最小限のアクセス設計を検討します。公式資料：GitHub ActionsのSecrets
改修見積もりは根拠と納品物をそろえて比較する
「古いので全体を作り直す」という説明だけでは、必要な改修と任意の改善を分けられません。現行バージョン、不具合の再現条件、影響する機能、対応期限の公式根拠を示してもらい、同じ条件で比較できる見積もりへ整えます。
| 確認軸 | 依頼したい説明 |
|---|---|
| 現状と問題 | 対象画面、再現手順、影響範囲、調査済み・未調査の区別 |
| 対応の必要性 | 必須・推奨・任意の区分と、その根拠 |
| 作業範囲 | 残す機能、廃止する機能、移行対象、対象外の作業 |
| 検収条件 | 確認する操作、合格条件、不具合時の修正範囲 |
| 納品物 | 改修済みソース、構成図、環境構築・公開・復旧手順 |
| 保守 | 更新頻度、障害時の窓口、対応時間、追加費用の扱い |
機能を減らす案を採用する場合は、利用者への影響と社内の代替作業も比較します。開発費が下がっても、日々の手作業が増えるなら、保守変更の目的を満たさない可能性があります。サイト運用全体の整理はEC運営・販売促進ガイドも参考にしてください。
検証・切替・復旧を順に確認する
- 読み取り確認：現行構成と公開版を記録し、ソース・設定・管理者の不足を洗い出します。
- 検証環境で再現：新担当者が文書を使って起動・ビルド・表示を確認します。顧客情報や本番通知を不用意に複製しません。
- 機能確認：商品、検索、カート、顧客アカウント、購入導線、計測、外部連携をチェックします。注文を伴う確認は担当者とテスト方法を合意します。
- 切替判断：変更日時、影響、承認者、中止条件、連絡先を決めます。
- 復旧確認：戻す対象のコードと設定、手順、担当者を特定します。
- 旧アクセス整理：引き継ぎ後の動作確認が終わってから、不要なアクセスや契約を整理します。
Oxygenのデプロイ履歴は復旧の手がかりになりますが、サイト外の設定やデータまで同時に戻せるとは限りません。コードの復旧と、外部サービス・設定・データの復旧を分けて確認してください。公式資料：Oxygenのデプロイ
社内の技術担当者がいない場合の進め方
社内に開発者がいない場合も、すべてを自社で実装する必要はありません。会社側は契約名義、管理責任、承認、業務上の合格条件を持ち、技術的な検証は引き継ぎ先へ依頼します。「自社で管理する」と「自社の社員だけで改修する」を分けると、必要な体制を考えやすくなります。
一人で運営する場合は管理者の不在時に備えた連絡先と保管場所を残します。複数担当の場合は公開の承認者を一人に決め、外部会社が複数ある場合はドメイン、フロント画面、アプリ、計測ごとに責任範囲を整理します。
引き継ぎ完了前のチェックリスト
- 公開URLと実装方式・公開元を照合した
- 本番に対応するソースと変更履歴を確認した
- 契約・納品・利用条件の未確認事項を整理した
- 新担当者が必要な範囲へアクセスできた
- 環境変数名と秘密値の保管方法を分けた
- 検証環境で構築・表示・主要機能を確認した
- 公開と復旧の手順を第三者がたどれた
- 外部サービス・請求・更新の担当者を決めた
- 作業中の変更と残課題を記録した
- 確認完了後に旧アクセスを整理する段取りを決めた
まとめ
Shopifyの制作会社から引き継ぐときは、ソースコードだけでなく、公開環境、権限、秘密情報の保管、外部サービス、公開・復旧手順を一組で確認します。Hydrogenを使う構成では、テーマの取得だけで本体を引き継いだと判断しないことが大切です。まず現行構成と不足資料を明確にし、検証できる条件を整えてから改修や本番切替を進めましょう。
確認日：2026年9月3日。画面・権限・仕様は変更されることがあります。本記事は運用上の確認項目であり、個別契約の法的判断や特定構成への移管手順を保証するものではありません。
