サーバー・インフラ構築のトラブル対処は、着手前に決めた範囲と支払い条件で決まる

2026年1月17日

朝比奈蒼

この記事のポイント

✓サーバー・インフラ構築のトラブル対処で揉める原因は
✓技術ではなく取り決めの不足です
✓免責をどう書面にするか

サーバー・インフラ構築のトラブル対処で揉めるかどうかは、障害が起きた瞬間ではなく、着手前の取り決めで決まっています。結論から言うと、対応範囲と支払い条件を書面にしていない案件は、ほぼ確実に揉めます。技術的に正しく復旧できたかどうかは、実は二次的な問題です。「これは契約に含まれていたのか」「この時間の作業は請求できるのか」という認識のずれが、関係を壊します。この記事では、障害が起きる前に決めておくべき項目と、決めていなかった場合にどう立て直すかを、実務の流れに沿って整理します。

障害は「起きるかどうか」ではなく「いつ起きるか」の話

まず前提を共有します。サーバーは壊れます。これは技術力の問題ではなく、物理的な必然です。

内部的な要因の1つ目は、サーバーのハードウェア自体の不具合や故障によるものです。家電製品と同じく、サーバーの部品やパーツにも耐用年数があり、使い続ければ劣化していきます。それらの一部でも故障すれば、正常に動作しなくなりサーバー障害につながることがあります。サーバーは熱を持ったまま24時間稼働し続けるため過剰な負荷がかかり、劣化しやすいといわれているため、定期的なメンテナンスが必要です。出典: biz.techvan.co.jp

ハードウェアの劣化に加えて、外部要因もあります。回線の障害、クラウド事業者側の障害、アクセス集中、不正アクセス、電力供給の停止。構築を担当した人がどれだけ丁寧に作っても、これらを完全には防げません。

この前提が共有されていないと、話がこじれます。依頼者側に「きちんと作られていれば止まらないはず」という認識があると、障害が起きた時点で構築者の責任という話になってしまう。だから着手前に、止まる可能性があること、止まったときにどう対応するかを説明しておく必要があります。これは責任逃れではなく、対応の設計です。

構築の請負と、保守の準委任は別物

契約の性質として、この2つは分けて考えます。構築作業は「完成させて引き渡す」性質の仕事です。一方で保守や障害対応は「一定期間、対応可能な状態を維持する」性質の仕事です。前者は成果物に対して報酬が発生し、後者は期間と体制に対して報酬が発生します。

ここを一体で扱うと、境目が消えます。「構築してもらったのだから、動かなくなったら直してくれるはず」という期待が生まれる。構築費用の中に無期限の保守が含まれていると解釈されると、いつまでも無償対応を求められることになります。

正直なところ、この混同は依頼者側の悪意ではなく、単純に説明されていないことが原因である場合がほとんどです。だから、見積もりの段階で構築費と保守費を明確に分けて提示する。この1つの工夫だけで、後の摩擦がかなり減ります。

着手前に決めておくべき項目

具体的に何を決めておくべきかを列挙します。すべてを重厚な契約書にする必要はありません。メールでも合意書でも、記録に残る形であればまず十分です。

対応する範囲を、対象と作業の両面で書く

範囲の定義は、対象システムと作業内容の2つの軸で書きます。

対象については、「このサーバー」だけでは足りません。サーバー本体、その上で動くミドルウェア、アプリケーション、データベース、ネットワーク機器、回線。どこまでが自分の担当なのかを明示します。特にアプリケーションは境界が曖昧になりやすい部分です。アプリの不具合が原因でサーバーの負荷が上がった場合、それはインフラ側の問題なのか。事前に決めておかないと、障害のたびに責任の押し付け合いになります。

作業内容については、監視するのか、検知したら連絡するのか、復旧作業まで行うのか、原因調査と報告書の作成まで含むのかを分けて書きます。この4つは別々の作業であり、必要な時間もまったく違います。

対応する時間帯と、応答までの時間を数字で決める

平日の何時から何時まで対応するのか。土日祝日は対応するのか。夜間はどうするのか。この3点は必ず数字で書きます。

あわせて、連絡を受けてから応答するまでの目安時間も決めます。「平日9時から18時の連絡には2時間以内に一次返信」といった形です。ここを決めておかないと、依頼者は即時対応を期待し、受注者は「気づいたときに」と考える。このずれが不満に変わります。

