2026.10.23 Webシステム

ラボ型開発とは？請負・SESとの違いと準委任契約の中身、国内ラボが向く案件

ラボ型開発は、開発会社のエンジニアを数名単位のチームとして半年、1年と確保し、その期間中の開発内容を発注側が組み替えながら進める発注形態です。「ラボ契約」とも呼ばれ、契約の性質は民法上の準委任にあたります。この記事では、民法の条文から見たラボ型の報酬と解除のルール、請負・SES・派遣との違い、オフショアと国内のラボ型の比較、月額費用の読み方、契約書で確認する条項、偽装請負にならない指示系統までを、発注側の判断に必要な順で整理します。

まとめ：ラボ型開発は準委任でチームを借りる契約、向くのは仕様が動く継続開発

ラボ型開発で発注側が買っているのは、成果物ではなく「一定期間の開発体制」です。完成責任は負わせられない代わりに、仕様変更のたびに見積もりと承認をやり直す必要がありません。

採用してよいのは、半年以上にわたって開発すべき要件が途切れず、社内に優先順位を決める担当者を置ける場合です。仕様が固まった単発の開発なら請負、足りないのが1〜2名の人手だけならSESのほうが総額は下がります。

契約前には、最低契約期間、人数の増減ルール、解約予告の期間、成果物の著作権の帰属の4点を書面で決めておきます。稼働中は、発注側から受注側の個々のエンジニアへ直接作業を指示しないことが、偽装請負を避ける条件になります。

ラボ型開発の定義と、成果物ではなく一定期間の開発チームを確保する仕組み

ラボ型開発には法令上の定義がありません。業界で使われる呼び名なので、まず実務上の意味を押さえ、そのうえで民法上どの契約に当たるかを確認します。

ラボ契約やODCとも呼ばれる、専属チームを月額で確保する発注形態

ラボ型開発では、開発会社が発注側の案件専用にエンジニアを割り当て、契約期間中はそのチームが継続して開発を担います。オフショア開発の文脈では「ラボ契約」「ODC（Offshore Development Center）」とも呼ばれてきました。料金は「月額いくらで何名」という形で決まり、その月に何を作るかは発注側が優先順位を付けて渡します。

請負との違いは、契約の時点で作るものの範囲を固定しない点にあります。たとえばSaaSの新機能を毎月リリースする開発では、翌月に何を作るかが利用データを見るまで決まりません。こうした開発で、範囲を固定する請負を毎回結び直す手間を省くのがラボ型の役割です。

民法656条の準委任＝委任の規定を準用し、仕事の完成を約束しない契約

ラボ型の契約書は、多くの場合「準委任契約」または「業務委託契約（準委任）」の名前で結ばれます。民法656条は「この節の規定は、法律行為でない事務の委託について準用する」と定め、ソフトウェア開発のような事実行為の委託にも委任の条文が当てはまります。

対照的に、請負を定める632条は「仕事を完成することを約し」と書いており、受注者は完成させる義務を負います。準委任の受注者が負うのは、専門家として注意を尽くして業務をする義務（善管注意義務）で、完成の保証ではありません。ラボ型で「期日までに全機能が揃わなかった」としても、それだけでは契約違反にならないのはこのためです。準委任そのものの契約実務は準委任契約とは？請負・派遣との違いとシステム開発での使い分けで詳しく扱っています。

履行割合型と成果完成型の2種類と、ラボ型が履行割合型で組まれる理由

2020年4月施行の改正民法で、準委任の報酬は2つの型に整理されました。648条は働いた分に報酬を払う形（履行割合型）で、期間で報酬を定めた場合は期間が過ぎた後に請求できます。648条の2は「委任事務の履行により得られる成果に対して報酬を支払う」形（成果完成型）で、成果の引渡しと同時に支払う定めです。

ラボ型は月単位でチームの稼働に報酬を払うため、履行割合型で組むのが通例です。成果完成型にすると、成果の定義を毎月決めることになり、仕様を固定しないというラボ型の利点が消えます。648条3項により、契約が途中で終わった場合でも、受注者はそれまでの履行の割合に応じて報酬を請求できます。

請負・SES・派遣とラボ型開発の違いを確保する単位と指揮命令で比較

