case_635 士業・専門業務

下請法改正(取適法)対応をClaude Codeで仕組み化する実装パターン

下請法改正(取適法)対応をClaude Codeで仕組み化する実装パターン

2026年1月施行の取適法(下請法改正)への対応点検。従業員基準での適用再判定・受領日起算60日の支払期日チェック・発注書面の明示事項点検・手形払い等の支払手段確認をClaude Codeで仕組み化する実装パターンを公取委一次情報で解説。

結論:2026年1月1日に施行された改正下請法(新通称「取適法」)への対応は、①適用対象の再判定(従業員300人/100人基準の追加)②受領日起算60日以内の支払期日チェック③発注書面の明示事項点検④手形払い等の支払手段の総点検、の4つに分解でき、発注・支払データがCSVで出せる会社なら、いずれもClaude Codeで点検スクリプトとして仕組み化できます。施行から半年が経ちましたが、実務で漏れやすいのは「資本金基準では対象外だったが、従業員基準の追加で新たに対象になった取引」の見落としです。

要点1:従来の資本金基準(3億円/5千万円区分)に加えて従業員基準(300人/100人)が追加され、規制対象が拡大された。資本金1,000万円ちょうどまで減資していた会社の取引も、従業員数次第で対象になり得る(公正取引委員会 取適法リーフレットNo.01より)

要点2:支払期日は「物品等を受領した日から起算して60日以内のできる限り短い期間内」。検査をするかどうかを問わず起算されるため、「検収完了から60日」と運用しているとその時点で違反リスクがある。超過時の遅延利息は年率14.6%

要点3:手形払は支払手段として禁止され、電子記録債権等も支払期日までに代金相当額の満額を得ることが困難なものは禁止された。支払方法マスタに「手形」が残っていないかの機械スキャンが最初の一手になる

対象読者:発注側(委託事業者)の購買・経理部門とAI活用を進める開発者・PM。発注件数が月数十件を超え、Excelでの目視点検が回らなくなっている現場を想定しています。

今日やること:取引先マスタに「資本金」「従業員数」の列があるかを確認する。なければ、それがこの記事のパイプラインの最初の作業在庫です。

2026年1月、下請法は「取適法」になった——何が変わったか

2025年5月16日に成立した改正法が2026年1月1日に施行され、法律名は「下請代金支払遅延等防止法」から「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」に変わりました。通称は「中小受託取引適正化法」、公正取引委員会の使う略称は「取適法(とりてきほう)」です。用語も一新され、「親事業者」は「委託事業者」、「下請事業者」は「中小受託事業者」、「下請代金」は「製造委託等代金」になりました。

公正取引委員会のリーフレット(令和7年8月・No.01)を一次情報として、実務に効く変更点を6つに整理します。

  1. 従業員基準の追加——従来の資本金基準に加え、従業員数(300人/100人)で対象を判定する基準が追加され、規制・保護の対象が広がった
  2. 特定運送委託の追加——製造等の目的物の引渡しに必要な運送の委託が適用対象取引に追加された
  3. 「協議に応じない一方的な代金決定」の禁止——価格協議の求めに応じない、必要な説明を行わないなど、一方的な代金決定が禁止行為になった
  4. 手形払等の禁止——手形払が禁止され、電子記録債権等その他の支払手段も、支払期日までに満額を得ることが困難なものは禁止された
  5. 書面交付の電磁化——発注内容の明示は、中小受託事業者の承諾の有無にかかわらず電子メール等の電磁的方法でよくなった
  6. 面的執行の強化——公取委・中小企業庁に加えて事業所管省庁にも指導・助言の権限が付与された

このほか、製造委託の対象物品に金型以外の型等が追加されています。中小企業庁のミラサポplusの解説では、振込手数料を受注者に負担させて代金から差し引くことも禁止行為として整理されており、支払実務側の点検項目は確実に増えました。

重要なのは、これらの多くが「契約書の話」ではなく「発注・支払データの話」だということです。適用判定は取引先マスタの属性、60日ルールは受領日と支払期日の日付演算、書面明示は発注レコードの必須項目、手形禁止は支払方法コード。つまり大半が、CSVを読んで規則と突き合わせるスクリプトで機械点検できる領域です。

対応の本丸は「適用対象の再判定」——従業員基準で対象が広がる

