LASSIC Media らしくメディア
保守と運用の違い｜障害対応や監視など作業の分け方と任せ方
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 運用はシステムを毎日動かして業務を回す仕事で、保守はシステムを業務や環境に合わせて直し続ける仕事です。
- 障害対応やOSの更新のように境目があいまいな作業は、どちらに入れるかを契約で決めておきます。
- 分けて頼むか1社に任せるかは、社内に残る人と作業から選び、どちらでも作業の範囲を書き分けます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
障害が起きて保守の会社に連絡したら、それは運用の範囲だと言われた。運用を頼んでいるはずなのに、プログラムの直しは別の見積もりだと言われた——。システムの仕事を外部と分け合っている会社では、こうした食い違いが起こりがちです。保守はシステムを業務や環境に合わせて直し続ける仕事、運用はシステムを毎日動かして業務を回す仕事を指します。
ふだんは区別しなくても困りませんが、契約の範囲や見積もりを比べる場面では、どちらの作業かで頼む相手も費用の決まり方も変わります。本記事では、システムの担当者に向けて、保守と運用の定義、作業ごとの違い、障害対応の切り分け方、分けて頼むか一括で任せるかの判断、そして外部に頼むときに確認したい点を整理します。
保守と運用とは
IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」は、システムの一生をいくつかの段階に分け、運用と保守を別の段階として説明しています。*1 どちらも稼働を始めたあとの仕事ですが、運用は「動かす」仕事、保守は「直す」仕事と覚えると区別しやすくなります。
- 運用：「業務運用環境で情報システムを稼働して、業務を円滑に遂行するフェーズ」。システムの起動と終了、監視、ファイルの整理などを含みます
- 保守：「情報システムやソフトウェアの現状を業務及び環境に適合するように維持管理を行う工程」。不具合の修正や、環境の変化に合わせた手直しが中心です
- 運用の対象：システムの運用だけでなく、業務の運用や、パッケージソフトを使う人の支援まで含みます*2
この2つの定義は、IPAの共通フレーム2013（システムの構想から開発、運用、保守、廃棄までの作業を整理した共通の枠組み）*3の運用プロセスと保守プロセスにおおむね対応しています。*1共通フレームは、運用から得られる情報が保守にも関係する場合があると書いています。*2
作業で見る保守と運用の違い
モデル契約に付いている2つの業務仕様書のサンプルを見ると、境目が具体的に分かります。アプリケーション保守のサンプルは、改良、トラブル対応、質問対応、予防保守などを業務に挙げています。一方、運用を受け持つオンサイト型（利用者の現場で作業する形）のサンプルは、監視、トラブル対応、ヘルプデスク、運用管理業務、資産管理業務を主な中身としています。*1
| 作業 | 運用が受け持つこと | 保守が受け持つこと |
|---|---|---|
| 監視 | 稼働の様子を見て、異常に気づく | 監視で見つかった問題の原因を調べる |
| バックアップ | 決めた手順で取り、そのためにサービスを止める時間を管理する | 仕組みそのものを変えるときに改修として扱う |
| 障害対応 | 回避策で業務を続け、問題を報告する | 原因を分析し、プログラムを直して確かめる |
| 問い合わせ | 使い方の問い合わせを受ける（ヘルプデスク） | システムの動きについての質問を調べて答える |
| 改修 | 直してほしい点を修正依頼として出す | 動作環境の変化に合わせた修正や、性能を上げる修正をする |
| OSやミドルウェアの更新 | 契約しだい。運用の委託に含める例もある | |
表の中で境目があいまいになりやすいのは、障害対応とOSやミドルウェア（OSと業務アプリの間で動く基盤のソフト）の更新です。モデル契約のオンサイト型のサンプルでは、アプリケーションの保守は外す一方で、機器やOS、ミドルウェアの保守は運用の委託に含めています。*1 どちらに入るかは言葉の意味では決まらず、契約で決まると考えておくと迷いません。
障害対応の切り分け方
障害対応は、運用と保守の両方が関わる代表的な作業です。共通フレームは、運用の側では当面の回避策として、使える機能を絞った運転など運用手順で対処することを挙げています。保守の側は、システムを直す前に問題報告や修正依頼を分析し、ほかの仕組みへの影響を明らかにすることが望ましいとしています。*2
- STEP1：運用が監視や問い合わせから異常に気づく
- STEP2：運用が回避策で業務を続けられるようにする
- STEP3：運用が問題報告や修正依頼をまとめて保守へ渡す
- STEP4：保守が影響を調べて直し、確かめてから運用へ戻す
つまずきやすいのはSTEP3の受け渡しです。共通フレームは、問題報告や修正依頼の文書化を運用者や利用者が行うよう契約で定めてもよいとし、問題の再現の確認を利用者が行うよう契約で定める場合もあるとしています。*2 誰が報告を書き、どこまで確かめてから渡すかを先に決めておくと、運用と保守の間の行き来を減らせます。
分けて頼むか一括で任せるか
モデル契約は、保守と運用の委託を「基本契約」と「個別契約」の2段にしています。保守と運用の仕事は幅が広く、どこを自社の要員で行い、どこを委託するかはその時々の必要しだいだからです。*1 時期を変えて、別の切り口で業務を切り出して頼むことも想定しています。
| 頼み方 | 向いている場面 | 気をつけること |
|---|---|---|
| 保守と運用を別々の会社に頼む | 運用は現場での作業や夜間の監視が要り、保守は開発した会社に続けてほしいとき | 障害のときの受け渡しの手順と連絡先を、両社を交えて決める |
| 保守と運用を1社にまとめて任せる | 社内の担当者が少なく、窓口を1つにしたいとき | 作業の中身が見えにくくなるので、報告の形と頻度を決める |
| 運用は自社で行い保守だけ頼む | 毎日の作業を回せる人は社内にいて、プログラムを直せる人がいないとき | 修正依頼の書き方と、再現を誰が確かめるかを決める |
どの形を選んでも、契約書に業務の名前を書くだけでは足りません。モデル契約は、オンサイト型の運用について、サービスの範囲と役割分担を利用者ごとの受託条件明細に、手順や連絡体制を運用手順書に書いて合意する形を示しています。*1 1社にまとめて任せる場合も、その中で運用と保守の作業を分けて書いておくと、あとで範囲を見直すときの土台になります。
外部に頼むときに確認しておきたい点
保守と運用の違いを踏まえて外部に頼むときは、見積もりを取る前に次の点をそろえておきます。各社の提案を同じ条件で並べられます。
- 範囲：表の作業のうち、どれを運用として、どれを保守として頼むか。OSやミドルウェアの更新をどちらに入れるか
- 期間と時間帯：受け付ける曜日と時間、夜間や休日の扱い。モデル契約のサンプルも、作業する曜日と時間帯を契約に書く形です
- 体制：窓口の責任者、障害のときの連絡の順番（エスカレーションのルール）、定例報告の頻度
- 費用の決まり方：決めた作業量を基準に月ごとに払うのか、改修を案件ごとに見積もるのか。範囲や手順を変えたときに金額を見直す手順も確かめます*1
- 引き継ぎ：設計書、手順書、過去の障害の記録など、渡せる資料。直した内容を設計書へ反映する担当も決めます
モデル契約は、システムの持ち主である利用者の側にも、保守の内容を設計書などへ漏れなく反映させることや、業務と設計のノウハウを円滑に引き継ぐことを求めています。*1 保守を頼む会社の比べ方はシステム保守会社の選び方、費用の内訳はシステム運用保守の費用相場と内訳やサーバー保守費用の内訳で扱っています。
まとめ：保守と運用で確かめておきたい3つの点
保守と運用の違いを外部への依頼に生かすうえで、確かめておきたい点は3つに整理できます。第一に、運用は動かす仕事、保守は直す仕事として、作業ごとにどちらに入るかを表にしておくこと。第二に、障害対応の受け渡しで、報告を誰が書き、再現を誰が確かめるかを決めること。第三に、分けて頼むか1社に任せるかを、社内に残る人と作業から選ぶことです。この3点を踏まえておけば、「頼んだつもりの作業が契約に入っていなかった」という事態を避けやすくなります。範囲の線引きや契約の形に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
保守と運用をまとめて運用保守と呼ぶのはなぜですか
どちらも稼働を始めたあとに続けて行う仕事で、契約もまとめて扱われることが多いためです。モデル契約も、保守と運用を1つの基本契約で扱い、ある範囲の保守運用業務をひとまとまりのサービスとして提供する例が多くなっていると説明しています。まとめて呼ぶ場合でも、中の作業は分けて書いておくと範囲の食い違いを防げます。
OSやミドルウェアの更新は保守と運用のどちらに入りますか
決まった答えはなく、契約で決めます。モデル契約のオンサイト型のサンプルは、機器やOS、ミドルウェアの保守を運用の委託に含め、アプリケーションの保守は外しています。*1 更新のあとに業務アプリの動きを誰が確かめるかも、あわせて決めておきます。
保守に必要な資料が残っていない場合はどうしますか
資料が無いまま頼むこともできますが、資料づくりも依頼の範囲に入れて考えます。共通フレームは、保守に必要な文書が無い場合、その作成と責任の範囲を契約に含めることがあるとしています。*2 見積もりの前に、残っている資料の一覧を相手に見せておくと話が早く進みます。
システムの保守と運用のご相談
保守と運用の範囲の線引きから、運用手順書の整備、障害のときの受け渡しの設計まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」（2025年4月8日更新）（https://www.ipa.go.jp/digital/model/model20201222.html）。出典：フェーズの概要（運用・保守の説明）、情報システム保守運用委託基本モデル契約書（第1条の解説）、業務仕様書サンプル（アプリケーション保守サービス、オンサイト型アウトソーシングサービス）と注釈を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「共通フレーム2013 第3部 共通フレームとガイダンス（ガイダンス部分の抜粋）」（https://www.ipa.go.jp/publish/qv6pgp000000107j-att/000062659.pdf）。出典：2.6 保守プロセス、3.1 運用プロセスのガイダンス（運用の範囲、回避策、問題報告・修正依頼の分析、再現確認、保守文書）を参照（2026年10月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）「SEC BOOKS：共通フレーム2013」（https://www.ipa.go.jp/publish/secbooks20130304.html）。出典：共通フレームの概要（構想から開発、運用、保守、廃棄に至るまでのライフサイクルを通じた共通の枠組み）を参照（2026年10月確認）