個人や少人数で受ける場合、24時間365日の体制は現実的に持てません。専業の事業者はそこを組織で担っています。

システム開発で培った確かな技術と幅広いシステムの導入実績で培ったノウハウを生かし、経験豊富なテクバンのITエンジニアが、お客様に代わって24時間365日リモートでサーバー監視を行います。少しでも異常を検知したら、障害の一次～二次対応を行うことも可能です。「夜間や休日のみだけ対応してほしい」などお客様のご要望に合わせたサポート体制をご提案しますので、お気軽にご相談ください。出典: biz.techvan.co.jp

交代要員がいる組織だからこそ、常時対応が成り立ちます。一人で受ける場合は、そこを正直に伝えるべきです。「夜間の即時対応はできません。翌営業日の対応になります」と先に言っておけば、依頼者は必要に応じて別の手当てを検討できる。できないことを黙って引き受けるほうが、最終的に信頼を失います。

料金体系を、発生条件とセットで決める

保守や障害対応の料金には、いくつかの型があります。どれを選ぶかより、発生条件が明確かどうかのほうが重要です。

月額固定型は、毎月一定額を受け取り、決められた範囲の対応を行う形です。対応の有無にかかわらず収入が安定する反面、範囲を曖昧にすると青天井の作業を求められます。範囲外の作業は別料金になることを明記してください。

時間単価型は、実際に作業した時間に応じて請求する形です。公平ですが、作業時間の記録と報告が必須になります。何時から何時まで、何をしたのかを残す習慣がないと請求できません。

回数制やチケット制は、あらかじめ決めた回数分の対応を含める形です。回数を超えた分は追加請求になるので、依頼者側にも歯止めが効きます。

いずれの型でも、移動を伴う現地作業、深夜早朝の作業、原因が依頼者側の変更にあった場合の作業については、割増や別途請求のルールを決めておきます。

免責と、責任の上限を書く

これは書きにくい項目ですが、書かないほうが危険です。

クラウド事業者側の障害、回線事業者の障害、天災、依頼者が独自に行った変更に起因する不具合。これらについて受注者が責任を負わないことを明記します。あわせて、損害賠償が発生する場合の上限額を定めておく。一般的には、その契約で受け取る報酬額を上限とする形が使われます。

※損害賠償の範囲や上限の定め方は、契約の内容や取引の実態によって有効性の判断が変わることがあります。金額の大きい案件や、業務停止による損害が想定される案件では、契約書の作成段階で弁護士に確認してください。

書面に入れておく項目を一覧で確認する

ここまでの内容を、実際に書面へ落とすときの項目としてまとめます。重厚な契約書でなくても、この項目が埋まっていれば実務上の争いはかなり減ります。

項目	決めておく内容
対象範囲	サーバー、ミドルウェア、アプリケーション、ネットワークのどこまでを担当するか
作業範囲	監視、検知連絡、一次対応、復旧作業、原因調査、報告書作成のどれを含むか
対応時間帯	平日の時間帯、土日祝の扱い、夜間の扱い
応答時間	連絡を受けてから一次返信までの目安時間
料金体系	月額固定、時間単価、回数制のいずれか。範囲外作業の単価
割増条件	深夜早朝、休日、現地作業の割増率
支払期日	請求から支払いまでの期間と支払方法
免責事項	責任を負わない事象の列挙
責任上限	損害賠償が発生する場合の上限額
変更連絡	依頼者側がシステムを変更する際の事前連絡ルール
契約期間	保守契約の期間と、更新および解約の手続き

この表を埋める作業は、案件ごとに30分程度で終わります。障害が起きてから条件を交渉することを考えれば、はるかに安い時間の使い方です。

なお、契約期間と解約の条件を入れておくことは、受注者を守るうえで重要です。保守契約に終了時期の定めがないと、実質的に無期限の拘束になります。年単位で更新し、更新時に条件を見直せる形にしておく。稼働の実態が当初と変わったときに、料金を見直す機会が必要だからです。

支払い条件は、作業の前に決めるのが原則

トラブル対応で最も揉めるのが、お金の話です。特に、緊急対応をした後の請求は難易度が上がります。「頼んでいない」「そこまでやるとは思わなかった」という反応が出やすい。

