同じ物をばらばらに買っている状態を購買明細から見つけて、集約の候補を出す

処理の起点を決める

月次の購買明細がフォルダに置かれたときが起点です。

Power Automate の SharePoint コネクタには「ファイルが作成されたとき」というトリガーがあります。基幹システムからの月次CSV出力を指定フォルダへ置く運用にすれば、置いた時点で処理が始まります。

月次で回してください。 週次にすると、単価の比較に必要な母数が集まりません。 四半期にすると、発見が遅れます。

半自動化では、次を追加します。

• 単価の開きが一定以上の品目が出たら、その月のうちに通知する
• 新しい仕入先からの購買が発生したら挙げる

2つ目が効きます。 新しい仕入先が増えるのは、既存の仕入先で買えなかったか、現場が知らなかったかのどちらかです。 どちらも確認する価値があります。

入力データを集める

「品目区分表」がこの構成の中核です。

階層は2段までにしてください。

「例示する品名」の列を必ず作ってください。 定義だけでは分類が揺れます。実際の明細から拾った品名を3〜5個並べるのが、いちばん効きます。

3段以上にしないでください。 細かくすると、分類の一致率が落ち、集計の単位としても使いにくくなります。

「過去の分類結果」を毎回渡してください。 同じ品名が毎月出ます。前月の分類を渡せば、月ごとに結果が変わることを防げます。

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

購買明細： 基幹システムから月次でCSV出力します。購買システムに直接つながずに、まずCSVで始めてください。 分析の設計が固まる前に接続を作ると、作り直しになります。

渡す列を絞ってください。 品名、数量、単位、拠点、仕入先、単価があれば分類できます。発注者の氏名、承認者、社内の勘定科目は渡さなくて済みます。

金額をそのまま渡すかは、方針を決めてください。 単価の比較には必要ですが、購買単価は取引先との関係で機微な情報です。 分類の工程では単価を渡さず、集計の工程は社内のプログラムで行うという分け方もできます。

品目区分表と過去の分類結果： 最小構成では、Claude のプロジェクトにアップロードします。プロジェクトに置いた文書は、そのプロジェクト内の会話で読ませられます。 半自動化ではプロンプトに含めて渡します。

AIへ渡す前に整形する

機械でできることは、AIに渡す前に済ませます。

1. 全角・半角の統一 … 英数字、カタカナ、記号
2. 単位の統一 … 「枚」「P」「pcs」「箱」「ケース」を正規の単位に寄せる
3. 数量の分離 … 「ニトリル手袋M100枚」から数量と単位を切り出す
4. サイズの分離 … S／M／L、寸法をタグとして切り出す
5. 型番の抽出 … 英数字の並びを型番候補として切り出す
6. メーカー名の正規化 … 表記ゆれの辞書で寄せる
7. 既存コードの除外 … 品目コードが入っている行は対象外にする
8. 重複行のまとめ … 同一の品名文字列は1件にまとめ、件数を持たせる

8番目が費用を大きく下げます。 3,000行のうち、ユニークな品名は数百件しかないことが普通です。 同じ文字列を何度もAIに渡す理由はありません。

5番目の型番が、いちばん強い手がかりです。 型番が一致すれば、品名の表記が違っても同じ物である可能性が高くなります。 ただし型番だけで断定しないでください。 型番の体系はメーカーごとに違い、別のメーカーの型番と衝突します。

AIに処理させる

AIに次のことをさせないでください。

「同一品目である と断定させない」ことが、この構成で最も重要な制約です。 医療・介護・製造の現場では、同じ名前でも規格が違えば使えません。 ニトリル手袋の厚さ、耐薬品性、粉の有無は、品名からは分かりません。 AIの出力は「同じ物として扱える候補」までです。

「安い仕入先への切り替えを推奨させない」も必ず入れてください。 単価の差には理由があります。納期、最小ロット、緊急対応、支払条件、品質保証の範囲。 単価だけを見た推奨が記録に残ると、それが独り歩きします。

指示内容を固定する

あなたは、購買明細の品名を品目区分に分類する担当者です。
自由記述の品名を、社内の品目区分に当てはめてください。

【厳守事項】
- 「同一品目である」と断定しないでください。
  同じ物として扱える候補として group_candidate にまとめ、
  まとめた根拠を grouping_basis に書いてください。
  「同一です」「同じ商品です」と書かないでください。
- 集約すべきかどうかを判断しないでください。
  「仕入先Xに集約すべきです」と書かないでください。
- 仕入先の優劣を評価しないでください。
  安い仕入先への切り替えを勧めないでください。
- 品名から仕様を推定しないでください。
  厚さ、材質の等級、耐性など、品名に書かれていない仕様を
  書かないでください。
  確認が必要な仕様は spec_to_verify に列挙してください。
