仕入先から届く見積の内訳を、材料の市況・過去の見積・加工時間の目安に照らして点検し、根拠の確認が要る費目と価格交渉の論点を出す

処理の起点を決める

「見積受付」ライブラリにファイルが作成されたことを起点にします。 見積は依頼から回答まで日がばらばらに届くため、1日1回の定時実行にはしません。 まとめて処理すると、仕入先へ照会を返すのが1日遅れ、回答期限の短い見積では交渉の時間が残りません。

品番のフォルダに直接入れる運用はやめます。 フォルダが品番の数だけあると、トリガーを置く場所が決まりません。受付は1か所にし、点検が終わったら品番のフォルダへ移します。 移すのは点検結果をリストに書き込めたときだけにし、受付ライブラリに残っている数が、そのまま未点検の数になるようにします。

ライブラリには 品番、仕入先コード、依頼番号の列を持たせ、保存するときに担当者が選びます。ファイル名から推し量る方式は、仕入先が名前を付け替えて返してくるので続きません。

入力データを集める

質を決めるのは、見積依頼書の項目です。 前回と今回で何が変わったかが分からなければ、差のすべてが「高い」に見えます。図面の版、材質、ロット、表面処理を依頼書の項目として持たせておくのが、最初の準備作業です。

材料の単価表には、単価の出どころの列を持たせます。 業界紙の市況、商社からの提示、自社の購入実績のどれを元にしたかで、仕入先に示せるかどうかが変わります。出どころのない単価で「材料費が高い」と言うと、根拠を聞かれて答えられません。

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

内訳の表は、行が多いと既定では全部返りません。 「テーブルに存在する行を一覧表示する」は既定で最大256行を返し、すべての行を取るには改ページの設定を有効にするとされています。見積内訳書の行は通常そこまで多くありませんが、複数の品番をまとめた見積では超えることがあるので、改ページは最初から有効にします。

列名に記号を使わないでください。 応答の列名は OData の形式に合わせて変換されることがあり、たとえば # は _x0023_ になるとされています。指定様式の列名を「工程No.」のようにしていると、フローの側で名前が変わります。列名は英数字と日本語の語だけにします。

AIへ渡す前に整形する

1. 様式の確認 … 指定様式のテーブル名と列がそろっているかを確かめます。そろっていなければ点検せず、担当者に戻します
2. 単位の統一 … 重量はkg、時間は分、金額は円にそろえます。「1.2h」「72min」が混ざる仕入先があります
3. まとめ書きの検出 … 加工費が1行にまとめられ、工程ごとの時間が無いものに印を付けます
4. 前提の比較 … 依頼書の材質・ロット・図面の版・表面処理を前回と比べ、変わった項目を一覧にします
5. 検算 … Office スクリプトで、重量×kg単価、時間×チャージ、各費目の合計と総額の一致を確かめます
6. 差の計算 … 費目ごとに、参照値との差の率と前回比を出します
7. 差の材料の付与 … 差の大きい費目に、関係する前提の変更を結び付けます（材料費と材質、加工費とロットなど）

5番目をAIに渡す前に終わらせます。 内訳の合計が総額と合わない見積は、点検の前に仕入先へ確かめるべきもので、論点の判定に進めると、計算の食い違いが「加工費が高い」という論点に化けます。

スクリプトには呼び出しの上限があります。 Power Automate から Office スクリプトを実行する操作は、10秒あたり最大3回、1日あたり最大1,600回とされています。月120件なら余裕がありますが、1件で何度も呼ばない作りにします。 検算と差の計算は1回の実行でまとめて行います。

AIに処理させる

させるのは、計算済みの差を受け取り、費目ごとにその差の意味を判定して、論点を質問の形で書くことだけです。

premise_gap と ask_basis の区別が、この構成でいちばん大事です。 前者は前提をそろえれば比べられるもの、後者は前提が同じなのに違うものです。前者を値下げの論点にすると、仕入先には「前回の条件を読んでいない」と映ります。

basis_given を論点から外すのは、指針に沿うためです。 労務費転嫁指針は、発注者が説明や根拠資料を求める場合は公表資料に基づくものとし、受注者が公表資料を用いて示した価格を合理的な根拠があるものとして尊重するよう求めています。チャージの上昇に最低賃金の上昇率などが添えられていれば、それは交渉で押し返す対象ではありません。

3行目がいちばん起きやすい失敗です。 差が出ている見積を渡すと、AIは親切に「加工費を15％下げた〇〇円が妥当」と書きます。参照値は社内の目安にすぎず、それを相手の適正価格として示すと、一方的な価格の押し付けに見えます。 書かせるのは「何を聞くか」までです。

指示内容を固定する

あなたは製造業の購買課で、仕入先から届いた見積の内訳を点検し、
仕入先に確かめる論点を整理する立場です。
渡すのは、スクリプトが計算した費目ごとの差と、前提の変更の一覧です。
計算はすでに終わっています。あなたは計算をしないでください。

【やること】
費目（材料費・加工費の各工程・外注費・管理費・利益）ごとに、
次のどれに当たるかを判定し、論点を書いてください。
- in_range ...... 参照値との差が目安の幅に収まっている
- ask_basis ..... 幅を外れており、前提の変更も、見積の備考の根拠も無い
- premise_gap ... 幅を外れているが、前提の変更（材質・ロット・工程・表面処理・図面の版）が
                  この費目に結び付いている
- basis_given ... 幅を外れているが、見積の備考に公表資料などの根拠が書かれている
- no_reference .. 参照値が無い
迷ったときは ask_basis ではなく no_reference を選んでください。

【論点の書き方】
- 論点は、仕入先に聞く質問の形で書いてください。
  「高い」「下げてください」とは書かないでください。
