請負契約とは——民法632条の「仕事の完成」と、報酬・不具合・解除の時間軸【2026年版】

開発会社から届いた契約書の表題は「業務委託契約書」。中を読むと「本件成果物を完成させ、納入する」と書いてある。これは請負なのだろうか。そもそも請負だと何が変わるのだろうか——契約書を前にして、そこで止まってしまう方は少なくありません。調べ始めると、業務委託、委任、準委任、請負、派遣と似た言葉が並び、かえって輪郭がぼやけます。

先に結論を書きます。請負契約を理解する鍵は、似た契約との比較表ではありません。『仕事を完成させることを約束し、その完成に対して報酬を払う』という一点です。民法632条がそう定めています。ここから、報酬はいつ払うのか、完成しなかったらどうなるのか、引渡し後に不具合が出たら誰が直すのか、途中でやめられるのか、という実務の問いにすべて答えが出ます。

この記事では、条文を並べるのではなく、発注から解除までの時間軸に沿って並べ替えます。発注(632条)、完成と引渡し(633条)、完成しなかった場合(634条)、引渡し後の不具合(636条・637条)、途中でやめる場合(641条・642条)。この順で読むと、手元の契約書のどこを確認すればよいかが決まります。なお、この記事は法的助言ではありません。個別の判断は弁護士にご確認ください。

私はTALENTBASE VIETNAMでCOOを務めています。人材業界の出身で、請負・委任・派遣の使い分けを実務で見てきました。当社が提供しているのはラボ型開発、つまり準委任であって請負ではありません。ですから、仕様が確定していて変更の見込みが小さい案件では、請負のほうが発注者にとって分かりやすいと率直にお伝えします。一方、2018年以降に約100社のご相談を受けてきた実感として、作りながら決めたい案件で請負を選ぶと、変更のたびに変更契約が必要になり、手続きが実態に追いつかなくなります。

読み終えたら、手元の契約書で3箇所だけ確認してみてください。完成の定義、検収の基準、契約不適合責任の期間です。この3つが埋まっていれば、表題が何であれ、その契約は実務で機能します。

請負契約とは——民法632条が定める「仕事の完成」の約束

請負契約は、民法632条に定められた典型契約のひとつです。条文は短く、次のように定めています。当事者の一方がある仕事を完成することを約束し、相手方がその仕事の結果に対して報酬を支払うことを約束する契約である、と。この一文にすべてが入っています。

なお、この記事はシステム開発の発注を前提に書いています。請負は建設工事でも使われる契約類型ですが、建設業法に基づく論点は扱いません。

条文が定めていること

押さえるのは2点です。ひとつ、約束しているのは「仕事の完成」であること。作業に従事することではありません。ふたつ、報酬は「仕事の結果」に対して支払われること。時間ではなく、出来上がったものに対価が付きます。

この2点から、請負の性格が決まります。受注者は完成させる義務を負います。一方で、条文は「誰がどう作るか」を定めていません。発注者が作業のやり方を細かく指示し、実態が労働者派遣と評価されると偽装請負の問題になります(厚生労働省東京労働局「偽装請負について」)。逆に、受注者は完成させるまで責任を負い続けます。

私は人材業界の出身で、請負・委任・派遣の使い分けを実務で見てきました。この3類型を分けているのは、結局のところ「何を約束したか」です。請負は完成、委任と準委任は事務を処理すること、派遣は労働力を提供すること。約束の対象が違うから、責任の形も違う。ここを押さえると、細かい比較表を覚える必要はなくなります。

「完成」とは何を指すのか

実務で最初に問題になるのが、この「完成」です。裁判例の考え方として一般に紹介されているのは、予定された最後の工程まで終わっているかどうかで判断するというものです。細かい不具合が残っていても、最後の工程まで終わっていれば完成とみなし、残った不具合は契約不適合の問題として扱う、という整理になります。

この考え方は、発注者にとっては直感に反するかもしれません。「動かないのだから完成ではない」と言いたくなります。しかし完成と不適合を分けておかないと、報酬の支払時期も責任の期間も定まりません。だからこそ、契約書で「何をもって完成とするか」を具体的に書いておく必要があります。

書き方は難しくありません。別紙に納入物の一覧を書き、検収の基準を「別紙のテスト項目をすべて満たすこと」のように判断できる形にする。これだけで、完成の議論は事実の確認になります。

