準委任と請負の違い｜AI開発を外注する前に

AI開発やシステム開発を外注しようとして、見積書と一緒に契約書の案が届いたとき、多くの方が最初につまずくのが「準委任契約」と「請負契約」のどちらなのかという点です。

「業務委託契約書」と書いてあるのに中身は準委任だった、という場面もよくあります。名前だけでは判断できません。そして、この違いは「完成しなかったときにお金を払うのか」「途中でやめられるのか」「不具合が出たとき直してもらえるのか」という、発注側にとって最も重要な部分に直結します。

本記事では、民法の条文を実際に確認したうえで、AI開発を外注する中小企業の発注側という一点に絞って整理します。契約類型の一般論だけを並べるのではなく、「AIの開発はなぜ請負になじみにくいのか」「では何を決めておけば安全に進められるのか」まで踏み込みます。

結論｜AI開発は準委任が基本になる

先に結論からお伝えします。

違いは「完成を約束するか」

両者の差は、極端に言えば一点に集約されます。

• 請負＝受注側が「仕事を完成させること」を約束する契約
• 準委任＝受注側が「事務を適切に処理すること」を約束する契約

請負では、完成しなければ原則として報酬は発生しません。準委任では、完成を約束していないので、適切に作業していれば完成に至らなくても報酬が発生しうる、という構造になります。

ここだけ聞くと「発注側は絶対に請負のほうが得だ」と感じるはずです。実際、その直感は半分正しく、半分は誤解です。理由は次の項で説明します。

AIは完成の事前定義が難しい

請負が発注側に有利に働くのは、「完成」が誰の目にも同じように見える場合だけです。建物であれば図面どおりに建っているかで判断できます。給与計算システムであれば、仕様書どおりの金額が出るかで判断できます。

ところがAIを使った開発では、この「完成」が事前に書けません。たとえば「問い合わせメールを自動で分類する仕組み」を発注したとして、完成とは何でしょうか。

• 分類できれば完成なのか
• 正解率90%で完成なのか
• その90%は、どのデータで測った90%なのか
• 想定外の問い合わせが来たときに間違えたら、未完成なのか

これらを契約時点で数値と測定方法まで含めて決められるなら請負が成立します。決められないまま「一式」で請負契約を結ぶと、完成したかどうかで揉めるという、最も避けたい事態になります。発注側は「使えないから未完成だ」と言い、受注側は「仕様どおりに作った」と言う。この対立は契約書に完成の定義が書かれていない限り、話し合いでは決着しません。

それでも請負が向く場面はある

ただし、AI関連の案件がすべて準委任になるわけではありません。やることが完全に固まっている部分は請負に向きます。

たとえば「既存の勤怠システムからCSVを取り出し、決まった書式のExcelに変換する」という処理は、AIを一部で使っていたとしても、入力と出力が確定しているので完成を定義できます。この部分は請負でも問題ありません。

つまり実務上の答えは「案件全体をどちらか一方に決めない」ことです。この点は後述する「多段階契約」の項で詳しく扱います。

民法上の定義を条文で確認する

感覚で語ると誤解が生まれるので、条文を確認します。以下はいずれもe-Gov法令検索「民法」で確認できます。

請負とは何か（民法632条）

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

「請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。」

ポイントは「仕事を完成することを約し」と「その仕事の結果に対して」報酬を払うという二点です。報酬は結果に対して支払われます。

なお、仕事が完成しなかった場合に一切支払いが生じないかというと、そうではありません。民法第634条は、注文者の責めに帰することができない事由で完成できなくなったとき、または完成前に解除されたときに、可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなし、請負人は利益の割合に応じた報酬を請求できると定めています。「完成しなければ1円も払わない」と単純化するのは正確ではありません。

準委任とは何か（民法656条）

まず委任について、民法第643条は「委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。」と定めています。

そして民法第656条が「この節の規定は、法律行為でない事務の委託について準用する。」と定めており、これが準委任です。法律行為ではない事務（システム開発の作業など）を委託する場合は準委任にあたり、委任の規定が準用されます。

準委任で中心になるのが民法第644条です。「受任者は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う。」いわゆる善管注意義務です。完成の約束はしませんが、専門家として適切な注意を払って作業する義務は負います。

また民法第645条により、受任者は委任者の請求があればいつでも処理状況を報告し、終了後は遅滞なく経過と結果を報告しなければなりません。準委任は「報告を求める権利」が条文上明記されているという点は、発注側として覚えておく価値があります。

準委任には2つの型がある

実務でよく混乱するのがここです。準委任には報酬の決め方によって2つの型があります。

ひとつは履行割合型です。民法第648条は、受任者は特約がなければ報酬を請求できないこと、報酬を受けるべき場合は委任事務を履行した後でなければ請求できないことを定め、第3項で「委任者の責めに帰することができない事由によって委任事務の履行をすることができなくなったとき」「委任が履行の中途で終了したとき」には既にした履行の割合に応じて報酬を請求できるとしています。工数（人月・人日）に応じて支払う形がこれにあたります。

