取適法の支払期日は受領日から60日以内：受発注システムで見直す要件の整理

◆監修・編集責任者　小園 将隆　2026年11月2日

B2B EC-COLUMN

自社の取引は取適法の対象か：支払サイト短縮が必要になる分岐点

検収が終わってから請求書を受け取り、締め日を経て支払う。
受発注システムをそう設定している場合、取適法の対象取引では支払遅延になるおそれがあります。
支払期日は、納品などの受領日から60日以内で、具体的な日として定める必要があります¹。
検査や請求書が遅れても、取引先が同意しても、期日は延びません¹。
令和8年1月1日以降の発注では、手形での支払も禁止されています²。
最初に、自社の取引が対象かどうかを判定します。
そのうえで、期日計算の起点日、特定日での期日の持ち方、対象と対象外の区別の3点を現行システムで確かめると、設定変更で済むか改修が要るかを切り分けられます。

取引内容と規模で決まる対象判定

取適法は、令和7年に成立・公布され、令和8年1月1日に施行された改正法です⁴。
正式な名称は「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」で、略称は中小受託取引適正化法です⁴。
これまで下請法の名前で知られてきた取引ルールを改めたものです。
法律の中では、発注する側を「委託事業者」、受ける側を「中小受託事業者」と呼びます。

支払サイトの短縮が必要かどうかは、取引の内容と、委託事業者・中小受託事業者それぞれの規模の組み合わせで決まります³。
取引の内容は2つの類型に分かれます³。
一つ目は、物品の製造委託・修理委託、特定運送委託、政令で定める情報成果物作成委託・役務提供委託です。
二つ目は、それ以外の情報成果物作成委託・役務提供委託です。
資本金や従業員数による規模の基準は、この類型と組み合わせて当てはめます。

受発注システムで扱う発注は、一種類とは限りません。
たとえば、ある会社が部品の加工を外注し、製品の配送を運送会社に任せ、販売管理画面の改修を開発会社に発注しているとします。
この場合、同じシステムから出た注文でも、取引ごとにどの類型に当たるかを見る必要があります。
判定が取引先ごとではなく取引の内容ごとに分かれ得ることは、後でシステムの設定を考えるときの前提になります。

資本金・従業員数の具体的な区分は、公正取引委員会の取適法ページにある概要資料や診断の案内で、類型ごとに確かめます。
区分の境目に近い取引先がある場合は、次に説明する従業員数の数え方を押さえてから当てはめます。

従業員数の数え方と判定時点

従業員数で判定する場合は、数え方に決まりがあります。
従業員には、パート・アルバイトも含めます¹。
数える単位は事業者ごとで、親会社や兄弟会社などグループ会社の従業員は含めません¹。
判定する時点は、製造委託などをした時点、つまり発注した時点です¹。

この決まりは、受発注システムの取引先マスタの持ち方に関わります。
取引先を登録したときに規模の区分を入力したまま更新していなければ、取引先の従業員数が変わったとき、発注時点の実態と記録がずれます。
グループで一つの受発注システムを共用している場合は、発注元の会社ごとに判定が分かれることもあります。
グループ全体の規模でまとめて判定する設定になっていないか、発注元の会社ごとに区分を持てるかを見ておくと、後の切り分けが楽になります。

判定に使った情報と判定した時期を取引先の情報と一緒に残しておくのは、法令が求める形式ではなく、実務上の工夫です。
後から対象かどうかを問われたとき、いつの時点で何を根拠に判断したかを説明しやすくなります。

対象外の場合に考えること

判定の結果、自社の取引が取適法の対象にならなければ、法的な義務として支払期日を見直したり、システムを全面改修したりする必要はありません。
ただし、公正取引委員会は、取適法の対象外の取引でも支払サイトを受領日から60日以内に短縮し、できる限り現金で支払うよう、事業者団体に要請しています²。
これは要請であり、法的な義務ではありません。

判断が難しくなるのは、対象の取引と対象外の取引が同じシステムの中に混ざっている場合です。
このときは、全取引を一律に見直すか、対象取引だけを区別して扱うかを選ぶことになります。
どちらを選ぶかで、システムに求める機能が変わります。
対象取引だけを区別するなら、取引ごとの判定結果をシステム側で持てる必要があります。

▼ 図の内容を文字で読む

