請負と準委任の違いは見積書のどこに出るか｜発注側の確認項目

システム開発の見積書を並べて、片方は「開発一式 1,800万円」、もう片方は「月額240万円 × 8か月」と書かれている。準委任と請負の違いは何となく知っているけれど、この2枚をどう比べればいいのかが分からない——この記事は、契約形態そのものの解説ではなく、契約形態によって見積書のどの欄を見るかがどう変わるかを整理した実務ガイドです。

この記事の結論｜違いは「完成を約束したか」、見積書では「検収欄があるか」に出る

先に結論を書きます。

請負と準委任の違いは、突き詰めると「仕事の完成を約束したかどうか」の1点です。 そして、その1点が見積書に現れる場所は決まっています。請負なら検収条件と納品物の欄、準委任なら作業報告と精算方法の欄です。ここが空欄の見積書は、契約形態にかかわらず、後から揉める余地を残しています。

もう少し具体的に言うと、こうなります。

• 請負の見積書で見るべきは「何をもって終わりとするか」。総額が固定されていても、完成の基準が書かれていなければ、検収の場で「これで完成です」「まだです」の解釈差が表面化します。
• 準委任の見積書で見るべきは「何に時間を使ったと報告されるか」。月額が決まっていても、報告の頻度と粒度が書かれていなければ、支払った対価が何に使われたかを後から検証できません。

「請負のほうが安全」「準委任のほうが柔軟」という一般論は、この2つの欄が埋まっていて初めて成り立ちます。埋まっていなければ、どちらの形態でも同じように損をします。

契約形態が分かったら、見積書を4つの状態に仕分ける

契約形態を確認するのは、良し悪しを判定するためではありません。次にベンダーへ何を聞くかを決めるためです。手元の見積書を、次の4状態のどれかに割り当ててください。

「高リスク」と「判断不能」は、対処がまったく違います。高リスクは書き方の問題なので、分けて書き直してもらえば解消します。判断不能はプロジェクトの成熟度の問題なので、書式を直しても解決しません。この記事は最後にこの4状態へ戻ってきます。

この記事で扱わないこと

金額の相場は扱いません。工程別・規模別の費用構造はシステム開発の費用相場と見積もり妥当性の判断にまとめています。複数社の見積もりを同じ条件へそろえて並べる手順は開発会社の見積もり比較ガイド、1枚の見積書にある「一式」を工程・成果物・工数へ分ける手順は見積書の「一式」を分解する方法が担当です。

また、本記事は開発フェーズの契約を扱います。稼働後の月額保守で準委任が使われる場合の評価軸は月額固定の保守費用は何に対する対価かを参照してください。開発中は「作るもの」を、稼働後は「維持する状態」を買っているため、同じ準委任でも見る欄が変わります。

本記事は法令の一般的な整理であり、個別案件についての法的助言ではありません。契約条項の適否は弁護士へ、税務の取扱いは税理士または所轄税務署へご確認ください。

民法が決めているのは3点だけ。残りは見積書と契約書で埋める

契約形態の解説記事は数多くありますが、発注判断に必要なのは「民法がどこまで決めていて、どこから先は自分で決めなければならないか」の線引きです。ここを外すと、「請負だから法律が守ってくれる」という誤解が生まれます。

1. 何を約束したか

請負は、民法第632条で次のように定義されています。

請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。

一方、準委任は独立した節を持たず、第656条が「この節の規定は、法律行為でない事務の委託について準用する」として委任の節（第643条〜第655条）を準用する形をとっています。委任そのものは第643条で「当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる」と定義され、受任者の義務は第644条にこう書かれています。

受任者は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う。

つまり、請負は「完成」を、準委任は「注意深く事務を処理すること」を約束している。これが唯一にして最大の違いです。準委任は成果物を出さない契約ではなく、成果物が出なかったこと自体を債務不履行としない契約です。

もう1点、報告義務に非対称があります。委任には第645条があり、「委任者の請求があるときは、いつでも委任事務の処理の状況を報告し、委任が終了した後は、遅滞なくその経過及び結果を報告しなければならない」と定めています。これに対して、請負の節（第632条〜第642条）には報告義務を定めた条文がありません。請負で進捗報告を受けたいなら、契約書か見積書に自分で書き込む必要があります。

2. いつ・いくら払うか

支払時期の規定も分かれています。

• 請負: 「報酬は、仕事の目的物の引渡しと同時に、支払わなければならない」（第633条）。前払いが原則ではない、という点が出発点です。
• 準委任（履行割合型）: 「報酬を受けるべき場合には、委任事務を履行した後でなければ、これを請求することができない。ただし、期間によって報酬を定めたときは、第六百二十四条第二項の規定を準用する」（第648条第2項）。第624条第2項は「期間によって定めた報酬は、その期間を経過した後に、請求することができる」と定めています。月末締めの月額請求が成り立つのは、この準用があるためです。
• 準委任（成果完成型）: 第648条の2が「委任事務の履行により得られる成果に対して報酬を支払うことを約した場合において、その成果が引渡しを要するときは、報酬は、その成果の引渡しと同時に、支払わなければならない」と定めています。

