procurement-offer-review

/procurement-offer-review — サプライヤーの提案をレビューし、パックの整合性を保つ

調達の受け入れ側を担うスキルです。IPPF ToR に対するサプライヤーの技術的・財務的提案が届いたら、このスキルで内容を確認してコメントし、判断に変更があった場合は内部パック（ToR、免除の正当化資料、ベストバリューの記録、調達チェックリスト）の整合性を保ち、複数入札者の評価でスコアを比較します。ToR の作成を担う上流側のスキルは tor-procurement です。

モードの振り分け

• OFFER-REVIEW — 提案または改訂提案が届いた場合に使います。ToR および、以前のコメントラウンドがある場合はその内容との整合性を確認します。ベンダーのファイルは読み取り専用です。必要に応じて _COMMENTS コピーを作成します。
• PACK-PROPAGATE — 調達に関する判断（契約主体、予算額、構成、日程）に変更があった場合に使います。すべてのパック文書に変更を一貫して反映します。
• SCORE-COMPARE — スコアリング用ワークブックを使った複数入札者の評価に使います。評価者と AI の比較を作成するか、リンクします。

モードが明確でない場合は、作業を始める前に1行で確認してください。

共通ルール — すべてのモードに適用

• ベンダーのファイルは絶対に編集しないでください。 提案書はサプライヤーの文書です。コメントは <original>_COMMENTS.docx という名前のコピーに記入します。分析はチャットまたは内部メモに記載します。提案書が PDF の場合、コメントはチャットのレポートに記載します（PDF はベンダーの確定記録です。これは問題ではなく利点です。古い余白コメントが残ることも防げます）。
• 事実の信頼性。 数値、組織名、SIREN/VAT 番号、日付、承認を捏造したり、概算で示したりしてはいけません。レポートに記載するすべての数値は、文書名または確認元を明示できるものとします。不明点は不明点として報告します。
• ⚠ 財務部への確認に関するルール。 このスキルは、CERV、VAT、再委託、調達マニュアルへの準拠を断定しません。文書に記載された内容を述べ、矛盾点を明示し、⚠ Finance to confirm: [question] として確認事項を提示します。準拠性の判断は、財務部と免除承認者が行います。
• 原本を保持してください。 内部パック文書に手を加える前に、そのタイムスタンプを記録します。パックの命名規則に従って、バージョン付きまたは接尾辞付きのコピーを書き込みます。Ane はセッション中にパックのファイルを手動で編集したり、名前を変更したりします。編集の直前にフォルダーを再度一覧表示し、各ファイルを読み直してください。以前読み取った内容を使って編集してはいけません。
• OneDrive の復元に関する注意。 Git 管理されていない OneDrive フォルダーでは、同期によって、書き込んだばかりの内容が数秒以内に気付かれないまま元に戻されることがあります。ファイルを書き込んだ後は、変更した行を読み直して、内容が反映されたことを確認してください。Git 管理されたフォルダーでは、1つの処理ブロック内で書き込みとコミットを行います。
• docx のテキスト、変更履歴、コメント XML、PDF のテキスト、openpyxl の数式などの抽出方法は、references/docx-xlsx-mechanics.md に記載されています。コメント、docx の直接編集、ワークブックの数式を書き込む前に、これを読んでください。

エビデンスカード — 評価基準ごとの要約（OFFER-REVIEW と SCORE-COMPARE）

どちらの評価モードでも、ToR の要件または採点基準ごとにエビデンスカードを 1 枚作成します。委員会のメンバーが読むのは、分類でもスコアでもなく、このカードです。

ToR を作成しておらず、調達対象の専門家でもない人に向けて、すべてのカードを作成してください。ほとんどの調達委員会のメンバーがこれに当てはまります。対象が MEL ではなく IT の場合は、アネも例外ではありません。カードのない分類は評価結果ではありません。出典箇所のないカードはエビデンスではありません。

カードは単独で依頼することもできます（「各基準のエビデンスをまとめてください」）。既存の採点ワークブックやレビューをもとに作成することもできます。

6 つのフィールドを次の順番で記載します。

1. これは何を求めているか。 平易な英語で 1 文にまとめます。ToR の参照先は末尾の角括弧内に記載し、冒頭には置きません。
2. なぜ重要なのか。 入札者がこの点で不十分な場合に生じる業務上の影響を、1 文で示します。この契約に即した内容にしてください。一般的なリスクの説明では、このフィールドを満たせません。
3. 入札者は何を提案したか。 該当箇所（セクションまたはページ）を添えてエビデンスを記載します。正確な文言が判断を左右する場合は、判断の根拠となるフレーズを引用してください。
4. 何が不足しているか、または不明確か。 不足している点を明確に示します。「記載なし」も正当で有用な記述です。
5. 判断。 met／partial／missing／diverges、またはテンプレート独自の評価尺度におけるバンドラベル付きのスコアを記載します。
6. 何があれば判断が変わるか。 これがあれば評価が 1 段階上がるという具体的なエビデンスを示します。これにより判断を検証可能にし、入札者に送る確認質問としても使えます。

