運用保守・オンコール案件のフリーランス実情｜単価相場・手当・契約

運用保守・オンコール案件とは

結論：本番稼働中のシステムを安定させるための保守作業と、想定外の障害に対応する呼び出し当番（オンコール）を担う業務委託案件です。開発案件が「新しく作る」責務を負うのに対し、運用保守は「動かし続ける」責務を負います。

「開発」との違いと業務範囲

運用保守案件で扱う業務は、次のような範囲に整理できます。

開発案件が仕様書からコードを起こす作業に時間を割くのに対し、運用保守は「調査 → 記録 → 再発防止」のループが業務の中心です。この違いは単価と評価軸の両方に影響します。

役割の周辺にはSREやプラットフォームエンジニア、インフラエンジニアといった職種があり、監視ツールとしてDatadogやPrometheus & Grafanaが使われるケースが多く見られます。

オンコールの定義と稼働形態

オンコールとは、業務時間外に発生する障害に備えて呼び出しに応じられる状態を保つ勤務形態を指します。厚生労働省の考え方でも、待機時間そのものは労働時間として一律に扱われるわけではなく、使用者の指揮命令下にあるかどうかで判定されます。

もっとも、フリーランスは労働者ではなく業務委託の受託者になるため、労働時間の枠組みよりも契約書上の定義と実際の運用条件が重要になります。ここが会社員時代のオンコールと大きく違う点であり、契約書の設計次第で報酬の性格が変わります。契約名称と実態が乖離すると偽装請負や労働者性が争点になる場面もあるため、条件面は契約書で先に握るのが安全です。

ミニFAQ

• Q. 開発案件と運用保守を兼任するケースはある？

• A. あります。改修や機能追加を7割・保守作業を3割で走らせるハイブリッド案件はよく見られます。単価は「開発比率が高いほうへ寄る」傾向です。

• Q. 副業レベル（週1〜2日）でも入れる？

• A. 入れなくはありませんが、監視の当番設計を組みにくいため常駐比率の高い案件がまだ主流です。副業想定なら「日中の定期作業＋改善提案」型を探すのが現実的です。

案件の月額単価相場

結論から：首都圏中心の公開案件ベースでは月額50〜80万円帯が最も分厚く、経験年数3〜5年のフリーランスであればここに入るケースが多い水準です。

以下の数字は、2026年7月時点のギークスジョブ「保守／運用」カテゴリやインフラエンジニア案件ナビ「運用・保守」カテゴリなど、首都圏中心の主要フリーランスエージェント2〜4社の公開案件カテゴリを確認した目安です。週4〜5日稼働・準委任契約・実務経験3年以上を想定しています。

公開案件ベースの単価レンジ

公開案件で目立つのは50〜80万円のゾーンです。非公開案件では役割が上位ロール寄り（運用リード、SLA責任者）になる場合に、上振れするケースが個別にあります。ただし非公開案件は個別条件で振れ幅が大きく、公開案件と同列の目安として扱わないほうが安全です。

自分がどのレンジに入りそうか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。

単価が上がる条件

運用保守案件で単価が伸びるのは、次のような役回りを引き受けられる人です。

• 障害対応の主担当を任せられる：一次〜三次まで抜けなく回せて、事後の振り返りまで書ける

• クラウド運用の設計変更ができる：AWS／Azure／GCPで構成変更・コスト最適化まで踏み込める

• 運用の標準化を進められる：属人化していた手順をRunbook化し、他メンバーが再現できる形に整える

• アプリ側と会話できる：ログ・スタックトレースを読み、KubernetesやDockerの挙動を切り分けられる

• SLA運用の実務経験がある：応答時間・稼働率の測定と月次レポートを回した経験がある

これらは、単に「監視オペレーションができる」だけの経験より一段上のロールで、公開案件でも要件欄に頻出します。

ミニFAQ

• Q. 開発案件と保守案件で単価差はどのくらい？

• A. 公開案件を見比べる限りでは、同条件でも開発案件のほうが月額で10〜20万円程度高いケースが見られます。差が縮まるのは、運用側で「改善提案・標準化」まで踏み込める人材の場合です。

オンコール手当・待機報酬の考え方

