ECサイトの運用保守を外部に発注するには、まず運用と保守の範囲を切り分けます。そのうえで、準備資料を整え、SLAと契約形態、責任分界、見積もりを固めてから、移行の段取りを組みます。
追加費用や責任の押し付け合いといったトラブルは、発注設計のミスから後を絶ちません。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
- 運用保守の範囲：運用と保守の境界を整理し、内製と外注のどちらを選ぶかを決めます。
- 準備資料と契約形態：RFPや現状資料を準備し、SLAと契約形態を設計します。
- 決済・セキュリティ：どこまでを誰が受け持つかを明確にして、委託先を選びます。
- 見積もりと移行：契約前チェックを行い、移行と引き継ぎを進めます。
ECサイト運用保守を発注・外注する前に押さえる全体像
発注の話に入る前に、何を任せるのかを自分の言葉で整理しておく必要があります。ECサイトの運用保守は、日々の監視やバックアップといった「運用」と、障害復旧やアップデート、セキュリティ対応といった「保守」の2つで成り立っています。この運用と保守の境界が曖昧なまま発注すると、後から「それは契約範囲外です」と言われる典型的なトラブルにつながります。
EC運用と保守で変わる外注範囲
ECサイトの「運用」とは、サーバーやサイトの死活監視、注文データのバックアップ、商品登録や価格改定の反映、アクセス状況のモニタリングなど、日常的に発生する作業を指します。一方、「保守」は、決済不具合の修正、カートのバグ対応、CMSやプラグインのバージョンアップ、脆弱性パッチの適用といった、サイトの健全性を保つための技術作業です。
外注を検討する際は、運用と保守のどこまでを委託するかを切り分ける必要があります。たとえば、商品登録のような日常運用は自社で行い、決済まわりの保守やセキュリティ対応だけを専門会社に任せるという分担も可能です。
発注範囲を広げるほど月額費用は上がりますが、属人化リスクを外部の体制で吸収できるメリットも生まれます。そこで、自社のEC担当者の人数やスキル、「止められない機能」がどこにあるかを基準に、委託ラインを決めていくのが現実的です。
内製・外注・併用の選び方
運用保守の体制には、完全内製、完全外注、両者を組み合わせる併用型の3つがあります。完全内製では、ノウハウが社内に蓄積される一方で、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特有の論点として、セールや大型キャンペーンの時期の対応体制もSLAに織り込んでおく必要があります。
- 交渉の例：普段は平日日中の対応でも、繁忙期だけは深夜・休日を含む緊急体制を組んでもらう条件を、発注時に交渉しておきます。
- ペナルティ：SLAは、未達時のペナルティ（料金減額など）まで合意して初めて実効性を持ちます。
- 口頭の約束：数値を決めないまま「迅速に対応します」と口頭で約束して契約すると、いざというときに対応の遅れを問えなくなる点に注意が必要です。
準委任と請負の使い分け
運用保守の契約は、業務の遂行そのものを目的とする「準委任契約」が一般的です。日々の監視や問い合わせ対応のように、仕上がりを一つの形に定めにくい継続的な業務だからです。
- 請負が向く作業：特定機能の改修や新しいキャンペーンページの制作のように、完成の基準がはっきりした作業には請負契約が向いています。
- 一般的な組み合わせ：多くのEC保守契約は、月額の準委任を基本にし、まとまった改修だけを請負で切り出す形です。
- 裁判例に見るリスク：保守契約をめぐる東京地裁の平成24年4月25日判決では、ベンダーが見積もり工数を超過した分の報酬を請求しました。
- 判決の結果：超過の原因がユーザー側の追加指示による場合に限ってユーザー負担とされ、請求の一部しか認められませんでした。
- 追加費用のルール：「どんな場合に追加費用が発生し、誰がどう承認するのか」を発注時に取り決めておけば、こうした紛争を事前に防げます。
決済・セキュリティの責任分界と委託先選定
ECサイトは、漏えいすれば事業の存続に関わる決済情報や個人情報を扱います。そのため、委託先を選ぶ際は、セキュリティへの対応力と、どこまでを誰が受け持つかの明確さを最も重視する必要があります。
価格の安さを優先して選ぶと、障害時の復旧が大幅に遅れるおそれがあります。また、誰が対応すべきかが不明確なまま、復旧が止まってしまうリスクも高まります。
決済・個人情報まわりの責任範囲の切り分け
ECサイトの決済には、自社サイト、決済代行サービス、カード会社など複数の事業者が関わります。そのため、「どこまでが保守ベンダーの責任で、どこからが決済代行側の責任か」を、契約時に明確にしておく必要があります。複数の外部パートナーが入る場合こそ、誰が司令塔になるのかを事前に決めておくことが、ECの売上を守ることにつながります。
- PCI DSS：クレジットカード情報を扱う場合は、カード情報保護の国際基準であるPCI DSSへの準拠が求められる場面もあります。
- 準拠の責任：その責任を自社・ベンダー・決済代行のどこが担うのかを、発注時に確認しておくことが欠かせません。
- 担当の境目：曖昧なまま複数ベンダーが関わると、障害時に深刻な事態を招きます。
- 責任の転嫁：障害時に「ネットワーク側」「サーバー側」「装置側」の担当会社が責任を転嫁し合い、復旧が大幅に遅れた事例が報告されています。
- 一次対応窓口：発注の段階で、障害発生時の窓口を一本化し、各事業者の責任範囲を図にして関係者で共有しておきます。
セキュリティ実績と対応力による委託先の見極め
委託先を選ぶ際は、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では、決済・セキュリティの責任の分け方を明確にし、障害時の一次対応窓口を1つにまとめておくことが、売上損失の防止に直結します。
見積もりは、開発費の15%程度という相場観と、維持費・管理費・運用費の内訳を踏まえて、妥当性を判断します。契約締結前には、追加費用の条件やデータ返却まで含めたチェックリストで、漏れを一つずつ確かめます。
ベンダー移行では、引き継ぎ資料の受領と並行稼働、繁忙期を避けたスケジュールが安全策になります。将来の内製化を見据えた発注設計をしておけば、外注と社内育成を両立させられます。
発注を単なる外注で終わらせず、自社のECを守り育てる投資として設計する視点で、最適なパートナーと契約形態を選んでいきましょう。
RFP作成前に、Webサービス開発の完全ガイドブックと【2026年最新版】AI駆動開発の完全ガイドブックをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。