業務委託エンジニアに頼める業務・出せない指示｜偽装請負の境界

社内の開発リソースが足りず、フリーランスや業務委託のエンジニアに開発を頼み始めた。ところが日々のやり取りのなかで、「この依頼は出していいのか」「ここまで指示すると偽装請負になるのではないか」と、一つひとつの場面で手が止まってしまう。社内の誰かに「それ、偽装請負では」と言われ、必要な依頼までためらうようになった。こうした状況に心当たりのある発注担当者は少なくありません。

偽装請負という言葉だけが先行して耳に入ると、「外部のエンジニアには細かいことを頼んではいけない」という漠然とした不安が残ります。しかし実際には、頼んでよい業務・出してよい指示は明確に存在します。問題は、その境界線がどこにあるのかを言葉で説明できないために、安全側に振りすぎて外部人材を活かしきれていないことにあります。

外部エンジニアの活用でつまずく原因の多くは、「何が違法か」という禁止行為の知識が断片的にあるだけで、「では結局この業務は頼んでよいのか」を判断する物差しを持っていないことです。物差しさえ持てれば、必要な依頼は萎縮せずに行えますし、危険な指示は契約や体制の工夫で回避できます。

本記事では、業務委託エンジニアに「依頼できる業務」と「出せない指示」の境界を、発注者が現場でその場で照合できるよう、業務・シーン別の対比表として整理します。あわせて、依頼したい内容から契約形態（請負／準委任）を逆算して選ぶ考え方、偽装請負と判断された場合に何が起こるか、そして2024年11月に施行されたフリーランス新法で発注者に新たに求められる義務までを通して解説します。読み終えたとき、外部エンジニアを「怖い相手」ではなく「安心して任せられるチーム戦力」として捉え直せることを目指します。

フリーランスエンジニアへの依頼で「できること・できないこと」を分ける基準

最初に、本記事全体の結論となる判断軸を示します。細かい場面の正解を覚える前に、この一つの軸を押さえておけば、迷ったときに自分で考えられるようになります。

大原則 ── 発注できるのは「結果」、できないのは「人への指揮命令」

業務委託（請負契約・準委任契約）における発注者の立場を一言で表すと、「成果や業務の結果は求められるが、その人に対して労働者のように指揮命令することはできない」となります。

具体的には、発注者は以下を求めることができます。

• 完成させてほしい成果物の内容や要件
• 満たすべき品質基準
• 守ってほしい納期

一方で、発注者が外部エンジニアに対してできないのは、次のような「人そのものへの指揮監督」です。

• 作業の進め方を一つひとつ指示すること
• 何時から何時まで働くかという稼働時間・勤怠の管理
• 自社の業務命令系統に組み込んで、その場で次々と作業を割り振ること

ここを分ける本質は、「誰がそのエンジニアを労働者として指揮監督しているか」という一点にあります。発注者が直接エンジニアを指揮監督している実態があれば、契約書の名目が「業務委託」であっても、実態としては労働者派遣や労働者供給とみなされ、偽装請負と評価されてしまうのです。

「指示」と「指揮命令」はどう違うのか

ここで多くの発注担当者がつまずくのが、「指示」と「指揮命令」という言葉の区別です。「業務委託では指示してはいけない」と聞いて、「では何も依頼できないのか」と萎縮してしまうケースが典型です。

両者は次のように整理できます。

• 業務上の指示（OK）: 成果物の要件・仕様・品質・納期といった「何を作ってほしいか」を伝えること。これは発注者として当然行ってよい依頼です。
• 指揮命令（NG）: 「いつ・どこで・どのように働くか」という、労働者に対して使用者が行う管理。出退勤の管理、作業手順の逐一指示、その場での随時の業務追加などが該当します。

つまり、「指示」がすべて禁止されているわけではありません。禁止されているのは、労働者を管理するのと同じ形での「指揮命令」です。成果物について必要な依頼を行うことは、業務委託でも何ら問題ありません。この区別を曖昧にしたまま「指示は危ない」と一括りにしてしまうと、本来できるはずの依頼まで遠慮することになり、外部人材を活かせなくなります。

なぜ指揮命令ができないのか ── 実態で判断される偽装請負の物差し

では、なぜ業務委託では指揮命令ができないのでしょうか。その根拠となる考え方が、厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」、通称「37号告示」です。