発注の内容を書面で確認する

事業者間の取引には、発注内容を書面などで明示することを求めるルールがあります。取引の適正化を目的とした法律の枠組みがあり、発注時の条件明示や、報酬の支払い期日についての定めが置かれています。2026年時点の適用範囲や具体的な期日の要件については、公正取引委員会や中小企業庁が公表している資料を確認してください。制度の内容は改正されることがあるため、最新の情報を一次情報で確認するのが確実です。公正取引委員会のサイトに関連する解説が掲載されています。

実務としては、緊急対応の依頼が来た時点で、対応前に短く返信するのが有効です。「調査から着手します。調査は時間単価での請求となり、目安は3時間程度です。復旧作業が必要な場合は、別途お見積もりします」といった内容を送っておく。この1通があるかどうかで、後の請求の通りやすさが変わります。

緊急時に契約書を作る余裕はありません。だからこそ、返信の型をあらかじめ用意しておくのが実務的です。

フリーランスが取引条件の明示や支払いについて知っておくべき点は、書類のひな型を含めて整理されています。フリーランスを守る「下請法（取適法）」の知識｜発注書・契約書の必須項目チェックリストでは、発注書に記載すべき項目が一覧になっているので、自分の案件に足りない項目を確認する材料になります。

支払われなかった場合の道筋を知っておく

対応を終えたのに支払われない、という事態も起こり得ます。このとき重要なのは、感情的なやり取りに時間を使わず、手順に沿って進めることです。

まず、作業の記録を揃えます。依頼を受けた連絡、作業内容の報告、成果の証跡。これらが揃っていれば、請求の根拠が明確になります。次に、支払期日を明記した請求書を再送し、期日を過ぎた場合の対応を伝えます。それでも動きがない場合は、内容証明郵便の送付や支払督促といった手続きが選択肢になります。

回収にかかる費用と手間については、事前に把握しておいたほうがいいでしょう。未払い報酬を回収する！弁護士の着手金・成功報酬と支払督促の流れ【2026年最新】では、回収手続きの流れと費用の目安が整理されています。金額によっては、回収コストが回収額を上回ることもあります。だからこそ、着手前の取り決めと、着手時の書面確認が効いてきます。

障害が起きたときの動き方

取り決めができている前提で、実際の対応手順を確認します。慌てて手を動かす前に、順番を守ることが結果的に最短になります。

実際にサーバー障害が発生した場合は、どのような対処をすればよいのでしょうか。ここでは、障害発生時の基本的な対処の流れについて解説します。以下の3つのステップに沿って対処をしましょう。出典: biz.techvan.co.jp

第一報を先に出す

原因が分かる前でも、連絡だけは先に出します。「障害を認識しました。現在状況を確認しています。次の報告は30分後に行います」という内容で十分です。

依頼者にとって最も不安なのは、止まっていることではなく、誰も見ていないかもしれないという状態です。第一報が早いだけで、その後のやり取りの温度が変わります。

そして、次の報告時刻を自分から宣言しておくことが重要です。原因が分からない時間が続くと、依頼者は不安になって何度も連絡してきます。その対応で作業が止まるという悪循環が起きる。「30分ごとに状況を報告します」と先に決めておけば、その間は集中して調査に充てられます。報告する内容がなくても「まだ原因を特定できていません。次は1時間後に報告します」と送る。進捗がないことを伝えるのも報告です。

もう1つ、第一報の段階では原因の推測を断定的に書かないでください。「おそらくクラウド側の障害です」と早い段階で書いてしまい、後で自分の設定ミスだと判明する事態は起こり得ます。その瞬間に信頼が崩れます。確定していない情報は「現在確認中です」にとどめるのが安全です。

状況を記録しながら切り分ける

対応中の記録は、後の報告書と請求の根拠になります。何時に何を確認し、何が正常で何が異常だったか。焦っていると記録を飛ばしがちですが、ここを飛ばすと後で説明できません。

切り分けは、影響範囲の特定から始めます。全体が止まっているのか、一部の機能だけか。特定のユーザーだけか。外部からの経路の問題か、サーバー内部の問題か。順番に切っていくと、原因の候補が絞られます。

復旧と、恒久対策を分けて扱う

