毎月の発注データから仕入先別・品目別の単価の動きを集計し、前回より上がった品目を拾って、理由の確認依頼の文を購買担当に下書きする

処理の起点を決める

時間主導型のトリガーを、毎月3日の朝7時台に1つ置きます。 月末に入った発注の単価が生産管理システムで確定し、CSVが書き出されるのを待つためです。1日や2日に動かすと、月末の発注が半分しか入っていない明細を点検することになります。

CSVがフォルダに無ければ、スクリプトは何もせずに購買課へ「前月の発注明細がまだありません」とだけ知らせ、翌朝の同じ時刻にもう一度見に行きます。 置いたファイルの名前に対象の年月を入れる決まりにし、前々月のファイルを読み違えないようにします。

処理は仕入先ごとに区切ります。 1社分のそろえ・比較・判定・下書きを1まとまりにし、どの仕入先まで終わったかをスクリプト プロパティに残します。 1回の実行が5分を過ぎたら区切り、15分後に置いた続きのトリガーで残りから再開します。

月の途中でも、対象の仕入先と期間を設定のシートに書けば手で動かせるようにします。 大きな値上げの通知が届いた直後に、その仕入先だけ見たいときがあるからです。

入力データを集める

質を決めるのは、値上げ通知の記録です。 届いた通知を受け付けた日に1行書き、通知の文面をそのまま貼る欄を設けます。 「鋼材全般」「加工品のうち材料費の比率が高いもの」のように品目を名指ししない通知が多いので、AIは文面と品目の情報を照らして、対象に入るかを判定します。口頭で聞いた値上げも、聞いた担当者が1行書きます。 書かれていない値上げは、この構成からは「説明がつかない」に見えます。

AIに渡すのは、上がった行と、その仕入先の通知の記録だけです。 単価が変わっていない行や下がった行は渡しません。他の仕入先の単価も渡しません。

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

発注明細は、決まったフォルダから対象の年月の名前のファイルを探して読みます。文字コードは生産管理システムの書き出しに合わせ、読み込んだ直後に行数と金額の合計を数えて、システムの画面の数字と照らせるようにログに残します。

「前回」は、同じ数量の区分の中で一番新しい発注にします。 量産の100個と試作の10個を比べないためです。同じ区分の発注が12か月に無いときは「前回なし」とし、合意単価とだけ比べます。

合意単価は、発注日の時点で有効だったものを引きます。 有効開始日が発注日より後の合意は、その発注には当てはめません。4月1日から有効の新単価を、3月28日の発注に当てはめると、値上げが無かったように見えます。

Gemini API の鍵はスクリプト プロパティに置き、UrlFetchApp で呼びます。 muteHttpExceptions を true にして、失敗の状態コードでも応答を受け取り、送り直すかを決めます。 下書きは GmailApp の createDraft で作り、宛先・件名・本文と、cc に購買課の共有アドレスを入れます。

AIへ渡す前に整形する

1. 行のそろえ … 同じ月に同じ仕入先×品目の発注が複数あれば、数量の区分ごとに1行にまとめ、単価が違う発注があれば別の行のまま残します
2. 単位の換算 … 「箱」「本」「m」で書かれた単価を、品目マスタの換算で基本の単位あたりにそろえます。換算の無い単位は「換算不能」として比較から外し、件数を数えます
3. 通貨の確認 … 外貨建ての行は、比較を外貨のまま行います。円に直してから比べると、為替の動きが値上げに見えます
4. 数量の区分 … 品目マスタの境目で、各行に「小ロット」「通常」「大口」を付けます
5. 前回と合意単価の引き当て … 前の節の決め方で、前回の発注単価と有効な合意単価を横に並べます
6. 上昇の計算 … 前回比の率と、合意単価との差を出します。どちらかが設定の幅（既定は前回比3％以上、または合意単価より高い）を超えた行を拾います
7. 規格の違いの印 … 品名や規格の文字列が前回と違う行に印を付けます
8. 伏せる処理 … 通知の文面に書かれた先方の担当者の氏名と電話番号を、AIに渡す前に伏せます

