請負・準委任・ラボ型 — システム開発の契約形態の選び方【発注者ガイド】

最初に結論を述べます。システム開発の契約形態の選択は、突き詰めれば「成果物を買うのか（請負）」「時間・体制を買うのか（準委任・ラボ型）」の一択です。そして、その正解は開発会社ではなく『要件がどれだけ固まっているか』が決めます。 要件が固まっているのに準委任で丸投げすれば成果物の保証を失い、要件が流動的なのに請負で握れば変更のたびに追加費用と交渉が発生します。契約形態は「相手を縛る道具」ではなく、「不確実性をどちらがどれだけ引き受けるかの合意」だと理解するのが第一歩です。

本記事は、私が実際に手がけたプロジェクト——経済産業大臣賞を受賞したB2B SaaS（木材流通業界のDX）、本番稼働中の二重課金0件を維持する決済プラットフォーム、国内大手放送局向けのエンタープライズAI基盤——の契約・検収・変更管理の実務を根拠に、発注者（経営者・事業責任者・情報システム担当）が損をしないための地図を提供します。なお、私は弁護士ではありません。法的な最終判断は必ず専門家に確認してください。本記事は実務者としての解説です。

前提の明示: 民法・著作権法などの条文番号と文言はe-Gov法令検索の現行条文（2026年10月3日に確認）、改正の内容と施行日は法務省およびIPA「情報システム・モデル取引・契約書」に基づきます。私の実プロジェクトに紐づく定量値（本番二重課金0件、4ラウンドの自主セキュリティ監査など）はリポジトリから検証可能な実測値です。事業ROI（売上・工数削減%）はクライアントの実データが必要なため断定しません。

1. 3つの契約形態を1枚で理解する

システム開発で使われる契約は、実務上ほぼ次の3つに集約されます。まず全体像を1枚で押さえます。

覚えるべき対比はシンプルです。請負は「結果」に、準委任・ラボ型は「過程（時間・体制）」にお金を払う。この一点を軸に、以下で一つずつ深掘りします。契約形態を選ぶ前段の「そもそも作るべきか」「いくらが相場か」は、システム開発の発注 完全ガイドと費用相場・見積もりの見抜き方で扱っています。本記事はその「誰に・どう頼むか」の契約設計に絞ります。

2. 請負契約 — 「完成」を約束し、契約不適合責任を負う

請負は民法632条に定められた、「仕事の完成」に対して報酬を支払う契約です。開発会社は約束したシステムを完成させる義務を負い、完成しなければ原則として報酬を請求できません。発注者から見れば「決めた仕様どおりのものが、決めた金額で手に入る」——最も安心感のある形態に見えます。

2.1 契約不適合責任（旧・瑕疵担保責任）

請負の要は、納品物に欠陥（バグや仕様との不一致）があったときの責任です。2020年4月1日施行の改正民法（平成29年法律第44号）により、従来の「瑕疵担保責任」は「契約不適合責任」へと再構成されました。「瑕疵」という言葉は請負の条文から消え、納品物が種類・品質などの点で「契約の内容に適合しない」かどうかで判断する形になっています。いま契約書や見積書で「瑕疵担保」という言葉を見かけたら、改正前の雛形が使い回されていないかを疑うきっかけになります。IPAの「情報システム・モデル取引・契約書」も、この改正に対応して見直されています。

条文に沿って、発注者目線で整理します。