契約書の表題では決まらない

もうひとつ押さえておきたいのは、632条が契約書の表題ではなく「当事者が何を約束したか」を要件にしている点です。条文は「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」と定めています(e-Gov法令検索で条文を確認、確認日2026-09-21)。したがって「業務委託契約書」という表題でも、中身が仕事の完成とその結果に対する報酬を約束するものであれば、632条の要件に当てはまることになります。

当社は受注する側として契約書を拝見する立場でもあります。表題が業務委託契約書で、条文には完成義務と検収が書かれ、しかし成果物の別紙は空欄、という組み合わせをよく見かけます。この状態は、請負の責任だけがあって、完成の基準がない状態です。

なお、契約の成立に書面は要りません。民法522条2項は、契約の成立には法令に特別の定めがある場合を除き、書面の作成その他の方式を具備することを要しないと定めています。メールのやりとりだけでも請負契約は成立しうるということです。契約書を交わすのは、成立させるためではなく、後から何を約束したのかを確認できるようにするためです。

請負で双方が負う義務——完成させるのは受注者だけの仕事ではない

請負というと、受注者が一方的に義務を負う契約だと理解されがちです。条文の建て付けとしては間違っていませんが、システム開発の実務ではその理解のままだと止まります。

受注者が負うのは、仕事を完成させる義務、完成した目的物を引き渡す義務、そして引き渡した後の契約不適合責任です。この3つは条文に書かれています。一方、発注者が負うのは報酬を支払う義務(632条)が中心で、それ以外の義務は条文に明示されていません。

にもかかわらず、実際の開発では発注者が動かないとプロジェクトが進みません。仕様を確定するのも、既存システムの資料を出すのも、中間成果物を確認するのも発注者です。IPAと経済産業省の「情報システム・モデル取引・契約書」第二版は、この点を契約書の側で手当てしています。第8条(協働と役割分担)は、発注者による仕様の早期かつ明確な確定が重要であることを双方が認識し、共同作業と各自の分担作業を誠実に実施すること、相手方の分担作業に誠意をもって協力することを定め、3項では分担作業を遅延したり実施しなかったりした場合の損害賠償責任まで、双方向に定めています。

同じ第二版の公表資料によれば、第一版の公表以降にシステム開発の裁判例が集積し、ベンダのプロジェクトマネジメント義務とユーザの協力義務がよく問題になってきました。同資料は、ユーザもシステム開発プロセス一般の意味でのプロジェクトマネジメントを行う必要がある、とも述べています。

請負で発注したから丸投げでよい、という読み方はできません。約束の対象が完成であることと、発注者が何もしなくてよいことは、別の話です。定義が分かったところで、次は時間軸で追っていきます。

時間軸で見る請負——報酬・不具合・解除は条文で決まっている

ここからが本題です。条文を番号順に並べても契約書には当てはめられません。発注から解除までの順に並べ替えると、各段階で何が決まっているのかが見えてきます。

この表のうち、契約不適合責任(636条・637条)は分量が多いので、後ろに独立した章を設けました。この章では報酬と解除を扱います。

報酬はいつ払うのか(633条)

原則は、目的物の引渡しと同時です。633条本文がそう定めています。引渡しと支払いが同時履行の関係に立つため、発注者は引渡しを受けるまで支払いを拒めますし、受注者は支払いを受けるまで引渡しを拒めます。

物の引渡しを要しない仕事の場合は、633条但書が624条1項を準用しています。624条1項は「約した労働を終わった後でなければ、報酬を請求することができない」という規定ですから、こちらも後払いです。つまり請負は、形式を問わず後払いが原則で、完成前に報酬を請求する権利は当然には生じません。

実務では、着手金や中間金を設定することが多くあります。これは条文の原則を契約で変えている形です。633条は当事者の合意で変えられる規定ですから、契約書の支払条項が条文より優先します。中間金を入れるなら、どの時点で何割を支払うのかを契約書に明記してください。「基本設計の完了時に30%」のように、支払いの条件を成果物と結びつけておくと、判断が事実の確認になります。

発注者の側から見ると、分割払いには別の意味もあります。全額を納品後にすれば途中で問題が起きたときの交渉は楽ですが、その分だけ受注者の資金繰りが苦しくなり、体制を維持できなくなるリスクを発注者も抱えます。支払いの設計は値切りの道具ではなく、プロジェクトを完走させるための設計です。

