基幹システムの運用保守：業務カレンダー・法改正・EOLから決める体制と委託範囲

基幹システムの運用保守は、一般的なシステム保守と同じ契約書の型で組むと、月末締めの夜に障害対応の人がいない、法改正の施行日に改修が間に合わない、といった形で破綻します。会計・販売・在庫・給与といった基幹系は、止まった瞬間に締め処理や出荷、給与支払いが止まるからです。この記事では、基幹システムの運用保守を「業務カレンダー」「法改正の施行日」「OS・DB・パッケージのサポート終了（EOL）」という三つの時間軸から設計する方法を扱います。日次の運用作業、年間の保守計画、内製と外注の分け方、刷新へ切り替える目安までを2026年11月時点で整理します。

まとめ：基幹システムの運用保守は三つの時間軸で計画と委託範囲が決まる

基幹システムの運用保守とは、締め処理や受発注を毎日・毎月確実に回し続けるための運用と、法改正・取引先の仕様変更・基盤のサポート終了に合わせてシステムを変え続ける保守の組み合わせです。汎用的な保守の定義や費用比率、契約形態はシステム保守とは何か、運用との違いと費用相場・契約形態で解説しているので、ここでは基幹系だから変わる部分に絞ります。

計画の起点は三つです。月末・四半期末・年末調整・決算といった業務カレンダーで「作業してよい窓」を決めること。インボイス制度のように施行日が動かない法改正を、保守契約の範囲に入れるかどうかを決めること。OS・DB・パッケージのサポート終了日を一覧にし、延命か刷新かの判断時期を前倒しで置くことです。

委託範囲は、監視・バッチ運行・障害の一次対応を外へ出し、業務仕様とアドオン改修の判断を社内に残す混成型が基本になります。業務知識を持つ社員がおらず、仕様書も残っていない状態で丸ごと外注するのは避けてください。保守費が毎年上がり続け、主要部品のサポート終了が2年以内に迫っているなら、運用保守の見直しではなく刷新の検討に切り替える時期です。

基幹システムの運用保守が一般的なシステム保守と異なる点と影響範囲

基幹システムが何を指すかは基幹システムと業務システム・ERPの違いで整理していますが、運用保守の観点で効いてくる違いは次の二点です。

停止が月次締め・給与支払・出荷に直結する基幹系の業務特性と影響範囲

Webサイトや社内ポータルは、半日止まっても業務は代替手段で回ります。基幹系は違います。販売管理が止まれば受注と出荷指示が止まり、会計が止まれば月次決算の締め日がずれ、給与計算が止まれば支払日に振込データを銀行へ渡せません。影響が社外の取引先や従業員に及ぶ点が最大の差です。

加えて、同じ基幹システムでも止まって困る度合いは時期で大きく変わります。月中の昼間に1時間止まっても大きな損害にならない会社でも、月末最終営業日の夕方に止まれば締めが翌月にずれ込みます。稼働率やRTO・RPOといった目標値の決め方はミッションクリティカルの判断基準と稼働率・RTO・RPOの決め方に詳しく書きました。基幹系では、これを一年を通じた一律の値ではなく、締め期間とそれ以外で分けて定めるのが実務的です。

パッケージ保守料と作業保守を分けて見る基幹システム特有の費用構造

基幹システムの保守費は、性格の異なる二種類の費用を合計して算出します。一つはERPや会計パッケージのベンダーへ払うライセンス保守料で、製品のバージョンアップや法改正対応パッチを受け取る権利の対価です。もう一つは、自社向けのアドオン、帳票、外部連携、データ修正、問い合わせ対応に対する作業保守です。

この二つを一つの「保守費」として見ていると、削減の議論がかみ合いません。ライセンス保守料は契約上ほぼ固定で、削れる余地は小さい費目です。動かせるのは作業保守のほうで、アドオンの数と複雑さ、問い合わせの件数、手作業で行っているデータ修正の頻度がそのまま金額を決めます。見積りを取るときは、両者を分けて明細を出してもらってください。

基幹システムの日次運用と、業務カレンダーに合わせた年間保守計画

運用業務の全体像はシステム運用の業務一覧と委託判断で扱っています。基幹系で特に厚くなるのは、夜間バッチと締め処理まわりです。

夜間バッチ・ジョブ監視・バックアップを軸にした日次運用の作業一覧

基幹システムの日次運用は、前日分の取引を確定させる夜間処理が中心になります。実務で毎日回す作業は、おおむね次のとおりです。