取適法の適用対象は「①取引の内容」と「②資本金基準又は従業員基準」の組み合わせで決まります。リーフレットの整理をそのまま引くと、次の2グループです。

取引グループ 委託事業者側 中小受託事業者側
製造委託・修理委託・特定運送委託・情報成果物作成委託(プログラム)・役務提供委託(運送・物品の倉庫保管・情報処理) 資本金3億円超/資本金1千万円超3億円以下/従業員300人超 資本金3億円以下/資本金1千万円以下/従業員300人以下
情報成果物作成委託・役務提供委託(上記以外。デザイン、コンテンツ制作、一般的なサービス委託など) 資本金5千万円超/資本金1千万円超5千万円以下/従業員100人超 資本金5千万円以下/資本金1千万円以下/従業員100人以下

実務で怖いのは、旧下請法時代に「うちは資本金基準で対象外」と整理して終わっていた取引です。従業員基準の追加で、資本金を1,000万円以下に抑えている委託先・自社の組み合わせでも対象になるケースが生まれました。取引先マスタに従業員数の列がない会社は、そもそも判定の入力データが存在しない状態です。

なお、資本金と従業員数のどの組み合わせで適用になるかの厳密な条文適用は、公取委の特設サイトとガイドブックに判定チャートがあります。この記事のスクリプトは「明確に対象」「明確に対象外」「要確認」の3値で出力し、要確認を人(法務)に回す設計にします。境界ケースをスクリプトで断定しないことが、この種の法令チェック自動化の生命線です。

設計原則——判定は機械、確定は人。スクリプトは「網」であって「裁判官」ではない

このサイトで繰り返し書いている原則ですが、法令対応の自動化では特に強調しておきます。Claude Codeで作るのは「全件を漏れなく点検して、疑わしいものを人の前に並べる網」です。個別取引が取適法違反かどうかの確定判断は、法務・顧問弁護士の仕事として残します。

  • 機械がやること:全発注レコードの60日演算、必須項目の欠落検知、支払方法コードのスキャン、対象判定の一次分類
  • 人がやること:「要確認」に分類された取引の精査、契約類型の解釈(そもそも製造委託か、売買か)、違反疑い時の是正判断
  • 両者の界面:毎週・毎月の例外レポート。件数がゼロに近づくほど、体制として健全になっていく

取引類型の判定(この契約は「製造委託」か「売買」か「請負」か)は、契約書の実態を読む仕事であり、CSVの列からは確定できません。スクリプトの入力に使う「取引類型」列は、法務が一度整理した結果を持たせる前提です。逆に言うと、この列を一度整備してしまえば、以後の新規発注は機械が守ってくれます。

実装1:取引先マスタ×委託類型で適用対象を一次判定する

入力は2つ。名寄せ済みの取引先マスタ(資本金・従業員数の列を追加したもの)と、取引類型を整理した発注マスタです。マスタが名寄せされていないと同一取引先が複数行に割れて判定が漏れるので、名寄せはこのパイプラインの前提工程になります。

Claude Codeへの最初の指示はこの程度で十分です。

取引先マスタ vendors.csv(資本金 capital_yen、従業員数 employees、
取引類型 contract_type)を読み、取適法の適用対象を一次判定する
Pythonスクリプトを書いて。
- 閾値はコード先頭に定数dictでまとめる(グループA=3億円/300人、グループB=5千万円/100人)
- 出力は「対象」「対象外」「要確認」の3値。境界・欠損は必ず「要確認」に倒す
- 自社側の資本金・従業員数も設定ファイルから読む
- 結果はjudgment.csvに、判定根拠の列つきで書き出す

生成されるコードの骨格はこうなります(判定ロジック部分の抜粋)。

GROUP_A = {"capital": 300_000_000, "employees": 300}   # 製造・修理・特定運送・プログラム等
GROUP_B = {"capital": 50_000_000,  "employees": 100}   # その他の情報成果物・役務