途中で終わった場合の扱いも、条文が用意されています。準委任では第648条第3項が、①委任者の責めに帰することができない事由によって委任事務の履行をすることができなくなったとき、②委任が履行の中途で終了したとき、の2つの場合に「既にした履行の割合に応じて報酬を請求することができる」と定めています。請負では第634条が、①注文者の責めに帰することができない事由によって仕事を完成することができなくなったとき、②請負が仕事の完成前に解除されたとき、の2つの場合について、「請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるとき」はその部分を仕事の完成とみなし、利益の割合に応じた報酬を請求できるとしています。

ここで発注側が押さえるべきは、請負の割合的報酬には「可分な部分」と「注文者が利益を受ける」という条件が付いているのに対し、履行割合型の準委任にはその条件がないという点です。履行割合型は、途中で止まっても、そこまでの履行割合分が支払対象になります（成果完成型では第648条の2第2項により第634条が準用されるので、請負と同じ条件がかかります）。

3. 出来上がりが違ったときにどうするか

請負では、売買の規定が有償契約へ準用され（第559条）、引き渡されたものが種類・品質・数量について契約の内容に適合しないときは、追完請求（第562条）、報酬（代金）減額請求（第563条）、損害賠償請求と解除（第564条）ができます。ただし請負固有の制限が2つあります。

• 第636条: 注文者が供した材料の性質、または注文者が与えた指図によって生じた不適合は、原則としてこれらを請求できません（請負人がその材料または指図が不適当であることを知りながら告げなかったときを除く）。システム開発では、発注側が渡したデータや、発注側が出した仕様の指示がこれにあたります。「言われたとおりに作った」という反論が成り立つ場面がある、ということです。
• 第637条第1項: 注文者が不適合を知った時から1年以内に通知しないと、これらを請求できなくなります（引渡し時に請負人が不適合を知り、または重大な過失によって知らなかったときは適用されません＝第637条第2項）。

準委任には、これに対応する担保責任の規定がありません。成果完成型で準用されるのは、報酬に関する第634条だけです（第648条の2第2項）。「準委任だから品質を問えない」のではなく、「品質を問う根拠を契約で作らないと問えない」というのが正確な理解です。

民法の条文対比

ここまでを条文単位で並べるとこうなります。

条文の出典はe-Gov法令検索「民法（明治二十九年法律第八十九号）」（2026年8月18日取得）です。

「条文なし」が2つ並んでいる行に注目してください。検収です。 請負・準委任のどちらにも、民法上の規定がありません。「請負契約だから完成の基準は法律が守ってくれる」という理解は成り立ちません。

見積書に「請負」「準委任」とは書かれていない

実務でつまずくのはここです。契約書には契約形態が書かれますが、見積書の段階で「本見積もりは請負を前提とします」と明記されていることは多くありません。 契約書は最後に出てくるので、見積書を比較する時点では自分で読み取る必要があります。

手がかりは4か所

4か所のうち2か所以上が同じ方向を指していれば、その形態を前提にしていると考えて、ベンダーへ確認してください。混在している場合は要注意です。 たとえば単位が「人月」なのに支払条件が「検収完了後」になっている見積書は、準委任の見た目で請負の支払条件を課している可能性があり、どちらの前提で見積もったのかを必ず確認します。

請負型の見積書はこう書かれる

品名                          数量  単位      金額
──────────────────────────────────────────────
外部設計                        1   式    ○,○○○,○○○
内部設計・実装                  1   式    ○,○○○,○○○
システムテスト                  1   式    ○,○○○,○○○
──────────────────────────────────────────────
納品物：外部設計書、内部設計書、ソースコード一式、
        テスト仕様書、テスト結果報告書
支払条件：契約時30%、検収完了後70%

この形式で確認するのは金額ではなく、「検収完了後70%」の"検収"が何を指すかです。検査の基準になる文書（検査仕様書）は誰が作るのか、検査期間は何日か、不合格になったときはどうなるのか。ここが書かれていなければ、支払条件の70%は宙に浮いています。

準委任型の見積書はこう書かれる

品名                          数量  単位      金額
──────────────────────────────────────────────
シニアエンジニア               8   人月    ○,○○○,○○○
エンジニア                    16   人月    ○,○○○,○○○
プロジェクトマネージャー        4   人月    ○,○○○,○○○
──────────────────────────────────────────────
前提：標準稼働 月160時間／人
支払条件：毎月末締め、翌月末払い

この形式で確認するのは単価ではなく、「月160時間」の上下に何が起きるかです。140時間しか稼働しなかった月は減額されるのか、180時間を超えたら追加請求されるのか、そして何にその時間が使われたかをどう報告するのか。準委任では、この報告が対価の裏づけになります。

