ECサイト・Shopifyエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのECサイト・Shopifyエンジニアがつまずきやすいのは、請負の構築で作る範囲が膨らむこと、本番のストアを直接触って事故を起こすこと、Webhookの欠落や仕組みの提供終了への備えが足りないこと、繁忙期の待機の扱いがあいまいなことです。どれも、ECが「止まると売上が止まる」仕事であり、しかも管理画面から誰でも設定を変えられるという性質から起きます。

対策の基本は、範囲と権限と反映の手順を参画の最初に決め、変更の記録と照合の仕組みで守ることです。この記事では、契約・現場・技術・お金の順に、ECエンジニアならではの場面と対策を整理します。契約前に確かめる項目の一覧はECサイト・Shopifyエンジニアの案件の選び方で扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

請負の構築で、作る範囲が少しずつ広がる

ストアの新規構築は請負で受けることが多く、商品データの登録、画像の加工、ページの追加、デザインの修正の繰り返しなど、見積もりの外の作業が後から増えやすい仕事です。「ついでにこのアプリも入れてほしい」「この特集ページも」と頼まれるうちに、時間あたりの報酬が目減りしていきます。

対策：作るページの数、テーマのセクションの数、商品データの登録をどちらが担うか、修正の回数、検収の基準を、着手の前に書面で確かめます。範囲の外の依頼が来たときの扱いは業務範囲が変わったときの記事と追加の依頼の断り方、契約の形の違いは準委任契約と請負契約の違いをご覧ください。

ストアやアプリの契約者が自分になってしまう

事業者から直接依頼を受けた構築で、ストアやアプリ、決済サービスの契約を開発者のアカウントで済ませてしまうと、引き渡しのときに移す手間がかかり、費用や責任の所在もあいまいになります。

対策：ストアの所有者、アプリの費用を払う人、決済サービスの契約者は、最初から事業者にしてもらい、自分は付与された権限で作業します。

公開後の不具合をどこまで直すかが決まっていない

請負の構築では、公開後に見つかった不具合を無償で直す範囲と期間が決まっていないと、運用の相談がいつまでも続くことがあります。

対策：引き渡し後の対応の期間と範囲、それを超えたときの扱い（運用の契約に切り替えるなど）を、契約の段階で決めておきます。

現場でのつまずき

本番のテーマや設定を直接変えて事故を起こす

運用中のストアでは、公開中のテーマを直接編集したり、管理画面の設定をその場で変えたりすると、表示の崩れや価格・送料の誤りが、そのまま買い手に見えてしまいます。

対策：テーマは複製したものや開発用の環境で作業し、確かめてから反映します。誰が、いつ、どの方法で本番に反映するかを最初に決め、管理画面の設定の変更も、いつ・何を・なぜ変えたかを課題管理の道具に残します。

権限が広すぎる、または足りない

Shopifyのヘルプセンター（2026年10月時点）では、ストアの権限はストア単位でかかり、個々の注文や商品、顧客の単位では絞れないと説明されています。広い権限をもらうと、顧客の情報に触れられる範囲も広がり、意図しない変更の責任を問われる立場になりかねません。逆に足りないと、確認のたびに待ちが発生します。

対策：担う作業に必要な権限だけを窓口と確かめてもらい、それ以外の作業は運用担当に頼む線を決めます。顧客の情報の扱いは個人情報を扱う業務委託の記事で整理しています。

不具合の原因が、自分の作ったものかどうか分からない

ECのストアには、テーマ、複数のアプリ、決済サービス、外部の連携先が重なっています。注文が通らない、表示がおかしいといった不具合が起きると、まず「最後に触った人」が疑われやすくなります。

対策：入っているアプリと、それぞれがテーマに足しているコード、連携先の問い合わせ窓口を一覧にしておきます。自分の変更は履歴で示せるようにしておくと、切り分けが早くなります。

セールの直前に変更が集中する

ECでは、セールや新商品の発売の直前に、事業側から修正や追加の依頼が集中しがちです。直前の変更は、確かめる時間が取れないまま本番に出ることになります。

