ラボ型開発とは｜請負・SES・内製との4択比較と、契約前に確認する10条項

「半年間、専属チームを確保できます」「仕様変更のたびに再見積もりは要りません」「メンバーをご指名いただけます」——ラボ型開発の提案書には、たいていこの3つが並んでいます。どれも発注側にとって魅力的に読めます。

ただ、この3つは同じ一次資料のなかで、線を越える条件として名指しされている行為とほとんど同じ言葉で書かれています。厚生労働省の告示と疑義応答集を読むと、「メンバーを指名する」「仕様変更をその都度指示する」「チームに直接やりとりする」は、やり方を間違えると適正な請負・準委任と認められなくなる行為として整理されています。

これはラボ型が違法だという話ではありません。ラボ型は準委任契約の正当な運用形態です。ただし発注側が「便利だから」とやってしまいがちなことと、法令上の線が、他の契約形態より近い距離にある。それがラボ型固有の性質です。

本記事は、ラボ型開発を提案されている、あるいは検討している発注側の立場から、(1) 自社に噛み合うのか、(2) 名目の月額は実質いくらなのか、(3) 契約前に何を確認するのか、を整理します。ラボ型開発を提供する事業者ではなく、発注側の意思決定を支援する立場から書いています。

この記事の結論｜ラボ型は「安い契約」ではなく「稼働枠を買う契約」

先に結論を書きます。

ラボ型開発で買っているのは、成果物でも、作業時間でもなく、一定期間の「稼働枠」です。 枠は使っても使わなくても料金が発生します。したがってラボ型が得になるかどうかは、単価が安いかどうかではなく、その枠を埋め続けられるだけの要件を、発注側が供給し続けられるかで決まります。

ここを外すと、ラボ型は「安い外注」ではなく「一番高い外注」になります。単価が2割安くても、稼働枠の3割が埋まらなければ、実質単価は元より高くなります。

もうひとつの結論はこうです。ラボ型は準委任の運用形態であり、準委任には発注者の指揮命令権がありません。 ラボ型の提案書に書かれている「柔軟に指示できる」「メンバーを指名できる」は、そのまま実行すると法令上の線に触れる可能性があります。厚生労働省の一次資料でこの線がどこにあるかを、本記事の後半で条文ごとに確認します。

判断は「安い／高い」ではなく、見積書と契約書の記載を次の4状態に仕分けることから始めてください。

「判断不能」が最も多いのが、ラボ型の相談です。ベンダー選びの前に、自社が半年間、毎月何人分の仕事を出せるのかを先に見積もってください。

この記事で扱わないこと

単価の水準は扱いません。 1人月の数え方、役割別の単価レンジ、単価をそろえて比較する手順は人月単価の相場の見方と比較手順にまとめています。ラボ型の見積書も、最終的には単価×人数×期間の形をとるため、単価そのものの妥当性はそちらで確認してください。

拠点の地理も扱いません。 「国内のどこに頼むか」「海外のどこに頼むか」は契約形態ではなく発注先の選択です。国内地方拠点の単価係数や拠点選定はニアショア開発の拠点選びと契約形態、海外委託の国別比較と是非はオフショア開発のメリット・デメリットが担当します。ラボ型はオフショアで語られることが多い形態ですが、ラボ型であることと海外であることは別の意思決定です。国内ベンダーのラボ型契約も、内製チームの外部拡張としてのラボ型も存在します。

見積書のどの欄をどう読むかも扱いません。 請負と準委任で見積書の見る欄がどう変わるか、検収条件や履行の割合をどう確認するかは請負と準委任の違いは見積書のどこに出るかが担当です。本記事は、契約形態が決まったあとの体制設計と運用に射程を置きます。

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

ラボ型開発とは｜期間と枠を買い、成果物の完成は買わない

ラボ型開発とは、一定期間にわたって発注側の専属チームを外部に確保し、その期間の稼働に対して費用を支払う開発の進め方です。 「ラボ契約」「ラボ型契約」、海外拠点に置く場合は「ODC（Offshore Development Center）」とも呼ばれます。呼び方は違っても、契約上の骨格は同じです。

法的には準委任契約の一形態

ラボ型開発という契約類型は、法律上は存在しません。実務で「ラボ型契約」と呼ばれているものは、民法上の準委任契約として結ばれるのが一般的です。

民法は次のように定めています。

システム開発は法律行為ではないため、委任ではなく準委任にあたります。そして準委任には、請負の第632条にある「完成することを約し」がありません。ここがラボ型を理解する出発点です。

ラボ型では、ベンダーは成果物の完成を約束していません。 約束しているのは、合意した体制で、合意した期間、善良な管理者の注意をもって業務を遂行することです。「半年で機能Aが完成する」ことは、契約上の債務ではありません。

ただし、準委任だから成果を求められないという意味ではありません。民法第648条の2（委任の規定であり、第656条により準委任に準用されます）は「委任事務の履行により得られる成果に対して報酬を支払うことを約した場合」という成果報酬型を想定しています。ラボ型でも、稼働に対する月額とは別に、特定の成果に紐づく報酬を組むことは可能です。実務でそう組まれているケースは多くありませんが、契約書を読むときは「この月額は稼働の対価なのか、成果の対価なのか」を確認してください。

発注側が実際に買っているもの

契約書の言葉を、発注側の家計簿の言葉に翻訳すると次のようになります。

右列の下2つが、ラボ型の提案書でしばしば左列に書かれます。ここが本記事の核心で、後述する「ラボ型の売り文句は、そのまま偽装請負の線に接している」で一次資料を挙げて確認します。

なぜ「ラボ」と呼ばれるのか

