準委任契約と請負契約の違いとは？システム開発の発注者向けガイド【2026年】

準委任契約は「業務の遂行」に対して報酬が発生し、請負契約は「仕事の完成」に対して報酬が発生します。この一点が両者の最も重要な違いであり、システム開発における見積もりの立て方、検収の位置づけ、トラブル時の責任分担は、すべてこの違いから派生します。

本記事は、システム開発を外部に発注する立場の方——事業責任者、経営企画、情報システム部門など、法律の専門家ではない発注者——に向けたガイドです。両契約の定義と違い、2020年の民法改正で変わった点、開発フェーズごとの使い分け、そしてAI駆動開発が普及した現在の契約で確認しておきたい新しい論点まで、契約書レビューの実務に使える形で整理します。

準委任契約とは

準委任契約は、法律行為以外の事務の処理を相手方に委託する契約です。民法656条により、委任（民法643条・法律行為の委託）の規定を法律行為でない事務に準用したもので、システム開発では要件定義の支援、技術調査、PoC（概念実証）、開発チームへの技術者参画、保守運用などで広く使われます。

報酬は業務の遂行そのものに対して発生します（民法648条）。実務では「1人月あたり◯円」のように、稼働した時間・工数に応じて支払う形が一般的です。成果物が完成したかどうかは、原則として報酬発生の条件になりません。

ただし、準委任だからといってベンダーが何の責任も負わないわけではありません。受託者は「善良な管理者の注意をもって業務を処理する義務」、いわゆる善管注意義務を負います。プロフェッショナルとして通常期待される水準の注意を払って業務を遂行する義務であり、明らかに稚拙な設計や、業界標準から逸脱した進め方で損害が生じた場合には、債務不履行として責任を問える余地があります。「完成義務がない」ことと「責任がない」ことは別物です。

なお、2020年施行の民法改正により、準委任には「履行割合型」と「成果完成型」の2つの類型が明文化されました。この点は後の章で詳しく説明します。

発注者から見た準委任契約の特徴を整理すると、次のようになります。

• 向いている場面：要件が固まっていない段階でも契約でき、仕様変更に柔軟に対応できる。試行錯誤しながら方向性を探るフェーズと相性がよい
• 注意が必要な点：完成が保証されないため、進捗と品質の把握は発注者側の関与に依存する。稼働報告の粒度や定例での進捗確認など、モニタリングの仕組みを契約と運用の両面で用意しておく必要がある
• 費用の性質：工数に応じた変動費になる。総額を管理したい場合は、月あたりの稼働上限を設ける、契約期間を短く区切って更新判断を挟む、といった設計が実務的な対処になる

請負契約とは

請負契約は、当事者の一方（受注者）がある仕事を完成することを約束し、相手方（発注者）がその仕事の結果に対して報酬を支払うことを約束する契約です（民法632条）。システム開発では、要件定義書や仕様書で定めたシステムを完成させ、納品することが受注者の義務になります。

報酬は仕事の完成（結果）に対して発生します。どれだけ工数をかけても、契約で定めた仕様のシステムが完成しなければ、受注者は原則として報酬を請求できません。実務では、納品されたシステムを発注者が検収し、検収合格をもって完成と扱い、報酬を支払う流れが標準です。

また、納品されたシステムが契約の内容に適合しない場合——仕様どおりに動かない、性能要件を満たさないなど——には、受注者は契約不適合責任を負います。発注者は修補（追完）の請求、報酬の減額請求、損害賠償請求、契約の解除といった手段を取ることができます。

請負契約が成立するためには、「何をもって完成とするか」を契約時点で定義できることが前提になります。つまり、要件・仕様がある程度固まっていることが請負契約の実質的な条件です。要件が曖昧なまま請負で契約すると、完成の定義をめぐって発注者・受注者双方が不幸になりやすい、という点は後述の使い分けにつながります。

発注者から見た請負契約の特徴は次のとおりです。

• 向いている場面：要件が確定しており、固定金額・納期・完成物を事前に約束してほしい開発。予算の稟議や社内説明がしやすい
• 注意が必要な点：契約後の仕様変更は原則として変更契約・追加費用の対象になる。「完成」の基準が仕様書の書き方に依存するため、仕様書・検収基準の精度が契約の実効性を左右する
• 費用の性質：固定費として確定する一方、受注者は不確実性の分をリスクバッファとして見積もりに織り込むため、要件が曖昧なほど割高になりやすい

準委任契約と請負契約の比較表

両者の違いを6つの軸で整理します。契約書を読むときは、この6項目がどう書かれているかを軸に確認すると全体像をつかみやすくなります。

