SES契約書レビューのチェックポイント｜委託者・受託者別の実務論点

こんにちは。LegalAgent 代表弁護士の朝戸です。

企業法務の現場では、システム開発や運用保守、情シス支援などの場面で、SES契約書を確認することがよくあります。名前だけを見ると業界で使い慣れた標準的な契約に見えますが、実務の感覚としては、かなり慎重に確認すべき契約類型だと考えています。契約書の文言に加えて、現場で誰がエンジニアに指示を出すのか、成果物を約束するのか、稼働時間を基準に請求するのかによって、リスクの見え方が大きく変わるためです。

委託者も受託者も「いつもの準委任契約だから」と考えてしまいがちですが、現場の運用が契約書とずれていると、偽装請負や情報管理、知的財産といった問題が一気に表面化することがあります。

指揮命令関係とSES契約の法的性質

SES契約は、一般に、エンジニアが委託者のシステム開発や運用、保守、調査、改善支援などに関与し、その稼働時間や支援業務に応じて対価が支払われる契約として使われています。「SES」という名称自体が民法上の契約類型として定義されているわけではないため、契約書レビューでは契約タイトルではなく、業務内容や指揮命令関係、報酬計算などを具体的に見ます。法的には、多くの場合、仕事の完成を目的とする請負契約ではなく、一定の業務遂行を目的とする準委任契約として整理されます。

この契約類型で最も注意すべき論点は、指揮命令関係です。委託者がエンジニアに対して日々の作業指示を直接出し、勤務時間や休暇を細かく管理し、受託者側の管理者が実質的に機能していない場合、契約書上は業務委託や準委任と書かれていても、実態として労働者派遣に近いと評価されるおそれがあります。委託者が業務上の要望や仕様を伝えること自体は差し支えありませんが、日々の作業割当や勤務管理、休暇承認といった人事評価に近い事項まで委託者が行う形になると、契約書と実態の整合性が問われます。

2026年1月1日に施行された取適法（旧下請法から改正された中小受託取引適正化法）への目配りも欠かせません。SES契約が情報成果物作成委託や役務提供委託に近い取引となる場合、発注書面や支払期日、減額といった観点を、契約書と運用の両方で見ておきます。

業務範囲と報酬の精算幅を具体化する

単に「システム開発支援」「運用保守支援」とだけ書かれていると、どこまでが基本料金の範囲で、どこからが追加費用になるのかが分かりません。担当工程、対象システム、稼働時間、夜間休日対応の有無まで、できるだけ具体化しておくことで、請求時の認識違いを防ぎやすくなります。

報酬条項では、月額固定なのか時間単価なのか、精算幅があるのかを確認します。たとえば140時間から180時間の精算幅を置く場合、控除単価や超過単価、待機時間の扱いまで詰めておくと、請求時の揉め事を減らせます。エンジニアの交代や欠勤についても、特定のエンジニアを前提にした契約なのか、同等スキルの代替要員を配置できるのか、交代時の引継ぎ費用を誰が負担するのかによって、運用の柔軟性が変わってきます。

成果物・知的財産と情報管理の線引き

SES契約では成果物を明確に特定しないまま、実際にはプログラムや設計書、調査レポート、運用手順書などが作成されることがあります。この場合、知的財産権の帰属や利用許諾、OSSの利用条件まで確認しておかないと、後で「誰が何を使えるのか」が曖昧になります。委託者に帰属させる範囲と、受託者の汎用的なノウハウを除外する範囲は、分けて定めておくべき事項です。

情報管理では、秘密保持だけでなく、アクセス権限や個人情報の取扱い、再委託先の管理を見ます。本番環境や顧客データにアクセスする場合、事故発生時の通知期限や調査協力、費用負担、再発防止策まで契約上の流れを作っておくことが重要です。

責任制限と契約終了時の引継ぎ

責任制限では、損害賠償の上限、間接損害や逸失利益の扱い、故意・重過失や秘密保持違反の例外を確認します。受託者側としては無制限責任を避けたいところですが、委託者側としては情報漏えいや重大な運用事故まで一律に低い上限で処理されると、実損に見合わない場合があります。

契約終了時の引継ぎも実務上は見落とせません。アカウント削除や資料返却、途中成果物の利用可否を定めておかないと、担当エンジニアの離任と同時に運用が止まってしまいます。

レビューで確認しておきたい要点

• 業務範囲と稼働時間、報酬の精算方法（精算幅・控除単価・超過単価など）
• 成果物の知的財産権の帰属と、受託者の既存ノウハウの除外
• 秘密保持やアクセス権限などの情報管理と、契約終了時の引継ぎ

委託者側・受託者側で見るべきリスク

委託者側では、外部エンジニアにどこまで権限を渡すのかを具体的に見ます。管理者権限や本番環境、顧客データにアクセスできる場合、契約上の秘密保持条項だけでは足りないことがあり、アクセス権限の付与と削除、ログ取得、事故時の連絡体制を契約と運用でそろえておくべきです。また、準委任契約であることを前提にしながら、実際には成果物の完成や品質保証を期待してしまう場面もあります。成果物の完成を重視するなら請負契約や個別発注書で成果物を定義し、支援業務を重視するなら善管注意義務や報告義務を中心に設計するという整理がないまま進むと、障害発生時に責任追及が難しくなります。

受託者側では、業務範囲の曖昧さが最も大きなリスクになりやすいです。「関連する一切の業務」「委託者が指示する業務」と広く書かれていると、契約時に想定していなかった夜間対応や緊急障害対応まで無償で求められることがあります。基本業務と追加業務の境界を明確にしておくことが、受託者側の防御線になります。

双方に共通するのは、現場の認識と契約書の文言を合わせることです。現場では委託者が毎日作業指示を出しているのに、契約書では受託者が自律的に業務を遂行すると書かれている場合、契約書だけ整っていても十分ではありません。レビューでは、契約書の文言だけでなく、現場の運用をどう変えるかまで一緒に見ることになります。

生成AIは、SES契約書の論点抽出と一次チェックには使いやすいと感じています。業務範囲や報酬、責任制限といった条項の抜け漏れを短時間で確認できるためです。ただし、契約書上は「受託者が自己の裁量で業務を遂行する」と書かれていても、実際には委託者のプロジェクトマネージャーが受託者のエンジニアに毎日直接指示していることがあります。こうした現場運用とのズレは、契約書だけをAIに読ませても分かりません。案件情報として自社の立場や指示系統、精算方法、契約期間まで併せて読ませることで、AIの指摘は実務に近づきます。