37号告示の考え方を要点だけ示すと、請負（業務委託）として認められるためには、業務を請け負った側が「自己の業務として、発注者から独立して処理している」実態が必要とされています。具体的には、業務処理に要する資金を自ら調達し、事業主としての責任を負い、単に労働力を提供するだけでないことなどが求められます（37号告示関係 疑義応答集（厚生労働省））。

重要なのは、これが契約書の文言ではなく実態で判断されるという点です。契約書に「業務委託契約」と書いてあっても、現場で発注者がエンジニアを直接指揮監督していれば、偽装請負と評価されます。逆に言えば、実態として独立して業務を処理してもらう形を保てば、安心して依頼できるということでもあります。

なお、37号告示の逐条的な解釈や、適法な指示として許容される具体的なパターンについては、より体系的に整理した記事があります。法的根拠を深く確認したい場合は、業務委託で適法な指揮命令の範囲とは？をあわせてご覧ください。本記事ではここから先、「では具体的にどの業務・どの指示がよいのか」という現場の判断に焦点を絞ります。

【業務・シーン別】業務委託エンジニアに依頼できる業務・できない指示の対比

ここからが本記事の中核です。発注者が現場で必ず迷う「業務」と「指示」を、依頼してよいもの・偽装請負リスクが高いものに分けて一覧化します。迷ったときに照合できる即断ツールとして活用してください。

依頼してよい業務・出してよい指示

まず、発注者が安心して行ってよい依頼です。これらは成果物や業務の結果に関わるものであり、「人への指揮命令」には当たりません。

これらのうち、特に誤解が多いのが「成果物への修正依頼」です。「修正を頼むと指示になってしまうのでは」と心配する発注者がいますが、納品物が要件を満たしていない場合に修正を求めることは、成果物の品質に関する依頼であって、人への指揮命令ではありません。要件・仕様・品質・納期について必要なやり取りを行うことは、業務委託でも当然に行ってよい依頼です。

ポイントは、依頼の対象が「成果物・業務の結果」に向いているかどうかです。結果に向いている依頼であれば、原則として安心して出すことができます。

出すと偽装請負リスクが高い指示

次に、出してしまうと偽装請負と評価されるリスクが高い指示です。これらはいずれも「人そのものの管理」に踏み込んでいる点が共通しています。

なかでも実務で起こりがちなのが、「稼働時間の指定」と「随時の業務追加」です。たとえば「平日9時から18時は必ず稼働してほしい」と時間で縛ったり、その場で次々と契約範囲外のタスクを振ったりすると、実態として労働者を管理しているのと変わらなくなります。

こうした指示を避けるには、発注の単位を「時間」ではなく「成果・業務範囲」で設計することが有効です。「この成果物をこの納期で」「この業務をこの契約期間で」という形にしておけば、稼働の進め方はエンジニア側の裁量に委ねられ、指揮命令の問題を避けられます。

迷いやすいグレーゾーンの判断原則

上記のように整理しても、現場には「OKともNGとも言い切りにくい」グレーゾーンが残ります。代表的な場面ごとに、安全側の運用原則を示します。

• 進捗確認はどこまでOKか: 定期的に進捗や課題を確認すること自体は問題ありません。ただし、確認の頻度や方法を細かく管理し、その場で逐一作業を指示し始めると、指揮命令に近づきます。原則は「結果・進捗の確認はOK、進め方の管理はNG」です。
• コードレビューでの指摘は指示か: 成果物の品質を保つためのレビューと修正依頼は、成果物に対する依頼であり問題ありません。一方、コードの書き方そのものを一行ずつ強制するような関わり方は、作業手順の指示に近づくため注意が必要です。
• 緊急の本番障害対応: 障害発生時の対応そのものは、契約に基づく業務として依頼できます。ただし「今すぐ何時間でも対応せよ」と稼働を時間で縛る形にすると、勤怠管理に踏み込みます。緊急対応の範囲や連絡フローは、あらかじめ契約・体制で定めておくのが安全です。
• チャットでの日常的なやり取り: SlackやJiraなどでの情報共有・質問対応は通常の業務連絡として行えます。ただし、随時その場で作業を割り振り続けると、指揮命令系統への組み込みに近づきます。
• アジャイル開発での協働: デイリースクラムなどで密に協働する場面でも、原則は同じです。協働それ自体が直ちに偽装請負になるわけではありませんが、発注者がエンジニアの作業を逐一管理する実態があると問題になります。