ラボ型は、請負・SES・労働者派遣と並べると位置づけがはっきりします。違いが出るのは、完成責任の有無、確保する単位、誰が技術者に指示を出すかの3点です。

請負・SES・派遣・ラボ型の4形態を完成責任と確保単位で並べた比較表

発注判断に関わる項目に絞って4形態を並べます。

項目	請負	SES	ラボ型	労働者派遣
民法・法令上の型	請負（632条）	準委任（656条）	準委任（656条）	労働者派遣法
完成責任	あり	なし	なし	なし
確保する単位	成果物	技術者個人	チーム	技術者個人
技術者への指示	受注者	受注者	受注者	派遣先
仕様変更の扱い	都度見積もり	稼働の範囲内	稼働の範囲内	稼働の範囲内

表のとおり、ラボ型とSESは契約の型が同じで、違いは確保する単位だけです。発注側が技術者へ直接指示を出せるのは労働者派遣に限られ、ラボ型でもその点は変わりません。受託開発として出す請負の考え方は受託とは？受託開発の意味と委託・請負・SESとの違いで整理しています。

SESは個人の稼働、ラボ型はPMを含むチームの稼働を確保するという差

SESは「Javaが書ける人を1名、6か月」のように技術者個人の稼働を確保する形です。タスクの分解や進め方は、発注側の既存チームの中で決まることが多くなります。ラボ型は、PMやテックリードを含めたチームごと確保し、受注者の側で作業を割り振る前提で組みます。

使い分けの基準は、社内に開発チームがすでにあるかどうかです。チームはあって人手だけが足りないならSES、チームそのものを外に作りたいならラボ型が合います。SESの商流や発注時の注意点はSESとは？契約形態と派遣・SIerの違いで解説しています。

オフショアのラボ型と国内ラボ型：単価差と時差・言語による確認コストの比較

ラボ型はオフショア開発の契約形態として広まった経緯があり、検索結果の解説もベトナムなど海外拠点を前提にしたものが中心です。国内の開発会社がラボ型を受ける例もあり、両者は向く案件が違います。

オフショアのラボ型が持つ単価の利点とブリッジSE経由の伝達遅れ

オフショアのラボ型を選ぶ理由は、ほぼ単価です。同じ人数を確保しても月額が国内より下がるため、実装量の多い開発では総額の差が大きくなります。国別の人月単価と総額の比べ方はオフショア開発の費用相場は？国別の人月単価と内訳にまとめています。

代わりに、日本語と現地語の橋渡しをするブリッジSEが間に入り、仕様の確認が往復するたびに時差の分だけ回答が遅れます。ラボ型は仕様が動くことを前提にした契約なので、確認の遅れはそのまま開発速度の低下につながる要因です。オフショアの全体像と国内受託との使い分けはオフショア開発とは？メリット・デメリットと国内受託開発との使い分けで扱っています。

国内ラボ型が向くのは仕様の確認を当日中に回したい案件という条件

国内のラボ型は単価で海外に勝てません。勝てるのは、同じ時間帯に日本語で仕様を詰め、その日のうちに方針を変えられる点です。週に何度も優先順位が入れ替わる新規プロダクトや、業務部門と話しながら作る社内システムでは、この確認の速さが単価差を上回ります。

判断の目安は、仕様の確認が発生する頻度です。要件がスプリント単位でほぼ固まり、確認が週1回程度で済むならオフショアのラボ型でも回ります。毎日のように確認が要る案件では国内を選ぶほうが、待ち時間を含めた実効コストを下げることが可能です。国内の地方拠点に委託する選択肢はニアショア開発とは？オフショア開発との違いで比較しています。

ラボ型開発の費用構造：人数×月額単価と稼働率で決まる総額の読み方

ラボ型の見積もりは単純です。難しいのは、払った金額に見合う開発量を引き出せるかどうかで、そこは発注側の準備に左右されます。

月額の総額は人数×1名あたり単価×契約月数で決まるという費用の式

ラボ型の費用は「人数×1名あたり月額単価×契約月数」で決まり、開発量が少ない月でも請求額は変わりません。単価は役割で差が付き、実装担当とPM・テックリードでは開きがあります。例として一創の国内ラボ型の目安は、実装を担うメンバーが1名あたり月額60万〜80万円、PM・スペシャリストが1名あたり月額110万円からで、3名構成なら月額200万円前後からです。