「ラボ（laboratory）」は、発注企業の研究開発部門を外部に置くイメージから来た呼称です。単発の請負を「工場への発注」に喩えるなら、ラボ型は「研究室を借りる」感覚に近い。成果物単位ではなく、組織単位で外部リソースを持つという発想です。

この比喩は、ラボ型が得意なことと不得意なことをよく表しています。研究室は、テーマを与え続ければ成果を出しますが、テーマを与えなければ止まります。テーマを供給する責任は借り手側にある、というのがラボ型の本質です。

請負・SES・ラボ型・内製の4択判断表

ラボ型とSESは、どちらも準委任契約です。違いは契約類型ではなく、何を単位に発注しているか（チームか個人か）と、チームを誰が束ねるかにあります。

この2つが混同されやすいのは、契約類型が同じで、契約書の表紙だけでは見分けがつかないからです。ラボ型開発を調べるときに「SESとの違い」が併せて調べられるのは、そのためです。

4択の比較表

SESとラボ型の実務上の違い

契約類型が同じでも、実務では次の点が違います。

1. 発注の単位が「人」か「チーム」か。 SESは「Aさんの1か月」を買います。ラボ型は「3名体制の1か月」を買います。SESでは誰が入るかが費用に直結しますが、ラボ型ではチームとしての産出が対象になります。

2. 誰がチームを束ねるか。 SESでは、束ねるのは発注側のマネージャーであることが多い。ラボ型では、受注者側にチームリーダーや管理責任者が置かれるのが基本形です。これは体制の好みの問題ではなく、後述する法令上の要請と関係します。

3. 終わり方が違う。 SESは月単位・四半期単位で人数を増減させやすい形態です。ラボ型は半年〜1年の枠を先に押さえる代わりに、期中の減枠が効きにくい。「柔軟」という言葉が、SESでは人数の柔軟さを、ラボ型では仕事の内容の柔軟さを指しています。同じ言葉で別のものを指しているので、提案を聞くときは「何が柔軟なのか」を聞き返してください。

4. 知識の残り方が違う。 SESで参画したエンジニアが抜けると、そのエンジニアが持っていたプロダクト知識も抜けます。ラボ型はチーム単位なので、1名が交代してもチーム内に知識が残る設計になっている——というのがラボ型側の主張です。ただしこれは設計されていればの話で、ドキュメントとレビュー体制が無ければチームでも属人化します。後述の失敗パターン3で扱います。

どれを選ぶかの分岐

上から順に判定してください。最初に「はい」になったところが第1候補です。

1. 要件が確定していて、変更がほぼ発生しない見込みか？ → はい: 請負。完成責任をベンダーに移せるので、管理負荷が最も低くなります。見積書の読み方は「一式」を工程・成果物・工数へ分ける方法を参照してください。
2. 必要なのは特定スキルの補充で、チーム運営は自社で行うか？ → はい: SES／準委任（個人単位）。既存の内製チームに1〜2名足す用途に噛み合います。
3. 中長期（半年以上）にわたり、毎月まとまった量の開発を出し続けられるか？ そして要件を出す担当者を社内に置けるか？ → はい: ラボ型。
4. その機能が自社の競争力の中核で、5年以上運用し続けるか？ → はい: 内製（または内製への移行計画つきのラボ型）。判断の詳細は内製と外注の判断フレームワークを参照してください。

3で「毎月まとまった量を出し続けられるか」に自信を持って「はい」と言えない場合、ラボ型は選ばないほうが安全です。この問いは費用の話ではなく、社内の体制の話です。

ラボ型の費用は「単価×人数×期間」では終わらない

ラボ型の費用は、見積書の「単価×人数×期間」では終わりません。名目の月額を、実際に成果へ結びついた稼働で割り直した「実質単価」で見る必要があります。

ラボ型の見積書は、たいてい非常にシンプルです。「エンジニア3名 × 月額◯◯万円 × 6か月」。行数が少ないので比較しやすく見えますが、発注側が実際に負担するのは、この名目額だけではありません。

実質単価の分解式

実質単価 = （名目月額 × 契約月数 ＋ 発注側が負担する周辺コスト）
           ÷ （実際に成果へ結びついた稼働人月）

分子を膨らませ、分母を痩せさせる要因が5つあります。この5つは、いずれも見積書の行を数えるだけでは把握できません。

1. 立ち上げ期間の非稼働をどう見るか

新しいチームが、初月から想定どおりの産出を出すことはありません。業務ドメインの理解、既存コードの把握、開発環境とレビュー基準の擦り合わせに時間がかかります。この立ち上がりを見込まずに投資対効果を計算すると、序盤で必ず「思ったより進んでいない」となります。

重要なのは、この期間があること自体は正常だという点です。問題になるのは、(1) 発注側がこの期間を予算計画に入れていない、(2) この期間に何を達成すれば正常なのかが合意されていない、の2つです。

費用の観点で確認するのは、この期間の料金が満額なのか、逓減があるのかです。そのうえで、この期間に何を目標に置くかは、後述の立ち上げ90日をどう設計するかで扱います。

2. 管理体制の枠は「別料金」かを必ず確認する

ラボ型では、受注者側に管理責任者やチームリーダーを置くことが実質的に必要になります。これは体制の好みではなく、37号告示が受注者に求める「業務の遂行に関する指示その他の管理を自ら行うものであること」から実務上導かれるものです（疑義応答集（第3集）Q3・Q6の回答も、指示が必要になった場合について同旨を述べています。原文は後述します）。発注側がチームメンバーに直接作業指示を出せない以上、誰かがベンダー側で指示を出さなければ、チームは動きません。

見積書で確認するのは次の点です。