結論：オンコール手当には法定の最低基準がなく、フリーランスは労働基準法の枠外で契約する立場です。契約書に「待機」「実対応」「呼び出し1回あたりの精算」を分けて書けているかが、実質的な報酬水準を決めます。

待機と実対応の切り分け

契約で分けておきたいのは、以下の3つのフェーズです。

1. 待機フェーズ：呼び出しに応じられる状態を維持する時間。稼働は伴わない

2. 一次対応フェーズ：呼び出しを受けてから状況把握までの短時間

3. 実対応フェーズ：復旧作業や事後対応が発生する時間

「待機は月額に含む／実対応は追加で時間精算」の切り分けが実務では現実的です。逆に、待機・実対応まで丸ごと月額固定にすると、深夜・休日の呼び出しが増えたときに割に合わなくなります。

相場と契約上の位置づけ

一般に「オンコール1回あたり数千円」といった数字が語られることがありますが、これは看護・介護現場の慣行を含む一般論で、フリーランスエンジニアの業務委託でそのまま使える金額ではありません。エンジニア案件では、次のような形が公開案件・面談情報を通じて見られます。

• 月額に一定回数まで含める形：オンコール当番を月◯回まで月額報酬に含める（超過分は別精算）

• 1回あたり定額＋実対応時間精算：待機に対して定額を上乗せし、実対応は時間単価で精算

• 時間単価の割増設定：案件によっては、深夜（22時〜翌5時）や休日を平時単価の1.25〜1.5倍で精算する例もあります（フリーランスの業務委託では労働基準法の割増賃金は適用されず、契約で個別に定める形です）

いずれも案件・エージェントによる差が大きく、相場として単一の数字を提示するのは難しい領域です。契約前に「呼び出し想定頻度」「1件あたりの想定復旧時間」「精算単位（15分刻みか、30分刻みか）」を必ず確認してください。

ミニFAQ

• Q. オンコール当番は断れる？

• A. 契約書に明記された義務であれば、断ると債務不履行と評価される可能性があります。参画前の交渉段階で、当番回数の上限や年末年始の扱いまで詰めておくのが安全です。

契約形態と契約書で必ず確認する条項

結論：運用保守の中核業務は準委任契約で設計されることが多いです。請負契約は「成果物の完成」を約束する契約形式のため、継続的な運用保守全体とは相性がよくないケースが多く、改修部分のみ請負で切り出す例が見られます。

準委任が主流な理由

準委任契約は「善良な管理者の注意義務（善管注意義務）」を負うものの、成果の完成を約束するものではありません。障害を「発生させない」ことは技術的に不可能なため、継続的な保守対応では準委任のほうが受託者側のリスクが小さくなります。契約形式の違いは準委任契約と請負契約の違いで整理しています。

SLA・応答時間・稼働率の書き方

SLA（サービスレベルアグリーメント）は、サービス品質を数値で約束する取り決めです。運用保守で頻出する項目は以下です。

契約書レビューでは、「達成できなかった場合の効果」も必ず確認します。単なる努力目標なのか、報酬減額があるのか、ペナルティ金額の上限があるのか、で受託リスクが大きく変わります。契約書全体のレビュー観点は業務委託契約書テンプレートにまとまっています。

免責・責任範囲

免責条項が広すぎないかも必ず確認します。次のようなケースは、契約上の免責対象として交渉されやすい項目です。

• 天災・停電など、受託者の管理外の事由

• クライアント側の指示に基づく作業で生じた損害

• ハードウェアやサードパーティサービスの障害

逆に、「一切の損害を賠償する」といった無限責任型の条項があると、事故時に個人事業では負いきれない金額のリスクを抱えることになります。責任額の上限（例：報酬額の3か月分まで、など）は設定を強く求めたい条項です。案件・クライアントによっては交渉が難しいケースもあるため、他条件と組み合わせて詰めます。

情報の取り扱い面では、監視ログや障害時のダンプに個人情報・顧客情報が含まれることが多く、秘密保持契約（NDA）の範囲は先に確認しておきます。

追加費用・精算方法

以下の精算条件は契約前に必ず確定させます。

• 精算幅：稼働時間の下限・上限（例：140h〜180h、超過は時間単価精算）

• 時間単価：超過稼働や実対応時の単価

• 深夜・休日の割増：割増率と適用時間帯

