営業担当から出る「この取引先にこの支払条件・取引額で受けてよいか」の質問に、与信管理規程と取引先の与信区分を根拠にチャットで答え、例外の申請が要るものを財務へ回す

処理の起点を決める

起点は、営業担当が社内のチャット画面で取引先を選び、質問を送ったことです。 画面は社内の ID でログインした営業担当と財務の担当だけが使います。取引先と条件を入れないと送信できない作りにします。

取引先は、販売管理の担当の割り当てから、自分の担当の取引先だけを選べるようにします。 質問の文に取引先の名前を書かせて推定させると、社名の似た取引先や、同じグループの別会社を取り違えます。 取引先のコードを画面の側で確定させます。

条件は、自由文ではなく項目で入れさせます。 締め日（月末・20日など）、支払サイト（日数）、支払手段（振込・手形・電子記録債権）、取引額、納品の分け方（一括／分割の回数）の5つです。項目で入れた値は、中継プログラムが基準表と照らすのにそのまま使います。 質問の文は、項目に入らない事情（「初回の取引」「既存の注文への追加」）を書く欄にします。1件の質問は1つのセッションで続け、別の取引先に移ったら新しいセッションで始めます。

入力データを集める

質を決めるのは、区分ごとの基準表です。 規程の別表はPDFの表ですが、数字の照合に使う基準表は、財務が行と列の決まった表で持ちます。 「区分B：支払サイト上限90日、手形可、電子記録債権可」のように1区分1行にし、規程の改定日と同じ日付で版を切ります。

内部の審査基準は、取り込むか取り込まないかを最初に決めます。 取り込むなら、acl_info で財務部のグループだけを読み手にします。財務の担当がこの画面で質問したときだけ、内部の基準も根拠に入ります。

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

台帳は、販売管理の読み取りの口から取ります。 中継プログラムは取引先のコードで与信区分・限度額・審査の期限・売掛金の残高・受注残を引き、書き込みの権限は持たせません。 読み取りの口が無ければ、販売管理から毎晩書き出した表を読みます。その場合は画面に「残高は前日の夜の時点」と出します。

規程と手引きは Cloud Storage に置き、メタデータとアクセス制御の情報付きでデータストアへ取り込みます。

絞り込みの式は、日付と主題で書きます。 項目を索引可能にしておけば、valid_from <= "2026-10-08" AND valid_to >= "2026-10-08" AND topic: ANY("exception", "split_delivery") のように、今日効いている版の、その事情に当たる条項を引けます。主題は、画面の質問の文から中継プログラムが決めるのではなく、営業担当が選んだ事情のチェック欄から入れます。

区分と残高の数字は、検索の問いに文として添えます。 「与信区分B。支払サイト120日は区分の上限90日を超える。今回の取引で限度額の範囲内」のように、中継プログラムが出した判定を文にして、質問の前に付けます。 モデルには計算させず、判定が出た状態で、当てはまる手続きだけを探させます。

AIへ渡す前に整形する

1. 規程を条項ごとに見出しを付ける … 「第○条（例外の承認）」の見出しを残し、条項の番号をメタデータにします
2. 別表を基準表にする … PDFの別表から、区分ごとの行の決まった表を財務が作ります
3. 手引きを主題で分ける … 新規取引、分割納品、追加注文、例外申請の章に分け、topic を付けます
4. 版を分ける … 規程の改定のたびに版を分け、valid_from・valid_to を付けます
5. 読み手を付ける … 営業向けの文書は営業部と財務部、内部の基準は財務部だけを acl_info に書きます
6. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします
7. 台帳の値を確かめる … 与信区分が空、審査の期限が過ぎている取引先は、判定に進まず財務の確認にします

5番目と6番目は、データストアを作る前に決めます。 アクセス制御も分割も、作った後には切り替えられません。 後から内部の基準を入れたくなったときに作り直しにならないよう、最初からアクセス制御を有効にしたデータストアにしておきます。

7番目を中継プログラムに入れるのは、審査の期限切れが例外の申請の漏れの入り口だからです。

AIに処理させる

させるのは、中継プログラムが出した判定と事情に当てはまる、規程の条項と手引きの手続きを探し、根拠付きで並べることです。 範囲内かどうかの判定と、例外を認めるかどうかの判断はさせません。

answer メソッドの設定は次のようにします。

4行目がいちばん起きやすい失敗です。 過去に同じような例外が認められた記載が手引きにあると、モデルは「認められる可能性が高い」と書きがちです。営業担当はそれを取引先に伝えてしまいます。 手続きと決裁者だけを示し、可否には触れさせません。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは商社の財務部で、与信管理規程について営業担当の質問に答える立場です。
質問の前に、システムが台帳と基準表から出した判定が書かれています。
判定はそのまま正しいものとして扱い、変えないでください。
あなたの仕事は、その判定と事情に当てはまる規程の条項と手続きを探すことです。

【答え方】
1. 判定ごとに、当てはまる規程の条項の番号と、その条項の要点を書いてください。
2. 例外の申請が要る場合は、申請の書式、添付するもの、決裁者、
   受注の前か後か、を手引きの記載のまま書いてください。
3. 事情（新規取引、分割納品、追加注文）が書かれている場合は、
   その事情について規程と手引きが定める扱いを書いてください。