• 「エンジニア3名」の3名に、リーダー／管理責任者は含まれるのか、別枠なのか
• 含まれる場合、そのリーダーは開発工数を何割持つのか（管理専任なら実質の開発リソースは2名分）
• 海外拠点の場合、ブリッジ担当（通訳・仕様伝達を担う役割）はこの3名に含まれるのか

「3名で月◯◯万円」の3名のうち1名が管理専任、1名がブリッジ専任であれば、コードを書く人は1名です。名目単価が安く見えても、実質単価は3倍になります。ここは見積書の行を見ただけでは分からないので、体制図を出させてください。

3. 埋まらなかった枠の扱い

ラボ型の費用構造で最も見落とされるのがこれです。枠は、使わなくても料金が発生します。

要件定義が間に合わない、社内の意思決定が止まる、繁忙期で担当者がレビューできない——理由は何であれ、発注側の都合でチームの手が空いた月があっても、月額は変わりません。

契約前に確認すべきは次の2点です。

• 稼働の下限保証があるか（「月160時間分は必ず確保」など）と、その未消化分の扱い
• 未消化分の繰り越しが可能か。可能な場合、繰り越せる上限と有効期限

繰り越しを認めるベンダーもありますが、上限や期限が付くのが普通です。「繰り越せます」という口頭の説明を、契約書の条項として確認してください。

4. 解約予告期間は「実質の最低契約期間」を延ばす

最低契約期間が6か月で、解約予告が3か月前だとすると、実質的に拘束される期間は最大9か月になります。6か月契約が自動更新される条項と組み合わさると、更新の3か月前までに意思表示しなければ、さらに6か月が確定します。

ただしこれは最悪ケースです。最低契約期間の途中で予告を出せる契約なら、6か月で終えられます。予告を最低契約期間中に出せるのか、期間満了後にしか出せないのかは条項次第で、ここが9か月と6か月を分けます。

ラボ型開発を提供する事業者の公開ページを見ると、契約期間の書き方には幅があります。半年〜1年を目安として説明するものもあれば、1名・1か月から開始できるとするものもあります。公開情報から確認できる範囲では、業界共通の相場と呼べるものは見当たりません。

したがって確認すべきは相場ではなく、自社が提示されている契約書の条項です。次の3つを掛け合わせた期間を「実質の拘束期間」として稟議に書いてください。

実質の拘束期間（最悪ケース）= 最低契約期間 ＋ 解約予告期間 ＋（自動更新条項がある場合の更新単位）

5. 引き継ぎ工数は、自社側にも発生する

終了時の引き継ぎで見落とされるのは、ベンダー側の作業費ではなく、自社側の受け取り工数です。ソースコードを受け取っても、ビルドできる環境、依存関係の一覧、運用手順、設計の意図が揃っていなければ、次の担当者は動けません。

この受け取りコストが極端に大きくなると、実質的にベンダーを変えられない状態になります。構造としては保守フェーズのロックインと同じで、ベンダーロックインが起きる仕組みと引き継ぎ条件で扱っている論点がそのまま当てはまります。成果物の権利と納品範囲についてはソースコードの納品条件と権利の確認を参照してください。

なお、ラボ型を選ぶかどうかとは別に、開発費用そのものの内訳構造は開発費用の相場と見積もり妥当性の判断にまとめています。

ラボ型が噛み合うケースと、噛み合わないケース

ラボ型が噛み合うのは、毎月まとまった量の要件を出し続けられる体制が発注側にある場合に限られます。 以下では両方のケースを並べ、噛み合わない場合の送り先まで示します。

噛み合うケース

噛み合わないケース

上の表で2つ以上に当てはまる場合、ラボ型の提案を受け取っていても、いったん立ち止まる価値があります。ラボ型を提案されたという事実は、ラボ型が最適だという根拠にはなりません。 提案側にとって、稼働枠を先に押さえられる契約は収益の予測が立てやすい形態です。これは不誠実という意味ではなく、利害の向きが違うという意味です。

そもそも開発手法としてどう進めるかを迷っている段階であれば、ウォーターフォールとアジャイルの選び方とプロダクト開発の外注ガイドを先に読むほうが順序として自然です。

ラボ型の売り文句は、そのまま偽装請負の線に接している

ラボ型開発の提案書で魅力として語られる3つの機能は、いずれも厚生労働省の一次資料が線を引いている領域に接しており、運用を誤ると適正な請負・準委任と認められなくなります。

繰り返しますが、ラボ型が違法だという話ではありません。線が近いという話です。線がどこにあるかを知らずに運用すると、越えたことに気づかないまま数か月が経ちます。

前提｜線を引いているのは契約書ではなく実態

労働者派遣法第2条第1号は、労働者派遣を次のように定義しています。

自己の雇用する労働者を、当該雇用関係の下に、かつ、他人の指揮命令を受けて、当該他人のために労働に従事させることをいい、当該他人に対し当該労働者を当該他人に雇用させることを約してするものを含まないものとする。

つまり、指揮命令関係があれば労働者派遣です。この区分の判断基準を定めているのが厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号、最終改正 平成24年厚生労働省告示第518号。通称37号告示）で、同基準が準委任にも及ぶことは、同省の疑義応答集（第3集）Q1が明示しています。なお告示第2条と契約類型の対応関係は請負と準委任の違いは見積書のどこに出るかが扱っています。

本記事で「Q◯」と書くときは疑義応答集の問答の組を指します。疑義応答集からの引用は、設問文であることを明示している箇所を除き、当該回答（A◯）からのものです。

なお同集のQ1〜Q7は、いずれもアジャイル型開発を題材とした問答です。これがアジャイル型開発以外にも及ぶことは、同集のQ8とA8が示しています。

Ｑ８　Ｑ１～７の考え方は、アジャイル型開発以外のシステム開発を請負業務とする場合についても当てはまりますか。