もうひとつが成果完成型です。民法第648条の2は「委任事務の履行により得られる成果に対して報酬を支払うことを約した場合において、その成果が引渡しを要するときは、報酬は、その成果の引渡しと同時に、支払わなければならない。」と定め、第2項で前述の第634条を準用しています。

つまり「準委任だから成果物がなくてよい」というのは誤りで、成果に報酬を紐づける準委任も条文上存在します。契約書に「準委任」とだけ書いてある場合、どちらの型なのかを必ず確認してください。

用語の整理｜業務委託契約とは

ここも実務で頻繁に誤解される点です。「業務委託契約」という契約類型は民法にありません。民法が定めているのは請負（632条以下）と委任・準委任（643条以下）です。

「業務委託契約書」というタイトルは、実務上の呼び名にすぎません。中身が請負のこともあれば準委任のこともあり、両方が混ざっていることもあります。したがってタイトルではなく条項の中身で判断する必要があります。

判断の手がかりは次のとおりです。

• 「完成」「検収」「引渡し」という言葉が中心にあれば請負寄り
• 「作業」「稼働」「人月」「善管注意義務」が中心にあれば準委任寄り
• 「本件業務の遂行により得られた成果物」に報酬が紐づいていれば成果完成型の準委任の可能性

迷ったら「完成しなかったら報酬はどうなるか」を受注側に文書で確認してください。その回答が、実質的にどちらの契約かを示します。

違いを7つの観点で比較する

比較表で全体をつかむ

観点	請負	準委任
約束する内容	仕事の完成（民法632条）	事務の適切な処理（民法644条の善管注意義務）
報酬の対象	仕事の結果	履行割合型は作業、成果完成型は成果（民法648条・648条の2）
完成しなかった場合	可分な部分で注文者が利益を受けるなら割合報酬（民法634条）	既にした履行の割合に応じた報酬（民法648条3項）
不具合への対応	契約不適合責任（民法559条により売買の規定を準用）	専用の規定はなく、善管注意義務違反として判断されるのが基本
期間制限	不適合を知った時から1年以内の通知が必要（民法637条）	請負のような通知期間の規定はない
途中解除	注文者は完成前ならいつでも損害を賠償して解除可（民法641条）	各当事者がいつでも解除可、時期等により損害賠償（民法651条）
向いている場面	要件と完成基準を先に確定できる開発	やりながら決める要素が大きい開発・調査・運用支援

報酬｜何に対して払うか

請負は結果に払います。準委任の履行割合型は作業に払います。この違いが、発注側の見積の読み方を変えます。

請負の見積は「一式いくら」で出てくることが多く、内訳が見えません。見えない代わりに、超過分のリスクは受注側が負います。ただし受注側もリスクを織り込むため、単価は高めになるのが通常です。

準委任の見積は「月◯人日で単価いくら」という形になります。透明ですが、伸びれば伸びるほど費用が増えます。だからこそ上限工数（キャップ）を契約書に書くことが実務上の防御になります。「◯人日を超える場合は事前に書面で合意する」の一文があるだけで、青天井は避けられます。

責任｜契約不適合責任の有無

2020年4月1日施行の改正民法により、従来の「瑕疵担保責任」は「契約不適合責任」に整理されました。請負については、民法第559条が「この節の規定は、売買以外の有償契約について準用する。ただし、その有償契約の性質がこれを許さないときは、この限りでない。」と定めており、売買の契約不適合責任の規定が準用されます。

売買の側では民法第562条第1項が「引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、買主は、売主に対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。」と定めています。

ここで発注側が最も注意すべきなのは、条文が「契約の内容に適合しない」と書いている点です。つまり契約に書いていないことは、契約不適合になりません。「思っていたのと違う」は理由になりません。請負にしたから安心、ではなく、契約書に何を書いたかがすべてということです。

また、民法第636条は、注文者が供した材料の性質や注文者が与えた指図によって生じた不適合については、原則として追完請求・報酬減額請求・損害賠償請求・契約の解除ができないと定めています（請負人がその材料や指図が不適当であることを知りながら告げなかったときを除く）。発注側が渡したデータや指示に起因する問題は、発注側の責任になりうるという点は、AI開発では特に重要です。学習や検証に使うデータを発注側が提供するケースが多いためです。

準委任については、請負のような契約不適合責任の規定は置かれていません。責任の有無は、善管注意義務（民法644条）を尽くしたかどうかで判断されるのが基本です。なお、成果完成型の準委任における不適合の扱いについては専門的な議論があるため、この点は必ず弁護士にご確認ください。

解除｜途中でやめられるか

途中でやめられるかどうかは、発注側にとって現実的に最も重要な論点のひとつです。

請負については民法第641条が「請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる。」と定めています。完成前であれば注文者側から解除できるという規定です。ただし「損害を賠償して」とある点に注意が必要です。