4. 根拠にした文書の種類（規程／手引き／内部基準）と条項・章を書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  一般的な与信管理の考え方や、他社の例で補わないでください。
- 「受けてよい」「問題ありません」「認められる見込みです」と書かないでください。
- 金額や日数の計算をしないでください。判定に書かれた数字だけを使ってください。
- 取引先の信用や経営状態について、意見や推測を書かないでください。
- 事情に当てはまる記載が無い場合は「規程に記載が見つからない。財務に確認」とし、
  扱いを推し量らないでください。
- 規程と手引きの記載が食い違うときは、どちらが優先かを決めず、
  両方を並べて「財務に確認」と書いてください。

「判定を変えない」を最初に書くのは、モデルが判定を読み直そうとするからです。 判定に「上限90日を超える」とあっても、手引きに「長期の取引先は例外として扱うことがある」とあれば、モデルは判定を和らげた文を書きます。 判定はプログラムの側の事実として固定し、モデルにはその先の手続きだけを任せます。

「認められる見込み」を禁じるのは、営業担当がその一言を取引先に伝えるからです。 交渉の場では、見込みと決定の区別はすぐに消えます。

出力形式を固定する

中継プログラムが、数字の判定と answer メソッドの応答を合わせて、次の形で画面と記録に渡します。

{
  "query_id": "",
  "session_id": "",
  "sales_id": "",
  "customer_id": "K30418",
  "request": { "closing": "月末", "site_days": 120, "method": "bill | transfer | e_claim",
               "amount": 0, "split": 1, "circumstances": ["first_deal | split_delivery | add_on"] },
  "ledger": { "grade": "B", "limit": 0, "receivable": 0, "backlog": 0,
              "review_due": "", "as_of": "" },
  "checks": [ { "item": "site_days | method | limit | review_due",
                "result": "ok | over | not_allowed | expired | missing",
                "basis": "", "detail": "" } ],
  "verdict": "within | exception | review",
  "rules": [ { "doc_type": "rule | guide | internal", "article": "",
               "summary": "", "uri": "", "grounding_score": 0 } ],
  "procedure": { "form": "", "attachments": [""], "approver": "", "timing": "" },
  "not_found": false,
  "application_draft": ""
}

1つ目の理由は、checks と rules を別の層に置けることです。 checks は中継プログラムが台帳と基準表から出し、rules はAIが規程から探します。verdict は checks だけで機械的に決めます。 1つでも over か not_allowed があれば exception、expired か missing があれば review、すべて ok なら within です。規程の答えが何を書いても、判定は動きません。

2つ目は、ledger に as_of を持てることです。 台帳を前日の夜の書き出しで読んでいるときは、今日の午前に入った受注が受注残に入っていません。 画面に時点を出し、限度に近いものは財務の確認に回す目安にします。

3つ目は、application_draft で申請の手間が減ることです。 exception のとき、中継プログラムは checks と procedure から申請書の下書きを作ります。理由の欄は空のまま渡し、営業担当が書きます。 例外を求める理由は、取引先と話した本人にしか書けません。

システムへ連携する

販売管理には書き込みません。 受注の登録も、与信区分の変更も、この画面から行う経路を作りません。 範囲内と出たものも、受注の登録はこれまでどおり営業担当が販売管理で行います。

アクセス制御のための ID は、画面のログインから渡します。 アクセス制御のあるデータストアでは、利用する人に検索と回答の権限（discoveryengine.servingConfigs.search、discoveryengine.servingConfigs.answer）を含むロールを付けます。中継プログラムがサービスの権限でまとめて検索すると、全員が財務の内部の基準まで読める状態になります。 検索はログインした人の権限で行います。

人が確認する

範囲内（within）のものは、営業担当が根拠の条項と計算の内訳を確かめて進めます。 財務は個別には確かめず、記録を週に1回抜き取りで見ます。

1. 取引先と条件を確かめる … 画面の上の取引先のコードと条件が、取引先と話した内容と合っているかを見ます
2. 台帳の時点を見る … as_of が前日なら、今日入った受注が受注残に入っていないことを頭に置きます
3. 根拠の条項を開く … 事情（初回取引・分割納品）の扱いが自分の取引に当たっているかを読みます
4. 例外のものは申請書の理由を書く … 下書きの理由の欄を埋めて出します

財務の担当は、exception と review のものを確かめます。 申請の内容と根拠の条項を読み、決裁者に回します。review のうち審査の期限切れのものは、臨時の審査に回します。

目標は、240件をならして1件9分です。 範囲内のものは営業担当が確かめて5分前後、例外と確認のものは財務が確かめるので20分前後かかります。例外と確認が2割強という想定でならすと9分です。

例外に対処する

1行目と2行目が、例外の申請の漏れの入り口です。 どちらも数字の照合の前に中継プログラムが止めるので、区分の無い取引先や期限切れの区分で「範囲内」と出ることはありません。

3行目で規程の答えだけを出さないのは、判定の無い答えが判定に見えるからです。

記録を残す

• 質問の文、取引先のコード、条件、営業担当、日時、セッションの ID
• 読んだ台帳の値と時点、照らした基準表の版、checks と verdict
• 絞り込みの式と、answer メソッドの応答の全文（出典と根拠のスコアを含む）
• 例外の申請を出したか、決裁の結果
• 範囲内と出た後に、実際に受注したか（販売管理の受注番号との対応）
• 財務の抜き取りの確認の結果

5つ目は、月末の与信の監視と突き合わせるために残します。 監視で限度超過が見つかった取引先について、受注の前にこの画面で確かめたか、確かめたときの判定は何だったかを見ます。範囲内と出て超過したなら、受注残の取り込みか台帳の時点に穴があります。

2つ目で基準表の版を残すのは、規程の改定の後で当時の判定を説明するためです。