• 取引内容の類型
  • 物品の製造委託・修理委託、特定運送委託、政令で定める情報成果物作成委託・役務提供委託
  • それ以外の情報成果物作成委託・役務提供委託
• 規模
  • 資本金や従業員数の区分を類型と組み合わせて当てはめる
• 従業員数の数え方
  • パート・アルバイトを含む
  • 事業者ごとに数え、グループ会社は含めない
  • 発注した時点で判定する

支払期日は「受領日から60日以内」の特定日：今の支払サイトのどこが問題になるか

起点は検収日ではなく受領日

対象になると分かったら、次は現在の支払ルールを点検します。
受発注システムでは、支払予定日を検収日や請求書の受領日から計算する設定にしていることがあります。
検収が済み、請求書が届いて初めて支払の準備ができる、という経理の流れに合わせた設定です。

取適法では、支払期日を数える起点は受領日で、原則として納品された時点を指します¹。
検収日や請求書の受領日ではありません。
つまり、納品から検収までにかかる日数も、検収から請求書が届くまでの日数も、受領日から60日以内という枠の中に含まれます。

たとえば、取引先から部品が納品され、品質検査に時間をかけてから検収する取引を考えます。
システムが検収日から60日後を支払予定日にしていると、受領日から数えた日数は、検査にかかった日数の分だけ60日を超えます。
画面の上ではルールどおりに期日が入っているように見えても、起点が違うため、制度上は支払が遅れている状態になり得ます。

特定日で定める

支払期日は、具体的な日が特定できるように定める必要があります¹。
「納品後○日以内」という定め方は、期間の幅を示すだけで日が決まらないので認められません¹。
一方、「月末納品締切・翌月○日払い」のように締め日と支払日を組み合わせる定め方は認められています¹。
定めた期日より前に支払うことは差し支えありません¹。

締め日と支払日を組み合わせる場合は、締め期間の中で最も早く受領した分に注意します。
月末締めなら、月の初めに納品された分は、月末に納品された分よりも、受領日から支払日までの日数が長くなります。
締め期間の最終日に受領した分だけを見て60日以内と判断すると、月の初めの納品分が超えていることに気づけません。
締め・支払のパターンごとに、締め期間の初日に受領した場合の日数で確かめれば、そのパターン自体を使えるかが分かります。

請求書の遅れ・合意・検査期間でも延びない

現場で迷いやすいのは、取引先や検査の事情で手続が遅れたときの扱いです。
請求書の提出が遅れた場合、中小受託事業者から依頼や合意があった場合、検査に60日を超える期間がかかる場合のいずれでも、受領後60日以内の支払期日までに支払う必要があります¹。

このルールは、請求書を受け取ってから支払データを作る運用と相性がよくありません。
経理担当者が請求書の到着を待って支払処理を始める流れでは、請求書が遅れた取引の支払はそのまま後ろへずれます。
取引先から「請求書が遅れたので次の支払日で構いません」と言われても、その合意で期日は延びません。
請求書が届いているかどうかに関係なく、受領日から決まる期日に向けて支払の準備を進められる仕組みが必要です。

例外：受領の合意・やり直し・仮受領

受領日の考え方には、いくつか例外があります¹。

• 一定の水準を満たしたことを確認した時点を受領とする合意がある場合は、その確認の時点が起算日になります。
• 納期より前に納品された場合でも、仮受領として扱えば、納期を受領日にできます。
• やり直しをさせた場合は、やり直し後に受領した日が起算日になります。

ただし、これは通常の検査や検収の日がそのまま起算日になるという意味ではありません。
検査期間が長くても期日が延びないという原則は先に見たとおりです。
確認の時点を受領とするには、そのための合意が必要です。
合意の内容や当てはまる場面は、公正取引委員会のよくある質問で条件を確かめてから、システムの扱いに反映させます。

システムの側から見ると、例外があることで、受領日という一つの項目に入る日付の意味が取引ごとに変わります。
納品日なのか、確認の日なのか、やり直し後の日なのか、仮受領での納期なのか。
どの日付を受領日として記録したかが後から分からなければ、期日の計算が正しかったかを確かめられません。

▼ 図の内容を文字で読む

• 検収日から60日後を支払予定日にする設定
  • 検査にかかった日数の分だけ、受領日から数えた日数が60日を超える
  • 請求書を待つと、支払が後ろへずれる
