ITシステムアップデート対応の発注/外注/依頼/委託方法について

OSやミドルウェアのアップデート、セキュリティパッチの適用、ブラウザ仕様変更への追従といった「ITシステムアップデート対応」を社内のリソースだけで回しきるのは、年々難しくなっています。脆弱性は週単位で公表され、放置すればランサムウェアの侵入口になりかねません。だからこそ外部の保守ベンダーへ発注・外注する判断は合理的ですが、いざ委託しようとすると「どこまでが月額保守の範囲で、どこからが別途見積になるのか」「EOSL（保守終了）を迎えた製品はどう扱われるのか」といった契約上の論点が一気に押し寄せてきます。

本記事では、ITシステムアップデート対応を発注・外注・委託する際の具体的な進め方を、契約面・セキュリティ担保面に踏み込んで解説します。とくに競合記事が触れていない「パッチ適用範囲の契約明記」「第三者保守におけるセキュリティリスクの担保条項」「EOSL対応の責任分界」に重点を置き、相見積もりの取り方から委託先選定、契約書で必ず詰めておくべき条項までを一気通貫でお伝えします。読み終えた頃には、見積書の数字だけでなく契約の構造で発注先を見極められるようになっているはずです。

ITシステムアップデート対応を外注すべき理由と委託範囲の考え方

ITシステムアップデート対応とは、OSのメジャー／マイナーアップデート、ミドルウェアのバージョンアップ、セキュリティパッチの適用、そしてそれらに伴う動作検証と不具合修正を含む一連の運用作業を指します。発注・外注を検討する前に、まず「なぜ自社対応では限界が来るのか」「委託する範囲をどう線引きするのか」を整理しておくことが、その後の見積取得と契約交渉の精度を大きく左右します。

アップデート対応を内製で抱え込むと、二つの構造的な負担が生じます。一つは脆弱性情報の追跡コストです。OS・ミドルウェア・利用しているOSS（WordPressやライブラリ群）それぞれについて、公表される脆弱性とパッチを常時ウォッチし、自社環境への影響を評価し続ける必要があります。これは片手間でこなせる作業ではありません。

もう一つは検証環境とロールバック体制の維持です。パッチを本番にいきなり当てて不具合が出れば業務が止まります。予備機やステージング環境でテストし、問題があれば切り戻せる体制を自前で持つには相応の投資が要ります。外部委託が合理的なのは、これらの追跡・検証・切り戻しの仕組みを、複数顧客で共有する保守ベンダーが規模の経済で安価に提供できるからです。手作業の多さとシステムのブラックボックス化がコストの高止まりを招くため、標準化された手順を持つ専門ベンダーへの委託は、適正化の有力な手段となります。

発注前に最も重要なのが、委託範囲（スコープ）の明確化です。ここが曖昧だと、後から「それは契約に含まれていません」という追加費用トラブルに直結します。アップデート対応の場合、線引きの軸は「定型作業か、判断を伴う作業か」「保守の範囲内か、別途制作扱いか」の二つです。

一般論として、バグ修正・障害対応・OSやミドルウェアの軽微なアップデート適用は月額保守費用の範囲内とされます。一方で、大幅なデザイン変更や新機能追加など、プログラムの根本修正を伴う仕様変更は保守範囲外＝別途制作作業として追加費用が発生します。アップデート起因の不具合修正がどちらに該当するかは、後述する早見表で個別に判断する必要があります。発注時には、自社が監視・告知だけ担い実作業はベンダーへ、あるいは判断は自社が握りパッチ適用はベンダーへ、といった役割分担を契約書に明記しておくことが、最適な保守体制の出発点になります。

ITシステムアップデート対応の発注・外注の進め方

外注を成功させるには、いきなり数社に声をかけるのではなく、要件整理から委託先決定まで段階を踏むことが大切です。ここでは現状把握、要件定義（RFP作成）、相見積もりと選定という三つのフェーズに分けて、発注の進め方を具体的に解説します。

最初にやるべきは、アップデート対応の対象となる資産の棚卸しです。サーバーOS、ミドルウェア（Webサーバー、DB、言語ランタイム）、利用しているOSSやライブラリ、それぞれのバージョンとサポート期限（EOL／EOSL）を一覧化します。ここで保守終了が近い、あるいは既に切れている製品が見つかれば、それは委託先選定の最優先課題になります。

