selection-toolkit

/selection-toolkit — 評価委員会が採点するためのツール

役割はひとつです。選定を実施し、評価委員会にはそのためのワークブックが必要です。公示から落札者決定までの間をつなぎます。/tor-procurement はToRを作成して終了し、procurement-offer-review は入札後に個々の提案書を読み込みます。このツールはその間を担います。

すべてを支配するルール

何も創作しません。 すべての基準、配点、しきい値、日付は、出典ドキュメントから取得するか、Aneが解決するギャップとして報告します。デフォルトの配点は、セルに入力された時点で公表済みの配点と区別がつかなくなり、評価委員会は気づかないまま6週間それに基づいて採点します。validate_spec は穴のある仕様を拒否し、read が穴を埋めることもありません。

このスキルを使うユーザー向けに何かを書く際は、次の2つのルールを守ってください。

1. 採点には、出典に公表された基準のみを使用します。 公表しておくべきだったと評価委員会が考える基準は、次回のToRに活かす教訓であり、このワークブックの列にはしません。
2. 配布または採点に使用された後は、これらのファイルを再生成せず、その場で編集します。 まさにこの理由から、build は既存のツールキットの上書きを拒否します。返却された採点者ファイルのスコアは、ほかの場所には存在しません。

コードの場所

Office関連の処理はすべて ane_package にあります。このスキルが担うのは判断であり、処理の基盤ではありません。

• ane_package.reporting.selection_toolkit — 仕様、採点エンジン、2種類のワークブックビルダー。
• ane_package.officeops.document_tables — ToRの表を、空欄を保持したグリッドとして読み込みます。
• scripts/selection_toolkit.py — ドライバー：表の採点、配点の解析、しきい値の読み取り、仕様の組み立て、検証。

責任範囲を明確にしておきます。議論の余地はありません。Officeファイルを開く処理はすべてモジュールに属します。 ドライバーでドキュメントを開く呼び出しは、ちょうど2つです。ToRにある5つの表のうち、どれが落札基準なのかを判断することや、"up to 35 points" から 35 を取り出すことはテキスト処理であり、ドライバーが担います。

Officeコードを書く前に office-repair 内の references/officeops-excel-api.md を読み、各モードによって何が変わるかについては、ここにある references/modes.md を読んでください。

実行方法

1. 出典を読み込む

python scripts/selection_toolkit.py read "path/to/ToR.docx" --out selection-spec.json

見つかった基準、それぞれの配点、すべてのギャップが出力されます。ギャップはAneに確認してください。ToRが答えていない質問です。よくある例：評価委員会のメンバー（ToRには記載されません）、適合性チェック、タイトル、ToRに「70%」と「60 points」の両方が記載されている場合の曖昧なしきい値です。

ギャップを自分で解決してはいけません。ToRに配点が記載されていない場合は、確認してください。類似の調達案件を参考に推測してはいけません。

2. Aneと仕様を埋めてから、_gaps を削除する

仕様ファイルは、「この基準の配点が35なのはなぜか」を示す監査証跡です。ワークブックのそばに保管してください。_gaps が残っている間、build は処理を拒否します。また、削除後も実際の値が不足していれば validate_spec が処理を拒否します。ギャップリストを削除しても、穴をすり抜けさせることはできません。

調達以外の比較では、mode を appraisal に設定してください。詳しくは references/modes.md を参照してください。

3. 作成する

python scripts/selection_toolkit.py build selection-spec.json --out "3 Selection toolkit"

selection-master.xlsx と、評価委員会のメンバーごとに scorer-<name>.xlsx を作成します。共有ワークブックは使わず、ファイルを分けてください。独立した採点こそ、評価委員会の平均を算出する意味を保つ仕組みです。共有ファイルでは、2人目が開いた時点でその仕組みが失われます。

4. 実行による検証 — スキルの真価が問われる工程です

python scripts/selection_toolkit.py verify "3 Selection toolkit" --spec selection-spec.json

ワークブックをコピーし、Excel COM を通じて応募者とスコアのサンプルを入力してから、完全な再計算を強制します。そのうえで、計算された平均値、しきい値、財務スコア、順位が、数式の作成に使用したものと同じエンジンで算出した値と一致することに加え、数式エラーのセルがゼロであることを検証します。

見た目は正しくても計算が間違っているワークブックが、ここで想定される失敗パターンです。これを検出できるのは実行による検証だけです。 数式を読み戻して確認できるのは、書き込んだ数式がその数式であることだけです。検証はコピー上で実行されるため、サンプルデータが進行中の調達記録に書き込まれることはありません。

