仕入先からの値上げ依頼を購買実績と物価指数に照らして、協議用の検討表にまとめる

処理の起点を決める

価格改定依頼の専用アドレスにメールが届いたときを起点にします。Power Automate の Outlook コネクタのメール受信トリガーを使います。

依頼が担当者個人のアドレスに届く運用のままだと、処理の起点が作れません。仕入先に対して、価格改定の依頼は専用アドレス宛てに送ってもらうよう案内することが最初の準備です。個人宛てに届いたものは、担当者が転送します。

入力データを集める

5番目の対応表は、人が作って管理します。 「この仕入先の言う原材料費は、どの指数と比べるのが妥当か」は、品目を知っている購買担当でなければ決められません。AIに指数を選ばせないでください。

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

依頼文書： 文字情報を持つPDFは、生成AIに直接読ませて項目を取り出します。郵送で届きスキャンした画像のPDFは、文字の読み取りを別に通すか、最初は人が入力する運用にします。

購買実績と改定履歴： ERPから日次で書き出したデータを参照します。影響額は「直近12か月の購買数量 × 単価の差」で計算します。季節で数量が大きく変わる品目は、24か月の平均も併記します。

物価指数： 日本銀行の時系列統計データ検索サイトが、2026年2月からAPI機能を提供しています。企業物価指数は、国内企業物価指数・輸出物価指数・輸入物価指数などから構成され、月次で公表されます。このAPIは次の仕様です。

• 系列コードを指定して時系列データを取る「コードAPI」、階層情報を取る「階層API」、系列の属性情報を取る「メタデータAPI」の3種類がある
• 出力はJSONまたはCSV。企業物価指数のDB名は PR01
• 1回のリクエストで検索できるのは250系列、データ数（系列数 × 期数）で60,000件まで。上限を超えた場合は、出力の「次回検索開始位置（NEXTPOSITION）」を次のリクエストに指定して続きを取る
• 1回に指定する系列は、すべて同じ期種（月次など）でなければならない
• 高頻度のアクセスは避けるよう求められており、接続が遮断される可能性がある
• データの更新は原則として8時50分頃

この業務では、指数を毎回取りに行く必要はありません。 対応表にある系列だけを、公表後に月1回取得して自社に保存し、そこから参照します。依頼が届くたびにAPIを叩く構成にすると、繁忙期に高頻度のアクセスになります。

AIへ渡す前に整形する

1. 単位の統一 … 依頼書の単価が「円/kg」、自社の単価マスタが「円/個」ということがあります。品目マスタの換算係数で揃えます。換算係数がない品目は計算せず、人に回します
2. 品番の対応付け … 依頼書の品名と品目マスタの「仕入先の品名」を照合します。完全一致しないものは候補を最大3件並べ、確定は人が行います
3. 改定率と改定後単価の整合 … 依頼書に両方が書かれている場合、計算が合っているかを確かめます。合わない場合はその事実を確認事項に入れます
4. 指数の期間合わせ … 依頼書が「前回改定時から」「2025年4月から」のように期間を示している場合、その期間の指数の変化率を計算します。期間が書かれていない場合は、前回の改定日から直近までで計算し、期間を自社で置いたことを明記します
5. 前回改定からの経過 … 改定履歴から、前回の改定日と改定率を取り出します

AIに処理させる

2回に分けて呼び出します。

1回目：依頼文書からの取り出し。

2回目：検討表の所見と確認事項。 プログラムが計算した影響額、指数の変化率、前回改定からの経過を渡し、次を作らせます。

指示内容を固定する

あなたは購買部で価格改定の依頼を整理する担当者です。
仕入先からの依頼内容と、社内で計算した数字を渡します。
協議に向けた検討表の所見と、仕入先に確認すべき点を作ってください。

【厳守事項】
- 数字は、下に渡した計算結果だけを使ってください。
  自分で計算し直したり、概算したりしないでください。
- 「受け入れるべき」「断るべき」「妥当でない」といった結論を書かないでください。
  事実と、協議で確認すべき点だけを書いてください。
- 物価指数は品目類の平均的な価格の動きであり、
  この仕入先の原価を直接示すものではありません。
  指数と依頼書の数字が違うことを、依頼の誤りであるかのように書かないでください。
  「差があるため、原価に占める割合と期間を確認する」という形にしてください。
- 根拠資料がない理由について、仕入先の意図を推測しないでください。
- 労務費の上昇を理由とする依頼について、その理由を軽く扱う表現を使わないでください。
- 確認事項は、仕入先に失礼のない問いの形で書いてください。

【依頼内容（取り出し済み）】
{request}

【社内で計算した数字】
影響額（年間）: {annual_impact}
前回改定: {last_revision}
依頼書の期間に揃えた指数の変化率: {index_change}
（対応表で選んだ系列: {index_series}、期間: {period}、期間を自社で置いたか: {period_assumed}）

【品番の対応付けで未確定のもの】
{unmatched_items}

「受け入れるべき、断るべきといった結論を書かない」の1行が、この構成でもっとも重要です。 検討表に「妥当性が低い」とAIが書き、それが部長の判断や仕入先への回答に流れると、十分な協議をしないまま結論が決まってしまいます。後述するように、委託取引では協議に応じない一方的な代金の決定が禁じられています。

出力形式を固定する

{
  "request_id": "",
  "supplier": "",
  "received_at": "",
  "reply_due": "",
  "effective_date_requested": "",
  "items": [
    {
      "supplier_item_name": "",
      "item_code_candidates": [],
      "item_code_confirmed": null,
      "current_price": 0,
      "requested_price": 0,
      "requested_rate": 0,
      "unit": ""
    }
  ],
  "reasons": [
    {
      "category": "原材料費 | エネルギー費 | 物流費 | 労務費 | 為替 | その他",
      "original_text": "",
      "claimed_rate": null,
      "claimed_period": ""
    }
  ],
  "evidence_attached": false,
  "evidence_types": [],
  "findings": "",
  "questions_for_supplier": [],
  "documents_to_request": [],
  "summary_for_manager": ""
}

単価と改定率は数値型で返させます。依頼書に書かれていない値は null にします。0 と「書かれていない」を区別するためです。

item_code_confirmed は既定で null にし、人が確定させます。品番の対応付けを誤ったまま影響額が計算されると、検討表の数字がすべて違ってきます。

システムへ連携する

ERPの単価マスタへの反映は自動化しません。 協議の結果として合意した単価だけを、人が登録します。

管理台帳の「回答期限」と「状態」を持つことが、実務上とても効きます。集中する時期に、どの依頼の協議がまだ始まっていないかが一目で分かるためです。

人が確認する

全件、人が確認します。

理由は、価格の協議が仕入先との取引関係そのものであり、法令上のルールもかかわるためです。検討表は判断の材料であって、判断ではありません。

確認を速くするための設計が要ります。

• 品番が未確定の品目を、検討表の先頭にまとめて表示する
• 影響額の大きい品目の順に並べる
• 指数の比較では、期間を自社で置いた場合に印を付ける
• 前回の改定からの経過と改定率を、同じ行に並べる

例外に対処する

記録を残す

• 依頼文書の原本と受付日
• 取り出した項目と、品番の対応付けの確定結果
• 計算に使った購買実績の範囲、指数の系列と期間
• 生成AIが作った所見と確認事項、人が修正した後の版
• 協議の経過（いつ、誰と、何を確認したか）と合意内容

5番目の協議の経過は、法令対応の観点からも残してください。 価格の協議に応じ、必要な説明を行ったことの記録になります。