外部エンジニアの障害対応・オンコール体制の作り方｜契約と偽装請負の注意点

「夜中にサービスが止まったら、いったい誰が動くのだろう」——外部のエンジニアに開発も運用も任せている発注企業の担当者なら、一度はこの不安を抱えたことがあるのではないでしょうか。社内に運用やインフラの専任者がおらず、システムを作ってくれた業務委託・フリーランスのエンジニアにそのまま運用も頼んでいる。平日の日中は問題なく回っているけれど、夜間や休日に障害が起きたとき、誰がどれくらいの速さで直してくれるのかが曖昧なまま、という状態です。

この不安が厄介なのは、「穴があること」自体は何となく分かっているのに、何が問題で、どう手を打てばいいのかが言語化できないところにあります。外部の人に「この時間に対応してほしい」と頼んでいいのか、それは偽装請負にならないのか。当番を頼んだら断られないか、いざというとき連絡がつかなかったらどうなるのか。かといって24時間365日の手厚い体制を組めば、コストが青天井になりそうで踏み切れない——こうした迷いが重なって、結局「何かあったら都度お願いする」という曖昧な運用のまま、いつ来るか分からない深夜の障害に怯えることになります。

実は、この問題は「優秀なエンジニアを確保できているか」とは別の、体制設計の問題です。障害対応・オンコール（夜間休日の待機）の仕組みは、運用の専任者がいなくても、平時に「どこまで守るか」を決め、契約に何を書き、誰がどう待機するかを段階的に組み立てることで、属人化させず・違法にならず・コストも必要十分に抑えた形で作ることができます。

本記事では、外部エンジニアを含む障害対応・オンコール体制を発注者が作るための実務を、運用設計・契約／法務・属人化対策の3つの観点から一気通貫で解説します。まず障害対応の穴がなぜ生まれるかを構造的に整理し、自社の可用性要求から体制レベルを選ぶ判断軸、最大の不安である偽装請負を避けた依頼方法、委託契約とSLAに盛り込むべき項目、そして属人化・連絡不能を防ぐ運用の仕組みまでを順に見ていきます。

外部エンジニアに運用を任せると「障害対応の穴」が生まれる理由

体制を設計する前に、まず「なぜ穴が生まれるのか」を構造として理解しておくと、自社のどこが弱いのかを当てはめやすくなります。外部エンジニアに開発と運用をまとめて任せている発注企業で起きがちな穴は、大きく3つのパターンに整理できます。

「開発できる＝運用も任せられる」という思い込み

システムを作ってくれたエンジニアは、その仕組みを誰よりも理解しています。だからこそ「運用もそのままお願いすれば安心」と考えるのは自然な流れです。しかし、開発フェーズと運用フェーズでは、求められる動き方が大きく異なります。

開発は「決められた仕様を、ある程度まとまった時間をかけて作り上げる」仕事です。一方で運用、とくに障害対応は「いつ起きるか分からない異常に、即座に反応して復旧させる」仕事です。前者は計画的に進められますが、後者は本人の稼働時間や生活リズムに直接ぶつかります。フリーランスや業務委託のエンジニアの多くは、複数のクライアントを並行して抱えていたり、稼働時間を平日日中に区切っていたりします。「開発はできる」ことと「いつでも障害に反応できる」ことは別物であり、ここを暗黙のうちに同一視してしまうと、夜間・休日にぽっかりと対応の空白が生まれます。

障害対応が契約に書かれていないと起きること

もう一つの典型的な穴は、障害対応の条件が契約に明記されていないケースです。「運用もお願いします」という口約束だけで進めていると、いざ障害が起きたときに次のような問題が一気に噴き出します。

• 対応義務の不在: 委託契約に「障害が起きたら対応する義務」が書かれていなければ、外部エンジニアには法的にも契約的にも、夜間に対応する義務はありません。善意で動いてくれることに依存した状態です。
• 対応時間帯の不在: 「何時から何時まで対応するのか」が決まっていないため、稼働時間外の障害は誰の責任でもない宙ぶらりんの状態になります。
• 連絡先・連絡手段の不在: 普段はチャットでやり取りしていても、深夜にそのチャットを見ているとは限りません。緊急時にどの手段で、誰に連絡すれば確実につながるかが決まっていないと、復旧の起点である「気づいて連絡する」段階で時間を失います。