まず止血をして、原因の恒久対策は別の作業として扱います。この2つを混ぜると、復旧が遅れます。

そして恒久対策は、追加の作業として見積もりを出す。「今回の障害の再発を防ぐには、この構成変更が必要です。作業は別途お見積もりします」と伝える。緊急対応の流れのまま無償で構成変更まで引き受けてしまうと、次回も同じ期待をされます。

作業後の報告書は、丁寧に書く価値があります。何が起きて、どう対応し、今後どうするか。この文書が、次の依頼につながる材料になります。報告文書の型についてはビジネス文書検定で扱われている構成が参考になります。技術的な正確さと、読み手に伝わる構成は別のスキルです。

原因の所在によって、負担する側が変わる

障害対応の費用をめぐる争いは、多くの場合「原因が誰にあるか」の認識がずれていることから始まります。ここを整理しておくと、請求の根拠が説明しやすくなります。

原因は大きく3つに分けられます。1つ目は、構築を担当した側の作業に起因するもの。設定の誤り、手順の抜け、検証不足。これは受注者側が無償で修正すべき領域です。ここを曖昧にすると、逆に信頼を失います。自分のミスは早く認めて直すほうが、結果的に関係が保たれます。

2つ目は、依頼者側の変更や運用に起因するもの。相談なくアプリケーションを更新した、権限を変更した、容量を超えるデータを投入した。この場合の調査と復旧は、追加作業として請求できる性質のものです。ただし、事前に「変更する場合は事前に連絡してください」と伝えていなければ、依頼者は自分に非があると思っていません。取り決めの段階で、変更時の連絡ルールを入れておくことが効いてきます。

3つ目は、どちらにも帰属しない外部要因。クラウド事業者の障害、回線の断絶、天災、外部からの攻撃。これらへの対応は、免責の対象にしつつ、対応作業そのものは有償で行うという整理が一般的です。「責任は負わないが、対応はする。対応には費用が発生する」という三段構えを、契約に書いておきます。

原因の切り分けができないと、この分類自体ができません。だから技術的な切り分け能力は、実は請求の根拠を作る能力でもあります。特にネットワーク層で発生する障害は、原因の所在が見えにくい。CCNA（シスコ技術者認定）の出題範囲には、経路の確認、名前解決、疎通の切り分けといった基礎が体系的に含まれているので、切り分けの手順を整理する材料として使えます。

予防のための提案を、費用を伴う作業として出す

トラブル対応の負担を減らす最も確実な方法は、そもそも障害が起きにくい構成にしておくことです。ただし、この提案の出し方には注意が要ります。

バックアップの自動取得、復旧手順の整備、監視の設定、冗長化。これらはすべて手間と費用がかかります。無償のサービスとして提供してしまうと、その後の作業も無償が前提になる。だから予防策は、はっきり見積もりを出す作業として提案してください。

提案の仕方としては、リスクと費用を並べて示すのが有効です。「現在の構成では、サーバーが故障した場合の復旧に1日以上かかる可能性があります。バックアップの自動化と復旧手順の整備を行えば、復旧時間を数時間まで短縮できます。作業費用は別途お見積もりします」という形です。数字の部分は案件の実態に応じて調整しますが、時間の見通しを示すことが判断材料になります。

ここで押しつけがましくならないコツは、決定権を相手に渡すことです。「やるべきです」ではなく「こういう選択肢があります。実施しない場合のリスクはこうです」と示す。そのうえで、実施しなかった場合に障害が起きても、事前に説明した範囲については免責であることを記録に残しておく。この記録が、後の責任論を防ぎます。

正直なところ、予防の提案は通らないことも多い。予算がない、今は必要ないと判断される。それでも提案した記録を残しておく価値はあります。実際に障害が起きたとき、「以前ご提案した内容です」と言えるかどうかで、その後の会話がまったく変わります。

復旧作業の記録が、そのまま次の提案になる

対応が終わったら、記録を整理して依頼者へ渡します。発生時刻、検知の経緯、確認した項目、原因、実施した対応、再発を防ぐために必要なこと。この6点が揃っていれば、報告書として十分です。