チャットツール別の細かなOK/NG例や、アジャイル開発における具体的なグレー判定については、業務委託で適法な指揮命令の範囲とは？で詳しく整理しています。本記事の判断原則とあわせて確認すると、現場での線引きがより明確になります。

依頼内容から逆算する契約形態の選び方（請負／準委任）

ここまで「出してよい依頼・避けるべき指示」を見てきましたが、安心して依頼するためのもう一つの土台が、依頼内容に合った契約形態を選ぶことです。多くの記事は「請負と準委任の違い」を解説しますが、発注者にとって実務上重要なのは「自分が頼みたい業務には、どちらの契約が向いているか」を逆算で考えることです。

請負契約が向く依頼／準委任契約が向く依頼

請負契約と準委任契約は、求める成果の性質によって使い分けます。

たとえば「この仕様書どおりのWebシステムを作り切ってほしい」という依頼は、成果物の完成を求めるため請負契約が向きます。一方、「これから仕様を詰めながら開発を進めたい」「既存システムの運用保守を継続的にお願いしたい」といった、完成という一点では区切りにくい依頼は準委任契約が適しています。

依頼したい業務の性質から逆算すれば、どちらの契約を結ぶべきかは自ずと見えてきます。

どちらの契約でも「指揮命令」はできない ── 契約選択と偽装請負回避は別問題

ここで誤解しやすいのが、「準委任なら多少は指示してよいのでは」という考え方です。これは正しくありません。

請負契約であれ準委任契約であれ、発注者がエンジニアに対して労働者と同様の指揮命令を行えない点は共通です。準委任は「業務の遂行」を委託する契約ですが、それは「発注者が随時指揮命令してよい」という意味ではなく、委託された業務を受託側が自らの裁量で遂行することを前提としています。

つまり、契約形態の選択（請負か準委任か）と、偽装請負を避けること（指揮命令をしないこと）は、別々の論点です。どちらの契約を選んでも、人への指揮命令は避ける必要があります。逆に言えば、依頼内容に合った契約を正しく選び、その範囲内で成果物や業務に関する依頼を行うかぎり、安心して外部エンジニアに任せられるということです。

偽装請負と判断されるとどうなるか、発注者が取るべき対策

線引きを理解したうえで、万が一偽装請負と判断された場合に何が起こるのか、そしてそれを避けるために発注者が実務で取れる対策を確認しておきましょう。ここでの目的は不安を煽ることではなく、「対策を打てば安全に活用できる」という見通しを持つことです。

偽装請負と判断されるとどうなるか

偽装請負が労働者派遣法や職業安定法に違反すると判断された場合、発注者側にも以下のような影響が及ぶ可能性があります。

• 行政指導・改善命令・企業名公表: 厚生労働大臣による指導・助言、改善命令、企業名の公表などの対象となりえます（偽装請負について（東京労働局））。
• 罰則: 無許可の労働者派遣や労働者供給に該当すると判断された場合、関係する事業主に対して罰則が科されうるとされています（出典: 厚生労働省・労働者派遣法、2024年）。
• 直接雇用みなしのリスク: 派遣法の労働契約申込みみなし制度により、一定の要件のもとで、発注者がそのエンジニアに労働契約を申し込んだものとみなされる場合があります（出典: 厚生労働省「労働契約申込みみなし制度について」）。

ただし、これらはあくまで「実態として労働者を指揮監督していた」と評価された場合のリスクです。本記事で整理してきた境界を守り、適切な体制で依頼していれば、過度に恐れる必要はありません。重要なのは、リスクを正しく理解したうえで、次に示す対策を講じておくことです。

発注者が取るべき実務対策

偽装請負を避けつつ外部エンジニアを活用するために、発注者が実務で取れる対策は次のとおりです。

• 契約書に業務範囲と遂行方法を明記する: 「何を成果物とするか」「業務の範囲はどこまでか」を契約で明確にし、進め方は受託側の裁量に委ねる旨を整理しておきます。
• 窓口を一本化する: 個々のエンジニアに直接指示を出すのではなく、受託側の責任者（窓口）を通じてやり取りする体制にすると、指揮命令系統への組み込みを避けやすくなります。
• 稼働報告の運用を整える: 稼働時間を発注者が管理するのではなく、成果・進捗ベースで報告を受ける形にすると、勤怠管理に踏み込まずに状況を把握できます。
• 指揮命令しない仕組みを業務フローに組み込む: 作業の割り振りや進め方の決定を受託側に委ねるよう、運用ルールとして定めておきます。

