システムの更新で複数のベンダーから届いた提案書を、要件の充足・費用・体制・リスクで比較表にし、確かめる質問の一覧を作る

処理の起点を決める

主担当が、提案の締切日に全社の提案書がそろったことを確かめた時点を起点にします。 ベンダーから届いた順に1社ずつ読ませると、先に届いた会社の要約だけが先に共有され、選定メンバーの印象が届いた順に左右されます。全社分がそろってから、同じ指示で一度に読ませます。

締切に遅れた会社があるときは、そろった分だけで先に進めません。遅れた会社の提案書が届くまで待つか、その会社を選定から外すかを、選定会議の責任者が決めてから始めます。 比較の起点を人が決めることで、比べる相手がそろっていない比較表が出回るのを防ぎます。

質疑の回答が届いたときが、2回目の起点です。 回答書をノートブックの参照に足し、「記載なし」だった項目と、質問を送った項目だけをもう一度読ませます。最初から全部をやり直すと、すでに確かめた項目の要約が変わり、確認の手間が増えます。

入力データを集める

質を決めるのは、いちばん上の要件一覧です。 要件の番号が振られていない、1つの文に3つの要件が入っている、といった要件一覧では、AIの要約も同じだけあいまいになります。「帳票をCSVとPDFで出力でき、出力の権限を部署ごとに設定できること」は、2つの要件に分けておきます。 分けておけば、「CSVは標準、権限設定は追加開発」という読み分けができます。

評価の観点の説明は、毎回同じものを使います。 区分の定義が案件ごとに変わると、比較表の粒度がまたばらつきます。この1枚が、第3章の（b）を直す道具です。

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

すべての文書は、案件の SharePoint のサイトにすでに置かれています。取得の仕組みを新しく作る必要はありません。 主担当がノートブックを作り、参照を追加するだけです。

参照は、フォルダではなくファイルを1つずつ追加します。 公式のページでは、共有の場所を参照に加えると、その中からプロンプトに関係の深い最大300のファイルが選ばれて根拠に使われるとされ、確実に含めたいファイルはノートブックに直接追加するよう案内されています。1社の提案書が選ばれずに抜け落ちると、その会社だけ「記載なし」が並びます。

ファイル名は、ベンダー名と文書の種類が分かるようにそろえます。 「A社_提案書_本文.pdf」「A社_見積明細.xlsx」のようにしておくと、AIが根拠として返す文書名から、どの会社のどの文書かがすぐに分かります。

AIへ渡す前に整形する

1. 要件一覧の分割 … 1つの文に複数の要件があれば分け、番号を振り直します
2. 区分の定義の確認 … 評価の観点の説明が最新の版であることを確かめます
3. 提案書の形式の確認 … 対応する形式は .docx、.pptx、.xlsx、.pdf などです。画像だけのPDF（スキャンしたもの）は、文字として読めるかを先に確かめます
4. ファイル名の統一 … ベンダー名、文書の種類、版を付けます
5. 版の整理 … 提案書の差し替えが届いたら、古い版を参照から外します
6. ページ番号の確認 … 根拠のページを返させるため、ページ番号の無い文書はそのことを記録しておきます
7. 機密の表示の確認 … 秘密保持の範囲で社内利用できる文書かを確かめます（第13章）

3番目と5番目を軽く見ないでください。 スキャンした体制図や、画像で貼り付けた機能対応表は、文字として読めないことがあります。読めない部分は「記載なし」として返ってくるため、ベンダーが書いていたのに質問を送ることになります。古い版を残したままにすると、差し替え前の金額が要約に混ざります。

AIに処理させる

させるのは、要件一覧の項目ごとに、各社の記載を区分に分けて要約し、根拠の文書名とページを付けることです。 あわせて、費用・体制・リスクの記載を拾い、質問の案を作らせます。

右端の列が、この構成でいちばん大事な区別です。 「記載なし」は、提案書を読んでも見つからなかったということで、対応できないという意味ではありません。 逆に「対応不可と明記」は、ベンダーがはっきり書いたものです。この2つを分けておくと、比較表の空欄がすべて質問に変わります。