Ａ８　アジャイル型開発以外のシステム開発を請負業務とする場合についても当てはまります。

つまり、契約類型が準委任にも及ぶことを示すのがQ1、開発手法がアジャイル型に限られないことを示すのがQ8です。

ただしQ8自身の文言は「アジャイル型開発以外のシステム開発を請負業務とする場合」であり、準委任を名指ししてはいません。準委任へ及ぶ根拠は、A1が置いている次の原則にあります。

（前略）労働者派遣と請負等（委任、準委任を含みます。以下同じ。）のいずれに該当するかについては、契約形式ではなく、「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和 61 年労働省告示第 37 号）に基づき、実態に即して判断されるものです。

契約形式ではなく実態で判断される——この原則と、先に引いた労働者派遣法第2条第1号の定義が、橋渡しを担っています。本記事が以下で引くQ3〜Q7も、この前提で読んでください。

ラボ型契約書に「準委任」と書いてあることは、何の防御にもなりません。 判断されるのは契約書の表題ではなく、日々の運用の実態です。

対応表｜売り文句と、接している条項

以下、1つずつ一次資料を確認します。

売り文句1｜「メンバーをご指名いただけます」

37号告示第2条第1号ハ(2)は、労働者派遣事業に該当しないための要件のひとつとして「労働者の配置等の決定及び変更を自ら行うこと」を受注者側に求めています（準委任への及び方は前述のQ1によります）。ここでいう「自ら」は受注者のことです。

厚生労働省の疑義応答集（第3集）Q7は、この点をシステム開発の文脈で直接扱っています。設問は、開発担当者の技術・技能レベルや経験年数等を記載したスキルシートの提出を求めてよいか、というものです。回答はこうです。

（前略）受注者の労働者の配置等の決定及び変更について受注者自らが行うことが求められます。 そのため、発注者が特定の者を指名して業務に従事させたり、特定の者について就業を拒否したりする場合は、発注者が受注者の労働者の配置等の決定及び変更に関与していると判断されることになり、適正な請負等とは認められません。

一方でスキルシートそのものは否定されていません。

（中略）受注者側の技術力を判断する一環として、発注者が受注者に対し、受注者が雇用する技術者のシステム開発に関する技術・技能レベルと当該技術・技能に係る経験年数等を記載したいわゆる「スキルシート」の提出を求めたとしても、それが個人を特定できるものではなく、発注者がそれによって個々の労働者を指名したり特定の者の就業を拒否したりできるものでなければ、発注者が受注者の労働者の配置等の決定及び変更に関与しているとまではいえないため、「スキルシート」の提出を求めたからといって直ちに偽装請負と判断されるわけではありません。

さらに、厚生労働省の「労働者派遣・請負を適正に行うためのガイド」は、告示第2条第2号ハ(2)（自ら行う企画または自己の有する専門的な技術・経験に基づいて業務を処理すること）の判断基準として、次のように整理しています。

当該要件は、事業主が企業体として有する技術、技能等に関するものであり、業務を処理する個々の労働者が有する技術、技能等に関するものではない。

この整理に照らすと、「Aさんが優秀だからAさんを指名する」という発注は、ラボ型で本来買っているもの——ベンダーという企業体の技術力——とずれています。 指名そのものの可否については、上に引いたQ7が直接示しています。

実務としてどう振る舞えばよいか。

• やってよいこと: 必要な技術・経験レベルを条件として提示する。体制として満たすべき役割構成を要求する。匿名化されたスキルシートの提出を求める
• 避けるべきこと: 個人を特定して指名する。特定個人の交代を要求する（成果に問題がある場合は、個人ではなくベンダーに対して体制の是正を求める）
• 契約書で確認すること: メンバー交代が発生する場合の事前通知、引き継ぎ期間、体制水準の維持義務。個人の氏名ではなく、役割と要求水準で書く

なお、メンバーの継続配置を求めること自体は、Q7が名指しする行為にはあたりません。Q7が問題にしているのは、発注者が特定個人を指名する／特定個人の就業を拒否することであって、体制の継続性を契約で確保することではありません。ただし、継続配置の要求が実質的に特定個人の指名として機能する場合は、Q7が指す問題と同じことになります。

売り文句2｜「仕様変更をその都度、柔軟にご指示いただけます」

これはラボ型の最大の売り文句であり、最も注意が必要な部分です。

厚生労働省の疑義応答集（第1集）（平成21年3月31日 職発0331007号）Q11は、まさにこの状況を扱っています。

Q11. 請負業務の内容が変更した場合の技術指導

製品開発が頻繁にあり、それに応じて請負業務の内容が変わる場合に、その都度、発注者からの技術指導が必要となりますが、どの程度まで認められますか。

回答はこうです。

請負業務の内容等については日常的に軽微な変更が発生することも予想されますが、その場合に直接発注者から請負労働者に対して変更指示をすることは偽装請負にあたります。一方、発注者から請負事業主に対して、変更に関する説明、指示等が行われていれば、特に問題はありません。

「これは製造業の話ではないか」という疑問が当然に出ます。この点について厚生労働省職業安定局需給調整事業課は、令和3年5月13日付の事務連絡で各労働局に対し、次の問い合わせと回答を示しています。

（問い合わせ）疑義応答集Ｑ10 及びＱ11 の考え方は、システム開発を請負業務とする場合にも当てはまるか。

（回答）システム開発を請負業務とする場合についても当てはまる。

出典: 厚生労働省「『労働者派遣事業と請負により行われる事業との区分に関する基準』（３７号告示）に係る疑義応答集について」（事務連絡、令和3年5月13日。2026年9月3日取得）

