購買の引き合い仕様書を、依頼部門とのAIとの対話で必要事項を埋めてから作る

処理の起点を決める

依頼者がエージェントに話しかけたことを起点にします。 クラシック オーケストレーションでは、トピックにトリガーフレーズを設定します。

トリガーフレーズは5個から10個必要です。 AIに応答の理解を訓練させるために、この程度の数が求められます。句読点を含めてかまいませんが、長文ではなく短い語句が推奨されます。顧客の入力はトリガーフレーズと完全一致である必要はありません。

購買の引き合いなら、次のような語句を並べます。

見積を取りたい
購買依頼を出したい
設備を買いたい
工事を頼みたい
外注をお願いしたい
相見積が欲しい
RFQ
仕様書を作りたい

トリガーフレーズはテキストファイルでアップロード、置換、ダウンロードができます。 ファイルは最大3MBで、1行に1フレーズです。呼ばれなかった言い方の報告が来たら、ファイルを差し替えるだけで増やせます。

トピック名にピリオドを使わないでください。 ピリオドを含むトピック名のエージェントを含むソリューションは、エクスポートできません。

入力データを集める

項目リストがこの構成の質を決めます。 ここが空のまま作ると、これまで担当者の記憶にあったばらつきが、そのままエージェントのばらつきになります。

項目リストは大きくなくてかまいません。 1つの区分につき10項目から15項目、3区分で40項目ほどで足ります。直近の引き合い10件について、購買担当が依頼者に送ったメールを読み返し、実際に聞いた内容を並べるだけです。

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

項目リストは SharePoint リストで持ちます。 エージェントの中に項目をハードコードしません。理由は2つあります。

1つ目は、購買担当が自分で直せるようにするためです。 項目を1つ足すたびに Copilot Studio を開いて発行し直すのでは、運用に入ってから誰も直さなくなります。

2つ目は、区分の追加が行の追加で済むようにするためです。 対話の設計を変えずに、項目だけを足せます。

読み込みは、ツールノードから Power Automate のフローを呼んで行います。依頼者名と部門は聞きません。 サインイン情報から取れるからです。

過去の引き合い仕様書は、同じ区分の直近のものを SharePoint から取ります。ファイル名に「区分_案件名_YYYYMMDD」の形式を使えば機械的に引けます。

AIへ渡す前に整形する

1. 区分の確定 … 依頼者が「設備」と言っても、据付工事を伴うのか、機械を置くだけなのかで聞く項目が変わります。条件ノードで、最初に1つだけ確認の質問を挟みます
2. 項目リストの読み込み … 確定した区分に対応する行だけを読み、その順番で聞きます。関係のない項目を聞かないことが、依頼者の離脱を防ぎます
3. 既知の情報の充当 … 依頼者名、部門、日付はサインイン情報とシステム日付から埋め、質問しません
4. 単位の正規化 … 「3メートル」「3000ミリ」を、数値と単位に分けて持ちます。仕様書には単位を付けて書き戻します
5. 予算の分離 … 予算や希望価格は聞きますが、この時点で仕様書に載せない領域へ振り分けます

AIに処理させる

させることを、聞き取りの側と文書化の側に分けて考えます。

聞き取りの側（Copilot Studio のトピック）：

質問ノードでは、「識別」で応答の解釈の仕方を選びます。 複数選択オプションを選ぶと、選択肢ごとの条件付きパスが自動で作られます。各選択肢はチャットのボタンとして表示されますが、ユーザーは回答を入力することもできます。

応答を保持する変数は、名前を変更してプロパティを構成できます。変数名は仕様書の項目名と対応させます。 ノード名の長さは500文字までで、トリガーノードと手順に進むノードは名前を変更できません。

文書化の側：

「わからない」を無理に埋めさせないことが、この設計の要です。 書かれた仕様が間違っているほうが、書かれていないより厄介です。 各社は書かれたとおりに見積を作るからです。 わからない項目は「未定」として残し、引き合いの文面では「各社の提案による」と書きます。

指示内容を固定する

聞き取りの設計は、キャンバスで作った内容をコードエディターで YAML として確認できます。質問ノードと条件グループを組み合わせると、次のような構造になります。

kind: ConditionGroup
conditions:
  - id: equipment
    condition: =Topic.Category = "設備"
    actions:
      - kind: Question
        id: q_power
        variable: Topic.PowerSupply
        prompt: 電源は何が必要ですか。電圧と相数を教えてください。わからない場合は「わからない」を選んでください。
        entity: StringPrebuiltEntity
      - kind: Question
        id: q_size
        variable: Topic.Dimensions
        prompt: 設置できる最大寸法を、幅・奥行・高さの順に、単位を付けて教えてください。
        entity: StringPrebuiltEntity
      - kind: Question
        id: q_installation
        variable: Topic.InstallationScope
        prompt: 据付はどこまでを依頼しますか。
        entity:
          kind: ClosedListEntity
          items: [ 搬入のみ, 搬入と設置, 設置と電源工事, 試運転まで, わからない ]

分岐の設計はキャンバスで行ってください。 トピックは他のエージェントからコピーして貼り付けられますが、トピック全体をコードエディターで設計し、複雑なトピックを貼り付けることは完全にはサポートされていません。

文書化の側に与える指示は、次の形になります。

