事業部から届く「相見積は要るか・取適法の対象か・誰の承認か」の質問に、購買規程と取引先の区分と取適法の社内手引を根拠にチャットで答える

処理の起点を決める

起点は、事業部の担当者が購買の質問用のチャットに質問を送ったことです。 取引先コード、予定金額、発注の内容の区分の3つは、選択肢と数値の欄で入れさせます。質問の本文だけで聞かせると、金額が「100万くらい」「税抜で98万」のように書かれ、規則で判定できません。

発注の内容の区分は、「部品・製品の製造（自社の図面や仕様で作らせる）」「市販品の購入」「修理」「ソフトウェアの作成」「検査・保守などの役務」「運送」「分からない」から選ばせます。「分からない」を必ず置きます。 選択肢に無理に当てはめさせると、迷った担当者が市販品の購入を選び、取適法の対象を見落とします。

続けて聞く質問は、同じ会話の中で受けます。 「では金額が80万円なら」「取引先を替えたら」のような質問は、前の質問の取引先と金額を踏まえないと答えられないからです。ただし金額や取引先を変える質問は、中継プログラムが欄を入れ直させ、規則の判定をやり直します。

入力データを集める

質を決めるのは、従業員数の確認日です。 公正取引委員会は、従業員基準に当たるかは製造委託等をした時点の常時使用する従業員の数で判断するとし、前々月に賃金を支払った労働者の数を取引先が回答した場合などは、それを当月の数として扱えるとしています。 確認日が古い数で判定すると、その間に人数が境目を越えた取引先を見落とします。

委託事業者に従業員数を確かめる義務は無いとされていますが、 相手方が中小受託事業者かを判別する必要があるときは、相手方に確認することになるとされています。この構成では、確認日が一定の期間より古い取引先は、判定せずに確認の依頼を出す側に回します。

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

規程・権限表・手引・FAQは、Cloud Storage に置いて1つのデータストアに取り込みます。 文書ごとのメタデータに、文書の種類、版、施行日、状態を持たせます。

絞り込みは status: ANY("current") を基本にします。 規程を改定したら旧い版に retired を付け、絞り込みで外します。絞り込みは ANY() と AND・OR・NOT で組み立てられ、使う項目はスキーマで索引可能にする必要があるとされています。

判定の候補は、検索の文の先頭に「前提」として入れます。 answer メソッドは検索の文と前置きの指示（preamble）を受け取る作りなので、取引先の区分と規則の判定は、検索の文の中で渡します。

AIへ渡す前に整形する

1. 規則の表を作る … 相見積の金額の区分と社数、権限表の承認者、取適法の資本金と従業員数の境目を、購買部が表に書き写します
2. 金額は税抜にそろえる … 規程の金額が税抜か税込かを確かめ、チャットの欄と同じにします
3. 取引先マスタの従業員数を埋める … 取引の多い取引先から確認を依頼し、確認日と一緒に入れます
4. 規程と手引の版をそろえる … 現行版だけに status: current を付けます
5. FAQの古い回答を外す … 施行前の下請法を前提にした回答は、手引に合わせて書き直すか外します
6. 文書の分割を設定する … データストアを作るときに分割を有効にし、見出しを各断片に付けます

1番目の表と、データストアの規程は、同じ日に直します。 規程の改定で相見積の金額が変わったのに表だけ古いと、規則の判定と条文が食い違い、全件が購買部に回ります。 食い違いは安全な側に倒れますが、構成の意味がなくなります。

5番目を軽く見ないでください。 施行前のFAQには「資本金1,000万円以下の取引先は」のように、従業員基準を知らない頃の回答が残っています。 そのまま検索に入れると、資本金だけで判定した回答の根拠として返ります。

6番目は、データストアを作る前に決めます。 分割の設定はデータストアの作成後に変えられないとされています。断片の大きさは100〜500トークンで指定でき、見出しを断片に含める設定（既定は無効）を有効にすると、「購買規程の第何条の表の行」であることが断片だけで分かります。

AIに処理させる

させるのは、前提として渡した判定の候補について、それを支える条文を規程と手引から探し、事業部の担当者が次に何をすればよいかを出典付きで短く書くことです。

左の2列を中継プログラムが持ち、右の列をモデルに探させる、という分担がこの構成のすべてです。 取適法の規模の基準は、資本金の額で決まる区分と、常時使用する従業員の数（製造委託等では300人、情報成果物作成委託・役務提供委託の一部では100人）で決まる区分が組み合わさっています。この組み合わせをモデルの読解に任せると、資本金だけを見て「対象外」と答える回答が混ざります。

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

3行目が最も起きやすい失敗です。 モデルは一般的な購買の慣行を知っており、「緊急の場合は随意契約とすることも考えられます」と書き足します。 規程に随意契約の理由の条文があればそれを示し、無ければ書かせません。

指示内容を固定する

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

あなたは購買部の担当として、事業部の担当者からの発注前の質問に、
購買規程・職務権限表・取適法の社内手引の該当箇所を示して答えます。

【前提の扱い】
- 質問の先頭に「前提」として、取引先の区分と、相見積・承認者・取適法の
  判定が書かれています。この判定は購買部の規則で出したものです。
- 判定を変えないでください。判定を支える条文を探し、出典を付けて示してください。
- 判定と条文が合わないと考えたときは、判定を書き換えず、
  「判定と規程の記載が一致しません。購買部が確認します」とだけ書いてください。

