下請けいじめを下請法で守る！IT発注トラブル対処術完全解説ガイド

あなたのいまの案件、「相場より少し安いだけの取引」ではなく、明確な下請けいじめと下請法違反のリスクを含んでいるかもしれません。受領拒否、理由のない減額、一方的な返品、支払遅延、「みんなこの条件でやっています」という買いたたき。IT・Web制作・システム開発の現場では、これらが「お願い」「協力要請」「仕様変更」という言葉に包まれ、契約書や注文書に残らないまま日常化しています。

問題は、行為そのものより証拠と判断基準がないことです。チャットとクラウドツールに埋もれた発注内容、口頭ベースの変更依頼、契約書と実務がズレたままの請求・支払。こうした構造的欠陥がある限り、どれだけ頑張っても、あなたの時間と利益は静かに流出し続けます。一般的な下請法の条文解説や無料テンプレートでは、この「IT業務特有の委託構造」と「証拠の欠落」を補い切れません。

このガイドは、法律論の紹介で終わらせず、下請法を実務の武器に変えることを目的にしています。下請けかどうかをざっくり判定する基礎知識、禁止行為の具体的チェックポイント、契約書とメールのどこを押さえれば支払・減額トラブルに耐えられるのか。さらに、実際に飛んでくる相談メールやLINEの文面、交渉時に使える返信テンプレート、報復リスクを抑えた相談先・ADR・下請かけこみ寺の使い分けまで、今日の取引から使えるレベルまで落とし込んで解説します。

読み進めれば、「これは単なる値引き交渉なのか、法律上の禁止行為なのか」「どの書面を残しておけば下請代金を守れるのか」「どのタイミングで通報・相談に切り替えるべきか」を、自社のケースに即して判断できるようになります。顧問弁護士や法務部がなくても、IT発注トラブルから自分の売上と時間を守るための最低限の防御線を、自力で構築できる状態をゴールに設計しています。

この記事全体で手に入る実利を、先に整理しておきます。

セクション	読者が手にする具体的な武器（実利）	解決される本質的な課題
前半（セルフチェック〜証拠管理）	自社の取引が下請法の対象かを判断する目線、禁止行為チェックリスト、契約書・見積書・チャット・請求書を一貫した証拠に変える運用ノウハウ	「これは下請けいじめか分からない」「どの書面をどう残せばいいか分からない」という判断停止状態
後半（交渉・相談先〜マインドチェンジ）	元請けへの具体的な交渉文例、ADR・相談窓口の使い分け、次回の発注から必ず入れるべき契約条件リストと自衛のDX手順	「切られるのが怖くて何も言えない」「毎回同じトラブルを繰り返す」状況からの脱出

下請けいじめは、「我慢強さ」や「関係性」で解決しようとするほど損失が拡大します。必要なのは、感情論ではなく、どこからが違法行為で、どの証拠を押さえ、どの順番で動くかという実務ロジックです。次の案件を泣き寝入りで終わらせないために、ここから先で、あなたの取引にそのまま転用できる具体策を一つずつ言語化していきます。

「うちの業務だけキツくない？」と感じたら読む“下請けいじめ”セルフチェック

「気づいたら、赤字なのに走り続けている」。IT・Web制作・システム開発の現場で、この違和感が出た瞬間が、下請けいじめを疑うタイミングです。

まずは、いまの取引を次の3ステップでざっくり棚卸ししてみてください。

• 誰から発注を受けているか（一次請負か、そのまた下か）

• どこまでが最初の見積・契約書の範囲か

• お金・期日・仕様が、途中でどれだけ変わったか

ここから、典型パターンを具体的に切り分けます。

下請けいじめの典型行為5パターンを、現場のフローで具体解説（受領拒否・減額・返品・支払遅延・買いたたき）

IT・Web系の案件に落とすと、下請法の禁止行為は次のような“現場フロー”になります。

発注 → 制作・開発 → 納品・検収 → 請求 → 支払

この流れの各フェーズで、次の5つが起きていないかをチェックします。

• 受領拒否

  フロー: 納品後、明確なバグ指摘もないのに「まだ受け取れない」と検収を引き延ばされる。
  例: テスト環境で正常動作しているのに、「社内都合」で本番反映を遅らせ、請求タイミングも遅らせる。

• 減額

  フロー: 見積承認済なのに、納品後に「予算が厳しくなった」「他社はもっと安い」で一方的減額。
  例: 100万円で合意し稼働済にもかかわらず、「決裁が通らなかったから80万で」と発言だけで減額しようとする。

• 返品

  フロー: 仕様どおり制作したのに、「社内方針変更」「担当交代」を理由に受領拒否や差し戻し。
  例: デザイン案を3案出し合意も取ったのに、「全部やっぱりナシで、費用は払えない」。

• 支払遅延

  フロー: 契約書の支払期日を過ぎても、サイトの都合や決済システムを理由に支払が後ろ倒し。
  例: 「決済サイトが締まるのが遅れて」「親会社の承認がまだ」で数カ月遅れる。

• 買いたたき

  フロー: 初回から相場を明らかに下回る金額を提示し、「継続案件があるから」と圧力をかけて受注させる。
  例: 工数試算から最低でも70万円は必要な実装を、「この規模なら20万円が相場」と根拠なく押しつける。

下請法用語と現場感を並べると、判断しやすくなります。

現場での出来事	法律上のラベル候補	要チェックポイント
納品後に検収を延々と先延ばし	受領拒否・支払遅延	不具合指摘の有無・書面の有無
「予算がない」で事後減額	減額	見積・契約での合意金額
方針変更で受取拒否	返品・受領拒否	仕様どおりか・相手都合か
サイトサイクル120日超支払	支払遅延	契約上の支払期日
初回から極端な安値強要	買いたたき	相場・実際の工数・優越的地位

