ECサイト制作の修正を何回まで受けるか｜先に決めておく

2026年3月8日

朝比奈蒼

この記事のポイント

✓ECサイト制作の修正対応は
✓回数を決めていないと際限なく続きます
✓修正と仕様変更の線引き

結論から書きます。ECサイト制作の修正対応でトラブルになる案件は、修正の質が低いから揉めるのではありません。何を修正と呼ぶのか、何回まで含むのかを着手前に決めていないから揉めます。制作の腕とは無関係のところで消耗するのは、正直なところもったいない。この記事では、ECサイト制作を受注したあとに修正対応で疲弊しないために、見積もりの段階で何を決め、進行中にどう運用するかを具体的に整理します。

修正回数を決めていない見積もりは、必ず後で揉める

制作の依頼を受けるとき、多くの人が画面数や機能で見積もりを組み立てます。ところが実際の作業時間を食うのは、作る時間ではなく直す時間です。ここを見積もりに入れていないと、作業が進むほど実質的な条件が悪くなっていきます。

「修正は何度でも対応します」の代償

営業上、修正無制限をうたいたくなる気持ちは分かります。ただ、これは相手のためにもなりません。回数の上限が無いと、依頼者側にも「一度でまとめて確認する」という動機が生まれないからです。結果として、思いついた順に少しずつ指摘が届き、そのたびに作業と確認が往復します。

さらに厄介なのは、無制限を前提にすると、依頼者が社内で意見を集約しなくなることです。上司が見て一言、担当者が見て一言、別部署が見て一言。誰も全体をまとめないまま、断片的な指摘だけが流れてきます。この状態になると、直しても直しても終わりません。

回数だけでなく「一回の定義」を決める

回数を決めればよいという話でもありません。2回までと書いてあっても、一回の中身が「思いついたときに一件ずつ送る」であれば、実質的には何十回にもなります。決めるべきは、回数と、一回の単位の両方です。

一回の定義は、「工程ごとに、まとめて一度で受け取る指摘のかたまり」とします。指摘の数ではなく、受け取る回数で数える。この定義を先に共有しておくと、依頼者側も社内でまとめてから出すようになります。運用が変わるだけで、作業量は目に見えて減ります。

修正と仕様変更を分ける

回数の話をする前に、そもそも何が修正なのかを定義しておく必要があります。ここが曖昧だと、回数を決めても意味がありません。

三つに分類する

現場で扱いやすいのは、次の三分類です。ひとつ目は不具合の修正。合意した仕様どおりに動いていない状態を直す作業で、これは回数に数えません。無条件で直します。ふたつ目は指摘の反映。合意した仕様の範囲内で、見た目や文言、配置を調整する作業です。これが回数に数える対象になります。三つ目は仕様変更。合意した内容そのものを変える依頼で、これは別途見積もりになります。

この三分類を、見積書の注記に書いておきます。書いてあるだけで、進行中の会話がまったく変わります。「これは仕様変更にあたるので、別途お見積もりを出します」と言えるのは、事前に定義があるからです。定義が無い状態で同じことを言うと、値上げの請求に聞こえます。

ECサイト特有の判断が難しい箇所

ECサイトの案件では、分類に迷う場面がいくつか決まっています。

商品ページのバリエーション設定はその代表です。色とサイズの組み合わせをどう持つかは、見た目の調整に見えて、実はデータ構造の話です。あとから組み合わせの持ち方を変える依頼は、指摘の反映ではなく仕様変更として扱うのが妥当です。

決済手段の追加も同じです。決済手段が一つ増えるだけで、確認画面、完了メール、注文管理の表示、返金の手順まで影響します。「決済をもう一つ足すだけ」という依頼は、規模が見た目より大きい。

配送設定も要注意です。地域別の送料、一定額以上の送料無料、複数配送先の扱い。これらは初期の要件確認で詰めきれていないことが多く、制作の後半になって「そういえば」と出てきます。要件の抜けであっても、合意した内容に含まれていなければ仕様変更です。

制作会社側の説明でも、修正の幅は部分的なものから全体の作り直しまで広いことが示されています。

当社では、お客様のニーズに合わせて柔軟な修正対応を行っています。1ページ単位での部分的な修正から、WEBサイト全体のリニューアルまで、幅広い要望にお応えします。また、定額制の保守管理プランも用意しており、継続的なサイト運営をサポートいたします。経験豊富なスタッフが、的確なアドバイスと迅速な対応で、お客様のホームページの価値向上をサポートします。出典: markernet.co.jp