対策：反映できる最後の日（変更を控える期間）を事業側とそろえ、それより後の依頼は、急ぎかどうかを窓口と一緒に分けてもらいます。

技術でのつまずき

Webhookが「必ず届き、順番どおり」だと考えて作る

Shopify.devのWebhookの説明（2026年10月時点）では、配信は常に保証されるものではなく、同じ種類の通知の順番も保証されないと明記されています。そのうえで、署名の検証と重複の除外、定期的にデータを取り直す照合の処理が勧められています。これを想定せずに連携を作ると、注文の取りこぼしや二重の登録が起き、出荷や在庫のずれとして表に出ます。

対策：通知が来なかったとき、二重に来たとき、順番が逆だったときの動きを設計に入れ、日次などで照合する処理を用意します。

APIの版の更新と、仕組みの提供終了を見落とす

Shopify.devでは、APIの新しい版は3か月ごとに出され、各安定版は少なくとも12か月サポートされると説明されています（2026年10月時点）。また、Shopify Scriptsは2026年6月30日に廃止され、サンクスページと注文状況ページのcheckout.liquidと追加スクリプトは2025年8月28日に提供を終えています（いずれも2026年10月時点の公式ページの記載）。自分が作った処理がどの版や仕組みに依存しているかを把握していないと、動かなくなってから慌てることになります。

対策：担当したストアごとに、使っているAPIの版と仕組みを一覧にしておき、変更履歴や提供終了の告知を定期的に確かめます。更新の作業が契約の範囲に入るかも、窓口と確かめておきます。

設定やアプリで済むことを作り込む

管理画面の設定や既製のアプリで足りる要件を自分で作ると、保守の手間が増え、自分が抜けた後に誰も直せない仕組みが残ります。逆に、アプリを重ねすぎると表示速度が落ち、費用もかさみます。

対策：作る前に「設定で済むか」「既製のアプリで済むか」「作るか」を並べ、選んだ理由を残します。判断の考え方はECサイト・Shopifyエンジニアのスキルの記事で触れています。

お金でのつまずき

繁忙期の待機や夜間の対応が精算されない

セールの開始時刻や年末の繁忙期に、監視や待機を求められることがあります。待機の時間を稼働に数えるかが決まっていないと、報酬に反映されないまま負担だけが増えます。

対策：待機と対応の時間の扱いを参画前に確かめ、稼働を日々記録します。精算幅を超えそうな段階で窓口に伝えてください。精算の仕組みは精算幅の記事で解説しています。

公開や切り替えの後に、契約が突然終わる

構築や移行の案件は、公開や切り替えの後に終わることが多く、運用の案件も事業側の予算の見直しで区切られることがあります。フリーランス法では、6か月以上の業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。

対策：契約期間と公開・切り替えの日を並べて見ておき、更新の見込みを早めに確かめます。契約期間の考え方は契約期間の記事をご覧ください。

よくある質問

構築の途中で、事業側の要望が大きく変わりました。どうすればよいですか？

まずは、何が変わったのかを書き出し、契約で決めた範囲と照らし合わせます。そのうえで、紹介を受けたエージェントや発注側の窓口に早めに伝えてください。範囲の変更を口頭だけで受けると、報酬や納期の見直しが後から難しくなります。

自分が作った連携で注文の取りこぼしが起きたら、損害賠償を求められますか？

契約の形や内容、作業に落ち度があったかどうかで判断が変わります。請負と準委任では負う責任の中身も違います。不安がある場合は、契約書の損害賠償の条項を読み、弁護士などの専門家にご相談ください。日ごろから照合の処理を入れておくと、取りこぼしを早く見つけ、影響を小さくできます。

運用担当が管理画面で設定を変えて表示が崩れました。誰の責任になりますか？

契約で決めた範囲と、変更の経緯によって変わります。まずは何がいつ変わったかを記録から確かめ、事実を窓口に伝えます。再発を防ぐには、運用担当が触ってよい設定と、開発者に頼む変更の線を一緒に決めておくことをおすすめします。