準委任については民法第651条第1項が「委任は、各当事者がいつでもその解除をすることができる。」と定めています。第2項は、相手方に不利な時期に解除したとき、または委任者が受任者の利益（専ら報酬を得ることによるものを除く）をも目的とする委任を解除したときは、相手方の損害を賠償しなければならない（やむを得ない事由があったときを除く）としています。

実務上は、これらの規定と異なる内容が契約書に特約として書かれていることが少なくありません。解除条項が民法の原則と違う書き方になっていないかは、必ず確認してください。「中途解約の場合、残期間の報酬全額を支払う」といった条項が入っていることもあります。

指揮命令｜偽装請負の線引き

ここは発注側が加害者側になりうる論点です。準委任や請負で受け入れた外部の担当者に対して、発注側が直接、業務の遂行方法や労働時間を指揮命令すると、実態として労働者派遣と判断されるおそれがあります。

この区分の基準を示しているのが、いわゆる37号告示（労働者派遣事業と請負により行われる事業との区分に関する基準）です。厚生労働省は「37号告示に関する疑義応答集（第2集）」などで具体的な考え方を示しており、契約の形式ではなく実態に即して判断されるとされています。

AI開発では、発注側の担当者と受注側のエンジニアが同じチャットで密にやり取りすることが多く、この線引きが曖昧になりがちです。実務上の対応としては、次のようにしてください。

• 指示は「何を実現したいか」の単位で出し、「誰がどの時間にどう作業するか」は受注側の管理者に委ねる
• 受注側に責任者を1名立ててもらい、そこを窓口にする
• 個々のメンバーの勤怠管理や残業指示を発注側が行わない

AI開発が請負になじみにくい理由

ここからが本記事の本題です。一般的な契約解説には出てこない、AI固有の事情を整理します。

理由1｜精度を先に約束できない

AIを使った処理の精度は、実際にデータを入れてみるまで分かりません。同じ「文書の分類」でも、業界用語が多い文書と定型的な文書では結果が変わります。

したがって受注側が契約時点で「正解率95%を保証します」と書くことは、通常できません。書ける場合は、すでに同種の案件を経験していて見通しが立っているか、あるいは相当な余裕を単価に上乗せしているかのどちらかです。

発注側の実務的な対応は、精度そのものを完成条件にするのではなく、「精度を測る手順」と「基準に届かなかった場合の扱い」を契約に書くことです。「テスト用に発注側が用意した100件で判定し、80件以上で合格。届かない場合は◯週間の改善期間を設け、それでも届かない場合は◯◯とする」という形です。

理由2｜正解データが最初にない

精度を測るには、正解が分かっているデータが必要です。ところが多くの中小企業では、この正解データが存在しません。過去の処理結果はあっても、担当者の頭の中にある判断が記録されていないためです。

そのため、開発の初期には「何が正解かを決める作業」そのものが発生します。これは受注側だけでは実行できず、発注側の業務知識が必須です。完成を受注側だけの責任にする請負契約は、この構造と相性が悪くなります。

理由3｜モデルや前提が変わる

AIサービスは、提供元によるモデルの更新や仕様変更が起こります。契約期間中に前提が変わることは、通常のシステム開発より起きやすいと考えておくべきです。

この場合、請負契約で「完成」を固定していると、完成後に挙動が変わったときの扱いが宙に浮きます。「外部サービスの仕様変更に起因する修正は、保守契約の範囲とする／別途見積とする」といった切り分けを、最初から書いておく必要があります。

理由4｜業務側の仕様が動く

AI導入の現場では、動くものを触った瞬間に業務側の要望が変わります。「思っていたより使えるので、この処理も任せたい」「この項目は要らなかった」といった変化は、失敗ではなく正常な反応です。

しかし請負契約でこれをやると、そのたびに仕様変更として追加見積が必要になり、手続きだけで時間が溶けます。準委任であれば優先順位の入れ替えとして処理できるため、初期の探索段階には向きます。

実際、IPAが2020年に公開した「情報システム・モデル取引・契約書（アジャイル開発版）」は、機能の追加・変更や優先順位の変更に柔軟に対応する開発手法であることを踏まえ、準委任契約を前提としたモデル契約として作られています。同ページでは契約書のひな型のほか、契約前チェックリストや進め方の指針も公開されています。

逆に請負にしやすいAI案件

一方で、次のような案件は請負でも進めやすくなります。

• 入力と出力の形式が完全に決まっている変換処理
• すでに手作業の手順書が存在し、そのとおりに自動化するだけの処理
• 既存システムとの連携部分（APIの仕様が公開されている）
• 画面やレポートの実装など、見た目で完成が判断できる部分

要は「完成した状態を、発注側と受注側が同じ言葉で書けるか」が分岐点です。書けるなら請負、書けないなら準委任、という判断で概ね間違いありません。

どちらを選ぶかの判断基準

3つの質問で仕分けする

