先に要点
システム開発や受託開発では、この案件は準委任ですか、請負ですか という話がかなり早い段階で出ます。
ただ、現場では とりあえず請負で出す 保守っぽいから準委任で くらいの雰囲気で決めてしまい、あとから責任範囲や期待値がずれることがあります。
特に揉めやすいのは、発注側は 完成したものが納品される契約 だと思っているのに、受注側は 工数ベースで伴走する契約 と認識しているケースです。
ここがずれると、途中の仕様変更、追加要望、納品可否、無償対応範囲まで全部ぶれます。
この記事では、準委任契約 と 請負契約 の違いを、成果物、報酬、検収、責任範囲、システム開発での使い分けの観点から整理します。
納品後の責任範囲まで続けて見たい場合は、システム開発で瑕疵対応はどこまで必要？契約不適合責任と不具合修正の違いを整理 もつながりやすいです。
この記事では、2026年4月22日時点で IPA の情報システム・モデル取引・契約書（第二版）、アジャイル開発版、見直しポイントを確認しながら整理しています。ここでは法的助言ではなく、システム開発の実務で判断しやすくするための整理としてまとめます。個別契約は契約書と専門家確認を優先してください。
結論：完成責任で切るなら請負、業務遂行で切るなら準委任
最初にかなり大づかみに言うと、次の理解でだいたい外しにくいです。
だから、完成条件を決めやすい案件は請負に向きやすいです。
一方で、要件がまだ動く、検証しながら進める、調査や伴走支援が多い案件は準委任の方が実態に合いやすいです。
ただし、契約名だけで全部が決まるわけではありません。
同じ 請負 でも検収条件が弱ければ揉めますし、同じ 準委任 でも成果物や報告義務が曖昧なら期待値がぶれます。
準委任契約と請負契約の違い
まずは全体像を表で置くと整理しやすいです。
| 観点 | 準委任契約 | 請負契約 |
|---|---|---|
| 重心 | 業務の遂行 | 成果物の完成 |
| 向きやすい仕事 | 要件整理、調査、PM支援、保守、伴走型開発 | 仕様が比較的固まった開発、構築、制作 |
| 報酬の考え方 | 工数、期間、体制ベースになりやすい | 成果物や工程完了ベースになりやすい |
| 検収 | 必須概念になりにくいが、成果物があるなら確認方法は必要 | 完成物を受け入れるための検収が重要になりやすい |
| 揉めやすい点 | `どこまでやる前提か` `どこで追加になるか` | `何をもって完成か` `どこまで無償修正か` |
大事なのは、準委任は成果物が一切ない 請負は工数を見ない と雑に覚えないことです。
実際には、準委任でも調査報告書や設計メモは出ますし、請負でも途中のレビューや定例はあります。
違いは、契約の中心がどこにあるかです。
請負契約が向きやすいケース
請負に乗せやすいのは、何を作るか と どこまでできたら完了か を比較的明確に言える案件です。
たとえば次のようなケースです。
- 画面一覧、機能一覧、外部連携範囲がある程度固まっている
- 納品物が明確で、検収 条件も置きやすい
- 予算や納期を成果物ベースで管理したい
- 追加開発と初回納品範囲を分けたい
Webサイト制作でも、ページ構成、フォーム仕様、公開条件まで決まっている案件は請負と相性がよいです。
業務システムでも、対象範囲と完了条件をかなり具体化できるなら請負にしやすいです。
ただ、請負にした瞬間に安心というわけではありません。
要件が固まっていないのに請負で受けると、途中から出る論点が全部 契約内か契約外か の争いになりがちです。
準委任契約が向きやすいケース
準委任に寄せた方がよいのは、途中で理解が深まり、進めながら決める要素が多い仕事です。
たとえば次のようなケースです。
- 要件定義や現状調査から一緒に進める
- 既存システム調査や移行方針の整理が中心
- アジャイル開発で優先順位を入れ替えながら進める
- 運用保守、改善提案、伴走支援が主目的
- 発注側の意思決定待ちや関係者調整が多い
この種の案件を無理に請負にすると、途中で見えてきた論点が全部 最初から入っていたか という話になり、現場が消耗しやすいです。
準委任なら、業務の進め方、役割分担、報告方法、追加判断のルールを前に置きやすくなります。
システム開発では途中で契約類型が切り替わることもある
実務では、最初から最後まで完全に同じ類型で通すより、フェーズごとに切る方が自然なことがあります。
よくあるのは次の流れです。
この切り方なら、前半は不確実性を吸収しつつ、後半は完成責任を置きやすくなります。
逆に、全部を一つの請負に押し込むと要件変動に弱くなり、全部を準委任に寄せると発注側が いつ何が完成するのか を見失いやすくなります。
アジャイル開発はどちらを選ぶべきか
ここも誤解が多いですが、アジャイルだから必ず準委任 とまでは言い切れません。
ただ、要件や優先順位が変動しやすいなら、準委任の方が実態に合いやすい場面は確かに多いです。
IPA のアジャイル開発版でも、固定化しきれない要件や継続的な対話を前提にした整理が重視されています。
そのため、アジャイルで請負を使うなら、少なくとも次はかなり丁寧に決める必要があります。
- スプリントごとに何を成果とみなすか
- 変更をどう扱うか
- Backlog の優先順位変更を契約上どう扱うか
- どこで完了判定を置くか
ここが弱いまま アジャイル請負 を始めると、現場の運用は準委任っぽいのに、契約上は請負というねじれが起きやすいです。
よくある誤解
準委任なら何でも追加できる
これは違います。
準委任でも、対象業務、工数、対応時間、報告方法、優先順位の決め方を置かないと、際限なく仕事が膨らみます。
請負なら全部完成保証になる
これも危ないです。
何をもって完成とするか、何が納品対象か、どこまでが前提条件か、検収 で何を確認するかが曖昧なら、請負でも揉めます。
契約名だけ書けば十分
実務ではむしろここが危険です。
契約書の表紙に 準委任 請負 と書いてあっても、本文で成果物、報酬、責任範囲、変更管理が弱いと、現場では判断できません。
請負契約で特にそろえておきたいこと
請負にするときは、最低限次をそろえたいです。
このあたりが弱いと、あとで それも完成のうちですよね が増えやすくなります。
要件定義側の整理から見直したい場合は、要件定義で最低限決めることは？受託開発であとから揉めやすい項目を整理 もつながりやすいです。
準委任契約で特にそろえておきたいこと
準委任では、完成条件より どう進めるか をそろえるのが大事です。
- 対象業務の範囲
- 体制と稼働時間
- 定例、報告、意思決定の流れ
- 優先順位の決め方
- 成果メモや中間成果物の扱い
ここがないと、発注側は 頼んだら全部やってくれる と思いやすく、受注側は そこまでは契約外 となりやすいです。
準委任は柔らかく見えて、運用ルールをかなり丁寧に決める必要があります。
迷ったときの判断基準
迷ったら、次の順で見ると整理しやすいです。
- 今回の中心は
完成物か業務遂行か - 完了条件を具体的に置けるか
- 途中の要件変動がどれくらいあるか
- 検収 を明確に運用できるか
- 追加要望と当初範囲を分けやすいか
この5つで 完成物中心 に寄るなら請負、進めながら整理する業務中心 に寄るなら準委任が合いやすいです。
曖昧なら、フェーズ分割で切る方が無理が出にくいです。
クライアントにどう説明すると伝わりやすいか
実務では、法律用語をそのままぶつけるより、期待値の違いとして説明した方が通りやすいです。
説明例
この案件は、最初から完成条件を固めて納品まで責任を持つ進め方なのか、まず要件整理や優先順位の調整をしながら伴走する進め方なのかで、契約の切り方が変わります。
仕様が固まっている部分は請負、まだ変動が大きい部分は準委任に分けると、あとからの認識ずれが減らしやすいです。
この言い方なら、準委任の方が得です 請負の方が安全です と雑に寄せず、案件の性質で説明しやすくなります。
まとめ
準委任契約 と 請負契約 の違いは、ざっくり言えば 業務遂行に重心があるか 成果物完成に重心があるか です。
システム開発では、その違いが報酬、検収、責任範囲、変更管理にそのまま跳ねます。
実務では、契約名だけ決めるより、要件の固まり具合、不確実性、成果物、検収条件、運用保守との境目までそろえて設計する方がずっと大事です。
無理にどちらか一つへ寄せるより、フェーズごとに切った方がうまくいく案件もかなりあります。