【答え方】
1. 相見積：必要な社数と、根拠の条文
2. 承認者：必要な承認者と、職務権限表の該当の欄
3. 取適法：対象か対象外かと、手引の該当の節。対象なら、発注のときに
   明示する事項と支払期日について、手引の節の名前を示してください
4. 次にすること：事業部の担当者が購買システムで行うことを1〜2行で

【厳守事項】
- 規程と手引に書かれていないことを書かないでください。
  一般的な購買の慣行や例外の扱いで補わないでください。
- 金額、資本金、人数を自分で比べないでください。前提の判定をそのまま使ってください。
- 取引先の従業員数を推測しないでください。
- 発注の内容が製造委託に当たるかを質問されたら、手引の考え方の節を示し、
  「最終的な判断は購買部が行います」と書いてください。
- 旧い版の規程や、施行前の下請法を前提にした記述を使わないでください。

「判定を変えない」と「自分で比べない」を両方書くのが要です。 前者だけだと、モデルは前提を尊重しつつ「なお資本金から見ると対象外の可能性もあります」と書き足します。比べること自体を禁じ、合わないと考えたら購買部へ回る合図を書かせます。

検索の文は、中継プログラムが次のように組み立てます。 「前提：取引先の資本金2,000万円、常時使用する従業員の数45人（2026年8月確認）、発注の内容は自社図面による部品の製造、予定金額180万円（税抜）。判定：相見積2社以上、承認者は部長、取適法の対象。質問：見積は1社でもらっているが、相見積は要るか」。前提と判定を先に、質問を最後に置きます。

出力形式を固定する

answer メソッドの応答と規則の判定を、中継プログラムが次の形に整えます。

{
  "inquiry_id": "",
  "session": "",
  "vendor": { "code": "", "capital_jpy": 0, "employees": 0, "employees_checked_on": "" },
  "order": { "amount_jpy_excl_tax": 0, "category": "manufacturing | purchase | repair | software | service | transport | unknown" },
  "rule_result": {
    "quotes_required": 0,
    "approver": "",
    "toriteki": "covered | not_covered | needs_check"
  },
  "answer_matches_rule": true,
  "status": "answered | routed",
  "route_reason": "mismatch | employees_unknown | category_unknown | no_source | none",
  "refs": [ { "doc_type": "rule | toriteki_guide | faq", "doc_id": "", "section": "", "version": "" } ],
  "answer_text": ""
}

1つ目の理由は、判定を rule_result として回答の文と別に持てることです。 チャットの画面では、判定を回答の文の上に表の形で出し、回答の文が何を書いていても、判定は規則の値が表示されます。

2つ目は、refs の doc_type で根拠の種類を検査できることです。 FAQだけを出典にした回答は、購買部が過去に答えた言い回しであって、規程そのものではありません。 規程か手引の出典が無ければ回します。

3つ目は、session を記録できることです。 続けて聞いた質問のうち、どの前提で答えたかを後から追えます。

システムへ連携する

購買システムには書き込みません。 発注の申請も承認ルートの設定も、これまでどおり購買システムで行います。取引先マスタの従業員数を書き換えるのも、取引先の回答を受けた購買部です。

人が確認する

事業部へ直接返った回答は、購買部が1件ずつ見ることはしません。 規則の判定と条文の出典がそろい、判断が分かれうる条件に当たらないものだけを返しているからです。その代わり、週に1回、直接返した回答から20件を抜き出して購買部が読み直します。

1. needs_check と category_unknown を先に見る … 取適法の対象かが分かれるものは、法務部と相談して答えます
2. employees_unknown は取引先への確認を出す … 下書きを直して送り、回答を受けたら取引先マスタを直します
3. mismatch は規則の表と規程を見比べる … 多くは表の書き写しの誤りか、規程の改定の取り込み漏れです
4. 答えたらFAQに足すかを決める … 同じ質問が続くものは、FAQに足して次から直接返るようにします

週1回の読み直しで見るのは、判定ではなく回答の文です。 判定は規則の値なので、見るべきは条文の示し方と「次にすること」の書き方です。事業部の担当者が読み違えそうな書き方が見つかったら、preamble の答え方を直します。

目標は、480件をならして1件3分です。 回る割合が2割前後という想定です。

例外に対処する

4行目は、規則で判定する理由そのものです。 「100万円以上」の区分に、ちょうど100万円の発注を当てはめるのは、文章を読ませると揺れますが、表の比較なら揺れません。

最後の行で判定の表だけを返すのは、規則の判定が検索に依存しないからです。 条文が示せなくても、相見積の社数と承認者は正しく返せます。

記録を残す

• 質問の全文（取引先コード、予定金額、発注の内容の区分、本文）と日時、session
• そのとき引いた取引先マスタの値（資本金、従業員数、確認日）
• 規則の判定（rule_result）と、そのときの規則の表の版
• answer メソッドの応答の全文（回答、出典、回答しなかった理由）
• 振り分けの結果と、購買部が最終的に答えた内容

2行目と3行目を残すのは、取適法の判断の時点を説明するためです。 従業員数は製造委託等をした時点の数で判断するとされているので、どの時点のどの数で判定したかが後から分からないと、点検で見つかったときに経緯を説明できません。