欄が空のまま契約すると、最後にこうなる

ここが本記事の中心です。左端は、経営者が最終的に直面する事態です。右へたどると、その原因になっている見積書の空欄が分かります。契約形態は、どの事態が起きやすいかを変えるだけで、空欄そのものを埋めてはくれません。

表の中列に当たる記載が手元の見積書になければ、その欄を追記した見積書を再発行してもらってください。口頭で説明を受けても、担当者が変われば残りません。なお、下2行（範囲外の追加見積もり／障害時の連絡先）は契約形態を問わず起きるので、どちらの形態でも確認が必要です。

経営判断として最も重いのは4行目です。準委任は「時間を買う契約」なので、成果が出ていないことは、それ自体では支払いを止める理由になりません。だからこそ、中止の条件と通知期限を見積書の前提条件欄に書かせておく必要があります。

公的なモデル契約書は、工程ごとに契約類型を選ぶ前提で作られている

「請負のほうが安全そうだから、全工程を請負でお願いしたい」という要望はよく出ます。しかし、公的なモデル契約書は工程ごとに契約類型を選ぶ前提で作られています。ここを知っているかどうかで、見積書の読み方が変わります。

参照するのは、IPA（独立行政法人情報処理推進機構）が公開している情報システム・モデル取引・契約書（第二版）です。第一版は経済産業省が2007年に公開したもので、第二版はIPAが2020年12月22日に公開しました（ページの最終更新日は2025年6月17日）。以下は「受託開発（一部企画を含む）、保守運用」の**ひな型（条文抜き出し版、最終更新2023年5月9日）**からの引用です。引用中の「甲」は発注側（ユーザ企業）、「乙」はベンダーを指します。

個別契約で決める12項目のうち、2番目が「契約類型」

このモデル契約は、基本契約を1本結んだうえで、工程ごとに個別契約を結ぶ構造をとっています。その個別契約で定める取引条件が第4条に列挙されており、条文はこう始まります。

甲及び乙は、個別業務に着手する前に、甲から乙に提示された提案依頼書（RFP）及び乙から甲に提案した提案書、見積書を基礎として、当該個別業務について以下の各号のうち必要となる取引条件を定め、個別契約を締結する。

続く各号は、①具体的作業内容（範囲、仕様等）、②契約類型（請負・準委任）、③作業期間又は納期、④作業スケジュール、⑤甲・乙の役割分担、⑥連絡協議会の運営に関する事項、⑦甲が乙に提供する情報・資料・機器・設備等、⑧作業環境、⑨納入物の明細及び納入場所、⑩委託料及びその支払方法、⑪検査又は確認に関する事項、⑫その他個別業務遂行に必要な事項——の12項目です（⑨の「納入物」は、本記事がここまで「納品物」と呼んできた欄にあたります）。条文が「以下の各号のうち必要となる取引条件を定め」と書いているとおり、12項目すべてが常に必要とされているわけではありません。

発注側にとって重要なのは2点です。

1. 契約類型は、個別契約ごとに決めるものとして2番目に置かれている。プロジェクト全体で1つに決めるものではない。
2. その個別契約の基礎になるのは、RFP・提案書・見積書である。見積書は契約類型を決めるための資料として明示的に位置づけられている。

「見積書に契約形態が書かれていないのはおかしいのでは」という確認は、この条文を根拠にできます。

外部設計はA案（準委任）とB案（請負）の選択

このひな型では、本件業務は4つの個別業務——要件定義作成支援業務、外部設計書作成支援業務、ソフトウェア開発業務、ソフトウェア運用準備・移行支援業務——の「全部又は一部」から構成されるとされています（第3条）。4つすべてを同じベンダーへ発注することが前提ではありません。

このうち外部設計の節には、条文群の選択肢が用意されています。

第2節においては、外部設計を準委任とする場合はA案（第19条乃至第23条）を、請負とする場合はB案の条文群を採用

A案（準委任）では、ベンダーは「甲による外部設計書作成作業を支援するサービス」を提供し、「善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行う」とされます。業務の終わり方も、業務終了報告書を出し、点検期間内に発注側が書面で異議を述べなければ終了を確認したものとみなされる、という形です（第23条）。B案（請負）を採ると、同じ外部設計が「外部設計書作成業務」となり、納入と点検・承認の枠組みに変わります。

つまり、同じ「外部設計 一式 ◯◯◯万円」という見積行でも、A案かB案かで発注側がやるべきことがまったく違います。 A案なら設計書を作るのは発注側で、ベンダーは支援する立場です。B案ならベンダーが作って納品します。見積金額だけを2社で比べても、この前提が違えば比較になりません。

システムテストは選択案1と2で所属が変わる

さらに分かりにくいのが、システムテストの扱いです。ソフトウェア開発業務の条文はこうなっています。