• 受領日から60日以内の期日にする対象取引
  • 納品から検収までの日数も60日の枠に含まれる
  • 請求書の遅れ、取引先の合意、長い検査期間があっても期日は延びない

手形・電子記録債権・振込手数料：支払手段で支払遅延になる条件

手形払いの禁止

支払サイトを受領日から60日以内に収めても、支払手段によっては支払遅延になります。
最も分かりやすいのが手形です。
令和8年1月1日以降に発注される取適法の対象取引では、手形を交付して代金を支払うことが禁止されています²。
手形を交付した場合は、支払遅延として扱われます¹。

禁止の基準が発注の時期で示されていることは、システムの切り替えに関わります。
支払方法マスタで取引先ごとに手形を初期値にしている場合、同じ取引先の中に施行前の発注と施行後の発注が混ざります。
支払処理の段階で支払方法だけを見ても、どの注文が禁止の対象かは分かりません。
発注日と支払方法を注文ごとに結び付けて確認できる状態にしておく必要があります。
施行前に発注した取引の支払の扱いは別の論点なので、該当する取引が残っている場合は公正取引委員会の資料で個別に確かめてください。

電子記録債権・一括決済の扱い

電子記録債権や一括決済方式も、満期と支払期日の関係で判断が分かれます。
満期が支払期日より後になる一括決済や電子記録債権での支払は、原則として支払遅延の禁止に当たります²。
満期が支払期日より後の電子記録債権で、取引先が期日までに代金を得るために割引を受ける必要がある場合は、発注側が割引料を負担しても支払遅延になります¹。

ここで見落としやすいのが、システムに記録される支払日の意味です。
電子記録債権を発生させた日や一括決済の手続をした日を支払日として記録していると、満期が支払期日より後でも、画面の上では期日内に支払ったように見えます。
取引先が実際に代金を受け取れるのは満期なので、受領日から数えた期日と比べるのは満期の方です。
電子記録債権や一括決済を使う取引先があるなら、満期日をデータとして持ち、支払期日と比べられるかを確認します。

振込手数料の差引

現金振込なら問題がないかというと、手数料の扱いが残ります。
一括決済や電子記録債権の手数料、振込手数料を代金から差し引くことは、取引先と合意していても問題となります¹。

受発注や会計の支払処理には、取引先ごとに振込手数料の負担区分を持ち、先方負担なら代金から手数料を引いた額で振込データを作る設定ができるものがあります。
取適法の対象取引でこの設定が残っていると、契約書で負担を合意していても、振り込む額そのものが代金に足りなくなります。
支払期日を見直すときに、対象取引の手数料負担区分が先方負担になっていないかもあわせて見直せば、日数と金額の両方をそろえられます。

▼ 図の内容を文字で読む

• 手形を交付して支払う
  • 令和8年1月1日以降の発注では禁止
  • 支払遅延として扱われる
• 満期が支払期日より後の電子記録債権・一括決済
  • 原則として支払遅延に当たる
  • 割引料を発注側が負担しても支払遅延
• 振込手数料などを代金から差し引く
  • 取引先と合意していても問題となる

受発注システムで洗い出す要件：期日計算・受領日データ・記録・例外取引

期日の持ち方と受領日の記録

ここまでの制度の条件を、受発注システムの要件に置き換えます。
制度から直接言えるのは、期日の持ち方、受領日の記録、記録の保存、支払手段の記録に関わる要件です。
どれも、法令がシステムの機能を指定しているわけではありません。
制度の条件を満たす運用をシステムで支えるために必要になる項目です。

一つ目は、支払期日を受領日から数え、具体的な日として持てることです。
締め日と支払日のパターンで期日を決める場合でも、受領日から60日以内に収まるパターンだけを使えるようにする必要があります。
期日が注文ごとに日付として保存され、後から確認できるかもあわせて見ます。
パターンの名前だけが残り、実際の期日は支払処理のときに計算される作りだと、どの日を期日としていたかを後から示しにくくなります。