• 夜間バッチ（売上計上、在庫引当、仕訳生成、帳票作成）の完了確認と、異常終了時のリラン判断
• 取引先・銀行・物流会社との連携ファイルの送受信確認と、未着時の再送依頼
• データベースとファイルのバックアップ取得結果の確認
• ディスク容量、ジョブ所要時間、エラーログの傾向監視
• 利用部門からの問い合わせ受付と、操作ミスによるデータ修正依頼の切り分け

このうち最も事故につながりやすいのは、バッチ異常時のリラン判断です。ジョブの依存関係を知らない担当者が途中から再実行すると、仕訳が二重計上されることがあります。ジョブごとに「そのまま再実行してよい」「前処理を戻してから再実行」「担当者へ連絡」のどれに当たるかを手順書で決めておくと、夜間の判断が属人化しません。障害を受け付けてから復旧までの流れはITIL準拠のインシデント管理と監視・オンコールの実装も参考になります。

月末締め・年末調整・決算期を避けて保守作業を入れる年間計画の判断軸

OSのパッチ適用、パッケージのバージョンアップ、アドオン改修のリリースは、業務カレンダー上の繁忙期を避けて配置します。3月決算の会社を例にすると、保守作業を入れてよい時期と避けるべき時期は次のように分かれます。

この表を自社の締め日と決算月に合わせて作り、運用保守の委託先と共有しておくと、年に数回の大型作業をどこに置くかで毎回もめることがなくなります。計画のずれが最も起きやすいのは、パッケージベンダーのバージョンアップ提供時期と自社の繁忙期が重なったときです。その場合は適用を次の窓まで見送り、見送った期間のリスクを記録しておきます。

法改正・税率変更・取引先連携の変更に追随する基幹システム保守の実務

基幹システムの保守が汎用システムと最も違うのは、変更のきっかけが社外にあり、期日も社外で決まる点です。

インボイス制度のように施行日が決まる法改正を保守範囲に含める条件

消費税のインボイス制度は国税庁のインボイス制度特設サイトにあるとおり2023年10月1日に始まり、多くの会社が請求書の様式、登録番号の保持、税額の端数処理の改修を同じ時期に迫られました。こうした改正は施行日が先に決まり、システムの準備状況に関係なく適用されます。

保守契約で確認すべきなのは、法改正対応がライセンス保守料に含まれるのか、作業保守として別見積りになるのかです。パッケージ本体の改修はベンダーのパッチで提供されても、自社のアドオン帳票や外部連携の改修には、一般的に別料金がかかります。毎年起きる改定（例年3月分から変わる協会けんぽの保険料率、年末調整の様式変更など）は保守範囲に含め、数年に一度の大型改正は個別見積りにする、という線引きが現実的です。

銀行・EDI・取引先システムの仕様変更が作業保守を押し上げる場面

基幹システムは単独では動いていません。銀行への振込データ、取引先とのEDI、物流会社への出荷指示、ECサイトとの在庫連携など、社外とのデータ授受が何本もあります。相手側が形式や通信方式を変えると、自社の業務には変化がなくても改修が発生します。

作業保守の見積りが前年より膨らむ原因の多くは、こうした外部連携の変更です。連携先ごとに「形式」「送受信の方式」「変更時の通知元」を一覧にしておくと、変更の予告を受けた段階で影響を見積もれます。連携仕様が担当者の記憶にしか無い状態は、後述する丸投げ見送りの条件に直結します。

OS・DB・パッケージのサポート終了が連鎖する基幹システムの延命判断

基幹システムは10年以上使われることが珍しくないため、運用中に下の層から順にサポート終了を迎えます。

Windows Server 2016の延長サポート終了を例にしたEOL棚卸しの手順

たとえばWindows Server 2016は、Microsoftのライフサイクルページでメインストリームサポートが2022年1月に終わり、延長サポートが2027年1月に終了すると示されています。この上で動く基幹システムは、2026年11月時点で残り2か月余りしかセキュリティ更新を受けられません。

問題は、OSだけを上げれば済むとは限らない点です。OSを更新するとDBのバージョン要件が変わり、DBを上げるとパッケージの対応バージョンが変わり、パッケージを上げるとアドオンの改修が必要になる、という形で連鎖します。棚卸しは次の層ごとに行い、終了日が最も早い層から逆算して計画を置きます。