乙は、第25条所定の個別契約を締結の上、本件業務として前各節により確定したシステム仕様書に基づき、［【選択案１：システムテスト・準委任型】内部設計からシステム結合まで　【選択案２：システムテスト・請負型】　内部設計からシステムテストまで］のソフトウェア開発業務を行う。

選択案1ではシステムテストがソフトウェア運用準備・移行支援業務（準委任型の条文構成）の側に入り、選択案2ではソフトウェア開発業務（請負型の条文構成）の側に入ります。 内部設計からシステム結合まで、および導入・受入支援と運用テストの所属は、どちらの選択案でも変わりません。動くのはシステムテストだけです。

これが何を意味するか。選択案1なら、システムテストは発注側が主体で行い、ベンダーが支援する建て付けです。選択案2なら、ベンダーがシステムテストまで完成させて納品します。同じ「システムテスト」という言葉が、選択次第で請負側にも準委任側にも入るということです。

見積書に「システムテスト 一式」と書いてあるとき、それがどちらの意味なのかを確認しないまま契約すると、テストの主体が宙に浮きます。安く見える見積書が実は選択案1相当で、テスト要員を発注側が用意する前提だった、というのは実際に起こる行き違いです。

この資料の適用範囲

引用元のモデル契約書には、想定している取引の範囲が書かれています。IPAと経済産業省が公開した「第二版の公表にあたって」（2020年12月22日）には、第一版について次の記述があります。

第一版では情報の非対称性がありつつも企業同士の交渉力としては対等なユーザ・ベンダ間の契約であり、重要インフラ・企業基幹システムの受託開発を念頭に置いていた

これに対して追補版（パッケージ、SaaS/ASP活用、保守・運用）は「ITの専門知識を有しないユーザを業として情報サービスを提供するベンダ間の契約であって、必ずしも基幹システムのような大きいシステムの開発を想定していない」とされています。同資料は追補版について、主に中小企業が利用するという観点からより分かりやすくするための見直しが必要だという意見も出ていることから、中小企業向けとして適切なモデル取引・契約書の在り方を含めた検討が期待される、とも述べています。

したがって、数百万円規模のWebシステム開発に、このひな型の全条文をそのまま要求するのは過剰です。本記事で使うのは「工程ごとに契約類型を選ぶ」「見積書が個別契約の基礎になる」という考え方の部分で、これは規模を問わず成立します。なお、このモデル契約書はひな型であって法令ではありません。実際の契約書はベンダーごとに条文構成が異なります。また、IPAはアジャイル開発版のモデル契約書を2020年3月に別途公開しており、反復開発ではまた別の整理が必要です。

前工程と後工程の契約は、自動的には連動しない

上流を準委任、下流を請負にする多段階の発注は、いま見たとおり公的なモデル契約書も採用している一般的な形です。ただし、発注側が誤解しやすい点が1つあります。

前掲の「第二版の公表にあたって」は、システム開発の契約が問題になるケースを「同時並行的な履行によって達成されることが予定されていた複数の契約間で問題となるケース（『並列型』）」と「本モデル契約のような多段階契約における前工程の契約と後工程の契約との間で問題となるケース（『直列型』）」に分けたうえで、後者（②の直列型）について次の共通理解を得たと記しています。

また、②のケースにおいて、下流工程におけるトラブルで上流工程における個別契約を解除したり、当該個別契約に基づく委託料を損害として請求したものが認められているケースというのは、結局上流工程自体について債務不履行があると判断しているという、それが下流工程まで進んだあとに露見するということであって、下流工程の債務不履行で上流工程の契約に影響を及ぼしているといったものではないのではないか

同資料は、複数の個別契約の処理は「結局当該個別契約の関係や問題となった債務不履行次第」であるとして、条項で手当てするのではなく解説に整理を追記する方針をとった、と述べています。

発注側にとっての意味はこうです。実装工程で問題が起きても、それだけを理由に要件定義工程の支払いが戻ってくるとは限りません。 したがって、工程を分けて発注するときは、各工程の終わりに何が引き渡され、それが次工程で使える状態になっているかを、その工程の中で確認しておく必要があります。次工程に進んでから前工程の不備を清算しようとしても、簡単ではありません。

見積書が工程で分かれている場合は、次の表を自分で埋めてみてください。空欄が残る工程が、確認すべき工程です。

工程            契約形態   成果物   完了の確認方法   次工程へ進む判断基準
──────────────────────────────────────────────────────────────
要件定義
外部設計
内部設計・実装
システムテスト
導入・移行

どちらの形態が噛み合うかは、要件が確定しているかで決まる

上のワークシートで最初に埋まらないのが「契約形態」の列です。ここを何で決めるかを整理します。「準委任は曖昧だから避けるべき」という判断は誤りです。ベンダー側の提案が合理的である条件を整理します。

これに加えて、工程ごとに上の3つを組み合わせるのが、上流は不確実・下流は確定というプロジェクト形状には最も噛み合います。見積書では、工程ごとに単位（式／人月）が切り替わっている形で現れます。

