システム開発を外注したあと、打ち合わせに来る技術者の名刺を見て、契約した会社と違う社名が書かれていることに気づく。あるいは、質問をしても窓口の担当者が毎回「持ち帰って確認します」としか答えない。こうした場面で頭をよぎるのが、自分が払った金額のうち、実際に手を動かしている人にいくら届いているのかという疑問です。
この疑問は、システム開発の中抜きと呼ばれる問題として語られてきました。ただし世の中に出回っている記事の多くは、常駐して働くエンジニア側の立場から「いくら抜かれているか」を論じたものです。発注した側が何を確かめ、何を契約に書けばよいのかを扱ったものは、ほとんど見当たりません。
この記事では、公正取引委員会がソフトウェア業を対象に行った実態調査をもとに、中抜きが何を指すのかを整理したうえで、発注側が商流と契約のどこを確かめればよいのかを順番に説明します。結論を先に言うと、中間に会社が入ること自体は問題ではありません。問題になるのは、何もしていない会社が入っていることに発注側が気づけない状態のほうです。
この記事のポイント
- 公正取引委員会は中抜きを「形式的に関与するだけで業務を行わず利益を上げている者」と定義している
- 与信や要員確保など実質的な貢献がある中間会社は、この定義から除かれている
- 発注側の社内規程や購買ルールが、意図せず階層を増やしていることがある
- 事務代行だけの会社が間に入っても、法律上の責任は発注側に残ると整理されている
目次
システム開発の中抜きとは何を指すのか
中抜きという言葉は、日常会話では「間に入った業者が儲けている」という程度の意味で使われます。ただ、この曖昧さのせいで、正当な役割を果たしている会社まで一緒くたに扱われてしまうことがあります。発注側が判断するには、もう少し輪郭のはっきりした定義が必要です。
公正取引委員会が示した中抜きの定義
公正取引委員会は2022年6月29日に「ソフトウェア業の下請取引等に関する実態調査報告書」を公表しました。資本金3億円以下のソフトウェア業2万1000社を対象としたアンケートと、事業者・団体へのヒアリングをもとにした調査です。
この報告書のなかで、中抜き事業者は次のように定義されています。「多重下請構造の下、商流上は形式的に関与するものの、実際には何ら業務を行うわけでもないのに利益を上げている者」。そして括弧書きで「与信の供与など、業務以外の面で実質的な貢献を行っている場合を除く」と明記されています。
この定義で大事なのは、後半の除外規定です。行政が公式に使っている定義でも、中間に入る会社がすべて中抜きに当たるとは言っていません。判断の分かれ目は、マージンを取っているかどうかではなく、何らかの実質的な貢献をしているかどうかに置かれています。
なお、ここで引用している下請法は、2026年1月1日に「中小受託取引適正化法」へ改称されました。報告書は改称前の資料なので、以下の引用も当時の表記のままにしています。詳しい法的な判断が必要な場面では、弁護士に確認してください。より詳しい内容は公正取引委員会の報告書ページで公開されています。
中間に会社が入ること自体は問題ではない
報告書は、中抜き事業者が介在する問題点を論じる章の冒頭で、はっきりとこう書いています。「中間事業者の介在が一概に問題となるものではない」。前述の除外規定を受けた一文です。
実際、中間に入る会社が果たしている役割はいくつもあります。代表的なものを挙げます。
- 与信の供与。小さな開発会社が単独では受けられない規模の案件で、支払いの信用を引き受ける
- 要員の確保。必要な技術を持つ人を複数社から集めてチームを組む
- 品質と納期の保証。何かあったときに責任を負う主体になる
- 窓口の一本化。発注側が複数社と個別にやり取りしなくて済むようにする
これらは目に見える成果物にはなりませんが、発注側が受け取っている価値です。窓口の一本化ひとつ取っても、5社と個別に契約して個別に進捗を追う手間を考えれば、それを引き受けてもらうことには相応の金額が発生します。
逆に言えば、間に入っている会社に「御社は何を担っていますか」と聞いて、与信でも要員確保でも保証でも窓口機能でもない答えしか返ってこないなら、そこは疑ってよい場面です。丸投げとの線引きが気になる場合はシステム開発の外注丸投げのリスクと発注側が最低限すべきこともあわせて確認してください。
どのくらいの会社が中抜きを感じているか
報告書では、自社が参加したプロジェクトで中抜き事業者が存在すると感じたことがあるかを尋ねています。結果は次のとおりでした。
| 立場 | 「感じたことがある」と回答 | 回答数 |
|---|---|---|
| 全体 | 25.9% | 4,346社 |
| 元請 | 18.5% | 1,711社 |
| 中間下請 | 29.2% | 1,690社 |
| 最終下請 | 33.5% | 945社 |
全体で4社に1社以上、最終下請では3社に1社以上が、本来必要のない会社が商流に入っていると感じています。
この表で注目したいのは、商流の下流にいくほど数字が上がることです。最終下請は33.5%なのに、元請は18.5%と半分近くまで下がります。上流にいる人ほど、その下で何が起きているかが見えていないということです。
そして発注側は、元請よりもさらに上流にいます。つまり、この調査で最も中抜きを感じていない立場の、さらに外側にいることになります。自社が気づいていないことは、中抜きが存在しない根拠にはなりません。多重下請け構造そのものの仕組みは受託開発の多重下請けとは？発注者が丸投げを見抜く確認点を解説で詳しく説明しています。
発注側の調達ルールが階層を増やすことがある
報告書には、中抜きがなぜ起きるかについて、現場から寄せられた声が多数掲載されています。そのなかに、発注側にとって耳の痛いものが含まれています。
ひとつは「大手企業A社から弊社への直接請負が社内規程によりできないとのことで、A社→A社子会社B社→B社と取引のあるC社→弊社の商流となった」という声です。もうひとつは「エンドユーザーの調達、購買の意向により、他の企業を介しての契約となることがある」という声です。
どちらも、階層を作っているのは中間業者の都合ではなく、発注側の社内ルールです。取引実績のない会社とは直接契約できない、資本金や従業員数に基準がある、購買部門が指定する取引先リストにない会社は通せない。こうしたルールは、それぞれに理由があって作られたものです。ただ、その結果として商流が2段3段と伸び、伸びた分だけ実作業に回る金額が減っていきます。
自社の調達ルールを今すぐ変えられるとは限りません。それでも、階層が伸びている原因の一部が自社側にあると分かっていれば、見積もりの読み方は変わります。同じ1,000万円でも、直接契約なら開発に回る額と、2社経由したあとに開発に回る額は違うからです。
システム開発の中抜きを発注側が確かめる手順
ここからは、発注側が実際に何をすればよいかの話です。中抜きを告発することが目的ではありません。払った金額が何に使われているかを把握し、トラブルが起きたときに誰に言えばよいかをはっきりさせることが目的です。
発注前に商流と再委託の範囲を聞く
いちばん確実なのは、契約する前に聞いてしまうことです。発注後に聞くと詮索しているように受け取られますが、選定の段階なら比較のための質問として自然に出せます。
聞く項目は4つで足ります。
- このプロジェクトに入る要員は何人で、そのうち御社の社員は何人か
- 再委託する工程はあるか。あるなら、どの工程を、どの会社に出すか
- 窓口になる担当者はどの会社に所属しているか
- 不具合が出たとき、最終的に修正の責任を負うのはどの会社か
この4つを候補各社に同じ形で聞いて、答えを並べます。まっとうな会社であれば、隠す理由がないので素直に答えます。答えが曖昧だったり、質問の意図を確認し返してくるだけで中身が出てこなかったりする場合は、その時点で情報が出てきていないという事実が判断材料になります。
複数社を比べるなら、聞いた答えを同じ表に落とし込んでおくと後で見返せます。ベンダー選定比較表テンプレート（10カテゴリ100項目で4段階自動判定）には体制や再委託の確認項目も入っているので、そのまま質問リストとして使えます。
契約の曖昧さが中抜きを呼び込む
報告書の提言部分には、発注側に向けた指摘があります。「エンドユーザー・元請にあっては、自身の契約内容の不明確さがサプライチェーン全体における契約内容の不明確さを招き、独占禁止法・下請法違反行為を誘発しかねないことから、契約内容の明確化を図るべき」という一文です。
これは、発注側の契約が曖昧だと、その曖昧さが下にそのまま流れていくという指摘です。作業範囲がはっきりしない契約を元請が受ければ、元請は下に出すときも範囲をはっきりさせられません。その状態で仕様変更が入れば、誰が費用を持つかの話し合いが成立せず、いちばん下が無償で対応することになります。
契約に書いておく項目は、次の4つです。
- 成果物の定義。何が納品されたら完了なのか
- 作業範囲。どこからどこまでが契約に含まれるのか
- 体制。どの会社の誰が何を担当するのか（体制表を契約の添付資料にする）
- 再委託の扱い。事前承諾を必要とするか、報告だけでよいか
とくに3つ目の体制表を添付資料にしておくと効果があります。契約の一部になるため、あとから体制が変わった場合に説明を求める根拠になるからです。成果物の権利まわりを含めて契約で押さえる項目は受託開発の契約で発注者が確認すべきこと（著作権・ソースコード）で整理しています。
中抜きが疑われるときに現れる兆候
すでに発注してしまっている場合でも、進行中に見える兆候があります。報告書に寄せられた現場の声から、発注側の位置から観察できるものを整理しました。
| 観察できる兆候 | 何を示している可能性があるか |
|---|---|
| 契約先の担当者が打ち合わせに一度も同席しない | 契約先が実作業に関与していない |
| 技術的な質問への回答が毎回持ち帰りになる | 窓口が内容を判断できる立場にない |
| 名刺や議事録に契約先と違う社名が出てくる | 再委託の報告を受けていない |
| 提案書や設計書の体裁が回ごとに変わる | 作成している会社が複数ある |
| トラブル時に窓口と連絡が取りにくくなる | 実質的な対応を担える主体が不明 |
報告書には「企画・提案書・資料・問い合わせへの回答などを弊社がすべて作成し、中抜き事業者がやっていることはメールを転送しているだけ」という声や、「契約上間に入っているだけで、何らの付加価値もつけず、トラブルなどがあると真っ先に抜けて、実質的な対応などを一切しない」という声が載っています。発注側から見えるのは、この状態の外側だけです。
兆候に気づいたときの動き方は、まず体制表の提出を求めることです。追及ではなく「今の体制を最新の形で共有してほしい」という依頼にします。ここで出てくる会社名と人数が、契約時に聞いた内容と食い違っているかどうかで、次にすべきことが決まります。
中抜きが入ると発注側の責任はどうなるか
中抜きを損得の問題として捉えると、「多少抜かれても納品されるならいい」という結論になりがちです。ただ、報告書はもう一段踏み込んだ整理をしています。
報告書では、中抜き事業者が下請取引の内容、つまり製品仕様、下請事業者の選定、下請代金の額の決定などに全く関与せず、注文書の取次ぎや代金の請求といった事務手続の代行を行っているに過ぎない場合について、次のように整理しています。この場合、中抜き事業者は親事業者に当たらず、発注者が親事業者、外注取引先が下請事業者に該当する。そのため発注者は、中抜き事業者が介在したあとも引き続き下請事業者との間で法を遵守する必要があり、中抜き事業者を指導する必要がある。
意味するところは明快です。事務代行だけの会社を間に挟んでも、責任は発注側から移らないということです。実際に作業をしている会社との間で問題が起きたとき、間に会社がいるから自社は関係ないという整理にはなりません。
これは、発注側にとって中抜きが金額の話ではなく自社のリスクの話であることを示しています。商流を把握していない状態は、責任だけが残って統制が効かない状態と同じです。なお、個別の取引がこの整理に当てはまるかどうかは資本金区分や取引内容によって変わるため、実際の判断は弁護士に確認してください。
システム開発の中抜きに関するよくある質問
- Q. 中抜きそのものは法律違反ですか
- 中抜きを直接禁じる規定はありません。報告書も「中間事業者の介在が一概に問題となるものではない」としています。ただし、中抜き事業者が商流に加わったことを理由に見積額より著しく低い金額に下げさせる、手数料相当分を代金から差し引くといった行為は、買いたたきや減額として問題になり得ると整理されています。中抜きという状態ではなく、そこで起きる個別の行為が判断の対象です。
- Q. 中間マージンの相場はありますか
- 公的に示された相場はありません。中間の会社が何を担っているかによって妥当な金額が変わるため、率だけを見て高い安いを判断するのは現実的ではありません。発注側が確認すべきなのは率ではなく、その会社が担っている役割と、実作業を行う体制の人数です。
- Q. 中抜きに気づいたら契約を切るべきですか
- 進行中のプロジェクトで契約を切ると、引き継ぎに時間と費用がかかり、結果的に損をすることが多くなります。まずは体制表を出してもらい、実作業を行っている会社と直接話せる場を作れないかを相談するのが現実的です。そのうえで、次回の発注では選定段階で商流を確認する、という順番で改善します。
