保守・SESは準委任：改修部分だけを請負で切り出す

結論：保守・運用・SESは準委任で書き、改修の部分だけを請負で切り出す

民法は、仕事の完成を約束し、その結果に対して報酬を払う契約を請負とし（民法632条）、法律行為でない事務を相手に任せる契約を準委任として委任の規定を準用しています（民法643条・656条）。準委任の受託者は、委任の本旨に従い、善良な管理者の注意（善管注意義務。その職業や立場にある人に通常期待される程度の注意のことです）をもって事務を処理する義務を負います（民法644条）。結果が出なかったこと自体ではなく、なすべきことをしなかったことに責任を負う契約です。

保守・運用・SESの仕事は、障害が起きないことや、一定の時間内に必ず復旧することを約束できる性質のものではありません。事務所が扱ってきた保守・運用・SESの契約書は、いずれも準委任で書いています。そのうえで、保守の中に含まれる「ソフトウェアの改修」のように、完成を観念できる部分だけを請負として切り出す、という設計をとることがあります。

準委任の報酬は、事務処理の労務に対して払う形（履行の割合に応じて払う型）が典型で、委任者の責めに帰することができない事由によって履行できなくなったときや、履行の途中で終了したときは、既にした履行の割合に応じて報酬を請求できます（民法648条3項）。一方、事務処理の成果に対して報酬を払うと約束した場合は、その成果が引渡しを要するときは引渡しと同時に払うことになり（民法648条の2第1項）、請負の割合的な報酬の規定（民法634条）が準用されます（同条2項）。SESのように稼働時間で報酬を決める契約は前者、成果物の受領と引換えに払う契約は後者に近づきます。

このページは、保守・SESの契約でこの区別をどう書くかに絞ります。開発の工程ごとに請負と準委任を分ける考え方や、検収の一般的なルールは、アプリ・システム開発の委託契約書（姉妹サイト）をご覧ください。

準委任と書くときに、何を「保証しない」と明記するか

契約書の題名に「準委任」と書いても、それだけで責任の範囲が決まるわけではありません。個人のWebデザイナーが雛形をもとに作った保守・運用契約の原案をレビューしたときは、準委任に近い内容なのに、成果を保証するのか善管注意義務で足りるのかが条文上はっきりしない点を、最初の問題として挙げました。事務所の書き直し版では、業務が準委任に類する性質のものであって成果物の納入を目的とする請負とは異なること、善管注意義務で業務を行うこと、集客の増加や売上の増加は保証しないこと、最終的な判断と責任は依頼者にあることを、前文と本文の両方に書いています。

保守ベンダーの保守契約では、受託者は、特定の成果の完成、障害の完全な防止、システムの無停止、一定時間内の復旧、第三者のソフトウェアの継続的な提供を保証しない、と列挙していました。事務所で扱った定額ITサポートの契約書（全20条）では、さらに、提案書・営業資料・口頭の説明・メールでのやり取りは「概要の説明」にすぎず、成果の保証や完全な対応の義務、請負の責任を構成しない、という一文を置いていました。営業の段階で「何でも対応します」と説明したことが、契約上の約束として持ち出されるのを防ぐ書き方です。

準委任の中に「納品・確認・修補」を置くとき

保守やSESでも、作業報告書、調査報告書、手順書、設定ファイルなど、形のあるものを渡す場面はあります。そのため準委任の契約書に「成果物」「納品」「確認」「修補」という言葉が出てくること自体は避けられません。問題は、それが多くなるほど、請負と解釈される余地が広がることです。仲介会社から示された準委任の基本契約の原案をレビューしたときは、「形式的には準委任と明記されているが、成果物の納入を前提とする請負に近い性質を帯びる条項も散見される」と指摘し、契約の類型の解釈次第で受託者の責任が広がり得ると書きました。サービスを定義する条についても、「支援」の範囲が広すぎて実務上の責任の範囲が分からないので、定義にアウトプットや成果物の要件を書き足すよう指摘しています。修正版では、具体的な業務の内容・範囲・成果物の要否・遂行期間を個別契約で定めることにして、準委任の枠のまま成果物の有無を個別契約で書き分けています。

