ECサイトを安定して売上を生み続けるサイトに育てるには、構築後の運用保守をどこに、どう発注するかが大きな分かれ目になります。とくにECは決済・カート・在庫連携といった「止まれば即売上損失」につながる機能を抱えているため、内製で抱え込むか外注するか、外注するならどんな契約と体制で任せるかという判断が経営に直結します。ところが実際には「保守込みだと思っていた作業に追加費用が発生した」「障害時に複数のベンダーが責任を押し付け合って復旧が遅れた」といった発注設計のミスによるトラブルが後を絶ちません。
この記事では、ECサイト運用保守を外部に発注・外注・委託する際の具体的な進め方を、保守範囲の明文化からSLA設定、契約形態の選び方、見積もりの取り方、ベンダー移行までを一気通貫で解説します。EC特有の繁忙期対応や決済セキュリティの責任分界、過去の裁判例を踏まえた契約上の落とし穴まで踏み込みますので、これから運用保守先を選定する担当者の方が、認識ズレなく安心して任せられる発注ができるようになるはずです。
ECサイト運用保守を発注・外注する前に押さえる全体像
発注の話に入る前に、まず「何を任せるのか」を自分の言葉で整理しておくことが重要です。ECサイトの運用保守は、日々の監視やバックアップといった「運用」と、障害復旧やアップデート、セキュリティ対応といった「保守」の両輪で成り立っています。この境界が曖昧なまま発注すると、後から「それは契約範囲外です」と言われる典型的なトラブルにつながります。
EC運用と保守で外注範囲がどう変わるか
ECサイトにおける「運用」とは、サーバーやサイトの死活監視、注文データのバックアップ、商品登録や価格改定の反映、アクセス状況のモニタリングなど、日常的に発生するオペレーションを指します。一方「保守」は、決済不具合の修正、カートのバグ対応、CMSやプラグインのバージョンアップ、脆弱性パッチの適用といった、サイトの健全性を維持するための技術作業です。
外注を検討する際は、この運用と保守のどこまでを委託するかを切り分ける必要があります。たとえば商品登録のような日常運用は自社で行い、決済まわりの保守やセキュリティ対応だけを専門会社に任せるという分担も可能です。発注範囲を広げるほど月額費用は上がりますが、属人化リスクを外部の体制で吸収できるメリットも生まれます。自社のEC担当者の人数とスキル、そして「止められない機能」がどこかを基準に、委託ラインを決めていくのが現実的です。
内製・外注・併用のどれを選ぶか
運用保守の体制には、完全内製、完全外注、そして両者を組み合わせる併用型の三つがあります。完全内製はノウハウが社内に蓄積される反面、ECに精通したエンジニアの採用・育成コストがかかり、担当者が一人だけだと退職と同時に運用が止まる属人化リスクを抱えます。完全外注は専門性と24時間対応を確保しやすい一方、社内にノウハウが残りにくく、ベンダー依存が強まります。
多くのEC事業者にとって現実的なのは、商品更新やキャンペーン設定など売上に直結する運用は社内で握りつつ、技術的に難易度が高い保守と緊急障害対応を外注する併用型です。将来的に社内へノウハウを取り込んで内製比率を上げていきたい場合は、発注の段階で「構成図や手順書の納品」「定例での技術共有」を契約条件に含めておくと、後の内製化移行がスムーズになります。発注方針は単なるコスト比較ではなく、自社が運用保守の主導権をどこまで持ちたいかという経営判断として考えることをおすすめします。
発注前に準備すべきドキュメントと保守範囲の明文化
運用保守の発注で最もトラブルが起きやすいのが「どこまでが契約範囲か」の認識ズレです。これを防ぐ鍵は、発注前の準備にあります。曖昧な依頼で見積もりを取ると、各社の見積条件がバラバラになって比較もできず、契約後も「これは追加費用」のやり取りが続くことになります。発注の質は準備の質で決まると言っても過言ではありません。
RFPと現状資料の整備で手戻りを減らす
発注前に用意したいのが、提案依頼書（RFP）と現行サイトの構成資料です。RFPには、対象となるECサイトのURLと利用プラットフォーム、月間注文件数やアクセス規模、利用している決済代行サービスや外部連携（在庫管理・物流・会計など）、現在困っていることや期待する対応範囲を整理します。的確な質問リストとRFPを用いてベンダー選定を行うと、開発・保守後の手戻りコストを大きく削減できることが知られており、認識合わせの精度が成果に直結します。
あわせて、サーバーやドメインの契約情報、システム構成図、利用中のCMSやプラグインの一覧、過去の障害履歴といった現状資料も整理しておきます。これらが揃っていれば、ベンダーは引き継ぎ調査の工数を正確に見積もれるため、不要なバッファを乗せた割高な見積もりを避けられます。逆に資料がまったくない状態だと、ベンダーは現状把握のための調査費を上乗せせざるを得ず、初期費用が膨らみます。発注の進め方としては、社内の情報を棚卸しする工程を最初のステップに置くことが鉄則です。
EC特有の保守範囲を明文化する
ECサイトの保守範囲は、コーポレートサイトより複雑です。決済処理やカート機能のバグ修正、繁忙期のアクセス集中への負荷対策、在庫・受注データの外部システム連携、商品ページの軽微な修正、CMSやプラグインの脆弱性対応など、対象範囲を一つずつ書き出して「含む・含まない」を明確にする必要があります。とくに軽微な機能追加やデザイン変更を保守に含めるのかは、後の追加費用トラブルの火種になりやすいため、明文化が欠かせません。
たとえば「決済エラーの調査と修正は保守に含むが、新しい決済手段の追加は別途見積もり」「セール用バナーの差し替えは含むが、キャンペーンページの新規制作は別途」というように、線引きを文書として残します。この明文化のレベルが、そのままトラブル予防の保険になります。発注の段階で範囲を詰めるのは手間に感じられますが、ここで曖昧さを残すと運用が始まってから何倍もの調整コストがかかります。EC運用保守の発注で一番の力を注ぐべき工程は、この保守範囲の言語化だと考えてよいでしょう。
SLAと契約形態の決め方
ECサイトは障害が即売上損失に直結するため、どの程度のスピードと品質で対応してもらえるかをSLA（サービス品質保証）として数値で合意することが重要です。あわせて、運用保守をどの契約形態で結ぶかも、責任範囲やコストに影響します。SLAと契約形態は、発注の安心感を左右する両輪と言えます。
EC向けSLAで合意すべき数値
SLAでは、サイトの稼働率（例として99.9%）、障害受付から一次対応までの応答時間、復旧目標時間を数値で取り決めます。IT運用アウトソーシングの目安としては、重大な障害時で初回応答15分以内・解決4時間以内、通常の問い合わせで応答2時間以内・解決8時間以内といった水準が一つの基準になります。ECの場合は、決済が止まる障害とバナー表示が崩れる障害では深刻度がまったく違うため、障害をレベル分けして、それぞれに応答時間と復旧目標を設定するのが実務的です。
さらにEC特有の論点として、セールや大型キャンペーンといった繁忙期の対応体制をSLAに織り込むことが欠かせません。普段は平日日中対応でも、繁忙期だけは深夜・休日も含めた緊急体制を組んでもらう、といった条件を発注時に交渉しておきます。SLAは未達時のペナルティ（料金減額など）まで合意して初めて実効性を持ちます。数値を決めずに「迅速に対応します」という口約束だけで契約すると、いざという時に対応の遅れを問えなくなる点に注意が必要です。
準委任と請負の使い分け
運用保守の契約は、業務の遂行そのものを目的とする「準委任契約」が一般的です。日々の監視や問い合わせ対応のように、成果物を一つに定めにくい継続的な業務に適しているためです。一方、特定機能の改修や新しいキャンペーンページの制作といった、明確な成果物を伴う作業は「請負契約」が向いています。多くのEC保守契約は、月額の準委任をベースに、まとまった改修だけ請負で切り出すハイブリッド構成になります。
契約形態を巡るリスクは、過去の裁判例にも表れています。保守契約をめぐる東京地裁の平成24年4月25日判決では、ベンダーが見積もり工数を超過した分の報酬を請求したものの、超過原因がユーザー側の追加指示に起因する場合に限ってユーザー負担とされ、請求の一部しか認められませんでした。この判決が示すのは、追加作業の発生原因と費用負担のルールを契約時に明確にしておくことの重要性です。発注時に「どんな場合に追加費用が発生し、誰がどう承認するのか」を取り決めておけば、こうした紛争の芽を事前に摘めます。
決済・セキュリティの責任分界と委託先選定
ECサイトは決済情報や個人情報という、漏洩すれば事業の存続に関わる資産を扱います。だからこそ、委託先を選ぶ際はセキュリティ対応力と責任分界の明確さを最重視する必要があります。価格の安さだけで選ぶと、障害時の復旧が大幅に遅れたり、誰が対応すべきか不明確で復旧が止まったりするリスクが高まります。
決済・個人情報まわりの責任範囲を切り分ける
ECサイトの決済は、自社サイト・決済代行サービス・カード会社など複数の事業者が関わるため、「どこまでが保守ベンダーの責任で、どこからが決済代行側の責任か」を契約時に明確にしておく必要があります。クレジットカード情報を扱う以上、カード情報保護の国際基準であるPCI DSSへの準拠が求められる場面もあり、その準拠責任を自社・ベンダー・決済代行のどこが担うのかを発注時に確認しておくことが欠かせません。
責任分界が曖昧なまま複数ベンダーが関わると、障害時に深刻な事態を招きます。実際、障害発生時に「ネットワーク側」「サーバー側」「装置側」とそれぞれの担当会社が責任を転嫁し合い、復旧が大幅に遅れた事例が報告されています。これを防ぐには、発注の段階で障害発生時の一次対応窓口を一本化し、各事業者の責任範囲を図にして関係者で共有しておくことが有効です。複数の外部パートナーが入る場合こそ、誰が司令塔になるのかを事前に決めておくことが、ECの売上を守ることにつながります。
セキュリティ実績と対応力で委託先を見極める
委託先を選定する際は、EC保守の実績、24時間365日の障害対応体制、決済・セキュリティ対応の経験、そしてビジネス視点での改善提案力を確認します。とくにセキュリティについては、WAF（Webアプリケーションファイアウォール）の導入や常時SSL化、ログ監視、脆弱性パッチの即時適用といった具体的な対策をどこまで実施できるかを質問しておくべきです。保守を怠った結果、サーバーがハッキングされ、企業サイトの内容が無関係なコンテンツに書き換えられた事例も実在します。
選定にあたっては、複数社から相見積もりを取り、価格だけでなく対応範囲・体制・実績を横並びで比較することをおすすめします。具体的なベンダー候補の比較や選び方の詳細は、ECサイト運用保守でおすすめの開発会社・ベンダー6選と選び方で解説していますので、あわせてご覧ください。なお契約後に、提案時のエース人材が別案件に引き抜かれ、経験の浅いメンバーばかりになってしまう失敗もあります。担当者の固定化や引き継ぎ時の品質維持についても、発注前に確認しておくと安心です。
見積もりの取り方と契約締結前チェックリスト
発注の最終段階では、見積もりを正しく読み解き、契約書の重要条項を漏れなく確認します。ECの運用保守費用は規模やSLA水準によって大きく変動するため、金額の妥当性を判断する目線を持っておくことが、適正な発注につながります。
見積もりの相場観と内訳の見方
運用保守費用の一般的な目安は、開発費用の15%程度を年間でかけるという考え方です。費用構造は、サーバーやドメインなどの「維持費」、更新や障害対応・メンテナンスといった「管理費」、集客やコンサルティングを含む「運用費」の三つに分けて捉えると、見積もりの内訳を理解しやすくなります。月額は数万円から数百万円までと幅広く、サイトの規模や求めるSLA水準によって大きく変わります。
見積もりを比較する際は、月額固定型か従量課金型かという課金方式の違いにも注目します。アクセスや注文の変動が大きいECでは、繁忙期に費用が跳ね上がる従量型より、想定範囲を月額固定で押さえつつ大規模対応のみ別途とする方式が予算管理しやすいケースもあります。投資判断としては、ECの損益分岐点（たとえば100万円の費用に対し利益25万円といった利益率20%の感覚）を踏まえ、運用保守費が売上と利益を守るための投資として見合うかを評価します。費用の詳しい相場や内訳は、ECサイト運用保守の見積相場や費用・コスト・値段についてで具体的に解説しています。
契約締結前に確認すべき条項
契約書を交わす前に確認すべき主要な条項は次のとおりです。保守範囲が明文化されているか、SLAの数値と未達時の扱いが盛り込まれているか、追加費用の発生条件と承認フローが定義されているか、途中解約のルールと予告期間が明確か、そして契約終了時のデータ返却と引き継ぎ支援が義務付けられているか。これらはどれもトラブル予防に直結する条項です。
とくに見落とされがちなのが、契約終了時のデータ返却と免責に関する条項です。クラウドの広域障害のように、ベンダーの努力では対応しきれない事象に対する免責範囲をどう定めるかは、いざという時の責任所在を左右します。発注前にこのチェックリストを一つずつ潰しておけば、運用が始まってから「聞いていない」「契約書に書いていない」という事態を避けられます。契約条項の確認は地味な作業ですが、ここを丁寧に行うことが、結果的に最も大きなリスクヘッジになります。
ベンダー切り替え・移行をスムーズに進める方法
すでに別のベンダーに運用保守を委託していて、対応品質や費用に不満があり乗り換えを検討するケースも多くあります。EC運用保守の発注では、新規発注だけでなく、既存ベンダーからの移行をいかに止めずに進めるかも重要なテーマです。移行は計画を誤ると、売上を生むサイトを止めてしまう危険があります。
引き継ぎ資料の受領と並行稼働
ベンダーを切り替える際は、旧ベンダーから構成図やサーバー情報、IPアドレス、各種アカウント、運用手順書を確実に受領することが第一歩です。ここで怖いのが属人化の罠で、ドキュメントに残っていない暗黙知が引き継ぎ時の致命的なトラブル要因になります。「特定の順番でないと正常に立ち上がらない」「月初だけ特別な処理を手動で実行している」といった運用ノウハウは、書面に残っていないことが多いため、旧ベンダーが在籍しているうちに洗い出しておく必要があります。
移行のリスクを最小化するには、旧ベンダーと新ベンダーが一定期間並行して稼働する移行期間を設けるのが定石です。いきなり全面切り替えを行うと、引き継ぎ漏れによる障害が起きた際に対応できる人がいなくなります。並行稼働の間に新ベンダーが実際の運用を経験し、想定外の挙動を潰しておけば、本切り替え後のトラブルを大幅に減らせます。移行スケジュールは、ECの繁忙期を避けて閑散期に設定するのが鉄則です。
将来の内製化を見据えた発注設計
外注しながらも、将来的には社内に運用保守ノウハウを蓄積して内製比率を高めたいという企業も増えています。その場合、発注の段階から内製化を見据えた条件を盛り込んでおくと移行がスムーズです。具体的には、対応内容を記録した手順書やナレッジを定期的に納品してもらう、月次の定例会で技術的な判断の背景を共有してもらう、社内エンジニアがベンダーの作業に同席できるようにする、といった取り決めが有効です。
こうしたノウハウ移転を契約に組み込んでおけば、外注はコストの垂れ流しではなく、社内育成と並走する投資に変わります。最初は障害対応まで含めて全面的に外注し、徐々に日常運用を内製へ移し、最後に高難度の保守だけを外部に残すといった段階的なロードマップを描くのが現実的です。発注を単発の取引としてではなく、自社の運用体制を育てる中長期の枠組みとして設計する視点を持つと、ベンダーとの関係もより建設的なものになります。運用保守の進め方そのものをより深く知りたい場合は、ECサイト運用保守の進め方・やり方・流れや方法・手法・工程・手順もあわせてご確認ください。
まとめ
ECサイト運用保守の発注・外注を成功させる鍵は、運用と保守の境界を整理して委託範囲を決め、RFPと現状資料を準備して保守範囲を明文化し、SLAと契約形態で対応品質と責任を数値・文書として固めることにあります。とくにECでは、決済・セキュリティの責任分界を明確にし、障害時の一次対応窓口を一本化しておくことが、売上損失を防ぐうえで決定的に重要です。
見積もりは開発費の15%程度という相場観と維持費・管理費・運用費の内訳を踏まえて妥当性を判断し、契約締結前には追加費用の条件やデータ返却まで含めたチェックリストで漏れを潰します。ベンダー移行では引き継ぎ資料の受領と並行稼働、繁忙期を避けたスケジューリングが安全策となり、将来の内製化を見据えた発注設計をしておけば、外注を社内育成と両立させられます。発注を単なる外注ではなく、自社のECを守り育てる投資として設計する視点で、最適なパートナーと契約形態を選んでいきましょう。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。