フリーランスエンジニアや外部人材を業務委託で活用している企業の担当者から、こんな声をよく耳にします。「Slackで作業指示を送っているけど、これって偽装請負になるの？」「週次MTGで改善をお願いしたら違法になる？」といった不安です。
業務委託という契約形態をとりながら、実態として指揮命令を行えば「偽装請負」と判断されるリスクがあります。しかし逆に、指示を一切しないと成果も出ません。この「どこまでOKか」という境界線が曖昧なまま、多くの発注担当者が日々の業務をこなしているのが現実です。
難しいのは、法律の言葉と実務の行動の間に大きなギャップがあることです。「指揮命令禁止」と言われても、日常のコミュニケーションのどこからが指揮命令なのか、法律文書を読んでもなかなかわかりません。
本記事では、業務委託における指揮命令の法的根拠から、適法な例外パターン、そしてIT現場（Slack・Jira・スクラム開発）での具体的な判断基準まで、発注担当者が実務で使える形で解説します。「何がNGか」だけでなく「どう動けば安全か」という前向きな視点で整理しています。
業務委託で「指揮命令権」がない理由——法律の基本を理解する
指揮命令権とは何か
「指揮命令権」とは、使用者が労働者に対して業務の内容・方法・時間などを管理・命令できる権限のことです。通常の雇用契約では、会社（使用者）が従業員（労働者）に対してこの権限を持ちます。
業務委託契約では、発注者と受託者（フリーランスエンジニアや業務委託先の企業）の間に雇用関係がありません。そのため、発注者には受託者の労働者に対する指揮命令権が原則として生じません。
「業務委託」という言葉は実務でよく使われますが、民法上は「請負」「委任」「準委任」の3種類に分類されます。いずれの形態でも、発注者が受託者の従業員に直接指揮命令を下すことは禁止されています。
厚労省37号告示が定める「適法な請負」の要件
この原則を法的に定めているのが、厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号、いわゆる「37号告示」）です。
37号告示では、適法な請負・業務委託が成立するために「受託者が自ら労働者の指揮命令を行うこと」を必須要件として定めています。言い換えると、受託者側の管理者が自社の労働者を管理・指揮するのが適法な形であり、発注者がその輪の中に入って直接指示を出すと偽装請負と判断されるリスクが生じます。
（参考: 厚生労働省「37号告示」に関する疑義応答集）
請負・準委任で指揮命令の扱いはどう違う？
業務委託には大きく「請負」と「準委任」の2種類があります。IT・システム開発の現場では準委任が多く使われますが、それぞれ発注者の立場が異なります。
請負契約の場合
請負契約は「成果物の完成」に対して対価を支払う形態です（民法第632条）。システム開発でいえば「この機能を実装したシステムを納品してください」という契約です。
請負では受託者が成果物の完成責任を負うため、作業方法・スケジュール・人員配置はすべて受託者が自律的に決定します。発注者は「何を作ってほしいか（成果物の要件）」を伝えることはできますが、「どう作るか（作業方法）」に口を出すと指揮命令とみなされるリスクがあります。
準委任契約の場合
準委任契約は「業務遂行」に対して対価を支払う形態です（民法第656条・第643条準用）。「月○時間の開発業務を行ってください」という形態で、アジャイル型開発でよく使われます。
準委任でも指揮命令の禁止は同様です。受託者は「善管注意義務（善良な管理者としての注意義務）」を持って業務を遂行する義務を負いますが、遂行方法は受託者が自律的に決定します。発注者は成果・方向性を示すことはできますが、個々のメンバーへの直接指示は禁止されています。
発注担当者が自社の契約形態を確認するポイント: 契約書が「〇〇の完成」を目的とする場合は請負、「〇〇業務の遂行」を目的とする場合は準委任に該当することが多いです。不明な場合は契約書を法務担当者や弁護士に確認することをお勧めします。
「適法な指示」として許容される4つの例外パターン
「原則禁止」とはいえ、すべての指示・コミュニケーションが違法になるわけではありません。37号告示およびその疑義応答集では、以下の4つのパターンが「指揮命令に該当しない（または例外的に許容される）」として認められています。
例外①安全衛生・緊急時の指示
火災・地震などの災害時、または作業環境での安全確保が必要な場面では、発注者が受託者の労働者に直接安全指示を出すことが認められています。
「いますぐ建物から避難してください」「この機器に触れると感電の危険があります」といった生命・安全に直結する指示は、例外として適法とされています。これは労働安全衛生法上の義務に基づくものです。
日常的な安全衛生管理（社内のルールの遵守指示など）については、事前に契約書や業務手順書に定めておくことで適法化できるケースがあります。
例外②業務内容の変更依頼（受託者管理者を通じた場合）
仕様変更や品質改善の要求は、受託者側の管理責任者に対して行うのであれば適法です。
たとえば「この機能の仕様を変更したいので、対応をお願いしたい」という依頼を受託者の責任者に伝え、実際の対応方法と人員の割り振りを受託者が自律的に決定する形であれば問題ありません。
NGになるのは、発注者が受託者の個々のメンバーに直接「この機能を今週中に直してください」と指示するケースです。依頼先を「受託者の管理責任者」に限定することがポイントです。
例外③法令遵守のための指導
個人情報保護法・著作権法・情報セキュリティポリシーの遵守に関する指示は、発注者が直接行うことが認められています。
「この情報は社外持ち出し禁止です」「このデータは個人情報なので取り扱いに注意してください」といった指示は、法令遵守の観点から例外的に許容されます。ただし、業務遂行方法全体を管理する内容にならないよう注意が必要です。
例外④事前に合意した業務手順書・マニュアルに基づく指示
事前に受託者と合意した業務手順書やマニュアルに基づく指示は、それ自体は指揮命令とはみなされないとされています。
たとえば「この開発作業は契約書別紙の手順書に従って進めてください」という内容を事前に合意しておき、その手順書の範囲内での指示であれば問題ありません。ただし、実際の労務管理（勤怠・作業時間の管理など）は引き続き受託者が行う必要があります。
IT現場のグレーゾーンを整理する——SlackとJiraでの指示はOK？
発注担当者が最も悩むのが、日常的なITツールを使ったコミュニケーションが偽装請負になるかどうかという点です。厚労省は2021年に「37号告示に関する疑義応答集（第3集）」でアジャイル開発について明確なガイダンスを示しています（参考: 厚労省疑義応答集第3集）。
Slack・メール・チャットでの指示（OK/NGの判断基準）
OK（適法）な例:
- 「今週の成果物の方向性について確認したい」という情報共有
- 「仕様書のこの部分を確認してほしい」という資料の共有依頼
- 「QAの結果をフィードバックします」という品質情報の共有
- 技術的な質問への回答や情報提供
NG（偽装請負リスクあり）な例:
- 「Aさん、今日の午後からこのタスクに取り組んでください」という個人への作業指示
- 「明日の朝9時から作業を開始してください」という時間管理に関する指示
- 「今日中にこのバグを修正してください」という個人メンバーへの期限指定
ポイントは「受託者の特定の個人」に直接、作業内容・時間・方法を指示しているかどうかです。チームへの情報共有や方向性の確認であれば問題になりにくいですが、個人への具体的な業務指示はリスクが高まります。
タスク管理ツール（Jira/Backlog）でのアサイン
プロジェクト管理ツールでの操作も、誰が行うかで判断が変わります。
OK: 受託者チームのメンバーが自分たちでタスクをアサインし合う OK: 発注者が「ユーザーストーリー（要求・ゴール）」を登録し、タスクへの分解と担当割り振りは受託者が行う NG: 発注者が受託者の個別メンバーにタスクを直接アサインする NG: 発注者がメンバーの工数や作業時間を管理する
スクラム開発・アジャイル手法での指示（スプリント計画・デイリースクラム）
アジャイル開発では、発注者（プロダクトオーナー相当）と受託者チームが密に連携するため、特に判断が難しい場面があります。
厚労省の疑義応答集第3集では、アジャイル開発について以下の原則を示しています。
「受注者側の開発担当者が自律的に判断して開発業務を行っていると認められる場合であれば、偽装請負と判断されるものではない」
具体的には:
- スプリント計画: 発注者が「優先度の高いユーザーストーリー」を示し、スプリント内での実装計画は受託者チームが自律的に決定 → OK
- デイリースクラム: 進捗共有の場として発注者が参加 → OK（ただし個別メンバーへの指示はNG）
- スプリントレビュー: 成果物のフィードバックを受託者責任者に伝える → OK
プロダクトオーナー（PO）とスクラムマスター（SM）が受託者側にいる場合、POやSMを通じて方向性を伝えることが適法な形とされています。
偽装請負と判断される典型パターン（発注者が陥りやすいケース）
意図せず偽装請負に陥りやすいパターンを確認しておきましょう。
「ちょっとだけ指示」が積み重なるケース
個々には軽微に見えても、積み重なると問題になります。
- 「今日はこっちのタスクを優先して」（作業優先順位の直接指示）
- 「この方法でやってみて」（作業方法への介入）
- 「ちょっと早めに上げてほしい」（個人への納期変更依頼）
これらは一つひとつは小さく見えても、継続的に行われると「実質的な労務管理」として判断される可能性があります。
厚労省が示す判断基準のひとつは「誰が指揮命令しているか（発注者か受託者の管理者か）」です。発注者から個々のメンバーへの日常的な直接指示は、たとえ内容が軽微でも蓄積されると問題になります。
勤怠管理・作業時間への介入
- 「今日は何時から作業しますか？」という勤怠確認
- 「残業してでも今日中に終わらせて」という時間外指示
- 「○時から○時まで席にいてください」という在席管理
これらは雇用契約で使用者が行う「労務管理」そのものです。受託者の作業時間・在席状況を発注者が管理することは偽装請負の典型的なパターンとされています。
適法な範囲を最大活用するための実務設計
「指揮命令禁止」を守りながら成果を出すための実務的なアプローチを整理します。
「成果」と「期限」を起点にしたコミュニケーション設計
発注者が伝えてよいのは「何を・いつまでに達成してほしいか」という目標と期限です。「どうやって・誰が」の部分は受託者に委ねます。
実務でのコミュニケーション例:
-
NG: 「Aさんが今週このAPIを実装してください」
-
OK: 「今週末までに認証APIが動作する状態にしてほしいです（受託者責任者へ）」
-
NG: 「毎朝9時にSlackで進捗を報告してください」
-
OK: 「週1回、成果物の進捗をご共有いただけますか？（受託者責任者へ）」
受託者責任者（管理者）を通じた間接指示の仕組み
実務上、最もリスクを減らせるのは「受託者側に管理責任者を置き、発注者とのコミュニケーション窓口を1本化する」仕組みです。
発注者 → 受託者管理責任者 → 受託者のメンバー
という連絡経路を整備し、発注者は常に受託者管理責任者に対して要望・情報共有を行います。受託者管理責任者が実際の作業指示・工数管理・進捗管理を行う形にすることで、37号告示の要件を満たす適法な業務委託が成立します。
この仕組みを契約書や作業範囲書（SOW）に明記しておくことで、万が一調査が入った場合の証拠にもなります。
まとめ
業務委託における指揮命令の範囲をおさらいします。
- 原則: 発注者には受託者の労働者に対する指揮命令権がない（37号告示）
- 例外（適法）: 安全衛生・緊急時、業務変更依頼（受託者管理者経由）、法令遵守指導、事前合意した手順書に基づく指示
- ITツールでの判断基準: 受託者の個人への直接指示はNG。情報共有・方向性の確認はOK
- 実務設計: 「成果・期限」の伝達 + 受託者管理者を通じた間接指示
「指揮命令禁止」は制約ではなく、適切なマネジメント設計のガイドラインとも言えます。目標と期限を明確に伝え、達成方法は受託者の専門性に委ねることで、法的リスクを回避しながら高い成果を引き出す発注設計が可能です。
日々の運用が適法かどうか具体的に確認したい場合は、偽装請負チェックリスト：業務委託で違法にならない指揮命令の境界線もあわせてご活用ください。
また、業務委託契約全体のリスク点検については、業務委託発注の法律・契約リスクを体系的にまとめたお役立ち資料も参考になります。
