入札・提案書の要求事項に対する記載漏れを、提出前に点検する

処理の起点を決める

仕様書が案件フォルダに置かれたときと、提案書の版が置かれたときの2つが起点です。

Power Automate の SharePoint コネクタには「ファイルが作成されたとき」というトリガーがあります。案件ごとのフォルダを作り、01_仕様書 と 02_提案書 のサブフォルダに置く運用にすれば、どちらの処理かを判別できます。

提案書側は、版が上がるたびに回してください。 完成してから1回だけ回すと、締切の直前に大量の未対応が出ます。 執筆の途中で回せば、埋めながら進められます。

半自動化では、次を追加します。

• 提出期限の3日前に、未対応の一覧を通知する
• 質問受付期限の2日前に、解釈が割れた要求事項を通知する

2つ目が効きます。 「この項目は必須なのか任意なのか」で迷ったものは、質問受付期間に発注者へ聞くべきものです。 期限を過ぎると聞けません。

入力データを集める

「点検の観点」を先に作ってください。

「用語の一致」を軽く見ないでください。 仕様書が「利用者」と書いているのに提案書が「ユーザー」と書いていると、評価者は対応関係を追いにくくなります。 評価は人が行います。

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

仕様書の構造化： Azure AI Document Intelligence のレイアウトモデル（prebuilt-layout）を使います。このモデルは、テキスト、テーブル、選択マーク、そしてタイトル・セクション見出し・ページヘッダー・ページフッターなどの論理的な役割を抽出します。

要求事項の抽出では、次の出力が効きます。

outputContentFormat=markdown を指定すると、抽出結果をMarkdownで受け取れます。 章立てと表の構造を保ったまま生成AIに渡せるため、この用途では扱いやすくなります。v4.0（2024-11-30 GA）では、表はHTMLのテーブルとして表現され、結合セルや複数行ヘッダーも表せます。 選択マークは☒と☐のUnicode文字で表現されます。

入力の制限を押さえてください。

• PDFとTIFFは最大2,000ページまで処理できます（Freeレベルでは最初の2ページのみ）
• ファイルサイズは有料（S0）レベルで500MB、Free（F0）レベルで4MB
• パスワードがかかったPDFは、提出前にロックを解除する必要があります
• 大きな文書では、pages クエリパラメータでページ範囲を指定して分けて処理できます

表が複数ページにまたがる場合は、送信前にPDFをページで分割し、分析後に1つの表としてまとめる方法が案内されています。要求事項の表が10ページ続くような仕様書では、この処理を入れてください。

提案書の読み込み： 提案書はPDFのまま Claude API に渡せます。1リクエストの上限は32MB、ページ数は最大600ページ（コンテキストウィンドウが1Mトークン未満のモデルでは100ページ）です。パスワードや暗号化のかかったPDFは扱えません。

大きなPDFは、Files API にアップロードして file_id で参照してください。 リクエストの本文を小さく保てます。

ページ数の上限に注意してください。 提案書が120ページ、仕様書の要求事項一覧が20ページなら、同じリクエストに両方を入れると140ページです。要求事項を分割して回す設計にしてください。

AIへ渡す前に整形する

1. ヘッダー・フッターの除去 … role が pageHeader pageFooter pageNumber の段落を外します
2. 章立ての復元 … sectionHeading から目次構造を作ります
3. 表の正規化 … 結合セルを展開し、項目と内容の対応を作ります
4. 要求事項の候補の抽出 … 「〜すること」「〜を行う」「〜を提出する」の語尾を持つ文を拾います
5. 書式要件の分離 … 数値（ページ、部数、ポイント）を含む文を別枠にします
6. 提案書の見出しの抽出 … 対応付けの手がかりにします
7. 分割 … 要求事項を50項目ずつに分け、ページ数の上限に収めます

1番目を入れないと、ページヘッダーの文字列が要求事項として何十件も出ます。 レイアウトモデルの role を使えば機械的に外せます。

4番目は候補の抽出であって確定ではありません。 表の中の要求事項は語尾を持ちません。表から抽出したものと、本文から抽出したものを分けて持ってください。

AIに処理させる

AIに次のことをさせないでください。

「要求事項を要約させない」ことが、この構成でもっとも重要な制約です。 「システムは24時間365日の稼働とし、計画停止は月1回4時間以内とすること」を「高可用性が必要」と要約されると、月1回4時間という条件が消えます。 原文をそのまま引用させてください。

「未対応箇所の文章を自動生成させない」も必ず入れてください。 提案書の空欄をAIが埋めれば、提出物に、社内の誰も内容を把握していない記述が混ざります。 指摘までにとどめてください。

指示内容を固定する

要求事項の抽出：

あなたは、入札仕様書から要求事項を洗い出す担当者です。
仕様書の構造化された内容から、要求事項を1件ずつ取り出してください。

【厳守事項】
- 要求事項は、仕様書の原文をそのまま requirement_text に入れてください。
  要約や言い換えをしないでください。
- 必須か任意かは、語尾を根拠として分類してください。
  「〜すること」「〜しなければならない」は必須、
  「〜が望ましい」「〜も可」は任意としてください。
  判断がつかないものは "判別不能" とし、
  根拠にした語尾を basis に書いてください。