棚卸しの際は、平均や合計ではなく裏側のばらつきを見る視点が役立ちます。たとえば「障害は年数回」と平均で捉えるのではなく、どの構成要素で、どのアップデートを起点に発生したかという事実を観察すると、本当にリスクの高い箇所が浮かび上がります。先入観なく現場の事実を把握することが、過不足のない委託範囲の設計につながります。この棚卸し結果が、次のRFP作成の土台となります。

棚卸しが済んだら、委託したい内容をRFP（提案依頼書）として文書化します。アップデート対応のRFPでは、対象資産の一覧に加えて、適用判断のフロー、適用タイミング（メンテナンスウィンドウ）、緊急パッチへの対応時間（SLA）、検証環境の有無、ロールバック手順の責任範囲を明記します。とくにSLAは、ゼロデイ脆弱性が公表された際に何時間以内に評価・適用するのかという数値で示すと、各社の力量差が見えやすくなります。

RFPに求める対応範囲を具体的に書き込むほど、各社の見積もりが同じ土俵で比較できるようになります。逆にここが曖昧だと、安く見える見積もりが実は最小限の範囲しかカバーしておらず、いざ運用が始まってから追加請求が膨らむという事態を招きます。提案を依頼する段階で、後述する「保守内か別途見積か」の境界線を自社の言葉で定義しておくことが、フェアな相見積もりの前提になります。

RFPを基に3社程度から提案と見積もりを取得します。比較の際は、月額の総額だけを見るのではなく、内訳の透明性を重視します。保守費用の標準的な内訳は、定期保守・メンテナンス20〜30%、障害対応25〜35%、軽微な改修・改善10〜15%とされます。この割合から大きく外れた見積もりは、過剰請求か、逆にカバー範囲が薄い可能性があるため、内訳の根拠を質問しましょう。

絞り込みでは、単価の安さだけで判断しないことが肝心です。単価は高くても生産性が圧倒的に高いエンジニアと、安いが工数がかさむ下請けでは、総コスト（TCO）が逆転することは珍しくありません。フリーランスやSESの単価は月70〜76万円前後が中心ですが、重要なのは時間あたりの単価ではなく、一定期間に何件のアップデートを安全に処理できるかという生産性です。提案内容から品質を見極める発注ノウハウが、ここで効いてきます。

保守範囲内か別途見積か：アップデート対応の境界線早見表

発注交渉で最ももめるのが、アップデート起因の作業が「月額保守の範囲内」なのか「別途見積」なのかという境界線です。ここを契約前に具体的なケースで合意しておけば、運用開始後の追加請求トラブルを大きく減らせます。代表的なアップデート要因ごとに、判定の考え方を整理します。

・OSやミドルウェアの定例セキュリティパッチ適用：原則として月額保守の範囲内。定型的な適用作業として計画保守に組み込まれます。
・ゼロデイ脆弱性の緊急パッチ適用：保守範囲内とするのが望ましいが、夜間・休日対応は時間外対応費の対象になり得るため、契約で扱いを明記。
・OSメジャーアップデートに伴う大規模な動作検証・改修：別途見積になりやすい。アプリ側の改修工数が大きく、実質的に制作作業に該当するため。
・ブラウザ仕様変更への追従改修：軽微なら保守内、UIの作り直しを伴うなら別途見積。影響範囲で判断します。
・法改正対応の機能改修：新たな要件の追加であり、原則として別途見積（仕様変更扱い）。
・OSS（WordPress等）バージョンアップ起因の不具合修正：プラグイン互換性の調整程度なら保守内、機能の再設計が必要なら別途見積。

この早見表をそのまま契約書の別表として添付し、ベンダーと一行ずつ合意していくのが実務上もっとも揉めにくい進め方です。「軽微」「大規模」といった言葉の定義は人によってずれるため、たとえば改修工数が何人日を超えたら別途見積、といった定量的な閾値まで決めておくと、後の解釈論争を避けられます。

境界線の議論は費用負担だけでなく、税務・会計の処理にも直結します。障害除去や現状維持を目的とした修正は「修繕費」として期間費用に計上できますが、新機能追加や性能向上を伴うアップデートは「資本的支出」として資産計上が必要になります。発注時に作業の性質を切り分けておけば、請求書を受け取ってから経理が処理に迷う事態を防げます。