4行目がいちばん起きやすい失敗です。 機能対応表に「○」とあり、本文の別の章に「本機能はアドオン開発にて対応」と書かれている提案は珍しくありません。表の記号と本文の説明が食い違うときは、本文を根拠にし、食い違いそのものを質問にします。

指示内容を固定する

あなたは製造業の情報システム部で、システム更新の提案書を読み比べる担当です。
このノートブックの参照だけを使ってください。Webの情報や、参照にない知識で補わないでください。

【やること】
要件一覧の要件ごとに、各社の提案書の記載を読み、次の区分のどれか1つを選び、
記載の要約を1〜2文で書いてください。根拠にした文書名とページを必ず添えてください。

【区分】
- 標準機能 ........ 追加の開発や設定なしで対応すると書かれている
- 設定で対応 ...... パラメータや画面の設定で対応すると書かれている
- 追加開発 ........ カスタマイズ、アドオン、個別開発で対応すると書かれている
- 代替案 .......... 要件とは別の方法で同じ目的を満たすと書かれている
- 対応不可と明記 .. 対応しない、範囲外と書かれている
- 記載なし ........ 参照のどこにも、その要件に当たる記載が見つからない
- あいまい ........ 記載はあるが、上のどれに当たるか決められない

【厳守事項】
- 記載が見つからない要件は「記載なし」にしてください。対応できる・できないを推測しないでください。
- 機能対応表の「○」だけを根拠に「標準機能」にしないでください。
  本文に説明があればそちらを根拠にし、表と本文が食い違うときは「あいまい」にして、
  食い違いの内容を書いてください。
- 金額は書かれているとおりに写してください。合計、総額、年額への換算をしないでください。
  「別途」「含まない」「前提とする」と書かれた条件は、金額と同じ行に必ず写してください。
- 評価の点数、順位、おすすめのベンダーを書かないでください。
- 根拠の文書名とページが示せない要約は書かないでください。

【質問の案】
「記載なし」「あいまい」と、前提条件が要件一覧と食い違う項目について、
各社に送る質問の案を1項目1問で書いてください。要件番号を先頭に付けてください。
質問は、はい・いいえで答えられる形か、数値で答えられる形にしてください。

【参照する要件一覧】/要件一覧_第3版.docx
【区分の定義】/評価の観点の説明.docx

「参照だけを使う」と「Webの情報で補わない」を両方書いているのは、ノートブックの外へ出させないためです。 ベンダーの製品は公開の製品ページにも機能が書かれており、何も言わなければ、提案書に無い機能をそこから補って「標準機能」にします。比べたいのは製品の機能ではなく、提案書に書かれた約束です。

「金額は書かれているとおりに写す」は、費用の行を比較表の計算式につなぐための指示です。 月額と年額を勝手にそろえられると、比較表の計算式でもう一度12を掛けてしまう事故が起きます。単位は単位のまま写させ、換算は比較表で1回だけ行います。

出力形式を固定する

比較表は、要件ごとに1行、ベンダーごとに列を持つ表で受け取ります。 Word の Copilot で下書きを作るときも、ノートブックで受けるときも、同じ列にそろえます。

【要件ごとの対応の比較】
| 要件番号 | 区分 | 要件 | A社 | A社の根拠 | B社 | B社の根拠 |
| R-012 | 必須 | 帳票をCSVで出力できる | 標準機能：全帳票をCSV出力可 | A社_提案書_本文 p.34 | 記載なし | － |
| R-013 | 必須 | 帳票の出力権限を部署ごとに設定できる | 追加開発：権限制御はアドオンで対応 | A社_提案書_本文 p.35 | 設定で対応：ロール設定で可 | B社_提案書 p.22 |

【費用の拾い出し】
| ベンダー | 項目 | 金額 | 単位 | 数量 | 含まれない・前提とする条件 | 根拠 |
| A社 | ライセンス | 1,200,000 | 年額 | 100ユーザー | 101ユーザー目からは別途 | A社_見積明細 1行目 |
| A社 | データ移行 | 記載なし | － | － | 「別途お見積り」 | A社_提案書_本文 p.61 |