二つ目は、受領日として何を記録するかです。
原則は納品の時点ですが、先に見たとおり、一定水準の確認の時点、やり直し後の受領日、仮受領での納期が受領日になる場合もあります¹。
このとき確かめたいのは、受領日の項目があるかどうかだけではありません。
入荷の記録として受領日が入力されていても、支払期日の計算に使われているのが検収日なら、データはあっても期日の起点にはなっていません。
誰がいつ受領日を入力し、その日付がどの計算に使われるのかを、画面と処理の流れに沿ってたどります。

明示事項と記録の保存

三つ目は記録の保存です。
委託事業者は、代金の額や、その額が確定した日などを、いわゆる7条記録として記録し、記録した日から2年間保存します¹。
発注時に取引先へ示した内容、いわゆる4条明示の写しを保存しているだけでは足りません¹。

受発注システムに残っている注文書のデータは、発注時点の内容です。
受領した日、確定した代金の額、支払った日など、発注の後に起きたことが同じ取引に結び付いて残っているかが分かれ目になります。
注文と納品の情報は受発注システムに、支払の結果は会計システムにある、という分かれ方なら、両者を取引ごとにつなげて取り出せるかを確認します。
保存期間の途中でデータが自動で削除されないか、取り出しにくい形でしか保管されていないかも、設定で見ておきたい点です。

四つ目は支払手段の記録です。
一括決済や電子記録債権を使う場合は、金銭と同等に扱えることを確保した事項も記録します¹。
前の節で見た満期日の管理と合わせて、どの取引をどの手段で支払い、その条件をどう確保したかを残せるかを見ます。

例外取引の洗い出し

要件を固める前に、通常の流れから外れる取引を洗い出しておくと、設定で対応できる範囲が見えてきます。
ここまでの説明から、洗い出す対象は次のとおりです。

• 一定水準の確認を受領とする合意がある取引
• 納期より前に納品され、仮受領として扱う取引
• やり直しをさせた取引
• 手形、電子記録債権、一括決済で支払っている取引先
• 振込手数料を取引先負担にしている取引先
• 取適法の対象外と判定した取引

これらは、件数が少なくても、期日の起点や支払額が通常と違う動きをする取引です。
例外が少なければ、システムでは通常の取引だけを自動で扱い、例外は担当者が個別に期日を入れる運用で対応できることがあります。
例外が多い場合や、手作業で期日を入れる担当者が複数いる場合は、システムで区別して扱える仕組みが必要だという判断に近づきます。

制度上の要求ではありませんが、編集部からの提案として、受領日から60日を迎える前の未払の取引を一覧できるようにしておく方法があります。
請求書が届いていない、検査が終わっていない、といった理由で支払処理に乗っていない取引を、期日の近い順に確認するためのものです。
月末に経理担当者が購買担当者へ未着の請求書を一件ずつ問い合わせる手間を減らし、期日に間に合わせるための確認を早めに始められます。
どの程度役立つかは取引の量や締めの運用で変わるので、まず自社の現行データで、期日の近い未払取引がどれだけ出るかを試してから採用を決めます。

設定変更で足りるか、改修・入替か：自社の現行ルールで決める切り分け

3つの確認軸

要件が見えたら、現行システムの設定変更で対応できるか、改修やシステムの入替が必要かを判断します。
製品ごとの機能は異なるため、ここで示すのは制度の条件から組み立てた編集部の判断基準です。
確認する軸は、起点日、特定日、対象の区別の3つです。

起点日では、支払期日の計算の起点を受領日に変えられる項目があるかを見ます。
起点として受領日や納品日を選べるなら、設定変更で済む可能性があります。
選択肢が検収日と請求日しかなく、受領日のデータはあっても計算に使えない作りなら、改修が必要です。

特定日では、支払期日を取引ごとの具体的な日として持てるかを見ます。
締め日と支払日のパターンを登録できても、受領日から60日を超えるパターンを選べてしまう場合があります。
その場合は、使えるパターンを絞る設定で足りるのか、超えた期日を見つける仕組みを追加する必要があるのかを判断します。
パターンを絞るだけで全取引が収まるなら設定変更です。
例外取引の期日を個別に入れる必要があり、その入力をシステムが受け付けないなら、改修の側に寄ります。

対象の区別では、取引の類型や取引先の規模によって、対象の取引と対象外の取引を分けて扱えるかを見ます。
取引先マスタに区分を持てても、同じ取引先に類型の違う発注を出している場合は、取引先ごとの区分だけでは足りないことがあります。
全取引を受領日から60日以内にそろえる方針を取れば、この軸は判断から外せます。

