為了不構成偽裝承攬的準委任合約正確運作方式 ── 決定關鍵不是合約書的名稱，而是「指揮命令」

「我們簽的是準委任合約，所以不會構成偽裝承攬」

這是系統開發現場偶爾會聽到的說法，但其實是一種誤解。是否構成偽裝承攬，判斷依據並不是合約書的標題寫的是承攬、準委任還是業務委託，而是現場的實際情況，也就是究竟由誰對工程師下達指揮命令。即使簽訂的是準委任合約，只要委託方直接對受託方的工程師下達作業方法或勞動時間方面的指示，那就是偽裝承攬。

本文將根據厚生勞動省公布的資料，從承攬・準委任・勞動派遣的差異開始，整理偽裝承攬的判斷基準（37號告示）、開發現場常見的合規・違規界線、敏捷開發的思考方式，以及委託方・受託方各自應建立的實務做法。

先說明一個貫穿全文的用詞。本文反覆出現的37號告示，是「關於區分勞動派遣事業與以承攬方式實施之事業的基準」（昭和61年勞動省告示第37號）的通稱，告示的編號直接成了這個稱呼的來源。這是行政機關判斷是否構成偽裝承攬時所使用的判斷標準，具體內容將在第4章詳細說明。

此外，本文僅為制度與實務的解說，並非法律意見。個別合約或現場是否構成偽裝承攬，請向都道府縣勞動局（需求調整事業課）或律師確認。

1. 先講結論

企業之間流通工程師的勞動力・勞務的方式，大致可分為以下三種。差異的核心在於「委託方（實際工作場所）能否對工程師下達指揮命令」。

承攬與準委任，都是不會在委託方與受託方勞動者之間產生指揮命令關係的合約。下達指揮命令的，終究是身為工程師雇主的受託公司。若委託方想直接下達指揮命令，那麼應當選擇的合約既不是承攬，也不是準委任，而是勞動派遣。

而形式上簽訂的是承攬或準委任合約，實際上卻由委託方直接對受託方勞動者下達具體指揮命令、使其工作的狀態，就是所謂的偽裝承攬。厚生勞動省的疑義應答集（第3集）也明確指出，即使簽訂的是準委任合約，只要實際存在指揮命令關係，無論合約形式為何，都構成勞動派遣事業，須適用勞動派遣法。

也就是說，「因為是準委任所以沒問題」或「因為是承攬所以沒問題」都不成立，是否沒問題，不是由合約書決定，而是由現場每天的實際工作方式決定——這就是本文整體的結論。

2. 承攬・準委任・派遣 ── 正確區分三種合約

2.1. 承攬 ── 對完成工作負責

承攬（民法第632條）是承諾完成工作，並就其成果收取報酬的合約。在系統開發中，典型形態是「按照這項需求完成系統並交付」，受託方負有完成義務，若交付物不符合合約內容，則須負契約不適合責任。

2.2. 準委任 ── 以善良管理人的注意義務處理業務

準委任（民法第656條）是委託處理非法律行為事務的合約。在系統開發的脈絡中，常用於需求定義支援、技術調查、設計審查、維運、開發支援等場景——這些場景所委託的，與其說是「完成」，不如說是「以專家身分執行業務」這件事本身。受託方所負的不是完成義務，而是以善良管理人的注意處理業務的義務（善管注意義務，民法第644條）。

在2020年4月施行的修正民法中，還明文規定了針對成果、而非業務執行時間支付報酬的所謂成果完成型報酬約定（民法第648條之2），準委任已不再是「只能按時間結算的合約」。

另外，IT業界常用的SES（系統工程服務）並非法律用語。它是對以勞務形式提供工程師技術能力這種交易的稱呼，合約形式多採用準委任——兩者之間僅止於此關係。是否使用SES這個名稱，與適法性的判斷也沒有關係。

2.3. 勞動派遣 ── 唯一能「合法」轉移指揮命令的形態

