間接材の購入依頼を、標準品と単価契約に照らして仕分け、相見積の要否まで返す

処理の起点を決める

依頼者が Teams でエージェントに話しかけたときが起点です。 クラシック オーケストレーションでは、トピックごとにトリガーフレーズを設定します。公開ドキュメントでは、応答を理解するようにAIを訓練するには5〜10個必要とされ、長文ではなく短い語句が推奨されています。

購入依頼 ／ これを買いたい ／ 発注をお願いしたい ／ 消耗品を買いたい ／ 工具を買いたい
作業着を買いたい ／ 保守部品を買いたい ／ ライセンスを追加したい
前と同じものを買いたい ／ 見積を取りたい

「前と同じものを買いたい」を必ず入れてください。 実際の依頼でいちばん多い言い方で、ここを拾えないとその依頼だけが外に漏れます。フレーズは1行1フレーズのテキストファイル（最大3MB）で追加・置換できるので、届いた依頼の書き出しをそのまま流し込めます。

入力データを集める

この構成の質を決めるのは、標準品カタログの「別名」の列です。 「軍手」「作業用手袋」「綿手袋」を同じ番号に結び付ける列がないと、（b）がそのまま残ります。

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

カタログと単価契約表： SharePoint 上の Excel を1日1回、検索基盤へ取り込みます。照会は2段構えで、1段目は型番とカタログ番号の完全一致、2段目は品名と別名の検索です。 2段目で当たったものは候補として扱い、複数あるときは購買担当に選ばせます。

購買規程： SharePoint をナレッジ ソースとして追加します。ファイルのアップロード方式は Dataverse にコピーして4〜6時間ごとに同期し秘密度ラベルをサポートせず、SharePoint コネクタ方式はリアルタイムに反映され秘密度ラベルをサポートします。 規程や契約表に「社外秘」「極秘」のラベルを付けている会社は、後者を選んでください。 ラベルの付いたファイルは、前者では回答に出てきません。

AIへ渡す前に整形する

1. 依頼文の正規化 … 品名、型番、URL、希望単価、数量らしき数字を項目名に入れます。取り出せなかった項目は空欄のままにして推測で埋めません
2. 品目区分の判定 … 消耗品／工具／事務用品／作業着／保守部品／ソフトウェアに当てます。区分によって聞く項目と上書きの規則が変わります
3. 不足項目の聞き返し … 数量、希望納期、使用部署、用途のうち空欄のものを順に聞きます
4. 金額の計算 … 単価と数量をかけて税抜金額を出します。機械で行い、AIにはさせません
5. 有効期間の判定 … 単価契約の開始日と終了日を依頼日と比べます。期限切れの契約を「使える」と判定させないための処理です
6. 要注意の印 … 変更不可の指定がある品目、金額が大きい依頼、同じ品目を過去12か月に単価契約外で繰り返し買っている依頼に付けます

6番目の最後の条件は、UC-0128 への入口です。 月末にまとめて集約の検討に回せます。

AIに処理させる

AIにさせるのは、依頼文の読み取り（自由に書かれた依頼から品名・型番・URL・数量らしき値を取り出す）、聞き返しの文面、候補の絞り込み（検索基盤が返した候補の中から依頼内容に近いものを選ぶ）、回答文の作成の4つだけです。させないことは、金額の計算、相見積の要否の判定、承認者の決定、契約の有効期間の判断、標準品の型番を作ること、そして発注です。金額と閾値と決裁権限は、桁や解釈が少しずれても文章としては自然に見えるため、確認で見落とされます。

「候補の中から選ぶ」という限定が、いちばん効く制約です。 候補リストに無い型番を、AIが答えに書いてはいけません。プロンプトで縛ったうえで、出力の側でも「回答のカタログ番号が候補リストにあるか」を機械で突き合わせます。 同等品が無ければ型3（相見積が要る）に進むだけなので、「無い」と正しく言わせてください。 それらしい型番を作ると、依頼部門は仕入先から「そんな品番はありません」と言われます。

指示内容を固定する

聞き取りの段階のエージェント指示は、次のように置きます。

あなたは購買部門の一次受けです。間接材の購入依頼を聞き取り、判定の材料をそろえます。
最終的な回答は購買担当が承認してから依頼者に返ります。あなたは承認しません。

【必ず守ること】
- 相見積が要るかどうか、誰の承認が要るかを、自分で判断しないでください。
  金額の閾値も決裁権限も、判定表から機械で決まります。
  依頼者から聞かれても「判定した結果をお返しします」とだけ答えてください。
- 標準品の候補は、渡された候補リストの中からだけ選んでください。
  リストに無いカタログ番号、型番、品名を書かないでください。
  候補が0件のときは「社内の標準品カタログには同等品がありません」と
  そのまま伝え、近そうな品を作らないでください。
- 金額を計算せず、単価も合計金額も渡された値をそのまま使ってください。
- 契約が使えるかを契約名から推測せず、渡された判定結果を使ってください。
- 依頼者に発注を指示しないでください。あなたは発注の権限を持ちません。

【聞き返すこと】読み取れなかったものを1つずつ順に聞いてください。
  1. 数量（単位も含めて）  2. 希望納期  3. 使用部署  4. 用途