• 救済手段は4つ——履行の追完（修補）の請求（第562条）、報酬の減額の請求（第563条）、損害賠償の請求（第564条・第415条）、契約の解除（第564条・第541条・第542条）。追完と減額は売買の規定で、有償契約への準用を定めた第559条を通じて請負にも適用されます。損害賠償と解除は債務不履行の一般規定（第415条・第541条・第542条）によるもので、第564条はそれを妨げないことを確認しています。
• 通知の期間——発注者が不適合を知った時から1年以内に、その旨を通知しないと、上の4つを求められなくなります（第637条1項）。改正前は「引き渡した時から1年以内に請求」しなければならなかった（旧第637条）ので、起算点の面では発注者に有利になりました。また、引渡しの時点で請負人が不適合を知っていた、または重大な過失で知らなかった場合は、この1年の制限はかかりません（第637条2項）。通知をしたあとの権利そのものには、債権一般の消滅時効（第166条1項：行使できることを知った時から5年、行使できる時から10年）が別に働きます。
• 発注者の指図による不適合は対象外——発注者が提供した材料の性質や、発注者の指図によって生じた不適合は、原則として責任を追及できません（第636条）。ただし、請負人がその材料や指図が不適当だと知りながら告げなかったときは別です。「言われたとおりに作りました」で終わらせず、おかしな指示に異を唱えてくれる相手かどうかは、法的にも意味を持ちます。
• 期間は契約で定めるのが実務——実務では、契約書で「検収完了から○ヶ月」という期間を別途定めるのが一般的です。IPAの見直し資料でも、この起算点をどう設計するかが論点として整理されています。なお、「責任を負わない」という特約を置いても、知りながら告げなかった事実については責任を免れられません（第572条。第559条で請負にも準用）。

発注者が確認すべきは、契約不適合責任の期間と、その後の保守契約への引き継ぎ方です。「保証期間が短すぎないか」「保証期間終了と同時に有償保守に切り替わる設計になっていないか」を必ず読みます。参考までに、私が請負で受ける案件では、検収後3ヶ月以内に見つかった不具合を無償で修正することを基本にしています（期間などの条件は契約ごとに調整します）。

2.2 請負の落とし穴 — 「固定」の裏返し

請負の安心感には代償があります。固定価格・固定範囲は、要件が固まっていて初めて成立するという点です。要件が曖昧なまま請負契約を結ぶと、開発側は不確実性を織り込んで見積もりを高めに積むか、後から「それは契約範囲外です」という追加費用の応酬になります。私が現場で繰り返し見てきた失敗の典型がこれです。

つまり請負は「仕様書が書ける段階」に来て初めて力を発揮する契約であり、探索段階のプロジェクトには不向きです。

3. 準委任契約 — 「善管注意義務」を負い、工数に対して支払う

準委任は民法656条（法律行為でない事務の委託）に基づく契約で、開発会社は「善良な管理者の注意をもって業務を遂行する義務」（善管注意義務、644条）を負います。請負との決定的な違いは、「完成」を約束しない点です。誠実にプロとして作業を遂行すれば、たとえ狙った成果に届かなくても、その稼働に対する報酬は発生します。

「成果物が保証されないなら発注者に不利では？」と感じるかもしれません。しかし要件が流動的なプロジェクトでは、準委任のほうが合理的です。変更のたびに契約範囲を再交渉せずに済み、試しながら要件を固めていけるからです。要件定義・調査・PoC・運用改善など、「やってみないと分からない」領域で威力を発揮します。

3.1 「履行割合型」と「成果完成型」

改正民法は、準委任の報酬の払い方を2つに整理しました。発注者はこの違いを知っておくと交渉が有利になります。

「準委任＝時間精算だけ」ではありません。成果完成型を使えば、準委任でありながら『特定の成果物ができたら支払う』という設計もできます。「請負ほどガチガチに完成義務を負わせたくないが、成果には連動させたい」という中間解として有効です。

3.2 準委任で発注者が守るべきこと

準委任は柔軟な反面、放置すると「稼働はしているが前に進まない」状態を招きます。発注者側が防ぐべきは次の3点です。

1. 稼働の可視化を要求する——週次の進捗・工数・意思決定ログを必須にする。丸投げは準委任と最も相性が悪い。
2. 中間成果の合意点を置く——スプリントやマイルストーンごとに「何ができたか」をレビューする。
3. 善管注意義務の中身を具体化する——「プロとして当然の品質」を、テスト・型安全・セキュリティといった観測可能な基準に落とす（第8章）。

4. ラボ型契約 — 準委任を応用した「専属チームの継続確保」

ラボ型は、法律上の類型ではなく商慣行です。実体は準委任をベースに、一定期間（半年〜1年など）、専属の開発チームを確保し、その期間の工数枠に対して月額で支払う形態を指します。「オフショアラボ」「ラボ契約」などと呼ばれることもあります。