同じ「修正」という語の下に、部分的な差し替えから全面的な作り直しまでが並んでいます。依頼者はこの区別を意識せずに言葉を使うため、受ける側が分類を提示するしかありません。

見積もりの段階で決めておく項目

着手前に決めるのは、次の五つです。ここまで決めておけば、進行中に判断で迷う場面がほとんど無くなります。

工程ごとに回数を割り当てる

修正回数は、案件全体でまとめて数えるのではなく、工程ごとに割り当てます。要件のすり合わせ、デザイン、実装、公開前の確認。それぞれに回数を置きます。

まとめて数えると、序盤で使い切ってしまうか、逆に終盤に集中して手が回らなくなります。工程ごとに区切ると、依頼者もその段階で確認すべきことに集中します。デザインの段階で決めたことを実装後にひっくり返す動きも減ります。

一回に含める範囲を書く

前述のとおり、一回の単位を明記します。「指摘は工程ごとに一括でお送りください。分割してお送りいただいた場合、それぞれを一回として数えます」。この一文があるかないかで、進行が変わります。

冷たく感じるかもしれませんが、実際には依頼者にとっても有利です。まとめて出すよう促されることで、社内の合意形成が早まり、結果的に完成が早くなります。

フィードバックの期限を決める

依頼者からの指摘をいつまでに受け取るかも決めます。確認依頼を出してから5営業日以内、といった形です。期限を過ぎた場合は次の工程に進む、と書いておきます。

これは納期を守るために必要な条件です。制作側の遅れではなく、確認待ちで止まっているケースは非常に多い。にもかかわらず、遅延の責任は制作側に寄せられがちです。期限を書いておけば、事実として誰の手元で止まっていたかが明確になります。

超過した場合の扱いを書く

回数を超えた修正をどう扱うかを決めます。選択肢は三つあります。都度見積もりで追加対応する、時間単位で精算する、公開後の保守契約に含める。案件の性質で選びます。

大事なのは、超過したら追加になる、という事実を先に伝えておくことです。超過してから初めて言うと、必ず反発されます。事前に書いてあれば、依頼者は超過しないように動きます。

対象外を明記する

修正に含まれないものも書きます。商品データの登録作業、写真の撮影や加工、原稿の執筆、公開後の運用作業。ECサイトの案件ではこのあたりが曖昧にされやすく、気づけば商品登録を延々と手伝っている、という事態になります。

契約書と見積書への書き方

決めたことは文書に落とします。口頭やチャットの合意は、担当者が替わった時点で消えます。

見積書の注記に入れる

見積書の下部に、修正に関する条件を五行程度で書きます。工程ごとの回数、一回の定義、フィードバックの期限、超過時の扱い、対象外の作業。長い契約書を読んでもらえなくても、見積書は必ず読まれます。

書き方は事務的でかまいません。むしろ感情を混ぜないほうが、後から参照したときに機能します。

発注前に一度読み合わせる

見積書を送るだけでなく、打ち合わせの場で条件の部分を読み上げて確認します。「ここだけ先に共有させてください」と前置きすれば、押しつけがましくなりません。読み合わせをした事実自体が、後の証拠になります。

このひと手間を省いた案件ほど、後半で揉めます。読んでいない、聞いていない、という話になったとき、送っただけの資料は弱い。

進行中の運用

条件を決めても、運用が雑だと機能しません。実際の進め方も設計しておきます。

確認依頼の出し方を固定する

こちらから確認を依頼するときは、毎回同じ形式で出します。確認してほしい範囲、確認してほしい観点、返答の期限、指摘の送り方。この四点を書いたテンプレートを用意しておき、工程ごとに使い回します。

観点を指定するのが要点です。「デザインの確認をお願いします」とだけ送ると、文言や機能の話まで返ってきます。「この段階では色使いとレイアウトについてご確認ください。文言は次の工程で確認いただきます」と書けば、指摘の範囲が絞れます。

指摘の受け取り方を決める

指摘は、口頭やばらばらのメッセージではなく、一覧の形で受け取ります。表計算ソフトの共有シートでも、専用のツールでもかまいません。列は、該当箇所、指摘内容、優先度、対応状況。

一覧にすると、指摘の数が可視化されます。依頼者自身が「思ったより多いな」と気づくことがあり、それだけで整理が進むこともあります。また、対応済みかどうかを双方が同じ画面で確認できるため、「直っていない」という行き違いが減ります。

窓口を一人に絞る

