仕入先から届く価格表を読み取って、購買の単価マスタとの差分を洗い出して更新する

処理の起点を決める

受付アドレスにメールが届いたことを起点にします。 Email by Zapier の New Inbound Email で @zapiermail のアドレスを作り、購買部の共有メールアドレスから担当者がそこへ転送します。 仕入先に受付アドレスを直接教えることはしません。価格表以外のメールが混ざり、どの仕入先からのものかも分からなくなるためです。

転送は1通に1ファイルとします。 1回の実行で1ファイルを扱うと、失敗したときにどのファイルが止まったかがすぐに分かります。

転送時に件名の先頭へ仕入先コードを付けます（例：[S-0412] 価格改定のお知らせ）。仕入先の特定は人の役目で、社名からAIに推測させません。

入力データを集める

AIに渡すのは価格表ファイル・仕入先コード・受信日の3つまでです。 品番対応表と単価マスタは差分シートの計算式だけが引きます。品番対応表の「入数」と「税の書き方」の列は、担当者の頭の中にあった仕入先ごとの癖を書き出したもので、この構成の質を決めます。

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

Zapier から OpenAI API を呼ぶ部分は、Webhooks by Zapier で組みます。 2つのステップに分けます。

①が POST なのは、ファイルの送信には POST または PUT を使うと案内されているためです。②が Custom Request なのは、入れ子の JSON 配列（JSON Schema）を送るためです。 入力は整形されずにそのまま送られるので、保存前に書式を検証します。

API へのファイルの渡し方は file_id・Base64 の埋め込み・外部 URL の3つです。file_id を選ぶのは、Webhooks の送信内容の上限が5MBで、Base64 では数MBの価格表で上限に近づくからです。 外部 URL は価格表を公開の場所に置くことになるため使いません。

添付ファイルの受け渡しと、応答から JSON を取り出す部分の細かな設定は、利用環境に応じた個別実装が必要です。 1ファイルを通して確かめてから組み上げてください。

AIへ渡す前に整形する

1. 件名の確認 … 先頭に [S-xxxx] の仕入先コードがなければ、処理せずに担当者へ戻します
2. 添付の確認 … 添付が1つでなければ、処理せずに担当者へ戻します
3. 形式の確認 … .xlsx .xls .csv .pdf 以外は処理しません。画像で届いた価格表はPDFにしてから転送します
4. サイズの確認 … メールは添付を含めて10MB未満が条件です。超えるものは受付アドレスに届きません
5. 行数の確認 … 表計算ファイルはシートごとに先頭1,000行までが読まれます。超える価格表はシートを分けてから転送します
6. 重複の確認 … 同じ仕入先コードと同じファイル名の処理記録が直近にあれば、二重に取り込まないよう印を付けます

行数の確認を省くと、1,000行を超えた部分が差分シートで「価格表に無い行」に見え、廃番と区別がつかなくなります。

AIに処理させる

させるのは、価格表の各行を決めた列に並べ、原文の書き方を残すことだけです。

右端の列がいちばん大事な決まりです。 税の扱いを「たぶん税抜」で埋めると、単価が1割違うだけの正常な行に見えます。

単位の換算がいちばん起きやすい失敗です。 「1箱1,200円（12個入）」を「1個100円」と返した瞬間、単位の情報が消えます。

指示内容を固定する

あなたは購買部門で、仕入先から届いた価格表を転記用の表に整える担当です。
添付の価格表だけを見て、各行を指定の列に並べてください。推測で埋めないでください。

【やること】
- 価格表に載っている品目を1行ずつ rows に入れてください。
  見出し行、小計行、注記だけの行は入れないでください。
- 各行について、次の値を書かれたとおりに入れてください。
  supplier_item_code（仕入先品番）、item_name（品名）、
  unit_raw（単位の原文）、pack_raw（入数の原文）、
  unit_price（単価の数値）、currency、tax_basis、
  effective_from（適用開始日）、min_order_qty（最小発注数量）
- source_ref には、シート名と行番号、またはページ番号を必ず入れてください。

【厳守事項】
- 記載がない値は null にしてください。tax_basis と currency は unknown にしてください。
  他の行や一般的な慣習から補わないでください。
- 単位を換算しないでください。「1箱1,200円（12個入）」は
  unit_raw を「箱」、pack_raw を「12個入」、unit_price を 1200 とし、
  1個あたりの単価に直さないでください。
- 税込と書かれた単価を税抜に直さないでください。
- 「別途見積」「オープン価格」「応相談」など数値でない単価は、
  unit_price を null にし、price_note に原文を写してください。
- 適用開始日が表の上部に1か所だけ書かれている場合は、
  document の effective_from に入れ、各行の effective_from は null にしてください。
- 品番の表記（ハイフン、全角半角、先頭の0）を直さず、書かれたとおりに写してください。
- 単価が前回から変わったかどうかは判断しないでください。
- 価格表でない書類（見積依頼、請求書、案内状など）と判断した場合は、
  rows を空にして document_type にその種類を書いてください。

【仕入先コード】{supplier_code}
【受信日】{received_date}

「単位を換算しない」は具体例まで書きます。 禁じるだけでは「比べやすいように」と割ります。例を1つ書くと止まります。