def classify(row, own_capital, own_employees):
    th = GROUP_A if row["contract_type"] in TYPE_A else GROUP_B
    # 入力欠損は判定不能 → 要確認
    if pd.isna(row["capital_yen"]) or pd.isna(row["employees"]):
        return "要確認", "資本金または従業員数が未登録"
    over_capital  = own_capital  > th["capital"]
    over_employee = own_employees > th["employees"]
    under_vendor  = (row["capital_yen"] <= th["capital"]
                     and row["employees"] <= th["employees"])
    if (over_capital or over_employee) and under_vendor:
        return "対象の可能性が高い", "自社が基準超・相手が基準以下"
    if not over_capital and not over_employee:
        return "対象外の可能性が高い", "自社が資本金・従業員とも基準以下"
    return "要確認", "資本金と従業員基準の組み合わせが境界"

ポイントは、断定形のラベルを使わず「〜の可能性が高い」と出すことと、判定根拠を必ず列で残すことです。この出力を法務に渡すと、「要確認」の山から数件ずつ潰していく作業が始められます。ある程度の規模の発注データなら、初回実行で「従業員基準の追加で新たに引っかかった取引先」が具体的なリストとして見えるはずで、これが取適法対応の実質的なスコープ定義になります。

実装2:受領日起算60日の支払期日チェックを先読み型で回す

支払期日の義務はシンプルです。「検査をするかどうかを問わず、発注した物品等を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定めること」。違反して支払遅延や減額を行うと、遅延日数・減額分に応じて年率14.6%の遅延利息の支払義務が生じます。

実装のコツは、支払済みデータの事後監査ではなく「これから来る支払の先読み」にすることです。36協定の上限超過を勤怠データから先読みする実装と同じ型で、締め日と支払サイトの組み合わせから危険な発注を事前に鳴らします。

from datetime import timedelta

LIMIT_DAYS = 60  # 受領日から起算して60日以内

def check_payment_terms(df):
    # 保守的に受領日を1日目として数える(起算日の扱いは公取委ガイドブックで要確認)
    df["deadline"] = df["received_date"] + timedelta(days=LIMIT_DAYS - 1)
    df["over"] = df["payment_due"] > df["deadline"]
    df["days_over"] = (df["payment_due"] - df["deadline"]).dt.days.clip(lower=0)
    return df[df["over"]].sort_values("days_over", ascending=False)

起算日の数え方は保守側(受領日を1日目とする)に倒しておき、コメントで根拠確認先を残しています。ここで多くの現場が引っかかるのが「月末締め翌々月払い」です。暦月で「2ヶ月後」と数える運用は、月初に受領した給付だと60日を超えます。締めサイクル起点ではなく受領日起点で全件演算するからこそ、この種の構造的な超過が発見できます。

もうひとつ実務で効くのが、検収と受領の区別です。取適法の60日は受領日起算で、検査の有無を問いません。発注システムの「検収日」を起点に支払予定を組んでいる場合、検収が遅れた発注はそのまま60日超過に直結します。受領日列が別に存在するか、存在しないなら入荷データから受領日を復元できるか——ここはClaude Codeにデータ構造を調べさせると早い部分です。

実装3:発注書面の明示事項チェック——「口頭発注の残骸」を検知する

委託事業者には、発注に当たって発注内容——給付の内容、代金の額、支払期日、支払方法など——を書面又は電磁的方法で明示する義務があります。改正で電磁的方法の利用に相手の承諾が不要になったため、メール発注・システム発注への移行は進めやすくなりました。裏を返すと、「電話で発注して書面は後追い」「金額は別途調整と書いて空欄のまま」といった運用の残骸が、そのまま義務違反のリスクとして残ります。

チェックの実装は、発注データの必須項目検査として書けます。

REQUIRED = {
    "item_desc":    "給付の内容",
    "amount_yen":   "代金の額",
    "payment_due":  "支払期日",
    "payment_method": "支払方法",
}

def check_order_completeness(df):
    issues = []
    for col, label in REQUIRED.items():
        missing = df[df[col].isna() | (df[col].astype(str).str.strip() == "")]
        for _, r in missing.iterrows():
            issues.append({"order_id": r["order_id"], "missing": label})
    return pd.DataFrame(issues)

「代金の額が0円・空欄・『別途見積』のまま発注済みステータスになっているレコード」は、どの会社の発注データにも一定数眠っています。この検査は取適法対応であると同時に、請求書突合(発注・入荷・請求の3点照合)の精度を上げる下ごしらえでもあります。発注時点の金額が空欄だと、突合はそもそも成立しません。

実装4:支払方法マスタから「手形」を洗い出す