難しく考えず、次の3つに答えてください。

1. 完成した状態を、数値と手順で書けますか。（例：この100件を入れて、この形式で出力され、80件以上が正しい）
2. その判定を、発注側が自分で実施できますか。（受注側の説明を聞かないと合否が分からないなら、書けていません）
3. 途中で要望が変わる可能性は低いですか。（変わる前提なら、請負は手続きが重すぎます）

3つとも「はい」なら請負が成立します。ひとつでも「いいえ」があるなら、その部分は準委任にしたほうが、結果的に双方の負担が軽くなります。

判断フローの早見表

状況	向いている契約	補足
何を作るかがまだ固まっていない	準委任（履行割合型）	期間と上限工数を必ず設定する
やることは決まったが精度が読めない	準委任（成果完成型も検討）	合否判定の手順を契約に明記する
仕様書があり完成条件を書ける	請負	検収基準と検収期間を明記する
既存システムとの決まった連携	請負	相手側システムの仕様変更時の扱いを決める
公開後の改善・運用	準委任	対応範囲と応答時間を定義する
調査・比較検討のみ	準委任	成果物（報告書）の粒度を決める

工程で分ける「多段階契約」

実務でもっとも合理的なのは、案件全体を一括で発注せず、工程ごとに区切って契約する方法です。IPAが公開している「情報システム・モデル取引・契約書（第二版）」も、工程を分けた多段階の契約を想定した構成になっています。モデル契約書そのものが無償で公開されているので、契約書案を受け取ったときの比較材料として目を通しておく価値があります。

中小企業向けに簡略化すると、次の3段階が現実的です。

1. 調査・要件整理（準委任）：2〜4週間。何を自動化するか、データはあるか、精度はどのくらい出そうかを確認する
2. 試作・検証（準委任）：2〜6週間。実データで動かし、合否を判定する
3. 本開発（請負または準委任）：ここで初めて完成条件が書けるようになる

この分け方の利点は、1段階目の終了時点で「やめる」という選択が取れることです。一括で請負契約を結ぶと、途中でやめる判断は解除の話になり、損害賠償の議論が発生します。段階を分けておけば、次の契約を結ばないだけで済みます。判断の基準そのものについてはAI導入をやめる判断基準に詳しくまとめています。

発注前に決めておく6項目

契約類型を決めるより先に、この6項目を書き出してください。これが決まっていれば、どちらの契約でも大きな事故は避けられます。

1. 検収の基準を数値で書く

最も重要です。「検収」という言葉だけがあり、その基準が書かれていない契約書は非常に多いのが実情です。

書くべき要素は次の4つです。

• 何を使って測るか：テストデータの件数と、誰が用意するか
• どう測るか：判定の手順と、判定する人
• いくつで合格か：具体的な数値
• いつまでに判定するか：検収期間（この期間を過ぎると検収したものとみなす、という条項が入っていることが多いので要確認）

特に検収期間の「みなし合格」条項は見落としがちです。「納品後7日以内に異議を述べない場合は検収完了とみなす」と書かれていて、その7日間に担当者が出張していた、という話は実際に起こります。自社が現実に確認できる期間かどうかで判断してください。

2. 追加開発の扱いを決める

AI導入は、動き始めてから追加要望が出るのが普通です。したがって追加のルールを最初に決めておくことが、揉めないための最大の防御になります。

決めるべき内容は次のとおりです。

• 追加要望はどの形式で出すか（口頭は不可、チャットでよいのか、書面が必要か）
• 何日以内に見積が返ってくるか
• どの規模までは追加費用なしで対応してもらえるか（軽微な修正の定義）
• 誰が承認したら着手してよいか

「軽微な修正」の定義がないと、受注側は「すべて追加」と考え、発注側は「これくらいは範囲内」と考え、必ず衝突します。作業時間で線を引く（例：1回あたり2時間以内の修正は範囲内）のが分かりやすい方法です。

3. 生成物の権利の帰属

AI開発では、成果物の権利が複数の層に分かれます。整理せずに「著作権は甲に帰属する」とだけ書くと、後で動かなくなることがあります。

対象	実務上の考え方
受注側が新たに書いたプログラム	発注側への譲渡を求めるか、利用許諾で足りるかを判断する
受注側が従来から持つ汎用部品	譲渡は通常困難。利用許諾の範囲と期間を確認する
オープンソースの利用部分	使用しているOSSとライセンス条件の一覧提出を求める
指示文（プロンプト）	誰が保有し、誰が改変できるかを明記する
発注側が提供したデータ	発注側に帰属することと、利用目的の限定を明記する

著作権の譲渡を受ける場合、注意すべき条文があります。著作権法第61条第2項は「著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。」と定めています。

実務では「著作権（著作権法第27条及び第28条の権利を含む）を譲渡する」という書き方をするのが一般的です。この記載がないと、翻案（改造）に関する権利が受注側に残っていると推定されることになります。あとで自社や別の会社が改修したいと考えているなら、ここは必ず確認してください。