適用開始日を行に書き写させないのは、 行ごとに違う日付を書く価格表と区別するためです。どこに書かれていたかを、値の置き場所で残します。仕入先コードは出力に付け戻すためだけに渡します。

出力形式を固定する

Structured Outputs の strict: true で、次の JSON Schema に沿って受け取ります。 Responses API では text.format に type: "json_schema" と strict: true を指定します。

{
  "type": "object",
  "properties": {
    "document_type": { "type": "string", "enum": ["price_list", "quotation", "other"] },
    "supplier_code": { "type": "string" },
    "effective_from": { "type": ["string", "null"] },
    "tax_basis": { "type": "string", "enum": ["excluded", "included", "unknown"] },
    "currency": { "type": "string", "enum": ["JPY", "USD", "EUR", "CNY", "unknown"] },
    "rows": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "supplier_item_code": { "type": ["string", "null"] },
          "item_name": { "type": ["string", "null"] },
          "unit_raw": { "type": ["string", "null"] },
          "pack_raw": { "type": ["string", "null"] },
          "unit_price": { "type": ["number", "null"] },
          "price_note": { "type": ["string", "null"] },
          "currency": { "type": "string", "enum": ["JPY", "USD", "EUR", "CNY", "unknown"] },
          "tax_basis": { "type": "string", "enum": ["excluded", "included", "unknown"] },
          "effective_from": { "type": ["string", "null"] },
          "min_order_qty": { "type": ["number", "null"] },
          "source_ref": { "type": "string" }
        },
        "required": ["supplier_item_code", "item_name", "unit_raw", "pack_raw",
          "unit_price", "price_note", "currency", "tax_basis",
          "effective_from", "min_order_qty", "source_ref"],
        "additionalProperties": false
      }
    }
  },
  "required": ["document_type", "supplier_code", "effective_from",
    "tax_basis", "currency", "rows"],
  "additionalProperties": false
}

Structured Outputs では、全項目を required にし、additionalProperties を false にし、値が無いことを許す項目は ["string", "null"] と書きます。

1つ目の理由は、「空」と「読み落とし」を分けられることです。 キーが抜けることはなく、null は「書かれていなかった」という意味だけになります。

2つ目は、税の扱いと通貨を文書と行の両方に持てることです。 差分シートでは行の値が unknown なら文書の値を使います。

3つ目は、source_ref で確認が速くなることです。 差分シートの行から、価格表のどのシートの何行目かにすぐ戻れます。

安全上の理由でモデルが応答を断った場合は、応答に refusal という項目が入ります。この項目があれば、取込シートに書き込まずに担当者へ知らせます。

システムへ連携する

取込シートへは、line items を1行にまとめず複数の行として作るアクションで書き込みます。 価格表の1品目が取込シートの1行になります。

Looping by Zapier を使わないのは意図してのことです。 ループは最大500回、後続の各アクションは1回ごとに1タスクを使い、各回は並行して実行されます。 数百行を1行ずつ処理すると、タスクが膨らみ、途中で止まったときに追いにくくなります。

差分の計算は、スプレッドシートの計算式に置きます。

上から順に判定します。 単位や税が怪しい行を単価変更より先に拾うのは、見た目は単価の変更だからです。 マスタにあって価格表に無い行は別欄に並べ、廃番かは人が確かめます。

単価マスタへの書き込みは、この段階では人が行います。 本格構成では、Google Sheets の Lookup Spreadsheet Row で自社品番の行を探し、Update Spreadsheet Row で単価を書き換える形が考えられます（第9章）。

人が確認する

人が開くのは、差分シートの「変更なし」以外の行だけです。 「変更なし」は件数だけを見ます。全行を見る設計にすると、第10章の12.0時間には収まりません。

1. 例外の行を先に見る … 対応不明、単位要確認、税区分要確認。source_ref で価格表の該当箇所に戻り、品番対応表の側を直すのか、仕入先に問い合わせるのかを決めます
2. 単価変更の行を確かめる … 改定前と改定後の単価、変化の幅を見ます。変化の幅が極端な行は、単位の読み違いを疑います
3. 適用日待ちの行に日付を確かめる … 反映する日を決め、その日まで差分シートに残します
4. 承認の列に印を付ける … 承認した人と日時を残します
5. 承認した行を単価マスタへ反映する … 改定前の単価は履歴の列へ移します

変化の幅は必ず見てください。 10倍前後や12分の1前後に変わった行は、ほとんどが入数の読み違いです。 値上げを受け入れるかどうかは、ここでは決めません。

例外に対処する

大半を占めるのは単位の違いと税の扱いです。 どちらも一度品番対応表に書けば、同じ仕入先の次の価格表からは起きません。

記録を残す

• 元の価格表ファイルと、受信日時・仕入先コード・転送した人
• OpenAI API が返した JSON の全文
• 取込シートの行と、差分シートで付いた区分
• 承認した人と日時、承認しなかった行とその理由
• 単価マスタの改定前と改定後の単価、反映した日
• 仕入先ごとの例外の件数（対応不明・単位要確認・税区分要確認）

承認しなかった行を残すのは、同じ読み違いを繰り返さないためです。 仕入先ごとの例外の件数は、書式を相談する材料になります。税区分要確認が続く仕入先には、税の扱いを1行書いてもらうだけで解決します。