3番目を軽く見ないでください。 為替が動いた月に円換算で比べると、外貨建ての仕入先がすべて値上げしたように並びます。仕入先は単価を変えていないので、聞かれても答えようがありません。

6番目の幅は、設定のシートで変えられるようにします。 3％は出発点で、拾う行が多すぎる月は品目の群ごとに幅を分けます。幅を決めるのは購買課の課長で、決めた幅と変えた日を記録します。

AIに処理させる

させるのは2つです。 1つ目は、拾った行それぞれについて、上昇に説明がつくかを決めた区分から選ぶこと。2つ目は、説明のつかない行を仕入先ごとにまとめた確認依頼の下書きです。

notified_mismatch を分けているのが、この構成の分かれ目です。 通知が「5％」なのに8％上がっている、適用日の前の発注から上がっている、というものは、通知があるからと流すと見落とします。通知がある仕入先ほど、まとめて流されやすいからです。

data_issue も分けます。 前回の10倍の単価は、値上げではなく単位の入力の誤りであることがほとんどです。仕入先に聞く前に、社内の入力を確かめる行です。

いちばん起きやすい失敗は4行目です。 説明のつかない行について、AIは「エネルギー価格の上昇の影響と考えられます」のような一般論で埋めたがります。それを書いた瞬間、聞くべき行が説明のついた行に見えます。 説明の根拠は、渡した記録の中の文字列に限ります。

指示内容を固定する

1つ目の指示（判定）は次のとおりです。

あなたは製造業の購買課で、前月の発注単価を点検する立場です。
単価が上がった行それぞれについて、渡した記録の中に説明があるかを判定してください。
上がった率と差額は、すでにスクリプトが計算しています。

【区分】
- notified .......... 値上げ通知の対象に入り、率または新単価と適用日が合う
- notified_mismatch . 通知はあるが、率・適用日・対象のどれかが合わない、または対象か分からない
- lot_or_spec ....... 数量の区分または規格が前回と違い、それで説明がつきそう
- data_issue ........ 単位の書き違い・桁の誤りが疑われる（前回の数倍以上など）
- unexplained ....... 渡した記録のどれにも当たらない

【厳守事項】
- 渡した記録（値上げ通知の記録、数量の区分、規格）だけを根拠にしてください。
- 記録に無い理由（市況、為替、エネルギー価格、人件費など）を推測で書かないでください。
- 率や差額を計算し直したり、丸めたりしないでください。出力にも含めません。
- 通知の率と実際の率が合わないときは notified にしないでください。
- 通知の適用日より前の発注は notified にしないでください。
- 迷ったら unexplained ではなく notified_mismatch を選び、どこが分からないかを書いてください。
- evidence には、判定の根拠にした文字列を記録からそのまま写してください。
- 単価が妥当か、受け入れるべきかを書かないでください。
- 入力の line_id をそのまま返し、行を増やしたり減らしたりしないでください。

【上がった行（line_id、品目、規格、数量の区分、前回単価、今回単価、上昇率、発注日）】{rows}
【この仕入先の値上げ通知の記録】{notices}

2つ目の指示（確認依頼の下書き）は次のとおりです。

あなたは製造業の購買課の担当者として、仕入先に単価の変更の理由を伺うメールを下書きします。
対象は、社内の記録で変更の理由が確認できなかった品目だけです。

【書くこと】
1. 前月の発注で、次の品目の単価が前回と異なっていたこと（品目、前回単価、今回単価、発注番号）
2. 社内の記録で、変更の理由と適用日が確認できていないこと
3. 変更の理由と適用日、今後の単価を教えていただきたいこと
4. 必要であれば、打合せの場を設けたいこと

【厳守事項】
- 数字は入力の値をそのまま書いてください。計算し直したり丸めたりしないでください。
- 値上げを断る・受け入れられないといった表現を書かないでください。
- 値上げの理由を推測で書かないでください。
- 「誤請求」「間違い」と決めつけないでください。理由を伺う文面にしてください。
- 1通に入れる品目は、渡した行だけにしてください。

【仕入先名と担当者の呼び方】{supplier}
【説明のつかなかった行】{rows}
【自社の担当者の署名】{signature}