準委任のまま確認や修補の手続を置きたいときに使えるのが、類型を誤認されないための一文です。業務の自動化を外部のエンジニア会社に準委任で頼む委託側の契約では、成果物の作成・納品・確認・修補に関する定めは、業務の遂行状況と品質を確認するための契約上の手続にすぎず、契約を請負に変えたり成果物の完成義務を課したりするものではない、と書きました。

反対に、準委任と書きながら、成果が契約に適合しないときの是正請求、解除、損害賠償を一つの条にまとめて置く書き方を見かけることがあります。準委任の債務不履行として処理するのか、請負の契約不適合として処理するのかが条文上混ざると、受託者がどこまで責任を負うのかが読めなくなります。どちらのルールで処理するのかを、条文の上で分けておくことが大切です。

事務所が改稿した開発等基本契約では、準委任の業務は善管注意義務で行い、特定の成果や成果物の完成は保証しないこと、委託者から求められれば進捗と実施状況を報告すること、準委任で成果物を作っても検収と契約不適合の条は原則として適用しないことを、独立した条で定めていました。情報セキュリティ関連の業務を受ける個人エンジニアの契約のレビューでも、セキュリティの業務でも資料・レポート・システムの設定・改善の提案が生まれるので、準委任か請負かを明記し、成果物が出る場合は、その仕様・納品・検収・修正、権利の帰属、契約不適合の責任の範囲と期間を決めておくよう提案しました。準委任の業務から何が生まれるのかを最初に洗い出しておくと、「成果物」の扱いを条文で書き分けやすくなります。

保守の中の「改修」だけを請負にする

保守の契約に、ソフトウェアの改修のような請負になじむ作業が混ざることがあります。外資系のIT・コンサルティング会社が大手の顧客と基本契約を交渉した案件では、顧客側の条件として「システム保守の場合は、ソフトウェアの改修を含む部分だけを請負とし、その部分の契約不適合責任の期間は、注文者が不適合を知った時から最低でも1年間」が示されました。事務所は、業務の類型を定める条項と、請負の部分だけに契約不適合責任を適用する条項（不適合を知ってから1年、ただし検収後2年で打ち切り）で対応できると整理しています。保守全体を請負にするのではなく、改修だけを請負として扱えば、日々の監視や問い合わせ対応まで「完成」を求められることはありません。

開発の契約の側から見ると、典型的なリスクは「無期限の無償保守」です。事務所の提案書のチェックリストでは、開発の契約で不具合対応と保守を区別し、無償で不具合に対応する期間を限定したうえで、その後は保守契約（準委任）に移す、という修正の方向を示しています。AIを使ったシステムの開発については、運用を始めた後にデータの変化で精度が落ちること（ドリフト）は保証せず、再学習やチューニングは有償の保守契約の対象にする、外部の基盤モデルやAPIの仕様変更・停止は受託者の責任の範囲外とする、という整理も示しました。完成した時点の品質を約束する開発の契約と、その後の変化に対応する保守の契約を分けておけば、どちらの費用で対応するのかがはっきりします。

委託側の基本契約でも、同じ切り分けをとりました。Web制作会社がフリーランスに制作・開発・保守運用を発注する基本契約では、業務を成果物型と役務提供型に分け、役務提供型は、受託者の報告に対して委託者が5営業日以内に具体的な異議を述べなければ適切に実施されたものとし、検査・検収の条を適用しないこと、契約不適合責任は役務提供型には適用せず債務不履行責任で処理することを定めています。

開発等基本契約に添えて相手方に渡す説明資料では、請負と準委任の違いを次の表で説明しました。保守・SESの契約を説明するときにも、そのまま使える観点です。

SESのように人の稼働を提供する準委任では、類型の問題とは別に、発注者がエンジニアに直接指示を出す運用になっていないかという問題もあります。こちらは指揮命令と偽装請負のページで、契約書の文言の比較とあわせて扱います。

類型を書き忘れたときの扱いを決めておく

基本契約＋個別契約の型では、注文書に類型の記入漏れがあったときにどう扱うかを決めておく必要があります。事務所が改稿した開発等基本契約では、個別契約に類型の記載がなければ準委任とする、と定めていました（依頼者の下書きにあった考え方です）。一方、委託側の基本契約では、成果物の納入を伴う業務は成果物型（請負）、その他は役務提供型（準委任）とする、という切り分けをとっています。