カードの言語ルール。 ティア 1 の作業概要とし、読み手は専門家ではなく同僚を想定します。

• すべてのカードで、略語をすべて正式名称で記載します。カードは順不同で単独でも読まれます。
• 技術用語は、カード内で初めて使うときに 6 語以内で説明します。
• 影響は業務上の言葉で説明します。「ベンダーロックインのリスク」よりも、「契約終了時に自分たちのデータを取り出せなくなる可能性があります」と書きます。
• ラテン語由来の動詞より、英語本来の動詞を使います。utilise ではなく use、facilitate ではなく run、ascertain ではなく check を使います。
• 文は 25 語未満とし、能動態で、行為者を最初に置きます。

厳守するルールが 2 つあります。

• フィールド 2 は、ToR に理由が記載されている場合、その理由に基づいて記載します。 記載がない場合は、カードに (rationale inferred, not stated in the ToR) と記載します。独自の推測を ToR の意図として示してはいけません。
• フィールド 3 のすべての主張には出典箇所を付けます。 出典箇所のない主張はカードに記載しません。

提出前の読み手テスト。 カードを 1 枚選び、ToR を一度も開いたことがない委員会のメンバーが、何を求められているのか、なぜ重要なのか、なぜこの入札者がその評価になったのかを理解できるか確認します。理解できなければ、そのカードは不合格です。修正するのはフィールド 1 またはフィールド 2 です。フィールド 3 にさらに詳細を加えることが解決策になることは、ほとんどありません。

OFFER-REVIEW モード

入力：提案書（docx または PDF）、その提案書が回答する ToR、そして再提出の場合は Ane の前回のコメント一式（余白コメントおよび／または変更履歴。交渉の経緯が記録されているため、docx の XML から両方を抽出してください）。

1. 判断を始める前に、3つの資料をすべて抽出してください。 再提出の場合は、Ane が前回求めた事項の一覧を作成します。余白コメント1件、または変更履歴の挿入1件を、それぞれ1つの依頼として扱います。
2. ToR を条項ごとに確認してください。 ToR の要件（業務範囲の項目、成果物、予算項目、知的財産権と引き継ぎ、VAT の申告、セーフガーディング、報告）ごとに、エビデンスカードを作成します。充足／一部充足／未充足／相違の分類はカードのフィールド5であり、回答全体ではありません。ToR に根拠のない提案内容は別途記録してください。新たな業務範囲の項目は、特にセキュリティやアクセスモデルに関わるものについて、明示的に受け入れる必要があります。
3. 計算を自分で確認してください。 すべての合計を再計算します。日数×単価、VAT（税抜額×税率＝税込額）、予算項目の合計、承認額に対する上限額のすべてを確認してください。表の数値と表紙の数値が一致しないのは、よくある転記ずれです。最初に見つけた数値だけでなく、すべての数値が記載されている箇所を確認してください。
4. 前回のやり取りを検証してください。 Ane が前回求めた事項ごとに、対応済み／一部対応／未対応を判定します。未対応の項目は注記ではなく指摘事項です。これらは交渉上、未解決の論点です。
5. 既知の落とし穴に注意してください（それぞれ、実際のレビューを1ラウンド余計に要する原因になります）。ToR では譲渡が求められているのにライセンスが付与されている。ライセンスの範囲がひそかに狭められている（「X ネットワーク内」など）。前払いの条件が ToR と提案書で異なる名称になっている。支払いスケジュールはそのままで成果物の納期が変更されている。安全面への影響が明記されていない延期項目がある（例：承認ゲートのない提出物）。ホスティング／保守が暗に示されているものの、確約されていない。
6. 未解決の論点は、修正コストが低い順に並べてください。 順序は次のとおりです：（a）契約上の優先順位 — 再発行は不要で、どの文書が優先されるかを契約に明記する。（b）メールでの1行の書面確認。（c）ベンダーによる再発行 — 署名者や監査担当者に誤解を招くおそれがある誤りに限って行います。再発行の回数を最小限にすることも重要です。再発行のたびに1週間かかります。
7. BLUF 形式で提出してください。 最初に判定文（整合／N件の未解決事項を伴う整合／不整合）を示し、次に対応済みの事項（項目ごとに確認済みであることを明記）、続いて未解決の論点を重大度と修正方法とともに番号付きで記載し、その後に良い点（業務範囲の拡大、解決済みの項目）を示します。各要件に対するエビデンスカードは付録として後に続け、提案書を読まなくても、個々の判断を確認できるようにします。修正方法を反映した返信文案の作成を申し出てください。
8. 余白コメント（依頼があった場合のみ。docx 形式の提案書に限る）。 scripts/add_offer_comments.py を使って、_COMMENTS コピーに対象箇所を特定したコメントを記入します。各コメントは、該当する段落に正しく紐づけてください。誤った段落に紐づけるくらいなら、コメントを付けない方がましです。