障害対応は、平時には存在しないように見えますが、有事には契約に書かれていない部分がそのまま「動かない理由」になります。

外部エンジニア1人に依存した単一障害点リスク

3つ目の穴は、特定の1人にすべてを依存している状態です。システムを作った1人のエンジニアだけが構成や運用手順を把握していると、その人がつかまらない瞬間にシステム全体が止まる「単一障害点」が、人の側に生まれてしまいます。

このリスクは、本人の能力とは無関係に発生します。どれだけ優秀でも、人は体調を崩しますし、旅行にも行きますし、別の急ぎ案件と重なることもあります。たまたまその人が動けないタイミングと障害が重なれば、復旧は止まります。さらに、その1人が将来契約を終了して離れた場合、運用知識ごと失われるリスクも抱えることになります。

これら3つの穴——稼働時間のギャップ、契約の空白、属人化——は、どれも「外部エンジニアに任せきりにしている」状態から自然に生まれるものです。裏を返せば、この後の章で扱う「体制レベルの決定」「契約への明文化」「属人化対策」が、それぞれの穴に対応した打ち手になります。

まず決める「どこまで守るか」——可用性要求から体制レベルを選ぶ

障害対応・オンコール体制を考えるとき、いきなり「24時間365日の当番をどう組むか」から入ると、コストも負担も過大に感じて手が止まります。出発点はそこではなく、「自社のサービスは、どこまで止まってはいけないのか」を言語化することです。守るべき水準が決まれば、必要な体制レベルは自ずと絞り込めます。

体制レベルの3段階

業務委託のエンジニアを含むオンコール体制は、おおまかに3段階で考えると整理しやすくなります。

• レベル1: 営業時間内のみ対応: 平日の日中（たとえば9〜18時）に発生した障害のみ対応する。夜間・休日の障害は翌営業日の対応となる。社内向けの業務システムや、夜間に使われないサービスに適しています。
• レベル2: 平日夜間・休日は重大障害（P1）のみ対応: 通常は営業時間内対応だが、サービス全体の停止やデータ欠損のような重大障害（一般にP1と呼ばれる最優先度の障害）に限り、時間外でも待機者が対応する。多くの中小規模サービスが現実的に落ち着く水準です。
• レベル3: 24時間365日対応: 軽微な障害も含め、常に誰かが対応できる体制。金融・医療・大規模ECなど、停止が直接的な損失や信用毀損につながるサービス向けです。

ここで重要なのは、レベルが上がるほど待機の負担も費用も増えるという点です。最初から最上位を目指す必要はなく、自社のサービスがどのレベルを必要としているかを見極めることが先決です。

「止まると何を失うか」で必要レベルを判断する

どのレベルが必要かを判断する基準は、「サービスが止まったときに何を、どれくらい失うか」です。次のような問いに具体的に答えてみると、過不足のない水準が見えてきます。

• 1時間止まると、売上・顧客・信用のどれを、どの程度失うか
• 夜間（利用が少ない時間帯）に止まった場合と、日中に止まった場合で、損失はどう違うか
• 顧客や取引先と、復旧時間に関する約束（SLA）を交わしているか
• 止まったときに「翌朝までに直っていればよい」のか「30分以内に直さないと困る」のか

たとえば、夜間はほとんど利用のない社内システムであれば、夜中に重い当番を置くコストは見合いません。逆に、24時間稼働の決済サービスで深夜に止まれば、その間の取引がすべて失われます。「止まると失うもの」が大きく、かつ「止まりうる時間帯」が広いサービスほど、上位の体制レベルが必要になります。この判断を感覚ではなく金額・件数のレンジで言語化しておくと、後で外部エンジニアへの依頼内容やコストの妥当性を説明する材料にもなります。

段階的に体制を上げる進め方

体制レベルは、一度決めたら固定するものではありません。むしろ、最小限から始めて事業の成長に合わせて段階的に引き上げるのが現実的です。