加えて、AIが生成した文章や画像そのものの権利関係は、また別の論点になります。この点は生成AIと著作権で整理していますので、あわせてご確認ください。

4. 学習データと機密の扱い

発注側が提供したデータが、受注側の他案件や学習に使われないことを明記してください。確認すべきは次の点です。

• 提供データの利用目的を本件業務に限定しているか
• 契約終了後の消去義務と、消去したことの報告義務があるか
• 受注側が使う外部のAIサービス名が開示されているか
• そのサービスの規約上、入力内容が学習に使われない設定になっているか
• 再委託（下請け）を認めるか、認める場合は事前承諾を要するか

特に4点目は、受注側の担当者に口頭で聞くだけでなく、サービス名を教えてもらって発注側自身が規約を確認することをお勧めします。

5. 保守と引き継ぎの範囲

開発が終わった後のことを、開発前に決めておきます。ここが空欄のまま納品されると、翌月から動かなくなったときに誰も対応できません。

• 不具合対応の受付方法と、一次回答までの目安時間
• 外部サービスの仕様変更に起因する修正は、保守に含まれるか
• 月額の保守費用と、その範囲
• 契約終了時に引き渡されるもの（ソースコード、設計書、指示文、環境の情報）
• 担当者が交代しても運用できる説明書があるか

最後の項目は軽視されがちですが、中小企業では決定的です。A4で1枚、「何をするものか／どこにあるか／止まったときどうするか」が書かれた紙を納品物に含めてもらうだけで、引き継ぎの可否が変わります。

6. 中止したときの精算方法

始める前に「やめるときの話」をするのは気が引けますが、ここを決めておくほど安心して進められます。

• どのタイミングで中止の判断ができるか（段階の区切り）
• 中止した場合、その時点までの費用はどう精算されるか
• その時点までの成果物（コード、設計書、検証結果）は引き渡されるか
• 提供したデータは返還・消去されるか

3つ目の「途中までの成果物を受け取れるか」は特に重要です。準委任で工数に払っていたのに、途中でやめたら何も残らなかった、という状態は避けられます。「各段階の終了時に、その時点の成果物一式を引き渡す」という一文を入れておいてください。

見積が読めないときの進め方

まず小さく試す2〜4週間

「300万円の見積が来たが、妥当かどうか分からない」という相談は非常に多いです。この状態で判断しようとしても、材料がないので判断できません。

やるべきことは金額を値切ることではなく、範囲を小さくすることです。具体的には、最初の2〜4週間を準委任の調査・検証フェーズとして切り出し、そこだけを発注します。

この期間でやることは次の3つです。

1. 対象業務の現状の手順と所要時間を実測する
2. 実データを使って、AIがどの程度の精度で処理できるか試す
3. 本開発に必要な作業量の見通しを立てる

この3つが終われば、本開発の見積は「読める見積」になります。逆に言えば、これらが分からないまま出てくる一括見積は、受注側もリスクを見込んで多めに積んでいる可能性が高くなります。

検証の合否を先に決める

検証フェーズで最も多い失敗は、「やってみたけど、良かったのか悪かったのか分からない」という結果になることです。

これを防ぐには、開始前に合否の基準を1行で書いておきます。

• 「過去の問い合わせ100件で試し、70件以上が修正なしで送信できる下書きになれば合格」
• 「見積書10件を作成させ、金額の誤りが0件で、所要時間が現状の半分以下なら合格」
• 「担当者3名が2週間使い、3名とも継続を希望すれば合格」

基準は厳密でなくて構いません。重要なのは始める前に書いてあることです。後から基準を作ると、必ず結果に引きずられます。

本開発の見積が出る状態とは

次の情報が揃っていれば、まともな見積が出せる状態です。発注前に自社で確認してみてください。

項目	揃っているか
対象業務の手順が文章で書かれている	担当者の頭の中だけではないか
入力データの形式と件数が分かる	月に何件、どの形式で来るか
出力の形式が決まっている	どこに、どの形で出るか
例外パターンが洗い出されている	「こういうときはこうする」が列挙されているか
連携する既存システムが特定されている	製品名とバージョン、外部連携の可否
合否の判定基準が決まっている	数値で書けているか

この表の右側が埋まらない項目が多いほど、見積の精度は落ちます。埋まらないこと自体は問題ではありません。埋まらないまま一括で請負発注することが問題です。

発注側が用意すべきもの

準委任にせよ請負にせよ、発注側が用意しなければ前に進まないものがあります。ここが遅れると、費用は時間とともに増えます。

• 実データ（テスト用）：機密部分を伏せたものでよいので、実際の形式のもの
• 判断できる担当者の時間：週に1〜2時間の定例に出られる人
• 「正しい」の基準：何が正解かを答えられる人
• 既存システムの情報：管理会社の連絡先を含む
• 決裁のルート：追加要望が出たとき、誰が承認するか