手形払の禁止は、点検としては最も機械化しやすい項目です。支払方法のコード体系に「手形」「でんさい(電子記録債権)」「ファクタリング」系の値がどれだけ残っているかを、取引先別・金額付きで一覧化します。

支払データ payments.csv の payment_method 列の値の分布を集計して。
「手形」を含む値は全件、取引先・直近支払日・年間支払額つきで
banned_methods.csv に書き出して。電子記録債権・ファクタリング系の
コードも別リストで洗い出して(これは満額受領可否の個別確認に回す)。

注意点はひとつ。電子記録債権やファクタリングは一律禁止ではなく、「支払期日までに代金に相当する金銭(手数料等を含む満額)を得ることが困難であるもの」が禁止です。つまり手形は機械判定で「即・移行対象」、でんさい・ファクタリングは「条件確認リスト」に振り分ける2段構えにします。あわせて、振込への切替時に振込手数料を受注者負担にして差し引く運用は、それ自体が禁止行為として整理されている点も、切替の設計時に落とし穴になります。

運用設計——2年保存の記録・証跡・CLAUDE.mdの停止線

取適法には、取引完了後に給付内容・代金の額などの取引記録を書類又は電磁的記録として作成し、2年間保存する義務もあります。電子帳簿保存法の電子取引データ保存を仕組み化している会社なら、同じ保存基盤に載せるのが自然です。帳簿書類の保存は税法側の要件(法人は原則7年)の方が長いため、実務上は「税法・電帳法準拠で保存していれば取適法の2年は自動的に満たす」形に寄せられます。

点検スクリプト自体の運用は、週次バッチ+証跡ログが基本形です。

# 毎週月曜7時に4点検を実行し、例外レポートを生成
0 7 * * 1 cd /srv/toriteki && python3 run_checks.py --out report/$(date +\%Y\%m\%d).md

そしてCLAUDE.mdに停止線を焼き込みます。法令チェック系のリポジトリでは、AIに「直させない」ことが品質保証になります。

# CLAUDE.md(抜粋)
- このリポジトリの判定結果は一次スクリーニング。法適用の確定判断はしない
- 閾値定数(GROUP_A/GROUP_B・LIMIT_DAYS)の変更は法務承認が必要。勝手に変えない
- 「要確認」を「対象外」に自動で倒す変更は提案も実装も禁止
- 判定根拠列・実行日時・入力ファイルのハッシュをレポートに必ず残す

週次レポートの「要確認」件数と「60日超過予備軍」件数が減っていくグラフが、そのまま経営報告に使える対応進捗のKPIになります。

失敗パターンと回避策

❌ 失敗1:スクリプトに適用可否を断定させる
「対象外」と機械が断定した取引に実は従業員基準が刺さっていた——という事故が最悪のパターンです。
⭕ 回避策:出力は3値(対象の可能性が高い/対象外の可能性が高い/要確認)に固定し、欠損・境界は必ず「要確認」へ。閾値と分類ロジックの変更は法務承認をCLAUDE.mdの停止線で強制する。

❌ 失敗2:検収日を起点に60日を数える
支払期日の起算は受領日で、検査の有無を問いません。検収遅れがそのまま支払遅延になる構造は、データを受領日起点に組み替えないと消えません。
⭕ 回避策:受領日列を正とし、検収日ベースの支払サイト設定には「構造的超過リスク」のフラグを立てて棚卸しする。

❌ 失敗3:施行日以降の新規発注だけ点検する
取適法対応を「1月以降の新規契約のチェックリスト」に閉じると、旧下請法時代から継続している定期発注・自動更新契約が漏れます。従業員基準で新たに対象になるのは、むしろこの継続分です。
⭕ 回避策:初回は全取引先・全継続発注の洗い替えを回す。実装1の一次判定は全量に対して実行し、以後の新規分を差分チェックにする。

❌ 失敗4:手形をやめて振込にしたが、手数料を相手負担にした
支払手段の切替だけ見て、振込手数料を代金から差し引く設定を残すパターン。切替対応が新しい違反類型を生みます。
⭕ 回避策:支払方法の移行バッチに「手数料負担区分」の検査を同梱し、受注者負担のレコードをゼロにしてから切替完了とする。

想定モデルケースの目安