完成しなかったらどうなるのか(634条)

ここが最も誤解されている論点です。「請負は完成しなければ報酬はゼロ」と理解している方が多いのですが、634条は別の道を用意しています。

条文の適用場面は2つです。ひとつは、注文者の責めに帰することができない事由によって仕事を完成することができなくなったとき。もうひとつは、請負が仕事の完成前に解除されたときです。次に述べる641条の解除も、ここに入ってきます。

そのうえで条文は、請負人が既にした仕事の結果のうち「可分な部分の給付によって注文者が利益を受けるとき」は、その部分を仕事の完成とみなし、請負人は注文者が受ける利益の割合に応じて報酬を請求することができる、と定めています。

鍵になるのは「可分」と「利益」の2語です。作業が6割進んでいれば自動的に6割の報酬が発生する、という条文ではありません。既にできている部分が切り分けられる形になっていて、しかもそれによって発注者が現実に利益を受けていることが必要です。

システム開発に置き換えると、争点はここに集約されます。納品済みの要件定義書や外部設計書、リポジトリのソースコードは、次のベンダーがそのまま引き継いで続きを作れる状態なのか。引き継げるなら可分な部分の給付として評価される余地がありますが、設計書と実装が食い違っていて読み解くだけで作り直しと同じ工数がかかるなら、利益を受けているとは言いにくくなります。

この一点を知っているだけで、途中終了時の交渉はまったく違うものになります。「完成していないのだから払わない」でも「契約したのだから全額払え」でもなく、可分性と利益という土俵で話ができるからです。実務としては、揉めてから算定するより、契約時に工程ごとの中間の支払い条件と、中断時の成果物の引き渡し方法を決めておくほうが早い。契約を終わらせる場面の手続き全般は「業務委託契約の解除」の記事で扱っています。

途中でやめる場合(641条・642条)

途中でやめる場合の条文は641条です。注文者は、仕事が完成しない間であれば、損害を賠償していつでも解除できます。理由は要りません。受注者側から同じように自由に解除できる規定はなく、ここは請負の非対称なところです。

「損害を賠償して」という部分は、無料でやめられるわけではないという意味です。何が損害に当たるかは事案によりますが、既に投入した費用や、その案件のために確保していた体制に関する部分が議論の対象になります。634条の割合的報酬とどう組み合わせるかも含め、金額は交渉になります。

もう一方の642条は、注文者が破産手続開始の決定を受けたときの規定です。請負人または破産管財人が解除でき、ただし請負人による解除は仕事を完成した後はできません(1項但書)。2項は、請負人が既にした仕事の報酬とその中に含まれていない費用について破産財団の配当に加入できると定め、3項は、解除によって生じた損害の賠償を請求できるのは破産管財人が解除した場合の請負人に限るとしています。

なお、以上は一般的な整理であり、個別の事案の判断は事情によって異なります。この記事は法的助言ではありません。完成しなければゼロ、ではない。この一点だけでも持ち帰ってください。

検収とは何か——民法にない手続きが、報酬と責任を動かしている

前章で、報酬は目的物の引渡しと同時に支払うのが原則だと書きました。ところが実務で報酬を動かしているのは、引渡しそのものではなく「検収」という手続きです。ここに落とし穴があります。検収という言葉は、民法の請負の規定には一度も出てきません。

民法に「検収」という条文はない

請負を定めた民法632条から642条までを通して読んでも、「検収」という語は登場しません(2026-09-19にe-Gov法令検索で確認)。条文が使っているのは「仕事の完成」「目的物の引渡し」「仕事が終了した時」という言葉だけです。

つまり検収は、法律が用意してくれている手続きではなく、当事者が契約書で作る仕組みです。契約書に書かなければ存在しませんし、書き方がそのまま実務の手順になります。

では、何を書けばよいのか。参考になるのが、IPA(情報処理推進機構)と経済産業省が公表している「情報システム・モデル取引・契約書」第二版(2020年12月22日公表)です。このひな型は、納入から検収までを3段階に分けています。第26条で納入物を検収依頼書とともに納入し、第27条で検査の基準となる検査仕様書を作成・承認し、第28条でその検査仕様書に基づいて検査する。そして第28条4項は「本条所定の検査合格をもって、本件ソフトウェアの検収完了とする」と定めています。