つまり、「日常的に軽微な変更をその都度、発注者からチームメンバーへ直接指示する」というラボ型の典型的な運用は、システム開発においても偽装請負にあたると整理されているということです。なお事務連絡の文言も「請負業務とする場合」ですが、判断が契約形式ではなく指揮命令の実態によることは前述のとおりで、準委任のラボ型にも同じ線が当てはまります。

では、どう運用すればよいのか。Q11の回答が示す原則がその答えです。「発注者から請負事業主に対して」変更の説明・指示を行う建て付けにすればよい。具体的には、

• 仕様変更の依頼は、受注者側の管理責任者・チームリーダー宛に出す
• チャットで個々のエンジニアへ直接タスクを振らない。振るならリーダーのチャンネルへ出し、割り付けはリーダーが行う
• プロジェクト管理ツールでも同じ。発注側がチケットを個人にアサインする運用は、この線に触れます

なお同じQ11は、例外も示しています。ただしこれは、(1) 新しい製品の製造や新しい機械の導入により従来の作業方法では処理できない、(2) 請負事業主への説明・指示だけでは処理できない、という2つが重なったときに限られます。

新しい製品の製造や、新しい機械の導入により、従来どおりの作業方法等では処理ができない場合で、発注者から請負事業主に対しての説明、指示等だけでは処理できないとき

このときに限り、Q10のア・イに準じた技術指導を受けることは差し支えないとされています。しかもQ10のア・イは、いずれも「請負事業主の監督の下で労働者に当該説明…を受けさせる場合のもの」を指しています。説明で足りるなら説明で、足りないときだけ受注者の監督の下で限定的に、という順序です。

この「誰宛に出すか」の設計は、体制費用として見積書に現れます。ここが計上されていない安い見積書は、体制を落としている可能性があります。見積書の欄でどう確認するかは請負と準委任の違いは見積書のどこに出るかで扱っています。

売り文句3｜「自社チームのように直接やりとりできます」

一方で、協働そのものが禁じられているわけではありません。 ここを誤解して、必要な情報提供まで止めてしまうと、今度は要件が伝わらずに手戻りが起きます。

疑義応答集（第3集）Q6は、会議・チャット・プロジェクト管理ツールに双方の関係者全員が参加している場合について、こう回答しています。

（前略）実態として、両者が対等な関係の下で情報の共有や助言・提案が行われ、受注者側の開発担当者が自律的に開発業務を進めているのであれば、偽装請負と判断されるものではありません。

他方で、このような会議や打ち合わせなどの全ての機会に管理責任者の同席が求められるものではないものの、実態として、（中略）発注者側の開発責任者や開発担当者から受注者側の開発担当者に対し、直接、業務の遂行方法や労働時間等に関する指示などの指揮命令が行われていると認められるような場合には、偽装請負と判断されることになります。

そのため、受注者側の開発担当者に対し、業務の遂行方法や労働時間等に関する指示を行うことが必要になった場合には、受注者側が管理責任者を選任するなどして受注者自らが指揮命令を行うなど、適正な請負等と判断されるような体制を確立しておくことが必要です。

Q3も同じ趣旨で、管理責任者が全会議に同席していなくても直ちに偽装請負とはならないとしたうえで、こう続けています。

（前略）受注者側の開発担当者に対して業務の遂行方法や労働時間等に関する指示を行う必要がある場合や、開発の進捗に遅れが生じた際などに、受注者側の開発担当者に対し、仕事の割り付け、順序、緩急の調整等に関して指示を行う必要がある場合には、受注者が管理責任者を選任するなどして受注者自ら指揮命令を行う必要があり、発注者側の開発責任者や開発担当者が、直接受注者側の開発担当者に当該指揮命令を行ってしまうと、たとえ受注者において管理責任者を選任していたとしても、偽装請負と判断されることになります。

最後の一文が重要です。管理責任者を「置いている」ことは免罪符になりません。 実態として発注側が直接指示していれば、置いていても同じ判断になります。

線引きを実務の言葉に落とすと、こうなります。なお以下で使う「バックログ（プロダクトバックログ）」は、次に作るものを優先順位順に並べた一覧を指します。

Q4は、発注者側が優先順位を決めることを通常の姿として前提しています。ただし上段の4つは「安全」ではなく「それだけをもって直ちに偽装請負とはされない」という意味です。実態として業務の遂行方法や労働時間等の指示に至れば、上段の行為であっても偽装請負と判断されます。 疑義応答集（第3集）のA4・A5・A6は、いずれも「他方で」以下でこの点を明示しています。

覚え方としては、「What（何を）は発注側、How（どう）とWho（誰が）は受注側」が実務的な目安になります。

補足｜一発判定ではなく、要件ごとの総合的な勘案

ここまで読むと不安になるかもしれませんが、判断は個別の行為の一発判定ではありません。告示の各要件について、受注者が自ら行っているかを総合的に勘案する枠組みになっています。厚生労働省の適正ガイドは、その判断について次のように注記しています。

「総合的に勘案して行う」とは、これらのうちいずれかの事項を事業主が自ら行わない場合であっても、これについて特段の合理的な理由が認められる場合は、直ちに当該要件に該当しないとは判断しない（以下同様）という趣旨である。

ただし、免除されるのは「特段の合理的な理由が認められる場合」であって、回数が少なければよいという趣旨ではありません。見られているのは運用の実態の総体です。だからこそ、常態としてどういう指示系統になっているかを、契約時に設計しておく意味があります。

線を越えたと判断されたとき、発注側に何が起きるか

線を越えたと判断されると、発注側は労働者派遣法第40条の6により、ベンダーのエンジニアへ直接雇用を申し込んだものとみなされる場合があります。 偽装請負の話で語られるのはたいてい「やってはいけない」までですが、発注側が本当に知る必要があるのは、その先に何が起きるかです。

条文を順に確認します。