応用的な視点として、資本的支出として資産計上する際に「既存部分の除却」を併せて検討する考え方があります。改修で建物の一部を取り壊すのと同様に、置き換えられた既存の資産計上部分は除却されたと捉えれば、その分を費用処理できる余地が生まれます。情報システム部門だけでなくCFOや経理部門も巻き込んで発注の性質を整理しておくと、トータルのコスト最適化につながります。

契約形態の選び方と契約書で詰めるべき条項

アップデート対応の委託では、契約形態の選択と契約条項の作り込みが、発注後のトラブルを左右します。ここでは請負と準委任の使い分け、そしてアップデート対応特有の必須条項について解説します。

請負契約は、成果物の完成義務と契約不適合責任（旧・瑕疵担保責任）を伴います。「このパッチを当てて、この機能を改修して納める」といった成果物が明確な単発のアップデート作業には適しています。一方、準委任契約は善管注意義務を負う形で、毎月の継続的な保守・適用判断のように、要件が状況に応じて変化する作業に柔軟に対応できます。

アップデート対応は、どのパッチがいつ出るか事前に確定できず、適用要否の判断が継続的に発生します。そのため、月額保守のベースは要件変更に強い準委任で結び、大規模なメジャーアップデート改修など成果物が明確な作業はその都度請負で切り出す、という組み合わせが実務的です。継続的なアップデート・保守を前提とするなら、準委任が適すケースが多いと押さえておきましょう。

アップデート対応の契約書には、最低限つぎの条項を明記します。第一に、適用対象とするパッチの範囲です。OS・ミドルウェアだけでなく、OSSやライブラリまで含むのか、セキュリティパッチ限定か機能アップデートも含むのかを定義します。第二に、適用判断の責任分界です。適用するか否かの最終判断を自社が握るのか、ベンダーに委ねるのかを決めます。

第三に、緊急パッチに対するSLA（対応時間）です。重大な脆弱性が公表された場合、評価開始までと適用完了までの目標時間を数値で定めます。第四に、変更管理のルールです。即本番適用せず、事前に業務影響と「適用しなかった場合のリスク」を評価して是非を判断し、予備機でテストの上で適用するプロセスを契約に組み込みます。設計書・ソースコードのバージョンを一元管理し、変更理由・履歴を追跡可能にする変更管理は、安定運用に不可欠です。

パッチ適用後に不具合が発生した場合の責任の所在も、契約で詰めておくべき重要論点です。ベンダーの作業ミスによる不具合か、パッケージソフト自体の不具合か、で責任の切り分けが変わります。とくにクラウドやSaaSを利用している場合、クラウド事業者側の障害でデータ消失や損害が生じた際の責任分界は、ベンダーのSLAが自社要件に合っているかを含めて確認が必要です。

さらに踏み込むなら、セキュリティインシデント時のコスト負担を契約に織り込みます。ランサムウェア等の被害が発生した際、原因調査（フォレンジック）費用、復旧費用、業務停止に伴う損害を保守契約でどこまでカバーするのかを定義し、賄いきれない部分はサイバー保険で補完する設計が現実的です。障害対応が保守に含まれること自体は一般的ですが、大規模インシデントの賠償までは含まれないことが多いため、ここを曖昧にしないことが発注側の身を守ります。

EOSL・第三者保守を委託する際のセキュリティ担保

アップデート対応の発注で見落とされがちなのが、メーカー保守が終了したEOSL（End of Service Life）製品の扱いです。コスト削減のために第三者保守を選ぶケースは増えていますが、ここにはセキュリティ上の固有リスクがあります。委託前にこのリスクをどう担保するかを契約に落とし込むことが重要です。

第三者保守は、メーカー直接保守よりコストを抑えられる有効な選択肢です。実際に政府情報システムで、約50台の物理サーバーをメーカー直接保守から第三者保守に切り替えてコスト削減を実現した事例があります。延命したい資産がある場合、有力な手段になります。

ただし、第三者保守ではメーカー製のセキュリティパッチが提供されない点に注意が必要です。ハードウェア故障の修理は第三者でも対応できますが、ソフトウェアの脆弱性が新たに発見されても、公式パッチが出ない以上は根本的な修正ができません。このパッチ非提供による脆弱性リスクをどう担保・評価するかをセットで考えなければ、コスト削減と引き換えにセキュリティホールを抱え込むことになります。発注時には、第三者保守ベンダーがネットワーク分離・仮想パッチ・代替的な緩和策をどこまで提供できるのかを必ず確認しましょう。

