# 請負・準委任・ラボ型 — システム開発の契約形態の選び方【発注者ガイド】 > システム開発の契約形態を発注者の視点で解説。請負（成果物・契約不適合責任）と準委任（工数・善管注意義務）とラボ型の使い分け、知財・検収・追加要件の扱いを、経済産業大臣賞や本番二重課金0件の実プロジェクトの知見から体系化します。 - 公開日: 2026-07-07 - 著者: 友田 陽大 - タグ: 受託開発, システム開発, 発注, DX, 技術選定, コスト最適化 - URL: https://tomodahinata.com/blog/system-development-contract-types-guide - カテゴリ: 発注・内製化・コスト - 総合ガイド: https://tomodahinata.com/blog/system-development-outsourcing-guide-vendor-selection-cost ## 要点 - 契約形態は『成果物を買う（請負）』か『時間・体制を買う（準委任・ラボ型）』かの選択であり、要件の固まり具合で決まる——要件が流動的なのに請負を選ぶと変更のたびに揉める - 請負は『仕事の完成』を約束し契約不適合責任（旧・瑕疵担保）を負う。準委任は『善管注意義務』を負うが成果物は保証しない。ラボ型は準委任を応用した継続的な専属体制の確保 - 知財（著作権）は『何もしなければ開発側に残る』のが原則。譲渡か利用許諾か、汎用モジュール・OSSの扱いまで契約で明記しないと二次利用でトラブルになる - 検収は『合格基準を発注前に言語化する』ことがすべて。基準が曖昧だと請負でも検収が終わらず、支払いも保守も始まらない - 追加要件は『発生する前提』で変更管理プロセスを契約に組み込む。準委任・ラボ型は変更に強く、請負は固定範囲を守る代わりに変更コストが跳ねる --- 最初に結論を述べます。**システム開発の契約形態の選択は、突き詰めれば「成果物を買うのか（請負）」「時間・体制を買うのか（準委任・ラボ型）」の一択です。そして、その正解は開発会社ではなく『要件がどれだけ固まっているか』が決めます。** 要件が固まっているのに準委任で丸投げすれば成果物の保証を失い、要件が流動的なのに請負で握れば変更のたびに追加費用と交渉が発生します。契約形態は「相手を縛る道具」ではなく、「不確実性をどちらがどれだけ引き受けるかの合意」だと理解するのが第一歩です。 本記事は、私が実際に手がけたプロジェクト——**経済産業大臣賞を受賞したB2B SaaS**（木材流通業界のDX）、**本番稼働中の二重課金0件を維持する決済プラットフォーム**、国内大手放送局向けのエンタープライズAI基盤——の契約・検収・変更管理の実務を根拠に、発注者（経営者・事業責任者・情報システム担当）が損をしないための地図を提供します。なお、私は弁護士ではありません。法的な最終判断は必ず専門家に確認してください。本記事は実務者としての解説です。 > **前提の明示**: 民法上の定義や改正内容はIPA「情報システム・モデル取引・契約書」およびe-Gov法令検索の民法条文に基づきます。私の実プロジェクトに紐づく定量値（本番二重課金0件、4ラウンドのセキュリティ監査など）はリポジトリから検証可能な実測値です。事業ROI（売上・工数削減%）はクライアントの実データが必要なため断定しません。 --- ## 1. 3つの契約形態を1枚で理解する システム開発で使われる契約は、実務上ほぼ次の3つに集約されます。まず全体像を1枚で押さえます。 | 観点 | 請負契約 | 準委任契約（履行割合型） | ラボ型契約 | |---|---|---|---| | 買っているもの | **成果物**（完成したシステム） | **工数**（作業の遂行そのもの） | **一定期間の専属体制**（工数枠） | | 開発側の約束 | 仕事の**完成義務** | **善管注意義務**（誠実に遂行） | 善管注意義務（準委任がベース） | | 成果物の保証 | あり（契約不適合責任） | なし（完成は保証しない） | なし（体制の提供が本旨） | | 対価の決まり方 | 成果物に対して固定 | 稼働時間・人月に対して | 期間 × 人数（月額の枠） | | 民法上の根拠 | 632条〜 | 643・644・656条 | 明文なし（準委任の応用） | | 向く場面 | 要件が固まった開発 | 要件が流動的な調査・改善 | アジャイルな継続開発 | | 発注者の主なリスク | 変更のたびにコスト増 | 成果が出ない稼働も支払い対象 | 稼働の無駄・体制の空回り | 覚えるべき対比はシンプルです。**請負は「結果」に、準委任・ラボ型は「過程（時間・体制）」にお金を払う**。この一点を軸に、以下で一つずつ深掘りします。契約形態を選ぶ前段の「そもそも作るべきか」「いくらが相場か」は、[システム開発の発注 完全ガイド](/blog/system-development-outsourcing-guide-vendor-selection-cost)と[費用相場・見積もりの見抜き方](/blog/system-development-cost-estimate-market-rate-guide)で扱っています。本記事はその「誰に・どう頼むか」の契約設計に絞ります。 --- ## 2. 請負契約 — 「完成」を約束し、契約不適合責任を負う 請負は民法632条に定められた、**「仕事の完成」に対して報酬を支払う**契約です。開発会社は約束したシステムを完成させる義務を負い、完成しなければ原則として報酬を請求できません。発注者から見れば「決めた仕様どおりのものが、決めた金額で手に入る」——最も安心感のある形態に見えます。 ### 2.1 契約不適合責任（旧・瑕疵担保責任） 請負の要は、納品物に欠陥（バグや仕様との不一致）があったときの責任です。2020年4月施行の改正民法により、従来の「瑕疵担保責任」は**「契約不適合責任」**へと再構成されました。IPAの「情報システム・モデル取引・契約書」も、この改正に対応して見直されています。 改正のポイントを発注者目線で整理します。 - **契約不適合があった場合、発注者は「追完請求（修補）」「報酬減額」「損害賠償」「契約解除」を求めうる**——救済手段が明文で整理された。 - 責任を追及できる期間は、民法上は原則として**「不適合を知った時から1年以内に通知」**すればよい（改正前の「引渡しから1年」より発注者に有利になった面がある）。 - ただし実務では、契約書で**「検収完了から○ヶ月」**という期間を別途定めるのが一般的。IPAの見直し資料でも、この起算点をどう設計するかが論点として整理されています。 発注者が確認すべきは、**契約不適合責任の期間と、その後の保守契約への引き継ぎ方**です。「保証期間が短すぎないか」「保証期間終了と同時に有償保守に切り替わる設計になっていないか」を必ず読みます。 ### 2.2 請負の落とし穴 — 「固定」の裏返し 請負の安心感には代償があります。**固定価格・固定範囲は、要件が固まっていて初めて成立する**という点です。要件が曖昧なまま請負契約を結ぶと、開発側は不確実性を織り込んで見積もりを高めに積むか、後から「それは契約範囲外です」という追加費用の応酬になります。私が現場で繰り返し見てきた失敗の典型がこれです。 つまり請負は「仕様書が書ける段階」に来て初めて力を発揮する契約であり、探索段階のプロジェクトには不向きです。 --- ## 3. 準委任契約 — 「善管注意義務」を負い、工数に対して支払う 準委任は民法656条（法律行為でない事務の委託）に基づく契約で、開発会社は**「善良な管理者の注意をもって業務を遂行する義務」（善管注意義務、644条）**を負います。請負との決定的な違いは、**「完成」を約束しない**点です。誠実にプロとして作業を遂行すれば、たとえ狙った成果に届かなくても、その稼働に対する報酬は発生します。 「成果物が保証されないなら発注者に不利では？」と感じるかもしれません。しかし要件が流動的なプロジェクトでは、準委任のほうが合理的です。**変更のたびに契約範囲を再交渉せずに済み、試しながら要件を固めていける**からです。要件定義・調査・PoC・運用改善など、「やってみないと分からない」領域で威力を発揮します。 ### 3.1 「履行割合型」と「成果完成型」 改正民法は、準委任の報酬の払い方を2つに整理しました。発注者はこの違いを知っておくと交渉が有利になります。 | 型 | 報酬の対象 | 民法 | 向く場面 | |---|---|---|---| | **履行割合型** | 実際に稼働した割合（時間・人月） | 648条 | 継続的な作業・運用・改善 | | **成果完成型** | 定めた成果が完成したこと | 648条の2 | 調査報告書・PoCなど成果が明確な作業 | 「準委任＝時間精算だけ」ではありません。成果完成型を使えば、**準委任でありながら『特定の成果物ができたら支払う』という設計**もできます。「請負ほどガチガチに完成義務を負わせたくないが、成果には連動させたい」という中間解として有効です。 ### 3.2 準委任で発注者が守るべきこと 準委任は柔軟な反面、放置すると「稼働はしているが前に進まない」状態を招きます。発注者側が防ぐべきは次の3点です。 1. **稼働の可視化を要求する**——週次の進捗・工数・意思決定ログを必須にする。丸投げは準委任と最も相性が悪い。 2. **中間成果の合意点を置く**——スプリントやマイルストーンごとに「何ができたか」をレビューする。 3. **善管注意義務の中身を具体化する**——「プロとして当然の品質」を、テスト・型安全・セキュリティといった観測可能な基準に落とす（第7章）。 --- ## 4. ラボ型契約 — 準委任を応用した「専属チームの継続確保」 ラボ型は、**法律上の類型ではなく商慣行**です。実体は準委任をベースに、**一定期間（半年〜1年など）、専属の開発チームを確保し、その期間の工数枠に対して月額で支払う**形態を指します。「オフショアラボ」「ラボ契約」などと呼ばれることもあります。 案件ごとに発注し直す請負と比べたラボ型の価値は、**チームがドメイン知識を蓄積し続けること**にあります。木材流通DXのような「林業→市場→製材所→プレカット→工務店→メーカー」という多段の商流や、決済基盤の冪等性設計のように、ドメインの理解が品質を左右する領域では、毎回チームが入れ替わる請負より、同じチームが継続改善するラボ型のほうが総合的に速く・安くなることが多い。 | 比較軸 | 請負（都度発注） | ラボ型（継続体制） | |---|---|---| | ドメイン知識 | 案件ごとに再学習 | チームに蓄積・複利化 | | 要件変更 | 契約変更が必要 | 枠内で柔軟に吸収 | | 立ち上げコスト | 毎回発生 | 初回のみ | | 向く対象 | 単発・仕様確定の開発 | 育て続けるプロダクト | | 発注者の関与 | 検収時が中心 | 継続的な優先順位付けが必須 | ラボ型のリスクは「稼働枠が埋まらず遊ぶ」ことです。発注者側にプロダクトオーナーが不在だと、確保した体制が空回りします。**ラボ型は『発注者が優先順位を出し続けられる』ことが前提**の契約です。アジャイル開発を継続する体制については、IPAも「アジャイル開発版」のモデル契約を別途整備しています。 --- ## 5. どう使い分けるか — フェーズで契約を切り替える 現実の大きめのプロジェクトでは、**1つの契約形態で最初から最後まで通すより、フェーズごとに使い分けるのが最適**です。私が実務で採る典型的な組み立てはこうです。 ```text 【要件定義・調査フェーズ】 → 準委任（成果完成型 or 履行割合型） 要件が固まっていないので「完成」を約束できない。 ここで請負にすると、双方が不確実性を抱えて破綻する。 │ ▼ 要件が仕様書レベルまで固まる 【設計・実装フェーズ】 → 要件が固いなら請負 / 変わり続けるなら準委任・ラボ型 ・スコープが確定 → 請負で「決めた範囲を固定価格」 ・探索と改善が続く → 準委任 or ラボ型で柔軟に │ ▼ リリース後 【運用・保守・継続改善フェーズ】 → 準委任 / ラボ型（＋ 契約不適合責任からの引き継ぎ） 育て続けるプロダクトはラボ型が総合的に有利。 ``` 判断のコア問いは一貫して**「この段階で、仕様を固定として握れるか？」**です。握れるなら請負、握れないなら準委任・ラボ型。この見極めを飛ばして「とりあえず全部請負で」と進めるのが、追加費用トラブルの最大の温床です。「内製 vs 外注」「SaaS vs スクラッチ」というさらに上流の判断は[Build vs Buy の意思決定ガイド](/blog/build-vs-buy-saas-vs-scratch-inhouse-vs-outsource-guide)で、レガシー刷新の文脈は[2025年の崖とレガシー刷新](/blog/legacy-system-modernization-2025-cliff-cost-guide)で扱っています。 --- ## 6. 知財（著作権）の扱い — 「何もしなければ開発側に残る」 契約形態と並んで、発注者が最も見落とすのが**知的財産権（特に著作権）の帰属**です。ここは請負・準委任のどちらでも独立して定める必要があります。 **原則を誤解しないでください。契約で何も定めなければ、開発したプログラムの著作権は制作した側（受託者）に帰属します。** お金を払って作らせたからといって、自動的に発注者のものにはなりません。発注者がソースコードを自由に改変・再利用したいなら、契約に明記が必要です。 | 定め方 | 内容 | 発注者にとっての意味 | |---|---|---| | **著作権の譲渡** | 成果物の著作権を発注者へ移転 | 自由に改変・二次利用・他社委託が可能。最も自由度が高い | | **利用許諾（ライセンス）** | 著作権は開発側に残し、利用範囲を許諾 | 使えるが、範囲外の改変・転用に制約が残ることがある | | **著作者人格権の不行使特約** | 人格権（譲渡不可）を行使しない合意 | 改変・クレジット非表示などを円滑にする実務上の要 | さらに実務で必ず確認すべき論点があります。 - **汎用モジュール・自社ライブラリの扱い**——開発会社が他案件でも使う共通部品は、譲渡対象から除外され「利用許諾」に留めるのが通例。ここを一律「全部譲渡」と迫ると、単価が上がるか、優秀な会社に敬遠されます。線引きの合意が大事。 - **OSS（オープンソース）の扱い**——成果物に組み込まれたOSSは、そもそも譲渡できません。MITやApache-2.0、GPL系などライセンスごとに義務が違います。**「どのOSSをどのライセンスで使ったか」の一覧（SBOM相当）を納品物に含めさせる**のが、後の法務・セキュリティリスクを避ける実務です。 - **生成AIが関与したコードの扱い**——私は一人 × 生成AI（Claude Code）を加速装置として使いますが、生成物は人間の検証ゲートを通した上で成果物とし、著作権・ライセンスの整理は通常のOSS/自作コードと同じ枠組みで契約に落とします。「AIが書いたから権利が曖昧」という状態を残さないことが重要です。 IPAのモデル契約書にも著作権・特許権などの知財条項の雛形が含まれており、交渉の出発点として有用です。 --- ## 7. 検収の設計 — 合格基準を「発注前」に言語化する **検収は、契約形態が請負であっても、合格基準が曖昧なら永遠に終わりません。** そして検収が終わらなければ、支払いも、契約不適合責任の起算も、保守契約への移行も始まりません。検収は「納品後の作業」ではなく「**発注前に設計するもの**」です。 私が発注者側に必ず求める検収設計はこうです。 1. **合格基準を機能要件と非機能要件の両面で定義する**——「動く」だけでなく「どの負荷まで／どのブラウザで／どの応答時間で」を数値で。非機能を書かない検収仕様が、後の「遅い」「落ちる」の紛争の元。 2. **テスト観点をこちらから提示する**——正常系だけでなく異常系・境界値。決済基盤で**本番二重課金0件**を維持できているのは、冪等性(idempotency)を検収観点に明示的に組み込み、リトライ・重複リクエストのテストを合格条件にしているからです。「二重課金は起きない」を願望でなく検収項目にする。 3. **品質ゲートを合格基準に含める**——テストカバレッジ、型安全、そして脆弱性。私が手がけた基盤では**4ラウンドのセキュリティ監査**と**テストカバレッジ100%**（対象モジュール）を通過条件として運用しました。「善管注意義務」や「契約不適合」を、観測可能な基準に翻訳したものが品質ゲートです。 4. **検収期間と『みなし検収』条項を確認する**——発注者が期間内に何も言わないと自動で合格扱いになる条項が入っていることが多い。放置は禁物です。 検収基準を発注前に言語化できていれば、請負・準委任のどちらでも紛争は激減します。逆に、どんなに立派な契約書でも、合格基準が「発注者が満足すること」のような主観語だと、必ず揉めます。 --- ## 8. 追加要件・仕様変更の扱い — 「発生する前提」で設計する システム開発で仕様変更が**発生しない**プロジェクトは存在しません。だから優れた契約は「変更を禁じる」のではなく「**変更を安全に扱う手続き**」を最初から持っています。 契約形態ごとに、変更への強さは構造的に異なります。 | 契約形態 | 変更への強さ | 変更の扱い方 | |---|---|---| | 請負 | 弱い（範囲固定が前提） | 変更＝契約変更。**変更管理（CR）プロセス**で工数・費用・納期を都度合意 | | 準委任 | 強い | 次スプリントの優先順位として吸収。契約変更は基本不要 | | ラボ型 | 強い | 確保した工数枠の中で優先順位を組み替えて対応 | 請負を選ぶ場合、発注者が必ず契約に入れるべきなのが**変更管理（Change Request）プロセス**です。 ```text 変更要望 → 影響分析（工数・費用・納期・他機能への波及を開発側が提示） → 発注者が承認 / 却下 / 保留を判断 → 承認なら見積・契約変更 → 実装 → 却下でも記録を残す（言った言わないを防ぐ） ``` このプロセスがないと、「軽い変更のつもり」が無償対応の押し付け合いになり、関係が壊れます。**変更は起きる。だから、起きたときの決め方を先に決めておく**——これが追加要件を巡るトラブルを防ぐ唯一の方法です。準委任・ラボ型なら、この柔軟性が契約構造に最初から組み込まれている、という理解が正しい。 なお、発注者・受注者間の取引条件の書面明示（発注書等）は、下請法やフリーランス保護の観点からも実務上重要です。口頭発注のまま進めない、という基本は契約形態を問いません。 --- ## 9. 発注者のためのチェックリスト 契約書に署名する前に、発注者として最低限確認すべき項目をまとめます。印刷して、開発会社との打ち合わせに持ち込めるレベルの実務チェックリストです。 - [ ] **契約形態は要件の固まり具合に合っているか**（固い→請負／流動的→準委任・ラボ型） - [ ] 準委任なら**履行割合型か成果完成型か**、報酬の払い方が明確か - [ ] 請負なら**契約不適合責任の期間**と、保守契約への引き継ぎ方が妥当か - [ ] **著作権は譲渡か利用許諾か**、汎用モジュール・OSSの扱いが明記されているか - [ ] **著作者人格権の不行使特約**が入っているか - [ ] 納品物に**OSS一覧（SBOM相当）**が含まれるか - [ ] **検収の合格基準**が機能要件・非機能要件の両面で数値化されているか - [ ] **品質ゲート**（テスト・型安全・セキュリティ）が検収条件に含まれるか - [ ] **みなし検収**条項の期間と条件を把握しているか - [ ] **変更管理（CR）プロセス**が定められているか - [ ] **再委託（下請け）**の可否と、その場合の責任の所在 - [ ] **中途解約**時の精算方法（特に準委任・ラボ型） これらは、私が発注者側・受注者側の双方の立場で「揉めないための最低ライン」として繰り返し使ってきた項目です。ひとつずつ潰していけば、契約段階でトラブルの芽の大半を摘めます。 --- ## 10. まとめ — 契約は「不確実性の分配」を決める合意 契約形態の選択を一言でまとめます。**請負は「不確実性を開発側が引き受ける代わりに、範囲を固定する」契約。準委任・ラボ型は「不確実性を発注者と共有する代わりに、柔軟性を得る」契約**です。どちらが優れているかではなく、あなたのプロジェクトが今どちらのフェーズにいるかで決まります。 私は一人 × 生成AI（Claude Code）を加速装置に、速く・安く開発します。しかし「安く速い」だけでは発注者の信頼は得られません。**人間による検証ゲート——検収基準の言語化、品質ゲート、変更管理——で『安全』を担保して初めて価値になる**というのが、経済産業大臣賞のB2B SaaSや本番二重課金0件の決済基盤で一貫して守ってきた原則です。契約はその安全を、法的な言葉で固定する装置にほかなりません。 契約形態の前段にある「そもそも作るべきか」「いくらが妥当か」「誰に頼むか」は、[システム開発の発注 完全ガイド](/blog/system-development-outsourcing-guide-vendor-selection-cost)に体系化しています。補助金を活用する場合の契約・支払いの注意点は[補助金 × システム開発 完全ガイド](/blog/subsidy-system-development-outsourcing-complete-guide)を参照してください。判断に迷ったら、契約書のドラフトを持って相談してください。契約形態の選び方から一緒に設計します。