表の中で見落とされやすいのが指揮命令権の行です。準委任・請負のいずれでも、ベンダーの技術者への作業指示はベンダー側の責任者を通して行うのが原則で、発注者が個々の技術者に直接指示を出す運用は契約形態と矛盾します。なお、この区分は民法上の契約類型そのものが定めるものではなく、労働者派遣法上の偽装請負を避けるための実務に基づくものです。また途中解約の行は、事業判断で開発を止める可能性がある新規事業ほど重要です。民法の原則は表のとおりですが、実際の契約書では解約予告期間や精算方法が別途定められるのが通常なので、条文を必ず確認してください。

なお、混同されやすいSES（システムエンジニアリングサービス）は独立した契約類型ではなく、多くの場合、準委任契約として運用される技術者提供サービスの通称です。一方、労働者派遣は指揮命令権が発注者（派遣先）に移る点で準委任・請負と根本的に異なります。準委任や請負なのに発注者がベンダーの技術者へ直接指揮命令を行うと、いわゆる偽装請負の問題が生じます（詳しくはFAQで触れます）。

2020年民法改正で変わった点

2020年4月に施行された改正民法は、システム開発の契約実務に直結する変更を含んでいます。現在新たに締結する契約はすべて改正後の民法が前提になりますが、改正前の知識のままの解説記事や契約書雛形も残っているため、発注者として押さえておきたい2点を整理します。

①請負の「瑕疵担保責任」が「契約不適合責任」に

改正前の民法では、納品物に欠陥があった場合の受注者の責任は「瑕疵担保責任」と呼ばれていました。改正後は「契約不適合責任」に再構成され、名称だけでなく発注者が取れる手段も整理されています。

• 追完請求：不具合の修補など、契約に適合した状態にすることを求められる
• 報酬減額請求：追完がなされない場合などに、不適合の程度に応じた減額を求められる（改正で明文化）
• 損害賠償請求・契約解除：債務不履行の一般ルールに沿って行使できる

また、改正前は「隠れた瑕疵」——発注者が知らなかった欠陥——であることが要件とされていましたが、改正後はこの要件がなくなり、納品物が契約の内容に適合しているかどうかというシンプルな基準になりました。発注者にとっては、「契約の内容」すなわち仕様書や要件定義書に何をどこまで書き込むかが、これまで以上に責任範囲を左右することになります。

実務上の注意として、いまだに「瑕疵担保責任」という旧用語のままの契約書雛形が使われていることがあります。用語が古いこと自体で契約が無効になるわけではありませんが、改正前の枠組みを前提にした条項構成のまま更新されていない可能性があるため、雛形が現行民法に対応しているかをベンダーに確認する材料になります。

民法上、契約不適合責任の追及には不適合を知った時から一定期間内の通知が必要とされていますが、実務の契約書では「検収完了後◯か月」のように期間を独自に定めるのが一般的です。この期間設定はチェックポイントの章で改めて取り上げます。

②準委任に「履行割合型」と「成果完成型」の2類型が明文化

改正民法では、準委任の報酬の定め方として2つの類型が明文化されました。

• 履行割合型：業務の遂行の割合に応じて報酬を支払う類型。従来からの「工数ベース」の準委任がこれにあたります（民法648条3項）
• 成果完成型：業務の遂行により得られる「成果」の引渡しと引き換えに報酬を支払う類型（民法648条の2）。調査レポートの納品に対して報酬を支払う、といった形が典型です

成果完成型は「成果に対して支払う」という点で請負に似ていますが、請負とは異なり、受託者が完成義務を負うわけではありません。善管注意義務を尽くして業務を遂行したにもかかわらず成果が得られなかった場合の扱いが、完成をコミットする請負とは異なります。

発注者にとっての実務的な意味は、「準委任」とだけ書かれた契約書では報酬条件が特定しきれないということです。契約書がどちらの類型を想定しているのか、報酬の支払い条件（毎月の稼働報告に対する支払いか、成果物の引渡しに対する支払いか）と整合しているかを確認してください。

システム開発での成果完成型の使いどころとしては、要件定義フェーズの成果物（要件定義書）や技術調査のレポートなど、「完成を固く約束させるほどではないが、形のある成果物に対して支払いたい」場面が挙げられます。柔軟さと成果の明確さのバランスを取れる選択肢として、準委任＝履行割合型と決めつけずに検討する価値があります。

システム開発ではどう使い分けるか

「準委任と請負のどちらが良いか」という問いに一般解はありません。判断軸は要件がどこまで固まっているかです。

