顧客から届いた提案依頼書（RFP）の要求事項に、過去の回答書と製品資料から回答の下書きを作り、答えられない要求を一覧にする

処理の起点を決める

営業が Teams の案件のチャネルで、RFPの受領を知らせたときに始めます。 RFPが届いてから締切までは、多くの場合2〜3週間です。ノートブックを作るのは、届いた当日か翌日と決めます。答えられない要求を早く回すためです。

ノートブックは、作ったプリセールスから営業と製品担当に共有します。 公式のページでは、ノートブックはチームと共有して一緒に使えるとされています。営業は顧客との質疑の内容を、製品担当は答えられない要求への回答を、同じノートブックで確かめられます。

ノートブックは案件ごとに1つ作ります。 案件のノートブックには、その案件のRFPと、全案件で共通に使う参照を追加します。共通の参照は、毎回同じものを同じ順で追加する決まりにし、チェックリストを案件のフォルダに置きます。

【案件のノートブックに追加する参照（決まり）】
1. 今回のRFPの要求事項の一覧（顧客の様式のまま）
2. RFPの本文（調達の背景、スケジュール、評価の方法）
3. 回答の決まり（対応区分の付け方、使わない言い回し、確認先の一覧）
4. 製品の機能一覧（最新版）
5. 製品の仕様書（最新版）
6. セキュリティのホワイトペーパー、SLA
7. 回答ナレッジのフォルダ（採用された過去の回答書だけを集めたフォルダ）

入力データを集める

質を決めるのは、3行目の回答ナレッジです。 「提案・RFP」サイトには、提出したが失注した回答書、途中で取り下げた下書き、顧客との質疑の途中のメモも混ざっています。それらを全部参照にすると、採用されなかった回答や古い回答を根拠にします。 回答ナレッジのフォルダには、製品担当が確かめた回答書だけを、回答した年月をファイル名に入れて置きます。

4行目と5行目は「最新版」だけを置きます。 製品資料のサイトに旧版が残っていると、廃止した機能を根拠に使います。旧版は別のフォルダに移し、参照に入れません。

【回答の決まり（抜粋）】
対応区分：
- 標準機能で対応 … 機能一覧に「標準」とある機能だけ
- 設定で対応 ……… 仕様書に設定の手順がある機能だけ
- カスタマイズで対応 … 根拠の文書が無いときは付けない（製品担当が決める）
- 対応不可 ………… AIは付けない（製品担当が決める）
書かない内容：ロードマップ（予定の機能）、価格、他社との比較、契約条件
確認先：機能・非機能 → 製品担当／契約条件・損害賠償・知的財産 → 法務／価格 → 営業

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

Copilot が使えるのは、プリセールスが見る権限を持つ資料だけです。 公式のページでは、Microsoft Copilot は利用者が少なくとも閲覧の権限を持つ組織のデータだけを示すとされ、ノートブックも追加した参照のうち、本人がアクセスの権限を持つものだけを使うとされています。製品資料のサイトの権限が営業に付いていないと、参照に追加しても使われません。導入の前に、サイトの権限を確かめます。

参照は、ファイルが変わると答えも変わります。 公式のページでは、データが変わっても参照は最新の状態を保つとされています。製品担当が仕様書を直せば、次の案件からはその内容が使われます。 逆に、提出した後に資料を直すと、提出時の根拠と違ってしまうので、提出した回答書はノートブックの結果とともに案件のフォルダに保存します。

AIへ渡す前に整形する

1. 要求事項の一覧の形を確かめる … 結合したセルや、1つのセルに複数の要求が入っている行は、提出用とは別の作業用の写しで分けます
2. 章ごとの件数を数える … 章ごとに Copilot に頼むため、章と要求番号の範囲を書き出します
3. 回答ナレッジの更新を確かめる … 直近の採用された回答書が、フォルダに入っているかを見ます
4. 製品資料の版を確かめる … 機能一覧と仕様書が最新版かを、ファイル名の日付で見ます
5. 顧客の名前を外す必要があるかを確かめる … 顧客との秘密保持の取り決めで、社内の共有にも制限がある案件は、ノートブックを共有せずに担当だけで使います