PACK-PROPAGATE モード

1つの決定を複数の文書に反映します。このモードが想定する失敗パターンは、数値や組織名が3つのファイルで変更されたのに4つ目には気付かれずに残っていたり、段落全体の置換で誰も気付かないまま2文が抜け落ちたりすることです。

1. 編集前に、決定内容を1行で明記します。旧値 → 新値と、それを記載している文書を示します。決定が明示されておらず、暗示されていた場合は、Aneに確認します。
2. 対象一式を一覧化します。 フォルダーのファイル一覧を改めて取得します（ファイル名は変わることがあります）。次に、対象一式のすべての文書から旧値の出現箇所をすべて検索します。派生形も含めます（税抜額から算出したVAT込みの金額、名称変更後の組織の旧略称、フッターに残った古い日付など）。
3. 必要最小限の範囲をその場で編集します。 対象ファイルがある場合は、mel_wiki/wiki/concepts/edit-preservation-protocol.mdを適用します。最初に読み、範囲を限定して編集し、変更箇所以外はバイト単位で完全に保持します。docxの場合は段落のテキストを照合し、必要最小限のランだけを書き換え、Aneによる手編集を保持します。1つの数値を変更するために段落全体を置換してはいけません。編集前後の文数を数えます。一致しない場合、内容が抜け落ちています。
4. 残存箇所を検索します。 すべての編集後、対象一式の各文書からテキストを再抽出し、旧値と派生形をもう一度検索します。ファイルごとに、変更済み（N箇所）／すでに最新／⚠ 残存箇所あり、のいずれかを報告します。この検索結果が成果物です。検索を伴わない編集では作業は半分しか完了していません。
5. 判断せず、フラグを付けます。 コンプライアンスに関わる記述（調達基準額、免除の根拠、VATの扱い、ドナーの規則）に触れる編集には、機械的な編集であっても、報告書に⚠ Finance to confirmフラグを付けます。

SCORE-COMPARE モード

採点ワークブックを使った複数入札者の評価向けです（評価者の作業用マトリックス＋正式な評価フォーム）。実証済みのパターンです。数式と注意点については、references/docx-xlsx-mechanics.md § Workbookを参照してください。

1. まず、単一の信頼できる情報源を設定します。 正式なフォームの採点セル（およびベンチマークを複製したシートがあればそのシート）を数式で評価者の作業用Evidence Matrixにリンクし、スコアを一度編集するだけで依存するすべてのシートに反映されるようにします。リンクする前にシートを差分比較します。 作業用シートの修正が気付かれないままあると、リンクした瞬間に正式なスコアが変わります。差異を明らかにし、事前にワークブックをバックアップします。
2. Comparisonタブ： 基準ごとに評価者／AI／差分を横並びで表示し、合計点、順位、しきい値一致列も含めます。フラグのルールはテンプレート独自の評価区分に基づきます。赤＝差分が基準の最大点の20％以上（1区分分）または合計10点以上、アンバー＝10～19％（または合計5～9点）です。しきい値の不一致と3位以上の順位変動には、別個のフラグを付けます。値を貼り付けるのではなく、ライブ数式と条件付き書式を使用します。
3. 数値とあわせて評価カードを表示します。 Comparisonタブでは、評価者とシステムの相違箇所を示します。相違の理由は示しません。数値だけを見た委員会は、どちらのスコアも検証できません。Criterion cardsシートを追加し、基準ごとに1行を設けて、6つのカード項目を列として表示します。折り返し表示にし、Comparisonタブと一致する基準IDを付けることで、赤い差分セルから、その根拠を1回の検索で確認できるようにします。評価者とシステムの判断が異なる場合は、6番目の項目に、判断を確定するために必要な証拠を記載します。
4. 比較結果は判断の参考にし、最終判断は評価者が行います。 AIのスコアで評価者のスコアを上書きしてはいけません。タブは相違を確認するためのものであり、確認するのはAneです。

範囲の境界

• ToR自体の起草や採点は上流のtor-procurementが担当します。契約締結後の追跡はimplementation-packが担当します。ドナー向けの提案書は/proposalが担当します。
• 契約書の起草、署名の取りまとめ、各⚠フラグの根拠となるコンプライアンス上の判断は、Finance、予算責任者、免除承認者が担当します。
• 内部向けパック文書は内部文書です。Tier 1の登録対象ですが、外部公開用のクレジット表記は必要ありません。レビュー結果をサプライヤーに送付する場合（コメント入りコピー、返信メール）は、Aneの口調にします。協調的で具体的、かつ曖昧な表現は避けます。