【各社への質問】
| ベンダー | 要件番号 | 質問 | 理由 |
| B社 | R-012 | 帳票のCSV出力は標準機能で対応できますか。 | 提案書に記載が見つからない |
| A社 | R-013 | 機能対応表は○ですが、本文ではアドオンとあります。追加の費用は見積に含まれますか。 | 表と本文の食い違い |

1つ目の理由は、根拠の列で確認が速くなることです。 主担当は、要約を読んで違和感のある行だけ、根拠のページを開けば済みます。根拠の列が空の行は、それだけで疑ってかかれます。

2つ目は、区分の語を固定しておくと、比較表の上で数えられることです。 「必須要件のうち追加開発がいくつあるか」「記載なしが何件か」を、表計算の集計で各社ごとに出せます。選定会議の最初の論点が、この件数になります。

3つ目は、費用を単位のまま受けることで、計算を1か所に集められることです。 年額・月額・一括を混ぜずに写しておけば、5年間の総額は比較表の計算式で出せます。前提条件の列が空でない行は、条件をそろえるための質問を必ず添えます。

システムへ連携する

API の連携はありません。 この構成は、Copilot の画面で読ませ、Word で下書きを受け、人が確かめて共有する流れです。月12件の提案書なら、自動化の仕組みを作るより、画面の操作で回すほうが早く始められます。

Word の Copilot では、プロンプトの入力欄で / を入力してファイルを選ぶと、そのファイルを参照させられます。 公式のページの説明では、特定の情報源を使うときは / を入力してファイルを選ぶとされています。ノートブックで作った要約の文書と、比較表のひな形を指定して下書きを作ります。

ベンダーへの質問の送信は、人が行います。 質問の文面は、送る前に購買の担当者にも見せます。選定中のベンダーとのやり取りは、公平さが問われるからです。 1社にだけ詳しい質問を送ると、その会社にだけ提案を直す機会を与えることになります。

人が確認する

比較表のすべての行を人が確かめます。 ただし、確かめ方に濃淡を付けます。

1. 必須要件の行を最初に見る … 区分と要約が根拠のページと合っているかを、ページを開いて確かめます
2. 「標準機能」の行を疑う … 本文に追加開発の記載がないかを見ます。選定の結論に最も効くのは、この区分の誤りです
3. 「記載なし」の行を確かめる … 提案書の目次から、該当しそうな章を自分でも探します。見つかれば、質問を送らずに済みます
4. 費用の行を計算式に移す … 単位と前提条件を確かめてから転記します
5. 質問を取捨する … 同じ趣旨の質問をまとめ、全社に同じ粒度で送ります

2番目を省かないでください。 「標準機能」と読み違えた要件は、契約後に追加開発の見積として戻ってきます。比較表の誤りの中で、後から最も高くつくのがこの型です。

目標は、1社分の確認を90分に収めることです。 必須要件と「標準機能」の行を丁寧に見て、任意要件は根拠の列を流し見ます。90分を大きく超える案件は、要件一覧の分け方か、提案書の形式に原因があります。

例外に対処する

上の2行が大半を占めます。 どちらもAIの問題ではなく、提案書の受け取り方の問題です。 RFPの段階で「提案書は文字の入ったPDFで、機能対応表は表計算のファイルで提出すること」と書いておけば、ほとんど起きません。

記録を残す

• 案件ごとのノートブックと、そこで使った参照の一覧（文書名と版）
• 比較表の下書きと、人が確かめた後の版
• 人が区分を直した記録 … どの要件の、どの会社の区分を、何から何に変えたか
• 各社に送った質問と、届いた回答の対応
• 選定会議で使った比較表の最終版

3つ目の記録を残すのは、AIの癖を知るためです。 「標準機能」を「追加開発」に直した件数が多ければ、指示の書き方を変えます。直した記録が無いと、毎回同じところで同じ確認をすることになります。

ノートブックを消すときは注意します。 公式のページでは、Copilot のページやノートブックの削除は現時点で取り消せないとされています。選定の経緯を後から説明できるよう、比較表と質問の記録は案件のサイトに残してから消します。