ITシステムアップデート対応を外注するには、まず現状の構成を棚卸しし、委託したい内容をRFP（提案依頼書）にまとめ、複数社の見積もりを比べて委託先を絞り込みます。
あわせて、パッチ適用範囲やEOSL製品の扱い、責任分界を契約に明記しておくと、発注後のトラブルを減らせます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
ITシステムアップデート対応の外注理由と委託範囲の考え方
ITシステムの更新対応には、OSのメジャー・マイナー更新やミドルウェアのバージョンアップが含まれます。セキュリティパッチを当てたあとの動作検証や不具合修正も、この一連の運用作業に入ります。
発注前には、自社で対応しきれなくなる理由を整理しておきます。委託範囲を先に線引きしておけば、見積もりと契約交渉の精度も高まります。
自社対応が限界を迎える理由
アップデート対応を社内で抱え込むと、構造的な負担が二つ生じます。一つ目は、脆弱性情報を追い続けるコストです。
- 情報追跡：OS・ミドルウェア・OSSの脆弱性の継続監視
- 検証と復旧：予備環境と切り戻し体制の維持
OSやミドルウェア、利用中のOSS（WordPressやライブラリ群）では、脆弱性とパッチの情報を継続的に追う必要があります。さらに、自社環境への影響も評価しなければなりません。これは片手間でこなせる作業ではありません。
もう一つは、検証環境とロールバック体制の維持です。パッチを本番にいきなり当てて不具合が出れば、業務が止まります。予備機やステージング環境でテストし、問題があれば切り戻せる体制を自前で持つには、相応の投資が要ります。
外部委託が合理的なのは、追跡・検証・切り戻しの仕組みを複数の顧客で共有する保守ベンダーが、規模の経済によって安価に提供できるからです。手作業が多く、システムがブラックボックス化していると、コストは高止まりします。そのため、標準化された手順を持つ専門ベンダーへの委託が、適正化の有力な手段になります。
委託範囲と自社対応範囲の線引き
発注前にもっとも重要なのは、委託範囲（スコープ）をはっきりさせることです。ここが曖昧なままだと、後から「それは契約に含まれていません」と言われ、追加費用をめぐるトラブルに直結します。
- 定型作業：監視・告知・適用の担当を分けて明記
- 追加開発：新機能や大規模改修の別途見積もり
アップデート対応の場合、線引きの基準は「定型作業か、判断を伴う作業か」「保守の範囲内か、別途制作扱いか」の二つです。一般論として、OSやミドルウェアの軽微なアップデート適用や、バグ修正・障害対応は、月額保守費用の範囲内とされます。
一方、大幅なデザイン変更や新機能追加など、プログラムの根本修正を伴う仕様変更は、保守範囲外の別途制作作業として追加費用が発生します。アップデート起因の不具合修正がどちらに当たるかは、後述する早見表で個別に判断します。
発注時には、役割分担を契約書に明記します。たとえば、自社が監視と告知を担い、実作業をベンダーに任せる形があります。判断は自社、パッチ適用はベンダーという分け方も可能です。
ITシステムアップデート対応の発注・外注の進め方
外注を成功させるには、要件整理から委託先の決定まで段階を踏むことが大切です。いきなり数社に声をかけるのではなく、現状把握、要件定義（RFP作成）、相見積もりと選定の三つのフェーズで順に進めます。
STEP1：現状の構成把握と棚卸し
最初に行うのは、アップデート対応の対象となる資産の棚卸しです。結果は、資産台帳とリスク把握の二つにまとめます。
- 資産台帳：製品ごとの版の一覧
- リスク把握：EOL／EOSLと過去の障害の起点の記録
サーバーOS、Webサーバー、DB、言語ランタイムなどのミドルウェアを洗い出し、OSSやライブラリも含めて対象を拾い上げます。そのうえで、各製品のバージョンとサポート期限（EOL／EOSL）を一覧にします。ここで保守終了が近い、あるいは既に切れている製品が見つかれば、委託先選定でもっとも優先して扱うべき課題になります。
棚卸しでは、平均や合計ではなく、ばらつきを見る視点が役立ちます。「障害は年数回」と平均だけで判断しないことが大切です。どの構成要素で、どの更新をきっかけに起きたかを確認すると、リスクの高い箇所が見えてきます。
先入観なく現場の事実をつかむことが、過不足のない委託範囲の設計につながります。この棚卸しの結果は、次のRFP作成の出発点になります。
STEP2：要件定義とRFP（提案依頼書）の作成
棚卸しが済んだら、委託したい内容をRFP（提案依頼書）として文書にまとめます。RFPには、適用判断と実施条件の二つを記します。
- 適用判断：緊急度・影響・適用時期の記載
- 実施条件：SLA・検証環境・ロールバック責任の明記
対象資産と適用判断の流れを示し、適用時期はメンテナンスウィンドウ、緊急パッチの対応時間はSLAで示しておくと、各社が同じ前提で見積もれます。検証環境の有無やロールバックの責任範囲も、あわせて書き添えます。
とくにSLAは、ゼロデイ脆弱性が公表されたときに何時間以内に評価と適用を始めるのかを、数値で示すとよいでしょう。数値があると、各社の力量の差が見えやすくなります。
RFPに求める対応範囲を具体的に書き込むほど、各社の見積もりを同じ条件で比べられます。一方、ここが曖昧だと、安く見える見積もりが最小限の範囲しかカバーしておらず、運用が始まってから追加請求が膨らむ事態を招きます。
提案を依頼する段階で、後述する「保守内か別途見積か」の境界線を自社の言葉で定義しておくことが、公平な相見積もりの前提になります。
STEP3：相見積もりと委託先の絞り込み
RFPをもとに3社程度から提案と見積もりを取ります。比較では、月額の総額だけでなく、内訳の透明性も重視します。
- 比較条件：同じ範囲と対応時間での複数社比較
- 実行力：価格に加えて、安全に処理できる件数の確認
保守費用の標準的な内訳は、定期保守・メンテナンスが20〜30%、障害対応が25〜35%、軽微な改修・改善が10〜15%とされます。この割合から大きく外れた見積もりは、過剰請求か、あるいはカバー範囲が薄い可能性があるため、内訳の根拠を質問しましょう。
絞り込みでは、単価の安さだけで判断しないことが肝心です。単価は高くても生産性が圧倒的に高いエンジニアと、安くても工数がかさむ下請けでは、総コスト（TCO）が逆転することも珍しくありません。
フリーランスやSESの単価は、月70〜76万円前後が中心です。ただし、時間単価だけでなく、一定期間に安全に処理できる更新件数も評価します。提案内容から品質を見極める発注ノウハウが、ここで効いてきます。
保守範囲内か別途見積か：アップデート対応の境界線早見表
発注交渉でもっともめるのは、アップデート起因の作業が「月額保守の範囲内」か「別途見積」かという境界線です。ここを契約前に具体的なケースで合意しておけば、運用開始後の追加請求トラブルを大きく減らせます。代表的なアップデート要因ごとに、判定の考え方を整理します。
要因別の判定早見表
保守範囲の判断では、更新の種類と作業規模を分けて考えます。OSやミドルウェアの定例セキュリティパッチは、計画保守に組み込むのが原則です。ゼロデイ脆弱性への緊急パッチも保守内が望ましい一方、夜間・休日対応の追加費用は契約で定めます。
OSのメジャー更新に伴う大規模な動作検証・改修は、アプリ改修の工数が大きく、別途見積もりになりやすい作業です。ブラウザ仕様変更は、軽微な追従なら保守内、UIの作り直しなら別途見積もりとし、影響範囲で判断します。
法改正による機能追加は新要件のため、原則として別途見積もりです。WordPress等のOSS更新後は、プラグインの互換性調整なら保守内、機能の再設計が必要なら別途見積もりとなります。
- 保守内：定例パッチなど現状維持の作業
- 別途見積もり：大規模改修や新機能の条件の具体化
この早見表をそのまま契約書の別表として添付し、ベンダーと一行ずつ合意していくのが、実務上もっとも揉めにくい進め方です。「軽微」「大規模」の意味は、担当者によって異なります。そのため、改修工数が何人日を超えたら別途見積もりにするかという数値基準も決めておくと、解釈の違いを防げます。
経理処理（修繕費か資本的支出か）の確認
境界線の議論は、費用負担だけでなく、税務・会計の処理にも直結します。
- 修繕費：障害除去や現状維持の修正の区分
- 資本的支出：機能追加・性能向上と旧資産の扱いの確認
障害除去や現状維持の修正は「修繕費」として期間費用にできます。一方、新機能追加や性能向上を伴う更新は「資本的支出」として資産計上が必要です。発注の時点で作業の性質を切り分けておけば、請求書を受け取ってから経理が処理に迷う事態を防げます。
応用的な視点として、資本的支出として資産計上する際に「既存部分の除却」を併せて検討する考え方があります。改修で建物の一部を取り壊すのと同様に、置き換えられた既存の資産計上部分は除却されたと捉えれば、その分を費用処理できる余地が生まれます。
情報システム部門だけでなく、CFOや経理部門も巻き込んで発注の性質を整理しておくと、全体のコストの適正化につながります。
契約形態の選び方と契約書で詰めるべき条項
アップデート対応の委託では、契約形態の選択と契約条項の作り込みが、発注後のトラブルを左右します。請負と準委任の使い分けと、アップデート対応に特有の必須条項を取り上げます。
請負契約と準委任契約の使い分け
請負契約は、成果物の完成義務と契約不適合責任（旧・瑕疵担保責任）を伴います。「このパッチを当てて、この機能を改修して納める」のように、成果物が明確な単発のアップデート作業に適しています。
- 準委任：変更が続く月額保守や運用向き
- 請負：成果物と完成条件が明確な改修
一方、準委任契約は善管注意義務を負う形で、毎月の継続的な保守や適用判断のように、要件が状況によって変わる作業に柔軟に対応できます。
アップデート対応は、どのパッチがいつ出るかを事前に確定できず、適用の要否を判断する場面が継続的に生じます。そのため、月額保守は要件変更に対応しやすい準委任を基本にします。
大規模なメジャーアップデートなど成果物が明確な作業は、個別に請負として切り出すのが実務的です。継続的なアップデートや保守を前提とするなら、準委任が適するケースが多いと押さえておきましょう。
パッチ適用範囲とSLAの契約明記
アップデート対応の契約書には、最低限明記すべき条項があります。
- 対応条件：パッチ範囲、頻度、緊急時SLA
- 見積基準：軽微・大規模を分ける工数の数値基準
まず、適用対象の範囲を定めます。OS・ミドルウェアのほか、OSSやライブラリを含めるか、セキュリティパッチに限るか、機能更新も対象にするかを明確にします。
次に、適用判断の責任分界を定め、最終判断を自社が行うか、ベンダーに委ねるかを明記します。そのうえで、緊急パッチに対するSLA（対応時間）を定めます。重大な脆弱性が公表された場合、評価開始までと適用完了までの目標時間を数値で示します。
さらに、変更管理のルールも契約に含めます。即本番適用せず、事前に業務影響と「適用しなかった場合のリスク」を評価して是非を判断し、予備機でテストしたうえで適用するプロセスを組み込みます。
変更管理では、設計書やソースコードのバージョンをまとめて管理し、変更理由と履歴を追跡できるようにしておきます。これは安定運用に欠かせません。
不具合発生時の責任分界とインシデント対応
パッチ適用後に不具合が発生した場合の責任の所在も、契約で詰めておくべき重要な論点です。ベンダーの作業ミスによる不具合か、パッケージソフト自体の不具合かによって、責任の切り分けが変わります。
- 障害の責任：自社・ベンダー・クラウド事業者の範囲の区分
- 事故費用：調査・復旧・休業損害と保険の対象の決定
クラウドやSaaSでは、事業者側の障害によるデータ消失や損害について、責任分界を確認します。ベンダーのSLAが自社の要件に合うかどうかも、検討が必要です。
さらに踏み込むなら、セキュリティインシデント時のコスト負担も契約に織り込みます。たとえばランサムウェア被害では、フォレンジック調査費・復旧費・業務停止損害の契約上の扱いを決めます。保守契約で足りない部分は、サイバー保険で補う設計が現実的です。
障害対応が保守に含まれること自体は一般的ですが、大規模インシデントの賠償までは含まれないことが多いです。ここを曖昧にしないことが、発注側の身を守ります。
EOSL・第三者保守を委託する際のセキュリティ担保
アップデート対応の発注で見落とされがちなのが、メーカーの保守が終了したEOSL（End of Service Life）製品の扱いです。コスト削減のために第三者保守を選ぶケースは増えていますが、ここにはセキュリティ上の固有のリスクがあります。委託前に、このリスクをどう担保するかを契約に落とし込むことが重要です。
第三者保守のコスト削減効果とリスク
第三者保守は、メーカー直接保守よりコストを抑えられる有効な選択肢です。実際に政府情報システムでは、約50台の物理サーバーを、メーカー直接保守から第三者保守に切り替えてコスト削減を実現した事例があります。
- 費用効果：メーカー直接保守と比べた削減額の見込み
- 継続リスク：メーカー製パッチがない期間の対策
延命したい資産がある場合、第三者保守は有力な手段になります。ただし、第三者保守ではメーカー製のセキュリティパッチが提供されない点に注意が必要です。ハードウェア故障の修理は第三者でも対応できますが、ソフトウェアの脆弱性が新たに見つかっても、公式パッチが出ない以上、根本的な修正はできません。
パッチが出ないことによる脆弱性リスクは、担保と評価をセットで考えておく必要があります。そうしなければ、コスト削減と引き換えに、セキュリティホールを抱え込むことになります。発注時には、第三者保守ベンダーがネットワーク分離、仮想パッチ、代替的な緩和策をどこまで提供できるかを、必ず確認しましょう。
セキュリティ担保条項の盛り込み方
EOSL製品を第三者保守で運用する場合、契約には緩和策とその責任範囲を明記します。
- 代替策：ネットワーク制限と仮想パッチの検討
- 契約担保：監視・診断・被害時責任の条項化
具体的には、外部公開を遮断するネットワーク構成を検討し、IDS/IPSや仮想パッチ、定期的な脆弱性診断、被害発生時の責任分界も決めておきます。これらを「努力義務」で終わらせず、実施頻度や検知後の対応時間まで条文にすることで、パッチが出ないことによる穴を組織として塞ぎます。
あわせて、EOSL製品をいつまで延命し、いつ更改（リプレース）するかのロードマップも、委託先と共有しておくべきです。第三者保守はあくまで時間を稼ぐ手段であり、恒久策ではありません。延命期間中のセキュリティを担保しながら、計画的に新しい環境へ移行する設計まで含めて発注すると、コスト削減とリスク管理を両立できます。
隠れコストとベンダーロックインを避ける発注の工夫
月額の見積金額が安くても、トータルで見ると割高になる委託契約は少なくありません。そこで、発注時に隠れコストを見抜き、将来の乗り換えを難しくするベンダーロックインを避ける工夫を盛り込むと、長期的なコストの適正化につながります。
見積もりに潜む隠れコストの見つけ方
見積もりでは、時間外・休日の割増料金を確認します。緊急パッチの都度課金、更新作業の追加費用、報告書の別料金も、隠れコストになり得ます。
- 追加料金：時間外・緊急対応・報告書の費用
- 実績最適化：CPU利用率や故障率に基づく保守の見直し
月額のベース料金だけを見ていると、これらが積み重なり、実際の支出が想定を大きく超えることがあります。RFPの段階で、想定される作業を年間でどれくらいの頻度・工数で見込むかを示し、その前提での総額を提示してもらうと比較しやすくなります。
内訳の精査が削減に直結することは、実例が裏付けています。ある民間企業では、保守費の内訳を精査して未利用のサービスを発見し、月額28万円を20万円へ、28.6%・年間96万円の削減につなげました。
政府情報システムでは、CPU使用率の低い過剰なサーバーを停止した事例があります。数年単位の定期保守も、実際の故障率に合わせてスポット保守へ切り替え、利用実績に基づくコスト削減を実現しています。平均値ではなく実際の利用実態を押さえることが、適正化の起点になります。
ロックイン回避とトランジション条項
委託先を将来切り替えたくなったとき、引き継ぎ（トランジション）に膨大なコストがかかると、不満があっても乗り換えられない、ベンダーロックインに陥ります。
- 引き継ぎ：手順書、設定、構築物の権利と受け渡し
- 依存回避：終了時の協力義務とアクセス権の確保
これを避けるには、発注の段階で成果物の扱いと引き継ぎ協力義務を契約に盛り込んでおくことが有効です。アップデートの適用履歴、変更管理の記録、構成情報、手順書をベンダーが整備し、契約終了時には自社または新しいベンダーへ円滑に引き継ぐ義務を明記します。
手順書と定型作業を標準化すると、引き継ぎの工数を抑えられ、次のベンダーも短期間で立ち上がれます。反対に、システムがブラックボックス化すると、現ベンダーへの依存が強まり、交渉力も弱まります。
契約時に、文書の所有者と終了時の引き渡し方法を決め、長期的な主導権を確保しておきましょう。
発注・外注の進め方は、ITシステムアップデート対応の進め方もご確認ください。
まとめ
ITシステムアップデート対応の発注・外注では、見積金額の安さよりも、契約の構造で委託先を見極めることが成功の鍵になります。そのためには、まず資産を棚卸ししてRFPで委託範囲を明確にし、相見積もりでは内訳の透明性を重視します。
「保守内か別途見積か」は、早見表を使って具体的に合意します。パッチ範囲、SLA、変更管理、責任分界を契約に記せば、追加請求のトラブルを防ぎやすくなります。
EOSL製品を第三者保守で運用する場合は、パッチがないリスクを緩和策と合わせて管理します。隠れコストとトランジション条項も確認しましょう。
政府情報システムでは、CPU使用率の低い過剰なサーバーを停止した事例があります。数年単位の定期保守も、実際の低い故障率に合わせてスポット保守へ切り替え、利用実績に基づいてコストを抑えています。
別事例では、保守費の内訳を明らかにして28.6%削減しました。本記事の論点を発注時の確認に使い、自社に合う委託体制を整えましょう。
費用はITシステムアップデート対応の費用相場、委託先はおすすめの開発会社・ベンダー6選、全体像はITシステムアップデート対応の完全ガイドも参考になります。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。