運用の専任者がいない発注企業がいきなりレベル3を組もうとすると、外部エンジニアへの依頼コストも、社内の調整負荷も跳ね上がり、結局回らなくなりがちです。まずはレベル1（営業時間内対応）で対応範囲を契約に明文化するところから始め、重大障害が時間外に起きて困った経験が出てきた段階でレベル2へ、事業がスケールして停止が許されなくなった段階でレベル3へ、と引き上げていく進め方が無理がありません。

「今の自社にはどのレベルが必要十分か」を一度決め、過剰な体制を最初から抱え込まないこと——これが、コストを青天井にせず体制を作る出発点になります。

業務委託のエンジニアに障害対応・オンコールを頼むと偽装請負になる？

ここが、外部エンジニアへの時間外対応の依頼を最もためらわせる論点です。「業務委託の人に夜間対応を頼むのは、偽装請負になるのではないか」という不安に、正面から向き合います。結論から言えば、依頼の仕方を誤らなければ、外部エンジニアに障害対応やオンコールを依頼すること自体が直ちに違法になるわけではありません。問題になるのは「どう依頼するか」です。

偽装請負になる／ならないの分かれ目は「指揮命令」

偽装請負とは、契約の形式は業務委託や請負でありながら、実態として発注者が外部エンジニアを自社の従業員のように直接指揮命令して働かせている状態を指します。形式的には委託契約をとりながら、実態が労働者派遣に該当してしまうケースです。

適正な業務委託（請負・準委任）と労働者派遣を区別する基準は、厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」に整理されています（労働者派遣事業と請負により行われる事業との区分に関する基準（厚生労働省告示））。ポイントを発注者の目線でかみ砕くと、次のようになります。

• 指揮命令をしているか: 業務の遂行方法・手順・時間配分などを発注者が逐一指示している場合、指揮命令関係があると判断されやすくなります。
• 労働時間を管理しているか: 始業・終業の時刻や作業場所を発注者が拘束・管理していると、雇用に近い実態とみなされやすくなります。

そして、この判断は契約書の文言だけでなく、実際の業務のやり取りの実態を踏まえて総合的に行われます（偽装請負の判断基準と違反のリスク（TMI総合法律事務所））。つまり「契約書には委託と書いてあるから大丈夫」とは限らず、日々の依頼の仕方そのものが問われます。

障害対応という緊急場面でリスクが高まる理由

通常の開発業務では「成果物を納品してもらう」「決めた範囲を完成してもらう」という形を保ちやすいため、指揮命令の問題は比較的起きにくいものです。ところが障害対応は、この前提が崩れやすい場面です。

障害が起きると、発注者側は気が動転して「今すぐこのサーバーを再起動して」「先にあっちのログを見て」「電話を切らずにそのまま作業して」と、つい手順や時間配分を細かく指示してしまいがちです。緊急であればあるほど、相手を自社の手足のように動かしたくなります。しかし、こうした「今すぐこれをこの手順でやって」という逐一の指示が積み重なると、それはまさに指揮命令そのものであり、偽装請負と判断される実態を作り出してしまいます。

緊急時こそ直接指示が起きやすい——ここが、多くの発注者が見落としている盲点です。だからこそ、障害対応の依頼方法は「緊急になってから考える」のではなく、平時に設計しておく必要があります。

偽装請負を避けて依頼する3つの工夫

緊急場面でも適正な委託の形を保つために、発注者ができる工夫は次の3つです。

1. 成果・役割で依頼し、手順や時間配分は委ねる: 「サービスを復旧させること」という成果や「障害発生時の一次対応を担う」という役割で依頼し、具体的にどの順番で何をどう操作するかという手順は外部エンジニアの裁量に委ねます。発注者が伝えるのは「何が起きていて、何を達成してほしいか」（症状と求める結果）であり、「どうやるか」（手順）は指示しないのが原則です。
2. 対応範囲・連絡フローを契約とランブックに事前に落とす: 「どの時間帯に、どのレベルの障害について、どう連絡を受け、何を達成するか」をあらかじめ契約と手順書（ランブック）に明文化しておけば、障害発生時に逐一指示しなくても、合意済みのルールに沿って外部エンジニアが自律的に動けます。緊急時の場当たり的な指示を減らすことが、そのまま偽装請負リスクの低減につながります。
3. 緊急時の依頼方法を平時に合意しておく: 「重大障害が起きたら、まずこの連絡手段で第一報を入れる」「対応の進捗はどの粒度で共有する」といった緊急時のコミュニケーションの型を、平時のうちに双方で合意しておきます。型が決まっていれば、有事に発注者が細かく指示を出す余地が減ります。