見積もりを比べるときは、総額だけでなくチームの構成も確認の対象です。5名の見積もりでもPMが含まれていなければ、進め方の判断は発注側が担うことになります。単価の妥当性を判断する考え方は人月とは？計算方法・人月単価の相場と見積もりの妥当性で解説しています。

要件のストックが足りない月に稼働が余る失敗と四半期ごとの見直し

ラボ型で最も多い失敗は、チームを確保したのに渡す要件が足りず、稼働が余る状態です。月額は固定なので、空いた稼働はそのまま損失になります。発注側のPOが他業務と兼任で、バックログの整理が週1回しかできない組織で起きやすい失敗です。

防ぐ手段は2つあります。契約前に、少なくとも2〜3か月分の要件を一覧にしておくこと。そして、四半期ごとに人数を見直せる増減ルールを契約に入れておくことです。作り込みの時期は増やし、安定運用の時期は減らす前提で組めば、稼働の余りを小さくできます。

ラボ型の契約書で確認する条項：最低期間・人数の増減・解約予告・権利帰属

準委任の条文は任意規定が多く、契約書で別の定めを置けば、そちらが優先されます。ラボ型では、民法の原則と契約書の定めがどう違うかを確認しておくことが、後の揉め事を防ぎます。

民法651条の任意解除と、解約予告や最低期間で上書きする契約条項

民法651条1項は「委任は、各当事者がいつでもその解除をすることができる」と定めます。ただし2項により、相手方に不利な時期に解除した場合などは損害賠償が必要です。ラボ型の契約書では、この原則を「最低契約期間は6か月」「解約は30日前までに書面で通知」といった条項で具体化するのが一般的です。

確認すべき条項を並べると次のとおりです。

最低契約期間と更新の単位（例：6か月、以降3か月ごと）
人数の増減の申し出期限と、増員時に人が揃うまでの期間
解約予告の期間と、最低期間内に解約した場合の精算方法
成果物の著作権の帰属と、受注者が従前から持つライブラリの扱い
メンバー交代の条件と、交代時の引き継ぎ期間の費用負担

このうち著作権の帰属は、契約書に書かなければ原則として作った側に残ります。発注側が自社で運用・改修を続けるなら、帰属と引き渡しの範囲を必ず明記します。

IPAアジャイル開発版モデル契約が定める役割分担とPOをユーザが立てる前提

ラボ型の契約書を一から作るなら、IPAが公開している情報システム・モデル取引・契約書（アジャイル開発版）が下敷きになります。2020年3月31日に公開され、「あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく」準委任を前提にしたモデル契約です。

このモデル契約は、プロダクトオーナー（PO）をユーザ企業が選任し、スクラムマスターをベンダ企業が選任する分担を採っています。何を作るかの優先順位は発注側が責任を持つという設計で、ラボ型の契約にもそのまま当てはまる分担です。契約前に開発対象がアジャイルに向くかを確かめる「契約前チェックリスト」も同じページで配布されています。

偽装請負を避ける指示系統：疑義応答集第3集のQ2とQ7で見る線引き

ラボ型はチームが発注側の開発に深く入るため、指示の出し方を誤ると偽装請負になります。厚生労働省の37号告示に関する疑義応答集（第3集）のQ2は、双方が対等な関係で協働し、受注者側の開発担当者が自律的に判断して開発しているなら偽装請負とは判断されないとしています。反対に、発注側の担当者が受注者側の開発担当者へ業務の進め方や労働時間を直接指示すれば偽装請負です。

Q7は、技術力を判断するためのスキルシートの提出は、個人を特定せず、発注者が個人を指名したり就業を拒否したりできる形でなければ直ちに問題にならないとしています。ラボ型で「この人を入れてほしい」と名指しする運用は、この線を越える行為です。Q8は、これらの考え方がアジャイル以外の開発にも当てはまると答えています。4類型や罰則まで含めた判断基準は偽装請負とは：4類型と37号告示の判断基準で詳しく整理しています。