- 品目区分表にない区分を作らないでください。
  当てはまらないものは category を null にし、
  unclassified に品名をそのまま入れてください。
- 過去の分類結果に同じ品名があれば、同じ区分にしてください。
  変える場合は、change_reason に理由を書いてください。
- 品名の一部の読み取り（Mがサイズか型番か）が曖昧な場合は、
  interpretation に読み取りを書き、confidence を low にしてください。

【品目区分表】
{category_table}

【過去の分類結果】
{past_classifications}

【今月の品名一覧（重複をまとめたもの）】
{item_names}

「品目区分表にない区分を作らない」を必ず入れてください。 AIに新しい区分を作らせると、毎月少しずつ区分が増え、集計の連続性が切れます。 区分の追加は、購買が判断して区分表に反映します。

「過去の分類結果と同じにする」も重要です。 これがないと、同じ品名が月によって違う区分に入り、時系列の比較ができなくなります。

出力形式を固定する

{
  "period": "",
  "classifications": [
    {
      "item_name_raw": "",
      "item_name_normalized": "",
      "occurrences": 0,
      "category_major": "",
      "category_minor": "",
      "interpretation": "",
      "confidence": "high | medium | low",
      "change_reason": ""
    }
  ],
  "group_candidates": [
    {
      "group_id": "",
      "member_item_names": [],
      "grouping_basis": "",
      "matched_model_number": "",
      "spec_to_verify": [],
      "confidence": "high | medium | low"
    }
  ],
  "unclassified": []
}

集計（プログラム）の出力：

{
  "group_id": "",
  "total_amount": 0,
  "total_quantity": 0,
  "by_site": [
    {
      "site": "",
      "supplier": "",
      "unit_price": 0,
      "quantity": 0,
      "amount": 0
    }
  ],
  "unit_price_min": 0,
  "unit_price_max": 0,
  "unit_price_spread_ratio": 0.0,
  "supplier_count": 0,
  "same_supplier_multiple_sites": false,
  "potential_amount_at_min_price": 0
}

分類（AI）と集計（プログラム）を分けます。 単価の最大・最小、開きの比率、合計金額は、機械的に計算できます。 AIに計算させる理由がありません。

spec_to_verify が、この構成でもっとも実務的な出力です。 「厚さ」「粉の有無」「耐薬品性」といった、確認しないと同じ物とみなせない項目が並びます。購買担当は、ここを拠点に問い合わせます。

same_supplier_multiple_sites を必ず持たせてください。 同じ仕入先から複数拠点が別々に発注している状態は、交渉なしで改善できる可能性があります。

potential_amount_at_min_price は「最も安い単価で全量を買った場合の金額」です。 これは理論値であって、達成可能な削減額ではありません。 画面に出す際は、「上限の目安」と明記してください。 そうしないと、この数字が予算の前提になります。

システムへ連携する

最小構成では連携はありません。明細のCSVを生成AIのプロジェクトに入れて分類させます。

半自動化では、次をつなぎます。

基幹システムの品目マスタを自動で更新しないでください。 品目マスタは会社の正式なデータです。分類の結果は別の場所に持ち、マスタへの反映は購買が判断して行います。

発注先の自動変更も行わないでください。 集約はこの構成の外の判断です。

人が確認する

集約の判断は、必ず購買部門が行います。

1番目と5番目は、必ず拠点に確認してください。 単価が高い理由が「緊急で少量を買ったから」であることは普通にあります。データだけで結論を出さないでください。

6番目では、単価以外を必ず見てください。

• 品質（規格、認証、ロットの管理）
• 納期（緊急対応の可否、在庫の保有）
• 最小ロット（集約しても小口の発注が残るか）
• 支払条件
• 既存の仕入先との取引関係

例外に対処する

記録を残す

• 月次の分類結果（品名、区分、根拠）
• 同一品目としてまとめた候補と、その根拠
• 購買担当が分類を修正した内容と、修正前後
• spec_to_verify の確認結果
• 拠点への確認内容と回答
• 集約の判断と、その理由（集約しないと決めた理由も）
• 品目区分表の変更履歴
• 集約後の単価の推移

「集約しないと決めた理由」を必ず残してください。 翌月も同じ品目が候補として挙がります。理由が残っていなければ、同じ検討を毎月繰り返します。

「購買担当が修正した内容」が、分類の精度を上げる材料です。 どの区分でよく修正されているかが分かれば、区分の定義か例示する品名を直すべきかが判断できます。

集約後の単価の推移を必ず追ってください。 集約の効果を測る唯一の方法です。「集約した」で終わらせないでください。