要するに、緊急時に「人を動かす」のではなく、平時に「ルールと手順を整えておき、有事はそのルールが動く」状態を作ることが、偽装請負を避けながら障害対応を委託する核心です。

判断に迷うケースは専門家へ

ここで解説した区分はあくまで一般的な考え方であり、実際の判断は契約内容と業務の実態を総合して個別に行われます。自社の依頼の仕方が指揮命令にあたらないか、契約書の文言が実態と整合しているかに不安がある場合は、自己判断で進めず、弁護士や社会保険労務士など労務・契約の専門家に確認することをおすすめします。とくに、対応時間帯の拘束を契約に盛り込む場合や、常駐に近い形で待機を求める場合は、専門家のレビューを受けてから運用に移すのが安全です。

委託契約とSLAに盛り込むべき項目

体制レベルを決め、偽装請負を避けた依頼方法を理解したら、次はそれを「口約束」ではなく契約に落とし込みます。障害対応・オンコールに関して、委託契約やSLA（サービスレベルに関する合意）に明記しておきたい項目を整理します。雛形をそのまま写すのではなく、先ほど決めた自社の体制レベルに合わせて、どこまでを盛り込むかを選んでください。

対応時間帯・応答時間・復旧目標（SLA/SLO）の決め方

まず核になるのが、「いつ・どれくらいの速さで対応するか」を数値で合意することです。主に次の3つを定めます。

• 対応時間帯: 障害対応を受け付ける時間帯。レベル1なら「平日9〜18時」、レベル2なら「平日9〜18時＋時間外は重大障害のみ」、レベル3なら「24時間365日」というように、選んだ体制レベルをそのまま反映します。
• 応答時間: 障害の連絡を受けてから、外部エンジニアが対応に着手する（あるいは一次返信する）までの目標時間。「30分以内に着手」「1時間以内に状況連絡」のように定めます。
• 復旧目標（目標復旧時間／RTO）: 障害発生から復旧までに目指す時間。クラウドサービスのサービスレベル項目でも、目標復旧時間（RTO）や平均復旧時間といった指標が用いられています（クラウドサービスレベルのチェックリスト（assured.jp））。

ここで現実的に重要なのは、復旧時間を「必ず◯分で直す」という確約（SLA）にするか、「◯分での復旧を目指す」という努力目標（SLO）にするかの線引きです。ソフトウェアの障害は原因によって復旧時間が大きく変わるため、何でも確約にすると外部エンジニアが受けてくれなかったり、達成不能なペナルティを抱え込ませたりします。「応答時間は確約、復旧時間は努力目標」のように、達成可能性に応じて確約と努力目標を使い分けるのが現実解です。

オンコール（待機）の有無と手当の考え方

時間外対応を依頼するなら、その「待機」に対する手当をどう設計するかも決めておきます。オンコールでは、実際に呼び出されて作業した時間だけでなく、「いつ呼ばれるか分からない状態で備えていること」自体に対して手当を払うのが一般的です。

手当の設計は、おおむね次の2階建てで考えると整理できます。

• 待機手当: 呼び出しがあってもなくても、待機していること自体に支払う固定額。IT分野では、平日夜間で1回あたり数千円、休日終日で1日あたり数千〜1万円程度、週単位の当番制で週あたり1〜3万円程度が一つの目安として紹介されています（オンコール勤務とは（freee））。金額はサービスの重要度・呼び出し頻度・対応の負担に応じて、外部エンジニアと個別に合意します。
• 実対応分の報酬: 実際に呼び出されて作業した時間に対する報酬。通常の委託単価に時間外割増を設けるなど、待機手当とは別に定めます。

ここで挙げた金額はあくまで一般的な相場感であり、実際にはフリーランスの稼働状況やスキル、サービスの停止リスクの大きさによって変わります。重要なのは「待機そのものに対価を払う」という考え方を前提に置くことです。これを無報酬で当然のように求めると、外部エンジニアの離脱や、いざというときに動いてもらえないリスクにつながります。