勞動派遣，是讓派遣單位所雇用的勞動者，接受要派單位的指揮命令，為要派單位工作（勞動派遣法第2條）。若委託方希望直接進行業務指示、勞動時間管理、任務分配，那麼就只有這一種形態可選。作為交換，派遣單位須取得厚生勞動大臣的許可，要派單位也須承擔期間限制、選任要派單位負責人等諸多義務。

把這三種形態並列來看，偽裝承攬的構圖就清晰了。不承擔派遣的成本與義務，卻試圖透過承攬・準委任合約，取得派遣式的用工方式（直接指揮命令），這就是偽裝承攬。

3. 偽裝承攬的問題所在 ── 委託方・受託方雙方的風險

或許有人會覺得，「只要現場運作順利，細節不必太計較」。但偽裝承攬之所以受到規範，是有原因的。一旦下達指揮命令的一方（委託方）與承擔雇用責任的一方（受託公司）相互分離，勞動時間管理、安全衛生、職災責任的歸屬就會變得曖昧不明，勞動者就會被置於保護的空白地帶。勞動派遣法正是透過許可制，加上要派單位・派遣單位各自應負的義務，來管理這種分離狀態。而偽裝承攬，則是在這套管理體系之外，製造出同樣的分離。

具體的風險如下。

行政指導・整改。偽裝承攬違反勞動派遣法，是勞動局指導・整改的對象。厚生勞動省發布了正確實施勞動派遣・承攬的指南，持續推動區分基準的普及。

刑事處罰的可能性。若實際情況屬於勞動派遣，那麼派出勞動力的一方，就可能作為無許可經營的勞動派遣事業，成為勞動派遣法罰則的對象。此外，視具體構圖而定，也可能構成職業安定法第44條所禁止的勞動力供給事業，此時不僅供給的一方，接受供給的一方（委託方）也可能成為罰則（1年以下拘禁刑或100萬日圓以下罰金，同法第64條）的對象。

視為已提出勞動契約要約制度。這是對委託方而言最直接的風險。正如厚生勞動省的宣傳單所述，這是勞動派遣法第40條之6所規定的制度，要點可分解如下。

• 適用對象：違法派遣的5種類型（從事禁止業務、從無許可事業主處接受勞動力、違反事業所單位的期間限制、違反個人單位的期間限制，以及所謂的偽裝承攬等）
• 偽裝承攬等特有的要件：以規避勞動派遣法等適用為目的而締結合約
• 效果：在發生違法派遣的時點，視為接受勞動力的一方已向該勞動者提出了與目前相同勞動條件的勞動契約要約
• 成立條件：勞動者在1年以內做出承諾，即可與委託方之間成立勞動契約
• 例外：接受勞動力的一方不知道屬於違法派遣，且對此不知情並無過失（善意無過失）時，不適用本制度

也就是說，法律上確實可能發生「原本以為是協力公司的工程師，某天卻成了自家公司的員工」這種情況。而且由於承諾的猶豫期長達1年，也可能出現先整改完現場體制、之後對方才承諾該要約這樣的時間順序。

對交易與信譽的影響。整改過程中必然需要重新簽約、調整體制，專案勢必陷入混亂。無論對委託方還是受託方而言，偽裝承攬都不是「不被發現就賺到」的事，而是一旦被發現，雙方都會受損的結構。

4. 判斷基準是37號告示 ── 須同時滿足兩項「獨立性」

那麼，適當的承攬・準委任與勞動派遣，具體是以什麼來區分的呢？基準是「關於區分勞動派遣事業與以承攬方式實施之事業的基準」（昭和61年勞動省告示第37號），也就是所謂的37號告示。

37號告示規定，除非受託方的事業主同時滿足以下全部條件，否則就應被認定為經營勞動派遣事業的事業主。這些條件大致可歸納為兩項獨立性。

第一項是勞務管理上的獨立性 ── 自行直接運用自己所雇用勞動者的勞動力。