IT・Web制作・フリーランスに多い「お願いベース」の有償／無償境界線

「ちょっとだけ」「ついでに」が積み重なると、利益は一瞬で消えます。ここを曖昧にすると、下請法違反の温床にもなります。

有償・無償の境目は、次の3つが揃うかどうかで線引きすると実務上ブレません。

• 作業内容が、最初の見積書・契約書の「給付内容」に書かれているか

• 工数（時間や人数）が目に見えて増えるか

• 相手の一方的な都合変更かどうか

「お願いベース」で特に危ないのは、次のようなフレーズです。

• 「仕様書にはないと思うんですけど、ユーザーの声が出てしまって」

• 「このボタン、やっぱり管理画面からも操作できるようにしてもらえませんか」

• 「一旦これでリリースして、様子を見ながら随時修正お願いします」

これらが来たら、次のどれかで必ず書面に落としてください。

• 見積の再提示（有償対応として金額明示）

• 「今回は無償。ただし次回からは有償」とメールで明記

• 「仕様変更として扱う」ことだけでも、メール・チャットで確認

お願いベースで無償対応しがちな項目の例

• 文言修正が「箇所単位」から「全ページリライト」に膨らむ

• 1画面のUI調整が、全テンプレート修正に波及

• 追加テスト項目・追加デバイス検証が、後から増える

下請・下請事業・委託先のどこまでが下請法の適用対象になるのかを“ざっくり判断”する基礎知識

「自分はフリーランスだし、業務委託だから下請法は関係ない」と思い込んでいるエンジニアは少なくありません。実際には、情報成果物や役務の提供も“下請代金”の対象になり得ます。

ざっくり判断のために、数字計算なしのチェックポイントを置いておきます。

• 相手が自社より「明らかに大きい会社」か（資本金・売上・知名度）

• 仕事の中身が「ソフトウェア開発」「Webサイト制作」「システム保守」「コンテンツ制作」などの役務・情報サービスか

• こちらの立場が、継続して受注するポジションか（元請が他にも多数の下請先を使っている構造か）

項目	ざっくり判断軸	メモ
取引相手の規模	明らかに自社より大きい会社か	上場企業・グループ会社の一次請など
業務の種類	ソフトウェア・Web制作・保守など役務か	情報成果物も「下請事業」に入り得る
契約形態	請負・準委任・業務委託	形式名称より中身で判断
代金の性質	成果物・作業の対価として支払われるか	固定報酬・出来高いずれも対象候補

私の視点で言いますと、IT・Web業界では「クラウドソーシングだから下請法は関係ない」と思い込んだまま、買いたたきや支払遅延を受け入れてしまうケースが目立ちます。契約書や利用規約の文言だけで判断せず、上の表で一度“構造”を確認しておくと、取引委員や相談窓口に相談できるかどうかの感覚がつかみやすくなります。

下請法を「武器」に変える：禁止行為と適用対象を、現場の言葉で読み解く

「それ、ただの“キツい案件”じゃなくて、法律が味方してくれる状態かもしれません。」
IT・Web・システム開発の現場で、下請法を“読める言葉”に翻訳していきます。

規制対象はどこからどこまで？ 資本区分・規制対象業種・下請代金の範囲を“計算しないで理解する”ガイド

IT・Web系の現場でまず押さえるのは、「自分がそもそも下請法の世界にいるか」です。細かい金額計算より、ざっくり3ポイントで判断した方が現場では早いです。

1. 仕事の中身は何か

• システム開発・Web制作・アプリ開発 → 多くが「情報成果物の作成」＝下請法の役務対象になりやすい

• 常駐エンジニア・運用保守 → 契約形態によっては「請負」「準委任」が混ざるが、成果物があれば対象になりうる

2. 取引の立場関係

• 元請（親）から見て「発注側」か「受注側」か

• 元請が明らかに大企業／自社は中小・個人事業主

• 発注元が案件の内容・金額を一方的に決めてくる優越的地位があるか

3. お金の流れが“下請代金”にあたるか

• 見積書→発注→納品→請求→支払、という一連の流れで支払われる代金

• SaaS利用料やクラウド料金ではなく、「作成・開発」そのものの対価

ざっくりいうと、「自分が成果物を作って納品し、その対価をもらう立場」かつ「相手の方が圧倒的に強い」なら、下請法の土俵に乗る可能性が高いと見ておくと動きやすくなります。

禁止行為チェックリスト：減額・返品・支払遅延・強制的な割引が該当するかを見分ける判断基準

現場で混乱しやすいのは、「これは値引き交渉か、違法な減額か？」という線引きです。感覚ではなくフローで見ます。

シーン	元請の言い分	下請法的な見方のポイント
納品後に「予算厳しいから10％引いて」	協力要請のつもり	合意なき一方的な減額なら禁止行為候補
バグ対応が長引き「その分は支払わない」	品質問題だから当然	仕様書・チャットの指示内容と突き合わせが必須
入金サイトを勝手に60日→120日に変更	社内ルール変更	合意なしの支払遅延・条件変更は危険ゾーン
完成後のデザインを「全部やり直して」費用据え置き	顧客要望だから	追加給付かどうか、見積と注文書で判断

現場でチェックするときの4つの質問をテンプレにしておくと、相談やADRでも話が早くなります。

• その話は「発注前」か「発注後」か

• その条件変更に、書面やメールで同意したか

• こちらに原因がある不良・遅延なのか、相手都合なのか

• 減額・返品・遅延で、実際にいくら財布から消えるのか（手残りベースで把握）