案件ごとに発注し直す請負と比べたラボ型の価値は、チームがドメイン知識を蓄積し続けることにあります。木材流通DXのような「林業→市場→製材所→プレカット→工務店→メーカー」という多段の商流や、決済基盤の冪等性設計のように、ドメインの理解が品質を左右する領域では、毎回チームが入れ替わる請負より、同じチームが継続改善するラボ型のほうが総合的に速く・安くなることが多い。

ラボ型のリスクは「稼働枠が埋まらず遊ぶ」ことです。発注者側にプロダクトオーナーが不在だと、確保した体制が空回りします。ラボ型は『発注者が優先順位を出し続けられる』ことが前提の契約です。アジャイル開発を継続する体制については、IPAも「アジャイル開発版」のモデル契約を別途整備しています。

5. どう使い分けるか — フェーズで契約を切り替える

現実の大きめのプロジェクトでは、1つの契約形態で最初から最後まで通すより、フェーズごとに使い分けるのが最適です。私が実務で採る典型的な組み立てはこうです。

【要件定義・調査フェーズ】
  → 準委任（成果完成型 or 履行割合型）
    要件が固まっていないので「完成」を約束できない。
    ここで請負にすると、双方が不確実性を抱えて破綻する。
        │
        ▼  要件が仕様書レベルまで固まる
【設計・実装フェーズ】
  → 要件が固いなら請負 / 変わり続けるなら準委任・ラボ型
    ・スコープが確定 → 請負で「決めた範囲を固定価格」
    ・探索と改善が続く → 準委任 or ラボ型で柔軟に
        │
        ▼  リリース後
【運用・保守・継続改善フェーズ】
  → 準委任 / ラボ型（＋ 契約不適合責任からの引き継ぎ）
    育て続けるプロダクトはラボ型が総合的に有利。

判断のコア問いは一貫して「この段階で、仕様を固定として握れるか？」です。握れるなら請負、握れないなら準委任・ラボ型。この見極めを飛ばして「とりあえず全部請負で」と進めるのが、追加費用トラブルの最大の温床です。「内製 vs 外注」「SaaS vs スクラッチ」というさらに上流の判断はBuild vs Buy の意思決定ガイドで、レガシー刷新の文脈は2025年の崖とレガシー刷新で扱っています。

6. 知財（著作権）の扱い — 「何もしなければ開発側に残る」

契約形態と並んで、発注者が最も見落とすのが知的財産権（特に著作権）の帰属です。ここは請負・準委任のどちらでも独立して定める必要があります。

原則を誤解しないでください。契約で何も定めなければ、開発したプログラムの著作権は制作した側（受託者）に帰属します。 著作権法は、著作物を創作した者を著作者とし（第2条1項2号）、著作者が著作権を享有すると定めています（第17条）。受託者が会社なら、会社の発意に基づいて社員が職務上作成したプログラムの著作者は、契約や勤務規則などに別段の定めがない限りその会社です（第15条2項）。お金を払って作らせたからといって、自動的に発注者のものにはなりません。発注者がソースコードを自由に改変・再利用したいなら、契約に明記が必要です。

さらに実務で必ず確認すべき論点があります。

• 第27条・第28条の権利を書き込む——「著作権を譲渡する」とだけ書いた契約では、翻案権など（第27条）と二次的著作物の利用に関する権利（第28条）は、譲渡した側に留保されたものと推定されます（第61条2項）。改変しながら使い続けるソフトウェアでは致命的なので、「著作権（著作権法第27条及び第28条に規定する権利を含む。）を譲渡する」と明記させます。
• 汎用モジュール・自社ライブラリの扱い——開発会社が他案件でも使う共通部品は、譲渡対象から除外され「利用許諾」に留めるのが通例。ここを一律「全部譲渡」と迫ると、単価が上がるか、優秀な会社に敬遠されます。線引きの合意が大事。
• OSS（オープンソース）の扱い——成果物に組み込まれたOSSは、そもそも譲渡できません。MITやApache-2.0、GPL系などライセンスごとに義務が違います。「どのOSSをどのライセンスで使ったか」の一覧（SBOM相当）を納品物に含めさせるのが、後の法務・セキュリティリスクを避ける実務です。
• 生成AIが関与したコードの扱い——私は一人 × 生成AI（Claude Code）を加速装置として使いますが、生成物は人間の検証ゲートを通した上で成果物とし、著作権・ライセンスの整理は通常のOSS/自作コードと同じ枠組みで契約に落とします。「AIが書いたから権利が曖昧」という状態を残さないことが重要です。