エスカレーションの連絡フローと対応範囲外の扱い

「誰に・どの順番で・どの手段で連絡するか」というエスカレーションの連絡フローも、契約や運用ルールに含めておきます。具体的には次のような点を定めます。

• 障害を検知したら、まず誰に第一報を入れるか（一次対応者）
• 一次対応者が一定時間内に応答しなかった場合、次に誰へ連絡するか（二次対応者・バックアップ）
• 連絡手段（電話・専用のチャット・通知ツールなど）と、確実につながる経路の確保

あわせて、「対応範囲外」の扱いも明確にしておくとトラブルを防げます。たとえば、外部エンジニアが担当していない領域（ネットワーク事業者やクラウド基盤側の障害など）が原因の場合に、どこまでが委託先の責任で、どこからが発注者側や他事業者の領分かを切り分けておきます。これがないと、原因がはっきりしない障害のときに「これは自分の担当ではない」という押し付け合いで時間を失います。

準委任契約と請負契約で変わる障害対応の責任範囲

最後に、契約の種類によって責任範囲が変わる点も押さえておきます。外部エンジニアとの契約は、多くの場合「準委任契約」か「請負契約」のいずれかです。

• 請負契約: 「成果物の完成」に責任を負う契約です。仕事を完成させる義務があるため、納品物の不具合に対する責任（契約不適合責任）は問いやすい一方、障害対応のような「継続的に発生する不定形な作業」を請負の枠で縛るのは設計が難しく、なじみにくい面があります。
• 準委任契約: 「定められた業務を善良な管理者の注意をもって遂行すること」に責任を負う契約です。成果物の完成までは保証しませんが、「障害発生時に合意した手順・水準で対応する」という運用・対応業務とは相性がよく、オンコールや継続運用は準委任で結ぶのが一般的です。

どちらの契約形態を選ぶにせよ、「障害対応で何をどこまで保証してもらえるのか」は契約の種類だけで自動的に決まるわけではなく、契約書に書いた対応時間帯・応答時間・復旧目標などの個別条項で具体化されます。契約形態の特性を理解したうえで、自社が求める責任範囲を条項として明記することが大切です。

属人化・連絡不能を防ぐ運用の仕組み

契約を整えても、それだけでは防げない穴があります。「結局その人しか分からない」という属人化と、「いざというとき連絡がつかない」という連絡不能です。ここは契約条項ではなく、日々の運用の仕組みで埋めていく領域です。運用専任者がいない前提で、最小限の仕組みから始められる現実解を示します。

対応をランブック化して「その人しか分からない」を減らす

属人化を解く最も効果的な一手は、障害対応の手順を「ランブック」として文書化することです。ランブックとは、「この症状が出たら、まずこれを確認し、次にこう対処する」という対応手順をまとめた手順書です。

ランブックがあると、いくつもの効果が生まれます。第一に、特定の1人がつかまらないときでも、別の人が手順書をたどって一次対応に着手できます。第二に、外部エンジニアに依頼する際も「ランブックに沿って対応する」という成果ベースの依頼ができるため、緊急時に発注者が逐一指示する必要が減り、偽装請負リスクの低減にもつながります。第三に、その外部エンジニアが将来離れても、運用知識が文書として残ります。

最初から完璧なものを目指す必要はありません。過去に起きた障害や、起きたら影響が大きい代表的な障害について、「検知方法・連絡先・一次対応手順」を数枚にまとめるところから始め、障害が起きるたびに追記していけば十分に育ちます。ランブックの整備自体を、契約する外部エンジニアへの依頼項目に含めておくのも有効です。

当番ローテーションとバックアップ要員

1人への依存を解くもう一つの仕組みが、複数人での当番ローテーションです。理想は外部エンジニア2名以上で当番を回すことですが、委託先が実質1名という発注企業も少なくありません。その場合でも、次のような工夫で単一障害点を緩和できます。