依頼者側の窓口を一人に固定してもらいます。複数人から直接指摘が届く状態は、矛盾した要望が混ざる原因になります。誰かが赤にしたい、別の誰かが青にしたい、という状況で板挟みになるのは制作側です。

窓口を絞る依頼は、遠慮せずに最初にします。「社内でご意見をまとめていただいたうえで、ご担当者様からまとめてお送りください」と書けば十分です。これは相手の社内調整を促す行為なので、嫌がられることはあまりありません。

揉めやすい場面と、その場での対処

それでも起きる典型的な場面があります。事前に対処を決めておくと、その場で慌てません。

公開直前に大きな変更が来る

公開日が近づいてから、根本的な変更の依頼が来ることがあります。ここで即座に断ると角が立ち、受けると納期が崩れます。

対処は、公開日と変更のどちらを優先するかを相手に選ばせることです。「この変更を反映する場合、公開日は動かす必要があります。どちらを優先されますか」。判断を相手に返すのが正解で、こちらが勝手に納期を守ろうとして無理をすると、結果的に品質が落ちて評価も下がります。

「イメージと違う」と言われる

抽象的な否定が来たときは、具体化を手伝います。何がどう違うのかを言語化してもらう作業に付き合う。参考にしているサイトを挙げてもらう、どの部分が近くてどの部分が遠いかを聞く。

このやり取りは修正回数に数える前の段階です。指摘が具体化するまでは作業に入らない、というルールを自分のなかに持っておくと、無駄な作り直しが減ります。着手前の要件確認で参考サイトを複数もらっておくと、この場面自体が起きにくくなります。

公開後に修正依頼が続く

公開したあとに小さな修正が続くのは自然なことです。問題は、それが無償の作業として当然視されることです。

対処は、公開の時点で線を引くことです。「公開後2週間以内の不具合対応は含みます。それ以降の変更や追加は保守の範囲になります」と伝え、保守の条件を別に用意しておきます。定額の保守を用意しておくと、依頼者にとっても相談先が明確になり、双方にとって扱いやすくなります。

修正が増える原因を、着手前に潰す

条件を決めるのと並行して、そもそも修正が増えない進め方を設計します。回数の管理より、こちらのほうが効きます。

参考にするサイトを複数もらう

デザインの手戻りは、好みの言語化ができていないことから起きます。着手前に、参考にしているサイトを3件以上挙げてもらいます。そして、それぞれについて「どこが好きか」を一言もらう。

好きな理由を聞くのが要点です。同じサイトを挙げても、色を見ている人と、情報の並びを見ている人では、求めているものが違います。この確認を省くと、完成後に「そういう意味ではなかった」という話になります。

構成の段階で合意を取る

見た目を作り込む前に、要素の並びだけを決めた簡素な画面で合意を取ります。商品一覧の並び順、絞り込みの項目、商品ページに置く情報の順番、購入までの導線。この段階なら、変更しても作業量が小さい。

デザインが仕上がってから並びを変える依頼が来ると、作業量は跳ね上がります。手戻りのコストが低い段階で決めるほど、全体が楽になります。

文言と商品データの確定時期を決める

ECサイトの制作では、文言と商品データが遅れることが常態化しています。仮のテキストで進めて、あとから差し替える前提で組むこと自体は問題ありません。問題は、差し替えのタイミングで文字量が大きく変わり、レイアウトが崩れることです。

対策としては、文字数の目安を先に伝えることです。「この見出しは全角20文字程度を想定しています」と伝えておけば、原稿の段階で調整してもらえます。商品データについては、想定する項目と件数の規模を早い段階で確認し、誰がいつまでに用意するかを決めます。

確認の観点を工程ごとに書き出して渡す

依頼者は、何を見ればよいのかを知りません。だから思いついたことを全部書いてきます。着手時に、工程ごとの確認観点を一覧にして渡しておくと、この状態が改善します。

構成の段階では並び順と情報の過不足、デザインの段階では配色と余白と文字の大きさ、実装の段階では動作と表示の崩れ、公開前は購入の一連の流れと問い合わせの動作。それぞれの段階で見るべきものを書いて渡します。

この一覧は、依頼者の社内でも共有されます。複数人が確認する場合でも、同じ観点で見てもらえるようになり、矛盾した指摘が減ります。手間は最初の一回だけで、案件をまたいで使い回せます。

環境の作り方で、修正のコストが変わる

技術的な組み立て方でも、修正対応の負担は大きく変わります。ここは受ける側の裁量で決められる部分です。

依頼者が自分で直せる範囲を渡す