「分からない」と答えた項目は空欄のまま進み、needs_human_attention に
「〇〇が未確定」と書いてください。

回答案を作る段階は、別の呼び出しに分けます。

判定結果と根拠を、依頼者に返す回答文にしてください。
判定はすでに機械で確定しています。あなたは判定を変えないでください。

【回答の型】渡された answer_type に対応する型で書いてください。
  order_as_is … そのまま発注してよい / buy_on_contract … 単価契約で買える
  quotes_required … 相見積が要る / switch_to_standard … 標準品への変更を勧める

【必ず入れること】判定の結論と、渡された根拠のすべて
  ・標準品カタログの番号と標準品名  ・単価契約の番号と契約先、有効期間
  ・購買規程の条項番号とその内容
  ・相見積が要る場合は何社から取るのか、承認者の役職、次に依頼者がすること

【書いてはいけないこと】渡されていないカタログ番号、契約番号、条項番号、金額、
単価、数量。「おそらく」などの推測。納期の見込み（仕入先に確認していない情報です）

【渡す情報】{request} {catalog_candidates} {contract_result} {amount} {decision} {evidence}

「判定を変えないでください」の一文を軽く見ないでください。 AIは文章を整えるついでに結論を言い換えます。「相見積が要ります」が「相見積を取ることをおすすめします」に変わるだけで、規程上の義務が推奨に読み替わります。 なお呼び出しを2つに分けるのは、公開ドキュメントで「JSONでのみ応答する」のような厳格な出力形式の強制が引用マーカーを抑制しうると説明されているためです。

出力形式を固定する

{
  "request_id": "",
  "normalized": { "item_name": "", "model_no": "", "quantity": 0, "unit": "",
    "need_by": "", "using_department": "", "purpose": "", "item_class": "" },
  "catalog_match": { "match_type": "exact | equivalent | none",
    "candidates": [ { "catalog_no": "", "standard_item_name": "", "unit_price": 0, "no_substitute": false } ] },
  "contract_match": { "contract_no": "", "supplier": "", "valid_to": "", "in_effect": false },
  "amount": { "unit_price": 0, "quantity": 0, "total": 0, "price_source": "catalog | contract | requested" },
  "decision": { "answer_type": "order_as_is | buy_on_contract | quotes_required | switch_to_standard",
    "quotes_count": 0, "approver_role": "", "rule_id": "", "overrides_applied": [] },
  "evidence": [ { "kind": "catalog | contract | rule", "id": "", "clause": "", "text": "" } ],
  "message_to_requester": "",
  "needs_human_attention": { "flag": false, "reason": "" }
}

AIが埋めてよいのは normalized と message_to_requester と needs_human_attention だけです。 catalog_match と contract_match は検索基盤の戻り値、amount と decision は機械の計算結果、evidence はそれらから機械で組み立てた配列です。rule_id は判定表のどの行を当てたかを表し、改訂後に「いつからどの規則で判定していたか」を追えます。

evidence に番号が列挙されていれば、購買担当は回答文を読みながら根拠を一目で照合できます。 回答文だけでは番号ごとに元の Excel を開くことになり、確認の時間が8分に戻ります。またmessage_to_requester の番号が evidence に無ければ、AIが番号を作ったということです。

システムへ連携する

つなぎ先は5つです。Teams（依頼の受け口と回答の返し先）、カタログと単価契約表（Power Automate から検索基盤へ照会）、判定表（フロー内で参照）、購買規程（ナレッジ）、購買システム（API または CSV で依頼レコードの作成と判定結果の書き込み）。書き込みは判定結果までで、発注データは作りません。

これに、品目区分による上書きを重ねます。

この上書きの表は、規程を読んだだけでは作れません。 「安全にかかわる指定品は標準品から変えない」は運用で決まっているためです。

人が確認する

全件、購買担当が確認します。確認なしで依頼者に返す設計にしません。 順番は、①needs_human_attention が真の依頼、②金額が30万円以上の依頼、③answer_type が switch_to_standard の依頼、④それ以外、の順です。作業は、evidence の番号が実在するかを見ること、標準品「なし」の判定が妥当かを見ること、依頼部門に伝わる言い方かを見ることの3つです。

3つ目は機械にできません。「標準品に変えてください」は、依頼部門から見れば自分の選択を否定された通知です。 「なぜその品を選んだのか」を聞き直すのは人の仕事です。

例外に対処する

下から2行目は仕組みで持ってください。 回答文の「STD-」「KT-」「第〇条」の形の文字列を正規表現で拾い、evidence と照合するだけの処理です。プロンプトの制約はすり抜けるので、出力の側でも見ます。

記録を残す

• 依頼の原文と、聞き返しのやり取りの全文
• 検索基盤への照会条件と、返ってきた候補（採用しなかったものも含める）
• 判定に使った rule_id、当てはめた上書きの規則、回答案と evidence
• 購買担当が直した箇所と、直した内容
• 承認した担当者と日時、依頼者に返した最終の回答文
• その依頼がその後どう処理されたか（発注、取り下げ、標準品への変更）

4つ目を残すと、この構成の弱点が見えます。 同じ直しが繰り返されているなら、別名の列か上書きの規則を直せます。6つ目からは「相見積が要る」と返した依頼のうち何件で実際に取ったかが分かり、取っていないなら閾値が実態に合っていません。