取適法の記載事項と支払期日を毎月点検して、是正が要る取引を洗い出す

処理の起点を決める

毎日夜間のバッチ実行で動かします。対象は当日に発注・検収・支払のいずれかが動いた取引です。

月次でまとめて回さないのは、支払遅延を後から見つけても手遅れだからです。支払期日の3営業日前に未処理のものを検知して知らせるところまで入れて、はじめて遅延を防げます。

入力データを集める

データの取得方法を決める

ERPから： 夜間バッチでCSVまたはビューを読みます。受領日と支払期日の2つが正しく取れることを最初に確認してください。 多くのERPでは「検収日」と「受領日」が別項目で、点検に使うのは受領日です。ここを取り違えると、点検がすべてずれます。

取引先マスタ： 資本金と従業員数を持ちます。2026年1月の改正で、従来の資本金の基準に加えて従業員数の基準が入り、規制と保護の対象が広がりました。マスタに従業員数が入っていない会社が多いので、ここの整備が先になります。

やり取り： 発注番号で紐づくメールだけを取ります。全メールを対象にすると量が多すぎ、関係のない文面まで判定にかかります。

AIへ渡す前に整形する

1. 対象取引の絞り込み … 取適法の対象になる委託取引だけを抜きます。市販品の売買は対象外です。ここを広げすぎると、疑いの件数が膨らんで見きれなくなります
2. 委託先の区分 … 資本金と従業員数から、中小受託事業者に当たるかを判定します。当たらない取引先は対象外にします
3. 受領日の確定 … 分納がある場合は、各回の受領日で判定します。最終納品日で一本化しないでください
4. 文面の切り出し … メールの引用部分と署名を落とします。落とさないと、過去のやり取りの文面を新しい発注の判定に使ってしまいます

AIに処理させる

規則で測れるものと、文面を読まないと分からないものを分けます。

規則（Python）で測ること： 記載事項の欠け、支払期日が受領日から60日以内か、実際の支払日が期日内か、支払手段が手形かどうか、遅延利息の額。ここは生成AIにさせません。 日数の計算を生成AIにさせると、月をまたぐ計算を間違えます。また、なぜその判定になったかを後から説明できなくなります。

生成AIにさせること：

指示内容を固定する

あなたは委託取引のコンプライアンス点検を支援する担当者です。
発注後のやり取りを読み、取適法の禁止行為に当たる疑いがあるかを判定してください。

【厳守事項】
- 「違反である」と断定しないでください。
  判定は「疑いあり」「疑いなし」「判断できない」の3つだけです。
  違反かどうかは法務担当が判断します。
- 疑いありとするときは、根拠になった文面をそのまま引用してください。
  引用のない疑いは出さないでください。
- 金額と日付について、渡されたデータにないものを書かないでください。
- 委託先が了解していると書かれていても、それを理由に「疑いなし」にしないでください。
  了解の有無は判定の材料になりません。
- やり取りが3通以下で判断がつかない場合は「判断できない」にしてください。

【発注の情報】
{order_info}

【規則による点検の結果】
{rule_check_result}

【発注後のやり取り】
{email_thread}

「了解していると書かれていても疑いなしにしない」の1行が重要です。 取適法の禁止行為は、中小受託事業者の了解を得ていても、委託事業者に違法性の意識がなくても、規定に触れれば違反になります。生成AIは「先方も納得している」という文面を見ると、問題なしと判定しがちです。

出力形式を固定する

Claude API の structured outputs でJSONスキーマを指定します。判定の区分は enum で3値に固定します。

{
  "order_no": "",
  "supplier_name": "",
  "is_covered": true,
  "rule_findings": [
    {
      "item": "記載事項の欠け | 支払期日60日超 | 支払遅延 | 手形払い",
      "detail": "",
      "severity": "high | medium | low"
    }
  ],
  "delay_days": 0,
  "delay_interest": 0,
  "conduct_findings": [
    {
      "category": "減額 | やり直し | 協議に応じない代金決定 | 購入・利用強制 | その他",
      "judgement": "疑いあり | 疑いなし | 判断できない",
      "quote": "",
      "reason": ""
    }
  ],
  "summary": "",
  "needs_review": []
}

遅延利息は文字列でなく数値で返させます。計算そのものはPython側で行い、生成AIには結果だけ渡します。

システムへ連携する

点検結果の出力先は3通りあります。

支払の停止や自動での是正はしません。 点検の結果で支払を止めると、それ自体が支払遅延になります。是正は人が判断して行う運用にしてください。

人が確認する

疑いが挙がった取引は、全件、人が判断します。

理由は、取適法の違反に当たるかどうかが、取引の実態と経緯を含めた判断になるためです。文面だけでは決まりません。委託先に責任がある返品と、そうでない返品は、同じ文面に見えます。

確認を速くするための設計が重要です。

• 確認画面で、規則の点検結果と、やり取りの引用を左右に並べて表示する
• severity: high（支払遅延、支払期日60日超）を先頭に並べる
• 「判断できない」の件数を別枠で出す。ここが多いなら、データの取り方に問題があります
• 同じ委託先で繰り返し挙がっているものをまとめて表示する

月800件のうち、疑いが挙がるのは月20〜40件の想定です。760件を静かに通せる作りにしないと、点検が回りません。

例外に対処する

記録を残す

この業務では、点検したこと自体の記録が重要です。

• 点検の実行日時と対象件数
• 規則による点検の結果（全件、疑いなしを含む）
• 生成AIの判定と、根拠にした引用
• 法務の判断と、その理由
• 是正の内容と完了日
• 人が判定を覆した件と、覆した理由

委託事業者は取引の記録を書類として作成し、一定期間保存する義務を負います。保存の対象と年限は、必ず最新の規則で確認してください。 この仕組みのログは、その義務を代替するものではありません。