購買の引き合いに付ける仕様書の案を、あいまいな表現・数値の抜け・特定の仕入先を指す書き方で校正し、依頼部門に直しの案を返す

処理の起点を決める

購買依頼の添付を「校正待ち」フォルダに保存したことを起点にします。 購買管理システムから添付を書き出す方法はシステムによって違うため、最初は担当者が依頼を受けたときに手で保存する運用でも足ります。 依頼が届いてから引き合いを出すまでの間に挟まる処理なので、1日1回の定時実行にはしません。まとめて回すと、依頼部門への返送が1日遅れます。

保存のたびに1件ずつ動かし、処理が終わったら購買依頼の番号のフォルダへ指摘一覧を置き、元のファイルを「校正済み」へ移します。 移すのは成功したときだけです。「校正待ち」に残っている数が、そのまま未処理の数になります。

依頼部門から直した版が戻ってきたときも、同じフォルダに保存すれば2回目の校正が動きます。2回目は、前回の指摘一覧を一緒に渡し、前回の指摘が直ったかを先に見ます。

入力データを集める

質を決めるのは、2行目と4行目です。 ひな形の必須項目が引き合いの種類ごとに分かれていないと、加工品の仕様書に「据付工事の範囲」が無いと指摘することになります。仕入先・ブランドの辞書が無いと、型番の指定は文脈からしか拾えず、取りこぼしが出ます。

あいまいな語の辞書は、最初から完璧にしなくてかまいません。 運用の中で、担当者が採った指摘の語を足していきます。採られなかった語は、辞書から外すのではなく「文脈しだい」の印を付けて残します。

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

Word のファイルは、Python で段落と表を順に読み、見出しの番号と段落の番号を付けたテキストにします。表は行ごとに「列名：値」の形に直し、どの表の何行目かを付けます。場所の番号が無いと、依頼部門は指摘の箇所を探すところから始めることになります。

PDF で届いたものは、Python で文字を取り出せる場合だけ規則による洗い出しをかけます。 スキャンした PDF は文字が取り出せないので、規則の候補は空になり、AIの校正だけで見ます。 その場合は指摘一覧に「規則の確認なし」と表示し、担当者が気づけるようにします。

AIへ渡す前に整形する

1. 形式の確認 … Word と PDF のほかは受け付けず、担当者に PDF にして保存し直すよう返します
2. パスワードの確認 … パスワードのかかった PDF は扱えないため、依頼部門に外してもらいます
3. 大きさの確認 … 1回のリクエストは32MB、ページ数は600ページまで（コンテキストの長さが1M未満なら100ページまで）。超えるものは章で分けて渡します
4. あいまいな語の洗い出し … 辞書の語を探し、場所の番号と前後の文を候補にします
5. 単位の無い数値の洗い出し … 数字の後ろに単位も記号も無いものを候補にします。「φ50」「t6」のような寸法の書き方は、公差の記載が近くに無いかも見ます
6. 必須項目の確認 … ひな形の必須項目の見出しが本文にあるかを見ます。見出しがあって中身が空のものも候補にします
7. 仕入先・ブランドの洗い出し … 辞書の社名・ブランド名と、型番らしい英数字の並びを候補にします

6番目の「見出しがあって中身が空」を軽く見ないでください。 ひな形から書き始めると、「検査方法：」のような見出しだけが残ります。目で見ると項目が埋まっているように見え、見落としやすい型です。

AIに処理させる

させるのは、4つの観点で指摘を作り、各指摘に原文の引用・直しの案・依頼部門への質問を付けることです。

加えて、ひな形の必須項目のうち本文に無いもの、見出しだけで中身の無いものを「項目の抜け」として返させます。 これは規則でも拾えますが、「検査方法」の見出しは無くても「受入検査は〜」の段落で書かれていることがあるため、AIに中身で確かめさせます。

規則で拾った候補は、1件ずつ「指摘にする／しない」と理由を返させます。 候補を無視して黙ることを防ぐためです。しないと判断した候補も一覧に残るので、担当者はAIの判断を確かめられます。

1行目がいちばん起きやすい失敗です。 「公差を書いてください」だけでは不親切だと考え、AIは「一般的には±0.1mm 程度」と書き足します。依頼部門がそれをそのまま写すと、設計で決めた値ではない公差が仕様書に入り、加工の費用が変わります。

指示内容を固定する

あなたは製造業の購買部で、依頼部門が書いた引き合い用の仕様書を校正する立場です。
目的は、複数の仕入先が同じ前提で見積を出せる書き方になっているかを確かめることです。
要求の中身（値の大きさ、材質の選び方、設計の考え方）が正しいかは判断しないでください。

【見る観点】
1. ambiguous ...... 仕入先によって読み方が変わる語（「十分な」「適宜」「程度」など）
2. missing_value .. 単位の無い数値、公差の無い寸法、条件の無い性能値
3. no_criteria .... 受け入れの検査で合否を決める基準の無い要求
4. vendor_specific  メーカー名・型番の指定、同等の条件の無い「同等品」、
                    1社しか持たない規格の名前
5. missing_item ... 必須項目の一覧のうち、本文に無いもの・見出しだけで中身の無いもの

【厳守事項】
- 数値・公差・材質・規格の値を、直しの案に書かないでください。
  値が要る場所は【要記入】とだけ書いてください。
  「一般的には」「通常は」として値を示すことも禁止します。
- メーカー名や型番の指定を、外すべきだと書かないでください。
  指定の理由と、同等とみなす条件を依頼部門に質問する形にしてください。
- quote には、指摘の根拠にした原文をそのまま写してください。言い換えないでください。
- location には、渡された場所の番号（例: 3.2-p2、表2-行4）を書いてください。
  PDF の場合はページ番号を書いてください。
