取引先から届く支払条件の変更依頼（サイトの延長・手形への切替・前払の要求）を、与信管理規程と取適法の社内手引に照らして判定し、承認の可否の案と確かめる点を財務へ返す

処理の起点を決める

社内の申請に、支払条件の変更依頼が登録されたことを起点にします。 申請の画面に「支払条件の変更」の種別を設け、その種別で登録されたものだけを Logic Apps が拾います。営業担当がメールを転送するだけの経路は作りません。 依頼がどの取引先のものかを、申請の段階で取引先コードで決めておくためです。

登録のたびに1件ずつ動かします。 まとめて夜に回すと、依頼の開始時期が近いものの審査が翌日にずれます。開始時期が今月の締めに当たる依頼は、申請の画面で「急ぎ」を付けられるようにし、担当への通知を分けます。

同じ取引先から続けて依頼が来たときは、前の申請と結び付けます。 「前回お願いした件の修正です」という依頼を新しい依頼として審査すると、前回の条件を現行の条件と取り違えます。

入力データを集める

質を決めるのは、いちばん下の行です。 得意先のサイトの延長が、どの仕入先への支払と対になっているかが分からないと、立て替える期間の計算ができません。 商社の取引は商品ごとに仕入先が決まっているので、過去12か月の販売と仕入を商品で結び付けて、得意先ごとの主な仕入先の一覧を持ちます。

資本金と従業員数は、取引先マスタに両方の列が要ります。 従業員数の列が空の仕入先は、取適法の対象かどうかを決められません。空のまま「対象外」と扱わないことが、最初の決まりです。

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

依頼の文書は、PDFとメールの本文をテキストにして渡します。画像だけのPDFは、この構成の対象外にします。 文字が取れなかった依頼は、担当が要点を申請の画面に書き足してから流し直します。

規程と手引は、変更の種類ごとに渡す条文を絞ります。 サイトの延長なら延長の条項と承認の区分の条項、手形なら支払手段の条項と取適法の手引の手形の部分、というように、読み取りの結果で決まった種類に合わせて Functions が条文を選びます。 規程を丸ごと渡すと、関係の薄い条項を根拠に挙げてきます。

AIへ渡す前に整形する

1. テキスト化 … PDFとメールの本文から文字を取り出します。署名や過去のやり取りの引用は落とします
2. 取引先の確定 … 申請の取引先コードで、取引先マスタと与信の台帳を引きます
3. 変更の読み取り … AIが、変更の種類、現行と変更後の条件、理由、開始時期を読み取ります（後述）
4. 現行の条件の照合 … 依頼に書かれた現行の条件と、販売管理・購買管理の条件が合うかを比べます。合わなければ「現行の条件の食い違い」を付けます
5. 残高の計算 … 過去12か月の月ごとの取引額のうち、最も大きい月の額で、変更後の売掛の残高を計算します
6. 立て替える期間の計算 … 得意先の延長なら、対応する仕入先への支払日と、得意先からの入金日の差を日数で出します
7. 取適法の対象の候補 … 取引の種類と、資本金・従業員数の基準で、対象・対象外・不明を出します

5番目で最も大きい月を使うのは、季節で取引額が変わる取引先のためです。 平均の月で計算すると、繁忙期に限度額を超えることが見えません。 規程で別の月の取り方が決まっていれば、それに合わせます。

4番目の食い違いは、AIの誤りより、依頼の側の誤りのほうが多くあります。 取引先が古い条件を現行として書いてくる、別の拠点の条件を書いてくる、ということが起きます。食い違いがあれば、判定の前に営業担当へ確かめる点として出します。

AIに処理させる

AIの仕事は2か所です。依頼の読み取りと、規程と手引の要件ごとの判定です。

4行目がいちばん起きやすい失敗です。 依頼の理由に「売上の減少により」とあると、AIは「信用状態の悪化が懸念されます」と書き添えます。取引先の信用の評価は、与信の台帳の格付けと、担当が集めた情報で行うものです。 依頼の文面の印象を判定に混ぜると、正直に事情を書いてきた取引先ほど不利になります。

指示内容を固定する

読み取り：

あなたは財務部で、取引先から届いた支払条件の変更依頼を整理する担当です。
渡された依頼の文書だけを根拠にしてください。推測で埋めないでください。

【読み取るもの】
- change_type：sight_extension / payment_method / prepayment / sight_shortening / other
- 現行の条件：締め日、支払日、支払手段
- 変更後の条件：締め日、支払日、支払手段、手形・電子記録債権ならその期日
- 理由：依頼に書かれた理由の文をそのまま
- 開始時期と、期間の定め（「当面の間」「○月まで」など）

【厳守事項】
- 書かれていない項目は null にしてください。自社の現行の条件で補わないでください。
- 「90日」「3か月」などの期間は、書かれた表現のまま写してください。
  日数に換算しないでください。
- 1通に複数の変更が書かれていれば、changes に分けて並べてください。
- 取引先の信用状態や資金繰りについて、あなたの評価を書かないでください。