第二項是事業經營上的獨立性 ── 將所承接的業務，作為自己的業務、獨立於對方進行處理。

在軟體開發的情形下，最後一項通常是透過「依據自身所具備的專業技術・經驗來處理業務」來滿足的。也就是說，對開發公司而言，實務上的焦點幾乎都集中在勞務管理上的獨立性，尤其是「業務指示」「勞動時間」「配置」這三點分別掌握在誰手中。

此外，37號告示第3條還規定，即使形式上滿足了全部要件，但若是為規避違法而故意偽裝、真正目的實為勞動派遣時，仍應認定為勞動派遣事業。也就是說，僅僅在書面上做足功夫的「對策」是行不通的。

5. 開發現場常見的合規・違規界線

僅憑37號告示，現場判斷仍會感到困惑，因此厚生勞動省在疑義應答集（第1集～第3集）中公布了一系列問答。以下將其套用到系統開發現場，整理出合規與違規的界線。

（各行的依據分別為疑義應答集第1集問1・2・5・7・9・10・11，以及第3集Q4・Q7。）

貫穿整張表的原則只有一條，「公司對公司」的往來沒有問題，但「委託方對工程師個人」的指揮命令則不行。

再舉出另外兩點，在開發現場特別關鍵的論點。

透過文書或工具下達的指示，同樣屬於指示。疑義應答集第1集問7指出，即使委託方是透過文書詳細列出作業的內容・順序・方法，並要求依此作業，同樣會被判斷為偽裝承攬。這並不是說「不用口頭說，寫在工單或聊天工具裡就沒問題」。審查的重點在於是誰寫的，以及它是否實際發揮了指揮命令的作用。

只按「人數×單價」計算的合約很危險。第1集問8指出，若不是以產品或作業的完成來接單・發包，而是以投入的勞動力（人數）來接單・發包，並按勞動力的單價結算，這就屬於單純的勞動力提供，會被判斷為偽裝承攬。準委任本身按時間或工時結算並不會因此被否定，但若合約書中沒有寫明業務內容，只寫著「工程師○名，單價○元」這樣的合約，就很容易被評價為勞動力的提供。前提在於，合約能夠明確特定所委託的究竟是什麼業務。

5.1. 逐漸越界的現場 ── 用於說明的虛構情境

以下並非真實案例，而是把前文所列的基準組合起來、用於說明的虛構情境。不過，其中出現的每一個要素，都對應著上表違規一側的內容，或後文將提到的實務事項。

製造業的A公司，將業務系統的改造以準委任方式委託給B公司。B公司的1名工程師常駐在A公司。合約書只寫著「業務系統改造支援 一式」，請款則是「1名×月額單價」。B公司的管理負責人由這名常駐工程師本人兼任。到這裡為止，是許多現場都可能出現的起點。

• 4月：A公司的負責人開始在晨會上直接向工程師指示作業順序，「今天請先做這個畫面」。原因是案件緊急，通知B公司再等回覆太浪費時間。
• 6月：因為接近月底結算，A公司的負責人直接對本人說「這週請加班」。
• 9月：A公司的其他部門向本人提出「順便也把Excel巨集改一下」的請求。由於合約書未特定業務內容，現場沒有拒絕的依據。
• 12月：工程師身體出狀況，究竟是誰在管理其勞動時間，成了問題。

到這一步，第4章所述勞務管理上的獨立性中，「業務執行管理」與「勞動時間管理」兩項均已不成立。此外，合約未明確業務內容、按人數×單價結算（第1集問8），以及1人常駐且由本人兼任管理負責人（第1集問4）這兩項因素也疊加在了一起。在整改階段，需要重新簽約、重建體制、暫時撤回常駐人員等應對措施，專案將陷入停滯。

另外，是否會進一步發展到視為已提出勞動契約要約制度，還須另外判斷是否存在「以規避勞動派遣法等適用為目的」這項要素。不過，在此之前的行政指導與合約重簽，無論是否存在該目的，都有可能發生。