この4つをメモしておくと、取引委員や下請かけこみ寺に相談するとき、事実関係を整理しやすくなります。

freeeや弁護士コラムでは語り切れない、「書面交付」「注文品・支給原材料・給付内容」のリアルな抜け落ちポイント

IT・Webの案件で一番モレやすいのが、「チャットで済ませた話が書面に降りてこない」ことです。
とくに下請法が重視するのは、次の3つです。

• 注文書（発注書）や契約書の書面交付義務

• 何を作るかを示す「給付内容」

• 元請から渡された素材・データなどの「支給原材料」

現場あるあるの抜け落ちポイントを、チェックリスト化しておきます。

• 見積書には載っていたが、注文書には載っていない機能がある

• FigmaやNotion上で仕様が変わったのに、契約書のスコープが古いまま

• 元請から支給されたテキスト・写真・APIキーの一覧が、どこにも正式に残っていない

• Slack・Chatwork・LINEでの「これもお願い」が、どの時点から有償か整理されていない

私の視点で言いますと、プロジェクト管理ツールは「仕事の効率」は上げても、「法的な証拠」としては弱い運用になりがちです。
最低限、次のルールだけは自社の取引ルールとして決めておくと、下請法を武器にしやすくなります。

• 仕様が変わったら、メールかPDFで“変更確認”を1本流す

• 支給データは、一覧にしてGoogleドライブ等で日付付きで保存

• 割引要請や減額提案には、理由と影響額を書いた返信を必ず残す

ここまでできていれば、「下請けいじめかも」と感じた瞬間に、法律・相談窓口・ADRのどれを選ぶにしても、スタートラインが一段上がります。

「行為そのもの」より怖いのは“証拠不足” ─ 契約書・請求・支払の管理術

「それ、下請けいじめっぽいな…」と感じた瞬間から、勝敗はほぼ証拠管理ゲームになります。やられた内容より、「何が、いつ、どう合意されたか」を説明できるかが勝負どころです。

発注内容と注文内容がズレる瞬間：チャットDX時代の“口約束”をどう書面化するか

IT・Web制作の現場で一番危ないのは、次のような流れです。

• 初回は見積書・契約書で「発注内容」を合意

• その後はチャットで「ちょっとここだけ追加で」「この画面も対応できますか」と要望が積み上がる

• 検収段階で「そこまで頼んでいない」「無償対応の範囲だと思っていた」と言われる

この「ズレ」が起きるのは、チャットが“本当の注文書”になっているのに、書面が更新されないからです。

私の視点で言いますと、実務では次の3ステップを回している会社ほどトラブルが少ないです。

1. 仕様変更や追加依頼は、チャットで受けた瞬間に「有償か無償か」を一度は文字で返す
2. ボリュームが変わる場合は、簡易な「追加見積」「変更確認メール」を必ず1本出す
3. そのメールを、のちの「下請代金」請求の根拠として、案件フォルダに時系列保管する

具体的には、チャットで要望を受けた後、必ずこんな返信を1通返しておきます。

• 「今回のご要望は、当初お見積もりの範囲外となるため、別途お見積もりのうえ対応可否をご相談させてください。」

この1行があるだけで、「暗黙の無償対応」という逃げ道を封じられます。

契約書と現場運用のギャップを埋める、最低限の書面・メールテンプレ（変更・追加・割引要請への返信例）

下請法や民法の条文より、現場ではひな形レベルのメールテンプレのほうが役に立ちます。ここでは「これだけは用意しておきたい」3種を挙げます。

1. 仕様変更・追加作業の確認メール
2. 割引・減額要請への返信
3. 納期変更・検収条件の合意

代表的な文面イメージを表にまとめます。

シーン	目的	例文のポイント
仕様変更依頼を受けた	有償・無償を明確化	「本件は当初契約書第◯条の範囲外のため、追加費用◯円（税別）での対応をご提案いたします。ご承諾いただける場合は、本メールへのご返信にてご同意の意思表示をお願いいたします。」
一方的な減額要請	下請代金の保護	「本件お見積もりおよびご注文書に基づき、下請代金◯円で合意済みと認識しております。ご提示いただいた減額について、合理的な理由のご説明をお願いできますでしょうか。」
「今回は勉強して」割引要求	慣習化を防ぐ	「今回のご要望については、例外的に◯円の割引にて対応いたしますが、次回以降は同条件を前提としない認識で問題ないかご確認をお願いいたします。」

このレベルのテンプレを社内の「契約」「法務」フォルダやクラウド管理システムに保存し、誰でもすぐコピペできる状態にしておくと、担当者ごとの属人対応を減らせます。

手形・決済サイト・下請代金支払条件の「ここだけ見ればいい」ポイント

支払条件の書き方を読み飛ばしている現場は少なくありませんが、下請けいじめかどうかの判定で一番モメるのがここです。長い条項のうち、最低限チェックしたいのは次の3点です。

• 支払期日

  • 「検収完了日の翌月末払い」なのか「検収完了後◯日以内」なのか
  • 手形の場合、手形サイトが120日超になっていないか

• 支払方法

  • 手形払いのみか、振込と選択できるか
  • クラウドの請求書発行システム経由でしか請求できない等、過度な負担になっていないか

• 減額・返品の条件

  • 「発注者の都合によるキャンセル時の下請代金」の扱いが書かれているか
  • 「検査不合格の場合の再委託費用負担」が一方的になっていないか

条項場所	チェックすべきポイント	下請法上のリスク
支払期日条項	手形サイトが120日超、振込でも極端な支払遅延	支払遅延の禁止行為に該当するおそれ
支払方法条項	特定クラウドサービス利用を強制し、手数料が下請負担	実質的な負担転嫁として問題化しやすい
減額・返品条項	発注者都合キャンセルでも代金ゼロ	不当な減額・受領拒否として扱われるリスク