- 規則による候補は、すべてについて「指摘にする／しない」と短い理由を返してください。
  黙って飛ばさないでください。
- 見積に響かないと考えられるもの（例: 清掃は適宜行う）は severity を low にしてください。
  low でも削らずに返してください。
- 依頼部門への質問は、はい／いいえ、または値で答えられる形にしてください。
- 前回の指摘一覧が渡された場合は、まず前回の各指摘が直ったかを判定してください。
- 仕様書でない書類と判断した場合は、校正をせず document_type に種類を書いてください。

【引き合いの種類】{rfq_type}
【必須項目の一覧】{required_items}
【規則による候補】{rule_candidates}
【前回の指摘一覧】{previous_findings}
【仕様書（場所の番号付きのテキスト、または添付の PDF）】{spec_text}

「値を【要記入】とだけ書く」を明記しないと、親切に値を入れてきます。 「一般的には」の言い方まで禁じているのは、値を書くなと言うと、参考値として書くからです。禁じるのは値を示すこと全体です。

「指定を外すべきだと書かない」も同じ考え方です。 何も言わなければ、AIは競争を広げる方向に正しそうな助言をします。理由のある指定まで外す方向へ依頼部門を押すことになり、購買への不信につながります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "request_no": "",
  "document_type": "spec",
  "previous_check": [
    { "finding_id": "", "status": "fixed | not_fixed | partially_fixed", "note": "" }
  ],
  "rule_candidates": [
    { "candidate_id": "", "decision": "finding | not_finding", "reason": "" }
  ],
  "findings": [
    {
      "finding_id": "",
      "category": "ambiguous | missing_value | no_criteria | vendor_specific | missing_item",
      "severity": "high | medium | low",
      "location": "",
      "quote": "",
      "problem": "",
      "suggestion": "",
      "question_to_requester": ""
    }
  ]
}

1つ目の理由は、quote をプログラムで原文と照合できることです。 Python で書き出したテキストに quote が文字どおりあるかを確かめ、見つからない指摘には「引用不一致」の印を付けて担当者に回します。 AIが言い換えた引用や、別の段落の文を混ぜた引用を、人が見る前にはじけます。

2つ目は、rule_candidates で取りこぼしが見えることです。 規則で拾った候補の数と、decision が返ってきた数が合わなければ、AIが候補を飛ばしたということで、もう一度呼び直します。

3つ目は、category と severity で返送文を組み立てられることです。 担当者が採った指摘を category ごとにまとめ、high から並べて返送文にします。

vendor_specific を別の段落にするのは、角を立てないためです。 直してほしい点と、理由を聞きたい点を同じ並びに置くと、指定そのものを否定されたと受け取られます。

システムへ連携する

購買管理システムには書き込みません。 購買依頼の項目を読み出せない環境では、ファイル名に購買依頼の番号と引き合いの種類を付けて保存する取り決めにすれば、同じ処理が動きます。

依頼部門への送信は、この構成から行いません。 返送文は下書きとしてフォルダに置き、担当者が採否を反映して自分のメールで送ります。 依頼部門にとって、購買の担当者の名前で届く連絡であることに意味があります。

ひな形の必須項目とあいまいな語の辞書は、購買部が持つ一覧として別のファイルにします。 プロンプトに直接書かないのは、改訂のたびにプログラムを触らずに済ませるためです。

人が確認する

購買の担当者が、指摘一覧の全件を見て採否を決めます。 仕様書を頭から読み通すことはしませんが、指摘のある箇所は原文で確かめます。

1. 引用不一致 の印のある指摘を先に見る … 原文に無い文を根拠にした指摘です。多くは捨てます
2. vendor_specific を見る … 依頼部門の事情を知っていれば、質問を外します。過去に同じ指定で理由を聞いた記録があれば、それを添えます
3. high と medium を見て採否を決める … 見積に響くかで判断します
4. low は流し見る … 採るものだけ印を付けます
5. 返送文の下書きを直して送る

採らなかった指摘には、理由を一言残します。 「清掃の頻度は見積に響かない」「型番は既設の制御盤との互換のため」など。この記録がたまると、辞書の語に「文脈しだい」の印を付ける材料になり、次の月の指摘の数が落ち着きます。

仕様書を頭から読む時間は、ゼロにはしません。 新しい種類の引き合いや、30ページを超える設備の仕様書は、指摘一覧を見たうえで目次と要求の章を読みます。 AIが見落とした抜けは、指摘一覧には現れないからです。

例外に対処する

7行目の「値の混入」の検知は、必ず入れてください。 プロンプトで禁じても、ごくまれに直しの案に値が入ります。入ったまま依頼部門に届くと、購買が値を指示したことになります。 直しの案の欄に数字と単位の並びがあれば、機械的に止めます。

記録を残す

• 仕様書の版ごとのファイルと、受け取った日時、購買依頼の番号
• Python が書き出したテキストと、規則で拾った候補
• Claude API の応答の JSON の全文と、使ったプロンプトの版、必須項目と辞書の版
• 担当者の採否と、採らなかった理由
• 依頼部門に送った返送文と、直った版が戻ってきた日時
• 引き合いのあとに仕入先から届いた質問のうち、仕様書の書き方に起因するもの

4つ目の採否の記録が、この構成を育てる材料です。 どの語の指摘が採られ、どの語が採られないかが分かれば、辞書と severity の付け方を直せます。

最後の行は、校正で拾えなかったものの記録です。 仕入先からの質問のうち、仕様書の書き方が原因のものを集めると、校正の観点に何が足りないかが見えます。 4つの観点は最初の設計にすぎず、ここから足していきます。