文言や画像の差し替えを依頼者側でできる状態にしておくと、細かい修正依頼が激減します。管理画面から編集できる箇所を増やし、その使い方を短い資料にまとめて渡す。

ここを渡すと仕事が減ると考える人もいますが、実際には逆です。細かい依頼から解放されるぶん、設計や改善といった時間単位の価値が高い作業に集中できます。依頼者からの評価も上がります。

確認用の環境を分ける

公開中のサイトを直接触りながら確認してもらう進め方は、事故のもとです。確認用の環境を分け、そこで確認を済ませてから反映する。ECサイトでは注文データが動いているため、この分離は必須に近い。

環境を分けておくと、「確認中に本番が壊れた」という最悪の事態を避けられます。修正のたびに緊張する状態は、判断を鈍らせます。

やり取りの記録を残す

指摘と対応の記録は、必ず追える形で残します。共有シートの履歴でも、メッセージのやり取りでもかまいません。重要なのは、いつ何を依頼され、いつ対応したかが分かることです。

記録があると、認識の食い違いが起きたときに事実で確認できます。責任を追及するためではなく、話を早く終わらせるためです。感情の応酬になる前に、記録を見て事実を揃える。これができる案件は、揉めても長引きません。

相手の体制を、着手前に確認する

同じ条件を書いても、相手の社内体制によって進行の実態は変わります。契約前に確認しておくべき点があります。

最終的に決める人は誰か

打ち合わせに出てくる担当者が決裁者とは限りません。決める人が別にいる場合、その人がどの段階で登場するかを確認します。終盤に初めて登場して全部ひっくり返る、という事態は、この確認で防げます。

可能であれば、要件を決める段階とデザインの段階で、決裁者にも確認してもらう約束を取り付けます。忙しくて出られない場合は、担当者経由で承認を得たことを記録に残します。

商品データと画像は誰が用意するか

ECサイトの案件では、ここが最大の遅延要因です。商品の点数、写真の有無、説明文の準備状況を、着手前に確認します。用意できていない場合、制作側が代行するのか、公開時点では一部のみで進めるのかを決めます。

代行する場合は、明確に別の作業として見積もります。制作の一部として扱うと、際限なく作業が増えます。

公開日は動かせるか

キャンペーンや催事に紐づいた公開日は動かせません。動かせない日程がある案件では、修正回数の管理がより重要になります。逆に日程に余裕がある案件なら、回数を柔軟にしても破綻しません。

この確認を最初にしておくと、進行の設計そのものを変えられます。日程が固い案件では、確認の期限を短く設定し、期限を過ぎたら次に進むという運用を明示しておきます。

断りづらい依頼への答え方

条件を決めていても、その場で断りにくい言い方をされることがあります。答え方を用意しておくと、関係を壊さずに線を保てます。

「ついでにこれもお願いできますか」

小さな追加依頼は、単体で見れば断るほどのことではありません。ところが積み重なると、無視できない量になります。しかも記録に残らないため、あとから「そんなに作業していない」という認識のずれを生みます。

答え方は、断るのではなく可視化することです。「対応できます。作業一覧に追加して、次回の進捗でまとめてご報告します」と返し、一覧に記録します。無償で受ける場合でも記録は残す。次の見積もりや契約更新のときに、実際の作業量を示す材料になります。

「前に頼んでいたところはやってくれた」

比較を持ち出されたときに、感情的に反応しないことです。前の相手がどうだったかは、いまの契約条件とは関係ありません。返すべきは、条件の再確認です。「今回の契約では、この範囲でお見積もりしています。追加をご希望でしたら、条件を含めて改めてご提案します」。

この返し方なら、相手を否定せずに条件へ話を戻せます。正直なところ、比較を持ち出す相手ほど条件を読んでいないことが多く、そこを丁寧に共有し直すだけで収まる場面がほとんどです。

「これくらいなら無料でできますよね」

作業の重さは、外からは見えません。管理画面から一箇所直すだけに見える依頼が、実際には確認と反映と検証を伴うことは珍しくない。ここで「簡単ですよ」と答える癖がつくと、あらゆる依頼が簡単なものとして扱われるようになります。

答えるときは、作業の中身を短く説明します。「反映自体はすぐですが、注文の流れに影響するため、確認まで含めて半日ほど見ています」。金額の話をする前に、工程の話をする。これだけで、依頼者の見積もり感覚が変わります。

感情ではなく手順で返す