逆に言えば、これらを出せる状態を作っておくことが、発注前にできる最大のコスト削減です。自社で先に手をつけられる範囲については業務効率化のアイデアも参考にしてください。

モデルケース｜3つの発注例

前提と注記

例1｜問い合わせ返信の下書き

問い合わせメールに対する返信の下書きをAIに作らせ、担当者が確認して送信する構成です。

• 現状：1件あたり15分、1日20件、担当2名
• 削減見込み：1件あたり15分→7分。1日で20件×8分＝約160分
• 月換算：160分×20日＝約53時間。時給2,500円換算で月あたり約13万円相当

契約の考え方：この案件は精度が事前に読めないため、最初は準委任の検証フェーズを推奨します。「過去の返信100件で試し、70件以上が軽微な修正で送信できる」という合否基準を先に決めます。合格後、テンプレートの整備や画面の実装などやることが確定した部分だけを請負に切り出す形が現実的です。

例2｜見積書の自動作成

過去の見積と商品マスタをもとに、AIが見積書の草案を作る構成です。

• 現状：1件あたり40分、月60件、担当1名
• 削減見込み：1件あたり40分→15分。月60件×25分＝約25時間
• 月換算：25時間×2,500円＝約6万円相当

契約の考え方：金額の誤りが直接的な損失につながるため、検収基準を厳格に書く必要があります。「10件作成し、金額の誤りが0件」といった基準です。この案件は出力形式が確定しているため、要件整理を準委任で行った後、本開発を請負にしやすいタイプです。ただし「AIが金額を最終決定しない（人が承認する）」設計にすることを強く推奨します。

例3｜社内文書の検索

過去の議事録・マニュアル・仕様書を対象に、質問すると該当箇所を提示する構成です。

• 現状：「あの資料どこ？」の探索が1人1日15分、対象10名
• 削減見込み：15分→5分。1日10名×10分＝約100分
• 月換算：100分×20日＝約33時間。時給2,500円換算で月あたり約8万円相当

契約の考え方：この種の案件は「どの文書を対象にするか」で工数が大きく変わります。文書の整理状況を確認しないまま一括見積を取ると、必ず追加が発生します。対象文書の棚卸しを準委任で先に実施し、範囲が確定してから本開発の見積を取るのが安全です。また、閲覧権限の制御を要件に含めるかどうかで難易度が変わるため、初期段階で明示してください。

よくある失敗と回避策

完成の定義が言葉だけ

「業務が効率化されること」「実用に耐えるレベルであること」といった記載は、契約上ほぼ機能しません。前述のとおり、契約不適合は「契約の内容に適合しないこと」が前提です。契約に数値がなければ、判断の基準もありません。

回避策：契約書に検収基準の別紙を付けてください。本文を修正するより、別紙を作るほうが受注側も応じやすくなります。

準委任なのに成果物を期待

「準委任だから納品物はない」と受注側が言い、発注側は当然あると思っていた、という食い違いです。前述のとおり、準委任にも成果完成型があり、成果物を定義することは可能です。

回避策：準委任であっても「各月末に提出する成果物」を列挙してください。作業報告書、動作するプログラム一式、設定手順書、といった形です。これは民法第645条の報告義務とも整合します。

権利の条項を読み飛ばす

契約書の後半にある権利条項は、締結時にはあまり関心を持たれません。しかしこの会社に不満が出て別の会社に頼みたくなったときに、初めて重要性が分かります。

回避策：締結前に「別の会社に引き継ぐことになった場合、何が渡されますか」と1問だけ質問してください。回答が明確でなければ、その部分を契約に書いてもらいます。会社選びの観点はAI導入支援会社の選び方にまとめています。

発注側が直接指示してしまう

前述の偽装請負の論点です。悪意なく起こるのが厄介な点で、「急ぎなので直接お願いします」の積み重ねが実態を作ります。

回避策：受注側の責任者を明確にし、依頼は「何を実現したいか」で出します。個々のメンバーへの作業指示や勤務時間の指定は避けてください。判断に迷う場面は厚生労働省の疑義応答集が具体例を挙げています。

一括で大きく発注してしまう

最も損失が大きい失敗です。まだ何を作るか決まっていない段階で、半年分・数百万円分を一括で契約してしまうと、途中で方向転換したくなったときに身動きが取れなくなります。

回避策：段階を分けてください。1段階目を小さくすることで、相手の実力も判断できます。試作段階で動くものを触りながら方向を決める進め方についてはバイブコーディングもあわせてご覧ください。

契約書で必ず見る条項チェック

チェックリスト

契約書案を受け取ったら、次の項目にチェックを入れてみてください。空欄が多いほど、後で揉める確率が上がります。