• 経費実費：交通費・オンコール用の通信費・機材の扱い

ミニFAQ

• Q. 準委任と請負を組み合わせた契約は可能？

• A. 可能ですが、部分ごとに明確に区分する必要があります。「監視・障害対応は準委任、改修は請負」といった切り分けを契約書内で明示します。

稼働イメージ・週稼働のパターン

運用保守案件の稼働形態は、大きく3パターンに分かれます。自分の生活リズムに合うかを事前にイメージしておくと、参画後のミスマッチを避けられます。

平日日勤のみパターン

営業時間（例：9〜18時）内の運用作業と一次対応を担当します。夜間・休日は別チームやベンダーに引き渡す形が中心です。

• 想定稼働：週4〜5日／平日中心

• オンコール：なし、または軽微な待機のみ

• 単価目安：50〜75万円

生活リズムを崩したくない人に向くパターンです。ただし、夜間・休日の重大障害では緊急連絡を受けるケースがあり、その扱いを契約書に書いておきます。

オンコール当番ローテパターン

複数人でローテーションを組み、順番に夜間・休日の呼び出しを受け持ちます。

• 想定稼働：週4〜5日＋当番週の夜間待機

• オンコール：月に数回〜週単位のローテ

• 単価目安：60〜85万円（オンコール手当を含む）

チーム規模が3〜5名程度で回っている場合に多く、当番の頻度が事前に予測しやすい設計です。参画前に「当番の頻度」「振替可否」「年末年始・大型連休の扱い」を確認しておきます。

障害対応シフトパターン

24時間365日体制で複数人がシフトを組み、夜間帯を交代で受け持ちます。

• 想定稼働：シフト制（早番／遅番／夜勤）

• オンコール：シフトの一部として組まれる

• 単価目安：55〜80万円（シフト手当を含む）

金融・EC・大規模SaaSなど、停止時のインパクトが大きいサービスで見られます。夜勤前後の休みを確保しにくく、生活面の負担が大きくなりやすい形態です。

ミニFAQ

• Q. リモートで運用保守案件は取れる？

• A. 取れます。監視や一次対応はリモートで完結する案件が見られる一方、常駐やハイブリッドも依然として多いのが実情です。公開案件では「フルリモート／リモートメイン」の記載も一定数見られますが、キッティングやオンサイト作業を含む案件は常駐条件が付きます。

ケース別解説

同じ「運用保守」でも、担当領域によって必要スキルと単価カーブが変わります。

インフラ系

サーバー・ネットワーク・ストレージなど基盤層を担当します。オンプレミス残存環境ではハードウェアや物理面の知識も求められます。

• 頻出スキル：Linux、Windows Server、Ansible、Terraform

• 単価目安：50〜80万円

• 差別化ポイント：構成管理コード化、SLA運用、ネットワーク切り分け

インフラ系全体のロードマップはインフラエンジニア独立の全手順にまとまっています。

アプリ系（Web/API保守）

既存アプリケーションのバグ修正、軽微な機能追加、外部連携の障害対応が中心です。

• 頻出スキル：Java、PHP、Python、Ruby、SQL、GitHub Actions

• 単価目安：55〜80万円

• 差別化ポイント：ログ解析、性能改善、レガシー環境のリファクタリング

長期常駐が組まれやすく、案件が切れにくいのが利点です。反面、レガシーコードのメンテで技術的な広がりに悩みやすい面もあります。

クラウド運用（AWS/Azure/GCP）

パブリッククラウド上のサービスの運用改善、コスト最適化、セキュリティ運用を担当します。

• 頻出スキル：AWS（EC2／ECS／Lambda）、Azure、GCP、CloudWatch／Datadog、CI/CD

• 単価目安：60〜100万円

• 差別化ポイント：IaC化、FinOps視点のコスト削減、可観測性の実装

クラウド運用は単価が伸びやすい領域で、SLA運用やKubernetesまで踏み込めると上位レンジに入りやすくなります。

案件獲得の実務

結論：まずはエージェントの「保守／運用／監視／SRE」タグを横断で絞り、そこにキーワード（技術名・業界名）を組み合わせるのが実務的です。直営業や知人紹介ルートは、既存案件で信頼を積んでからの拡張として位置づけるのが安全です。

エージェント経由が主流