IPAのモデル契約書にも著作権・特許権などの知財条項の雛形が含まれており、交渉の出発点として有用です。

7. 発注者が所有すべきもの — 権利だけでなく「置き場所」と「鍵」も

第6章の著作権は「権利」の話でした。しかし、契約で著作権を譲り受けても、ソースコードの置き場所やクラウド、ドメインが受注者の名義のままなら、システムを動かす鍵は相手の手の中にあります。契約形態（請負・準委任・ラボ型）にかかわらず、発注者が自社名義で持つべきものを整理します。

ポイントは、これらは「納品時に渡してもらう」より「最初から発注者名義で作る」ほうが安全だということです。納品時の移管は相手の協力が前提になり、関係がこじれたときほど進みません。最初から発注者名義なら、関係の終わり方がどうであれ、発注者は相手の権限を外すだけで済みます。管理者権限・自動テスト・契約不適合責任の期間まで含めた確認項目は、システム開発の発注 完全ガイドの「契約初日から発注者が持つべきものチェックリスト」にまとめています。

私の進め方: 私が受ける案件では、リポジトリとクラウドアカウントを契約初日から発注者名義で作り、私はコラボレーター権限で作業します。契約が終わるときは、私の権限を外していただくだけです。成果物の著作権は、原則として発注者に帰属します（汎用的なライブラリ・テンプレート部分の扱いは個別契約書で明示します）。README・構成図・環境変数一覧・運用手順書（Runbook）は追加費用なしの標準納品物で、インフラはTerraformなどのIaCで管理し、別のエンジニアが同じ環境を再構築できる状態で納品します。社内にエンジニアがいない会社の技術責任者として関わる場合の担当範囲と料金の目安は、CTO代行・外部開発責任者のページにまとめています。

8. 検収の設計 — 合格基準を「発注前」に言語化する

検収は、契約形態が請負であっても、合格基準が曖昧なら永遠に終わりません。 そして検収が終わらなければ、支払いも、契約不適合責任の起算も、保守契約への移行も始まりません。検収は「納品後の作業」ではなく「発注前に設計するもの」です。

私が発注者側に必ず求める検収設計はこうです。

1. 合格基準を機能要件と非機能要件の両面で定義する——「動く」だけでなく「どの負荷まで／どのブラウザで／どの応答時間で」を数値で。非機能を書かない検収仕様が、後の「遅い」「落ちる」の紛争の元。
2. テスト観点をこちらから提示する——正常系だけでなく異常系・境界値。決済基盤で本番二重課金0件を維持できているのは、冪等性(idempotency)を検収観点に明示的に組み込み、リトライ・重複リクエストのテストを合格条件にしているからです。「二重課金は起きない」を願望でなく検収項目にする。
3. 品質ゲートを合格基準に含める——テストカバレッジ、型安全、そして脆弱性。私が手がけた基盤では、4ラウンドの自主セキュリティ監査（木材流通DX）やバックエンドのテストカバレッジ100%（AI動画ローカライズ基盤。未達ならCIでビルド失敗）を通過条件として運用しました。「善管注意義務」や「契約不適合」を、観測可能な基準に翻訳したものが品質ゲートです。
4. 検収期間と『みなし検収』条項を確認する——発注者が期間内に何も言わないと自動で合格扱いになる条項が入っていることが多い。放置は禁物です。

検収基準を発注前に言語化できていれば、請負・準委任のどちらでも紛争は激減します。逆に、どんなに立派な契約書でも、合格基準が「発注者が満足すること」のような主観語だと、必ず揉めます。

9. 追加要件・仕様変更の扱い — 「発生する前提」で設計する

システム開発で仕様変更が発生しないプロジェクトは存在しません。だから優れた契約は「変更を禁じる」のではなく「変更を安全に扱う手続き」を最初から持っています。

契約形態ごとに、変更への強さは構造的に異なります。