契約書の全条項を読み込むのが難しければ、まずはこの「支払条件」のページだけでも印刷し、プロジェクト開始前に担当同士で共有しておくと、後から社内で「そんな条件だったのか」と揉めるリスクを減らせます。

下請けいじめは、派手な行為よりも、「証拠の薄さ」と「支払条件の読み飛ばし」から静かに始まります。発注・請負・委託の流れを、証拠ベースで組み立て直すことが、自衛のスタートラインです。

相談メールはこう飛んでくる：実際にありえるLINE/メールのやり取り再現

【フリーランス編】「修正は有償のはずが、追加要請が止まらない」相談文と、その返信ドラフト例

「お願いベースの無限修正」は、IT系フリーランスの典型トラブルです。実際の相談はこんなトーンが多いです。

想定相談メール（抜粋）

サイト制作を請負で受注し、契約書では「デザイン修正2回まで」と明記しています。
しかし発注担当者がチャットで細かい修正を次々に依頼し、すでに5回以上修正しています。
「今回はお金出せないけど次の案件紹介します」と言われ、追加請求を言い出しづらくなっています。
下請法上の禁止行為や減額に当たるのか、どう交渉すべきか悩んでいます。

ここで重要なのは、契約書・見積・チャット履歴を「下請代金の範囲を示す証拠」として束ねることです。

返信ドラフト例（チャット・メール兼用）

件名：追加修正対応とお見積りの確認のお願い

いつもお世話になっております。○○の△△です。
現在、当初契約書およびお見積書に記載の「デザイン修正2回」を超えて、5回分の修正対応を行っております。

3月1日、3日、5日、8日、10日のチャットでご依頼いただいた内容は、いずれも当初の発注内容からの追加・変更に該当しますので、以下の通り有償対応としてお見積もりさせてください。
・追加修正3回分：××円（税別）
・追加バナー作成2点：××円（税別）

大変恐縮ですが、下請法および民法上も、合意済み範囲を超える役務提供については書面による条件の明確化が必要とされております。
ご確認のうえ、「上記金額で追加発注する」または「今回の追加修正はここまでとする」のどちらかを、メールにてご返信いただけますと幸いです。

ポイントは次の3つです。

• 「いつからどの修正が追加か」を日付付きで列挙

• 「法律用語を一言だけ」添えて、相手に軽くプレッシャー

• 次に進むための二択を提示し、ダラダラした要求を止める

【中小企業編】「注文品を一方的に返品された」ケースのメール文面と“感情を抑えた”返信テンプレ

在庫リスクを抱える制作会社・システム会社では、「一方的な返品」が下請けいじめになりやすいです。

想定相談メール（抜粋）

親事業者からシステム開発を受託し、検収も完了、請求書も送付済みです。
ところが支払期日の直前に「社内事情で導入をやめることになったので、今回は支払いできません」と連絡が来ました。
納品済みソフトを返品扱いにされている形です。下請法の禁止行為にあたりますか。

返信テンプレ（感情オフバージョン）

件名：納品済みシステムの検収完了およびお支払について

平素よりお世話になっております。○○株式会社の△△です。
本件システムにつきましては、◯月◯日付の検収完了メールおよび同日押印済みの検収書により、納品・検査とも完了している認識です。

そのうえで◯月◯日に「社内事情により導入を取りやめる」とのご連絡を頂戴しましたが、下請法および契約書第◯条に照らし、納品済み成果物の一方的な返品・下請代金の不払いには応じかねます。
既に発生している工数・費用がございますため、◯月◯日支払期日の請求書どおり、××円（税込）のお振込みをお願いいたします。

貴社のご事情についてご相談が必要な場合は、分割払いや納期調整といった別の選択肢も含めて協議させていただければと存じます。

怒りは飲み込み、事実（検収日・請求金額）と条項番号だけで押し返すのがコツです。

報復が怖い取引先への交渉メールで、絶対に書かない方がいい一言／入れておくべき一文

報復が怖い相手ほど、「一言ミス」が命取りになります。私の視点で言いますと、次のフレーズは実務で何度も火種になりました。

絶対に書かない方がいい一言

• 「下請法違反で通報しますからね」

  →脅し文句と受け取られ、関係が即時決裂しやすい

• 「御社が違法行為をしている証拠はすべて持っています」

  →感情戦争に発展しがちで、冷静な交渉にならない

• 「こちらも生活がかかっているんです」

  →法的議論ではなく感情論に見え、軽く扱われやすい

代わりに入れておくべき一文

• 「本件は下請法および契約書第◯条との関係を含め、社内で確認したい事項がございます。」

• 「双方にとって無理のない条件を整理したく、書面ベースでの条件確認をお願いできますでしょうか。」

• 「もし社内判断が難しい場合は、公正取引委員会や下請かけこみ寺等、第三者の意見も参考にしながら協議できればと考えております。」

これらは、「違法」とはあえて言わずに、相手に“法務・取引委員を意識させる」言い回しです。

交渉メールのNG/OKをまとめると、次のようなイメージになります。

観点	NGフレーズ例	代替フレーズ例
相手への攻撃	「違反なので支払え」	「契約および下請法との関係を整理したい」
脅し	「通報します」	「必要に応じて公的相談窓口も検討したい」
感情	「裏切られた気分です」	「双方にとって無理のない条件にしたい」
証拠	「全部スクショ済みです」	「これまでのメール・発注書を整理させてください」

このテーブルを横に置きながら、下書きを一度「NGチェック」してから送るだけで、取引継続と権利保護の両立にかなり近づきます。