非機能要件の整理には、IPAが公開している非機能要求グレードの「運用・保守性」の項目が使えます。可用性・性能・移行性などと並ぶ大項目として、保守作業の時間帯や更新方針を発注者と受注者で確認する枠組みが用意されています。

SAPの2027年問題と同型のパッケージ保守終了で延命か刷新かを決める基準

パッケージの保守終了で最も知られた例が、SAP ERP 6.0の標準保守が2027年末に終わる、いわゆるSAPの2027年問題とS/4HANA移行・延命の判断です。国産の会計・販売パッケージでも、旧版の保守終了と新版への移行は数年おきに起きます。

延命を選んでよいのは、残り利用期間が3年以内で後継システムの方針が決まっている場合と、第三者保守や延長保守の費用が刷新費用の分割額を下回る場合です。どちらにも当てはまらず、アドオンが多いために移行が怖いという理由だけで延命を続けるのは、改修できない期間を延ばしているにすぎません。延命した期間に法改正が来ると、パッチが出ない版に自前で改修を入れることになり、保守費はむしろ上がります。

基幹システムの運用保守を内製・外注・混成で分ける基準と見送る場面

JUASの企業IT動向調査2026（2025年度調査・回答957社）のサマリーは、物価高と人件費の高騰でランザビジネス（既存システムの維持）のコストが増えていること、IT人材の流出面では運用やインフラの担当が課題の上位にあることを示しています。同じ調査で多くの企業が目指す姿として挙げたのは、完全内製でも完全外注でもなく、内製と外部委託の使い分けでした。

業務知識とアドオン仕様を社内に残す内製と外注の役割分担の判断基準

基幹システムで社内に残すべきなのは、作業そのものより判断です。具体的には、業務仕様の決定、改修要望の優先順位付け、法改正への対応方針、そしてアドオンの仕様を説明できる人の確保です。逆に外へ出しやすいのは、監視、バッチ運行、バックアップ確認、OSやミドルウェアのパッチ適用といった、手順に落とせる作業になります。

この分け方が効くのは、委託先が替わっても業務仕様が社内に残るからです。手順と仕様を文書に残す方法はシステム運用保守ドキュメントの整備手順で、手順書から優先して書く順番まで扱っています。

ブラックボックス化した基幹システムの運用保守を丸投げしない条件

次の条件のうち二つ以上に当てはまるなら、運用保守を一括で外注するのは見送ってください。

• アドオンや帳票の仕様書が無い、または最新の改修が反映されていない
• 業務仕様を説明できる社員が1名以下で、その人が退職・異動を控えている
• 現在の保守ベンダーとの契約終了が決まり、引き継ぎ期間が3か月未満しかない
• 外部連携の本数と仕様を、誰も一覧で示せない

この状態で丸投げすると、委託先は仕様を推測しながら対応するしかなく、障害のたびに調査費が積み上がります。先に3〜6か月の引き継ぎ期間を取り、現行ベンダーと新しい委託先、社内担当の三者で仕様を文書化する工程を挟むほうが、結果として安く済みます。急いで外注先を決める判断は、この段階では誤りです。

監視と一次対応を外注し改修判断を社内に残す混成体制の組み方と委託範囲

混成体制の典型は、平日夜間と休日の監視・バッチ運行・一次対応を委託先が受け持ち、業務影響の判断と改修の発注を社内の担当者が持つ形です。委託先の判断範囲は「手順書にあるリランと再送まで」と明記し、それ以外は担当者へ連絡する取り決めにします。月末締めの期間だけ委託先の待機人数を増やす、といった業務カレンダー連動の契約にしておくと、平常時の費用を抑えられます。

委託先を比べる段階では、運用保守会社の相見積りを比較できる形に揃える手順のとおり、範囲と前提を固定してから見積りを取ってください。一創でも、基幹システムを含む業務システムの保守運用と内製化支援を、監視の受託から社内体制づくりの支援まで段階的にお受けしています。

基幹システムの保守体制を見直す手順と刷新へ切り替える判断の目安

最後に、現状の運用保守を見直すときの進め方と、見直しでは足りないと判断する基準を示します。

保守契約・問い合わせ履歴・EOL一覧から始める見直しの5ステップ

見直しは、委託先を探すことからではなく、現状を数字で把握することから始めます。