労働者派遣法第40条の6は、労働契約申込みみなし制度を定めています。第1項の各号列記以外の部分（本文とただし書）はこうです。

労働者派遣の役務の提供を受ける者（中略）が次の各号のいずれかに該当する行為を行つた場合には、その時点において、当該労働者派遣の役務の提供を受ける者から当該労働者派遣に係る派遣労働者に対し、その時点における当該派遣労働者に係る労働条件と同一の労働条件を内容とする労働契約の申込みをしたものとみなす。

ただし、労働者派遣の役務の提供を受ける者が、その行つた行為が次の各号のいずれかの行為に該当することを知らず、かつ、知らなかつたことにつき過失がなかつたときは、この限りでない。

（第一号から第五号まで 略）

そして第5号が、いわゆる偽装請負に対応する号です。

五 この法律又は次節の規定により適用される法律の規定の適用を免れる目的で、請負その他労働者派遣以外の名目で契約を締結し、第二十六条第一項各号に掲げる事項を定めずに労働者派遣の役務の提供を受けること。

さらに第2項。

前項の規定により労働契約の申込みをしたものとみなされた労働者派遣の役務の提供を受ける者は、当該労働契約の申込みに係る同項に規定する行為が終了した日から一年を経過する日までの間は、当該申込みを撤回することができない。

発注側の言葉に翻訳すると、次のようになります。

重要な注意点を2つ書きます。

1つ目。第5号には「適用を免れる目的で」という目的要件があります。 指揮命令があったというだけで自動的にみなし雇用が成立するわけではありません。目的の有無が問われます。したがって「ラボ型で直接指示したら即座に直接雇用義務が発生する」という説明は、条文よりも強すぎます。

2つ目。ただし書があります。 該当することを知らず、知らなかったことに過失がなかった場合は適用されません。ただしこれは、知ろうとしなかった場合に守ってくれるものではありません。 本記事のような整理を読んだあとで同じ運用を続けることは、「過失がなかった」の主張を弱める方向に働くと考えられます（この点は本記事の見立てであり、個別の判断は弁護士へご確認ください）。

そのうえで、発注側が現実に直面するリスクを整理すると次のようになります。

• 人事上のリスク: 直接雇用の申込みをしたとみなされ、1年間撤回できない状態が生じうる
• 契約継続のリスク: 問題を指摘された時点で、体制の組み直しが必要になる。開発は止まる
• 調達のリスク: 官公庁・大企業との取引で、コンプライアンス確認の対象になる

対策は、複雑なことではありません。指示系統を1本にして、それを契約書と体制図に書き、実際にそのとおりに運用する。これだけです。運用が設計と一致していることが、そのまま説明可能性になります。

なお本章は条文と厚生労働省の公表資料を発注側の視点で整理したものであり、個別案件についての法的助言ではありません。自社の体制が適正な請負等にあたるかの判断は、弁護士へご確認ください。

「稼働しているのに成果が出ない」5つの失敗

ラボ型固有の失敗には、共通した性質があります。契約が自動的には止まらないので、失敗が表面化しにくいことです。請負なら検収の場で問題が顕在化しますが、ラボ型は毎月の請求が淡々と続きます。

以下、原因・早期検知シグナル・対策の順で整理します。一般的な開発の失敗パターンはシステム開発の失敗事例と原因にまとめており、ここではラボ型に固有のものだけを扱います。

失敗1｜要件の供給が枯れて、枠が空洞化する

原因: 発注側でバックログを作る担当者が、他業務と兼務している。あるいは意思決定が上位者で滞留し、次に何を作るかが決まらない。ラボ型では「作るものを決める」責任が全面的に発注側にあるため、ここが詰まると即座にチームが止まります。

早期検知シグナル:

• 週次の定例で「次に何をやるか」が毎回その場で決まっている
• バックログに、すぐ着手できる項目が2スプリント（おおむね1か月）分を切っている
• チーム側から「確認待ち」「仕様確認中」のタスクが増えている
• ベンダーからの報告に、成果ではなく作業の羅列が並び始める

対策: バックログの残量を契約上のKPIとして両者で監視する。「常に2スプリント分の着手可能な項目を維持する」を発注側の義務として合意し、割ったら警告する運用にします。要件を出す担当者は、兼務でも構いませんが時間を確保して名前を出す。誰の仕事でもない状態にしないことが要点です。バックログの書き方はアジャイル開発の外注ガイドで扱っています。

失敗2｜レビューできる人がいないまま、産出だけが積み上がる

原因: 発注側に技術的な判断ができる人がいない。あるいはいても他案件で手一杯で、コードもドキュメントも受け取ったまま検分されない。ラボ型には検収がないため、品質の判定が誰の役割でもないまま進みます。

早期検知シグナル:

• ベンダーが出したコードの変更が、数週間レビューされずに滞留している（月次報告に「未レビューの変更件数」を入れてもらうと発注側でも見えます）
• リリースはされているが、リリースノートの内容を発注側の誰も説明できない
• 「動いているので問題ない」以上の品質評価が出てこない
• 障害が出たときに、原因の説明をベンダーの言葉のまま受け入れている

対策: 品質の判定を、人ではなく仕組みに寄せる。テストの網羅率・コードの自動検査・脆弱性チェックの基準値を契約時に合意し、毎回自動で判定される状態にします（人が見られない月でも最低ラインを割らない、という担保です）。人によるレビューが確保できないなら、機械が判定できる基準を先に決める。加えて、四半期に一度は外部の第三者レビューを入れることも検討に値します。

失敗3｜チームなのに属人化して、引き継げなくなる

原因: 「ラボ型はチームに知識が溜まる」という前提が、実際にはドキュメントとレビュー体制によって支えられています。これが無いと、知識は特定の1〜2名の頭の中に溜まります。チーム単位で契約していても、属人化は起きます。