「訴える」だけが解決じゃない：交渉・ADR・相談先のリアルな使い分け

「この条件、明らかに下請けいじめだけど、訴えたら仕事が全部飛ぶかもしれない」
IT・Web系の現場は、いつもこのジレンマと隣り合わせです。

いきなり訴訟は割に合わない？ 民事訴訟・裁判外紛争解決手続（ADR）・下請かけこみ寺のコストとリターン

民事訴訟は「最後の一撃」です。時間もコストも重く、継続取引が前提の下請事業者には相性が悪い場面が多いです。

手段	概要	コスト感・時間	向いているケース
民事訴訟	裁判所での正式な紛争解決手続	弁護士費用＋年単位の時間	取引終了後でも損害賠償を取りに行きたい時
ADR（裁判外紛争解決）	調停・あっせんで合意を目指す手続	費用は比較的低く、数か月程度	契約内容や下請代金の支払条件を第三者に整理してほしい時
下請かけこみ寺	中小企業庁系の無料相談窓口	相談は無料、面談も短期	下請法違反か迷う段階・証拠の整理から聞きたい時

IT・Webの委託では、チャットとメールが事実関係の“生命線”になります。ADRや下請かけこみ寺を使う場合も、以下は必須です。

• 契約書・発注書・見積書（電子でも可）

• 仕様変更のやり取り（一連のスレッドを時系列で整理）

• 請求書と支払期日、実際の支払日

• 減額・返品・無料対応を要求されたチャット／メール

私の視点で言いますと、ここを整理せずに窓口へ行くと、相談が「ただのグチ」で終わりがちです。

取引委員・相談ネットワーク・相談窓口を“匿名性”と“報復リスク”で比較する

「名前を出した瞬間に発注を切られるのでは」という恐怖が、通報を止めています。そこで、匿名性×報復リスクで整理しておきます。

相談先	匿名性	報復リスク感覚	ポイント
公正取引委員会・中小企業庁	匿名情報提供可	相手にあなたの名前が伝わらない運用	悪質な下請法違反の通報先
下請かけこみ寺	原則実名だが、相手方への配慮あり	調整しながら進む	交渉の仕方や通知書の書き方まで踏み込める
弁護士（顧問・スポット）	完全守秘義務	行動の仕方次第	契約書・通知書のリーガルチェックに最適
商工会・商工会議所	実名前提	地域で顔が割れている場合は慎重に	中小企業全般の取引トラブル相談に強い

「匿名で通報」と「実名で交渉支援」を、時間差で組み合わせるケースもあります。
先に公取委へ情報提供し、同時に下請かけこみ寺で相談しながら交渉戦略を組み立てる、という流れです。

交渉で終わらせるとき／通報するべきときの線引きと、損害賠償を検討する条件

交渉で済ませるか、通報・訴訟に踏み込むかは、「一時的な無理」か「構造的な搾取」かで分けると判断しやすくなります。

交渉で終わらせる選択肢があり得るケース

• 一度きりの支払遅延で、相手も非を認めている

• 経済状況の悪化による一時的な値引き要請で、事前に書面合意が可能

• 今後の契約書に改善条項を入れることでリスクが下がる

通報・損害賠償を視野に入れるべきケース

• 減額・受領拒否・返品が繰り返され、下請代金の支払が恒常的に削られている

• 優越的地位を背景に「他社はこの金額」「次から発注しない」と事実上の強制

• 仕様変更の無償対応を重ねた結果、自社の人件費が赤字ラインを超えている

損害賠償を検討するなら、「いくら損したのか」を数字で出すことがスタートラインです。

• 無償対応に費やした工数×社内の時間単価

• 遅延・減額された下請代金の総額

• キャンセル・返品に伴う外注費・クラウドサービス費用

これを整理した上で、

1. 交渉文面（通知書・メール）で是正を求める
2. 同時に、下請かけこみ寺や弁護士に相談しリーガルチェック
3. 回答次第で、ADR・公取委への通報・訴訟を段階的に検討

という「階段構造」で動くと、感情ではなく数字と証拠にもとづいた判断がしやすくなります。

それ、単なる値引き交渉ではありません：元請けの“よくある言い訳”を論破する

「このまま飲んだら赤字だけど、断ったら次の発注が飛ぶかもしれない」
IT・Web制作・システム開発で一番危険なのは、露骨な暴言ではなく、“それっぽい言い訳をまとった合法っぽい圧力”です。

下請法的にOKな値引きと、完全アウトな「下請けいじめ」を、現場のセリフベースで切り分けます。

「経済状況が厳しいから協力して」要請が下請法違反になるケース・ならないケース

「うちも経済状況が厳しくて…一緒に乗り越えましょう。10％だけ協力してもらえませんか？」

この一言が違法かセーフかを決める軸は、「任意性」と「対価の対応」です。

経済苦境を理由にした要請のざっくり判定軸

ポイント	違反になりやすいケース	違反になりにくいケース
割引の強さ	「協力しないと次は別会社に」など暗黙の脅し	応じなくても今後の取引条件が変わらない
対価	一方的な下請代金の減額	代わりに追加発注・支払サイト短縮などのメリット
交渉余地	見積書・契約書を無視して一律カット	金額根拠を開示し、条件をすり合わせ
タイミング	納品・受領後に「やっぱり下げて」	契約前・作業前の段階で相談

特に下請法の「減額」の禁止行為に触れやすいのが、検収後の一方的カットです。

• 納品済みWebサイトに対して

「社内承認が下りないので30％カットでお願いします。支払期日はそのままです」
これはほぼ減額違反の典型パターンです。
完成している成果物に対して支払うべき下請代金を、発注側の事情だけで削ることは認められていません。