1番目を省かないでください。 1つのセルに「CSVで出力できること。またAPIで取得できること」と2つの要求が入っていると、片方だけに答えた下書きになります。 作業用の写しで分けておけば、どちらの要求に根拠が無いかがはっきりします。

AIに処理させる

させるのは、要求ごとに根拠の文書を探し、その文書に沿って対応区分の案と回答の下書きを作り、根拠が無い要求を分けて出すことです。

「根拠が無ければ下書きを作らない」が、この表でいちばん大事な点です。 何も言わなければ、Copilot は要求の文を言い換えて「対応しております」と書きます。読みやすい回答ほど、根拠があるように見えます。 根拠の文書の欄が空の行は、回答の欄も空にする決まりにします。

最後の行の食い違いは、回答ナレッジを育てる材料になります。 2年前の回答書で「CSVの取り込みは手動」と答えた機能が、いまの仕様書では「定時の自動取り込み」になっていれば、今回の回答は仕様書に沿って書き、古い回答書には「旧仕様」の印を付けます。 印の付いた回答書がたまったら、製品担当がまとめて差し替えます。

指示内容を固定する

章ごとに、ノートブックのチャットで次の指示を使います。

あなたは当社のプリセールスとして、顧客のRFPの要求事項に回答書の下書きを作ります。
このノートブックの参照だけを使ってください。

【対象】
RFPの要求事項の一覧のうち、章「{chapter}」の要求番号 {from} から {to} まで

【やること】
要求ごとに、次の列の表を作ってください。
要求番号｜要求の要約（20字以内）｜対応区分の案｜回答の下書き｜根拠の文書名と章・項目｜確認先

【決まり】
- 対応区分は「回答の決まり」に沿って、「標準機能で対応」「設定で対応」のどちらかだけを付けてください。
  それ以外の区分は付けず、「要確認」と書いてください。
- 根拠の文書が見つからない要求は、対応区分を「要確認」、回答の下書きを空欄にし、
  確認先に「製品担当」と書いてください。言い換えで回答を作らないでください。
- 契約条件・損害賠償・知的財産・価格に関わる要求は、回答の下書きを空欄にし、
  確認先に「法務」または「営業」と書いてください。
- 予定の機能、開発中の機能を根拠にしないでください。
- 回答ナレッジの過去の回答と、製品の機能一覧・仕様書の内容が違うときは、
  機能一覧・仕様書を根拠にし、確認先に「食い違い：回答ナレッジ（ファイル名）」と書いてください。
- 1つの要求に複数の条件が含まれるときは、条件ごとに根拠があるかを見て、
  根拠が無い条件があれば「要確認」にしてください。
- 顧客の業務や規模について、RFPに書かれていない前提を足さないでください。

「言い換えで回答を作らない」を明記しないと、根拠の無い下書きが混ざります。 要求の文は「〜できること」と書かれているので、それを「〜できます」に変えるだけで、それらしい回答になってしまいます。禁じるのは、要求の文を根拠の代わりにすることそのものです。

章ごとに頼むのは、確かめる単位を小さくするためです。 200の要求を一度に頼むと、表が長くなり、根拠の欄を1行ずつ確かめる作業が後回しになります。章ごとに頼み、章ごとに確かめて次に進みます。

答えられない要求の一覧は、全章が終わった後に次の指示で出します。

これまでの表から、対応区分が「要確認」の要求と、確認先が書かれた要求だけを、
確認先ごとに分けて一覧にしてください。
要求番号｜要求の文（原文のまま）｜確認先｜確認したいこと（1文）
確認したいことは、要求の文と参照から分かる範囲で書き、推測で足さないでください。

出力形式を固定する

ノートブックのチャットの結果を、表で受け取ります。 Copilot Notebooks は API で構造化した結果を返す仕組みではないので、列を決めた表で受け取り、作業用の表に貼ります。

【回答の下書きの表（章ごと）】
| 要求番号 | 要求の要約 | 対応区分の案 | 回答の下書き | 根拠の文書名と章・項目 | 確認先 |
| F-031 | 権限を部署単位で設定 | 設定で対応 | 利用者の権限は、部署・役職の単位で… | 仕様書 v5.2 4.3「権限の設定」 | |
| F-032 | 承認経路を金額で分岐 | 要確認 | （空欄） | （空欄） | 製品担当 |
| N-104 | 稼働率99.9％以上 | 要確認 | （空欄） | SLA 2.1 | 法務（SLAの保証の範囲） |

