SES契約書レビューのチェックポイント｜委託者・受託者別の実務論点
こんにちは！Legal Agent 代表弁護士の朝戸です。
企業法務の現場では、システム開発、運用保守、情シス支援、データ移行、クラウド導入支援などの場面で、SES契約書を確認することがよくあります。
SES契約は、名前だけを見るとIT業界でよく使われる標準的な契約のように見えます。しかし、実務の感覚としては、かなり慎重に確認すべき契約類型だと考えています。なぜなら、契約書の文言だけではなく、実際の現場で誰がエンジニアに指示を出すのか、成果物を約束するのか、稼働時間を基準に請求するのか、個人情報や顧客データに触れるのかによって、リスクの見え方が大きく変わるためです
特に、SES契約では、委託者も受託者も「いつもの準委任契約だから」と考えてしまいがちです。ただ、現場の運用が契約書とずれていると、偽装請負、再委託、情報管理、知的財産、責任範囲、稼働管理、契約終了時の引継ぎなどの問題が一気に表面化する可能性があります。
今回は、SES契約とは何か、なぜレビューが重要なのか、どの条項を見るべきか、委託者側と受託者側でどのようにリスクが違うのか、そして生成AIでレビューするときにどこに注意すべきかを、企業法務の実務に近い形で整理します
この記事で分かること
この記事では、SES契約書レビューのチェックポイントについて、基本的な意味、レビューで問題になりやすい条項、立場ごとの注意点、AIで確認するときに人が見落としてはいけない点を整理します。最初に全体像をつかみ、その後にチェックリストで実務上の確認順序を追える構成にしています
最初に確認するポイント
- どの取引、手続、社内運用でこの論点が問題になるのか
- 自社が相手方に何を求め、相手方から何を求められているのか
- 契約書、発注書、規約、社内承認、実際の運用が同じ前提になっているか
- 条項だけでなく、証拠として残る資料や連絡経路まで整理されているか
- AIの指摘をそのまま採用せず、事業上の優先順位とリスク許容度に照らして判断できるか
SES契約とは
SES契約は、一般に、エンジニアが委託者のシステム開発、運用、保守、調査、改善支援などに関与し、その稼働時間や支援業務に応じて対価が支払われる契約として使われています。法的には、多くの場合、仕事の完成を目的とする請負契約ではなく、一定の業務遂行を目的とする準委任契約として整理されます。
もっとも、「SES」という名称自体が民法上の契約類型として明確に定義されているわけではありません。そのため、契約書レビューでは、契約タイトルではなく、業務内容、成果物の有無、指揮命令関係、検収、報酬計算、契約終了時の扱いを具体的に確認する必要があります。
たとえば、委託者がエンジニアに対して日々の作業指示を直接出し、勤務時間や休暇を細かく管理し、受託者側の管理者が実質的に機能していない場合、契約書上は業務委託や準委任と書かれていても、実態として労働者派遣に近いと評価される可能性があります。これは、SES契約で最も注意すべき論点の一つです。
また、SES契約では、成果物を明確に特定しないまま、実際にはプログラム、設計書、調査レポート、設定ファイル、運用手順書などが作成されることがあります。この場合、知的財産権の帰属、利用許諾、第三者ソフトウェアの扱い、既存コードの流用、OSSの利用条件まで確認しないと、後で「誰が何を使えるのか」が曖昧になる可能性があります。
したがって、SES契約は単なる人月契約や稼働契約として見るのではなく、人の関与、業務管理、成果物、データ、責任範囲が重なったIT取引契約として確認することが重要です
SES契約書レビューが重要になる理由
SES契約書レビューが重要なのは、契約書のリスクが現場運用と直結しやすいからです。
通常の業務委託契約であれば、契約書に書かれた業務範囲、納期、成果物、報酬、責任範囲を中心に確認すれば足りる場面もあります。しかし、SES契約では、現場での作業場所、コミュニケーション方法、チケット管理、会議参加、セキュリティ権限、勤怠報告、障害対応の有無まで見ないと、実務上のリスクが分かりにくいです。
委託者側から見ると、必要な人材を柔軟に確保できる点にメリットがあります。一方で、受託者のエンジニアを自社の社員のように使ってしまうと、労務管理や派遣規制に関する問題が生じる可能性があります。また、外部エンジニアが本番環境、顧客情報、個人情報、営業秘密にアクセスする場合、情報漏えい時の責任や証跡管理も重要になります。
受託者側から見ると、稼働時間に応じて安定した収益を得やすい一方で、委託者から過度な成果責任を負わされたり、曖昧な業務範囲のまま長時間対応を求められたりするリスクがあります。特に、「準委任」と書かれているのに検収不合格を理由に支払いを拒否できる条項がある場合、契約構造が混在している可能性があります。
さらに、2026年1月1日以降は、委託取引に関する規制として取適法、いわゆる旧下請法から改正された中小受託取引適正化法の確認も重要になっています。SES契約が情報成果物作成委託や役務提供委託に近い取引となる場合、発注書面、支払期日、減額、やり直し、価格交渉などの観点を契約書と運用の両方で見ておく必要があります。
SES契約では、契約締結時には問題が見えにくくても、障害発生、担当者交代、契約終了、追加作業、支払遅延、情報漏えいが起きた瞬間に、条項の曖昧さがそのまま紛争の入口になります。レビューの段階で、現場がそのまま使える契約になっているかを確認することが大切です
SES契約書レビューのチェックリスト
SES契約書を見るときは、まず契約の法的性質を確認します。準委任なのか、請負なのか、派遣に近い運用が予定されていないかを整理する必要があります。契約書に「準委任」と書かれていても、成果物の完成義務、検収、瑕疵対応、納品物の不合格時の無償修正が強く定められている場合、請負的な要素が混ざっている可能性があります。
次に、業務範囲を確認します。単に「システム開発支援」「運用保守支援」とだけ書かれていると、どこまでが基本料金の範囲で、どこからが追加費用になるのかが分かりません。実務では、担当工程、対象システム、作業場所、稼働日、稼働時間、会議参加、障害対応、夜間休日対応、ドキュメント作成の有無まで、できるだけ具体化しておく必要があります。
指揮命令関係も重要です。委託者が受託者のエンジニアに直接業務命令を出せるように読める条項は、慎重に見るべきです。委託者が業務上の要望や仕様を伝えること自体は必要ですが、日々の作業割当、勤務管理、休暇承認、人事評価に近い事項まで委託者が行う形になると、契約書と実態の整合性が問題になります。
報酬条項では、月額固定なのか、時間単価なのか、精算幅があるのか、控除や超過精算の計算方法が明確かを確認します。たとえば、140時間から180時間の精算幅を置く場合、控除単価、超過単価、端数処理、休暇、遅刻、待機時間、委託者都合で作業できなかった時間の扱いまで確認しておくと、請求時の揉め事を減らしやすくなります。
成果物と知的財産の条項も見落とせません。SES契約では成果物を予定しない建付けでも、実際にはコード、設定、スクリプト、設計メモ、調査結果、運用手順書が作成されることがあります。これらの権利が委託者に帰属するのか、受託者が再利用できるのか、汎用的なノウハウや既存ライブラリは除外されるのかを整理する必要があります。
情報管理では、秘密保持だけでなく、アクセス権限、個人情報の取扱い、ログ管理、アカウント返却、端末利用、リモートワーク時の環境、再委託先の管理を確認します。特に、本番環境や顧客データにアクセスする場合、事故発生時の通知期限、調査協力、費用負担、再発防止策まで契約上の流れを作っておくことが重要です。
責任制限では、損害賠償の上限、間接損害や逸失利益の扱い、故意・重過失や秘密保持違反の例外、セキュリティ事故時の扱いを確認します。受託者側としては無制限責任を避けたいところですが、委託者側としては情報漏えいや重大な運用事故まで一律に低い上限で処理されると、実損に見合わない可能性があります。
契約終了時の引継ぎも実務上は重要です。アカウント削除、資料返却、作業中データの扱い、後任者への引継ぎ、ナレッジ移管、途中成果物の利用可否、終了後の問い合わせ対応を定めておかないと、担当エンジニアの離任と同時に運用が止まる可能性があります
委託者側・受託者側で見るべきリスク
委託者側では、まず、外部エンジニアにどこまで権限を渡すのかを具体的に確認する必要があります。管理者権限、本番環境、顧客データ、決済情報、社内チャット、チケット管理ツールにアクセスできる場合、契約上の秘密保持条項だけでは足りないことがあります。アクセス権限の付与、削除、ログ取得、事故時の連絡体制を契約と運用でそろえるべきです。
また、委託者側では、準委任契約であることを前提にしながら、実際には成果物の完成や品質保証を期待してしまうことがあります。成果物の完成を重視するなら請負契約や個別発注書で成果物を定義するべきですし、支援業務を重視するなら、善管注意義務、報告義務、稼働管理、技術水準を中心に設計するべきです。この整理が曖昧なまま進むと、障害発生時に責任追及が難しくなります。
受託者側では、業務範囲の曖昧さが最も大きなリスクになりやすいです。「関連する一切の業務」「委託者が指示する業務」と広く書かれていると、契約時に想定していなかった夜間対応、緊急障害対応、追加開発、ドキュメント整備まで無償で求められる可能性があります。受託者としては、基本業務と追加業務の境界を明確にすることが重要です。
受託者側では、エンジニア個人の交代や欠勤に関する条項も確認すべきです。特定のエンジニアを前提にした契約なのか、同等スキルの代替要員を配置できるのか、委託者の承諾が必要なのか、交代時の引継ぎ費用を誰が負担するのかによって、運用の柔軟性が変わります。
双方に共通するのは、現場の認識と契約書の文言を合わせることです。現場では委託者が毎日作業指示を出しているのに、契約書では受託者が自律的に業務を遂行すると書かれている場合、契約書だけ整っていても十分ではありません。レビューでは、契約書の文言を直すだけでなく、現場の運用をどう変えるかも一緒に確認する必要があります
AIでSES契約書をレビューする際の注意点
生成AIは、SES契約書の論点抽出と一次チェックにはかなり使いやすいと感じています。業務範囲、報酬、秘密保持、再委託、知的財産、責任制限、契約終了時の引継ぎなど、典型的な条項の抜け漏れを短時間で確認できるためです。
一方で、AIだけでは、現場運用とのズレを十分に評価しにくいです。たとえば、契約書上は「受託者が自己の裁量で業務を遂行する」と書かれていても、実際には委託者のプロジェクトマネージャーが受託者のエンジニアに毎日直接指示していることがあります。このような実態は、契約書だけをAIに読ませても分かりません。
AIレビューを使う場合は、契約書だけでなく、案件情報も一緒に整理する必要があります。自社の立場、作業場所、指示系統、対象システム、アクセスする情報、成果物の有無、精算方法、夜間休日対応の有無、再委託の有無、契約期間、終了時に必要な引継ぎを入力すると、レビューの精度は上がります。
また、AIは「一般的には修正した方がよい条項」を多く挙げる傾向があります。しかし、SES契約では、取引金額、相手方との関係、エンジニアの希少性、プロジェクトの緊急度によって、どこまで交渉するかが変わります。重要なのは、AIの指摘をそのまま相手方に送ることではなく、会社として本当に直すべき条項と、社内で注意して受け入れる条項を分けることです。
LegalAgentでは、SES契約のレビューでも、生成AIによる論点抽出と、企業法務に精通した弁護士による実務判断を組み合わせることを重視しています。契約書だけではなく、現場の運用、事業部の進め方、情報管理体制、交渉余地を踏まえて、委託者側にも受託者側にも使えるレビューをお届けすることが大切だと考えています
LegalAgentの関連サービス
この記事のテーマに関連するLegalAgentのサービスは、以下のページで詳しくご確認いただけます。