一方、着手前に

• 「見積金額だと社内稟議が通らない。ページ数を減らして、この金額に収まる形で仕様を組み直せないか」

と仕様と金額をセットで再設計する相談は、通常の値引き交渉と評価されやすく、下請法違反とは別次元の話になります。

私の視点で言いますと、経営が苦しい発注側ほど「協力」の名の下に、期限だけそのまま・仕様もそのまま・金額だけ下げる要求をしがちです。ここを線引きしないと、フリーランスや中小企業側の収入だけが一方的に削られます。

「他社はみんなこの条件です」という割引・コスト削減要求のウラにある独占・優越的地位の問題

IT・Webの多重下請構造では、一次請・二次請に対し

• 「他社はもっと安くやっています」

• 「このレートで請けている会社がほとんどですよ」

と、“みんなやっている”論法が頻繁に使われます。ここで見るべきは、価格水準の正しさよりも、元請けの優越的地位です。

「優越的地位」が疑われる典型シグナル

• 売上の大半をその発注元に依存している

• 案件を切られたら事業継続が危うい

• 見積や契約条件をほぼ一方的に押し付けられている

• 代替となる取引先を短期では見つけづらい

この状態で「他社は皆この条件」と言われると、下請法上の「買いたたき」や、独占禁止法上の「優越的地位の濫用」に接近します。

特に危ないのは次のようなケースです。

• システム開発の途中で

「この機能、他社は追加費用なしでやっていますよ。御社も同じ条件で対応してください」

• 制作中のLPに対して

「今期から全パートナー一律で単価20％ダウンなので、御社も合わせてください」

契約書がすでに締結され、下請代金の金額・算定方法が決まっているのに、途中から一方的に下げる要求は、かなり危険です。
「他社」や「相場」を持ち出しても、過去に合意した契約条件を一方的に変える正当な理由にはなりません。

プロテクトスタンス等の弁護士コラムと照らして見える、“元請けの言い分”のどこが法律上NGなのか

弁護士が書く下請法解説やプロテクトスタンス系のコラムを読むと、発注側の常套句がどの禁止行為にあたるのかが整理されています。現場でよく聞くセリフを、禁止行為の観点で分解すると、論破ポイントがはっきりします。

ありがちなセリフ別・法律上のチェックポイント

• 「今回だけだから、30％引きで請求書を切り直して」

  • 検収後なら「減額」や「買いたたき」の疑い
  • 下請代金の支払期日を守っても、金額の一方的変更はアウト寄り

• 「修正は無償対応でお願いしている会社が多いですよ」

  • 仕様変更かどうかが焦点
  • 見積書や注文書にない作業なら、有償が原則

• 「来期も仕事を回すから、今回は協力ということで」

  • 将来の不確実な仕事を餌に、現在の代金を下げる行為は極めて危険
  • 優越的地位の濫用に該当する可能性

元請けの“言い分”を鵜呑みにするかどうかは、証拠の残し方で大きく差が出ます。

• 「協力要請」が来た日時

• どのチャット・メールで何を言われたか

• 見積書・契約書・注文書に記載された下請代金と支払条件

これらを時系列で並べるだけで、「値引き交渉」だったのか、「下請代金の一方的な減額」だったのかが見えてきます。
ここまで整理しておけば、取引委員会の相談窓口や下請かけこみ寺、弁護士への相談でも、具体的な事例として伝えられるレベルのエビデンスになります。

IT・Web業界ならではの“下請けいじめ”構造：DX・多重委託の盲点

「元請は東京、大手Sier。自分はそのまた3次受け。チャットで飛んでくる指示をこなしてるだけ。…この状態で“親事業者”って誰なんだ？」
IT・Webの現場でよくあるこのモヤモヤこそ、下請法が届きにくい理由のコアです。

多重下請・クラウドソーシング・業務委託が入り混じるときの「誰が親事業者か」の見極め方

IT案件は、請負契約・準委任契約・業務委託・クラウドソーシングがごちゃ混ぜになり、下請事業の線引きが一気に見えづらくなります。私の視点で言いますと、まずは誰から下請代金をもらうのかだけに絞って整理すると霧が晴れます。

見るポイント	具体的なチェック質問	下請法的な「親」候補
お金の流れ	誰から請求書の宛名を指定されているか	直接支払う事業者
指揮命令	誰が仕様・優先順位を決めているか	実質の発注者
交渉窓口	納期・金額を誰と交渉しているか	優越的地位を持つ先

ここで重要なのは、契約書のタイトルより「実態」です。
クラウド経由でも、同じ元請から継続受注し、単価を一方的に減額されているなら、独占禁止法や下請法の問題になり得ます。

【最低限やるべきこと】

• 発注・受注の相手を1案件ごとにメモ（スプレッドシートでOK）

• 「誰の指示で仕様変更したか」をチャットのスクショごとにフォルダ保存

• 毎回の取引条件（単価・納期・支払サイト）を1ページに一覧化

これだけで、取引委員会や相談窓口に相談するときの説明力が一段上がります。

DX案件で頻発する、仕様変更・スコープ拡大・成果物の定義あいまいによる有償／無償トラブル

DX・システム開発でいちばん多いのが、「じわじわ仕様変更」＋「無償前提扱い」です。

典型パターンを整理します。

• 要件定義書では「問い合わせフォーム1種」なのに、チャットで「A/Bテスト用にパターン増やして」「LPにも流用したい」が積み上がる

• 準委任契約なのに、「このタスクは見積に入ってるはず」と言われ、追加工数を請求書に載せさせてもらえない

• リリース後のバグ対応と、後出しの仕様変更が同じ「修正」と呼ばれ、有償ラインが崩壊する