検収とは、検査に合格したという事実のことです。感覚で「だいたい動いているから受け取る」ことではありません。

検収の基準は「検査仕様書」に書く

では検査の基準はどこに書くのか。IPAのひな型は、契約書の本文ではなく別の文書に置いています。第27条は、甲(発注者)が乙(受注者)と協議のうえ、システム仕様書に基づいて、検査の基準となるテスト項目、テストデータ、テスト方法、テスト期間等を定めた検査仕様書を作成する、という形です。

注目したいのは、検査仕様書を作るのが発注者側だという点です。受け取る側が、何をもって合格とするかを先に決める。発注者にその体力がない場合に備えて、第27条3項は「検査仕様書作成支援業務」を別の個別契約として受注者に委託できる道も用意しています。

当社は受注する側として契約書を拝見する立場でもありますが、検査仕様書が空のまま検収日を迎える現場は珍しくありません。担当者が画面をひととおり触って「動いているようなので合格にします」と言う。そこから3か月後に不具合が出て、これは検収前から存在したのかどうかで押し問答が始まる。この流れが起きるのは、合格の基準を書いた文書が最初からなかったからです。

文書の名前は検査仕様書でなくてもかまいません。別紙でもテスト計画書でも、第三者が読んで合否を判定できる項目が契約書から参照される形であれば足ります。

みなし検収条項——期間内に異議を述べないとどうなるか

検収の条項で、発注者がいちばん気にすべきなのはここです。IPAのひな型第28条3項は、検査合格書が交付されない場合であっても、検査期間内に発注者が書面で具体的な理由を明示して異議を述べないときは、検査に合格したものとみなす、と定めています。いわゆる「みなし検収」です。

受注者を守る条項ですが、不合理ではありません。発注者が黙っているだけで支払いが止まり続けるのでは、受注者は資金繰りが読めなくなります。ただし発注者の側から見れば、これは期限です。検査期間が5営業日なのか20営業日なのかで、社内で検査に割ける人手はまったく違ってきます。

不合格の場合の扱いも同じ条文にあります。IPAのひな型第28条2項は、受注者が期間内に無償で修正して再納入し、発注者は必要となる範囲で再度検査を行う、という手順です。

したがって、検収の条項で発注者が確認するのは3点です。検査期間が実際に検査できる長さか。異議の出し方が「書面で具体的な理由を明示」のように定められているか。不合格のときの再納入と再検査の手順、そして費用の負担が書かれているか。

検収しないまま使い始めた場合

現場でよくあるのが、正式な検収を済ませないまま本番で使い始めてしまうケースです。納期が迫っていて、営業部門がもう動かしている。検収書は「あとで」のまま数か月が過ぎる。

この場合、契約書にみなし検収条項があれば、検査期間の経過によって合格として扱われます。条項がなければ検収は未了のままですが、本番稼働させているという事実は、後から見れば受け入れたのと同じ評価を受ける方向に働きやすく、発注者に有利にはなりません。

もうひとつ見落とされがちなのが、責任の起算点です。IPAのひな型第29条5項は、受注者が契約不適合責任を負うのは「前条の検収完了後〇ヶ月／〇年以内」に通知された場合に限る、という形で空欄を置いています。起算点が検収完了に置かれている以上、検収が完了しない限り責任期間がいつ始まっていつ終わるのかも確定しません。

規模の大きい開発なら、機能のまとまりごとに部分検収を設計するほうが現実的です。全部できてから一度に検査するより検査側の負担が分散し、不具合の発見も早くなります。検収は事務手続きではなく、報酬と責任の両方を動かすスイッチです。ここを空欄にしたまま契約すると、次章の契約不適合責任も宙に浮きます。

契約不適合責任——引渡し後に不具合が出たときに使える4つの手段

2020年4月の改正民法施行までは「瑕疵担保責任」と呼ばれていた領域です。名前が変わっただけと説明されることもありますが、発注者が使える手段の中身と順番が整理されたため、契約書の読み方も変わりました。ここは請負で最も実務に効く部分です。

そもそも何が「契約不適合」になるのか

請負の契約不適合責任は、請負の条文だけでは完結していません。民法559条が「この節の規定は、売買以外の有償契約について準用する」と定めており、請負も有償契約ですから、売買の担保責任の規定が準用される構造になっています(2026-09-19にe-Gov法令検索で確認)。