要件定義を準委任にすること自体は、公的なモデル契約書もそう組んでいるとおり一般的です。IPAと経済産業省が2019年12月に公開した検討資料「～情報システム・モデル取引・契約書～ 第一版及び追補版 DX推進のための見直しにおける民法改正を踏まえた整理にあたって」は、モデル契約書について「現行の第一版において準委任契約と位置付けられている要件定義作成支援業務や外部設計書作成支援業務等」と明記しています。「要件定義まで請負でやってほしい」という要望は、実は難しい注文でもあります。要件定義の成果物は発注側の意思決定の結果であり、発注側が何を決めるかをベンダーが完成責任として引き受けるのは無理があるからです。前掲のモデル契約書が要件定義を「甲による要件定義書の作成作業を支援するサービス」と定義しているのは、この構造を反映しています。

なお、成果完成型準委任について「公的なモデル契約書が推奨している」と説明されることがありますが、前掲の検討資料は逆の整理をしています。同資料は「今回の改正で新たに設けられた成果報酬型準委任についても、モデル契約が想定している取引においては成果報酬型がなじむものは少ないように思われる」としたうえで、「特段モデル契約の条項として言及しないこととした」と記述しています（引用元は「成果報酬型」と表記していますが、民法第648条の2の成果完成型と同じものを指します）。成果完成型は民法上の選択肢として使えますが、モデル契約書の推奨形ではありません。

準委任で最も抜けるのは「履行の割合」の定義

準委任の見積書で、金額の次に重要なのが途中で止めたときにいくら払うかです。ここは民法に規定があるのに、実務では見積書に書かれないまま契約されます。

前述のとおり、民法第648条第3項は「既にした履行の割合に応じて報酬を請求することができる」と定めています。問題は、その「割合」をどう測るかを法律が決めていないことです。

この点について、前掲のIPA・経済産業省の検討資料は、検討過程での指摘としてこう記しています。

また、報酬請求権の額を決める基準である「履行の割合」についても、「全体の期間に占める中途終了時までの期間の割合」なのか、あるいは「人月」なのか、など様々なバリエーションが考えられることが指摘されている。

同資料は、モデル契約の対応として「中途解除における委託料の清算に関する条項を置かないこととし、改正後民法の規律又は個別の合意に委ねることとした」と述べ、さらにこう結んでいます。

どのように委託料を決めていくのか、中途解約の場合にどのように精算するのか（例えば、履行割合型準委任で中途解除する場合に、期間で区切るのか、人月で積算して支払委託料を決めるのか等）を当事者間でよく協議して決めることが望ましい

公的なモデル契約書ですら「当事者で決めてください」としている項目です。したがって、準委任の見積書で確認すべきは次の3点になります。

1. 精算単位：中止時の精算は、経過期間で按分するのか、実投入人月で積算するのか
2. 稼働の下限・上限：月◯時間を下回った場合の減額、上回った場合の単価
3. 通知期限：何日前に通知すれば、次月分の支払義務が発生しないか

3点目は特に見落とされます。「いつでも解除できる」（第651条第1項）ことと、「解除すれば翌月分を払わなくてよい」ことは別です。同条第2項は、相手方に不利な時期に解除したときなど一定の場合に損害賠償を要するとしています（やむを得ない事由があったときを除く）。要員をアサインしている以上、通知期限は実務上の必須項目です。

もう1点、準委任で見積書に書かせるべきなのが作業報告の中身です。民法第645条は「委任者の請求があるとき」の報告義務を定めていますが、報告の頻度・粒度・様式までは決めていません。単価と稼働時間だけが書かれた見積書では、支払った金額の裏づけが手元に残りません。

ここで効いてくるのが、その報告が来期の予算根拠になるという点です。同じベンダーへ継続発注するか、体制を縮小するか、内製へ切り替えるかを判断するとき、材料になるのは「何にどれだけ時間がかかったか」の記録だけです。報告書に何を書くかを見積書の前提条件欄で決めておくと、契約期間中の検証と、次の意思決定の両方が回ります。

請負で最も抜けるのは「検収しなかったら合格」の期限

請負で見落とされるのは、検収の期限です。以下、発注側が受け入れる行為を「検収」、その手続きを定めるひな型の条文用語を「検査」と書き分けます。IPAモデル契約書のひな型は、検収についてこう定めています（第28条第3項）。

検査合格書が交付されない場合であっても、検査期間内に甲が書面で具体的な理由を明示して異議を述べない場合は、本件ソフトウェアは、本条所定の検査に合格したものとみなされる。

発注側が何もしなければ、期間の経過だけで合格になります。 これは不公正な条項ではなく、検収が止まるとベンダーの報酬請求権が宙に浮くため、期限を切るのは合理的な設計です。ただし発注側から見れば、検査期間が見積書・契約書に書かれていない、あるいは短すぎる場合、実質的に検収できないまま合格することを意味します。

