「準委任契約なので、完成の責任は負いません」
ベンダーからそう説明されて、不安になった経験はないでしょうか。お金を払うのに完成させてもらえないのか、と。
ネットで「準委任契約 請負契約 違い」を調べると、たいてい次の1行が出てきます。
請負は仕事の完成義務がある。準委任は完成義務がなく、善管注意義務を負う。
これは条文上、正しい説明です。ただ、この1行だけで契約類型を選ぶと、次の3つの落とし穴に落ちます。
- 「準委任なら、ベンダーは何の責任も負わない」と思ってしまう（誤りです）
- 契約書の表題を見て安心してしまう（実際の責任範囲は、その下の条項で上書きされています）
- 契約書が準委任でも、進め方しだいで違法になることを知らない（2026年5月、厚生労働省がこの適用範囲を明示しました）
この記事では、開発を受注する側——実際に契約書を交わし、現場でエンジニアを動かす立場から、①民法上の違い、②工程別の使い分けとその前提、③契約書で必ず見る5条項、④偽装請負にならない進め方、を解説します。
民法上の違いは4つ
まず条文を確認します。請負は民法632条です。
第632条（請負）
請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
一方、準委任は656条です。
第656条（準委任）
この節の規定は、法律行為でない事務の委託について準用する。
システム開発は「法律行為でない事務」にあたるため、委任ではなく準委任になります。そして656条が呼び込む委任の規定に、次の条文があります。
第644条（受任者の注意義務）
受任者は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う。
632条には「完成」という言葉があり、644条にはありません。ここが違いの出発点です。実務に効く差は、次の4点に集約されます。
| 請負契約 | 準委任契約 | |
|---|---|---|
| 何に対してお金を払うか | 仕事の完成（成果物） | 業務の遂行（専門家としての稼働） |
| ベンダーが負う義務 | 完成義務 | 善管注意義務（644条） |
| 成果物に不具合があったら | 契約不適合責任（追完・報酬減額・損害賠償・解除） | 契約不適合責任は負わない。ただし善管注意義務違反なら債務不履行責任 |
| 途中でやめるとき | 発注者からいつでも解除できる（641条・要損害賠償） | どちらからでもいつでも解除できる（651条1項） |
見落としがちな「解除」の非対称
4行目は、他の記事があまり書きません。
請負の場合、契約を途中で打ち切れるのは発注者側だけです。
第641条（注文者による契約の解除）
請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる。
これに対し準委任は、受注者側からも解除できます。
第651条（委任の解除）
1 委任は、各当事者がいつでもその解除をすることができる。
2 前項の規定により委任の解除をした者は、次に掲げる場合には、相手方の損害を賠償しなければならない。ただし、やむを得ない事由があったときは、この限りでない。
一 相手方に不利な時期に委任を解除したとき。（後略）
もちろん解除した側が損害賠償を負う場合はありますし、実務では契約書で予告期間（「3か月前までに書面で通知」など）を定めるのが普通です。それでも、準委任は「ベンダーが降りられる契約」であるという前提は、長期の常駐・ラボ型契約を結ぶ前に知っておいたほうがよい情報です。
「準委任＝完成しなくていい」ではない
冒頭の不安に答えます。
たしかに準委任では、ベンダーは仕事の完成義務を負いません。ただ、何の責任も負わないわけではありません。IPA（情報処理推進機構）と経済産業省が公開している『情報システム・モデル取引・契約書（第二版）』は、この点をはっきり書いています。
これに対して、準委任の場合、請負のような契約不適合責任を負うことはない。但し、事務処理に関して善管注意義務違反があった場合には、通常の債務不履行責任（例えば不完全な履行を完全なものにすることや損害賠償責任など）を負うこととなる
IPA『情報システム・モデル取引・契約書（第二版）』（2020年12月22日）
つまり準委任で問われるのは、「完成したか」ではなく「専門家として当然やるべきことをやったか」です。
わかりやすい例で言えば、こうなります。
- 要件定義の支援を準委任で受けたが、期日までに要件が固まらなかった → それ自体は必ずしもベンダーの責任にならない（決めるのは発注側だから）
- ベンダーが明らかな技術的リスクに気づいていながら報告しなかった、必要な検討を怠った、約束した体制を入れなかった → 善管注意義務違反として責任を問える可能性がある
「完成しなかったこと」ではなく「プロとしての仕事の質」が問われる、と理解してください。
第3の選択肢「成果完成型の準委任」
2020年4月に施行された改正民法で、準委任に選択肢が増えました。
第648条の2（成果等に対する報酬）
1 委任事務の履行により得られる成果に対して報酬を支払うことを約した場合において、その成果が引渡しを要するときは、報酬は、その成果の引渡しと同時に、支払わなければならない。
2 第634条の規定は、（略）準用する。
これにより準委任は、実務上2つに分かれます。
| 履行割合型（648条3項） | 成果完成型（648条の2） | |
|---|---|---|
| 報酬の基準 | 働いた時間・工数 | 定めた成果の引渡し |
| 典型例 | 月額◯◯万円 × ◯人月の常駐・ラボ型 | 「調査報告書の提出」で◯◯万円 |
| 中断したら | 既にした履行の割合に応じて請求できる | 可分な部分で発注者が利益を受けるなら、その割合で請求できる |
ここで、よくある誤解をひとつ潰しておきます。
「成果完成型の準委任＝実質的に請負と同じ」ではありません。
648条の2第2項が請負から準用しているのは、634条（割合に応じた報酬）だけです。契約不適合責任の規定は準用されていません。したがって成果完成型を選んでも、請負の契約不適合責任が自動的に付いてくるわけではない、というのが条文上の帰結です。成果物の品質保証をベンダーに求めたいなら、契約書にその条項を書く必要があります。
工程別の使い分け——ただし「前提」に注意
IPA『情報システム・モデル取引・契約書（第二版）』は、工程ごとの契約類型のモデルを示しています。原文どおりに引用します。
| 段階 | 工程 | 契約類型 |
|---|---|---|
| 企画段階 | システム化の方向性 | 準委任 |
| 企画段階 | システム化計画 | 準委任 |
| 企画段階 | 要件定義 | 準委任 |
| 開発段階 | システム設計（システム外部設計） | 準委任・請負 |
| 開発段階 | システム方式設計（システム内部設計） | 請負 |
| 開発段階 | ソフトウェア設計 | 請負 |
| 開発段階 | プログラミング | 請負 |
| 開発段階 | ソフトウェアテスト | 請負 |
| 開発段階 | システム結合 | 請負 |
| 開発段階 | システムテスト | 準委任・請負 |
| 開発段階 | 受入・導入支援 | 準委任 |
| 運用段階 | 運用テスト | 準委任 |
| 運用段階 | 運用 | 準委任・請負 |
| 保守段階 | 保守 | 準委任・請負 |
分け目は明快です。着手前に「作るもの」を特定できるなら請負、できないなら準委任。IPAはこう説明しています。
企画段階は、準委任契約とする。企画段階は、ユーザ側の業務要件が具体的に確定しておらず、ユーザ自身にとってもフェーズの開始時点では成果物が具体的に想定できないものであるから、ベンダにとっても成果物の内容を具体的に特定することは通常不可能である。そのため、仕事の完成を目的とし予め成果物の内容が具体的に特定できることを前提とする契約類型である請負には馴染みにくく、準委任が適切と考えられるからである。
この表をそのまま使ってはいけない理由
ここが重要です。多くの解説記事はこの表を貼って終わりますが、IPA自身が、この表の前提を明記しています。
・契約当事者：対等に交渉力のあるユーザ・ベンダを想定。
(例) 委託者（ユーザ）：民間大手企業、受託者（ベンダ）：情報サービス企業
・開発モデル：ウォーターフォールモデル。
・対象システム：重要インフラ・企業基幹システムの受託開発、保守・運用。同『第二版』「（7）パッケージ活用型、反復繰り返し型の開発、中小企業ユーザにおける活用の留意点」
さらに続けて、こう書かれています。
また、企業規模、ユーザのリテラシーの成熟度によって情報システムの導入形態、契約のあり方も異なってくるところがあると考えられる。
つまりこの表は、大手企業が基幹システムをウォーターフォールで作るときのモデルです。従業員数十名の会社が数百万円のシステムを入れるとき、企画・要件定義・外部設計・内部設計……と工程ごとに契約を分割していたら、契約事務のコストのほうが高くつきます。
中小規模の案件では、次のように2〜3本にまとめるのが現実的です。
┌─────────────────────────┐
第1契約 │ 要件定義（＋概算見積の精度上げ） │ 準委任
└─────────────────────────┘
↓ ここで金額と範囲を確定してから
┌─────────────────────────┐
第2契約 │ 設計 〜 実装 〜 テスト 〜 リリース │ 請負
└─────────────────────────┘
↓
┌─────────────────────────┐
第3契約 │ 運用・保守 │ 準委任（月額）
└─────────────────────────┘
第1契約を分けておく意味は大きいです。要件が固まっていない状態で全体を請負にすると、ベンダーはリスク分をバッファとして見積もりに乗せざるを得ません。要件定義を準委任で先に回し、作るものが特定できた時点で請負の金額を決めるほうが、結果として総額は下がりやすくなります。
実態としても、上流は自社でやっている
JUAS（日本情報システム・ユーザー協会）の『企業IT動向調査2026』（2026年4月公開・2025年度調査）は、工程ごとの内製／外部委託の割合を調べています。
「ほぼ内製」と「内製が多い」の合計値は、「システム企画（システム化構想策定）」で 70.9%、「機能要件定義」で 46.1% と高く、上流工程では外部委託よりも内製が主となっている。一方で、「設計・実装・テスト」では「ほぼ外部委託」と「外部委託が多い」の合計値が 63.4% と高く、ベンダーの力を活用している状況となっている。
IPAが「準委任が適切」とした上流工程は、実態としても自社主体。外注の主戦場は、IPAが【請負】に振った「設計・実装・テスト」の帯でした。工程別の使い分けは、机上の分類ではなく実務の分布とも合っています。
出典：JUAS『企業IT動向調査2026』図表7-2-3。同調査の対象は東証上場企業とそれに準じる企業（有効回答957社）で、中小企業だけを対象にした調査ではない点は割り引いて読む必要があります。
「請負にしておけば安心」ではない——民法636条
請負を選べば品質はベンダー持ち、と考えるのは早計です。次の条文があります。
第636条（請負人の担保責任の制限）
請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したときは、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。
システム開発に置き換えると、発注側が指定した仕様どおりに作った結果、業務に合わなかった——このケースは、原則としてベンダーの契約不適合責任にはなりません（ベンダーが不適当と知りながら黙っていた場合は別です）。
請負契約は「丸投げしても結果が出る仕組み」ではなく、発注側が渡した情報の質がそのまま結果に返ってくる仕組みです。
IPAも、契約類型の選び方に関連して踏み込んだ指摘をしています。
上記の違いに加え、契約類型が注目されるのは、請負型をとると、ユーザ側の心理として「丸投げ」「ベンダにすべてお任せ」という意識が強くなる場合があることが指摘された。（略）準委任型としなかった場合、ユーザ自身のシステム化計画や要件定義におけるステークホルダとの調整を行う責任等が曖昧になる傾向にある。その結果、ユーザの対応不足を補完するために、ベンダが、ユーザ内のステークホルダとのコンタクトを取り始め、さらにユーザの自律的な調整機能が発揮されずに、要件定義上の見落としも生じやすくなるとの指摘が多い。
契約類型の選択が、要件定義の精度にまで影響するという指摘です。発注前の準備については、RFP（提案依頼書）の書き方の記事も参照してください。
契約書で必ず見る5つの条項
ここまで民法の原則を見てきましたが、実務でいちばん大事なのは次の一文です。
・このように、請負と準委任には法律上の重要な相違点がある。但し、契約書において規定を設けることで、具体的な取引・契約プロセスに合致するように民法や商法の規定を修正することは原則として可能な場合が多い。
IPA『情報システム・モデル取引・契約書（第二版）』
民法の原則は、契約書の条項で上書きできます。だから「準委任か請負か」という表題だけを見ても、実際に負う責任はわかりません。表題より下を読む必要があります。最低限、次の5つを確認してください。
① 検収の基準と期間
何をもって「完了」とするか。検収期間内に発注者が何も言わなければ合格とみなす（みなし検収）条項が入っているのが一般的です。期間が10営業日なのか30日なのかで、社内の確認体制が変わります。
② 契約不適合責任の期間と起算点
民法の原則では、注文者が不適合を知った時から1年以内に通知すればよいことになっています（637条1項）。この起算点は主観的なので、IPAはこう説明しています。
当該契約不適合を注文者が認識しない限りは、消滅時効の一般規定に基づき、完成物の引渡し又は仕事の終了時から最大10年間は権利行使しうる状況となる（民法第166条第1項第2号）。
ただし実務の契約書では、この原則がほぼ必ず修正されています。IPAのモデル契約自体、起算点を客観的なものに変えています。
本モデル契約では、民法上のデフォルトルールにかかわらず、契約不適合責任の期間制限の起算点は外部設計書の確定時という客観的なものとした。
つまり「請負なら1年保証」と覚えるのではなく、契約書の該当条項が「検収完了から◯か月」になっているかを読むのが正解です。
③ 中途解除したときの精算
準委任なら「既にした履行の割合」（648条3項）、請負なら「可分な部分で発注者が利益を受ける割合」（634条）が民法の原則です。実際にいくら払うのかは、契約書の精算条項と、月次の作業報告の粒度で決まります。
④ 仕様変更（変更管理）の手続き
誰が変更を申し入れ、誰が影響を見積もり、誰が承認すると金額・納期が変わるのか。ここが空白の契約書は、揉めます。準委任・請負のどちらであっても必要です。
⑤ 体制と窓口（管理責任者）
受注者側の責任者は誰か。発注側からの指示・依頼をどこに投げるか。これは次の章の偽装請負に直結します。
契約書が準委任でも、進め方しだいで違法になる
ここからが、この記事でいちばんお伝えしたい部分です。
システム開発を準委任で発注し、エンジニアが自社に常駐したり、自社のSlackやチケット管理ツールに入って一緒に開発したりする——よくある形です。このとき注意すべきなのが偽装請負です。
偽装請負とは、契約の形式は請負・準委任なのに、実態としては発注者がベンダーの従業員に直接指揮命令をしている状態を指します。これは労働者派遣法に違反します。
判断の基準は「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号、通称「37号告示」）です。そして厚生労働省は、この告示についての疑義応答集（第3集）を公開しており、その全8問がまるごとシステム開発の話になっています。
2026年5月25日、適用範囲が明示された
第3集はもともと「アジャイル型開発と契約方式」という表題で、アジャイル開発を念頭に置いた文書でした。ところが2026年5月25日、厚生労働省はここにQ8を追加しました。
Q8 Q1〜7の考え方は、アジャイル型開発以外のシステム開発を請負業務とする場合についても当てはまりますか。
A8 アジャイル型開発以外のシステム開発を請負業務とする場合についても当てはまります。
たった2行の追加ですが、意味は小さくありません。第3集はQ1で「請負等（委任、準委任を含みます）」と定義したうえで議論しています。つまり、ウォーターフォールでも、常駐でも、保守運用でも、外部委託でシステムを開発するすべての現場に、この判断枠組みが当てはまることが明示された、ということです。
まず、契約書の形式では決まらない
Q1の回答が出発点です。
実態として、発注者と受注者側の労働者との間に指揮命令関係がある場合には、その契約の形式を問わず、労働者派遣事業に該当し、労働者派遣法の適用を受けます。
（略）契約形式ではなく、「労働者派遣事業と請負により行われる事業との区分に関する基準」（略）に基づき、実態に即して判断されるものです。
契約書に「準委任契約」と書いてあっても、守ってはくれません。
セーフとアウトの線引き
第3集は、具体的な場面ごとに判断を示しています。実務で迷いやすいところを表にまとめます。
| 場面 | それだけでは偽装請負にならない | 偽装請負と判断される |
|---|---|---|
| チーム運営 | 発注者と受注者が対等な関係で協働し、受注者側の担当者が自律的に判断して開発している | 発注者が受注者の担当者に直接、業務の遂行方法や労働時間の指示をする |
| 管理責任者 | 受注者の管理責任者が、すべての会議に同席していない | 進捗が遅れた際に、発注者が直接仕事の割り付け・順序・緩急の調整を指示する（管理責任者を選任していても違反） |
| 要件の説明 | 発注者の責任者が、要件の詳細説明や情報提供を開発担当者に直接行う | その説明・情報提供が、実態として遂行方法や労働時間の指示にあたる |
| 技術的な議論 | 対等な立場での技術的な議論・助言・提案 | 助言・提案が、実態として指揮命令にあたる |
| 会議・チャット | 双方の関係者全員が会議・メール・チャット・プロジェクト管理ツールに参加する | その場で発注者から受注者の担当者へ直接、遂行方法や労働時間の指示が飛ぶ |
| 要員の確認 | 個人を特定できない形でのスキルシート（技術レベル・経験年数等）の提出を求める | 特定の人を指名して従事させる／特定の人の就業を拒否する |
「全員が同じチャットにいてはいけない」「毎回、管理責任者を同席させなければいけない」といった思い込みは、いずれも第3集が明確に否定しています。分けるべきなのは場ではなく、やりとりの中身です。
境目はシンプルです。
発注者が伝えてよいこと 発注者が伝えてはいけないこと
─────────────── ────────────────
・何を作りたいか（要件・優先順位） ・誰が、どの順番で、どうやるか
・なぜそれが必要か（背景・業務） ・今日は何時まで作業するか
・仕様の詳細説明・情報提供 ・この作業をあなたがやってください
・技術的な助言・提案（対等な議論） ・遅れているから今夜中に終わらせて
・この人を外して／この人を入れて
右側が必要になったときは、受注者の管理責任者に伝えるのが正解です。第3集にもこう書かれています。
受注者側の開発担当者に対し、業務の遂行方法や労働時間等に関する指示を行うことが必要になった場合には、受注者側が管理責任者を選任するなどして受注者自らが指揮命令を行うなど、適正な請負等と判断されるような体制を確立しておくことが必要です。
仕様変更を伝えるときも同じです。疑義応答集（第1集）は、業務内容が変わった場合について「直接発注者から請負労働者に対して変更指示をすることは偽装請負にあたります」「一方、発注者から請負事業主に対して、変更に関する説明、指示等が行われていれば、特に問題はありません」としています。そしてこの考え方がシステム開発にも当てはまることは、厚生労働省の事務連絡（令和3年5月13日）で明確にされています。
発注前にやっておくこと
第3集は、予防策も具体的に書いています。
発注者側と受注者側の開発関係者のそれぞれの役割や権限、開発チーム内における業務の進め方等を予め明確にし、発注者と受注者の間で合意しておくこと
契約書とは別に、役割分担表を1枚作っておく。これだけで大半のリスクは下がります。誰が優先順位を決め、誰が実装方法を決め、誰が要員配置を決めるのか。準委任で人を確保する形の契約を結ぶなら、キックオフ前に握っておくべき紙です。
結局、どちらを選べばいいか
判断は3つの質問で足ります。
| 質問 | Yes | No |
|---|---|---|
| ① 着手前に「作るもの」を具体的に特定できるか | 請負を検討 | 準委任 |
| ② 開発中に仕様が変わる前提か | 準委任 | 請負を検討 |
| ③ 完成物の品質保証をベンダーに負わせたいか | 請負（または準委任＋品質条項） | 準委任 |
そのうえで、中小規模の案件では次を出発点にするのが現実的です。
- 要件定義：準委任。決めるのは発注側なので、ベンダーに完成義務を負わせられません。ここを請負にしたがるベンダーがいたら、何を成果物とするのか確認してください
- 設計〜実装〜テスト：請負。作るものが決まっているなら、金額と納期を確定できます
- 運用・保守：準委任（月額）。何が起きるか事前に特定できないため
- アジャイル開発・ラボ型・常駐：準委任。IPAもアジャイル開発版のモデル契約で準委任を前提としており、理由を「ベンダ企業が専門家として業務を遂行すること自体に対価を支払う」ことで柔軟に対応できるためと説明しています
よくある質問
Q. SES契約と準委任契約は、違うものですか？
SES（システムエンジニアリングサービス）は実務上の呼び方で、民法上の契約類型ではありません。中身としては準委任にあたることが多いですが、呼び方では決まりません。確認すべきは、契約書に完成義務が書かれているか、報酬が工数基準か成果基準か、そして実際に誰が指揮命令をしているかです。
Q. 準委任契約なのに「納品物」が定められています。おかしいですか？
おかしくありません。成果完成型の準委任（648条の2）であれば成果物を定めますし、履行割合型でも作業報告書や設計ドキュメントを提出物として定めるのは一般的です。確認すべきは「何をもって完了とするか」と、その提出物に品質の保証が付いているかどうかです。
Q. 途中で請負から準委任に変更できますか？
工程ごとに個別契約を分けていれば、自然にできます。IPAのモデル契約も、基本契約＋工程ごとの個別契約という多段階契約を前提にしています。逆に、全工程を1本の契約で締結していると、途中変更は契約の巻き直しになります。契約を分けておくこと自体が、変更に強い構造です。
Q. 準委任で頼んだのに、ほとんど成果が出ませんでした。何も請求できないのでしょうか？
そうとは限りません。善管注意義務（644条）に違反していれば、債務不履行責任を問える可能性があります。ただし判断材料が必要になるため、作業報告書・議事録・課題管理表を月次で受け取っておくことが実務上の備えになります。準委任契約では、この報告体制を契約書に書き込んでおくことをおすすめします。
Q. 発注側のエンジニアが、ベンダーのコードをレビューするのは問題ですか？
疑義応答集（第3集）Q5は、対等な関係での技術的な議論・助言・提案は、それだけで偽装請負と判断されるものではないとしています。一方で、その言動が実態として業務の遂行方法の指示にあたる場合は偽装請負と判断されるとも書かれています。「この実装は保守性に懸念があると考えます」と伝えるのと、「この書き方に直してください」と指示するのでは、位置づけが変わります。判断は実態に即して行われ、個別の事案は各都道府県労働局が判断します。
Q. 契約書が準委任なら、偽装請負のリスクはないのでは？
逆です。準委任・請負のどちらであっても、契約形式ではなく実態で判断されます（疑義応答集 第3集 Q1）。むしろ常駐や共同開発を伴う準委任のほうが、日常的に指示が飛びやすいぶん注意が必要です。
まとめ
- 民法上の違いは完成義務・契約不適合責任・報酬・中途解除の4点。特に準委任は受注者側からも解除できる（651条1項）
- 「準委任＝責任なし」ではない。善管注意義務（644条）違反は債務不履行責任になる
- 成果完成型準委任（648条の2）は請負と同じではない。準用されるのは634条だけで、契約不適合責任は付いてこない
- 使い分けの基準は「着手前に作るものを特定できるか」。要件定義は準委任、設計〜実装〜テストは請負が基本
- ただしIPAの工程別表は大手企業・ウォーターフォール・基幹システムを前提としたモデル。中小規模の案件は2〜3本に束ねるほうが現実的
- 請負にしても丸投げはできない。発注側の指図が原因の不具合は、原則ベンダーの責任にならない（636条）
- 契約類型のラベルより契約書の5条項（検収／契約不適合の期間と起算点／解除精算／変更管理／体制と窓口）を読む
- 契約書が準委任でも、実態が指揮命令なら偽装請負。2026年5月25日の追加で、アジャイル以外のすべてのシステム開発に同じ判断枠組みが当てはまることが明示された
- 分けるべきは会議やチャットの場ではなくやりとりの中身。「何を作るか」は直接伝えてよく、「誰がどうやるか」は受注者の管理責任者へ
契約類型の名前は、責任範囲の要約でしかありません。実際に何が起きるかを決めるのは、①契約書の条項と、②日々の進め方（誰が誰に何を指示するか）です。契約書の表題だけを見て安心しないでください。
出典
- 民法（明治二十九年法律第八十九号）第559条・第562条・第632条・第634条・第636条・第637条・第641条・第643条・第644条・第648条・第648条の2・第651条・第656条（e-Gov法令検索）
- IPA・経済産業省『情報システム・モデル取引・契約書（第二版）』（2020年12月22日）
- IPA『情報システム・モデル取引・契約書（アジャイル開発版）』（2020年3月31日）
- 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）
- 厚生労働省「37号告示」に関する疑義応答集（第1集）／（第3集）※第3集は2026年5月25日にQ8を追加
- 厚生労働省 事務連絡「『37号告示』に係る疑義応答集について」（令和3年5月13日）
- JUAS『企業IT動向調査2026』（2026年4月公開・2025年度調査、有効回答957社）
※本記事は一般的な情報提供を目的としたもので、個別の法律相談に代わるものではありません。具体的な契約内容の判断は弁護士に、偽装請負に関する個別の事案は各都道府県労働局にご相談ください。