その売買の側の入口が562条1項です。「引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるとき」と書かれています。判断の基準は、世間一般の品質水準ではなく「契約の内容」です。つまり、何が不適合かは仕様書が決めます。

IPAのモデル契約第二版も同じ立場を取っていて、第29条1項は契約不適合を「システム仕様書との不一致(バグも含む。)」と定義しています。システム開発でいえば、次のようなものが不適合に当たりやすい類型です。

• 仕様書に書かれた機能が動作しない、または仕様と違う挙動をする
• 仕様書で合意した応答時間や同時接続数といった性能が出ていない
• 合意したセキュリティ仕様が実装されていない
• 納入物の明細に挙がっている文書やソースコードの一部が納入されていない

逆に、仕様書に書かれていない使い勝手の不満や、後から欲しくなった機能は、契約不適合ではなく仕様変更の問題になります。線引きは「仕様変更 追加費用」の記事で扱っています。この切り分けをしないまま「不具合だから直せ」と言い続けると、交渉そのものが進みません。

使える手段は4つ——順番がある

準用によって、発注者が使える手段は4つあります。条文と、使える場面を並べます。

この表で押さえてほしいのは、4つが並列ではなく順番になっているという点です。まず追完を請求する。相当の期間を定めて催告しても追完されなければ、そこで初めて報酬の減額や解除に進めます。いきなり「解除して全額返せ」とは言えない構造です。

条文の言葉づかいにも違いがあります。売買では「代金の減額」ですが、請負について定めた637条1項は「報酬の減額の請求」という表現です。契約書で減額条項を作るときは、請負側の言葉に合わせておくと読み違いが減ります。

もうひとつ、発注者側の落とし穴です。不適合が発注者の責めに帰すべき事由によるものであるときは、追完の請求も報酬の減額の請求もできません(562条2項、563条3項)。発注者が出した指示や提供した資料が原因である場合は、この後の636条とあわせて効いてきます。

期間——637条の「1年以内の通知」と、契約でどう変えるか

期間の話は、条文と契約書の両方を見ないと答えが出ません。

条文の原則は637条1項です。発注者が不適合を知った時から1年以内にその旨を受注者に通知しないときは、追完の請求、報酬の減額の請求、損害賠償の請求、契約の解除のすべてができなくなる、と定めています。起算点は引渡しではなく「知った時」であること、求められているのが訴訟ではなく「通知」であることの2点が要点です。

例外もあります。637条2項は、引渡しの時(引渡しを要しない場合は仕事が終了した時)に受注者が不適合を知り、または重大な過失によって知らなかったときは、1項を適用しないと定めています。

なお、1年以内に通知すれば権利が永久に残るわけではありません。権利そのものは債権の消滅時効(166条1項。権利を行使することができることを知った時から5年、行使することができる時から10年)の対象になります。

そのうえで、実務の契約書は多くの場合この原則を上書きしています。IPAのひな型第29条5項は、受注者が責任を負うのは「前条の検収完了後〇ヶ月／〇年以内【であって、かつ甲が当該契約不適合を知った時から〇ヶ月以内】に通知された場合に限る」という形で、起算点を検収完了に置き、長さを当事者が埋める設計にしています。前章で検収が責任期間のスイッチだと書いたのは、この条文の作りがあるからです。

ここにも例外が置かれています。同項の但書は、検収完了時に受注者が不適合を知っていた場合や重過失で知らなかった場合、または不適合が受注者の故意・重過失に起因する場合には、この期間制限が働かないとしています。IPAが第二版の公表資料で説明しているとおり、重過失の有無は、損害賠償の責任制限条項の適用と、契約不適合責任の期間制限の適用の、両方の分水嶺になっています。ただし同資料は、システム開発の局面で重過失が認められた例はほとんどないとも述べており、挙げられている例はSQLインジェクション対策を講じなかったことが重過失とされた東京地裁平成26年1月23日判決(判例時報2221号71頁)です。契約書に「重過失の場合は無制限」とあっても、そこへ持ち込むのは容易ではないという前提で読んでください。

発注者の指図で生じた不適合は対象外——636条

請負には、売買にはない制限規定があります。636条です。

条文は、受注者が契約内容に適合しない目的物を引き渡したときでも、発注者が供した材料の性質または発注者が与えた指図によって生じた不適合を理由としては、追完の請求、報酬の減額の請求、損害賠償の請求、契約の解除をすることができない、と定めています。ただし但書があり、受注者がその材料または指図が不適当であることを知りながら告げなかったときは、この制限は働きません。