ここで鍵になるのが成果物の定義です。契約書に「成果物」「対象システム」「下請代金の内訳」が書かれていないと、争点がすべて感覚勝負になります。

有償／無償の境界を守るための一文例：

「今回のご要望は、〇月〇日のご発注内容からスコープが拡大しているため、別途お見積・ご同意を前提に対応させてください。」

この一文を、仕様変更のたびにメールかチャット（ログが残るツール）で必ず打ち返すだけで、後から「同意履歴」という証拠になります。

効率重視のプロジェクト管理ツールが、逆に行為の証拠消失を招いている実態

Jira、Backlog、Notion、Slack、Teams。どれも生産性は爆上がりしますが、下請けいじめの現場では「証拠シュレッダー」にもなります。

ツール運用の落とし穴	下請け側のリスク	対応のポイント
チケット単位で仕様が書き換えられる	どのタイミングの仕様で見積したか不明に	初版チケットをPDF保存
スレッドが乱立し履歴が追えない	支払遅延や減額の経緯を説明できない	金額・納期が出たスレだけ別途メール転記
ゲスト権限で過去ログにアクセス不可	取引終了後に証拠を見返せない	関連スクショを自社ストレージに保管

特に危険なのが、「口頭＋チャットで減額・返品・支払遅延を飲まされたのに、正式な書面や通知書が一切ない」状態です。
このケースでは、後から下請法違反を疑っても、取引委員やADRに持ち込む際の証拠が決定的に足りなくなります。

実務的には、次のルールを社内で決めておくと防御力が一気に上がります。

• 支払条件・金額変更・納期変更が出たら、必ず「メールでの確認をお願いします」と一度は打診

• プロジェクト管理ツールの重要チケットは、月1回まとめてPDF化してクラウド保存

• 顧問弁護士がいなくても、無料相談や下請かけこみ寺に持ち込めるレベルのログを意識して整理

DX時代の下請けいじめは、「行為そのもの」より先に、「証拠が残らない設計」で進行します。
ツール任せにせず、自分側でもう一段階、証拠の保管レイヤーを用意しておくことが、取引を続けながら身を守る最短ルートになります。

「古い常識」を捨てる：泣き寝入りしないためのマインドチェンジと行動例

「仕事を切られたら困るから黙っている」は本当に合理的か？ 長期利益とリスクの比較

「今回だけの値下げだから」「次の大型案件もあるから」
そう言われて下請代金の減額や支払遅延を飲み続けるのは、キャッシュを燃やして延命しているのと同じです。

継続取引を優先して黙る判断が、本当に合理的かを数字の感覚で整理します。

項目	今だけ耐えるパターン	早めに線を引くパターン
1案件あたりの粗利	割引・無償対応でじわじわ低下	契約条件を守れない先は縮小
月間の拘束時間	チャット対応/仕様変更で膨張	時間を単価の高い案件へ再配分
法的リスク	書面なし・口約束増加でトラブル時に証拠不足	契約書・メールで証拠を確保
交渉力	「言えば飲んでくれる人」のラベルが付く	「線を持っている事業者」と認識される

私の視点で言いますと、「切られたら困る取引ほど、条件を明文化して守らせる」方が、3年スパンの手残り（利益）とメンタルの安定は確実に大きくなります。
下請法が禁止する受領拒否・減額・返品・買いたたき行為は、短期的な売上よりも長期の事業継続を削ります。ここを「感情」ではなく「事業リスク」として扱うのがマインドチェンジの出発点です。

今回の案件でできる“早期にリスクを減らす”3つの対応方法（コストをかけない順）

いきなり弁護士やADRに駆け込まなくても、今日からできる火消しがあります。コストの軽い順に並べると、次の3ステップです。

1. 証拠を静かに固める（無料）

   • チャット・メール・発注書・見積書・請求書を時系列でフォルダ分け
   • 仕様変更や追加作業の指示がある箇所をスクショ保存
   • 「何が、いつ、誰の指示で変わったか」を一枚のメモに整理

2. “線を引く”確認メールを出す（ほぼ無料）

   • 追加作業のたびに、短くてよいので書面（メール）で条件を明記
   • 例：
     「本件追加バナー2枚について、単価◯円・納期◯日で対応可能です。既存見積書No.◯◯とは別件として請求いたします。」
   • 割引や値下げ要請には、
     「下請法上の禁止行為に該当しない範囲で、◯％までであれば対応可能です」
     と法令名をさらっと出すだけでも、相手の態度が変わるケースが多いです。

3. 第三者の“目”を意識しておく（低コスト）

   • 公正取引委員会の相談窓口、下請かけこみ寺など相談先をブックマーク
   • 「行き先」が見えているだけで、交渉メールのトーンがぶれにくくなる
   • 相手に直接は言わなくてよいですが、いざとなれば通報・相談できるという前提で取引条件を見直すと、判断がシビアになります。

次の発注から絶対に入れておきたい契約条件チェックリスト

IT・Web制作やシステム開発の委託契約で、トラブル現場を一番見ていると感じるのは「肝心な条項だけ抜けている契約書」です。次の発注からは、最低でも次の項目に赤ペンを入れてください。

• 給付内容（スコープ）の定義

  • 画面数・機能一覧・修正回数の上限
  • 「仕様変更時は追加見積り」と明記

• 下請代金と支払条件

  • 金額・支払期日・決済方法（振込/決済サイト/手形）
  • 支払遅延時の遅延損害金や、検収完了の定義

• 変更・追加対応の手続き

  • 追加発注書またはメール合意を書面要件として規定
  • 口頭・チャット指示だけでは効力が出ないことを明文化