確認項目	見るべきポイント
契約類型	請負か準委任か。準委任なら履行割合型か成果完成型か
業務範囲	やらないことも書かれているか
成果物	提出物が名前で列挙されているか
検収	基準・期間・みなし合格の有無
報酬・上限	準委任なら上限工数と超過時の手続き
支払時期	着手金の割合と支払サイト
契約不適合責任	期間の定めが民法と異なっていないか
知的財産権	著作権法27条・28条の権利が明記されているか
秘密保持	提供データの利用目的限定と消去義務
再委託	事前承諾の要否と、再委託先の責任
解除	民法と異なる特約が入っていないか
損害賠償	上限額が定められているか、その額は妥当か
引き継ぎ	終了時に何が渡されるか

すべてを自社で判断する必要はありません。この表を持って弁護士に相談すると、確認の時間が短くなります。

取適法（旧下請法）の基本

発注側の規模によっては、下請法（2026年1月1日施行の改正により「中小受託取引適正化法／通称・取適法」に名称変更）の適用対象になる場合があります。ソフトウェア開発の委託は情報成果物作成委託として対象に含まれます。

適用される場合、委託事業者には発注内容等の明示義務、支払期日を給付の受領後60日以内に定める義務、書類の作成・保存義務などが課され、代金の減額、買いたたき、不当なやり直しの要求などが禁止されます。適用の有無は資本金や従業員数の基準で判断されるため、詳細は公正取引委員会「取適法の概要」およびよくある質問コーナーをご確認ください。

発注側として実務的に重要なのは、「仕様を後から変えたのに、費用も納期も据え置きで作り直させる」といった対応が問題になりうるという点です。追加が発生したときに、きちんと見積を取り直す運用にしておいてください。

よくある質問（FAQ）

Q. 結局どちらが発注側に有利ですか？

A. 一概には言えません。完成条件を明確に書ける案件では請負のほうが発注側の保護は厚くなります。しかし完成条件を書けないまま請負にすると、「完成したかどうか」で争うことになり、かえって解決が遠のきます。有利かどうかは契約類型ではなく、契約書に何を書けたかで決まります。

Q. 準委任だと完成しなくてもお金を払うのですか？

A. 履行割合型の準委任では、民法第648条第3項により、委任者の責めに帰することができない事由で履行できなくなったとき、または中途で終了したときに、既にした履行の割合に応じた報酬が請求できるとされています。ただし、これは善管注意義務（民法644条）を尽くしていることが前提です。作業の質に問題があった場合の扱いは個別判断になるため、専門家にご相談ください。

Q. 請負なら完成まで一切払わなくてよいですか？

A. そうとは限りません。民法第634条は、注文者の責めに帰することができない事由で完成できなくなったとき、または完成前に解除されたときに、可分な部分の給付によって注文者が利益を受けるときは、その部分を完成とみなし、利益の割合に応じた報酬を請求できると定めています。また実務上は着手金の支払いが契約で定められていることが多くあります。

Q. 契約書のタイトルが「業務委託契約書」です

A. 民法に「業務委託契約」という類型はありません。中身を見て、請負か準委任か（あるいは両方が混在しているか）を判断する必要があります。判断の手がかりは「完成」「検収」があるか、「作業」「稼働」「善管注意義務」が中心かです。分からない場合は、受注側に「完成しなかった場合の報酬の扱い」を文書で確認してください。

Q. 不具合はいつまで直してもらえますか？

A. 請負については、民法第637条第1項が、注文者が不適合を知った時から1年以内にその旨を請負人に通知しないときは、追完請求・報酬減額請求・損害賠償請求・契約の解除ができないと定めています。同条第2項により、引渡時に請負人が不適合を知っていたか重大な過失で知らなかったときは、この制限は適用されません。ただし契約で異なる期間が定められている場合も多いため、必ず契約書の記載を確認してください。

Q. 自社が渡したデータが原因の不具合は？

A. 民法第636条は、注文者が供した材料の性質または注文者が与えた指図によって生じた不適合を理由として、追完請求・報酬減額請求・損害賠償請求・契約の解除をすることができないと定めています（請負人がその材料や指図が不適当であることを知りながら告げなかったときを除く）。AI開発では発注側がデータを提供する場面が多いため、提供したデータの品質は発注側の責任範囲になりうると認識しておいてください。

Q. 途中でやめたくなったらどうなりますか？

A. 請負については民法第641条により、請負人が仕事を完成しない間は、注文者はいつでも損害を賠償して解除できます。準委任については民法第651条第1項により、各当事者がいつでも解除できます（第2項の損害賠償の定めに注意）。ただし契約書に特約がある場合はそちらが優先される場面があるため、解除条項を必ず確認してください。実務的には、段階を分けて契約し、次の段階を発注しないという形が最も摩擦が少なくなります。

Q. 準委任だと成果物がもらえないのですか？

A. そのようなことはありません。民法第648条の2は成果に対して報酬を支払う準委任（成果完成型）を定めていますし、履行割合型であっても契約で成果物を定義することは可能です。また民法第645条により、受任者は委任者の請求があればいつでも処理状況を報告する義務を負います。「準委任なので報告はしません」は条文上の根拠がありません。