IPAのひな型も同じ構造を持っています。第29条6項が636条と同趣旨の定めを置き、さらに第39条4項では、発注者が提供する資料等の内容の誤りや提供の遅延によって生じた受注者の履行遅滞・契約不適合について、受注者は責を免れるとしています。

システム開発でこれが問題になるのは、発注者が提供した既存データベースの定義書が実際のデータと食い違っていた場合、発注者が特定のライブラリやミドルウェアを指定した場合、発注者が中間成果物を承認したうえで先の工程に進んだ場合などです。いずれも、後から不具合が出たときに「それは指図によるものだ」と主張される余地があります。

ここで効いてくるのが記録です。連絡協議会の議事録、承認した中間資料、変更管理の書面。どの指示を誰がいつ出したかが残っていれば、636条の議論は事実の確認で済みます。残っていなければ、記憶の突き合わせになります。

なお、以上は条文と公表資料に基づく一般的な整理であり、個別の事案の結論は事情によって変わります。この記事は法的助言ではありません。契約不適合をめぐる交渉が現実に始まっている場合は、早い段階で弁護士にご相談ください。手段は4つ、順番は追完から。まずこれだけ持ち帰ってください。

請負が向く仕事と向かない仕事——発注前に見る3箇所

条文が分かったところで、実務の判断に移ります。請負を選ぶべきか、そうでないか。判断の軸はひとつしかありません。仕様が動くかどうかです。

向く条件と向かない条件

請負の安心感は、総額が決まることから来ています。ただしその安心感は、仕様が動かないという前提の上に成り立っています。前提が崩れると、変更のたびに変更契約か追加見積もりが必要になり、手続きが実態に追いつかなくなります。

当社が提供しているのはラボ型開発、つまり準委任であって請負ではありません。ですから、仕様が確定していて変更の見込みが小さい案件では、請負のほうが分かりやすいと率直にお伝えします。一方、2018年以降に約100社のご相談を受けてきた実感として、ご相談の多くは「作りながら決めたい」「優先順位が毎月動く」という性格のものです。当社の場合、最小構成は日本人PM+2〜3人月で月額約80万円から、単価は実務3年1,500USD、5年2,000USD、ブリッジSE3,000USD(1USD=150円換算が目安)と公開しています。

プロジェクト全体をひとつの請負にしない

もうひとつ、実務の組み方として知っておきたいことがあります。請負か、そうでないかを、プロジェクト全体で一度だけ決める必要はありません。

IPAと経済産業省のモデル契約第二版は、基本契約をひとつ結んだうえで、工程ごとに個別契約を締結する多段階契約の形を取っています。第4条は、個別契約で定める取引条件のひとつとして「契約類型(請負・準委任)」を挙げており、工程ごとに類型を選べる設計です。条文群そのものも、工程によって選択肢が用意されています。

第二版の公表資料は、システム再構築の場面についても、現行システム調査・分析と再構築方法の検討を内容とする準委任契約としてのコンサルティング契約を別に結ぶ形に触れています。要件が固まっていない段階まで請負に押し込まない、という発想です。どの工程をどちらにするかの比較そのものは「準委任 請負 違い」の記事に譲ります。ここで持ち帰っていただきたいのは、契約類型は工程ごとに選べるという一点です。

発注前に見る3箇所

時間が5分しかないなら、見るのは3箇所で足ります。ひとつ、完成の定義。別紙に納入物の一覧、形式、時期が書かれているか。ふたつ、検収の基準と期間。判断できる基準と、みなし検収の扱いが定められているか。みっつ、契約不適合責任の期間と範囲。

この3つが埋まっていれば、表題が業務委託契約書であっても、その契約は実務で機能します。逆にここが空欄なら、条文がいくら整っていても判断の基準がありません。

条項チェックリスト——民法の原則を、契約書がどう上書きしているか

3箇所を見たあと、もう少し丁寧に読む余裕があるなら、次の順で確認してください。請負の条文の大半は当事者の合意で変えられる規定ですから、契約書を読む作業は「民法の原則を、この契約書がどちらの方向に、どれだけ動かしているか」を確認する作業になります。