Excel を使用できない場合、コマンドは 2 で終了し、ワークブックが検証されていないことを示します。その場合は未検証として報告してください。未検証のワークブックを検証済みとして提示しないでください。

5. 出力をコミットする

編集保持ガードは Excel COM や openpyxl による書き込みを検知できないため、出力されたファイルを手動編集されたものとして警告します。変更を未コミットのまま残さず、最後の手順としてコミットしてください。

マスターワークブックの内容

00 DASHBOARD（自動計算、入力不可）、01 Read me（作業の順序）、02 Applicants、03 Questions log、04 Q&A to publish、05 Stage 1 Compliance、06 Score inbox（採点者から返却されたファイルをここに貼り付けます）、07 Stage 2 Technical（パネルの平均値、ばらつき、適格性）、08 Stage 3 Financial、09 Stage 4 Interview、10 Conflict of interest、11 Decision log、12 Applicant feedback、98 REF（公開済みのパラメーター。監査証跡をファイルと一緒に保持します）。

ソースで定義されていないステージのシートは作成しません。

問題になりやすい点

1. 空欄は欠落であり、ゼロではありません。 一度も採点していない予備パネリストの回答をゼロとして扱うと、平均値が3分の1も下がってしまいます。panel_mean は空欄を無視し、AVERAGE の数式もそれに合わせてあります。採点者ファイルの空欄を 0 で埋めて「整理」してはいけません。
2. 計算される各セルは、それぞれ自身の空欄をチェックします。 初日に引き渡されたワークブックは空であり、#DIV/0! が並ぶシートは、入力待ちではなく壊れているように見えます。これにより、「数式エラーのセルがゼロ」というチェックが、単なる同語反復ではなく実際に意味のある確認になります。
3. 手順は、コンプライアンス、次にゲート審査、その後に採点です。 非準拠の入札を採点してから除外するのは、パネルが自ら例外を正当化することにつながります。
4. 大きなばらつきはシグナルであり、エラーではありません。 ワークブックは、ばらつきがトリガー以上の場合に色を付けます。パネルで議論し、誰もひそかに平均化して消し去りません。
5. ToR が英語とは限りません。 ヘッダーの照合、しきい値の文、日付の解析は、英語、フランス語、スペイン語、ルーマニア語、ドイツ語のアクセント記号を考慮してあります。英語のみを対象とするチェックをフランス語の ToR に適用すると、基準表が見つからず、文書の実態ではなくパーサーに起因する不足が報告されます。これは Waves 4 と 5 で、すでに3回問題になっています。
6. 「Criterion」という見出しの列には、コードが入っていることがよくあります。 基準そのものは「Description」の下にあります。見出し語だけで照合すると、各基準がすべて「C1」「C2」とラベル付けされます。番号は正しくても見出しは役に立たず、エラーも発生しません。is_code_column がこれを防ぎます。このチェックを削除しないでください。
7. 価格は 02 Applicants から読み取られるため、そこで価格を修正すれば、依存するすべてのスコアに反映されます。 財務シートを直接上書きしても何も起きません。保護されているためです。
8. 返却された採点者ファイルをマスターに統合するには、読み戻しを伴う COM 処理が必要であり、ガードがコミットを妨げます。 Excel COM を通じて書き込んでください（openpyxl で保存すると、ワークブックの拡張データ検証が失われます）。最初に空であることを確認したセルだけに書き込み、再度開いて再計算したワークブックで検証してください。確認するのはマスター自身の合計とタブ 07 の平均であり、書き込み呼び出しがエラーなく返ったことではありません。編集保護ガードは COM による書き込みを検知できないため、その後は、いずれかのファイル名を指定する Bash または PowerShell コマンドをブロックします。これには、ガード自身が修正方法として指示する git commit も含まれます。Write ツールでスクラッチパッドにスクリプトを書き、ファイル名だけを指定して実行し、コミットしてください。また、先に同じ方法で成果物の統合前の状態もコミットしてください。これにより、マスターに手を加える前に、採点者から返された内容が git に含まれます（2026-10-13 の同一セッションで3回実証済み）。

対象外

ToR の作成（/tor-procurement）、届いた提案書1件の分析（procurement-offer-review）、IPPF が送付する提案書の採点（donor-proposal-scoring）、IPPF の基準に照らした加盟協会の評価（accreditation-desk-review）は行いません。落札者も決定しません。評価用のツールを作成し、判断はパネルが行います。