令人擔憂的是，這4個步驟中的每一步，對當事人而言都只是「一點小小的通融」。並非有人惡意偽裝，而是在忙碌的現場不斷選擇最短路徑的結果，導致合約的線與指示的線逐漸錯位。正因如此，下一章所述的「事先決定請託路徑，並讓全員共享」，才是最有效的對策。

6. 在準委任下正確運作的實務 ── 體制・窗口・報告

了解界線之後，接下來整理如何把它落實到日常運作中的具體做法。要點在於，用合約與體制把指揮命令的路徑固定下來。

flowchart TB
    subgraph OK["合規的準委任"]
        direction TB
        A1["委託方"] -->|"委託・要求・對成果物的意見"| B1["受託公司"]
        B1 --> C1["管理負責人"]
        C1 -->|"指揮命令"| D1["工程師"]
    end

    subgraph NG["偽裝承攬"]
        direction TB
        A2["委託方"] -->|"合約"| B2["受託公司"]
        A2 -->|"直接指示<br/>分配任務<br/>指示作業步驟<br/>指示加班或假日出勤"| D2["工程師"]
    end

「合規的準委任」這一側，來自委託方的請求先由受託公司接住，經管理負責人傳達給工程師。要點在於箭頭連成了一條線。「偽裝承攬」這一側，合約的線雖然存在於兩家公司之間，實際的指示卻從委託方直接飛向了工程師。合約的線與指示的線相互錯位，這就是偽裝承攬的圖景。

6.1. 受託方應建立的機制

• 在合約書・訂單中明確業務內容。不要只寫「系統開發支援一式」，而要寫明目標系統、業務範圍、體制、期間、報告方式。要採用成果完成型還是履行比例型（以時間・工時為基礎），也在此處決定。
• 設置管理負責人（現場負責人）並賦予其權限。管理負責人是在受託方一側，負責與委託方對接、向工程師下達指示、管理進度與品質的人。正如疑義應答集第1集問4所述，管理負責人本人兼任作業本身並不成問題，但若實際上無法履行管理職責，就沒有意義──若常駐成員只有1人，且由本人兼任管理負責人，那麼委託方的訂單就會直接變成對個人的指揮命令，因而被判斷為偽裝承攬。在只有1人常駐的案件中，需要設計一套讓公司內部的主管能夠實際發揮管理負責人作用的機制（把接受委託的窗口設在公司層級，並在公司內部定期進行報告・審查）。
• 由自家公司管理出勤。上下班、休假、是否加班的判斷，由身為雇主的受託公司來做。遵守委託方大樓的出入管理規定，或委託方出於安全確認目的掌握在場情況，屬於「單純掌握」的範圍，但「希望加班」「明天請早點來」這類要求，必須一律經由自家公司來接收。
• 留存業務報告。把受到什麼委託、做了什麼、如何完成，以月度或週度報告書・完工報告的形式留存下來。這既是應對偽裝承攬的對策，同時也是履行善管注意義務的記錄。

6.2. 委託方應建立的機制

• 委託事項統一交給窗口（管理負責人）。新的作業委託、優先順序變更、返工要求，應提交給受託公司的窗口，而不是工程師個人。正如疑義應答集第1集問2所述，向公司提出對成果物的要求・投訴，屬於正當的發包行為。
• 不指名特定個人。「希望讓A加入」「希望把B換掉」，屬於對受託方配置決定權的干涉，不被認定為合規的承攬・準委任（第3集Q7）。技術能力的確認，應以不指定特定個人的技能表等方式進行。
• 事先明確會議的定位。應將定期會議定位為傳達需求・規格、共享進度、討論課題的場合，而不是向個人分配任務的場合。雙方全員參加會議或聊天群組本身並不成問題（第3集Q6），但若委託方在其中開始向工程師直接下達指示，就會構成偽裝承攬。
• 區分「掌握」與「管理」。掌握進度與品質，並在不符合合約內容時向公司要求整改，是委託方理所當然的權利。但若以此為手段，開始干預工程師的時間運用方式或作業步驟，那就屬於管理＝指揮命令。