1つ目の理由は、根拠の欄を1行ずつ確かめられることです。 プリセールスは、根拠の文書を開いて章・項目を見れば、下書きが正しいかを確かめられます。根拠の欄が空なのに回答がある行は、それだけで差し戻します。

2つ目は、答えられない要求を確認先ごとに渡せることです。 一覧を製品担当と法務の Teams のチャネルにそのまま貼り、誰が何をいつまでに答えるかを決めます。

3つ目は、顧客の様式への転記を機械的にできることです。 要求番号を鍵に、作業用の表から顧客の様式の一覧へ、対応区分と回答を写します。写すのは、プリセールスが確かめて「採用」の印を付けた行だけです。

回答の方針の要約は、Word の Copilot で下書きします。 公式のページでは、Word の Copilot の入力欄で「/」を入力してファイルを選び、特定の資料を参照させて下書きを作れるとされています。案件の作業用の表と、RFPの本文を参照させ、「当社の回答の特徴と、確認中の事項」を1ページにまとめさせます。公式のページも、下書きは共有する前に事実・数字・引用・名前を確かめるよう案内しています。

システムへ連携する

顧客の様式に、Copilot が直接書き込むことはしません。 下書きは作業用の表に置き、プリセールスが確かめて「採用」の印を付けた行だけを写します。提出物に、確かめていない回答が紛れ込む経路を作りません。

回答ナレッジへの追加も人が行います。 案件が終わったら、採用された回答書を製品担当が確かめてからフォルダに入れます。Copilot の下書きがそのまま次の案件の根拠になることを防ぎます。

人が確認する

この構成では、提出するすべての回答を人が確かめます。

1. 答えられない要求を先に回す … 一覧を確認先ごとに分け、RFPが届いた翌日に依頼します
2. 根拠の文書を開いて確かめる … 根拠の章・項目に、回答の内容が本当に書いてあるかを見ます。ここは流し見しません
3. 対応区分を決める … 「標準機能」か「設定」かの案を確かめ、「カスタマイズ」「対応不可」は製品担当の回答を待って決めます
4. 食い違いを直す … 回答ナレッジと最新の資料の食い違いが出たら、最新の資料に合わせ、回答ナレッジ側の古い回答に印を付けます
5. 営業が全体を読む … 価格と契約条件を足し、評価の方法に照らして回答の強弱を整えます

1番目の依頼には期限を付けます。 製品担当への依頼に「締切の5営業日前まで」と書き、Teams のチャネルで要求番号ごとに返事をもらいます。返事が来た要求から、作業用の表の確認先の欄を「回答済み」に変えます。

2番目を省かないでください。 根拠の欄に文書名が書かれていても、その章に書いてある内容と回答が少しずれていることがあります。「部署単位で設定できる」と「部署と役職の組み合わせで設定できる」は、顧客の評価では違う回答です。

目標は、1件あたり90分です。 探して写す時間が、根拠を開いて確かめる時間に置き換わります。

例外に対処する

最後の行は、顧客への質疑に使えます。 RFPには質問の受付期間があることが多く、あいまいな要求を早く見つけられれば、質疑で前提をそろえられます。

記録を残す

• 案件ごとのノートブックと、追加した参照の一覧（ファイル名と版）
• 章ごとの下書きの表と、プリセールスが直した後の表
• 答えられない要求の一覧と、確認先の回答、回答した日
• 提出した回答書と、提出した日
• 回答ナレッジに追加した回答と、追加を確かめた製品担当

Copilot とのやり取りの記録は、組織の Microsoft 365 の中に残ります。 公式のページでは、利用者の指示と Copilot の応答は組織のほかの Microsoft 365 のコンテンツと同じ契約上の約束に沿って処理・保存され、管理者は Microsoft Purview で保持のポリシーを決められるとされています。どの期間残すかを、提案書の保存の期間と合わせて決めます。