3つとも既存の項目と設定で満たせるなら設定変更、どれかが既存の項目で満たせないなら改修、というのが基本の整理です。
改修が複数の軸に及び、さらに記録の保存や支払手段の記録まで作り直す必要がある場合は、改修とシステムの入替を比べる段階に入ります。
入替が有利かどうかは、改修の範囲と自社の運用によって変わるので、一律には決められません。

直近データでの試算

3つの軸を机上で確かめたら、自社の直近の発注データで試算すると判断の精度が上がります。
直近数か月分の発注について、受領日と実際の支払日（電子記録債権や一括決済の場合は満期日）を取り出し、その差が60日を超える取引を抽出します。
これも編集部の提案で、決まった方法ではありません。

試算で分かるのは、超えた件数だけではありません。
超えた取引を、取引先、締め・支払のパターン、支払手段で分けて見ると、原因がどの軸にあるかが見えてきます。
特定のパターンに集中しているなら、そのパターンを見直す設定の問題として扱える可能性があります。
検査の長い取引や請求書の遅れた取引に散らばっているなら、起点日の持ち方か、請求書を待ってから支払処理を始める流れに原因があります。

受領日のデータをそもそも取り出せない、あるいは取引によって入っていない、という結果になることもあります。
その場合は、受領日を記録する入力の流れがないこと自体が、最初に手を付ける要件だと分かります。
試算の結果は超過がないことを保証するものではありませんが、どこから見直すかの順番を決める材料になります。

▼ 図の内容を文字で読む

1. 起点日を確かめる
   • 受領日や納品日を起点に選べるなら次へ
   • 検収日と請求日しか選べないなら改修
2. 特定日を確かめる
   • 使えるパターンを絞れば全取引が収まるなら次へ
   • 例外取引の期日を個別に入れられないなら改修
3. 対象の区別を確かめる
   • 取引ごとに区別できる、または全取引をそろえるなら次へ
   • 類型の違う発注が混ざり、取引先ごとの区分しかないなら改修
4. 判断する
   • 3つとも既存の項目で満たせれば設定変更
   • 改修が複数の軸に及ぶなら入替と比べる

サイト短縮と資金繰り・対象外取引・着手手順：公的要請と社内の進め方

対象外取引への要請

公正取引委員会は、取適法の対象外の取引についても、支払サイトを受領日から60日以内に短縮し、できる限り現金で支払うよう、事業者団体に要請しています²。
これは法的な義務ではありません。
対象外の取引で60日を超える支払サイトを取っていても、それだけで取適法の違反になるわけではありません。

対象外の取引をどう扱うかは、システムの設計にも影響します。
対象と対象外で別の支払ルールを維持するなら、前の節で見た対象の区別の軸が欠かせません。
判定を誤れば、対象取引に長い支払サイトが適用されるおそれも残ります。
全取引を受領日から60日以内にそろえれば、区別の仕組みは簡単にできます。
その代わり、対象外の取引先への支払も早まり、資金繰りへの影響が大きくなります。
どちらを選ぶかは、要請への対応方針と資金繰りの見通しを合わせて、社内で決めます。

金融機関への相談

支払サイトを短縮すると、代金を支払う時期が早まり、その分の資金を手元に用意する必要が出てきます。
影響の大きさは、取引の量、現在の支払サイト、支払手段の構成によって変わるので、一般的な目安では見積もれません。
前の節の試算データを使えば、どの取引の支払がどれだけ前倒しになるかを自社の数字で示せます。

公正取引委員会は金融機関に対して、支払サイトの短縮に取り組む事業者からの資金繰りの相談に丁寧に応じるよう求めています²。
手形や電子記録債権から現金振込への切り替えも含めて見直す場合は、取引のある金融機関に早めに相談し、前倒しになる支払の時期と規模を共有しておくと、資金の手当てを考えやすくなります。

着手の順番

ここまでの内容を、社内で進める順番に並べると次のようになります。
この順番は編集部の提案です。

1. 対象判定：取引の類型と規模から、自社の取引が取適法の対象かを判定する
2. 現行の支払条件の棚卸し：起点日、締め・支払のパターン、支払手段、手数料の負担区分を取引先ごとに洗い出す
3. システムの確認：起点日、特定日、対象の区別の3つの軸で設定変更か改修かを切り分け、直近データで試算する
4. 金融機関への相談：前倒しになる支払の時期と規模を示し、資金繰りを相談する