6.3. 應事先與現場成員共享的事項

偽裝承攬往往並非始於合約負責人，而是始於現場的善意。委託方的負責人對鄰座的工程師說一句「這個也順便拜託了」，工程師也沒有惡意地接受下來 ── 這類請託看似只是閒聊的延伸，其實並非「與業務無關的日常閒聊」，而是業務委託，本來就應該經由窗口進行的往來。這種情況一旦累積，就會直接構成委託方指揮命令的實際狀態。事先向委託方・受託方雙方的現場成員，共享請託的路徑（該向誰請託、該由誰接受請託），最終才是最有效的做法。

7. 敏捷開發與偽裝承攬 ── 「對等協作」就沒有問題

「如果委託方與受託方密切交流就會構成偽裝承攬，那敏捷開發豈不是行不通？」──對於這個疑問，厚生勞動省在疑義應答集第3集（2021年公布）中給出了正面回答。2026年5月新增了Q8，明確指出這個思路同樣適用於敏捷型開發以外的系統開發。

要點如下。

• 密切協作・資訊共享・技術性建議與提案都沒有問題。若委託方與受託方的開發相關人員，作為一個團隊隨時共享資訊，在對等的關係下協作，且受託方的開發人員被認定為是在自主判斷下推進開發，那就不構成偽裝承攬（Q2・Q5）。
• 產品負責人對待辦清單的說明也沒有問題。委託方的開發負責人，直接向受託方的開發人員詳細說明產品待辦清單（Product Backlog）的內容、提供開發所需的資訊，這件事本身並不成問題（Q4）。
• 界線依然在於指揮命令。若這種說明或討論，實際上變成了關於業務執行方法或勞動時間的指示，那就構成偽裝承攬（Q4・Q5）。當進度延遲、需要就工作分配・順序・緩急進行調整指示時，這項工作本應由受託方的管理負責人來進行；若由委託方直接進行，即便已經選任了管理負責人，仍會被判斷為偽裝承攬（Q3）。
• 事先的機制設計很重要。建議事先明確雙方的角色・權限、團隊內部的業務推進方式並達成合意，並透過相關人員的培訓等，共享「敏捷開發是由開發人員自主推進」這項認識（Q2）。

也就是說，並非因為採用敏捷開發就更容易構成偽裝承攬，而是當打著自主團隊的名義、實際上卻由委託方在調度成員時，才會構成偽裝承攬。只要能將Scrum中的「自我組織化團隊」落實到實際運作中，採用準委任的敏捷開發就是制度上原本設想的工作方式。

8. 承攬・準委任・派遣，該選擇哪一種

最後，整理一下究竟該選擇哪種合約才適切。

重要的是，不要出於「想下達指揮命令，卻又想規避成本與義務」的心態而選擇準委任。這不是合約選擇，而是偽裝承攬的入口。若作為委託方確實有直接管控的需求，正確的順序應該是改用派遣合約，或研究能否透過受託方的體制（經由管理負責人運作）來滿足這項需求。

總結