EOSL製品を第三者保守で運用する場合、契約には緩和策とその責任範囲を明記します。具体的には、外部公開を遮断するネットワーク構成、侵入検知（IDS/IPS）や仮想パッチによる代替防御、定期的な脆弱性診断の実施、そして万一被害が出た際の責任分界です。これらを「努力義務」で終わらせず、実施頻度や検知後の対応時間まで条文化することで、パッチが出ないことの穴を組織的に塞ぎます。

あわせて、EOSL製品をいつまで延命し、いつ更改（リプレース）するのかのロードマップも委託先と共有しておくべきです。第三者保守はあくまで時間を稼ぐ手段であり、恒久策ではありません。延命期間中のセキュリティを担保しつつ、計画的に新環境へ移行する設計を含めて発注することで、コスト削減とリスク管理を両立できます。

隠れコストとベンダーロックインを避ける発注の工夫

月額の見積金額が安くても、トータルで見ると割高になる委託契約は少なくありません。発注時に隠れコストを見抜き、将来の乗り換えを難しくするベンダーロックインを避ける工夫を盛り込むことで、長期的なコスト適正化が実現します。

アップデート対応の見積もりで注意したい隠れコストは、時間外・休日対応の割増料金、緊急パッチ適用の都度課金、更新作業ごとの追加費用、報告書作成の別建て請求などです。月額のベース料金だけ見ていると、これらが積み重なって実際の支出が想定を大きく超えることがあります。RFPの段階で、想定される作業を年間でどれくらいの頻度・工数で見込むかを示し、その前提での総額を提示してもらうと比較しやすくなります。

内訳の精査が削減に直結することは、実例が裏付けています。ある民間企業では保守費の内訳を精査して未利用のサービスを発見し、月額28万円を20万円へ、28.6%・年間96万円の削減につなげました。また政府情報システムでは、CPU使用率の低い過剰なサーバーを停止し、数年単位の定期保守を実際の低い故障率に合わせてスポット保守契約へ切り替えるなど、利用実績に基づく最適化で大幅なコスト低減を実現しています。平均値ではなく実際の利用実態という事実を押さえることが、適正化の起点になります。

委託先を将来切り替えたくなったとき、引き継ぎ（トランジション）に膨大なコストがかかると、不満があっても乗り換えられないベンダーロックインに陥ります。これを避けるには、発注の段階で成果物の取り扱いと引き継ぎ協力義務を契約に盛り込んでおくことが有効です。アップデートの適用履歴、変更管理の記録、構成情報、手順書をベンダーが整備し、契約終了時には自社または新ベンダーへ円滑に引き継ぐ義務を明記します。

ドキュメントの標準化と属人性の排除は、ロックイン回避とコスト削減の両面で効きます。手順書が整備され、定型作業がスクリプト化されていれば、引き継ぎの工数が下がり、次のベンダーも短期間で立ち上がれます。逆にシステムがブラックボックス化していると、現ベンダーへの依存が強まり、交渉力を失います。発注時に「ドキュメントは誰の資産で、契約終了時にどう引き渡されるのか」を決めておくことが、長期的な主導権の確保につながります。発注・外注の進め方を体系的に押さえたい場合は、ITシステムアップデート対応の進め方もあわせてご確認ください。

まとめ

ITシステムアップデート対応の発注・外注では、見積金額の安さよりも契約の構造で委託先を見極めることが成功の鍵になります。まず資産を棚卸ししてRFPで委託範囲を明確にし、相見積もりでは内訳の透明性を重視する。そして「保守内か別途見積か」の境界線を早見表で具体的に合意し、パッチ適用範囲・SLA・変更管理・責任分界を契約書に明記することが、後の追加請求トラブルを防ぎます。

さらに、EOSL製品を第三者保守で運用する場合はパッチ非提供のリスクを緩和策とセットで担保し、隠れコストの精査とトランジション条項でベンダーロックインを回避する。これらを押さえれば、セキュリティを保ちながら保守費用を適正化できます。内訳可視化で28.6%削減、スポット保守への切り替え、過剰サーバーの停止といった実例が示すとおり、適正化は十分に可能です。本記事の論点を発注のチェックリストとして活用し、自社にとって最適なアップデート対応の委託体制を構築してください。関連テーマとして、ITシステムアップデート対応の費用相場、おすすめの開発会社・ベンダー6選、ITシステムアップデート対応の完全ガイドも参考になります。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。