判定：

あなたは財務部で、支払条件の変更依頼を社内の規程に照らして確かめる担当です。
渡された条文、読み取りの結果、計算の結果だけを根拠にしてください。

【渡すもの】
- 条文：{clauses}（条項の番号と本文）
- 読み取りの結果：{request}
- 計算の結果：{calc}（変更後の残高、限度額との差、立て替える日数、
  仕入先への支払の受領からの日数、取適法の対象の候補）

【判定のしかた】
- 条文の要件ごとに、met / not_met / undeterminable のどれかを付けてください。
- 根拠には、条項の番号と、要件に当たる条文の文をそのまま写してください。
- 計算の結果は、渡された値をそのまま使ってください。計算し直さないでください。
- 取適法の対象の候補が「不明」のときは、手引の要件を undeterminable にしてください。
- undeterminable の要件には、誰に何を確かめればよいかを書いてください。

【厳守事項】
- 承認してよいか、断るべきかの結論を書かないでください。
- 渡されていない条文や、一般的な法律の知識で要件を足さないでください。
- 取引先の信用状態についての評価を書かないでください。

「計算し直さない」を明記しないと、AIは依頼の「90日」から自分で日数を数え直します。 締め日からの90日と、請求日からの90日は違い、AIの数え方とプログラムの計算が食い違ったとき、どちらが正しいかを担当が確かめる手間が増えます。 数字の出どころを1つにします。

「不明なら undeterminable」も、明記しないと落ちます。 従業員数が空の仕入先について、AIは「資本金から見て対象外と考えられます」と書きます。資本金の基準に当たらなくても従業員の基準で対象になりうるので、この推測は誤りになりえます。

出力形式を固定する

判定の結果は、構造化出力で次の形に固定します。 公式のページでは、すべてのフィールドを必須にし、オブジェクトに additionalProperties: false を設定するとされています。空にしたい項目は null との共用体型にします。

{
  "request_id": "PTC-2026-10-0412",
  "change_type": "payment_method",
  "requirements": [
    {
      "clause": "与信管理規程 第14条第2項",
      "requirement": "受取手形の期日は、与信の区分ごとに定める日数以内とする",
      "status": "not_met",
      "evidence": "",
      "to_confirm": null
    },
    {
      "clause": "取適法社内手引 3-2",
      "requirement": "対象取引では仕入先への手形による支払をしない",
      "status": "undeterminable",
      "evidence": "",
      "to_confirm": "仕入先の従業員数を購買の担当に確かめる"
    }
  ]
}

可否の案は、この結果と計算から Functions が規則で付けます。

1つ目の理由は、判定と結論を別の層に置けることです。 requirements はAIが埋め、可否の案はプログラムが決めます。規程の承認の区分が変わっても、直すのは規則だけです。

2つ目は、根拠を条項の番号で読めることです。 審査の担当は、条項の番号と写された条文を見て、その要件に当てはめてよいかを規程の原文と見比べられます。

3つ目は、取適法の要件を別の扱いにできることです。 法令に関わる判定は、not_met が1つでも出れば法務の確認を必須にする、という規則をプログラムの側に置けます。

システムへ連携する

販売管理・購買管理と与信の台帳には、書き込みません。 支払条件の登録を変えるのは、承認の後に担当が行います。判定から登録までを自動でつなぐと、取引先と合意する前の条件が請求や支払に流れます。

人が確認する

財務の担当は、次の順で確かめます。

1. 計算の前提を見る … どの月の取引額を使い、どの仕入先と対にしたかを確かめます。対にした仕入先が違えば、立て替える日数は意味を失います
2. not_met と undeterminable の根拠を読む … 写された条文が、規程の原文のその条項にあるかを見ます
3. 確かめる点を営業担当へ返す … 判断保留の依頼は、何を確かめれば判定できるかを添えて返します
4. 意見を書いて回す … 可否の案と違う意見にしたときは、理由を残します

取適法の手引に関わる判定は、法務の担当も見ます。 特に、得意先の延長に合わせて仕入先への支払を延ばす話が営業から出ている依頼は、受領からの日数の計算と一緒に法務へ回します。

例外に対処する

5行目を「対象外」で埋めないことが、この構成のいちばんの守りです。 従業員数が分からない仕入先を対象外と扱うと、取適法の対象取引で手形払いを受けてしまう経路が開きます。

記録を残す

• 依頼の文書と、テキスト化した結果
• 読み取りの結果、計算の結果（使った月の取引額と、対にした仕入先）
• 判定に渡した条文と、その規程・手引の版
• 判定の結果と可否の案、担当の意見、承認の結果
• 確かめる点を営業担当へ返した日時と、返ってきた答え

条文の版を残すのは、規程が改定されるためです。 承認の区分や受取手形の期日の上限が変わったとき、過去の判定がどの版の規程に照らしたものかが分からないと、見直しの範囲が決まりません。