あなたは購買部門の担当者を支援する立場です。
依頼者との対話で集めた回答をもとに、引き合い仕様書（RFQ）の下書きを作ってください。

【厳守事項】
- 回答されていない項目を、推測で埋めないでください。
  記載がなければ不明とし、status を unknown にしてください。
  そのうえで open_questions に入れ、本文には「各社の提案による」と書いてください。
- internal_only に入っている項目（予算、希望価格、社内での比較の意図、
  想定している発注先）は、仕様書の本文に一切書かないでください。
  要約や前提条件の中にも書かないでください。
- 「一式」「現行同等」「適宜」「なるべく」という語を仕様書に使わないでください。
  依頼者がそう答えた場合は、聞き直した結果を書いてください。
  聞き直しても具体化しなかった場合は unknown にしてください。
- 数量、寸法、期間、能力は、必ず単位を付けて書いてください。
  単位が回答に含まれていない場合は、推測せず unknown にしてください。
- 会社名や型番を書いてよいのは、依頼者が「これと同等」と明示した場合だけです。
  その場合も「同等品可」と併記してください。
- 納期や価格の希望を、仕様書の中で条件として断定しないでください。
- 依頼者の発言のうち、社内の人物評や他部門への言及を含めないでください。

【購買の区分】
{category}

【聞き取りの結果】
{items}

【この区分のひな形】
{template}

「記載がなければ不明とする」という制約を、複数の書き方で重ねて入れています。 未回答、単位なし、曖昧な語の3つは、いずれも「それらしく埋められてしまう」箇所だからです。埋められた仕様書は、読んだだけでは不備が見えません。

出力形式を固定する

聞き取りの結果は、次の構造で受け取ります。

{
  "request_id": "",
  "requester": { "name": "", "department": "" },
  "category": "equipment | construction | service | other",
  "items": [
    {
      "key": "power_supply",
      "label": "電源",
      "value": "三相200ボルト",
      "unit": null,
      "status": "answered | unknown | skipped"
    }
  ],
  "open_questions": [
    { "key": "installation_scope", "note": "据付の範囲は各社の提案による" }
  ],
  "internal_only": [
    { "key": "budget", "value": "", "visibility": "purchasing_only" }
  ],
  "summary_confirmed": false,
  "draft_rfq_path": ""
}

internal_only を構造で分けることが、この設計の中心です。

予算や希望価格は、引き合いを出す前に相手を選ぶ判断に使う情報です。しかし、引き合い仕様書に書いてはいけません。 予算を知った各社は、その金額に寄せた見積を出します。相見積を取る意味がなくなります。

同じ対話で聞いた内容を、同じ場所に置いておくと、いつか混ざります。 指示するだけでは足りません。指示は守られないことがありますが、渡していない情報は書きようがありません。

status を3つに分けているのも同じ考え方です。unknown（依頼者が答えられなかった）と skipped（この案件には関係がないので飛ばした）を区別します。 この2つを一緒にすると、聞くべきだった項目が静かに消えます。

unit を value から分けているのは、単位の付け忘れを機械で検出するためです。数量の項目で unit が null なら、仕様書を出す前に警告を出せます。

システムへ連携する

Copilot Studio 側からは、ツールノードで Power Automate のフローを呼びます。 ツールノードは Power Automate や Excel Online のフローを呼び、コネクタを使うためのノードです。

各社への送付は人が行います。自動送信にしません。 引き合いを出すことは、買う意思があるという表明です。誤った相手に、誤った内容で出てしまうと、断るところからやり直しになります。

エージェントを変更したらテストし、目的のチャネルに発行します。発行を忘れると、依頼者の画面は古い設計のままです。

人が確認する

全件、購買担当が確認します。 確認するのは、文章の読みやすさではなく次の4点です。

1. internal_only の情報が本文に混ざっていないか … 予算、希望価格、想定発注先。ここは1件も見逃せません
2. unknown の項目が「各社の提案による」になっているか … 空欄のまま出すと、各社が黙って自社の標準で埋めます
3. 「一式」「現行同等」が残っていないか … 依頼者の言葉がそのまま通っていないか
4. 区分の判定が正しいか … 設備として聞き取ったが、実際は工事の要素が大きい案件がある

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

• status が unknown の項目を、仕様書の上のほうにまとめて表示する
• internal_only の項目を、仕様書の画面には出さず、別の画面で見せる
• 依頼者の元の回答と、文章化された仕様を左右に並べる

確認にかかる時間の目標は、1件15分です。 それ以上かかるなら、聞き取りの項目が足りていないか、文章化の指示が緩すぎます。

例外に対処する

記録を残す

• 対話の全文（誰が、いつ、何を聞かれて、どう答えたか）
• 聞き取り結果の構造化データ（items と status）
• internal_only の内容と、閲覧した人の記録
• 生成した引き合い仕様書の下書きの版
• 購買担当が直した箇所と、直した内容
• 各社へ送付した仕様書の版と、送付先・送付日時

5つ目が、この構成を育てる材料になります。「据付の範囲がいつも書き足されている」なら、聞く項目が足りていません。 「未定と書かれた項目をいつも埋め直している」なら、聞き直しの条件が緩すぎます。直した箇所の傾向が、そのまま項目リストの改善点になります。

対話の全文を残すのは、あとで「聞いていなかった」「答えていなかった」が起きたときに、事実を確認するためです。