旧下請法の3条書面から、取適法4条明示・7条記録、メール・EDI・発注ポータル、書面請求、監査証跡までを実務目線で整理します。
旧 下請法の3条書面から、取適法4条明示・7条記録、メール・EDI・発注ポータル、書面請求、監査証跡までを実務目線で整理します。
電子化の可否だけでなく、明示事項、伝達、証跡、保存、書面請求まで一体で整理します。
3条書面を電子メールやシステムで交付する運用は、紙の注文書を単にPDFへ置き換える作業ではありません。発注内容等を相手方が確認できる状態で明示し、送信、表示、閲覧、再送、変更、書面請求、保存までを後から再現できるようにする業務設計です。
2026年1月1日以降の取適法対象取引では、発注内容等を電子メール、EDI、発注システム、ポータルなどの電磁的方法で明示できると整理されています。ただし、電子化の自由度が高まっても、法定明示事項、発注直後の明示、書面請求対応、2年間の記録保存、受託者への不当な費用転嫁防止は弱まりません。
この比較表は、電子メールやシステムで3条書面相当の明示を行う主な方式を整理したものです。方式ごとに利点と弱点が違うため、読者は自社の発注量、取引先のIT環境、監査証跡の残しやすさを見比べて、単一方式に依存しすぎていないかを確認してください。
| 方式 | 典型例 | 実務上の利点 | 主なリスク |
|---|---|---|---|
| 電子メール方式 | 注文書PDFをメール添付、または本文に明示事項を記載 | 導入しやすく、小規模・非定型取引にも使いやすい | 誤送信、添付漏れ、不達、版管理不備、受信確認不足 |
| EDI方式 | 取引データを発注EDIで送信 | 大量・反復取引に向き、処理ログを残しやすい | データ項目不足、マスタ不整合、受託者側の表示不備 |
| 発注ポータル方式 | 受託者がログインして注文情報を確認・保存 | 権限管理、履歴管理、再発行管理に向く | 通知不足、閲覧期限、アカウント停止、保存機能不足 |
| 電子契約・契約管理方式 | 発注書、個別契約、注文請書を電子契約サービスで送信 | 署名、タイムスタンプ、証跡管理に強い | 署名完了と発注時明示のタイミングがずれる |
| 購買システム方式 | 社内承認後に相手方へ発注データを通知・表示 | 内部統制、承認、支払、保存を連動しやすい | 社内承認完了と相手方への明示を混同しやすい |
重要な結論は、電子化できることと、適法で監査可能な運用であることは別だという点です。この強調表示は、発注者側が最初に置くべき設計思想を示しています。送信方法だけでなく、明示事項の中身、相手方への到達可能性、記録保存までを一体で読むことが重要です。
紙をなくすだけでは足りません。いつ、誰に、何を、どの版で、どの取引について明示したかを再現できる状態にして、4条明示と7条記録をつなぐことが運用の中心です。
旧下請法時代は、3条書面の記載事項を電磁的方法で提供するには、原則として下請事業者の事前承諾が必要と整理されていました。2026年1月1日以降は取適法へ移行し、発注内容等の明示について、承諾の有無にかかわらず電磁的方法を使える方向へ整理されています。
この時系列は、旧法時代の承諾中心の運用から、取適法下の明示・記録中心の運用へ移る順番を示しています。読者は、日付の前後で適用される考え方が変わる点と、承諾不要化後も書面請求対応や閲覧可能性の確認が残る点を読み取ってください。
紙の書面交付に代えて電子提供をする場合、承諾記録、提供方法、受信・保存可能性、費用負担が重要でした。
下請法は取適法へ移行し、旧来の3条書面・5条書類は、実務上4条明示・7条記録として整理されます。
電子メール等を選びやすくなっても、書面請求、閲覧不能、システム障害、費用転嫁、記録保存を同時に管理します。
この比較表は、旧下請法時代と取適法施行後の違いを、電子交付の入口、相手方への配慮、障害対応、証跡の観点で並べています。改正によって省ける作業と、むしろ強化すべき管理を分けて読むことが大切です。
| 論点 | 旧下請法時代の考え方 | 取適法施行後の考え方 |
|---|---|---|
| 電子交付の可否 | 可能だが、原則として事前承諾が必要 | 承諾の有無にかかわらず電磁的方法を選択可能 |
| 相手方への配慮 | 電子化の押し付けは独禁法・下請法上の問題になり得る | 書面請求対応、閲覧可能性、費用転嫁防止が重要 |
| システム障害時 | 電子提供ができなければ書面交付が必要 | 発注時明示を止めない代替手段を準備する |
| 証跡 | 承諾記録、送信記録、受信確認が重要 | 送信、表示、版管理、書面請求、7条記録との整合が重要 |
電子化以前に、取引類型、資本金・従業員基準、基本契約との関係を確認します。
3条書面を電子メールやシステムで交付する運用を検討するとき、最初の論点は電子でよいかではなく、そもそも取適法の対象取引かどうかです。取引内容と、委託事業者・中小受託事業者の資本金基準または従業員基準を確認します。
この判断の流れは、対象取引かどうかを初期判定する順番を表しています。上から順に、委託類型、仕様指定、当事者規模、発注時期、明示・記録項目を確認することで、電子化以前に対象外・対象内の取り違えを減らすことができます。
製造、修理、特定運送、情報成果物作成、役務提供等に該当するかを見ます。
契約名よりも、発注者が仕様、品質、成果物、納期を指定しているかを確認します。
資本金基準に加え、2026年以降は従業員基準の見落としに注意します。
発注時明示と取引記録保存をシステム・メール運用へ落とします。
対象外でも、優越的地位や契約上の証跡管理は残ります。
この比較表は、基本契約、共通条件、個別発注の3層を分けて整理しています。電子契約や基本契約があるだけでは個別発注の明示が足りないことがあるため、どの層が何を担うのかを読み取ってください。
| 層 | 文書・データ | 役割 | 注意点 |
|---|---|---|---|
| 基本契約層 | 取引基本契約、業務委託基本契約、購買基本契約 | 継続取引の一般条項 | 個別発注の明示事項を当然に代替できるとは限らない |
| 共通条件層 | 支払方法、検査方法、締日、共通仕様書 | 一定期間共通の事項 | 適用期間、対象取引、参照番号を明確にする |
| 個別発注層 | 注文書、発注メール、EDIデータ、発注ポータル画面 | 給付内容、数量、納期、代金など発注ごとの条件 | 発注直後に相手方へ明示する |
12項目、給付内容、代金額、未定事項を、電子メール・システム項目へ落とし込みます。
電子化しても、明示すべき中身は省略できません。委託事業者・中小受託事業者の名称、委託日、給付内容、受領期日、受領場所、検査完了期日、代金額、支払期日、支払手段、有償支給原材料、未定事項などを、取引類型に応じて管理します。
この一覧は、電子メールやシステム画面に落とし込むべき12項目を、必須・条件付きの別と運用上の注意に分けたものです。列の左側から順に、何を明示するか、常に必要か、電子運用ではどこで漏れやすいかを読み取ってください。
| No. | 明示事項 | 必須・条件付き | 電子メール・システム運用上の注意 |
|---|---|---|---|
| 1 | 委託事業者および中小受託事業者の名称 | 必須 | 会社名、屋号、取引先コードの対応関係を明確にします。 |
| 2 | 製造委託等をした日 | 必須 | 注文日、発注確定日、システム送信日を混同しないようにします。 |
| 3 | 給付の内容 | 必須 | 品目、品種、数量、規格、仕様、成果物範囲を明確にします。 |
| 4 | 受領期日・役務提供期日または期間 | 必須 | 別途協議やASAPだけでは不十分になりやすい項目です。 |
| 5 | 受領場所・役務提供場所 | 必須 | 納入先、クラウド納品先、検収環境などを特定します。 |
| 6 | 検査完了期日 | 検査をする場合 | 検収後支払とする場合は検査期間も明示します。 |
| 7 | 代金の額 | 必須 | 税込・税抜、単価、数量、算定方法、通貨を明確にします。 |
| 8 | 代金の支払期日 | 必須 | 受領日から60日以内のできる限り短い期間内か確認します。 |
| 9 | 一括決済方式に関する事項 | 該当する場合 | 金融機関名、支払可能額、期間の始期、決済日等を明示します。 |
| 10 | 電子記録債権に関する事項 | 該当する場合 | 額、期間の始期、満期日等を明示します。 |
| 11 | 有償支給原材料等に関する事項 | 該当する場合 | 品名、数量、対価、引渡期日、決済期日、決済方法を明示します。 |
| 12 | 未定事項がある場合の理由・予定期日 | 該当する場合 | 未定理由と確定予定日を明示し、確定後直ちに補充明示します。 |
給付内容は、相手方が実際に作れる程度に具体化する必要があります。この一覧は、IT・AI・データ関連の委託で特に紐付けたい仕様項目をまとめたものです。単なる案件名では足りないため、成果物、対象範囲、品質、権利処理、検査基準まで発注データと結び付けて読むことが重要です。
成果物の名称、範囲、納品形式、納品環境、対象システム、対象画面、対象APIを明示します。
給付内容開発言語、フレームワーク、セキュリティ要件、品質基準、評価方法を仕様書に紐付けます。
仕様著作権、特許を受ける権利、ノウハウ、再利用権、OSS、学習データや生成物の扱いを整理します。
権利処理検査基準、再提出、修正範囲、運用保守、障害対応、追加作業の範囲を発注単位で残します。
検収代金額は原則として具体額を示し、やむを得ず算定方法を使う場合でも、根拠が確定すれば具体額が自動的に確定する形にする必要があります。この比較表は、危険な記載と改善例を並べています。右の列ほど、後日の交渉任せではなく、計算根拠と対象範囲が明確になる点を確認してください。
| 危険な記載 | 問題点 | 改善例 |
|---|---|---|
| 別途協議 | 算定方法ではなく後日の交渉に委ねています。 | 単価○円×実績時間。上限○時間。実績時間は月末承認表による。 |
| 見積どおり | どの見積か特定できません。 | 見積No. Q-2026-001、2026年○月○日付、税込○円。 |
| 実費精算 | 実費の範囲、証憑、上限が不明です。 | 交通費は実費、上限○円、領収書添付、宿泊費は1泊○円まで。 |
| 成果に応じて支払 | 成果指標と算定式が不明です。 | 成果物A納入時○円、成果物B検査合格時○円。 |
| 月額 | 対象期間、締日、日割りが不明です。 | 2026年4月1日から4月30日まで月額○円、日割なし。 |
宛先、件名、本文、添付PDF、版管理、到達確認、保存を実務に落とし込みます。
電子メール方式は導入が容易で、非定型の業務委託にも使いやすい一方、誤送信、添付漏れ、不達、旧版添付が起こりやすい方式です。送信先、件名、本文、添付、版管理、送信証跡、到達確認、保存の設計が必要です。
この表は、電子メールで3条書面相当の明示をする場合の最低限の設計要素を整理したものです。各行の左側が管理項目、右側が実務で確認すべき対応であり、送信した事実だけでなく、相手方が確認できる形と保存先までを見ることが重要です。
| 要素 | 実務上の推奨対応 |
|---|---|
| 宛先 | 取引先が指定した発注受信用メールアドレスへ送信します。個人担当者だけでなく共有アドレスを登録します。 |
| 件名 | 発注書であること、発注番号、取引先名、案件名を明示します。 |
| 本文 | 発注の意思、添付ファイル名、発注番号、明示日、問い合わせ先を記載します。 |
| 添付 | 法定明示事項を含むPDF、または明示事項を本文・表形式で記載します。 |
| 版管理 | PDFに発注番号、版番号、発行日時を表示します。 |
| 送信証跡 | 送信ログ、添付ファイル、宛先、送信者、送信日時を保存します。 |
| 到達確認 | バウンス監視、重要案件の受領確認、既読確認などを行います。 |
| 保存 | 7条記録、会計証憑、契約管理データと紐付けて保存します。 |
文案例は、発注番号、発注日、添付ファイル、明示事項の所在、開封不能時・書面請求時の窓口を一つのメールで示す考え方を表しています。読者は、単なる送付文ではなく、後日の証跡として必要な項目が本文に含まれているかを読み取ってください。
この一覧は、メール交付で避けたい運用と理由をまとめたものです。左列のような属人的・曖昧な送信は、右列の理由により明示や保存の実効性が弱くなるため、自社のメール運用に残っていないか確認してください。
| 避けるべき運用 | 理由 |
|---|---|
| 個人メールだけに発注する | 担当者の休暇・異動・退職で未確認になりやすくなります。 |
| 口頭発注後にメール明示を後回しにする | 発注時に直ちに明示する義務と整合しにくくなります。 |
| 見積メールへの返信で進行指示だけを送る | 法定明示事項が網羅されないことが多くなります。 |
| 添付仕様書を共有リンクだけにする | リンク切れ、版差替え、アクセス権限不備が起こりやすくなります。 |
| 支払条件は従来どおりとだけ記載する | どの条件か、どの期間の共通事項かが不明確になります。 |
| バウンス確認をしない | 不達でも発注者が気づけない可能性があります。 |
| 書面請求窓口を設けない | 取適法上の書面交付請求対応が属人的になります。 |
法定項目の完全性、相手方への伝達性、証跡・保存性を機能要件として整理します。
発注システム、EDI、購買ポータルで3条書面相当の明示を行う場合は、法定項目の完全性、相手方への伝達性、証跡・保存性を同時に満たす必要があります。社内システムに登録されているだけで、相手方が確認できない状態では十分とはいえません。
この一覧は、システム方式で備えたい機能要件を分野ごとに整理しています。左列で管理領域を確認し、中央列で満たすべき要件を押さえ、右列で実装例を読むことで、法務・購買・ITが同じ前提で設計を進めやすくなります。
| 分野 | 要件 | 実装例 |
|---|---|---|
| 取引先管理 | 対象事業者の資本金・従業員数・委託類型を管理 | 取引先マスタ、年次確認、見積依頼時確認 |
| 明示項目 | 法定明示事項を必須項目化 | 入力必須、条件分岐、未定事項フラグ |
| 共通条件 | 基本契約・共通条件と個別発注を紐付け | 条件マスタ、適用期間、参照番号 |
| 送信 | 相手方を特定して発注通知 | メール通知、EDI送信、ポータル通知 |
| 表示 | 相手方画面で明示事項を明確に表示 | 発注書画面、PDF出力、項目名表示 |
| 保存 | 発注時点の内容を後から再現 | PDF、CSV、XML、注文書控え、7条記録連携 |
| 証跡 | 送信・閲覧・ダウンロード・再送を記録 | タイムスタンプ、ユーザーID、IP、ログ |
| 書面請求 | 紙交付依頼を受付・処理 | 依頼フォーム、対応期限、郵送履歴 |
| 障害対応 | システム停止時の代替明示 | メール発注、紙発注、障害時手順書 |
ポータル方式では、掲載と明示を混同しないことが重要です。この判断の流れは、発注確定後に相手方へ通知し、相手方が画面で確認し、発注時点の内容を保存できる状態にするまでの順番を示しています。
発注番号、案件名、明示日、法定項目、共通条件の参照を確定します。
登録メールアドレスへ発注通知を送り、確認期限、URL、問い合わせ先を示します。
相手方が使う端末で、項目名付きの明示事項を確認できる状態にします。
PDF保存、閲覧、ダウンロード、未閲覧リマインド、再送履歴を残します。
メール添付または紙交付で、発注時明示が止まらないようにします。
発注時点の内容とログを取引記録へ紐付けます。
EDI方式では、データ送信ができても、相手方画面で正しく表示されないことがあります。この一覧は、EDIで確認すべき観点をまとめたものです。データ項目、表示、仕様書参照、変更履歴、再送、互換性、接続テストを一体で確認してください。
| 確認項目 | 実務上の観点 |
|---|---|
| データ項目 | 法定明示事項がデータ項目として存在するか。 |
| 表示 | 受託者側システムで項目名と内容が明確に表示されるか。 |
| 仕様書紐付け | 図面、仕様書、共通条件をどのデータで参照するか。 |
| 変更履歴 | 発注変更、取消し、単価変更の履歴が残るか。 |
| 再送 | 送信失敗時の再送手順とログがあるか。 |
| 互換性 | 取引先ごとのEDI仕様差異を管理しているか。 |
| 取引先テスト | 新規接続時に表示・保存・受信確認をテストしているか。 |
事前承諾不要化後も、紙交付希望、閲覧不能、費用転嫁防止を運用に組み込みます。
取適法では電子的な明示を選びやすくなった一方で、中小受託事業者から書面交付を求められた場合の対応が重要です。事前承諾が不要になったから紙対応を廃止してよい、という理解は避ける必要があります。
この時系列は、書面請求を受けたときの受付から交付記録までの順番を示しています。順番に意味があり、受付情報、対象発注、発注時点の内容、送付方法、交付日を残すことで、遅滞ない対応を説明しやすくなります。
メール、ポータル、電話、書面などで受けた希望について、発注番号、取引先名、対象発注、請求日、請求方法を記録します。
明示済みの電子データを基に、発注時点の内容を出力し、発注番号、版番号、出力日、再発行である旨を表示します。
郵送、手渡し、合意済みの方法で交付し、交付日、送付先、送付方法、担当者、控えを保存します。
同一取引先について、紙交付希望が継続的なものか、個別案件だけかを確認します。
電子化は発注者側の効率化につながりますが、そのコストや負担を受託者へ不当に転嫁すると、取引適正化上の問題になり得ます。この一覧は、電子化プロジェクトで確認すべき負担項目をまとめたものです。各項目について、発注者側の効率化費用を相手方へ押し付けていないかを読み取ってください。
受託者に専用機器、専用ソフト、有償アカウントを一方的に購入させていないか確認します。
利用料、登録料、発注書発行料を代金から差し引いていないか確認します。
電子化を拒む取引先や紙交付を求めた取引先に、不利な単価や発注数量を設定していないか確認します。
ITに不慣れな小規模事業者へ過大な操作負担や問い合わせ不能の状態を残していないか確認します。
障害時の代替明示、変更・取消し・再発行の証跡を整理します。
現行取適法でも、発注時に直ちに明示すべき義務は維持されています。したがって、システム障害、不達、添付ファイルの開封不能を理由に明示を後回しにする運用は危険です。
この表は、障害や不達の種類ごとに、代替手段と残すべき証跡を並べています。左列で発生事象を確認し、中央列で明示を止めない方法を選び、右列で後から説明するための記録を読む構成です。
| 障害・不達 | 代替手段 | 証跡 |
|---|---|---|
| 発注ポータル停止 | 発注書PDFをメール送信 | メール送信ログ、PDF控え |
| メールサーバ障害 | 紙発注書をFAX・郵送・手渡し | 送付記録、受領記録 |
| EDI送信失敗 | 再送、またはPDFメール | EDIエラーログ、再送履歴 |
| 取引先アカウント停止 | 登録メール・紙交付で代替 | アカウント状態、代替送付履歴 |
| 添付ファイル開封不能 | 再送、形式変更、紙交付 | 問い合わせ履歴、再送内容 |
変更・取消し・再発行は、電子発注で簡単に操作できる分だけ注意が必要です。この一覧は、発注変更時に記録すべき要素をまとめています。変更前後の内容と理由、受託者への影響、再明示の有無を読み取り、システム上の取消だけで履歴が消えない設計にします。
変更前の給付内容、代金、納期、検査期日、支払期日、添付仕様書を保存します。
受託者の責めに帰すべき理由か、委託者都合か、仕様確定による補充かを区分します。
変更により受託者に追加費用や損失が生じる場合、負担の扱いを検討します。
変更後の明示事項を電子メールまたはシステムで再明示し、送信・閲覧履歴を残します。
RACI、監査証跡、KPIを使って、法務・購買・経理・IT・内部監査をつなぎます。
3条書面を電子メールやシステムで交付する運用は、法務部だけで完結しません。購買、事業部、経理、情報システム、内部監査、コンプライアンス、リーガルオペレーションが関与します。
この責任分担表は、RACIの考え方で各業務の実行責任、最終責任、相談先、共有先を整理したものです。列ごとに責任の重さが違うため、誰が入力し、誰が承認し、誰に相談し、誰へ共有するかを読み取ることが重要です。
| 業務 | 実行責任 | 最終責任 | 相談 | 共有 |
|---|---|---|---|---|
| 適用対象判断 | 購買・事業部 | 法務・購買責任者 | 外部専門家、コンプライアンス | 経理、内部監査 |
| 明示事項テンプレート | 法務・購買 | 法務責任者 | 経理、IT、事業部 | 全発注部門 |
| システム項目設計 | IT・購買システム担当 | 購買・IT責任者 | 法務、内部監査 | 取引先担当 |
| 発注実行 | 購買・事業部 | 発注部門責任者 | 法務 | 経理 |
| 書面請求対応 | 購買事務局 | 購買責任者 | 法務 | 取引先担当 |
| 7条記録保存 | 購買・経理 | 経理・購買責任者 | 法務、内部監査 | 監査関係者 |
| モニタリング | 内部監査・コンプライアンス | 経営管理責任者 | 法務、外部専門家 | 経営陣 |
監査では、発注時明示の履行だけでなく、7条記録保存、支払遅延防止、減額・返品・やり直し等の有無を説明できる資料が必要になります。この一覧は、監査時に見るべき証跡を並べています。発注データから保存記録まで、一連の取引として紐付いているかを確認してください。
| 証跡 | 内容 |
|---|---|
| 発注データ | 発注番号、発注日、取引先、委託類型、金額、納期、支払期日 |
| 明示書面・電子記録 | 発注書PDF、メール本文、EDIデータ、ポータル表示内容 |
| 送信・表示ログ | 送信日時、宛先、ユーザーID、閲覧日時、ダウンロード日時 |
| 添付仕様書 | ファイル名、版番号、承認日時、ハッシュ値、適用範囲 |
| 共通条件 | 基本契約、共通明示、適用期間、個別発注との紐付け |
| 未定事項管理 | 未定理由、確定予定日、補充明示日時、補充内容 |
| 書面請求 | 請求日、請求者、対象発注、交付日、送付方法 |
| 障害・再送 | 障害日時、影響範囲、代替送付、再送履歴 |
| 変更・取消 | 変更前後の内容、理由、相手方通知、費用負担 |
| 保存記録 | 7条記録、保存場所、保存期間、アクセス権限 |
この一覧は、リーガルオペレーションとして管理しやすいKPIを示しています。数値は現場を罰するためではなく、明示漏れや補充漏れを早期に見つけるために使う点を読み取ってください。
| KPI | 目的 |
|---|---|
| 取適法対象取引の自動判定率 | 手作業判断の漏れを減らす |
| 発注から明示送信までの平均時間 | 直ちに明示の実効性を確認する |
| 明示項目エラー率 | 法定項目漏れを把握する |
| 未定事項の期限超過件数 | 補充明示漏れを防ぐ |
| バウンス・不達件数 | メール運用の到達性を確認する |
| 書面請求対応日数 | 遅滞ない書面交付を確認する |
| システム障害時の代替明示完了率 | BCPと法務対応を確認する |
| 内部監査指摘件数 | 継続改善の指標にする |
口頭・チャット発注、単価未登録、仕様未確定、費用転嫁などを重点的に確認します。
電子化された発注運用では、システムが動いているように見えても、法定明示事項の漏れや証跡不備が起こります。特に口頭・チャット発注、単価未登録、仕様未確定、電子化費用の転嫁は、重点的に確認すべき不備パターンです。
このリスク一覧は、典型的な不備と、どこが問題になりやすいかを並べています。各項目は、発注時明示の欠落、代金・仕様の曖昧化、受託者への不利益という観点で読むと、自社の弱い運用箇所を見つけやすくなります。
作業開始の指示が実質的な発注と評価される可能性があります。緊急時でも発注書メールまたはシステム発注へ接続します。
マスタ未登録や承認待ちは、決定済み単価を明示しない理由にはなりません。未定の場合は理由と予定期日を残します。
未定事項以外を明示し、未定の理由と確定予定期日を示し、確定後に補充明示する設計が必要です。
ポータル利用料、登録料、接続費、通信費を一方的に負担させる運用は取引適正化上の問題になり得ます。
現状調査、標準テンプレート、システム改修、社内教育、モニタリングの順に進めます。
電子交付運用は、一度にすべてを作り込むよりも、現状調査、テンプレート整備、システム改修、社内教育、モニタリングの順に進めると定着しやすくなります。
この時系列は、実装ロードマップを5段階で示しています。上から下へ進む順番に意味があり、現状の発注経路を把握してから標準化し、その後にシステムと教育へ展開する流れを読み取ってください。
紙注文書、メール発注、EDI、購買システム、独自フォーム、チャット・電話・口頭、電子契約サービス、取引先指定ポータルを棚卸しします。
電子メール用、PDF発注書用、システム画面用、EDIデータ用の標準テンプレートを整備します。
対象取引フラグ、必須項目、未定事項タスク、共通条件参照、PDF自動生成、通知ログ、書面請求、7条記録連携を組み込みます。
口頭・チャット発注、見積依頼と発注の混同、未定事項放置、紙交付希望、障害時手順、変更・取消しのリスクを教育します。
明示完了率、エラー率、補充漏れ、書面請求、バウンス、不達、障害時対応、変更・取消し、内部監査指摘を月次または四半期で確認します。
法務、購買・事業部、IT、内部監査の観点から運用定着を確認します。
運用の定着には、法務、購買・事業部、IT・システム、内部監査が、それぞれ自分の観点で確認できるチェック項目を持つことが有効です。
この一覧は、部門別に見るべきチェック項目をまとめたものです。各区分の見出しは担当部門、本文は実務で確認すべき内容を示しており、法務だけでなく現場とITが同じ運用を点検できる点を読み取ってください。
対象取引判定、旧3条書面と4条明示の用語整理、新旧法の区分、電子メール・EDI・ポータル・電子契約の適法性、未定事項、書面請求、費用転嫁を確認します。
制度口頭・チャット発注の例外管理、見積・仕様・代金・納期、発注書自動生成、指定アドレス、再送ルール、変更・取消し基準、紙交付希望の窓口連携を確認します。
実行法定明示事項の項目化、条件付き項目の表示、未定事項タスク、発注時点の固定保存、送信・閲覧・再送ログ、アカウント管理、障害時代替、改ざん防止を確認します。
証跡サンプル発注について、対象取引判定から明示、保存、送信ログ、閲覧可能画面、書面請求、補充明示、変更・取消し、7条記録との整合を追跡します。
監査よくある質問を、一般情報として制度説明と注意点に絞って整理します。
一般的には、2026年1月1日以降の取適法対象取引では、発注内容等を電子メールなどの電磁的方法で明示することが可能とされています。ただし、法定明示事項、発注後直ちの送信、送信証跡、不達対応、書面請求対応の整備状況によって評価が変わる可能性があります。
一般的には、法定明示事項がすべて明確に含まれていれば本文記載も考えられます。ただし実務上は、PDF発注書やシステム生成帳票を添付し、本文では発注番号、添付ファイル、問い合わせ先、書面請求窓口を示す方式が管理しやすいとされています。
一般的には、社内システムへ登録しただけでは十分とはいえません。相手方を特定して通知し、相手方が使用する端末の画面で明示事項を確認できる状態にする必要があります。具体的な評価は、通知、表示、保存、閲覧ログなどの設計によって変わります。
一般的には、現行取適法では電子メールなどの電磁的方法による明示について、中小受託事業者の承諾がなくても可能になったと整理されています。ただし、書面交付請求への対応、電子化費用の不当転嫁防止、閲覧不能時の代替手段は別途確認する必要があります。
一般的には、遅滞なく明示事項を記載した書面を交付する運用を整備する必要があります。例外に該当する可能性がある場合でも、記録が曖昧なときや取引先が閲覧困難を訴えているときは、資料を整理したうえで専門家へ相談する必要があります。
一般的には、一定期間共通の事項をあらかじめ明示している場合、個別発注ではその共通事項との関連性を明らかにすれば足りる場合があります。ただし、基本契約のどの条項・条件が当該発注に適用されるかを明確にする必要があります。
一般的には、正当な理由により未定事項がある場合でも、未定事項以外を明示し、未定の理由と確定予定期日を示し、確定後に補充明示する必要があるとされています。具体的な対応は、発注内容、時期、証拠関係によって変わります。
一般的には、紙発注書、メール発注書、代替ポータルなど、あらかじめ定めた方法で明示する運用が必要です。障害日時、影響範囲、代替送付、再送を記録し、発注時明示が止まらない設計にすることが重要です。
一般的には、注文請書や電子署名は有用ですが、発注時の明示義務とは別に考える必要があります。発注者が直ちに明示すべき事項を、発注時に相手方へ示しているかを確認する必要があります。
一般的には、一方的な利用料、登録料、システム接続費の負担、代金からの控除は、取適法・独占禁止法上の問題となり得ます。具体的な費用負担の扱いは、契約関係、交渉経緯、取引上の地位、実際の負担内容によって変わります。
電子化の自由度と、明示・保存・受託者保護の統制を両立させることが重要です。
3条書面を電子メールやシステムで交付する運用は、単なるペーパーレス化ではありません。旧下請法時代には事前承諾、電磁的記録の提供方法、保存可能性、費用負担、不利益取扱いが問題となり、取適法では承諾不要化により電子化の自由度が増す一方、4条明示、7条記録、書面請求対応、従業員基準、特定運送委託、手形払等禁止を踏まえた再設計が必要になりました。
この強調表示は、実務上の要諦を5点に集約したものです。用語、中身、タイミング、証跡、受託者保護を並べて確認することで、電子メールやシステムの導入が単なる形式変更で終わっていないかを読み取ってください。
用語を4条明示へ更新し、法定項目を網羅し、発注時に直ちに明示し、送信・閲覧・再送・変更の証跡を残し、書面請求・閲覧不能・障害時に受託者を保護する代替手段を用意します。
適切に設計すれば、電子化は法令遵守、業務効率、監査対応、紛争予防を同時に高めます。しかし、設計を誤れば、法定項目の一括欠落、不達、版管理不備、紙請求無視、取引先への費用転嫁が大規模に発生します。法務、購買、経理、IT、内部監査が連携し、発注時明示の統制をデジタル化する発想で運用を構築することが重要です。