ラボ型開発を採用する条件と見送る場面：発注側の体制と要件の量で判断

ラボ型が合うかどうかは、案件の性質より発注側の体制で決まります。条件を満たさないまま始めると、月額だけが出ていく契約になります。

採用する条件は6か月以上の要件ストックと優先順位を決める担当者

ラボ型を採用してよいのは、次の2条件を両方満たす場合です。1つ目は、少なくとも6か月分、チームが手を止めずに済むだけの開発要件が見込めること。2つ目は、社内に優先順位を決めて受注者の管理責任者へ伝えるPO役を置けることです。

典型は、リリース後も機能追加を続けるSaaS、利用者の声を見ながら改善する社内システム、精度を試しながら作る生成AIの組み込みです。こうした開発で請負を選ぶと、変更のたびに見積もりと承認の往復が挟まり、開発が止まる時間のほうが長くなります。一創の国内ラボ型開発（チーム常設）では、3名からのチームで、ラボ型が向くかどうかの見極めから相談を受け付けています。

見送る場面は仕様確定の単発開発、2名以下の補充、POを置けない組織

次のいずれかに当たる場合は、ラボ型の採用を見送る判断です。仕様と納期が確定していて納品すれば終わる開発は、請負のほうが総額を抑えられます。必要なのが1〜2名の人手だけなら、チームとしての体制費が乗らないSESのほうが安く済みます。

最も避けるべきなのは、発注側にPOを置けない組織です。何を作るかを決める人がいないまま月額のチームを確保すると、受注者が要件を推測で埋めるか、稼働が余るかのどちらかになります。この場合は、要件定義だけを先に固めて請負で出すほうが失敗の確率は下がります。

ラボ型開発とSESの違い・ラボ契約の期間・デメリットについてよくある質問

ラボ型開発を検討している発注側から出やすい疑問を5つ取り上げます。

ラボ型開発とSESは何が違いますか？

契約の型はどちらも準委任で、受注者が完成責任を負わない点も同じです。違うのは確保する単位で、SESは技術者個人の稼働、ラボ型はPMやテックリードを含めたチームの稼働を確保します。SESでは発注側の既存チームの中で作業が決まることが多く、ラボ型は受注者側で作業を割り振る前提です。社内に開発チームがあり人手だけ足りないならSES、チームごと外に作りたいならラボ型が合います。

ラボ契約の期間はどのくらいが一般的ですか？

半年から1年で結ぶ例が多く、最低契約期間を6か月とし、以降は3か月単位で更新する形がよく見られます。チームが業務を理解して開発速度が上がるまでに立ち上がりの期間が要るため、3か月未満では効果が出にくくなります。民法651条は委任をいつでも解除できると定めていますが、契約書で解約予告の期間や最低期間内の精算方法を定めるのが通例です。

ラボ型開発のデメリットは何ですか？

発注側の負担が大きい点です。何を作るかの優先順位は発注側が決める必要があり、要件を渡せない月も月額は変わりません。完成責任がないため、期日までに機能が揃わなくても契約上の責任は問えません。チームの立ち上がりに時間がかかる点や、オフショアでは時差と言語による確認の遅れが出る点もあります。社内にPO役を置けない場合、これらのデメリットがまとめて表面化します。

ラボ型開発は偽装請負になりませんか？

契約が準委任でも、運用次第で偽装請負に当たるというのが答えです。厚生労働省の疑義応答集第3集は、発注側と受注側が対等に協働し、受注者側の開発担当者が自律的に判断していれば偽装請負に当たらないとしています。発注側の担当者が受注者のエンジニア個人へ作業の順序や残業を直接指示したり、特定の人を名指しで配置させたりすると線を越えます。依頼は受注者の管理責任者を通すことを契約書に書いておくと安全です。

ラボ型開発で作ったソースコードの権利は誰のものになりますか？

契約書の定めで決まります。何も定めなければ、著作権は原則として実際に作った受注者側に残ります。発注側が自社で運用・改修を続けるなら、成果物の著作権を発注側に帰属させる条項と、受注者が従前から持つ汎用ライブラリを除外する範囲の明記が必要です。準委任は完成責任を負わない契約ですが、権利の帰属は完成責任とは別の論点なので、契約時に必ず確認します。