準委任を初期設定にする書き方は受託者に有利ですが、レビューでは二つの注意を書きました。一つは、委託者から「知らないうちに準委任にされた」と主張される火種になること、もう一つは、この初期設定は受託者にも働き、本来は請負で受けて完成時に報酬をもらうはずの案件が、記入漏れで準委任扱いになり、報酬と責任の前提がずれるおそれがあることです。そこで条項は残しつつ、注文書に類型の必須記入欄を設けて、毎回必ず明示する運用にしました。

運用とツールの開発を1本の契約に同居させるとき

建設会社が個人事業主に、現場の帳票の遠隔運用代行、秘書業務、作業指示アプリのモニター開発、アプリの保守を一括で委託した案件では、運用代行と秘書業務を準委任とし、アプリの開発は請負とせず、「受託者が試作するシステムを委託者がモニターとして利用し、協議のうえ機能を確認しながら改善を行う性質」のものとして、特定の仕様や性能に完全に適合することは保証しない、と定めました。代わりに、モニター期間中の変更・改良は無償とし、ただし通常の変更・改良の範囲を著しく超えるものは協議のうえ有償とする、という調整を置いています。モニター期間の終わりは、委託者が正式版としての利用開始を書面又は電磁的方法で確認した日です。

法人向けのSaaSの提供と導入支援を1本にした契約では、当初の案の「導入支援業務」が成果物4点・検収・固定額という請負的な作りでしたが、改訂で「支援業務」と改称して準委任型と定義し、成果物は要件定義書などに絞りました。導入の支援は、顧客側の準備や判断に左右される部分が大きく、完成を約束しにくいからです。

このように、1本の契約に性質の違う業務が同居するときは、業務ごとに類型と責任の範囲を条文で書き分け、どの業務の不具合なのかで適用されるルールが変わることを明確にします。

「直らなかったから返金して」と言われたら

準委任の保守で最も多い誤解は、「障害が直らなかったのだから、その月の保守料は払わない」「改善しなかったのだから返金してほしい」というものです。準委任の受託者が負うのは善管注意義務であり、障害が解消しなかったこと自体は債務不履行になりません。ただし、約束した作業をしなかった、必要な注意を払わなかった、という場合は債務不履行です。

AI活用支援のコンサルティング契約のレビューでは、成果を保証しないこと、受領済みの報酬は返還しないことを定めつつ、債務不履行の責任までは免除しない旨を置くことで、「成果が出ないこと」と「約束した業務をしなかったこと」を区別する構成を確認しました。成果を保証しない条項だけを強く書くと、何もしなくても報酬を受け取れる契約のように読まれ、かえって条項全体の有効性が疑われます。区別を書いておくほうが、受託者にとっても主張しやすくなります。

また、個人の副業エンジニアの時給制の契約のレビューでは、準委任と明記されていることを受託者に有利な点として挙げました。仕事の完成義務がなく、途中で終わっても既にした履行の割合に応じて報酬を請求でき（民法648条3項）、請負の契約不適合責任の規定も働かないからです。

起きがちなこと：類型があいまいなまま運用が始まる

類型は題名で決まるのではなく、約束の中身で判断されます。保守・SESの契約書では、準委任であることを書くだけでなく、保証しないこと、報告物の位置付け、改修を別にすることを、それぞれ条文に落としておきます。数字で範囲を決める方法は保守範囲の決め方、精算の方法はSESの精算幅、途中で終わるときの扱いは期間・更新・解約と引継ぎで扱います。

よくあるご質問

あわせて読みたいページ

本ページは一般的な情報提供です。個別の契約への当てはめは、取引の実態によって結論が変わることがあります。事務所の改訂例・ご相談の事例として紹介している内容は、アトラス行政書士法人が作成・レビューしてきたシステム保守業務委託契約書、Webサイトの保守・運用業務委託契約書、定額ITサポートの契約書、準委任型の業務委託基本契約書と個別契約、エンジニアへの業務委託契約書、秘密保持契約書、ヒヤリングシートなどを、個別の事業者が特定できない形に整理したものです。条文は e-Gov法令検索で確認しています（最終確認日：2026年10月16日）。参考: e-Gov法令検索 / フリーランス法特設サイト（公正取引委員会）