対象判定を最初に置くのは、その結果によって後の作業の範囲が変わるからです。
対象の取引がなければ、要請への対応として進め方を自社で決められます。
対象の取引があれば、支払条件の棚卸しとシステムの確認は、法令に沿った支払を続けるための作業になります。
システムの確認を棚卸しの後にするのは、どんな例外取引をどれだけ抱えているかが分からないと、設定で足りるかどうかを判断できないためです。
金融機関への相談は最後に置いていますが、短縮の影響が大きいと分かった時点で早めても構いません。

期日計算の起点や対象・対象外の区別がシステムのどこで決まっているかは、画面の設定を見るだけでは追い切れないことがあります。

現行の期日の計算方法と受領日データの流れを一緒にたどり、設定で直せる部分と改修が必要な部分の切り分けを確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
対象判定	取引内容の類型と規模で決める。従業員は発注時点・事業者単位で、パート・アルバイトを含む
支払期日	受領日から60日以内の具体的な日。「納品後○日以内」は不可
延びない事情	検査期間、請求書の遅れ、取引先との合意
支払手段	手形は不可。満期が期日より後の電子記録債権・一括決済は原則不可。手数料の差引も不可
記録	代金の額や確定した日などを、記録した日から2年間保存
切り分け	起点日・特定日・対象の区別が既存の項目で満たせれば設定変更、満たせなければ改修

例外取引や支払手段の記録まで含めると、要件の洗い出しは購買・経理・情報システムの各部門にまたがる作業になります。 洗い出した要件を現行の受発注の運用と突き合わせ、どこから手を付けるかの順番を整理できます。取引が対象かどうかの法的な判断は、公正取引委員会の窓口などで確認してください。

よくある質問

支払期日の起点を検収日にしている場合、どう直せばよいですか。

起点を受領日に変えます。
受領日は原則として納品の時点で、検査期間が長くても期日は延びません¹。
システムに受領日や納品日の項目があり、期日計算の起点として選べるなら、設定変更で対応できる可能性があります。
起点が検収日に固定されている場合は改修が必要です。
一定水準の確認を受領とする合意がある取引は、その確認の時点が起算日になるので、通常の取引と分けて扱います¹。

取適法の対象外の取引先にも60日以内を適用すべきですか。

法的な義務ではありません。
ただ、公正取引委員会は、対象外の取引でも受領日から60日以内への短縮と、できる限りの現金払いを要請しています²。
全取引をそろえると、対象を区別する仕組みは簡単になりますが、資金繰りへの影響は大きくなります。
両方を比べて、社内の方針として決めます。

電子記録債権で支払っている取引は、どの条件なら問題になりますか。

満期が支払期日より後になる場合は、原則として支払遅延に当たります²。
取引先が期日までに代金を得るために割引を受ける必要があるなら、発注側が割引料を負担しても支払遅延になります¹。
電子記録債権の手数料を代金から差し引くことも、合意の有無にかかわらず問題となります¹。
システムでは、発生記録の日ではなく満期日を支払期日と比べられるようにしておきます。

振込手数料を取引先負担にする合意があれば、差し引いてよいですか。

差し引けません。
振込手数料を代金から差し引くことは、取引先と合意していても問題となります¹。
取引先ごとの手数料負担区分が先方負担になっている場合は、対象取引について見直します。

記録の保存は、システムのデータだけで足りますか。

システムのデータで記録する場合も、求められる事項がそろっていることが前提です。
代金の額や、その額が確定した日などを記録し、記録した日から2年間保存します¹。
発注時に示した内容の写しだけでは足りないため¹、注文書のデータに加えて、受領日や支払の結果が取引ごとに結び付いて残っているかを確かめます。
保存の形式の細かな扱いは、公正取引委員会のよくある質問で確認してください。

1. 1　出典：公正取引委員会「よくある質問コーナー(取適法)」（2026年）
2. 2　出典：公正取引委員会「サプライチェーン全体での支払の適正化に関する事業者団体等への要請について」（2025年）
3. 3　出典：公正取引委員会「取適法の概要」（2026年）
4. 4　出典：公正取引委員会「取適法」（2026年）