「迷ったら notified_mismatch」と書いているのは、unexplained と notified の二択にすると、通知のある仕入先の行を notified に寄せるからです。 通知の存在を、その行の説明と取り違えないようにします。

下書きの指示で「断る表現を書かない」を入れるのは、取引の法令に関わるからです。 公正取引委員会の取適法の説明には、協議に応じない一方的な代金決定の禁止が挙げられています。この構成の確認依頼は、理由を伺い、話し合う場をつくるための文面です。

出力形式を固定する

判定は次の形で受け取ります。 category は5つの区分を enum で列挙します。

{
  "supplier_code": "S0412",
  "results": [
    {
      "line_id": "2026-09-S0412-M10233-normal",
      "category": "notified_mismatch",
      "evidence": "2026年10月1日出荷分より、鋼材価格を5％改定",
      "unclear_point": "発注日が9月18日で、適用日より前",
      "needs_contact": true
    }
  ]
}

確認依頼の下書きは次の形で受け取ります。

{
  "supplier_code": "S0412",
  "subject": "",
  "body": "",
  "line_ids": ["2026-09-S0412-M10233-normal"]
}

1つ目の理由は、line_id で入力と出力を突き合わせられることです。 送った行と返った行の数が合わなければ、その仕入先のまとまりを送り直します。下書きの line_ids も、needs_contact が true の行と同じかを確かめます。 判定で説明がついた行が下書きに入っていたら、その下書きは作り直します。

2つ目は、evidence を通知の記録と照らせることです。 スクリプトは evidence の文字列が、渡した通知の文面に実際に含まれているかを確かめます。含まれていなければ、その判定を unexplained に戻し、担当者の確認に回します。

3つ目は、下書きの本文の数字を照らせることです。 本文から単価と発注番号を正規表現で取り出し、入力の値と1つでも違えば作り直します。

一覧のシートには、仕入先×品目ごとに次の列を並べます。

システムへ連携する

生産管理システムと合意の記録には書き込みません。 単価を直すのは、仕入先と話した担当者です。AIの判定で合意の記録が書き換わると、誰がいつ合意した単価かが分からなくなります。

確認依頼は下書きまでにします。 担当者が仕入先との関係を見て、まとめて聞くか、次の打合せで聞くかを決めます。

人が確認する

1. data_issue を先に見る … 社内の入力の誤りなら、発注のやり直しや検収の訂正で済みます。仕入先に聞く前に片づけます
2. notified_mismatch を見る … 通知の文面と食い違う点を読み、通知の読み違いか、仕入先への確認が要るかを決めます
3. unexplained の下書きを読む … 品目と数字を確かめ、送る相手と時期を決めます
4. notified と lot_or_spec を流し見る … 根拠の文字列だけを読み、違和感のあるものだけ開きます
5. 送る … 仕入先ごとに、下書きを直して送ります
6. 返事を記録する … 合意した単価と理由を、合意の記録と一覧のシートに書きます

4番目を省かないでください。 説明がついたとされた行の中に、通知の範囲を広く読みすぎたものが混ざります。根拠の文字列を読めば、数秒で気づけます。

目標は、720行をならして1行1分です。 開いて読むのは上がった行のうち説明のつかないものと食い違いのあるもので、残りは一覧で根拠を流し見るだけ、という想定です。

例外に対処する

5行目の新規品目は、判定の対象にしません。 比べる相手が無い単価に「上がった」も「説明がつく」もありません。新規品目は、見積の段階で合意の記録に書く運用を先に決めます。

記録を残す

• 処理した月、読み込んだCSVのファイル名と行数・金額の合計
• 仕入先×品目ごとの前回単価・合意単価・今回単価・上昇率と、そのとき使った上昇の幅
• 判定の結果（category、evidence、unclear_point）
• 作った下書きと、送ったかどうか、送った日
• 担当者が判定を変えた記録（どの行を、どの区分に変えたか）
• 仕入先の返事の要旨と、合意の記録に反映した日

担当者が判定を変えた記録が、通知の記録の書き方を直す材料になります。 notified_mismatch から notified に変えた行が多いなら、通知の記録に対象の品目の書き方が足りていません。