要件が固まらないフェーズは準委任、確定後は請負

請負契約は「何をもって完成とするか」を定義できて初めて機能します。新規事業やDXの初期段階のように、作るべきものが検証しながら変わっていくフェーズで無理に請負を選ぶと、完成の定義が曖昧なまま契約することになり、仕様変更のたびに追加費用の交渉が発生したり、検収時に「言った・言わない」の争いになったりしがちです。

たとえば新規サービスの開発であれば、最初の2〜3か月は準委任でユーザーヒアリング・プロトタイプ検証・要件定義を行い、そこで確定した仕様に基づいて本開発を請負で見積もる、という流れが考えられます。検証フェーズの成果（要件定義書やプロトタイプ）が本開発の見積もりの精度を上げるため、最初から全体を一括請負で発注するより、総額の予測可能性はむしろ高くなります。

そこで実務では、開発をフェーズで分割し、契約形態を切り替える進め方が定着しています。

検証フェーズを準委任で小さく始め、要件が固まった時点で本開発を請負で契約する。この二段構えは、発注者にとっては「固まっていないものに固定価格を付けるリスク」を避けられ、受注者にとっては「曖昧な完成義務を負うリスク」を避けられる、双方に合理的な組み立てです。新規事業でこの進め方をどう設計するかは、新規事業の外注ガイドで詳しく解説しています。また、フェーズごとの費用感はWebアプリ開発の費用相場が参考になります。

実務では「基本契約＋個別契約」の形が多い

フェーズ分割を前提にすると、契約書の構成は「基本契約書＋個別契約書（注文書・個別覚書）」の二層になることが一般的です。秘密保持、知的財産、損害賠償、解約といった全フェーズに共通する条件を基本契約で定め、フェーズごとの業務内容・契約形態（準委任か請負か）・金額・期間を個別契約で定めます。

この構成では、個別契約ごとに契約形態が異なる点に注意が必要です。「基本契約を結んだからすべて同じ条件」ではなく、いま締結しようとしている個別契約が準委任なのか請負なのか、報酬と検収の条件はどちらの形態として書かれているのかを、個別契約単位で確認してください。基本契約と個別契約で矛盾がある場合にどちらが優先されるかの条項も、あわせて確認しておきましょう。

アジャイル開発は準委任が主流

短いサイクルで開発と検証を繰り返すアジャイル開発は、「最初に全仕様を確定しない」ことが前提の進め方であるため、完成の事前定義を要する請負とは構造的に相性がよくありません。実務ではアジャイル開発の契約は準委任が主流であり、IPA（情報処理推進機構）が公開しているアジャイル開発向けのモデル契約も準委任型を前提としています。

準委任でアジャイル開発を進める場合、発注者側にもプロダクトの優先順位を判断する役割（プロダクトオーナー等）への関与が求められます。「準委任だから任せきりでよい」のではなく、むしろ発注者の意思決定が開発の質を左右する契約形態だと理解しておく必要があります。契約書のうえでも、双方の役割分担（誰が優先順位を決め、誰がスプリントごとの成果を確認するか）が定められているかを確認してください。

AI駆動開発時代の契約で確認すべき新論点

生成AIをコード生成やテストに本格的に組み込むAI駆動開発が普及したことで、従来の「準委任か請負か」という論点だけではカバーできない確認事項が生まれています。多くの契約解説はこの変化に追いついておらず、ベンダー側の契約書雛形にもまだ反映されていないことが少なくありません。契約形態の選択とは別の軸で、契約書と提案書に次の3点が織り込まれているかを確認してください。

①AIが生成したコードの品質責任を誰が負うか

AIが生成したコードであっても、納品物としての責任の所在が変わるわけではありません。請負であれば完成義務と契約不適合責任、準委任であれば善管注意義務の枠組みの中で、ベンダーが自らの成果物として品質に責任を持つのが原則です。

ただし、この原則が実効性を持つかどうかは、ベンダーの体制次第です。確認すべきは、AI生成コードに対する人によるレビュー・テストのプロセスが提案書や契約書（仕様書・作業標準を含む）に明記されているかという点です。「AIを使って速く安く作れます」という説明だけで、生成コードの検証体制に言及がないベンダーには、体制を具体的に質問してください。回答が曖昧であれば、契約形態にかかわらず品質リスクを発注者が事実上引き受けることになりかねません。

②成果物の著作権・利用権の帰属（AI生成部分を含むか）