早期検知シグナル:

• 特定のメンバーが休むと、その領域の作業が止まる
• 設計判断の理由が、変更履歴の記録にもドキュメントにも残っていない
• 「前任者が作ったので分かりません」がチーム内部で発生している
• 環境構築の手順が誰かの手元メモにしかない

対策: 契約時に成果物の定義にドキュメントを含める。「動くコード」だけでなく、構成図、環境構築手順、運用手順、設計判断の記録を、納品物として明示します。加えて、四半期に一度、自社側で環境を再構築できるかを実際に試す。これが引き継ぎ可能性の最も確実なテストです。

失敗4｜稼働率が高いのに、事業指標が動かない

原因: ラボ型では稼働そのものが請求根拠になるため、稼働率という測りやすい指標が成果の代理指標になってしまいます。全員がフル稼働していても、作っているものが事業に効いていなければ意味がありません。

早期検知シグナル:

• 月次報告の中身が、稼働時間・消化した作業量・リリース本数だけで構成されている
• 「今月は◯◯機能をリリースしました」の先に、利用状況の報告が無い
• ベンダーへ渡している指標が、開発の量に関するものだけになっている

対策: 月次報告に事業側の指標を1つ以上入れることを契約時に合意します。リリースした機能が実際に使われているか、狙った行動が増えたか。作る側に事業指標を見せることは、優先順位の判断精度を上げる効果もあります。

失敗5｜撤退ラインが無く、惰性で更新され続ける

原因: 最低契約期間と自動更新条項の組み合わせで、「やめる」の判断を能動的にしないと更新が確定します。しかも、期中は毎月それなりに成果が出ているように見えるため、やめる決断のきっかけが訪れません。

早期検知シグナル:

• 契約更新の稟議が、前回の実績評価なしに更新前提で回っている
• 当初の目的（例: このプロダクトを事業として成立させる）が、社内で語られなくなっている
• 「もう半年やれば形になる」が2回以上繰り返されている

対策: 契約開始時に、撤退の条件を数値と期限で書いておく。「6か月時点で◯◯が達成できていなければ、更新せず体制を見直す」と、稟議書に明記します。判断の材料になる指標も同時に決めます。撤退ラインが無い投資は、撤退の判断ができない投資です。

契約書で必ず確認する10条項

ラボ型の契約書は、請負契約書に比べて条項が少ないことが多く、そのぶん抜けが見えにくい構造です。以下は発注側が必ず確認する10項目です。稟議の添付資料としてそのまま使えるよう、確認の観点まで書きます。

とくに 5・6・10 の3つは、契約の場でほとんど話題にならない論点です。契約を始めるときには誰も終わり方の話をしませんが、終わり方の条件は始まる前にしか決められません。

著作権の帰属（3）と成果物の定義（4）についてはソースコードの納品条件と権利の確認、引き継ぎ（10）についてはベンダーロックインが起きる仕組みと引き継ぎ条件で詳しく扱っています。稼働後の保守契約に移行する場合の範囲の切り方は保守契約の範囲とSLAの読み方を参照してください。

立ち上げ90日をどう設計するか

ラボ型で最初の3か月をどう使うかが、その後の成否をほぼ決めます。ここを「1か月目から機能開発」で走ると、序盤の躓きが最後まで尾を引きます。

0〜30日｜学習を成果物にする

この期間は、本番品質の機能開発を目標にしません。代わりに、学習が完了したことを確認できる成果物を置きます。

• 既存システムの構成図を、チーム側の理解でゼロから作成してもらう（発注側の資料を渡さずに作らせると、理解の穴が可視化されます）
• 小さな改修を1本、レビューからリリースまで通す（開発フローの詰まりが分かります）
• 開発環境の構築手順書を、チーム側が実際に構築しながら更新する

同時に、指示系統をこの期間に固定します。 誰に依頼を出すのか、緊急時はどうするのか、チケットは誰がアサインするのか。ここを曖昧にしたまま2か月目に入ると、便利さに流れて直接指示が常態化します。

31〜60日｜運用のリズムを確立する

スプリントの長さ、定例の頻度と参加者、報告のフォーマットを固定します。報告フォーマットには、稼働の指標だけでなく事業側の指標を1つ入れます（失敗4の対策）。

この期間に、バックログの残量が2スプリント分を維持できているかを確認します。維持できていなければ、それは体制の問題であって、チームの問題ではありません。3か月目に増員を検討する前に、要件を出す側の体制を見直してください。

61〜90日｜継続判断の材料を揃える

3か月目の終わりに、最初の継続判断を行います。判断材料は次の3つです。

1. 産出: 立ち上げ期間を織り込んだうえで、想定していた水準に近づいているか
2. 自走度: チームが自律的に判断できる範囲が広がっているか。質問の量ではなく質が変わっているか
3. 要件供給: 発注側が枠を埋め続けられているか

3つ目が満たせていない場合、増員はほぼ確実に悪化させます。枠を減らすか、契約形態を見直すかの検討に入ってください。この判断を「もう少し様子を見る」で先送りすると、失敗5の惰性更新に直結します。

AI協働開発が前提になった後のラボ型

ここからはkoromoとしての見立てです。断定ではなく、契約で確認すべき項目に落とし込む形で書きます。

ラボ型の課金単位は「人数 × 期間」です。この単位は、投入した人数と産出が比例するという前提の上に成り立っています。生成AIのコーディングエージェントが開発に組み込まれた現在、この前提は少なくとも一様ではなくなりました。

問題は「AIで安くなるか」ではありません。同じ月額で買っているものの中身が、ベンダーによって大きく違う可能性があることです。同じ「エンジニア3名 × 月額」でも、AIツールを日常的に使いこなすチームと、そうでないチームとでは産出が変わりえます。ところが見積書の表面は同じです。