同じひな型では、検査の基準になる検査仕様書は発注側（甲）が作成する建て付けになっています（第27条第1項、乙と協議のうえ作成）。作成を支援してもらう場合は、ソフトウェア開発業務の個別契約を締結するときまでに申し込み、検査仕様書作成支援業務として別途個別契約を締結できるとされています（同条第3項）。つまり検査仕様書の作成支援は、見積書に載る可能性のある独立した費目です。見積書にこの項目がなく、社内にテスト設計ができる人がいないなら、検収は形だけになります。

契約不適合責任の期間も、ひな型では空欄（〇ヶ月／〇年）のままです（第29条第5項）。民法第637条第1項は「不適合を知った時から1年以内の通知」を定めていますが、これは権利行使のための通知期限であって、無償で直してもらえる期間そのものを定めた規定ではありません。無償対応の期間は契約で決めます。

請負の見積書で確認する3点は次のとおりです。

1. 検査期間は何日か。社内の受入テスト体制で消化できる長さか
2. 検査仕様書は誰が作るか。発注側が作る前提なら、その工数は社内コストとして予算に乗るか
3. 検収後の無償修正期間は何か月か。有償対応との境界はどこか

3点目は追加費用の主要な発生源です。仕様変更と不具合修正の境界をどこに引くかを決めないまま検収を迎えると、稼働直後の修正依頼がすべて有償の追加見積もりになります。契約前に書面で確認してください。

見積書を見て手を止めるべき5パターン

冒頭で示した4状態のうち、要確認・高リスク・判断不能に落ちるパターンを挙げます。

1. 請負なのに検収の基準がない（高リスク）

支払条件に「検収完了後」と書かれているのに、その検収が何を指すかがどこにも書かれていない状態です。前章の3点（検査期間・検査仕様書の作成者・無償修正期間）を契約前に埋めてください。

2. 準委任なのに成果物が約束されている（要確認）

「準委任契約」と明記されているのに、納品物欄に設計書やソースコードが列挙されている見積書です。これは成果完成型のつもりなのか、履行割合型で参考資料として出すつもりなのかで意味が正反対になります。前者なら成果の引渡しと支払いが結び付き、後者なら成果物が出なくても報酬は発生します。どちらかを書面で確認してください。

3. 工程で形態が変わるのに、1行の総額しかない（高リスク）

「システム開発一式」で総額だけが提示され、工程ごとの契約形態が読み取れない見積書です。工程単位に分けた見積書を出してもらってください。分け方の手順は見積書の「一式」を分解する方法で詳しく扱っています。

4. 再委託の記載がない（要確認）

見積書の体制表に、社名の書かれていない要員や「パートナー」表記がある状態です。条文対比表のとおり、準委任で再委託が行われるなら原則として発注側の許諾が必要（民法第644条の2第1項）で、請負にはその制限がありません。前掲のIPAモデル契約書のひな型も、再委託について「事前承諾を設ける場合はA案、再委託先の選定について原則としてベンダの裁量とする場合はB案」という2案を用意しています。どちらの立て付けかを確認してください。

5. 契約形態を決める材料が、そもそも揃っていない（判断不能）

これが最も見落とされます。要件が固まっていないのに「請負でお願いします」と発注側から求めた結果、ベンダーがリスク分を上乗せした総額を出してくる——このとき問題なのは形態の選択ではなく、完成の定義を誰も書けない状態でプロジェクトを進めていることです。

見分け方は単純で、発注側が「何ができたら成功か」を3行で書けるかです。書けないなら、契約形態を議論しても答えは出ません。この場合の打ち手は、形態の交渉ではなく要件を固める工程を分離して発注することです。前掲のモデル契約書が要件定義作成支援業務を独立した個別業務に置いているのは、まさにこの段階を切り出すためです。

判断不能を高リスクと取り違えると、答えの出ない質問をベンダーへ投げ続けることになります。逆に、要件が固まっていないことを自覚したうえで小さく分けて発注できれば、それは失敗ではなく正常な進め方です。

常駐・オンサイトのときは、契約形態より「指示系統」が先に効く

見積書に「客先常駐」「オンサイト対応」「貴社オフィスにて作業」と書かれていて、かつ発注側の担当者が日々の作業指示を出す想定になっている場合、偽装請負に該当するおそれがあります。これは契約形態を選ぶ話ではなく、法令に関わる話です。

厚生労働省は「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号、最終改正 平成24年厚生労働省告示第518号。通称37号告示）を定めています。同告示第2条は、請負の形式による契約で自己の雇用する労働者を業務に従事させる事業主であっても、第1号（労働者の労働力を自ら直接利用すること）と第2号（請け負った業務を自己の業務として独立して処理すること）のいずれにも該当する場合を除き、労働者派遣事業を行う事業主とする、と定めています。

そして、これが準委任にも及ぶことは、厚生労働省の疑義応答集（第3集）Q1が述べています。