どの場面にも共通するのは、断る言葉ではなく手順を返すことです。追加の依頼には見積もりの手順を、範囲外の相談には分類の手順を、急ぎの依頼には日程の選択肢を返す。判断そのものを相手に渡す形にすると、対立になりません。

制作の現場では、実力があるのに条件面で消耗して疲れてしまう人をよく見ます。腕の問題ではなく、手順を用意していないだけのことが多い。手順は一度作れば使い回せます。

保守と修正を分けて設計する

制作の仕事を単発で終わらせず、公開後の運用まで含めて設計すると、修正対応の位置づけが変わります。

保守に含めるものを決める

保守の範囲は、不具合の対応、プラットフォームの更新確認、軽微な文言や画像の差し替え、問い合わせへの回答。ここまでを定額に含めるのが一般的な形です。デザインの変更や機能の追加は、その都度の見積もりにします。

範囲が明確な保守は、依頼者にとっても予算を組みやすく、受ける側にとっても継続の収入源になります。制作中の修正対応を過剰に抱え込むより、公開後の関係として設計するほうが健全です。

引き渡しの形を決めておく

保守を受けない場合は、引き渡しの内容を明確にします。管理画面の権限、更新手順の資料、使用しているサービスの一覧。渡すものを決めておかないと、公開後に延々と質問が届きます。

長くこの市場を見てきた立場から言うと、修正対応で消耗している人ほど、良かれと思って線を引かずに引き受けています。ところが依頼者の側は、無償で受けてもらった作業を「サービスが良い」とは記憶しません。記憶されるのは、進行が滞りなく進んだかどうかです。線を引いたほうが評価が上がるのは、そのためです。中間コストの乗らない直接の取引では、条件のすり合わせも自分で行いますが、そのぶん決めた条件がそのまま手取りに反映されます。手数料0%の環境が効くのは、この決めたことが目減りしない点にあります。

案件の性質によって、決め方を変える

ECサイトの案件は、依頼者の業種と規模で進行の性質が変わります。募集の内容を見ると、その傾向がはっきり出ています。ECサイト制作・運用・画像制作のお仕事では、新規構築の依頼と、既存サイトの改修や運用代行の依頼が並んでおり、それぞれ修正対応の意味が違います。新規構築では工程ごとの回数配分が効き、改修案件では作業単位の切り分けが効きます。

運用まで含めて任される案件では、公開後の分析や改善提案が範囲に入ることもあります。その領域の業務内容を確認したい場合は、AI・マーケティング・セキュリティのお仕事の募集内容が参考になります。制作と運用のどちらに軸足を置くかで、契約の組み立て方が変わります。

職種としての位置づけを把握しておきたい場合は、ソフトウェア作成者の年収・単価相場にある公的統計ベースのデータが参考になります。また、条件の交渉が文化的に厳しく行われる海外案件の作法を知っておくと、国内案件でも条件を先に決める習慣が身につきます。Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法では、契約前に範囲を確定させる進め方が紹介されています。

条件を文書にする力そのものを鍛えたい場合、ビジネス文書検定で問われる文書構成の型が実務に直結します。見積書の注記も確認依頼のテンプレートも、要は読み手が誤解しない文書を書けるかどうかの問題です。修正対応で揉めるかどうかは、制作の腕より先に、この部分で決まっています。

よくある質問

Q. 修正回数は何回に設定するのが妥当ですか？

案件全体で数えるのではなく、工程ごとに割り当てるのが実務的です。要件のすり合わせ、デザイン、実装、公開前の確認のそれぞれに回数を置きます。まとめて数えると序盤で使い切るか終盤に集中してしまいます。回数そのものより、一回の単位を「工程ごとに一括で受け取る指摘のかたまり」と定義することのほうが重要です。

Q. 不具合の修正も回数に数えてよいですか？

数えません。合意した仕様どおりに動いていない状態を直す作業は、制作側の責任範囲であり無条件で対応します。回数に数えるのは、仕様の範囲内で見た目や文言、配置を調整する指摘の反映です。合意内容そのものを変える依頼は仕様変更として別途見積もりにします。この三分類を見積書の注記に書いておくと進行中の判断が楽になります。

Q. 「イメージと違う」と言われたらどうすればよいですか？

すぐに作り直さず、まず具体化を手伝ってください。どの部分がどう違うのか、参考にしているサイトはどれか、どこが近くてどこが遠いのかを聞きます。指摘が具体化するまで作業に入らないと決めておくと、無駄な作り直しを防げます。着手前の要件確認で参考サイトを複数もらっておくと、この場面自体が起きにくくなります。