AI業務委託で偽装請負を避ける発注側チェック
AI業務委託で偽装請負を避ける発注側チェック
AIエンジニアの業務委託は、契約書が弁護士監修で整っていても、現場のSlackで発注側マネージャーが毎朝タスクを割り振り、進捗を詰める運用になれば偽装請負の入り口に立ちます。
AIエンジニアの業務委託は、契約書が弁護士監修で整っていても、現場のSlackで発注側マネージャーが毎朝タスクを割り振り、進捗を詰める運用になれば偽装請負の入り口に立ちます。
私が人材マッチングの実務でよく見てきたのは、PoCや要件定義のように成果物が固まりにくい局面ほど、厚生労働省の区分基準、いわゆる37号告示が見る指揮命令の実態を外しやすいという現実でした。
偽装請負は『業務委託』『準委任』『請負』という名前では防げず、業務遂行の指示管理、労働時間の指示管理、企業秩序の指示管理の3観点と、受託者が自社の労働者を自ら直接利用して独立処理しているかで判断されます。
だからこそ、SOWで範囲を固定し、逐次指示や差し戻しを避け、勤怠や常駐ルール、人選や交代要求まで発注側が握らない運用に直し、実態を契約に合わせていく必要があります。
偽装請負とは何か:契約の名前ではなく実態で判断される
偽装請負は、請負や準委任、業務委託という契約名を使っていても、実態として発注者の指揮命令下で人が動いている状態を指します。
つまり、紙の上では外注でも、現場では発注側の社員のように扱われていれば境界を越えやすいのです。
違法性の核心は、労働者派遣に当たる実態があるのに、その規律を外れてしまう点にあります。
偽装請負と適法な業務委託・派遣の境界
適法な業務委託では、受託者が成果物や業務の完成に責任を負い、進め方も自分で決めます。
労働者派遣では、派遣元が雇用し、派遣先が日々の指揮命令を出す構造です。
偽装請負はその中間に見えて、実際には雇用関係のない発注者が、作業手順や優先順位を事実上決めてしまっている状態だと整理するとわかりやすいでしょう。
判断軸は契約書の文言ではなく、勤怠、指示、評価の実態です。
誰が始業・終業を握っているのか、誰が作業差し戻しをしているのか、誰が進捗を評価しているのかで見ます。
人材マッチングの現場でも、発注企業が「うちは業務委託契約だから大丈夫」と考えているのに、常駐エンジニアが社員と同じ朝会に出て同じ勤怠ルールで動いているケースは珍しくありません。
契約形式への過信こそ、最初の落とし穴です。
| 観点 | 適法な業務委託 | 労働者派遣 | 偽装請負 |
|---|---|---|---|
| 責任の中心 | 成果物・業務完成 | 労務提供 | 名目は委託だが実態は労務提供 |
| 日々の指示 | 受託者が自律的に判断 | 派遣先が指揮命令 | 発注者が逐次指示 |
| 勤怠管理 | 受託者側で管理 | 派遣元・派遣先の役割分担あり | 発注者が実質管理 |
| 評価 | 成果ベース | 派遣元の雇用管理 | 発注者が実質評価 |
なぜAIエンジニア活用で偽装請負が起きやすいのか
AI開発はPoC、要件定義、データ整備のように成果物が固まりにくい準委任フェーズが多く、発注側が日常的に関与しやすい構造があります。
しかも専門性が高いほど、発注側は細かな論点を把握できないため、「この方向で進めて」「ここを直して」と口頭やチャットで随時介入しがちです。
実務で何度も見てきたのは、仕様が曖昧なまま走り出し、要件をあとから固めるほど、指示の密度が上がって境界に近づいていく流れでした。
AI案件では、相談が密になること自体は悪くありません。
むしろ初期は密な対話が必要です。
ただ、その対話が「仕様のすり合わせ」から「作業の逐次指示」に変わると、準委任の自律性が崩れます。
たとえば、モデルの方針、データの扱い、修正順の決定まで発注側が毎日細かく決める運用なら、受託者は独立した事業者ではなく、実質的な作業者になってしまいます。
AIエンジニア活用では、この切り替わりが静かに起きるのが厄介です。
契約書を整えても運用で崩れる典型パターン
契約書に「指揮命令権はない」と書いても、チャットで逐次指示し、会議で作業割り振りを決め、発注側が勤怠や評価まで握っていれば、実態が優先されます。
名目だけ整えても、現場の動きが変わらなければ意味がありません。
契約の名前を修正するより、指示系統、勤怠、評価、ログの設計を先に整えるほうが先です。
典型的なのは、常駐エンジニアに対して発注側の朝会参加を当然視し、同じルールで稼働状況を管理するケースです。
そこに人選や交代の要望まで混ざると、受託者の裁量はさらに細ります。
AI案件では、要件が後追いで固まるぶん「まず着手して、あとで修正」が起きやすく、結果として発注側の即時判断が積み上がりやすい。
だからこそ、SOWで業務範囲を固定し、依頼は成果物ベースに寄せ、逐次の作業指示や差し戻しを避ける運用に切り替えましょう。
おすすめです。
判断基準:指揮命令・労働時間・企業秩序の3つの管理権限
37号告示ベースの判断は、契約書の名目ではなく現場で誰が何を握っているかで決まります。
見られるのは、業務遂行に関する指示・管理、労働時間に関する指示・管理、企業秩序に関する指示・管理の3観点です。
さらに、受託者が自己の雇用する労働者を自ら直接利用し、請け負った業務を自己の業務として相手方から独立して処理しているかも外せません。
AI開発のように途中で相談が増えやすい案件ほど、ここを曖昧にすると運用だけで偽装請負へ傾きます。
誰が業務の進め方を指示しているか
業務遂行に関する指示・管理でまず見るのは、作業の順序、方法、割り振りを誰が決めているかです。
発注者が個々のエンジニアに直接タスクを振り、途中成果物に細かく差し戻しを入れ、やり方まで逐次指定しているなら、請負や業務委託の外形を保っていても、実態は発注者の指揮下で動いていると見られやすくなります。
逆に、成果物の要件だけをSOWで固定し、進め方の裁量を受託者側に残せていれば、独立して処理している形に近づきます。
実務では、この線引きが最も崩れやすいです。
AIエンジニアは専門性が高いぶん、発注側が「ここはこう直して」「次はこの順で」と口を出しやすいからです。
実際に、成果物単位で発注し、週次の定例で進捗だけを確認しながら、人選も稼働時間も受託者に委ねていた案件は、密に相談しつつも指揮命令に踏み込まず、適法な運用を保てていました。
相談は多くても、決める権限を誰が持つかが分かれ目でしょう。
誰が勤務時間・残業・休暇を管理しているか
労働時間に関する指示・管理では、始業終業、残業、休憩、休暇の承認を誰が担っているかが問われます。
発注者が勤怠を打刻させ、残業の可否を判断し、休暇申請まで承認しているなら、本人がフリーランスであっても、勤怠だけ社員と同じ運用になっていることになります。
これを現場で確認したときは、労働時間管理の観点で明確にアウトでした。
時間の管理は、見た目以上に契約関係を決定づける要素です。
もっとも、時間の管理をゼロにする必要はありません。
週次の定例で進捗を確認する程度なら、成果物の管理にとどまります。
問題なのは、発注者が「何時から何時まで働くか」「残業してよいか」「休暇を取るか」を決めてしまうことです。
ここを受託者側の自己管理に戻し、必要な調整は納期や成果物の受け渡しで吸収する設計に変えましょう。
そうすれば、働き方の裁量と責任の所在がそろいます。
受託者の独立性と自己完結性をどう示すか
受託者には、『自己の雇用する労働者を自ら直接利用していること』と『請け負った業務を自己の業務として相手方から独立して処理していること』の両要件が求められます。
つまり、単に人を外に出しているだけでは足りず、案件全体を受託者側の責任で回している実態が必要です。
発注者が個々のエンジニアに直接作業を割り振っている時点で、この独立処理の要件は崩れやすくなります。
人の使い方まで発注者が握ると、受託者は実質的な窓口にすぎなくなるからです。
企業秩序の観点も見落とせません。
社員と同じ服務規律を課していないか、評価や懲戒に似た扱いをしていないかを点検しましょう。
加えて、独立性を示すには、独立した設備やアカウントで処理させること、進捗管理を受託者の自己管理に委ねること、交代要員の人選を発注者が要求しないことが効きます。
AI開発はPoCや要件定義のように成果物が固まりにくいフェーズが多いので、密な相談と指揮命令を切り分ける設計が欠かせません。
おすすめです。
発注側チェックリスト:現場運用で守る7項目
SOWと仕様書で業務範囲と成果物を先に固定し、契約書には発注者が指揮命令権を持たないことを明記します。
ここが曖昧だと、現場でその都度「ここを直して」「次はこの手順で」と指示を重ねやすくなり、偽装請負の入口が生まれます。
発注側の運用として守るべきは、細かな作業管理ではなく、要件の合意と検収です。
業務範囲と成果物をSOWで固定する
最初に固めるべきなのは、何をやるかではなく、何を納めるかです。
業務はSOW・仕様書で境界を切り、依頼は「この作業をこの手順で」ではなく「この要件を満たす成果物を納品して」に揃えます。
発注フローを見直してSOWを必ず添付し、依頼を成果物ベースに統一しただけで、現場の「つい細かく指示してしまう」運用が減り、偽装請負リスクが構造的に下がった企業を実務支援の中で確認しました。
範囲が固定されると、担当者の裁量で指示が膨らみにくくなるのです。
日常コミュニケーションで避けるべき指示の出し方
日常のやり取りでは、自社チャットでの逐次の作業指示、細かい差し戻し、即時対応の要求を避けます。
会話の中心は、仕様確認と検収に絞るほうがよいでしょう。
受託者に「今すぐこの順番で直して」と踏み込むほど、現場の相手方は独立した事業者ではなく、社内メンバーのように扱われやすくなります。
進捗や品質の確認は必要でも、工程管理まで飲み込まないことがポイントです。
ℹ️ Note
仕様の確認と成果物の受け取りを分けて運用すると、密な協働を保ちながらも、指揮命令に見える線を越えにくくなります。
常駐が前提のAI案件でも、勤怠と作業の進め方を受託者に委ね、発注側は成果物の検収と仕様の合意だけを担う線引きにしたことで、密な協働と適法性を両立できたケースがありました。
現場での近さそのものが問題なのではなく、誰が働き方を決め、誰が作業順を決めるかが見られます。
おすすめは、会話の粒度を「仕様」「成果物」「検収」にそろえることです。
やってみてください。
勤怠・常駐・人選で踏み込まないライン
勤怠・常駐時間・出社ルールは、発注側が決めません。
常駐が必要でも、稼働時間や働き方は受託者の管理に委ねるのが筋です。
さらに、担当者の人選や交代を発注者が指名・要求しないことも欠かせません。
誰をアサインするかは受託者の裁量に残しておくほうが、独立処理の実態を説明しやすくなります。
加えて、可能な範囲で受託者が自己の設備・ツール・アカウント・費用で業務を処理する実態を残し、進捗管理は社員と同じ会議体に組み込まず、自己管理と定期報告に委ねます。
チェックの観点は7項目です。
SOW・仕様書で範囲を固定しているか、成果物・要件ベースで依頼しているか、チャットで逐次指示していないか、即時差し戻しを常態化させていないか、勤怠・出社を決めていないか、人選や交代を要求していないか、設備・アカウント・費用の独立性と自己管理の運用が残っているか。
該当・非該当で見直していくと、運用のどこが危ないかが見えます。
おすすめです。
AI開発特有の論点:準委任・請負の選び方と成果物定義
AI開発の契約は、完成責任を負う請負と、遂行義務を負う準委任のどちらに寄せるかで、紛争の起こり方が変わります。
特にPoCや要件定義のように不確実性が高い局面では、請負を選ぶと「精度が出ない」こと自体が契約不適合をめぐる争点になりやすく、実務では準委任を起点に設計するほうが自然です。
もっとも、実装フェーズまで含めて役割を分け、成果物・検収・知財帰属まで詰めておかないと、契約形態より先に権利関係で行き詰まります。
フェーズごとの請負・準委任の使い分け
請負は仕事の完成に法的責任を負い、成果物に不備があれば修補や減額、損害賠償、解除の対象になります。
これに対して準委任は、善良な管理者の注意のもとで業務を遂行する責任を負う契約であり、仕事の完成そのものまでは法的に約束しません。
この違いを出発点に置くと、AI開発でどこまで完成を求めるかが整理しやすくなります。
実務では、企画・要件定義やPoC(技術検証)は準委任、仕様が固まった実装フェーズでは請負も検討する、という切り分けが定石です。
PoCを請負で発注してしまい、検証の結果「精度が出ない」こと自体が契約不適合だと主張されて揉めた現場を見たことがありますが、不確実な段階を請負に載せると、技術上の限界まで契約責任に変わってしまうのです。
フェーズを区切らず一括請負にすると、要件の揺れがそのまま紛争の火種になります。
成果完成型準委任という折衷案
AIソフトウェアは、学習データの量と質に精度が左右され、未知の事象への推論精度を事前に保証しにくい性質があります。
そのため、受託者側は完成責任を負う請負を避けやすく、法的な完成責任は負わないが事実上の完成を目指す成果完成型準委任が落としどころになりやすいのです。
完成責任を外しても、成果物の水準を曖昧にすると発注側が不安になりますから、ここは契約文言で橋をかける必要があります。
成果完成型準委任では、成果物の定義、到達目標、評価観点を明示しつつ、法的には遂行義務として組み立てるのがポイントです。
たとえば、学習データの前提、想定ユースケース、評価指標、再学習の扱いを決めておけば、単なる「やってみた」で終わらず、双方の期待値をそろえやすくなります。
善管注意義務と完成責任の差を理解したうえで設計すると、AI案件の現実に合った契約になりやすいでしょう。
成果物・検収・知財帰属を契約で固める
契約で最も抜けやすいのが、成果物、検収、納品方法、知的財産権の帰属です。
権利帰属の条項がないと、受託者が作成したプログラム著作物の著作権は受託者に帰属する可能性が高く、後から別ベンダーへ引き継げない、横展開できないという事態が起こります。
実際、知財帰属の条項を入れ忘れたために、モデルや前処理コードの権利が受託者側に残り、発注企業が移管で困ったケースを見ました。
契約書は後回しにしやすいですが、AI開発では本体そのものです。
加えて、AIでは学習データの準備・取得費用の負担や、生成物の二次利用可否まで定義しておく必要があります。
納品物がソースコードだけなのか、学習済みモデルまで含むのか、検収は精度で見るのか再現手順で見るのか、そこを先に決めておくと後工程が安定します。
おすすめは、成果物の範囲と検収条件を一つの表現にまとめ、納品方法まで文章で固定することです。
そうしておけば、契約形態の選択と実務運用がずれにくくなります。
フリーランス新法で増えた発注側の義務
2024年11月1日に施行されたフリーランス・事業者間取引適正化等法で、発注側の実務は「偽装請負に触れないようにする」だけでは足りなくなりました。
個人で業務委託を受けるフリーランスにAIエンジニアを活用する場面では、契約形態の整理に加えて、取引条件の明示、報酬の支払管理、長期委託時の配慮までを発注フローに組み込む必要があります。
口頭やチャットの一言で進めていた運用を見直すだけで、トラブルの芽はかなり減らしやすいです。
取引条件の明示義務
発注事業者は、委託したら直ちに、委託内容・報酬の額・支払期日などの取引条件を、書面またはメール、メッセージ等で明示しなければなりません。
ここで求められているのは、後から見返したときに「何を、いくらで、いつ支払うのか」が判読できる状態にしておくことです。
AI案件は要件が曖昧なまま走りやすいので、定型フォーマットを先に整えておく発想が有効になります。
実務で見ると、口頭発注や雑なチャット指示をやめ、委託内容・報酬・支払期日を毎回同じ順序で書く運用に変えただけで、受託者との認識ずれが減りました。
契約書を重く構えなくても、発注時点で条件を明示する仕組みを入れておけば、確認漏れや「言った、言わない」の摩擦を抑えやすいです。
AIエンジニアの個人委託では、この初動の整備が信頼関係の土台になるでしょう。
報酬・受領をめぐる禁止行為
取引適正化の観点では、報酬の減額、受領拒否、返品、買いたたき、不当な経済上の利益の提供要請などが禁止行為として整理されています。
ポイントは、成果物に不満があるからといって、発注側が一方的に条件を動かせないことです。
AI案件では、精度が想定より低い、納品物の見え方が違うといった理由で揉めやすいので、発注時に評価基準や修正条件をできるだけ具体化しておく必要があります。
とくに、学習データの状態や検証環境の差が成果に影響する案件では、結果だけを見て報酬を削る運用は危ういです。
実際、想定外の品質を理由に減額しようとした場面で、契約条件の確認からやり直すことになったケースを確認しています。
報酬の支払と受領の扱いは、開発の出来不出来とは切り分けて管理しましょう。
そうしておくと、受託者側も安心して改善提案を出しやすくなります。
継続的な委託で生じる配慮・ハラスメント対策義務
6か月以上の継続的な業務委託では、妊娠・出産・育児・介護と業務を両立できるよう、フリーランスの申出に応じた配慮義務が生じます。
あわせて、ハラスメント対策の体制整備も求められます。
短期のスポット発注では見えにくい論点ですが、長期で常駐型のAI人材を活用するほど、発注側の運用設計そのものが問われる領域です。
長期のAI開発を個人フリーランスに委ねていた企業で、契約更新のタイミングになってから、継続委託の配慮義務や相談窓口の整備が抜けていると判明したケースがありました。
そこで必要になったのは、単なる契約延長ではなく、勤務の進め方、連絡手段、相談対応の流れまで含めた体制の見直しです。
実務では、更新時にまとめて整えるより、最初から長期前提の設計で始めるほうが自然です。
偽装請負と判断された場合のリスクと是正の進め方
偽装請負は、契約書の名称ではなく現場の実態で判断されます。
発注者が作業手順を細かく指示し、勤怠や人選まで握っているのに業務委託として扱っていれば、無許可の労働者派遣と評価され、受託会社・発注者の双方に1年以下の懲役または100万円以下の罰金が科されうるのです。
AI人材を常駐させる場面では、ここを見落とすと、調達段階では軽く見えた運用が一気に法令リスクへ変わります。
罰則・直接雇用みなし・社保遡及の具体像
無許可で労働者派遣を行うと、発注者・受託会社の双方が処罰対象になります。
現場では「開発支援」「業務委託」という名目で始まっても、指揮命令が日々のタスク配分や優先順位の指定に及べば、請負の外形は崩れます。
だからこそ、罰則は遠い話ではなく、運用設計を誤った瞬間に射程へ入るものだと捉える必要があります。
偽装請負と知りながら受け入れていた場合は、労働契約申込みみなし制度が重くのしかかります。
発注者が当該労働者に直接雇用を申し込んだものとみなされ、労働者が承諾すれば直接雇用義務が生じます。
想定外の採用コストだけでなく、人数計画や配置計画そのものを組み替えざるを得なくなるため、経営への影響は人事部門にとどまりません。
さらに、過去に遡って社会保険料の支払いを求められる可能性があり、金銭負担は後から膨らみます。
行政指導や勧告が入れば、社内の問題として閉じず、取引先や株主、消費者からの見え方も変わります。
実際、行政の調査をきっかけに指摘を受け、急いで是正に追われた現場では、平時にチェックリストで点検していれば避けられた負荷が大きく、発覚前の自己点検の価値を痛感しました。
発覚の経路と発注側に及ぶ影響
発覚のきっかけは、内部通報だけではありません。
行政調査、契約更新時の確認、現場ヒアリング、稼働実態の食い違いなど、入口は複数あります。
発注側にとって厄介なのは、表向きの契約条件よりも、現場での振る舞いのほうが証拠として残りやすい点です。
誰が指示を出し、誰が出退勤を管理し、誰が要員を選んでいるかが見られるため、運用の癖がそのままリスクになります。
影響は法務だけで終わりません。
行政指導が入れば説明対応に工数を取られ、案件の進行が鈍りますし、対外的には「コンプライアンスを軽視していた会社」と見られる恐れがあります。
ステークホルダーへの波及も無視できません。
取引先は再発防止策を求め、現場は不安を抱え、採用部門は急な雇用転換に追われます。
こうした混乱は、適法化の遅れそのものより、情報整理と意思決定の遅さから増幅されがちです。
実態を契約に一致させる是正の優先順位
是正は、すべてを一度に直そうとしないほうがうまく進みます。
最初に手を付けるべきは、指揮命令・勤怠・人選のような、偽装請負を最も強く疑われる実態です。
ここが残ったままでは、SOWを整えても成果物ベースの依頼に切り替えても、現場の運用が契約を上書きしてしまいます。
実務上は、まずSOWを整備し、依頼を作業指示ではなく成果物ベースに寄せ、勤怠管理を受託者側へ移管する流れが基本になります。
そのうえで、要員の選定や交代の決め方を見直し、必要に応じて契約形態そのものを再検討しましょう。
すべてを同時に変えるより、リスクの高い順に段階的に進めた企業のほうが、協働を止めずに適法化できていました。
必要なら専門家のレビューも受けて、運用と契約のズレを一つずつ潰してみてください。
IT人材サービス企業で10年以上、AIエンジニアを含むIT人材のマッチング・コンサルティングに従事。SES・業務委託・フリーランスの契約形態に精通し、企業のAI人材戦略をアドバイスしている。
関連記事
AIエンジニアの将来性|需要と年収の今後
AIエンジニアの将来性|需要と年収の今後
AIエンジニアは、生成AIの普及で役割が変わりつつある一方で、需要そのものは拡大し続ける職種です。国内AIシステム市場は2023年の約6,859億円から2028年に約2兆5,434億円へ伸びる見込みで、現場でもAI領域の求人は他職種より候補者が集まりにくく、埋まるまでの時間が長いという肌感があります。
AIエンジニアの年収相場|経験・スキル別で569万〜1000万超
AIエンジニアの年収相場|経験・スキル別で569万〜1000万超
AIエンジニアの年収は、求人票を見ても単純な平均値ではつかめない職種です。人材マッチングの現場でも、下限と上限で3倍ほど開く求人レンジを何度も見てきましたが、求人媒体ベースの平均569万円と職業情報サイトの628.9万円は、いずれも日本全体平均382万円の1.5〜1.6倍にすぎません。
AIエンジニアの種類と職種一覧|役割・年収の違い
AIエンジニアの種類と職種一覧|役割・年収の違い
AIエンジニアは、機械学習エンジニア、データサイエンティスト、MLOps、生成AI・LLMエンジニア、コンピュータビジョンエンジニア、AIプランナー・コンサルタント、アノテーターまで含む職種群の総称である。
AIエンジニアを副業で週2日依頼する相場と進め方
AIエンジニアを副業で週2日依頼する相場と進め方
AIエンジニアの副業・業務委託は、正社員採用の難度とコストが高いなかで、生成AI活用やPoCをまず小さく試したい企業に向けた現実的な選択肢です。IT人材のマッチングを長く手がけてきた立場から見ると、発注企業は「週2日でも本当に成果が出るのか」と慎重に見極めながら、採用一択から一歩踏み出していきます。