この表にない論点として、成果物の著作権をどちらが持つかという問題があります。請負でも著作権は当然には発注者に移らないため、譲渡の条項が必要です。詳しくは「システム開発 著作権 帰属」の記事をご覧ください。また、ひな型そのものの直し方は「業務委託契約書 テンプレート」の記事で扱っています。

なお、チェックリストは読み方の順番を示したもので、個別の契約書の適否を判定するものではありません。金額の大きい契約は弁護士のレビューを受けてください。

請負で起きる紛争の3つの型

当社が見てきた範囲でも、また公表されている裁判例の整理を見ても、請負の紛争はおおむね3つの型に収まります。型が分かると、どの条項で止められるのかも見えてきます。

ひとつ目は、完成したかどうかの争いです。納期を過ぎても動かない、動くが仕様と違う。ここで効くのは納入物の明細と検査仕様書です。合格の基準が先にあれば、議論は事実の確認で終わります。

ふたつ目は、仕様変更の押し付け合いです。発注者は「最初から入っていた要件だ」と言い、受注者は「追加だから別料金だ」と言う。IPAのモデル契約が第34条から第37条にかけて、仕様書等の変更、中間資料の承認、未確定事項の取扱い、変更管理手続という4つの条項を連続して置いているのは、この型を条項で受け止めるためです。第37条は、変更提案書を受け取ったら変更管理書を交付し、第12条の連絡協議会で変更の可否を協議する、という手順を定めています。

みっつ目は、プロジェクトが途中で止まったときの責任の所在です。IPAの公表資料は、ベンダのプロジェクトマネジメント義務の一環として一定の場合の中止提言義務を判示した裁判例として、東京高裁平成25年9月26日判決(金融・商事判例1428号16頁)を挙げています。同資料はまた、下流工程のトラブルを理由に上流工程の個別契約まで解除できるかという論点に触れ、最高裁平成8年11月12日判決(民集50巻10号2673頁)の射程が直列型の多段階契約には当然には及ばないという共通認識が得られたと記しています。複数の契約に分けて発注する場合、どこまでが一蓮托生なのかは自明ではない、ということです。

3つの型に共通しているのは、争いの中身が技術ではなく記録だという点です。議事録、承認、変更管理書。これが残っている現場は、揉めても短時間で片が付きます。

個人や中小に請負で発注するときの追加の注意

発注先が個人や小規模な事業者の場合、追加で見る点があります。2024年11月施行のフリーランス新法は、個人に業務委託する場合の取引条件の明示などを定めています。2026年1月施行の取適法(旧下請法)は、発注時の条件明示や支払期日の扱いを厳格化しています。いずれも請負での発注に関わります。

もうひとつ、指揮命令の線引きです。請負は完成を約束する契約であり、発注者が受注者の作業者に直接指示を出す関係ではありません。ここを崩すと別の問題が生じますが、詳細は当社の別記事に譲ります。手元の契約書に、完成の定義は書かれていますか。

よくある質問

請負契約について、実務でよく届く質問に答えます。いずれも契約書を前にした担当者から繰り返し聞かれる内容です。法的な判断が必要な場面については、一般的な整理にとどめ、専門家への確認をお勧めしています。

Q1. 請負契約書に収入印紙は必要ですか

請負に関する契約書は印紙税法上の課税文書に当たり、記載金額に応じた印紙が必要とされています。電子契約では課税文書の作成に当たらないとされるのが一般的な理解ですが、判断は税務の専門家にご確認ください。

Q2. 契約書の表題を「業務委託契約書」にしても請負になりますか

なります。民法632条は契約の表題ではなく、「ある仕事を完成することを約し」「その仕事の結果に対してその報酬を支払うことを約する」という当事者の約束の内容を要件としています。仕事の完成とその結果に対する報酬を約束する内容であれば、この要件に当てはまります。

Q3. 請負で発注した場合、受注者が別の会社に作らせてもよいのですか

民法は請負について再委託の可否を直接定めていません(632条から642条までに再委託の規定はありません)。可否と条件は契約書で決めることになります。再委託を制限したい場合は契約書に明記してください。承諾の方式には複数の選択肢があります。

Q4. 契約不適合責任の期間はどのくらいが一般的ですか

民法637条1項は「前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない」と定めています。この期間は契約で変えられるため、手元の契約書に何か月と書かれているかを確認してください。期間より、何が不適合かを判断する基準(完成の定義と検収基準)が先に決まっていることのほうが実務では効きます。