運用保守案件は、業務内容と契約条件の細かい調整が必要になるため、契約書面のレビュー含めてエージェント経由が実務的です。参画前の面談での確認事項については別記事にまとめています。公開案件ベースで探すときは、以下の絞り込みが効きます。

• カテゴリタグ：保守／運用／監視／SRE／インフラ

• キーワード：AWS、Linux、Datadog、Ansible、24365、シフト

• 稼働条件：週4〜5、フルリモート／リモートメイン

• 契約形態：業務委託（準委任）

探し方と絞り込みキーワード

短時間で目視できる範囲まで案件を絞る手順は次のとおりです。

1. カテゴリで「保守・運用」を選ぶ

2. 稼働条件（週日数・リモート可否）で絞る

3. 単価下限を自分の希望値に設定する

4. 面談時に「オンコール頻度・SLA・引き継ぎ資料」を必ず質問する

5. 契約書ドラフトで「精算幅・時間単価・免責上限」を確認する

参画してから条件を交渉するのは難易度が高いため、契約前に詰めておくのが結局早い、というのが実務の相場観です。

よくある失敗と対策

運用保守案件で参画後に困るパターンをまとめます。

スコープが曖昧なまま参画

「運用全般をお任せ」といった広い記載のまま参画し、後から「これも運用の一部だと思っていた」と際限なく作業を振られるケースです。契約書の対象範囲に対象システム名・対象作業の一覧を別紙で必ず添付します。

オンコール手当を後付けで交渉

「最初の1〜2か月は当番なしと言われていたのに、いつの間にか組み込まれていた」という事例が典型です。参画時点の契約書に当番の有無・頻度・精算方法を先に書き込みます。後付けの交渉は関係性が悪化しやすく、単価に反映されない可能性が高くなります。

引き継ぎ資料不足

Runbookやアーキテクチャ図が整備されていない現場に参画すると、初動で消耗しがちです。面談時に現状のドキュメント整備状況を必ず確認し、無ければ「最初の1〜2週間はドキュメント整備の稼働を認めてもらう」ことを条件に加えます。

監視アラートの誤検知が多すぎる

閾値設計が甘い現場では、アラート疲れで実際の障害を見落とすリスクが高まります。参画後の早期に、直近1〜3か月のアラート履歴を確認し、誤検知を削るタスクを合意しておきます。

実践チェックリスト

参画前に確認しておきたい項目です。契約書レビュー時にそのまま使えます。

• 対象システム一覧が別紙で明示されているか

• SLAの数値（応答時間・稼働率）と、未達時の効果が書かれているか

• オンコール当番の有無・頻度・振替可否・精算方法が明記されているか

• 深夜（22時〜翌5時）・休日の割増率が定義されているか

• 精算幅（下限〜上限稼働時間）と超過分の時間単価が書かれているか

• 免責条項に無限責任型の記載がないか、責任上限が設定されているか

• Runbookなどの引き継ぎ資料が整備されているか、無ければ整備稼働を認めてもらえるか

• 情報取扱いの範囲・持ち出し可否がNDAで確認されているか

• 契約期間・更新条件・解約通知期間が定められているか

まとめ

運用保守・オンコール案件は、公開案件ベースで月額50〜80万円が主流ゾーンで、単価を伸ばす鍵はオンコール手当の設計と契約書の作り込みにあります。

• 月額単価のボリュームゾーンは50〜80万円、上位は100万円前後（週4〜5日・準委任）

• オンコール手当は法定基準がなく、契約書での切り分けが実質的な報酬水準を決める

• 準委任契約が実務に合う。SLA・免責・精算幅・オンコール条件は参画前に必ず握る

• 参画後の交渉は難易度が高いため、契約前に「対象範囲・当番・引き継ぎ資料」を確認する

• クラウド運用・SRE寄りに踏み込むと単価は伸びやすい

次のステップとしては、まず現時点の市場単価を把握するためにフリーランスエンジニア単価診断で目安を確認し、そのうえで運用保守カテゴリの公開案件から絞り込んでいくのが実務的です。

参照

• 厚生労働省「労働時間・休日・休暇・賃金」

• ギークスジョブ 保守／運用カテゴリ

• インフラエンジニア案件ナビ 運用・保守カテゴリ