Q. 作ったAIの権利は誰のものになりますか？

A. 契約の定めによります。何も書かなければ、受注側が作成したプログラムの著作権は受注側に発生するのが原則です。譲渡を受ける場合、著作権法第61条第2項により、第27条・第28条の権利が譲渡の目的として特掲されていないときはこれらの権利は譲渡した者に留保されたものと推定されます。後で自社が改修したいなら、この記載の有無は必ず確認してください。詳細は弁護士にご相談ください。

Q. 発注側の担当者が直接指示してもよいですか？

A. 業務の遂行方法や労働時間について発注側が直接指揮命令すると、実態として労働者派遣と判断されるおそれがあります。区分の考え方はいわゆる37号告示に示されており、厚生労働省の疑義応答集で具体例が公開されています。契約の形式ではなく実態で判断されるとされているため、受注側に責任者を立ててもらい、そこを窓口にする運用にしてください。

Q. 見積が高いか安いか判断できません

A. 金額だけを比較しても判断できません。判断できる状態にする方法は、範囲を小さくすることです。2〜4週間の準委任フェーズで、対象業務の実測・実データでの精度確認・必要作業量の見通しを立ててから本開発の見積を取ると、金額の根拠が見えるようになります。複数社に同じ条件で見積を取るのも有効ですが、条件が揃っていなければ比較になりません。

Q. 契約書は自社で作るべきですか？

A. 受注側の案をベースにして、必要な部分を修正してもらうのが現実的です。比較材料として、IPAが公開している「情報システム・モデル取引・契約書」（第二版・アジャイル開発版）が無償で入手できます。ただし最終的な条項の妥当性判断は弁護士にご確認ください。本記事のチェックリストは、相談の準備として使っていただく想定です。

Q. 小規模な案件でも契約書は必要ですか？

A. 必要です。金額が小さいほど「口頭やメールで済ませよう」となりがちですが、揉めたときの手間は金額に比例しません。少なくとも、業務範囲・成果物・検収基準・報酬・知的財産権・秘密保持・解除の7項目は文書に残してください。取適法の適用がある取引では、発注内容等の明示義務が課されている点にもご留意ください。

Q. AIサービスの仕様変更で動かなくなったら？

A. これは契約時に決めておくべき論点です。何も書かれていない場合、それが契約不適合にあたるのか、保守の範囲なのか、別途費用が必要なのかで見解が分かれます。「外部サービスの仕様変更に起因する修正の扱い」を条項として入れておくことをお勧めします。AIを使う開発では、通常のシステム開発より発生確率が高い事象です。

まとめ

• 違いの本質は「仕事の完成を約束するか（請負・民法632条）」か「事務の適切な処理を約束するか（準委任・民法656条／644条）」
• 準委任には履行割合型（648条）と成果完成型（648条の2）がある。「準委任＝成果物なし」は誤り
• 請負には契約不適合責任が準用されるが、「契約の内容に適合しない」ことが前提。契約に書いていないことは追及できない
• AI開発は精度を先に約束できない／正解データが最初にない／前提が変わるため、請負になじみにくい
• それでも入出力が確定している部分は請負にできる。案件全体をどちらか一方に決めない
• 判断は「完成状態を数値で書けるか」「発注側が判定できるか」「要望が変わらないか」の3問で足りる
• 発注前に決める6項目は検収基準／追加開発／権利の帰属／データの扱い／保守と引き継ぎ／中止時の精算
• 権利の譲渡を受けるなら著作権法27条・28条の記載を必ず確認する
• 見積が読めないときは値切るのではなく、2〜4週間の準委任フェーズに範囲を絞る
• 発注側が直接指揮命令すると実態として労働者派遣と判断されるおそれがある

契約類型の選択は、それ自体が目的ではありません。目的は「何を作るのか」「できたと言えるのはどういう状態か」「うまくいかなかったらどうするか」を、発注側と受注側が同じ言葉で共有することです。準委任か請負かという議論は、その共有ができているかを確認するための入り口にすぎません。

もし今、見積書を前にして判断に迷っているなら、まずは「完成した状態を1行で書けるか」を試してみてください。書ければ請負の道が見えます。書けなければ、書けるようにするための小さな一歩から始めるのが、結果的にいちばん早く、いちばん安く済みます。

なお、繰り返しになりますが、本記事は一般的な情報提供です。個別の契約条項の妥当性、紛争が生じた場合の対応については、必ず弁護士等の専門家にご確認ください。

無料相談はこちら（初回のご相談・お見積りは無料です）

発注先の見極め方はAI導入支援会社の選び方、続けるかやめるかの基準はAI導入をやめる判断基準、生成物の権利については生成AIと著作権にまとめています。

契約形態を選ぶ前に、そもそも刷新すべきかの判断が必要です。基幹システム刷新の進め方で費用が何で決まるかから解説しています。