• 外部＋社内の混成: 高度な復旧対応は外部エンジニアが担い、一次受け（検知して連絡する・状況を確認する）は社内の誰かが担える状態にしておく。社内に技術専任がいなくても、「異常に気づいてランブックに沿って連絡を入れる」役割なら担えます。
• バックアップ要員の確保: 主担当の外部エンジニアが対応できないときに連絡する二番手を、あらかじめ決めておく。同じ委託先の別メンバーや、別途契約した予備の委託先などが候補になります。
• 当番の負担を平準化する: IT分野では、平日は日替わり、休日は週替わりといったハイブリッドな当番の組み方が負担のバランスを取りやすいとされています（オンコール勤務とは（freee））。当番表を作って負担を見える化すること自体が、特定の人への偏りを防ぎます。

「2人目を確保するコスト」と「1人に依存し続けるリスク」を天秤にかけ、事業の重要度に応じて段階的に冗長性を持たせていくのが現実的です。

連絡手段の二重化と監視・通知の自動化

最後に、「気づけない」「連絡がつかない」をなくす仕組みです。障害復旧は「異常に気づいて、対応者につなぐ」ところから始まります。この入口が詰まると、どれだけ契約を整えても復旧は始まりません。

• 連絡手段の二重化: 普段使いのチャットだけに頼らず、電話や専用の通知ツールなど、深夜でも確実に相手に届く経路を二系統用意しておく。第一の連絡が一定時間つながらなければ第二の手段・第二の人へ、という流れを決めておきます。
• 監視・通知の自動化: 人が常時画面を見張るのではなく、システムの異常を自動で検知して、あらかじめ決めた対応者へ通知が飛ぶ仕組みを入れる。これにより、「誰も異常に気づかないまま朝を迎える」という最悪のパターンを防げます。誰が見ても異常に気づける状態を作ることは、属人化対策そのものでもあります。

監視・通知の仕組みづくりは、運用を委託している外部エンジニアに「どんな異常を、どの経路で、誰に通知する設定にするか」を相談して整えるとよいでしょう。最小限でも「サービス全体の停止だけは自動で検知して、対応者へ通知が飛ぶ」状態を作っておくだけで、夜間障害への備えは大きく変わります。

体制を作ったら備える——実際に障害が起きたときの動き方

ここまでで、平時に「外部エンジニアを含む障害対応・オンコール体制」を設計・契約・運用する流れを見てきました。体制レベルを選び、偽装請負を避けた依頼方法を理解し、契約とSLAに必要項目を盛り込み、属人化と連絡不能を仕組みで防ぐ——これらが整えば、深夜の障害に対する備えは大きく前進します。

ただし、平時に体制を整えることと、実際に障害が起きた瞬間に発注者として正しく動けることは、別の準備です。仕組みがあっても、いざ障害が発生したときに「ベンダーにどう連絡し、社内・顧客にどこまで・どのタイミングで報告し、何をもって復旧と判断するか」という有事の動き方が曖昧では、せっかくの体制を活かしきれません。

実際に本番障害が起きたときの発注者としての対応フロー——ベンダーへの連絡判断、社内・関係者への報告基準、影響範囲の見極め、復旧確認の進め方——については、【発注者向け】本番障害の対応フローで具体的に解説しています。本記事で整えた「平時の体制」と、有事の対応フローをセットで準備しておくことで、初めて深夜の障害に落ち着いて向き合える状態になります。

最後に、本記事の要点を整理します。

• 穴の構造を知る: 外部エンジニアに運用を任せると、稼働時間のギャップ・契約の空白・属人化という穴が生まれる。
• どこまで守るかを先に決める: 「止まると何を失うか」から体制レベル（営業時間内／時間外は重大障害のみ／24時間365日）を選び、最小限から段階的に上げる。
• 偽装請負は依頼の仕方で避ける: 緊急時こそ逐一の指示が起きやすい。成果・役割で依頼し、ランブックと事前合意で「ルールが動く」状態を作る。
• 体制を契約に落とす: 対応時間帯・応答時間・復旧目標・オンコール手当・連絡フロー・契約形態の責任範囲を明文化する。
• 属人化を仕組みで防ぐ: ランブック・当番ローテーション・連絡手段の二重化・監視通知の自動化で、1人依存と連絡不能をなくす。
• 平時の体制と有事のフローをセットで備える: 体制設計に加え、実際に障害が起きたときの対応フローも準備しておく。

外部エンジニアに頼っているからこそ、平時の設計が安心の土台になります。今の自社の体制を、本記事のチェックポイントに一つずつ当てはめるところから始めてみてください。