• 減額・返品・キャンセルの取り扱い

  • 着手後のキャンセル料率
  • 納品後の一方的な減額・返品を認めない条文

• 著作権・成果物の利用範囲

  • ソースコード・デザインデータの権利帰属
  • 再利用、改変の範囲と追加料金のルール

• 紛争解決と相談ルート

  • まずは協議、次にADRや調停、最終的な管轄裁判所
  • 法務・顧問がいない前提で、証拠は電子データで保管すると決めておく条項

これらはテンプレートや雛形をそのまま貼るのではなく、自社の業務フローとツール（クラウド管理システム、プロジェクトボード、チャット）に合わせて書き換えることがポイントです。
「古い常識」を捨てて、契約書と現場運用をセットで設計することで、下請けいじめは“起きてもすぐ火消しできる小さなトラブル”に変わっていきます。

この記事をどう使うか：チェックリストと次アクションへの落とし込み

「読むだけでタブを閉じる」のをやめて、5分で“守りの一手”まで進めるための使い方をまとめます。

5分でできる現状確認チェックリスト（取引内容・支払状況・書面・社内体制）

まずは、いま進行中の取引がどれくらい危険かをサクッと可視化します。下のチェックが3つ以上「×」なら、下請けいじめリスク高めです。

【取引・支払まわり】

• 最新の発注内容を、1枚の書面かPDFで説明できる

• 下請代金の金額・支払期日・決済サイトが契約書に明記されている

• 直近3件の請求書で「減額」「一方的な返品」「支払遅延」がない

【仕様・変更管理】

• 仕様変更や追加依頼は、メールかチャットで「有償か無償か」を毎回書いている

• クラウドのプロジェクト管理ツールのログとは別に、エビデンス用フォルダで議事録・見積書を整理している

【社内体制・ルール】

• 下請法の禁止行為（減額・受領拒否・返品・支払遅延・買いたたき）を1ページにまとめたメモが社内で共有されている

• トラブル時に誰が交渉窓口になるか、役割が決まっている

「書面がどこにあるか分からない」「チャットを遡らないと取引内容が説明できない」状態なら、まずはこの章を横に開きながら、証拠と契約書の場所を整理するところから始めてください。

失敗しない相談の準備：相談先ごとにまとめるべき情報・質問のポイント

相談するときに“もたつく”のは、情報の並べ方がバラバラだからです。相談先別に、最低限そろえておきたい項目を整理します。

相談先	主な役割	事前にまとめる情報	質問のポイント
公正取引委員会・下請かけこみ寺・商工団体などの相談窓口	下請法違反の有無や通報・勧告の可能性を教えてくれる	取引相手の企業名・資本金規模が分かる資料、契約書・発注書・請求書、減額や返品が起きた日付と金額	「この行為は下請法の禁止行為に該当するか」「通報した場合の流れと匿名性」
ADR機関・調停センター	裁判外の和解・紛争解決	紛争になっている具体的な行為の経緯時系列メモ、損害金額の目安、相手とのメール・チャットのログ	「ADRで解決するメリット・デメリット」「費用と期間の相場」
弁護士（スポット相談・顧問弁護士）	法的見解・損害賠償請求の可能性	上記に加え、自社の収入構造と、取引中止になった場合の影響	「交渉と訴訟のどちらを選ぶべきか」「どこまで請求できるか」

相談メールを書くときは、次の3点だけ押さえます。

• 取引の概要（業務内容・契約タイプ：請負か業務委託かなど）

• 問題行為の具体例（いつ、いくら、どんな要求・減額があったか）

• 相談したいこと（下請法違反の可能性か、交渉方法か、ADRか）

私の視点で言いますと、「感情のグチ」と「事実の時系列」を混ぜるとプロ側が整理し直すコストが増え、回答も遅くなりがちです。時系列はシンプルに、感情は別途メモに吐き出すくらいがちょうど良いバランスです。

顧問弁護士・法務担当がいない会社でも、今日から始められる“自衛のDX”

法務部ゼロでも、IT・Web系なら「道具で守る」ことができます。高価な管理システムにいきなり手を出さなくても、次の3ステップなら今日から動かせます。

【ステップ1：証拠を1カ所に集約】

• クラウドストレージに「01_契約書」「02_発注書・注文書」「03_見積・請求・支払」「04_チャット・メール抜粋」フォルダを作る

• 取引ごとにサブフォルダを切り、PDFかスクリーンショットで保存

【ステップ2：簡易台帳で“見える化”】

• スプレッドシートで「取引内容」「下請代金」「支払期日」「変更有無」「下請法NGっぽい行為」に列を作る

• 支払遅延や減額があったら必ず記録し、月1回は見直す

【ステップ3：テンプレートで交渉の質を底上げ】

• 仕様変更・割引要請への返信テンプレ（「本件は有償変更となる認識ですが、よろしいでしょうか」など）を社内共有

• 電子契約サービスを検討し、契約書の紛失リスクと印紙コストを同時に削減

顧問弁護士がいなくても、ここまで整えておけば、いざ相談するときにリーガルチェックの精度もスピードも上がります。この記事は、チェックリストと台帳作成の“型”としてブックマークしておき、トラブルが起きた瞬間に開ける「現場マニュアル」として使ってください。

執筆者紹介

情報通信分野でIT活用・通信コスト削減・DX支援のハウツー記事を数多く発信してきた株式会社アセットは、Webメディア運営を通じて中小企業・フリーランスの発注・委託トラブルや契約運用の課題を継続的に整理してきました。本記事では、公正取引委員会や中小企業庁などの公的情報と、情報通信業の一般的な委託構造に関する知見をもとに、下請法とIT実務を橋渡しする「現場で使える対処ロジック」を提供しています。