Q5. 瑕疵担保責任と契約不適合責任は何が違うのですか

2020年4月施行の改正民法で、請負の担保責任は契約不適合責任という枠組みに整理されました。旧法にあった請負人の担保責任の規定は削除され、現在の635条は「削除」と表示されています(2026-09-19にe-Gov法令検索で確認)。実務上の違いとして分かりやすいのは、使える手段が履行の追完・報酬の減額・損害賠償・解除の4つとして条文上に並び、追完を先に求めるという順番が明確になった点です。

Q6. 検収書を出さないまま本番で使い始めてしまいました。どうなりますか

契約書にみなし検収の条項があれば、検査期間の経過によって合格として扱われることになります。条項がない場合、検収は形式上は未了ですが、本番で使っているという事実は発注者に有利には働きにくいと考えてください。あわせて、契約不適合責任の起算点を検収完了に置いている契約書では、責任期間の始まりも確定しません。気づいた時点で、検査の記録と残課題の一覧を書面で共有しておくのが現実的です。

Q7. 契約書を交わしていなくても請負契約は成立しますか

成立し得ます。民法522条2項は、契約の成立には法令に特別の定めがある場合を除いて書面等の方式を要しないと定めています。ただし、書面がないと「何を完成させる約束だったのか」を後から示せません。契約書は契約を成立させるためではなく、約束の中身を確認できるようにするための文書です。

Q8. 発注者の都合で途中でやめた場合、支払いはどうなりますか

民法641条により、発注者は仕事が完成しない間はいつでも解除できますが、損害の賠償が必要です。あわせて634条2号により、完成前に解除されたときは、既にできている可分な部分の給付によって発注者が利益を受けるなら、その割合に応じた報酬の請求が認められます。金額は交渉になるため、契約時に中断時の精算方法を決めておくほうが早く済みます。手続きの全体像は「業務委託契約の解除」の記事をご覧ください。

Q9. 御社は請負で受けてもらえますか

当社が提供しているのはラボ型開発(準委任)です。仕様が確定していて請負のほうが適していると判断した場合は、その旨を率直にお伝えします。最小構成は日本人PM+2〜3人月で月額約80万円から、1名・最短2週間で開始。まずは要件の共有から。

まとめ: 請負は「完成」の約束——確認するのは完成の定義・検収の基準・責任の期間

請負契約とは、仕事を完成させることを約束し、その結果に対して報酬を払う契約です(民法632条)。約束の対象が「完成」であることから、実務の論点はすべて導かれます。報酬は原則として目的物の引渡しと同時に支払われ(633条)、完成しなかった場合でも、注文者が受ける利益の割合に応じた報酬請求が認められることがあります(634条)。「完成しなければ報酬はゼロ」という理解は正確ではありません。この一点を知っているだけで、途中終了時の話し合いは利益の割合という土俵に乗ります。

引渡し後の不具合は契約不適合責任の問題になり、不適合を知った時から1年以内の通知が必要とされています(637条)。ただし注文者の指図によって生じた不適合には例外があります(636条)。責任の期間は契約で変更できるため、契約書の記載を確認してください。途中でやめる場合、注文者は仕事が完成しない間であれば損害を賠償して解除できます(641条)。受注者側から同じように解除できる規定はありません。

請負を選ぶかどうかの判断軸はひとつで、仕様が動くかどうかです。契約時に仕様が確定していて、成果物を文書で特定でき、変更がほとんど入らない見込みなら請負が向きます。作りながら決める、優先順位が毎月動くという性格の案件では、変更のたびに手続きが必要になり実態に追いつきません。そして契約書で見るのは3箇所です。完成の定義(別紙に納入物・形式・時期)、検収の基準と期間、契約不適合責任の期間と範囲。この3つが埋まっていれば、表題が業務委託契約書であっても実務で機能します。準委任との使い分けは準委任と請負の違い、契約書の条項の直し方は業務委託契約書のひな形と埋め方もあわせてご覧ください。なお、この記事は法的助言ではありません。個別の判断は弁護士にご確認ください。当社が提供しているのはラボ型開発(準委任)で、最小構成は日本人PM+2〜3人月の月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、契約形態の考え方を含めてお答えします。請負のほうが適していると判断した場合は、その旨も率直にお伝えします。