この点において、委任（民法643条）、準委任（民法656条）も同様であり、アジャイル型開発（※２）が準委任契約を締結して行われる場合でも、実態として、発注者と受注者側の労働者との間に指揮命令関係がある場合には、その契約の形式を問わず、労働者派遣事業に該当し、労働者派遣法の適用を受けます。

同集Q1〜Q7はアジャイル型開発を題材にした問答ですが、Q8は「Ｑ１～７の考え方は、アジャイル型開発以外のシステム開発を請負業務とする場合についても当てはまりますか」という問いに対し、「アジャイル型開発以外のシステム開発を請負業務とする場合についても当てはまります」と回答しています。

同集は、密な連携そのものを問題視しているわけではありません。Q2への回答は、密に連携し助言・提案を行っていたとしても「実態として、発注者と受注者の関係者が対等な関係の下で協働し、受注者側の開発担当者が自律的に判断して開発業務を行っていると認められる場合であれば、偽装請負と判断されるものではありません」としたうえで、こう続けています。

他方で、実態として、発注者側の開発責任者や開発担当者が受注者側の開発担当者に対し、直接、業務の遂行方法や労働時間等に関する指示を行うなど、指揮命令があると認められるような場合には、偽装請負と判断されることになります。

発注側として見積書の段階で確認するのは、指示系統がどう設計されているかです。受注者側に管理責任者が置かれているか、作業指示は発注側からベンダーの管理責任者へ渡る建て付けか、その体制にかかる費用が見積書に計上されているか。「常駐だから安い」という見積書は、この体制費用を落としている可能性があります。

出典は厚生労働省「『労働者派遣事業と請負により行われる事業との区分に関する基準』（37号告示）に関する疑義応答集（第3集）」（2026年8月18日取得。同省の掲載ページには令和8年5月25日更新・Q8追加と記載されています。文書内に発行年月日の記載はありません）。

契約形態を口実に抜けやすい費目

見積もりの問題は「高すぎる」だけではありません。契約形態を理由に費目が抜けている見積書は、安く見えて、あとから発注側のコストとして現れます。形態別に、抜けやすい費目を挙げます。次章の確認質問は、この一覧に対応させて作ってあります。

請負の見積書で抜けやすいもの

• 受入テストの支援：ベンダーのテストは含まれていても、発注側の受入テストを支援する工数が入っていない。検査仕様書を発注側が作る建て付けなら、その作業は社内コストとして発生します
• データ移行：本番データの変換・リハーサル・照合が「対象外」に入っている
• 移行後の初期障害対応：検収完了で契約が終わり、稼働直後のトラブル対応の担当が決まっていない
• プロジェクト管理：総額に溶けていて、誰がどの期間、何を管理するかが分からない

準委任の見積書で抜けやすいもの

• 報告・ドキュメント作成の工数：稼働時間はすべて実装に充てる前提で、週報や設計ドキュメントの作成時間が見込まれていない
• 引き継ぎ：契約終了時に、次の担当者やベンダーへ引き継ぐ工数が入っていない
• 品質の作り込み：レビュー、テストコード、リファクタリングが「稼働時間内でできる範囲」となっていて、水準が定義されていない
• 管理責任者の稼働：常駐案件で、前章の指示系統を成立させるための管理責任者の工数が計上されていない

印紙代も、契約書の書き方で変わる小さな実費です。国税庁のタックスアンサー「No.7102 請負に関する契約書」（令和7年4月1日現在法令等）によれば、請負についての契約書は第2号文書に該当し、契約金額に応じた印紙税がかかります。ただし同ページは「印紙税は、契約書に記載された内容により取扱いが異なりますのでご注意ください」と注記しており、契約書の名称ではなく記載内容で判断されるため、「準委任契約書だから不課税」と一律に言うことはできません。国税庁のタックスアンサーには準委任契約書という区分の記載がなく、本記事では扱いを断定しません。なお、基本契約＋個別契約の構造をとる場合、基本契約が第7号文書「継続的取引の基本となる契約書」（1通につき4,000円。契約期間が3か月以内かつ更新の定めのないものを除く）に該当することもあります。確認するのは金額の大小ではなく、見積書に印紙代が計上されているか、どちらが負担するかです。

いずれも、契約形態そのものが原因ではなく、契約形態を境界の言い訳に使えてしまうことが原因です。「請負の対象外です」「準委任の稼働時間内に収まりませんでした」という説明は、事前に範囲を書いていれば起きません。

ベンダーへそのまま送れる確認質問8つ

以下はコピーしてそのまま送れる文面です。「金額を疑っている」ではなく「社内稟議と契約書の別紙に必要」という立て付けにすると、通常の商習慣の範囲に収まります。

お見積もりありがとうございます。契約形態の前提を社内で確認したく、
以下について書面でご回答いただけますでしょうか。

1. 本見積もりは、請負・準委任（履行割合型／成果完成型）のいずれを前提と
   していますか。工程によって異なる場合は、工程ごとにお教えください。