- 仕様書に書かれていない要求事項を補わないでください。
  一般的な入札でよくある要件を、あなたの知識から追加しないでください。
- 要求事項の出典として、章・節番号とページ番号を必ず付けてください。
- 様式番号、ページ数の上限、フォント、部数、期限、押印の要否は、
  requirements ではなく format_requirements に入れてください。
- 表から抽出したものは source_type を "table"、
  本文から抽出したものは "body" としてください。

【仕様書（構造化済み）】
{structured_spec}

対応付け：

あなたは、提案書が仕様書の要求事項に触れているかを点検する担当者です。

【厳守事項】
- 「要件を満たしている」「十分です」と書かないでください。
  触れている箇所を示すか、見つからないと書くだけにしてください。
- 提案内容を評価・点数化しないでください。
- 対応している箇所には、提案書のページ番号・見出し・
  該当部分の引用を必ず付けてください。
  引用を示せない対応付けは、covered にしないでください。
- 触れている箇所が見つからない要求事項は、
  not_covered に入れてください。
  「おそらく第3章で触れていると思われます」と書かないでください。
- 触れてはいるが記述が1〜2文にとどまる場合は、
  thin_coverage に入れてください。
- 仕様書の用語と提案書の用語が異なる場合は、
  term_mismatch に両方を入れてください。
- 未対応箇所を埋める文章を書かないでください。

【要求事項の一覧】
{requirements}

【提案書】
{proposal_document}

2つを分ける理由は、扱う文書が違うからです。 抽出は仕様書だけ、対応付けは両方を見ます。同じリクエストにまとめると、ページ数の上限に当たります。

出力形式を固定する

要求事項の抽出：

{
  "spec_id": "",
  "requirements": [
    {
      "req_id": "",
      "section": "",
      "page": 0,
      "requirement_text": "",
      "obligation": "必須 | 任意 | 判別不能",
      "basis": "",
      "source_type": "body | table"
    }
  ],
  "format_requirements": [
    {
      "kind": "様式 | ページ数 | フォント | 部数 | 期限 | 押印 | その他",
      "text": "",
      "value": "",
      "section": "",
      "page": 0
    }
  ],
  "submission_documents": []
}

対応付け：

{
  "spec_id": "",
  "proposal_version": "",
  "checked_at": "",
  "covered": [
    {
      "req_id": "",
      "proposal_page": 0,
      "proposal_heading": "",
      "quoted_text": ""
    }
  ],
  "not_covered": [],
  "thin_coverage": [],
  "term_mismatch": [
    {
      "spec_term": "",
      "proposal_term": "",
      "proposal_page": 0
    }
  ],
  "format_check": [
    {
      "kind": "",
      "required": "",
      "actual": "",
      "matched": false
    }
  ]
}

obligation に「判別不能」を持たせるのが、この構成の要です。 「〜に配慮すること」のような語尾は、必須とも任意とも読めます。判別不能のものは、質問受付期間に発注者へ確認すべき候補です。 無理に必須か任意かに寄せると、確認する機会を失います。

covered には引用を必須にしてください。 引用のない対応付けは、対応付けになっていません。 「第3章で触れています」だけでは、確認できません。

thin_coverage は、未対応と同じくらい重要です。 「触れてはいる」状態は、点検をすり抜けます。評価では点が付きません。

format_check の matched は、機械的に照合できる項目だけを持たせてください。 ページ数と部数は数えられます。フォントや余白は、文書の設定から取るかどうかを決めてください。

システムへ連携する

最小構成では連携はありません。仕様書と提案書を生成AIに貼って作業します。

半自動化では、次をつなぎます。

提案書の内容を自動で書き換えないでください。 点検の結果として文章が自動で挿入されると、誰も読んでいない記述が提出物に入ります。

期限のカレンダー登録は自動化してよい部分です。 質問受付期限、提出期限、開札日は、仕様書から機械的に取れます。

人が確認する

要件を満たしているかの判断は、必ず提案の責任者が行います。

5番目を省かないでください。 抽出された一覧が仕様書の要求事項を網羅しているかは、AIの出力からは分かりません。 「拾えなかった項目」は、出力に出ません。目次と章立てを見て、抜けている節がないかを人が確かめてください。

2番目は、期限のある確認です。 質問受付期間を過ぎると、発注者に聞けません。提案書の執筆より先に、この確認を済ませてください。

例外に対処する

記録を残す

• 仕様書の構造化結果
• 要求事項の一覧（原文の引用を含む）
• 取りまとめ担当が補正した内容と、補正前後
• 提案書の版ごとの対応付け結果
• not_covered の推移（版が上がるごとに減っているか）
• 判別不能 として発注者へ質問した内容と、その回答
• 書式要件の照合結果
• 提出後の結果（落札・失注・失格の別と、分かれば理由）

「not_covered の推移」を残してください。 版が上がるごとに未対応が減っていく様子が見えれば、締切前の慌ただしさが数字で管理できます。

「提出後の結果」を必ず紐づけてください。 失格や不備の指摘があった場合、その項目がこの点検で挙がっていたかどうかが、この構成の実効性を測る唯一の指標です。

発注者への質問と回答を残してください。 同じ発注者の次の案件で、同じ論点が出ます。