- premise_gap の論点は、前提をそろえた金額を聞く形にしてください。
  例：「前回（ロット100個）と同じ条件での加工費を教えてください」
- 論点ごとに、根拠にした数値（参照値・今回値・差の率）と、
  参照値の出どころを basis に写してください。

【厳守事項】
- 金額や率を計算しないでください。渡された数値だけを使ってください。
- 目標価格、値下げ額、値下げ率を書かないでください。
- 「適正な価格は〜円」のように、相手の原価を断定しないでください。
- 見積の備考に、最低賃金の上昇率、春季労使交渉の妥結額などの公表資料が
  根拠として書かれている費目は basis_given にし、論点にしないでください。
- 仕入先の経営状況や、発注先の変更について書かないでください。
- 内訳の合計が総額と一致しないという印が付いている場合は、
  判定をせず、document_status を totals_mismatch にしてください。

【費目ごとの差】{diffs}
【前提の変更の一覧】{premise_changes}
【見積の備考】{remarks}
【参照値の出どころ】{reference_sources}

「下げてください」と書かせないことを、論点の書き方と厳守事項の2か所に書いています。 片方だけだと、質問の形を守りながら「〇％程度の削減は可能でしょうか」と数字を入れてきます。禁じたいのは、社内の目安を相手への要求に変える書き方そのものです。

出力形式を固定する

Azure OpenAI の構造化出力で、次の形のJSONに固定して受け取ります。 構造化出力は、推論の呼び出しで渡したJSONスキーマにモデルを従わせる機能で、JSONとして正しいことしか保証しない従来のJSONモードとは違い、スキーマへの厳密な準拠を求められるとされています。

{
  "quote_id": "",
  "document_status": "ok | totals_mismatch | layout_mismatch",
  "items": [
    { "cost_item": "material | process | outsourcing | overhead | profit",
      "process_name": null,
      "judgement": "in_range | ask_basis | premise_gap | basis_given | no_reference",
      "linked_premise": null,
      "question": null,
      "basis": "" }
  ],
  "open_questions_count": 0
}

スキーマの書き方には決まりがあります。 すべての項目を required に入れ、オブジェクトには additionalProperties: false を付けます。省略してよい項目は、型を ["string", "null"] のように null との組にして表します。 上の process_name や question がそれで、加工以外の費目や in_range の費目では null が入ります。スキーマ全体でオブジェクトのプロパティは100個まで、入れ子は5段までです。

1つ目の理由は、判定と確認の重さを別の層に置けることです。 items はAIが埋め、確認の重さは Power Automate が規則で決めます。

2つ目の理由は、論点の数を後段で数えられることです。 open_questions_count と items の中の論点の数が合わなければ、出力のどこかが崩れています。合わないものは、確認の重さを「人の判断が要る」に上げます。

3つ目は、basis で確認が速くなることです。 担当者は論点ごとに、何と比べてどれだけ違うかを、ファイルを開かずに読めます。

システムへ連携する

生産管理システムへは書き込みません。 この構成が出すのは点検の結果と論点までで、単価を登録するのは交渉が終わった後の別の手続きです。 書き込みを足すと、交渉中の金額がそのまま単価になる経路ができます。

参照の表も読み取りだけです。 Excel Online (Business) コネクタは、読み取りの操作でもファイルが変更されてバージョン履歴に新しい版が出ることがあるとされています。参照の表は、フロー用に書き出した写しを読み、原本には触れさせません。 手で編集している最中のファイルに別の経路から書き込むと競合が起きるともされているので、写しを分けておけば両方の問題を避けられます。

人が確認する

人が開くのは「論点あり」と「人の判断が要る」の見積です。 「軽い確認」のものは、一覧で仕入先と総額を流し見ます。全件で論点を読み込む設計にすると、第10章の30.0時間には収まりません。

1. 「人の判断が要る」を先に見る … no_reference の費目は、生産技術課に目安を聞くか、似た工程の目安を当てます
2. premise_gap の前提を確かめる … 結び付けられた前提の変更が、本当にその費目に効くかを図面と依頼書で見ます
3. ask_basis の論点を取捨する … 差が小さく金額の影響も小さいものは外します。聞く論点は多くても3つまでに絞ります
4. 照会文を直して送る … 送信は人が行います
5. 判定を覆したら記録する … どの費目を、どの判定からどの判定に変えたかを残します

2番目を省かないでください。 premise_gap は機械的に結び付けたものなので、ロットが変わっていても材料費には効かない、といった組み合わせが混ざります。前提の取り違えは、仕入先に「条件を読んでいない」と受け取られる一番の原因です。

例外に対処する

上から3行目までが、最初の数か月の大半を占めます。 どれもAIの問題ではなく、見積の出し方の問題です。 仕入先ごとの発生件数を数え、多い仕入先には様式の書き方を説明しに行くほうが、判定を磨くより効きます。

記録を残す

• 見積内訳書の元ファイルと、受け付けた日時・担当者
• スクリプトが出した検算の結果と、費目ごとの差の一覧
• そのとき参照した単価表・加工時間の目安の版（更新月）
• AIの出力のJSON（items、論点、basis）と、確認の重さ
• 担当者が判定を覆した記録と、外した論点
• 照会文、仕入先の回答、交渉の経過と決まった価格

3つ目で参照の表の版を残すのは、単価表が毎月変わるためです。 「材料費が高い」という判定が、どの月の単価と比べたものかが残っていないと、仕入先から異議が出たときに説明できません。

最後の行は、指針が求める記録でもあります。 労務費転嫁指針は、発注者と受注者の共通の取組として、価格交渉の記録を作成して双方が保管することを挙げています。点検結果と照会文と回答を1件の記録につないでおけば、そのまま交渉の記録になります。