一方で、人数を確保する意味が消えたわけでもありません。AIが得意なのはコードを書く工程であって、要件を確定させること、既存業務の制約を拾うこと、運用に耐える設計を選ぶこと、障害時に責任を持って判断することは、依然として人の仕事です。ラボ型で本当に買う価値があるのは、後者のほうです。

そう考えると、ラボ型を検討する際に新しく確認すべき項目が出てきます。

3番目は特に重要です。「AIは使っていません」という回答も、それはそれで確認すべき情報です。 使わない選択が、セキュリティ要件から来ているのか、単に体制が追いついていないのかで、意味が変わります。

koromoでは、AIエージェントを前提にした開発体制で受託開発と内製化支援を行っています。その立場から言えば、AI前提の開発で最も効くのは人数の削減ではなく、要件の確定から実装までのリードタイムの短縮です。ラボ型を検討する際は、「何人つくか」と同じ重さで「何日で回るか」を聞いてください。この観点での内製と外注の判断はAI活用における内製化と外注の判断、開発会社の選定軸は受託開発会社の比較と選び方にまとめています。

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

提案を受け取った段階で、そのままメールに貼り付けて送れる質問です。回答は本記事冒頭の4状態（説明済み／要確認／高リスク／判断不能）に仕分けてください。

1. 体制について: 提示いただいた「◯名」の内訳を、役割別（開発／リーダー／管理責任者／ブリッジ）に教えてください。このうち開発工数を持つのは何名分ですか。リーダーと管理責任者は開発工数を何割持ちますか。
2. 指示系統について: 仕様変更や優先順位の変更をお伝えする際、どなた宛にお出しすればよいですか。チケットの担当者割り当ては、どちら側が行う想定ですか。
3. 稼働の下限と未消化分: 月あたりの稼働の下限保証はありますか。当方の事情で未消化が出た場合、翌月以降へ繰り越せますか。繰り越せる場合、上限と有効期限を教えてください。
4. 最低契約期間と自動更新: 最低契約期間は何か月ですか。自動更新条項はありますか。更新しない場合、いつまでに意思表示が必要ですか。
5. 解約予告と精算: 中途解約の予告期間は何か月ですか。予告後、支払い義務はいつまで続きますか。既履行分の精算方法を教えてください。
6. メンバーの交代: メンバー交代が発生する場合、事前通知はどのくらい前になりますか。引き継ぎ期間は設けられますか。交代後の体制水準について、契約上どのような取り決めが可能ですか。
7. 成果物とドキュメント: 契約期間中および終了時に納品いただける成果物の一覧を教えてください。ソースコードのほかに、構成図・環境構築手順・運用手順・設計判断の記録は含まれますか。
8. 権利の帰属: 成果物の著作権はいつの時点で当方へ移転しますか。第三者のOSS（無償で公開・再利用されるソフトウェア）やライブラリ、AIが生成したコードが含まれる場合の取り扱いを教えてください。
9. 再委託: 再委託を行う可能性はありますか。ある場合、事前承諾の手続きと、再委託先での秘密保持の担保方法を教えてください。
10. 終了時の引き継ぎ: 契約終了時、当方または第三者への引き継ぎにどのような協力をいただけますか。その費用は月額に含まれますか、別途となりますか。

回答が揃わない、あるいは口頭でしか返ってこない項目は「要確認」です。とくに4・5・7・10のいずれかが空欄のまま契約する状況は、「高リスク」として扱ってください。

根拠資料と適用条件

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

本記事では、ラボ型開発の人月単価や国別の単価水準に関する数値は扱っていません。契約形態と金額水準は別の論点であり、同じ形態でも金額は案件ごとに大きく変わります。単価の見方は人月単価の相場の見方と比較手順を参照してください。

また、本文とFAQの契約期間に関する記述は、2026年9月3日時点で複数のラボ型開発提供事業者の公開ページを確認した結果の要約であり、特定企業の見解や業界共通の相場を示すものではありません。契約期間は事業者ごとに大きく異なるため、相場ではなく自社の契約書条項で確認してください。

ラボ型の契約範囲を見積書から確認する

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

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

よくある質問

まとめ

ラボ型開発は、専属チームの稼働枠を一定期間買う準委任の運用形態です。判断の順序をもう一度整理します。

1. 買っているのは稼働枠であって、成果物の完成ではない。得になるかは単価ではなく、枠を埋め続けられるかで決まる
2. 請負・SES・ラボ型・内製の4択で位置づける。要件が確定していれば請負、個人補充ならSES、中長期で毎月まとまった量を出せるならラボ型
3. 名目月額を実質単価へ引き直す。立ち上げ期間の非稼働、管理体制の枠、埋まらなかった枠、解約予告期間、引き継ぎ工数を足し引きする
4. 指示系統を1本に設計する。何を作るかは発注側、どう作るか・誰がやるかは受注側。この線は37号告示と疑義応答集が引いている
5. 終わり方の条件を、始まる前に決める。最低契約期間・解約予告・引き継ぎの3つは、契約後には交渉できない
6. 撤退ラインを数値と期限で書く。ラボ型は自動的には止まらない

最後に、この記事で一番伝えたいことを繰り返します。ラボ型が「安い」か「高い」かは、ベンダーの単価ではなく、発注側の体制で決まります。 毎月まとまった量の要件を出し、産出をレビューし、指示を1本の系統に通す。この3つができる体制があれば、ラボ型は強力な選択肢です。無ければ、同じ契約が最も高い外注になります。

ベンダー選びの前に、この3つが自社にあるかを確認してください。無いという結論も、正しい結論です。