結論: AI 駆動開発で準委任と請負のどちらを選ぶべきか
先に結論からお伝えします。AI 駆動開発のように 要件が動くことを前提にしたプロジェクトでは、要件定義から不確実性の高い前半は準委任、仕様が固まった後半の実装は請負、という使い分けが最も発注者を守ります。最初から全体を請負一本で締結すると、後述するとおり仕様変更のたびに揉め、結果として高くつくか品質が犠牲になるケースが多いからです。
ただしこれは「請負が悪い」という話ではありません。仕様が確定していて変更余地が小さい案件、たとえば既存システムの軽微な改修や、画面も項目も決まりきった定型開発であれば、請負の方が発注者にとって総額が読みやすく安全です。要は、作るものがどれだけ確定しているか で選ぶべき契約形態は変わります。
この記事では、準委任と請負の違いを発注者目線で整理したうえで、なぜ AI 駆動開発では請負一本が破綻しやすいのか、どうハイブリッドに組み合わせるのか、そして契約書で必ず確認すべき条項を具体的に解説します。AI 駆動開発そのものの進め方は AI 駆動開発とは？従来開発との違い・進め方 で定義しているので、あわせて読むと理解が深まります。
準委任契約と請負契約の違い(責任・検収・成果物の定義)
まず両者の本質的な違いを押さえます。混同されがちですが、責任の置きどころが根本から異なります。
請負契約は、民法上 「仕事の完成」を約束する契約 です。受託側はあらかじめ合意した成果物を完成させる義務を負い、完成しなければ報酬を請求できないのが原則です。発注者にとっては「決めた金額で、決めたものが必ず出来上がる」という安心感がある一方、その前提は 何を完成とするかが事前に詳細に定義できていること にあります。
準委任契約は、「業務の遂行」自体を委ねる契約 です。受託側は善良な管理者の注意をもって業務を遂行する義務(善管注意義務)を負いますが、特定の成果物の完成までは保証しません。稼働した分に対して対価を払う形が基本で、発注者が進め方や優先順位に深く関与しながら、いっしょに作っていくスタイルに向いています。
両者の違いを発注者の関心事ごとに整理すると、次のようになります。
| 観点 | 請負契約 | 準委任契約 |
|---|---|---|
| 受託側の義務 | 成果物の完成 | 業務の誠実な遂行(善管注意義務) |
| 報酬の対象 | 完成した成果物 | 稼働・工数 |
| 成果物の定義 | 契約時に詳細に確定が必要 | フェーズごとに柔軟に調整可能 |
| 検収 | 完成物が仕様を満たすか厳密に判定 | 報告・レビューによる確認が中心 |
| 仕様変更 | 原則として再見積もり・契約変更 | 優先順位の調整で吸収しやすい |
| 不具合対応 | 契約不適合責任(旧・瑕疵担保) | 善管注意義務の範囲で対応 |
ここで発注者が特に誤解しやすいのが 検収 です。請負では、納品物が契約で定めた仕様を満たしているかを厳密に確認し、満たしていなければ受け取りを拒否できます。これは強力な発注者保護ですが、裏を返せば「仕様を契約時にどこまで具体的に書けたか」で検収の実効性が決まります。仕様が曖昧なまま請負を結ぶと、何をもって完成とするかの解釈で対立し、検収が事実上機能しません。
もう 1 つ重要なのが、2020 年の民法改正で「瑕疵担保責任」が 「契約不適合責任」 に変わった点です。納品物が契約の内容に適合しない場合、発注者は修補・代金減額・損害賠償・解除を請求できます。ただしこれも、契約で何を約束したかが基準になるため、結局は 仕様の明確さ がすべての土台になります。
なぜ AI 駆動開発は請負だと破綻しやすいのか(要件が動く前提)
ここが本記事の核心です。AI 駆動開発では、要件が動くことが「想定外」ではなく「前提」 です。
理由は 2 つあります。1 つは、AI 駆動開発が高速にプロトタイプや動くものを作れるため、発注者が早い段階で実物に触れ、「やっぱりこうしたい」というフィードバックが自然に出てくること。もう 1 つは、AI を使うことで実装スピードが上がる分、ボトルネックが「決めること」に移り、作りながら仕様を磨いていくプロセスが合理的になることです。Claude Code や Cursor を使った開発では、画面や挙動を実際に見てから方向を決められるので、最初から細部まで仕様書を書き切るより、動かしながら確定させる方が早く良いものに着地します。
ところが請負契約は、その正反対の前提に立っています。請負は「完成を約束する」契約なので、完成の定義 = 詳細な仕様が契約時に確定していること を求めます。要件が動くたびに、それは契約範囲外の変更となり、再見積もり・契約変更・追加交渉が発生します。これが繰り返されると、次のような不健全な状態に陥ります。
- 受託側は契約範囲を守ろうとし、仕様変更に対して防御的になる(「それは別料金です」が増える)
- 発注者は追加費用を恐れて要望を抑え、結果として本当に必要な改善が後回しになる
- 当初の仕様に縛られたまま、誰も望まないものが「完成」してしまう
つまり、要件が動く前提のプロジェクトに請負を当てると、契約が改善を妨げる構造 になってしまうのです。発注者を守るはずの「完成保証」が、皮肉にも柔軟性を奪い、最終的なプロダクト品質を下げる方向に働きます。
逆に言えば、AI 駆動開発の速度や柔軟性というメリットを発注者が享受するには、それを許容できる契約形態 をセットで選ぶ必要があります。良い進め方と相性の悪い契約を組み合わせると、せっかくの強みが活きません。費用と期間の考え方は AI 駆動開発の費用と期間の目安 でも整理していますが、契約形態の選択はこの見積もりの前提そのものを左右します。
ハイブリッド契約: 要件定義は準委任・実装フェーズは請負の使い分け
では、発注者として総額の見通しは持ちたい、でも柔軟性も失いたくない。この両立をどう図るか。実務でよく機能するのが フェーズで契約形態を切り替えるハイブリッド型 です。
考え方はシンプルで、不確実性が高いフェーズは準委任、確定したフェーズは請負 にします。
flowchart LR
P1["要件定義 / PoC<br/>準委任"]
P2["仕様確定<br/>(成果物の確定)"]
P3["実装 / リリース<br/>請負 または<br/>準委任 (キャップ付き)"]
P1 --> P2 --> P3前半の要件定義や PoC のフェーズは、まさに「何を作るか」を探る段階です。ここで成果物の完成を約束させる契約は無理があるので、準委任で進めます。発注者は短いサイクルで動くものを確認しながら、優先順位を握り、仕様を固めていきます。
このフェーズの終わりで、作るものが十分に確定 します。仕様書・画面設計・受け入れ条件が具体化されるので、ここからは請負に切り替えても検収が実効的に機能します。完成の定義が明確だから、固定金額で握っても発注者は損をしません。
一方で、後半も仕様が動く可能性が残るなら、無理に請負にせず 上限金額(キャップ)を設けた準委任 にする選択肢もあります。これは「青天井ではないが、柔軟性も残す」という中間解です。スプリントごとに予算上限を決め、その中で優先度の高いものから作る運用にすれば、総額をコントロールしながら変更にも対応できます。
ハイブリッド型の利点は、それぞれのフェーズのリスクを、最も適した契約形態で扱える ことです。不確実なものを請負で無理に固定したり、確定したものを準委任でだらだら進めたりする無駄がなくなります。発注先がこの設計を最初から提案してくるかどうかは、その会社が要件の動く案件を本当に理解しているかの判断材料にもなります。発注先選びの観点は AI 受託開発の会社を選ぶときのチェックポイント も参考にしてください。
発注者が守られるための条項チェックリスト(知財・再委託・データ・解約)
契約形態を決めたら、次は条項です。形態が準委任でも請負でも、発注者を守るために必ず確認したい項目があります。見積書の金額だけ見て契約書の中身を読まない、という事故は本当に多いので、最低限ここは押さえてください。
知的財産権の帰属
開発したソフトウェアの著作権が、納品後に発注者へ移転するのかを明記します。「対価の支払い完了をもって著作権を発注者に譲渡する」という条項が基本です。これがないと、お金を払ったのにソースコードを自由に改変・再利用できない、という事態になりかねません。著作者人格権の不行使についても触れておくと安全です。
再委託の可否と範囲
受託側が第三者へ作業を再委託(下請けに出す)できるか、その場合の責任は誰が負うかを定めます。再委託を認める場合でも、機密保持義務を再委託先にも同等に課す こと、再委託先の行為について受託側が責任を負うことを明記しておきます。誰が実際にコードに触れるのかは、後述するデータ取り扱いとも直結します。
データと機密情報の取り扱い
これは AI 駆動開発で特に重要です。開発過程で自社のソースコードや業務データを AI ツールに読み込ませる場面があるため、どのツールに、どのデータを、どう渡すのか を契約と運用の両面で確認します。学習にデータが使われない設定になっているか、機密情報の保存場所や保持期間はどうか、退場時にデータが確実に削除されるか。秘密保持条項に加えて、AI ツール利用に関する取り決めを別途設けるのが望ましい時代になっています。
検収と契約不適合責任の期間
何をもって検収完了とするか、検収期間は何日か、不具合が見つかった場合の対応期間と範囲はどこまでか。請負ならここが特に重要で、契約不適合責任を主張できる期間(通知期間)も確認します。曖昧だと、リリース後の不具合対応が「追加費用です」となりがちです。
解約と中途終了の条件
プロジェクトを途中で止める場合の予告期間、それまでの精算方法、そして 成果物とソースコードの引き渡し条件 を必ず入れます。特に途中解約時にソースコードが渡されない契約は、発注者にとって致命的なリスクです。「いつでも、納得できる条件で離脱できる」状態を契約で確保しておくことが、最大の保険になります。
これらは形態を問わず共通のチェック項目です。準委任だから、請負だからではなく、発注者の権利が条項として書かれているか を 1 つずつ確認してください。
AI 生成コードの著作権・責任はどう扱うか(契約上の論点)
AI 駆動開発ならではの論点として、AI が生成したコードの扱いがあります。発注者からよく質問される点なので、現時点での実務的な考え方を整理します。
まず著作権について。日本では、人が創作的に関与せず AI が自動生成しただけの成果物には著作権が発生しないという考え方が一般的です。一方、実際の開発では AI が出力したコードを人間が取捨選択し、組み合わせ、修正して仕上げるため、成果物全体としては人間の創作的関与がある ケースがほとんどです。契約実務としては、生成コードか否かを細かく区別するより、「成果物の権利は対価の支払いをもって発注者に帰属する」と包括的に定める のが現実的で、発注者にとっても安全です。
次に、AI が生成したコードに第三者の権利を侵害するものが混入するリスクです。可能性はゼロではないため、契約では受託側が 学習データの扱いが明確なツールを選び、納品前にレビューと既存コードとの整合確認を行う義務 を負うこと、万一第三者から権利侵害の主張があった場合の対応分担を定めておくと安心です。AI 駆動開発のクリエイティブスタジオとして私たちが実務で重視しているのは、学習データの扱いが明確なツールを使い、生成物をそのまま納品せず人間のレビューと既存コードベースとの整合確認を必ず挟むことです。
責任についても、「AI が書いたから受託側の責任ではない」という主張は通りません。どのツールを使おうと、成果物の品質に対する責任は受託側が負うのが当然の前提です。AI はあくまで道具であり、その出力を採用して納品する判断をしたのは受託側だからです。契約上は、成果物の品質保証は使用ツールにかかわらず受託側が負う ことを確認しておけば、発注者が AI 特有のリスクを一方的に押し付けられる事態は避けられます。
要するに、AI 生成コードだからといって特別な法的真空地帯があるわけではなく、従来どおり「権利は発注者に帰属し、品質責任は受託側が負う」という原則を契約で明確にしておけば、発注者は十分に守られる というのが実務的な結論です。
週次デモと段階契約でリスクを分散する進め方
最後に、契約形態と並んで発注者のリスクを下げる進め方の工夫を紹介します。契約書だけでなく、進め方そのものでリスクを分散させることができます。
ポイントは 段階契約(フェーズ分割) と 週次デモ の組み合わせです。
段階契約は、プロジェクト全体を一括で締結するのではなく、要件定義フェーズ・PoC フェーズ・実装フェーズのように区切り、フェーズごとに合意して進める形です。各フェーズの終わりが自然な判断ポイントになり、成果と費用を確認したうえで次に進むか決められます。期待と違えば、そのフェーズで一度立ち止まる、あるいは方向を修正する、最悪の場合は撤退する、という選択が取れます。一括契約のように「走り出したら最後まで止まれない」状態を避けられるのが大きな利点です。
週次デモは、毎週(あるいはスプリントごとに)動くものを発注者に見せ、フィードバックを反映していく運用です。これには 2 つの効果があります。1 つは、認識のズレが大きくなる前に修正できること。月単位で報告を待つと、ズレが発覚したときには手戻りが膨大になりますが、週次なら最大でも 1 週間分のズレで済みます。もう 1 つは、進捗が実物で見えるため、発注者が状況を常に把握できる ことです。請負の「完成するまで中身がわからない」ブラックボックス状態と対照的に、リスクが早期に可視化されます。
この進め方は準委任やキャップ付き契約と特に相性が良く、優先順位を毎週いっしょに決めることで費用のコントロール権も発注者が握れます。契約形態でリスクの所在を整理し、進め方でリスクを早期に顕在化させる ——この二段構えが、要件の動く AI 駆動開発で発注者を守る現実的な型です。
まとめ
AI 駆動開発の契約は、「準委任か請負か」を二者択一で決めるものではありません。作るものがどれだけ確定しているかでフェーズを分け、不確実な前半は準委任、確定した後半は請負(または上限付き準委任)に切り替える ハイブリッド設計が、要件の動く案件で発注者を最もよく守ります。そのうえで、知財・再委託・データ・検収・解約の条項を 1 つずつ確認し、週次デモと段階契約で進め方からもリスクを分散する。ここまで設計できれば、AI 駆動開発のスピードと柔軟性を、安心して享受できます。
契約形態は単なる事務手続きではなく、プロジェクトの成否を左右する設計判断です。発注先がこの設計を当たり前に提案してくるかどうかは、その会社の実力を測る試金石にもなります。
FIXIT は AI 駆動開発のクリエイティブスタジオとして、契約形態を含めた進め方の設計から伴走しています。要件がまだ固まっていない段階でも構いません。準委任と請負の使い分けや、自社の案件にどの契約設計が合うかの相談を 無料相談 で受け付けています。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。