これらは特別な施策ではなく、日々の体制設計の工夫です。仕組みとして整えておけば、現場で一つひとつ迷う必要がなくなります。

フリーランス新法で発注者に求められる取引条件の明示義務

偽装請負と並んで、発注者が今押さえておくべき関連義務があります。2024年11月1日に施行された「フリーランス・事業者間取引適正化等法」、いわゆるフリーランス新法です。

フリーランス新法では、フリーランス（従業員を使用しない個人事業主など）に業務を委託する発注事業者に対して、いくつかの義務が課されています。発注者が特に押さえておきたいのは次の点です（フリーランス法特設サイト（公正取引委員会）、政府広報オンライン）。

• 取引条件の明示義務: 業務を委託した際、業務内容・報酬額・支払期日などの取引条件を、書面または電磁的方法（メール等）で明示する必要があります。口頭のみの取り決めは認められません。
• 報酬の支払期日: 成果物等を受け取った日から数えて60日以内のできるかぎり短い期間内に支払期日を設定し、その期日内に支払うことが求められます。
• 中途解除・不更新時の予告: 6か月以上継続する業務委託を中途解除したり更新しなかったりする場合は、原則として30日前までに予告する必要があります。

偽装請負が「指揮命令の有無」という実態の問題であるのに対し、フリーランス新法は「取引条件をきちんと明示し、適正に取引する」という手続きの問題です。外部エンジニアを安心して活用するためには、この両方をセットで押さえておくことが、これからの発注者に求められます。

まとめ ── 線引きを知れば、外部エンジニアは安全に活用できる

外部エンジニアへの依頼でつまずく多くの原因は、違法ラインを断片的にしか知らず、安全側に振りすぎてしまうことにあります。本記事で示した判断軸を整理すると、次の数点に集約できます。

• 発注できるのは「結果」、できないのは「人への指揮命令」。成果物・要件・品質・納期は求めてよく、稼働時間・作業手順・勤怠の管理は避ける。
• 「指示」と「指揮命令」は違う。成果物に関する依頼は問題なく、禁止されるのは労働者を管理するのと同じ形での指揮命令だけ。
• 依頼内容に合った契約形態（請負／準委任）を選ぶ。ただしどちらの契約でも指揮命令はできない点は共通。
• 対策を打てば安全に活用できる。契約書での業務範囲の明記、窓口の一本化、成果ベースの報告、フリーランス新法の取引条件明示をセットで整える。

境界を理解すれば、必要な依頼は萎縮せずに行えますし、危険な指示は契約と体制の工夫で回避できます。外部エンジニアは「怖い相手」ではなく、線引きを押さえれば安心して任せられるチーム戦力です。

次のステップとして、指揮命令の法的根拠をさらに深く確認したい場合は、業務委託で適法な指揮命令の範囲とは？で37号告示や適法な指示のパターンを体系的に整理しています。

また、ここまで見てきた契約書での業務範囲の明記やフリーランス新法への対応は、自社の契約をどこまで点検できているかが気になるところです。発注時の契約リスクをチェックリスト形式で点検し、押さえておきたい契約条項の例までまとめた資料として、「フリーランス新法対応 業務委託発注の法律・契約リスク点検ガイド」があります。自社の発注体制を一度棚卸ししたい方は、こうした点検ツールを手元に置いておくと、迷ったときの拠り所になります。

画像指示

• アイキャッチ推奨クエリ: "business contract signing handshake office"

• 本文内画像（主要セクション3〜5枚に絞る）:

  挿入位置（セクション見出し）	検索クエリ	備考
  フリーランスエンジニアへの依頼で「できること・できないこと」を分ける基準	"developer working laptop remote freelance"	判断軸を示す導入セクション
  【業務・シーン別】業務委託エンジニアに依頼できる業務・できない指示の対比	"checklist clipboard decision review"	対比表を主役とする中核セクション
  依頼内容から逆算する契約形態の選び方（請負／準委任）	"business documents contract comparison desk"	契約形態の使い分け
  偽装請負と判断されるとどうなるか、発注者が取るべき対策	"legal compliance office meeting discussion"	リスクと対策のセクション