請負を選ぶ場合、発注者が必ず契約に入れるべきなのが変更管理（Change Request）プロセスです。

変更要望
  → 影響分析（工数・費用・納期・他機能への波及を開発側が提示）
  → 発注者が承認 / 却下 / 保留を判断
  → 承認なら見積・契約変更 → 実装
  → 却下でも記録を残す（言った言わないを防ぐ）

このプロセスがないと、「軽い変更のつもり」が無償対応の押し付け合いになり、関係が壊れます。変更は起きる。だから、起きたときの決め方を先に決めておく——これが追加要件を巡るトラブルを防ぐ唯一の方法です。準委任・ラボ型なら、この柔軟性が契約構造に最初から組み込まれている、という理解が正しい。

なお、取引条件を書面（発注書等）で明示することは、実務上の基本であるだけでなく、取引の当事者や委託の内容によっては法律上の義務です。従業員を使用しない個人などに業務を委託する場合はフリーランス・事業者間取引適正化等法（特定受託事業者に係る取引の適正化等に関する法律）第3条が、双方の事業者の規模と委託の内容が一定の要件に当たる場合は取適法（2026年1月1日施行の改正で下請法から改称）第4条が、給付の内容・代金（報酬）の額・支払期日などを書面または電磁的方法で明示するよう求めています。口頭発注のまま進めない、という基本は契約形態を問いません。

10. 発注者のためのチェックリスト

契約書に署名する前に、発注者として最低限確認すべき項目をまとめます。印刷して、開発会社との打ち合わせに持ち込めるレベルの実務チェックリストです。

• 契約形態は要件の固まり具合に合っているか（固い→請負／流動的→準委任・ラボ型）
• 準委任なら履行割合型か成果完成型か、報酬の払い方が明確か
• 請負なら契約不適合責任の期間と、保守契約への引き継ぎ方が妥当か
• 著作権は譲渡か利用許諾か、汎用モジュール・OSSの扱いが明記されているか
• 譲渡の場合、条文に著作権法第27条・第28条の権利が明記されているか
• 著作者人格権の不行使特約が入っているか
• リポジトリ・クラウドアカウント・ドメインを、契約初日から発注者名義で作ることになっているか
• README・構成図・環境変数一覧・運用手順書が納品物として契約に書かれているか
• 納品物にOSS一覧（SBOM相当）が含まれるか
• 検収の合格基準が機能要件・非機能要件の両面で数値化されているか
• 品質ゲート（テスト・型安全・セキュリティ）が検収条件に含まれるか
• みなし検収条項の期間と条件を把握しているか
• 変更管理（CR）プロセスが定められているか
• 再委託（下請け）の可否と、その場合の責任の所在
• 中途解約時の精算方法（特に準委任・ラボ型）

これらは、私が発注者側・受注者側の双方の立場で「揉めないための最低ライン」として繰り返し使ってきた項目です。ひとつずつ潰していけば、契約段階でトラブルの芽の大半を摘めます。

11. まとめ — 契約は「不確実性の分配」を決める合意

契約形態の選択を一言でまとめます。請負は「不確実性を開発側が引き受ける代わりに、範囲を固定する」契約。準委任・ラボ型は「不確実性を発注者と共有する代わりに、柔軟性を得る」契約です。どちらが優れているかではなく、あなたのプロジェクトが今どちらのフェーズにいるかで決まります。

私は一人 × 生成AI（Claude Code）を加速装置に、速く・安く開発します。しかし「安く速い」だけでは発注者の信頼は得られません。人間による検証ゲート——検収基準の言語化、品質ゲート、変更管理——で『安全』を担保して初めて価値になるというのが、経済産業大臣賞のB2B SaaSや本番二重課金0件の決済基盤で一貫して守ってきた原則です。契約はその安全を、法的な言葉で固定する装置にほかなりません。

契約形態の前段にある「そもそも作るべきか」「いくらが妥当か」「誰に頼むか」は、システム開発の発注 完全ガイドに体系化しています。補助金を活用する場合の契約・支払いの注意点は補助金 × システム開発 完全ガイドを参照してください。判断に迷ったら、契約書のドラフトを持って相談してください。契約形態の選び方から一緒に設計します。