1. 現行の保守契約を読み、ライセンス保守料と作業保守の金額、対応時間帯、法改正対応の扱いを書き出す
2. 過去12か月の問い合わせと障害の記録を、原因別（操作ミス・データ不整合・バッチ異常・外部連携・法改正）に分類する
3. OS・DB・パッケージ・アドオンのEOL一覧を作り、終了日の早い順に並べる
4. 業務カレンダーを作り、保守作業の窓と凍結期間を決める
5. 社内に残す判断と外へ出す作業を分け、委託範囲の案を作ってから見積りを取る

手順2で操作ミスとデータ修正が半数を超えるなら、委託先を替えるより画面や入力チェックの改修が先です。外部連携が多いなら、連携の一覧化と監視の自動化から手を付けます。

保守費の増加が続くときに刷新・マイグレーションへ切り替える目安

運用保守の改善で対処できる範囲には限りがあります。次のいずれかに当てはまるなら、刷新の検討に入る時期です。主要な層のサポート終了が2年以内に迫り、後継版への移行でアドオンの大半に改修が必要になる場合。作業保守費が3年続けて増え、その主因がアドオンの複雑さにある場合。法改正のたびにベンダーから対応不可または高額な個別見積りが返ってくる場合です。

刷新の進め方には、同じ機能を新基盤へ移すマイグレーションと、業務ごと作り直す方法があります。違いと発注時の判断はマイグレーションとリプレイス・モダナイゼーションの違いで解説しました。いずれの方法でも、見直しの5ステップで作った契約・障害・EOLの整理は、刷新の要件定義にそのまま使えます。

よくある質問

基幹システムの運用保守を検討する担当者から寄せられやすい質問をまとめました。

基幹システムの運用保守と一般的なシステム保守は何が違いますか？

作業の種類は同じですが、計画の決まり方が違います。基幹システムは月末締めや決算など業務カレンダーで作業できる時期が限られ、法改正の施行日や取引先の仕様変更日など社外の期日に合わせた改修が毎年発生します。さらにOS・DB・パッケージのサポート終了が連鎖するため、更新計画の対象は数年先までです。保守の一般論は親記事のシステム保守の解説を参照してください。

ERPのライセンス保守料は削減できますか？

契約上の料率はほぼ固定で、交渉で大きく下がることは多くありません。削減の余地があるのは、使っていないユーザー数やモジュールの見直しと、作業保守の側です。延長保守を外して第三者保守へ移す選択肢もありますが、法改正パッチや新版への移行経路を失う点を理解したうえで、残り利用期間が短い場合に限って検討してください。

基幹システムの保守ベンダーを途中で替えることはできますか？

可能ですが、引き継ぎ期間を十分に取ることが前提です。仕様書が整っていない場合は3〜6か月を見込み、現行ベンダーに引き継ぎ協力を依頼できるよう、契約終了の通知時期を逆算して決めます。現行契約に引き継ぎ協力の条項が無い場合は、別途有償で依頼する形になることが多いため、費用も事前に見積もっておきます。

夜間や休日の障害対応はどこまで委託すべきですか？

監視と通報、手順書で定めたバッチの再実行やファイル再送までは委託し、業務影響の判断と復旧後のデータ確認は社内担当者が行う形が基本です。給与振込や月次締めにかかる時間帯だけは、委託先の対応範囲と社内担当者の連絡体制を厚くしておくと、平常時の費用を抑えながら事故を防げます。

クラウドERPに移れば運用保守は不要になりますか？

サーバーやOS、パッケージ本体の更新はクラウド事業者側の責任になり、EOL対応の負担は大きく減ります。一方で、ベンダーが決めた時期に機能更新が入るため、アドオンや外部連携の動作確認は自社の作業として残ります。業務仕様の管理、問い合わせ対応、データ修正も無くなりません。クラウドとオンプレミスの比較は基幹システム・ERPのクラウドとオンプレミスの選び方で扱っています。

関連記事

• システム保守とは？運用との違い・費用相場・契約形態を発注者視点で解説：保守の定義・費用比率・契約形態の一般論を確認できます。
• 保守契約とは：システム保守契約書の条項と準委任・請負の違い、印紙の判定：保守契約書に入れる条項と契約類型の違いが分かります。
• SAP Basisとは：運用保守の作業範囲とSAP Note・カーネル・サポートパッケージ適用の手順【2026年10月】：SAPを使う基幹システムの運用保守作業を技術面から扱っています。
• AWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準：基幹システムをAWSで動かす場合の委託範囲の考え方が分かります。
• 基幹システムとは？業務システム・ERPとの違いと構成領域・刷新の進め方を解説：基幹システムの構成領域と刷新の進め方を確認できます。