従来のシステム開発契約でも著作権の帰属は主要な交渉事項でしたが、AI生成物については、そもそも著作権が発生するのか、発生するとして誰に帰属するのかについて、法的な議論が続いている段階です。だからこそ、法律の解釈に委ねるのではなく、契約書上で「AIにより生成された部分を含む成果物一式」の権利帰属と利用許諾の範囲が明記されているかを確認する必要があります。

あわせて、AI生成コードが第三者の権利を侵害していた場合の対応（ベンダーによる表明保証や、問題発覚時の対応義務）や、開発に使用するAIツールへ自社の秘密情報・データを入力する場合の取り扱いが定められているかの確認も欠かせません。

③開発が速くなっても検収の考え方は変わらない

AI駆動開発によって実装のスピードは大きく上がりますが、検収——納品物が要件を満たしているかを発注者が確認する行為——の重要性はまったく変わりません。むしろ短期間に大量のコードと機能が納品されるようになるため、検収基準が曖昧なままだと、確認しきれないものを受け入れる状況が生まれやすくなります。

検収の対象・基準・期間・不合格時の手続きが契約書に具体的に定められているか、そして納期短縮を理由に検収期間まで不当に短く設定されていないかを確認してください。開発が速くなった分の余裕は、検収と品質確認に充てるのが健全な使い方です。

一方で、AI駆動開発は発注者にとって好材料にもなります。設計書やテスト結果報告書のようなドキュメントの作成コストが下がるため、従来は「ドキュメントは最小限で」と省略されがちだった納品物を、追加負担を抑えて求めやすくなりました。ただし、AIが作成したドキュメントも人による内容確認を経ているかは、コードと同じ基準で確認が必要です。納品物の一覧にソースコードだけでなく設計ドキュメント・テスト結果が含まれているかは、契約書の別紙で具体的に確認できます。

発注者が契約書レビューで見る10のチェックポイント

システム開発の契約書は、多くの場合ベンダー側の雛形をベースに提示されます。雛形が悪いわけではありませんが、雛形は作成者に有利に書かれているのが通常です。発注者として、次の10点を自社の立場から確認してください。

読み方のコツは、条文を頭から順に読むのではなく、チェックポイント単位で該当条項を探して読むことです。契約書は条文の並び順に重要度が並んでいるわけではなく、発注者にとって重要な条項ほど後半や別紙に置かれていることがあります。以下の10項目を確認して該当条項が見つからなければ、「定めがない」こと自体が確認事項になります。

1. 業務範囲の特定：委託する業務・成果物が別紙や仕様書で具体的に特定されているか。「◯◯システムの開発一式」のような曖昧な記載は、後の追加費用交渉やスコープ争いの火種になります。
2. 契約形態と報酬条件の整合：タイトルが「業務委託契約」でも実体は条文で決まります。完成義務・検収・報酬の支払い条件が、準委任（履行割合型／成果完成型）・請負のどれとして書かれているか、報酬の定め方と矛盾していないかを確認してください。
3. 検収基準と検収期間：何をもって合格とするか（テスト項目・判定基準）と、検収に使える期間が明記されているか。「◯日以内に異議がなければ合格とみなす」条項がある場合、その日数で実際に確認しきれるかを検討してください。
4. 契約不適合責任の期間：検収後に発見された不具合への対応期間がどう定められているか。極端に短い期間や、責任を全面的に免除する条項になっていないかを確認してください。
5. 知的財産権・著作権の帰属（AI生成物を含む）：成果物の著作権がいつ・どの範囲で移転するか（または利用許諾か）、著作者人格権の不行使、ベンダーの既存資産（ライブラリ等）の扱い、そしてAI生成部分を含むことが明記されているかを確認してください。
6. 再委託の条件：ベンダーが業務を第三者に再委託できるか、できる場合に発注者の事前承諾が必要か。再委託先の行為についてもベンダーが責任を負う旨があるかを確認してください。
7. 秘密保持とデータの取り扱い：秘密情報の定義と管理義務、契約終了時の返却・破棄に加え、自社データを開発・テスト・AIツールにどう使ってよいかの範囲が定められているかを確認してください。個人情報を扱う開発では特に重要です。
8. 途中解約の条件と精算方法：プロジェクト中止時にどんな条件で解約でき、既履行分の報酬や仕掛かり成果物の扱いをどう精算するか。事業判断で開発を止める可能性がある新規事業では、この条項の実務的な重みが増します。
9. 損害賠償の上限：ベンダーの賠償責任が「受領済み委託料の範囲内」などに制限されるのが一般的ですが、上限額が契約金額や想定される損害の規模に対して著しく見合っていないか（例：契約金額の1か月分相当など極端に低い設定になっていないか）、故意・重過失の場合の例外があるかを確認してください。
10. 追加開発・仕様変更の扱い：仕様変更や追加要望が発生した場合の手続き（変更管理）と費用の決め方が定められているか。ここが曖昧な契約は、開発が進むほど摩擦が大きくなります。