従業員400人規模の製造業(発注月300件・取引先マスタ800社)を想定した場合の、この4点検の構築目安です。

工程 内容 目安
データ棚卸し 取引先マスタへの資本金・従業員数・取引類型列の整備(名寄せ済み前提) 1〜2週間(人の調査作業が主)
実装1〜4 判定・60日・書面・支払手段の4スクリプトをClaude Codeで構築 2〜3日
初回洗い替え 全量実行→「要確認」リストの法務レビュー 2〜4週間(件数依存)
定常運用 週次バッチ+例外レビュー30分/週 継続

スクリプト構築そのものより、入力データ(資本金・従業員数・受領日)の整備に時間がかかるのがこの領域の特徴です。逆に言えば、コーディング部分はClaude Codeで数日に圧縮できるので、人の時間は全部データ整備とレビューに寄せるのが正しい配分です。

よくある質問

Q. 下請法の改正はいつから施行されていますか?

2026年1月1日に施行済みです。改正法は2025年5月16日に成立、同月23日に公布されました。法律名が変わったため、現在は「下請法」ではなく「取適法(中小受託取引適正化法)」が公式の通称です。

Q. 従業員数は何人から対象になりますか?

製造委託・修理委託・特定運送委託・プログラム作成委託・運送/倉庫保管/情報処理の役務委託では300人、それ以外の情報成果物作成委託・役務提供委託では100人が基準です。資本金基準と組み合わせて判定されるため、境界のケースは公正取引委員会の特設サイトの判定資料で確認してください。

Q. 「60日ルール」の60日と2ヶ月は違うのですか?

違います。60日は暦日カウントで、受領日から起算します。「翌々月払い」を暦月で数えると、31日の月を挟んだ場合などに60日を超えることがあります。月末締め翌々月払いの支払サイトは受領日によって超過が発生しやすい構造なので、受領日起点の全件演算で確認するのが確実です。

Q. 手形での支払いはいつから禁止ですか?

取適法の施行日である2026年1月1日から、支払手段として手形を用いることが禁止されています。電子記録債権やファクタリング等も、支払期日までに代金相当額の満額を得ることが困難なものは禁止対象です。

Q. フリーランス新法と取適法はどう違いますか?

従業員を使用しないフリーランスへの業務委託は、発注側の資本金にかかわらずフリーランス法(特定受託事業者に係る取引の適正化等に関する法律・2024年11月施行)の対象になります。取適法は資本金・従業員数基準で決まる事業者間取引が対象です。委託先に個人事業主が含まれる会社は、取引先マスタに「法人/個人」「従業員の有無」の列を持ち、両方の法律で判定する必要があります。

Q. 資本金1,000万円以下の会社が発注する場合も対象になりますか?

資本金基準では、資本金1,000万円以下の委託事業者は対象になりません。ただし改正で従業員基準が追加されたため、資本金が1,000万円以下でも従業員数が300人(または100人)を超える場合は対象になり得ます。「減資で対象外」という旧来の整理は、従業員数で再判定が必要です。

まとめ:今日から始める3つのアクション

  1. 今日やること:取引先マスタに資本金・従業員数・取引類型の列があるか確認する。なければ整備計画を立てる。これが全点検の入力データです
  2. 今週中:実装2の60日チェックを最初のClaude Codeタスクとして動かす。受領日と支払期日の2列があれば動き、超過予備軍が具体的な件数で見えます
  3. 今月中:実装1の適用一次判定を全量で回し、「要確認」リストを法務と分担して潰す体制を作る。週次バッチとCLAUDE.mdの停止線を整備してから定常運用に入る

取適法対応は、インボイス登録番号の一括確認や電帳法対応と同じく「法令の要件をデータの検査条件に翻訳し、例外だけ人が見る」型の仕事です。施行から半年のいま動けば、初回の洗い替えで見つかる問題はまだ「是正」で済みます。点検の仕組みがないまま指導・勧告の局面で発見されるのが、いちばん高くつくパターンです。


著者:佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』(SBクリエイティブ)。

参考・出典

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

関連記事: 年5日の有給取得義務の未達をClaude Codeで先読みする実装

Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、AI開発ツール導入の失敗を減らせます。

導入を相談する

チームで学ぶなら: Claude Code 法人研修(2日間ハンズオン) / 1人で習得するなら: 個別指導(週1マンツーマン)