要点（最初に結論）
- 工数ベースの見積もりは「何時間かかるか」より「何が出来上がるか」を測る方向へ圧力がかかっています。
- 受託の契約類型（請負・準委任）とリスクの所在を踏まえないと、AI前提の見積もりは設計できません。
- AI生成物の責任・著作権・再現性は、既存の契約条項だけでは対応しきれない部分があります。
- 成果物の定義が「動くコード」から「動かし続けられる設計と引き継ぎ情報」へ広がっています。
- どのリスクを誰が引き受けるかを、契約類型の選択とセットで事前に合意する重要性が増しています。
はじめに
terurou さんの記事「AI以後の受託システム開発はどうなっていくのか」 を読みました。
AI時代における受託開発の変容を俯瞰した総論として、非常に示唆に富む内容でした。
ただ、読み終えて「ではどう動けばいいか」という問いが残りました。
「AI前提の時代に見積もりはどう書くのか」「契約条項はどう直すのか」「何を成果物として定義するのか」——そういった実務の各論が、まだ十分に整理されていないと感じています。
本記事は、その実務各論を私なりに考えたものです。
私は大手SIerでシステム開発に携わったのち、現在はAIの研究に関わっています。
受託開発の現場で見積もりや契約に向き合ってきた経験と、いまAIを研究する立場の両方から、この変化を考えてみたいと思います。
作る側と、その作り方そのものを研究する側の両方を行き来している、という視点で読んでいただけると分かりやすいかもしれません。
ただし法律の専門家ではないため、契約や著作権の記述は公開資料を参照した一般的な整理にとどめ、最終的な判断は専門家に相談する前提で読んでいただければと思います。
あくまで一個人の視点です。
異論は歓迎します。
この記事の前提として、まず受託開発の契約が法律上どう組み立てられているかを押さえます。
そのうえで、見積もり・契約条項・成果物定義・リスクの4つの軸が、AIによってどう揺らぐかを順に見ていきます。
前提：受託開発の契約は「請負」と「準委任」でできている
AI以前の話を先に整理します。
ここを飛ばすと、後半の「AIで何が変わるか」が宙に浮くからです。
日本の受託開発で使われる契約類型は、大きく請負契約と準委任契約に分かれます。
両者の決定的な違いは「仕事の完成義務」と「契約不適合責任」の有無です。
- 請負契約：仕事の完成が目的（義務）です。成果物が契約内容に適合しなければ、受注者が契約不適合責任を負います。
- 準委任契約：一定の事務処理を行う契約で、仕事の完成義務はありません。
準委任はさらに2種類に分かれます。
従来からある「履行割合型」は、稼働した工数や期間に応じて報酬が発生します。
これに加えて、2020年4月施行の改正民法（民法648条の2）で、委任事務の履行で得られる「成果」に対して報酬を定める類型が整理されました。
実務ではこれを「成果完成型」と呼びます。
成果に対して報酬が発生し（成果の引渡しを要するときは引渡しと同時に支払う形です）、それでも請負のような仕事の完成義務や契約不適合責任は負わない、という点が請負との違いです。
ただし準委任でも善管注意義務は残り、その違反は別途、債務不履行責任の対象になり得ます。
システム開発の実務では、要件定義・基本設計・受入テスト・導入支援など「やるべきことが事前に固まりにくい工程」は準委任が向いているとされます。
逆に、仕様が固まった実装フェーズは請負で完成責任を負う、という使い分けが一般的です。
契約類型は「準委任だから楽」「請負だから安心」という単純な話ではありません。請負は受注者が完成リスクを負う代わりに、スコープが固まっていれば金額の見通しが立ちます。準委任は完成義務を負わない代わりに、発注者から見ると「いつ終わるか」が読みにくくなります。どちらが有利かは立場と工程で変わります。
この「契約類型ごとにリスクの所在が違う」という構造が、AIの話と直結します。
見積もりの議論は、結局のところ「どの類型で、どちらがリスクを持つか」の議論だからです。
見積もりがどう変わるか
工数という前提が揺らいでいる
受託開発の見積もりは、長らく「工数×単価」が基本でした。
「この機能を作るのに何人日かかるか」を積み上げ、リスクバッファを乗せて金額を出す、という構造です。
この方式が成り立っていたのは、「習熟した開発者が一定時間でこなせる量」がある程度予測できたからです。
工数は、品質と納期と価格を一本の線でつなぐ共通単位として機能してきました。
AIコーディングツールが普及するにつれて、この前提が揺らいできました。
同じ機能を実装するのにかかる時間が、開発者のAI活用度合いによって大きく変わるようになったからです。
「1人日かかる作業が2時間で終わった」——私の周囲やPoC・限定的なタスクでは、こうした体験を聞くことが増えました。
このとき、「早く終わったのだから安くなるはずだ」という発想は自然です。
しかし同時に、「早く終わったのは経験と判断力があったからだ」という側面も否定できません。
AIに的確な指示を出し、出力の良し悪しを見抜き、危ういコードを弾く——この判断力こそが、時短の正体である場合が多いからです。
工数が成果と分離し始めたことで、「何時間使ったか」ではなく「何を作り上げたか」で価値を測る方向への関心が高まっています。
見積もりモデルとリスクの所在
見積もりを考えるうえで避けて通れないのが、「コスト超過のリスクを誰が負うか」です。
代表的なモデルを、リスクの所在とあわせて整理します。
| モデル | 近い契約類型 | コスト超過リスクの所在 | 向いている場面 |
|---|---|---|---|
| 固定価格 | 請負 | 受注者 | スコープが固まっている |
| 実費＋工数（T&M） | 準委任（履行割合型） | 発注者 | スコープが不確定 |
| 成果報酬 | 成果完成型準委任に近い | 双方で分担 | 成果が定義できる |
| サブスク型保守 | 準委任の継続 | 双方で分担 | 継続的な運用が前提 |
固定価格は、見積もりを外すと受注者が損をします。
だからこそ従来は、不確実性に備えてバッファを厚く積む動機が働きました。
T&Mは実費精算なので受注者のリスクは小さい代わりに、発注者から見ると総額が読みにくく、予算超過を防ぐために期間や上限額（price cap）を設けることが多いです。
AIが効いてくるのはここです。
AIによって「実装にかかる時間」の不確実性が下がる一方、「AIが出した成果の品質をどこまで保証できるか」の不確実性は上がります。
時間リスクが減り、品質リスクが増える——この入れ替わりが、固定価格のバッファの置き場所を変えます。
従来は「時間が読めないこと」に積んでいたバッファを、これからは「品質保証と検証」に積み替える発想が要ると感じています。
成果ベース・価値ベースへの移行——両論併記
移行を推す立場の論点：
- 顧客が本当に買っているのは「エンジニアの時間」ではなく「問題が解決された状態」です。
- AI活用で同品質のものがより短時間で作れるなら、生産性向上の恩恵は顧客にも届くべきという議論があります。
- 「いくら時間をかけたか」より「どんな価値があるか」のほうが発注者にとっても分かりやすい側面があります。
移行に慎重な立場の論点：
- 成果の定義が難しい領域では、「何が達成されれば完了か」の合意形成コストが上がります。
- AI生成コードの品質にばらつきがあるなかで、「動いているが理解されていないコード」を成果物として認めるかは別の問題です。
- 価値ベースの価格付けは、顧客が価値をどう測るかに依存するため、認識ずれが起きやすいリスクがあります。
どちらが正しいかは、案件の性質・顧客の成熟度・関係性によって変わります。
私が感じているのは、「工数ベースから脱却しよう」という圧力が強まっているのと同時に、受け皿となる新しいモデルがまだ実務として固まっていない、という状況です。
だからこそ、いきなり成果報酬に飛ぶより、まず契約類型とリスクの所在を見直すところから始めるのが現実的だと考えています。
契約条項の論点
AI生成物の責任と著作権
AIツールを使って生成したコードを納品する場合、いくつかの論点が発生します。
著作権の帰属：
文化庁は2024年3月に「AIと著作権に関する考え方について」を公表しています。
ここでの整理を私なりに要約すると、AI生成物の著作物性は一律に決まるものではなく、個別具体的に判断されます。
判断の要素として、指示・入力（プロンプト等）の分量・内容、生成の試行回数、複数の生成物からの選択といった「人間の創作的寄与」がどれだけ積み重なっているかが挙げられています。
また、AI自身は法的な人格を持たないため著作者にはなり得ず、著作物に該当する場合は「AIを使って創作した人」が著作者になる、とされています。
つまり「AIが出力したコードに著作権があるか／誰のものか」は、使い方によって変わり得るグレーな領域です。
だからこそ、「AI生成物を含む成果物の著作権は誰に帰属するか」を契約で明示しておくことの価値が、以前より上がっていると思っています。
ここは解釈が固まりきっていない領域です。本記事の記述は2026年6月時点で公開されている資料を参照した一般的な整理であり、個別の案件は弁護士など専門家への確認を前提にしてください。
ライセンス汚染のリスク：
見落とされがちですが、実務でより怖いのはこちらだと感じています。
生成AIが学習データ由来のコードを出力し、気づかないうちにOSS——特にGPLのようなコピーレフト型ライセンスのコード——を成果物に混ぜ込んでしまうリスクです。
コピーレフトには伝播性があり、組み込むと派生物全体を同じライセンスでソース公開する義務が生じる場合があります。
商用の受託案件でこれが起きると、納品物のライセンス前提が崩れかねません。
対策として、GitHub Copilot には公開コードと一致する提案をブロックする設定や、提案が公開コードを参照しているかを示す機能が用意されています。
また Microsoft は、著作権侵害が生じた場合の補償方針（Copilot Copyright Commitment）を2023年9月に公表しています。
ただしツール側の対策に丸投げするのではなく、「どのAIツールを、どの設定で使うか」を発注者と合意し、ライセンススキャンを検収プロセスに入れておくのが安全だと考えています。
秘密保持との整合：
顧客が守秘義務を求めているプロジェクトで、プロンプトやコードをクラウドのAIサービスに送信することが秘密保持条項に抵触しないか——この確認も必要です。
どのAIツールを使うかは、利便性だけでなく、契約上の情報の取り扱いと合わせて決めるべき事項になっています。
契約不適合責任との関係：
2020年4月施行の改正民法で、従来の「瑕疵担保責任」は「契約不適合責任」に変わりました。
救済手段として、従来の損害賠償請求・契約解除に加えて、履行の追完請求・代金（請負では報酬）の減額請求が認められています。
請負では、目的物の種類・品質に関する不適合について、発注者が不適合を知った時から1年以内に通知しないと権利行使ができない、という期間制限もあります。
ただし、請負人が不適合を知っていた、または重大な過失で知らなかった場合などは、この期間制限の対象外とされています。
ここでAI特有の論点が乗ります。
AI生成コードに起因するバグや脆弱性が生じたとき、責任は契約類型・検収条件・契約不適合（瑕疵）条項・責任制限の設計、そして顧客の指示や承認の範囲によって変わります。
一般には請負で受注者が品質責任を負う場面が多いですが、契約設計によって分担は変わり得ます。
いずれにせよ「AIが出力したので検証できていない」は免責の根拠にはなりにくく、この点は契約上明文化しておく価値があると思っています。
再現性の問題
ソフトウェア開発の成果物には、一定の再現性が期待されます。
同じ入力を与えれば同じ出力が得られる、同じ環境を構築すれば動作する、という前提です。
AIツールを使った開発では、このプロセスの再現性が変わります。
「どのプロンプトを使ったか」「どのモデルのどのバージョンか」が成果物の再現に関係するケースが出てきます。
モデルは更新され、同じプロンプトでも出力が変わり得るため、「作り方の再現」は従来より難しくなりがちです。
契約上の問題として出てくるのは、「保守・拡張ができる状態で納品する」という条件の解釈です。
AIを使って作ったが、どう作ったかを引き継げない場合、その成果物は保守可能と言えるのか——という問いは、まだ実務として答えが出ていません。
私は、再現すべきは「生成の過程」ではなく「成果物そのものと、それを理解・変更するために必要な情報」だと整理するようにしています。
成果物定義の変化
コードだけが成果物ではなくなる
従来の受託開発における成果物は、おおむね「動くコードと仕様書」でした。
AIが前提になると、成果物の範囲が広がります。
運用・継続のための設計：
AIエージェントを使った自動化ワークフローを開発・納品する場合、「そのエージェントをどう運用するか」の設計も成果物に含まれます。
プロンプトの版管理、モデルの切り替え手順、失敗時の対応フロー——これらが整備されていなければ、納品後に顧客が詰まります。
引き継ぎ可能性：
誰が引き継いでも動かせること、は以前からの要件です。
ただし、AI活用前提の開発では「どのツールを使い、どういう判断をしたか」という開発文脈の引き継ぎが加わります。
コードは読めるが、なぜそういう設計になったかが誰にも分からない状態は、AIを使うほど起きやすくなります。
テストと検証の設計：
AI生成コードはそれらしく見えて動かない、あるいは特定の入力にだけ失敗する、というケースがあります。
「どういうテストで検証したか」を成果物の一部として定義することは、品質保証の観点で重要性が増していると感じています。
検証の設計は、前述の「品質保証にバッファを積み替える」という見積もりの話とも地続きです。
成果物の定義を先に合意する
契約前に「何が完成状態か」を言語化する重要性は以前からありましたが、AI時代にはさらに高まっていると思っています。
理由は、AIを使うと「動くプロトタイプ」が早い段階で出来上がるからです。
動いているものを見た顧客が「これで完成ですね」と受け取るケースと、開発者が「まだ品質が要件を満たしていない」と考えるケースのギャップが起きやすくなります。
ここで前述の契約類型が効いてきます。
要件が固まりきらない初期は準委任で探索し、固まった段階で請負に切り替える——IPA・経済産業省が公開している「情報システム・モデル取引・契約書」も、工程ごとに契約を分ける多段階契約の考え方を採っています。
アジャイル開発版（2020年）は準委任を前提に組まれており、「作りながら決める」前提と契約類型を合わせています。
「動く」と「完成」は別だ、という合意を、契約の組み方そのものに織り込む発想が要ると感じています。
リスクと向き合い方
「自動化できます」の先にあるもの
AIを使った開発提案で「この業務を自動化できます」という言葉は使いやすくなりました。
実際、以前なら数ヶ月かかった開発が数週間でできるケースもあります。
問題は、「自動化できる」と「自動化したあとのリスクを誰が引き受けるか」が別の話だということです。
自動化したワークフローが想定外の入力でエラーを起こす、AIの出力が業務上の判断として不適切だった——こういったケースが起きたとき、責任の所在を事前に合意していないと関係が壊れます。
これは新しい問題ではなく、システム開発全般に通底する問題です。
ただしAI活用により「自動化の対象範囲」と「想定外ケースの発生頻度」が変わるため、リスク分担の合意をより丁寧に行う必要性が高まっています。
そしてこの「誰が引き受けるか」は、最終的には契約類型と責任制限条項の話に落ちます。
固定価格の請負で全部受注者が負うのか、準委任で発注者と分担するのか——リスクの議論は、見積もりと契約の議論に必ず戻ってきます。
誠実に「分からない」を言う
私が実務で気をつけているのは、AIを使うことで「できる」の閾値が下がった分、リスクについて曖昧なまま進めやすくなっている、という点です。
「AIがあれば早くできる」は本当のことが多いです。
一方「どんな品質になるか」「保守はどうなるか」「エラーが出たらどうするか」——これらは以前より不確実性が高いと思っています。
「分からない」ことを「分からない」と顧客に伝えることは、短期的には受注の障壁になることがあります。
しかし、それを曖昧にしたまま進めると、後で取り返しがつきにくくなります。
不確実性を正直に共有し、そのうえでどう進めるかを一緒に考える——というスタンスが、AI時代においてもっとも持続可能な関係性だと、私は考えています。
まとめ
AI以後の受託開発における実務の変化を、契約類型という土台のうえに、見積もり・契約・成果物定義・リスクの4つの軸で整理しました。
- 見積もりは工数からアウトカムへの移行圧力がかかっていますが、受け皿となるモデルはまだ発展途上です。まず契約類型とリスクの所在を見直すのが現実的です。
- 契約条項はAI生成物の著作権・ライセンス汚染・再現性・秘密保持について、明示的な合意が必要です。契約不適合責任の枠組みも踏まえる必要があります。
- 成果物の定義は「動くコード」から「動かし続けられる設計と引き継ぎ情報」まで広がっています。
- リスクの分担は、契約類型と責任制限の選択とセットで丁寧に合意する重要性が増しています。
どれも「こうすれば正解」という答えがある話ではありません。
法律や契約の細部は専門家の領域であり、私は実務者として「どこを意識して専門家と話すか」を整理しているにすぎません。
自分なりの試行錯誤をしながら、少しずつ実務を整えている途中です。
同じ立場で悩んでいる方の参考になれば嬉しいですし、「自分はこうしている」という実践があればぜひ教えていただければと思います。
参考
- AI以後の受託システム開発はどうなっていくのか（2026年6月版） — terurou（Zenn、2026年6月）。総論として参考にしました。
- AIで自動化できます。で、そのリスクは誰が飲むんですか — continuitymodel（Zenn、2026年6月）。「リスクと向き合い方」の節を書くきっかけになりました。
- 準委任契約・請負契約とは？違いと基本をわかりやすく解説 — BUSINESS LAWYERS。請負と準委任の違いの整理。
- 準委任契約の成果完成型とは？ — Workship ENTERPRISE。成果完成型準委任（2020年改正民法）の解説。
- 契約不適合責任とは？2020年の民法改正で何が変わった？ — GMOサイン。契約不適合責任への変更点。
- AIと著作権について — 文化庁。「AIと著作権に関する考え方について」（2024年3月）。
- GitHub Copilot使用の2つの法律リスクを弁護士が解説 — レバテックLAB。OSSライセンス混入リスク。
- 情報システム・モデル取引・契約書 — IPA・経済産業省。多段階契約・アジャイル開発版。