• 是否構成偽裝承攬，判斷依據不是合約書上的名稱，而是委託方是否對受託方的勞動者直接下達了指揮命令這一實際情況。即使簽訂的是準委任合約，也可能構成偽裝承攬
• 承攬・準委任是不會在委託方與工程師之間產生指揮命令關係的合約，唯有勞動派遣才能直接下達指揮命令
• 判斷基準是37號告示。須同時滿足：業務執行・勞動時間・配置的管理由受託方自行進行（勞務管理上的獨立性），以及依靠資金・責任・專業技術獨立處理業務（事業經營上的獨立性）
• 日常會話、規格說明、向公司提出的要求、對等的技術性討論都沒有問題。向個人分配任務、直接指示作業步驟、直接指示加班、指名或要求更換成員，都是偽裝承攬的訊號
• 常駐與座位混雜本身並不構成偽裝承攬。像「1人常駐＋管理負責人兼任」這種、導致訂單直接等同於對個人下達指揮命令的體制，才是危險所在
• 只要對等協作以及受託方成員的自主判斷在實際上成立，敏捷開發就不構成偽裝承攬。這個思路同樣適用於敏捷以外的開發
• 偽裝承攬的風險不僅限於行政指導與刑事處罰，根據視為已提出勞動契約要約制度，委託方還可能被視為已向工程師提出了勞動契約要約
• 若拿不定主意，可以向都道府縣勞動局諮詢。關於是否符合視為已提出勞動契約要約制度的情形，勞動局也設有提供建議的機制（勞動派遣法第40條之8）

給正在考慮受託開發・技術支援推進方式的您

若想委託外部工程師進行開發，或者對現行的常駐・支援形態是否合適感到擔心，最先應梳理清楚的是「想委託的究竟是什麼（完成物、業務，還是勞動力）」以及「由誰下達指揮命令」這兩點。只要這兩點確定下來，究竟應以承攬・準委任還是派遣哪種形式來組成，體制與窗口該如何設計，也就自然而然能夠確定。

合同會社小村軟體以Windows應用程式為中心，承接受託開發與技術支援，無論是承攬還是準委任的形式，皆可承接。我們以明確業務範圍與成果物的合約、透過窗口與報告推進的方式為基本原則，即使您尚處於「不知道該如何切分委託內容」的階段，也歡迎諮詢。

準委任只要運用得當，非常適合需求尚未完全確定的開發，以及持續性的改善工作。請從讓合約形式與現場工作方式保持一致做起，打造一個委託方與受託方雙方都能安心協作的體制。

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

SES與準委任合約是同一回事嗎？

SES（系統工程服務）並非法律用語，而是業界對於以勞務形式提供工程師技術能力這種交易的實務慣用稱呼。合約形式多採用準委任合約，但稱之為SES還是準委任，與適法性的判斷無關。真正被判斷的，是委託方是否直接對受託方的工程師下達指揮命令這項實際情況。

在準委任合約下常駐委託方的辦公室工作，是否有問題？

常駐本身並不構成問題。厚生勞動省的疑義應答集中也指出，僅憑委託方的勞動者與受託方的勞動者在同一場所混雜工作這一點，並不能就此判斷為偽裝承攬。真正成為問題的不是場所，而是指揮命令。即使常駐，只要業務指示・勞動時間管理・配置決定都由受託方公司自行進行，就是合規的；反之，即使是遠距工作，只要委託方直接下達指揮命令，同樣可能構成偽裝承攬。

委託方能否直接向受託方的工程師提問或提出請求？

日常性的交談、對規格或需求的說明、資訊提供，以及在對等立場上進行技術性的討論・建議・提案，僅憑這些並不會構成偽裝承攬。另一方面，若委託方直接向受託方的工程師下達作業方法或順序的指示、向個人分配任務、指示加班或假日出勤，就會被視為指揮命令，判斷為偽裝承攬。新的委託或作業指示，原則上應經由受託方的管理負責人（窗口）來進行。

一旦被判斷為偽裝承攬，會發生什麼事？

會作為違反勞動派遣法的行為，成為勞動局指導・整改的對象；若構成無許可的勞動派遣或勞動力供給，還可能成為刑事處罰的對象。此外，根據視為已提出勞動契約要約制度，若是以規避派遣法等適用為目的而實施了偽裝承攬，就會被視為委託方已向該工程師提出了勞動契約要約，只要工程師在1年以內做出承諾，即與委託方之間成立勞動契約。這對委託方・受託方雙方而言，都是重大風險。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。