10項目すべてを発注者有利に書き換えることが目的ではありません。リスクの所在を双方が理解したうえで、自社にとって許容できない条項がないかを見極めることがレビューの目的です。金額の大きい契約や判断に迷う条項については、法務部門や弁護士への確認をおすすめします。

よくある質問

Q. 準委任契約だと、成果物に責任を負ってもらえないのですか

「完成義務がない」ことは事実ですが、「責任がない」わけではありません。履行割合型の準委任であっても、受託者は善管注意義務——専門家として通常期待される水準で業務を遂行する義務——を負っており、これに反する仕事ぶりで損害が生じれば債務不履行責任を問える余地があります。また、成果物への責任を明確にしたい場合は、成果完成型の準委任や請負を選ぶ、検収に相当する確認プロセスを契約に組み込むといった設計も可能です。

Q. 準委任と請負では、どちらが安く済みますか

契約形態そのものが価格を決めるわけではありません。総費用を左右するのは要件の確度です。要件が固まっているなら請負で固定価格にする合理性がありますが、固まっていない段階で請負にすると、ベンダーは不確実性の分をリスクバッファとして見積もりに乗せるか、仕様変更のたびに追加費用を請求することになり、結果的に高くつくことがあります。逆に要件が明確なのに準委任で進めると、工数管理が緩んだ場合のコスト増を発注者が負うことになります。形態の選択より先に、要件の確度を正直に評価することをおすすめします。

Q. 偽装請負とは何ですか

契約上は請負や準委任の形をとりながら、実態として発注者がベンダーの技術者に直接指揮命令している状態を指します。指揮命令を伴う労働力の提供は労働者派遣にあたり、派遣の許可や労働法上の保護なしにこれを行うことが問題とされます。発注者側の実務としては、ベンダーの技術者が常駐する場合でも、作業指示はベンダーの責任者を通す、勤怠管理をしないなど、指揮命令の線引きを守ることが重要です。なお、アジャイル開発のように発注者とベンダーが日常的に密にやり取りする体制は、それ自体が偽装請負になるわけではありません。プロダクトの要望や優先順位を伝えることと、個々の技術者への作業指示・労務管理は区別されます。判断に迷う体制になりそうな場合は、契約前に双方の役割分担を文書で確認しておくと安全です。

Q. 契約書はベンダーに任せておけばよいですか

ベンダー提示の雛形をそのまま締結することはおすすめしません。雛形は通常、作成した側のリスクを抑える方向に書かれています。前章の10のチェックポイントを目安に、少なくとも業務範囲・検収・責任範囲・解約条件・知財の帰属は自社の目で確認し、金額や重要度に応じて法務・弁護士のレビューを入れてください。誠実なベンダーであれば、契約条件の質問や修正協議を嫌がることはありません。むしろ契約段階での丁寧なすり合わせは、開発が始まってからの認識齟齬を減らし、プロジェクト全体の成功確率を高める投資になります。

まとめ

契約形態の選択は、法務だけの問題ではなく「開発をどう進めるか」の設計そのものです。本記事の要点を整理します。

• 準委任は「業務の遂行」に、請負は「仕事の完成」に対して報酬が発生する。完成義務と契約不適合責任の有無が実務上の最大の違い
• 2020年民法改正で、請負の瑕疵担保責任は契約不適合責任に再構成され、準委任には履行割合型・成果完成型（民法648条の2）の2類型が明文化された
• 使い分けの軸は要件の確度。検証フェーズは準委任、要件確定後の本開発は請負というフェーズ分割が実務の定石で、アジャイル開発は準委任が主流
• AI駆動開発の時代には、AI生成コードのレビュー体制、AI生成部分を含む権利帰属、検収基準の明確化という新しい確認事項が加わる
• ベンダー提示の契約書は10のチェックポイントで確認し、重要な契約は法務・弁護士のレビューを入れる

Swoooは、東証グロース上場の株式会社アイビス（証券コード9343）が運営する開発支援サービスです。累計50件以上の開発支援実績のなかで、検証フェーズは準委任・本開発は請負というフェーズ分割の契約設計を標準的な進め方として提案しています。契約形態の相談を含め、開発の進め方から一緒に設計したい方は、お問い合わせからご相談ください。

※本記事は一般的な情報提供であり、法的助言ではありません。個別の契約は法務・弁護士への確認をおすすめします。