2. 請負を前提とする工程について、検収の合格基準、検査期間（日数）、
   不合格となった場合の扱いを、見積書の前提条件欄へご記載ください。
   検査仕様書はどちらが作成する想定か、貴社に作成支援を依頼する場合の
   費用が本見積もりに含まれるかも併せてお願いします。

3. 検収後に無償で修正いただける期間は何か月でしょうか。仕様変更と
   不具合修正の境界を、どこで線引きされているかもお教えください。

4. 準委任を前提とする工程について、稼働時間の下限・上限、上限を超えた
   場合の単価、下回った月の精算方法をお教えください。

5. 作業報告はどの頻度で、どのような項目をご記載いただけますか。担当者
   ごとの作業内容と時間、その期間に完了したこと、次の期間に着手すること
   が分かる粒度を想定しています。あわせて、報告書や設計ドキュメントの
   作成時間が、ご提示の稼働時間に含まれる前提かどうかもお教えください。

6. 契約を中途で終了する場合、精算はどのように行われますか。経過期間で
   按分するのか、実投入人月で積算するのか、また何日前の通知が必要ですか。

7. 納品物として引き渡されるドキュメント（設計書、テスト仕様書、テスト
   結果報告書、運用手順書など）を、形式と版数を含めてご列挙ください。
   契約終了時の引き継ぎ作業は本見積もりに含まれますか。

8. 常駐・オンサイトでの作業がある場合、貴社側の管理責任者はどなたで、
   弊社からの作業依頼はどの経路でお渡しすればよいでしょうか。その体制に
   かかる費用が本見積もりに含まれるかもお教えください。

なお、次の項目については、本見積もりの対象内・対象外のどちらかを明示して
いただけると助かります。
  ・受入テストの支援
  ・データ移行（変換・リハーサル・照合）
  ・稼働直後の初期障害対応
  ・プロジェクト管理
  ・コードレビュー、テストコードの作成、リファクタリング
    （稼働時間内でできる範囲、という扱いになっていないか）
  ・契約書に貼付する収入印紙の費用と、その負担者

お手数をおかけしますが、契約書の別紙として添付したく、書面でのご回答を
お願いいたします。

回答が返ってきたら、金額ではなく空欄が埋まったかどうかで評価してください。すぐに埋まるなら、見積書の表記が要約されていただけです。埋まらない項目が残る場合、その項目はベンダー側でもまだ決まっていない可能性があります。後者のほうが、発注判断にとっては重い情報です。

根拠資料と適用条件

本記事で引用した資料と、その適用条件をまとめます。

本記事では、価格相場や人月単価に関する数値は扱っていません。契約形態と金額水準は別の論点であり、同じ形態でも金額は案件ごとに大きく変わります。

見積書の要件・契約範囲をレビューする

上の質問への回答が返ってきたあと、対象範囲・納品物・検収条件・再委託といった記載が実際に埋まっているかを1枚ずつ照合するのは手間がかかります。koromoでは、受け取った見積書のテキストから、要件と契約範囲の記載を確認できる要件・契約範囲チェック（登録不要）を公開しています。登録不要で、結果を見るまでメールアドレスの入力も必要ありません。テキストの抽出はブラウザ内で行い、送信前に内容を確認できます。

契約形態そのものを判定するツールではなく、契約形態が決まったあとに埋まっているべき欄の抜けを洗い出す用途です。診断結果は法的・会計的・技術的な最終判断ではなく、ベンダーへ次に何を聞くかを整理するためのものです。提示された契約形態のまま進めるのが合理的、という結論になることもあります。

よくある質問

まとめ

準委任と請負の違いは、法律の言葉としては「仕事の完成を約束したかどうか」の1点です。しかし発注側にとって意味があるのは、その1点が見積書のどの欄を読むかを変えるということです。

手順をもう一度整理します。

1. 見積書の4か所（単位・納品物・支払条件・前提条件）から契約形態を読み取る
2. 読み取れたら、請負なら検収条件、準委任なら作業報告と精算方法の欄を確認する
3. 工程で形態が変わる場合は、工程ごとに同じ確認を行う。前工程と後工程の契約は自動的には連動しない
4. 常駐がある場合は、指示系統と管理責任者の体制費用を確認する
5. 回答を説明済み／要確認／高リスク／判断不能の4状態に仕分ける
6. 判断不能なら、契約形態の議論を止めて要件を固める工程の分離発注を検討する

最後に、この記事で一番伝えたいことを繰り返します。検収の基準にも、報告の頻度にも、中途解約の精算方法にも、民法の条文はありません。 公的なモデル契約書ですら、これらを「当事者間でよく協議して決めることが望ましい」としています。契約形態を選ぶことは、リスクの分け方を決めることであって、確認を省略できる根拠にはなりません。空欄を埋める作業は、値引き交渉よりも先に来ます。