この文書には2つの効果があります。1つは、作業内容を可視化して請求の根拠にすること。もう1つは、次の提案につなげることです。報告書の最後に「再発を防ぐには構成の見直しが必要です」と書いておけば、それが次の見積もりの入口になります。障害対応を単発の出費で終わらせるか、継続的な改善の起点にするかは、この文書の書き方で決まります。

そして自分自身のためにも、記録は残しておく価値があります。同じ種類の障害は、別の案件でも起きます。過去の切り分け手順が手元にあれば、次回の対応時間が短くなる。時間単価で受けている場合は収入が減るように見えますが、実際には同じ時間でより多くの案件を回せるようになります。

取り決めがないまま受けてしまった場合の立て直し方

すでに曖昧なまま関係が続いている場合もあるでしょう。そこからでも立て直せます。

いきなり契約書を持ち出すと角が立つので、まず現状の整理から入ります。「これまでの対応内容を整理したところ、当初の想定を超える範囲が含まれていました。今後の進め方を明確にしたいので、対応範囲と条件を一度書面にさせてください」という切り出し方であれば、相手も受け入れやすい。

このとき、これまでの無償対応を遡って請求しようとしないことです。過去の分は諦めて、今後の条件を整えるほうが現実的です。過去分の請求を持ち出すと交渉全体が止まります。

そして、条件を提示する際は、相手にとってのメリットも添えます。「対応時間を明確にすることで、緊急時の連絡先と手順がはっきりします」「範囲を決めておくと、追加費用が予測可能になります」。取り決めは受注者を守るためだけのものではなく、依頼者にとっても予測可能性が上がる話です。この説明ができると、交渉が前に進みます。

市場を長く見てきた立場からの観察

在宅ワークとフリーランスの市場を20年運営してきた立場から見ると、トラブル対応で信頼を失う人と、逆に信頼を得る人の差は、技術力ではないところにあります。

差が出るのは、伝える速度と、範囲を言葉にできるかどうかです。復旧が遅れても、状況が逐一伝わっていれば関係は壊れません。逆に、素早く直しても、その間ずっと連絡がなければ「何をしていたか分からない」という印象だけが残ります。

もう1つ、長く続いている人ほど「できないこと」を先に言っています。夜間は対応できない、この範囲は担当できない、この作業は追加費用がかかる。断りの言葉を先に出すことは、仕事を失う行為に見えて、実は信頼を作る行為です。できないことを黙って引き受けて後で破綻するほうが、はるかに損害が大きい。

そして報酬の構造の話をすると、トラブル対応は中間マージンの影響が特に大きい領域です。緊急対応は単価が高めに設定される一方、仲介手数料が乗るとその分だけ受け手の取り分が減ります。同じ緊急対応でも、中間マージンの乗らない直接取引であれば、依頼者は同じ予算でより手厚い体制を頼めて、受け手の手取りは厚くなる。手数料0%という条件が意味を持つのは、こうした継続的で責任の重い仕事においてです。

職種データから見る、責任範囲と報酬の関係

インフラの仕事は、担当する工程によって責任の重さが大きく違います。サーバー・インフラ構築・保守のお仕事で工程を確認すると、構築と保守が別の性質の仕事として整理されていることが分かります。この区別を見積もりに反映させるだけで、後の交渉が楽になります。

セキュリティに関わる領域はさらに責任が重くなります。AI・マーケティング・セキュリティのお仕事に含まれる作業は、判断を誤ったときの影響が大きく、免責の範囲をより明確にしておく必要があります。逆に、作曲・編曲・効果音・ジングルのお仕事のような制作系の仕事では、責任の中心が納品物の品質にあり、稼働の継続性を問われることは少ない。同じ在宅の仕事でも、契約で気をつけるべき点はまったく異なります。

報酬の水準を職種横断で見るなら、ソフトウェア作成者の年収・単価相場と著述家，記者，編集者の年収・単価相場を並べて確認すると、責任の重さと報酬の関係が見えてきます。金額の高さだけで判断せず、その金額に含まれている責任の範囲まで含めて比較してください。

会計や税務の専門職が副業として案件を受ける場合の契約設計も、範囲と責任の切り分けという点で共通する部分があります。会計士の副業ガイド｜監査法人勤務でもできる高収入の稼ぎ方【2026年版】では、本業との関係も含めた条件整理の考え方が扱われています。専門性の高い仕事ほど、着手前の取り決めが効いてくるという構造は同じです。