donor-proposal-scoring

/donor-proposal-scoring — ドナーの評価基準に照らして提案書を採点する

目的は一つです。すでに作成された提案書を受け取り、ドナーの評価者が何点を付けるか、その理由とともに示します。提案書の作成には /proposal を、サプライヤーの提案の評価には procurement-offer-review を使います。これは申請者側の視点から、自らの提出書類をドナーの目を通して確認するものです。

モードの振り分け

• SCORE（デフォルト）— 募集要項と提案書がそろっている場合に使います。評価基準ごとの評価、スコア、根拠、スコアの幅、優先順位付きの改善リストを作成します。
• CALIBRATE — ドナーの評価サマリーレポート（ESR）が届いており、以前の採点結果もある場合に使います。両者を比較し、その差から学びます。

両方の文書があり、Ane がモードを指定していない場合は、1行で確認してください。ドナーの評価資料を先に読んで SCORE の出力に反映してはいけません。先に読むと検証の意味が失われます。

まず最初に確認する2点

これはブラインドテストですか、それとも実務上の助言ですか？ 読む順序が正反対になります。

• ブラインドテスト（ESR があり、手法を検証することが目的の場合）：ESR を開いてはいけません。「形式だけ確認する」ために開くのも禁止です。まず採点結果をディスクに書き込み、その後で比較してください。
• 実務上の助言（提出または再提出の前に提案書を修正する場合）：同じドナーによる過去の ESR をすべて先に読んでください。ドナーの評価スタイルは学習でき、精度向上のために最も手軽に活用できます。このドナーが称賛した点、常に求めていた点、こちらから促さずに言及した対象者、決して触れなかった事項を確認してから採点してください。

誰の提案書ですか？ 申請者が IPPF または Ane の所属チームである場合、これは一部が自己評価となり、構造上、独立性に限界があります。そのことは脚注ではなく、冒頭の注記で出力に明記してください。提案書を検索して Ane の名前があるか、また、どのような役割で記載されているかを示してください。組織の意図について知っていることではなく、募集要項の文言に基づいて採点してください。

共通ルール — 両モード

• 評価基準の根拠は募集要項のみです。 同じ募集の前年の基準、申請書の記入要領、記憶を根拠にしてはいけません。募集要項は年ごとに文言、配点、閾値が変わるため、記憶に基づいて持ち込んだ評価基準は捏造したものです。募集要項がない場合は、そのことを伝えて作業を中止してください。内容を再構成してはいけません。
• 事実の信頼性。 スコアに関する主張にはすべて、根拠とする提案書のセクションまたはページを明記してください。評価基準に関する主張にはすべて、募集要項のページを明記してください。特定できない数値は不足情報として報告してください。予算項目、閾値、日付を決して推測してはいけません。
• ドナーの見解を捏造しないでください。 出力では、募集要項が評価する内容と、提案書に記載されている内容を示します。それを「したがって評価者は減点するだろう」と結論付ける部分が推測であれば、推測であることを明記してください。
• Tier 1 の実務向け概要。 読者は経営陣または提案書の責任者であり、評価の専門家ではありません。BLUF、平易な英語、略語は初出時に正式名称を記載し、本文ではフレームワーク名をむやみに挙げないでください。引用は末尾の **Evidence base:** 行にまとめてください。
• 編集内容の保持。 対象ファイルがすでに存在する場合は、mel_wiki/wiki/concepts/edit-preservation-protocol.md を必ず適用してください。Ane が採点結果またはその Word 版を手作業で編集した時点で、生成処理は古くなっています。「更新」のためにビルダーを再実行せず、Ane のファイルを直接編集してください。
• OneDrive。 git フォルダーでは、書き込みとコミットを同じブロック内で行ってください。通常の OneDrive フォルダーでは、書き込み後に変更した行を読み直し、反映されたことを確認してください。

---

SCORE モード

ステップ 0. ブラインド実行の衛生管理

何かを開く前に、提供された文書が入っているフォルダーの一覧を取得し、各ファイルを *ESR*、*evaluation*summary*、*evaluation*report* に照らして確認してください。該当するファイルがある場合は、出力でその名前を示し、開かないことを明記したうえで、採点開始前に実行対象の範囲外へ移動するよう提案してください。読むのを自制するだけでは管理策になりません。対象範囲内にあるファイルが読まれなかったことを、読者は検証できません。実演において、この確認可能性の欠如こそが、テストと単なる主張の違いです。

ステップ 1. グリッドを抽出し、採点を始める前に一覧にする

公募文書の採択基準に関するセクションを読みます。判断を示す前に、出力に以下を記載してください。

• すべての基準と、それぞれの最高点
• すべての個別の合格基準点と全体の合格基準点
• 公募要領に定められている場合は、同点時の優先順位
• 各基準が対象とする要素。公募要領の原文どおりに引用するか、原文に忠実に言い換えてください
• 合格が資金提供を意味するのか、それとも上限枠内に順位付けされることだけを意味するのか

これは厳格な順序制約です。理由は事務的なものではありません。採点は簡単に逆算できます。いったん合計点が妥当に感じられると、各基準の点数はその合計に合わせて歪められます。最初の採点を始める前に、グリッドをすべて公に書き出しておくことが、それを防ぐ方法です。また、公募要領では、評価者が別の基準に分類するような項目がある場合にも気づけます。これはよくある、かつ大きな損失につながる誤読です。

各要素の出典となった公募文書のページを明記してください。

ステップ 2. 文書を採点する前に、プログラムを採点する

次の順序で、2つのパスを実施します。この順序は、このスキルにおける最も重要な指示です。

パス A：プログラムの実質的な内容。 このプログラムは実際に何を、誰のために実施するのか。また、十分に検討されているか。

• 対象となる権利保有者と集団、および名前は挙がっているものの支援を受けない集団（ステップ 3）。
• 表明されたアプローチは設計に反映されているのか、それとも記載されているだけなのか（ステップ 4）。
• 各メカニズムを誰が運営し、どのような能力があり、担当者が離れた場合に何が起きるのか（ステップ 5）。
• 活動から変化に至るとされる道筋に信頼性はあるか。また、測定の枠組みはその変化を追跡しているか。
• 持続可能性についての回答になっているか、それとも整合性を言い換えているだけか。

パス B：文書の形式面。 内部の整合性、計算、セクションの配置、チェックリストへの字義どおりの準拠、添付資料の不足、予算項目の説明不足。

両方のパスから、実質的な指摘事項が得られます。しかし、ドナーの評価者が記述するのはパス A であり、資金提供を決めるのもパス A です。パス B の指摘事項は見つけやすく、厳密な評価をしたように感じられますが、実際の評価で誤りの大半を占めていました。キャリブレーション記録を参照してください。非公開のキャリブレーション記録があれば ${WORK_FOLDER_ROOT}/agent-improvements/private-calibration/donor-proposal-scoring/cerv-2026-worked-example.md を、なければ合成版の references/worked-example-synthetic.md を使用してください。

提出前のバランス確認。 指摘事項の数を数えます。半数を超えるものがパス B に集中しているなら、プログラムではなく文書を採点しています。パス A に戻ってください。この確認には 30 秒しかかからず、このスキルで最も効果の高い作業です。

ステップ 3. 権利保有者の対象範囲を確認する

公募要領にこれらの集団が明記されているかどうかにかかわらず、すべての提案に対して確認してください。権利と平等の分野に携わるドナーは、これらを標準的な確認項目として適用しており、評価フォームに専用のステータス欄を設けている場合も複数あります。

各集団について、名前が挙がっているか、アプローチが具体的に定められているか、モニタリングの枠組みで追跡されているか、個別のアウトリーチがあるかを確認します。対象集団の一覧に名前があるだけで、それ以外の箇所には登場しない場合、対象に含まれているのではなく、指摘事項となります。

子どもおよび国連「児童の権利に関する条約」・青少年の年齢区分・障害・難民および移民・農村部の住民・ロマおよびその他の少数民族・LGBTIQ の人々。

各集団についての詳細な確認事項と、通常どの基準に関係するかは references/rights-holder-coverage.md に記載されています。最終確認としてではなく、パス A の実施中に読んでください。

子どもの権利については、特に強調する必要があります。最も見落とされやすく、最も頻繁に採点対象となる項目だからです。関連性の基準では、条約への言及があるか、年齢区分が示されているかが問われます。質の基準では、子どもの権利がモニタリングの枠組みに含まれているか、セーフガーディングが採用されているだけでなく、パートナー全体で徹底されているかが問われます。インパクトの基準では、子どもを対象とする個別のアウトリーチがあるかが問われます。これを一度見落とすと、通常は三度見落とすことになります。

ステップ 4. 提案に適用するレンズの実質性テスト

分析を変えないレンズは、省略と同じく失敗です。このルールは、すでに私たち自身の文章にも適用している基準です。審査対象の成果物にも適用してください。

提案が掲げる各レンズ――交差性、ジェンダー変革型、参加型、脱植民地主義、権利に基づく、危害を与えない――について、プログラムが何をするかを変える文を見つけてください。単に名前が挙がっている箇所ではありません。原則の一つとして列挙されている箇所でもありません。

ドナー自身の枠組みに沿った問いは次のとおりです。提案は、交差するアイデンティティがアクセスにどう影響するかを示していますか。それとも、交差性が重要だと述べているだけですか。証拠に基づいてジェンダー・コンティニュアム上の位置づけを示していますか。それとも、自らをジェンダー変革型と呼んでいるだけですか。評価に誰がどのように参加するかを示していますか。それとも、評価を参加型と呼んでいるだけですか。

レンズが何も変えずに登場する場合、それは評価所見です。通常、ジェンダーの視点や包摂性を得点要素として掲げる評価基準では、減点につながります。レンズが実際に設計を変えている場合は、どこで変えているかを明示してください。擁護する価値のある強みです。

反対方向の誤りにも注意してください。文章がよく書けているからといって、枠組みを額面どおりに評価してはいけません。交差性への取り組みをよく表現した記述でも、ニーズ評価に細分化データがなく、当該コミュニティへの相談を示す証拠もなければ、評価点は得られません。

ステップ 5. 誰が実施するかのテスト

サブグラント、評価、パイロット、キャンペーン、能力強化の取り組みなど、主要な仕組みごとに、次の3つの質問をしてください。

1. どの役職が実施するのか。 どの組織かではありません。どの職位かです。
2. どのような実施能力があるのか。 人員配置は予算とスケジュールに見合っていますか。予算の大きな割合を占め、短期間に多数の助成金として支給されるサブグラント制度には、担当者を明記する必要があります。
3. 代替策は何か。 主要な担当者が退職した場合、どうなりますか。

この確認が必要なのは、評価者が仕組みを項目ごとに細かく監査しながら、誰が運用するのかを一度も問わないことがある一方で、ドナーはまさにその点を問うからです。運用担当者のいない統制は、それ以外は優れた提案にもよくある欠落であり、直接質問しなければ見えません。

ステップ 6. 評価基準ごとに採点する

公募要項の順に、各評価基準について次の4点を記載してください。

1. 得点。満点を明記し、該当する場合は基準点を超えたかどうかも示します。
2. 得点につながった要素。 提案書内の根拠を、セクションまたはページ番号とともに示します。正確な表現が判断を左右する場合は、重要な文言を引用してください。
3. より高い得点につながる要素。 不足点をそれぞれ独立した項目として、明確に記載します。
4. 修正が必要なセクション。 対象となる提案書のセクションを明記し、再読しなくても修正できるようにします。

採点中は、次の2つの原則を守ってください。

何かが欠けていると判断する前に、文書全体を検索してください。 評価者は複数のセクションを確認し、記載場所を問わず内容を評価します。「提案書は X に触れていない」と書く前に、別添、方針、組織概要を含む提出書類全体を検索してください。別の箇所で説明されている既存の組織制度を通じて申請者が要素をカバーしている場合、通常はカバー済みとみなされます。この習慣一つで、具体例における誤りの最大のまとまりを防げたはずです。

各所見に確信度を付けてください。 高は、評価者もほぼ確実に同意するという意味です。中は、擁護できるものの異論の余地があるという意味です。低は、評価者がチェックリストをどれほど字義どおりに読むかによって変わるという意味です。「記載場所が違う」や「このチェックリスト項目がここでは再掲されていない」といった所見は、評価者が有能な申請者を総合的に判断するため、原則として確信度が低いものです。その旨を明記し、優先順位の先頭に置かないでください。

ステップ 7. 数値だけでなく、幅を示す

点推定と現実的な幅を並べて示し、その幅の下限が何を意味するかを説明してください。

同じ提案書を採点する専門家の間でも、採点結果には通常 5〜10 点の差が生じます。合計点だけを示すのは、見せかけの精度です。合否判定における見せかけの精度は、数値を示さないよりも有害です。しきい値がその幅の中にある場合は、下限では不合格となることを明記してください。

合計点よりも順位のほうが重要です。最も強いと判断した基準と最も弱いと判断した基準を明示してください。修正項目のリストはその判断に基づいて作られますし、その判断こそ最も間違いやすいものです。

ステップ 8. 2 つの区分を分けておく

リストは 2 つ作成し、1 つの順位表にまとめてはいけません。まとめてしまうと、0 点の項目が最優先の修正項目として順位付けされます。

区分 A — 採点対象の指摘事項。 スコアに影響する項目です。労力に対して回復できる点数が大きい順に並べてください。各行には、提案書のセクション、変更内容、影響を受ける基準、推定点数、確信度、「新たな証拠」が必要か「書き直し作業」かを記載します。書き直し作業の項目は、提案書の責任者が今週中に対応できるものです。

区分 B — 署名前および実施時の項目。 0 点でも重要な項目です。助成金申請の準備前に解消すべき管理上の不備、余裕のない上限値、コンプライアンス上のリスク、後に監査担当者を困惑させる計算などが該当します。スコアを下げる項目の一覧と誤解されないよう、区分名を明確にしてください。

公募の管理チェックリストを字義どおりに読むと、区分 A の項目に見える区分 B の項目が必ず生じます。実例では、こうした指摘がまとまって最優先のスコア修正項目として順位付けされていましたが、該当セクションは助成機関の基準を満たしていました。それでも修正する価値はありました。しかし、点数には影響しませんでした。

ステップ 9. 確認できなかった内容を明示する

テキスト抽出では失われる情報があります。以下は断定的な指摘ではなく、原本で確認すべき項目として列挙してください。

• 網掛けや色分けのある日程表、ガントチャート
• 組織図、図表、および画像として提出されたすべての図
• 列の位置関係が抽出後に維持されない予算表
• ポータルフォーム（Part A）と説明文書（Part B）の相互参照
• 公募で採点対象となっているものの、まったく見つけられなかった項目

それぞれについて、懸念が現実のものだった場合にどのような損失があるかを記載してください。確認できない項目がリスト内のどの修正項目よりも重大な損失をもたらしうるなら、その点も明記してください。

ステップ 10. 提出する

BLUF：まず判定の一文を示し、次にその根拠となる重要な理由を述べます。続いて、知っておくべき 5 つの点を示します。その後、バイアスと不確実性に関する注記、概要表、基準ごとの採点、2 つの区分、未確認項目の一覧、証拠の根拠を記載します。

ファイルを書き出したら、Word 形式へのエクスポートを提案してください（「Outputs」を参照）。

---

CALIBRATE モード

助成機関の ESR が届きました。このモードの価値は、ひたすら正直であることにあります。そして、その正直さは損なわれやすいものです。

ルール 0

元のスコアは絶対に修正しないでください。 変更せずに両方を示してください。ひそかな後付け修正は、比較の唯一の目的を台なしにします。しかも、それによって出力がよく見えるため、修正したくなるものです。以前公表した採点内容を正確に再現し、ヘッダーに一切修正していないことを記載してください。

ESR のパスは必ず指定されます。検索して見つけるものではありません。 Ane がファイル名を指定します。フォルダーを検索してはならず、別の作業中に見つけたファイル候補を開いてもいけません。フォルダー検索をすると、SCORE の実行中に ESR を読んでしまうことがあります。

構成

1. 見出しスコア表。 評価基準、最大点、合格ライン、自分のスコア、提供者のスコア、差分、および両者の最大点に対する割合です。割合が重要です。20点の評価基準で3点差がある場合と、40点の評価基準で3点差がある場合とでは、異なる失敗を示しています。

2. 評価基準ごとに1つのセクションを設け、それぞれに2つの表と短い分析を記載します。

   • 強み。各行に [Donor]／[Mine]／[Both] のタグを付けます。
   • 改善の提案。同じタグを付けます。
   • ここで意見が異なる理由。文章で、提供者が見て自分が見落としたのはどのような点か、自分が見て提供者が重視しなかったのはどのような点かを説明します。

すべての行にタグを付けてください。タグのない表は単なる統合リストにすぎず、この演習で明らかにするべきパターンそのものが見えなくなります。

3. 意見が一致した点。 同じドキュメントから独立して導き出された一致点こそ、信頼に値するものです。どの点が一致し、それぞれどこに記載したかを示します。

4. 自分が誤っていた点を率直に述べる。 食い違った所見ごとに、付けた優先度と、提供者の評価を提供者自身の言葉で示します。次に、その仕組みについて1段落で説明します。捏造された所見だったのか、それともドキュメントに実在する特徴の重み付けを誤ったのか。通常は重み付けの誤りです。謝罪よりも、それを明示するほうが有益です。

5. 完全に見落とした点。 スコアリングに含まれなかった提供者の所見ごとに、該当する評価基準と、見落とした理由を記載します。この列がこのセクションの要点です。「検討しなかった」は、正直な記載として認められます。見落としを分類してください。9件中4件が1つのカテゴリーに属するなら、そのカテゴリーを体系的な盲点として挙げ、何があれば見落としを防げたかを記載します。

6. 較正の判定。 次の項目を表にします。

   • 合計スコアの誤差。点数と割合の両方を記載します。
   • 公表した範囲に真の値が含まれていたか、および範囲内のどこにあったか
   • 評価基準ごとの方向性。寛大すぎたか、厳しすぎたかを1行ずつ記載します。
   • 評価基準の順位付け：正しいか、誤っているか。修正リストは順位付けに基づいて作られるため、合計点よりも重要です。
   • 合格または不合格の結論：正しいか、誤っているか
   • 件数：食い違った所見、実質的な見落とし、独立して確認された所見

7. パターンを一言で示し、続けてこの手法を使ううえでの意味を説明します。何に適しているのか、何に使ってはならないのか、次回の実行前に何を修正するべきかを記載します。

calibrate の目的

スコアの予測は成果物ではなく、成果物ではないとはっきり述べるべきです。食い違った所見があり、評価基準の順位付けも誤っている中で、数点ずれる手法は予測ツールではありません。価値があるのは、修正リスト、一致した所見、盲点の記録です。精度があると読者に誤解させず、出力でそのことを明示してください。

較正を実行するたびに、次回の実行で何を変更するかを明記して終えてください。その内容をこのスキルに反映してください。

---

出力

正本は Markdown です。 まず Markdown を作成し、Ane が別の場所を指定しない限り、ソース文書を格納しているフォルダーに保存します。

• SCORE：<call-or-programme-slug>-proposal-scoring.md
• CALIBRATE：<call-or-programme-slug>-scoring-vs-donor-comparison.md

どちらの場合も IPPF ブランドの Word 版を作成し、文書の形に合ったビルダーを選びます。 2 つの形式にはそれぞれ異なるツールが必要で、誤ったツールを使うと文書が窮屈になります。

• 物語形式のスコアリング → ane_package.reporting.word_export の write_word_report。BLUF の箇条書き、平易な要約と箇条書きで構成したセクション、スコアを示す評価カード、方法に関する注記、用語集を含めます。
• 表を中心とした較正 → python-docx を使用し、_open_branded_base() を直接ベースにして作成します。WordReport の評価カードは 2 列しか扱えませんが、比較には 3〜6 列が必要です。

レシピ、正確なインポートリスト、ブランド付きテーブルのヘルパー、用語集のパターンは references/word-export.md にあります。ブランド値は ane_package.reporting.brand.IPPF_FORMAT_TEMPLATE を参照します。色、フォント、数値形式をハードコードすると、後退につながります。

各ジェネレーターの docstring には、編集内容の保持に関する古さの警告を記載します。生成対象の .docx の名前を明記し、mel_wiki/wiki/concepts/edit-preservation-protocol.md を参照してください。対象ファイルがすでに存在する場合は、必ずこのプロトコルを適用します。

AI の開示。 どちらの出力も、モデルについて、スコアリングの判断と提言は使用前に人間が検証する必要があること、そして AI は著者でも情報源でもないことを記した開示文で締めくくります。ブラインドで実施した場合は、寄付者評価が存在していたものの、意図的に開かなかったことを明記します。この手順によって、比較は再構成ではなく検証になります。

ブラインドの種類を明記します。 方法に関する注記では、構造的にブラインド（寄付者評価が実施範囲に含まれていなかった）か、自制によるブラインド（評価はフォルダー内にあったが、開かなかった）のどちらかを示します。この 2 つは同じ強さの主張ではありません。前者は読者が検証できますが、後者は担当者の言葉に依存します。そのため、単に「ブラインド」と記してより強い意味に受け取らせるのではなく、自制によるものと明記します。

用語集。 専門家ではない読者にも伝わるよう、すべての用語に説明を付けます。公募の用語（採択基準、しきい値、公募要項、助成率、ワークパッケージ、マイルストーン、成果物、普及レベル、サブグラントまたは FSTP、名誉宣誓書）と、MEL の用語（ベースライン、指標、アウトカム、アウトプット、変化の理論）が対象です。

---

専門家との協働

専門家がすでに行っている作業を再実装してはいけません。スコアリングの判断が求められる場面では、専門家を呼び出します。

• proposal-architect — 採択基準への対応付け、ロジックモデル・予算・作業計画の整合性、寄付者要件への準拠
• safeguarding-reviewer — 子どもの保護、国連子どもの権利条約、危害を与えない原則、パートナー間でのセーフガーディングの徹底
• intersectionality-analyst — ステップ 4 における視点の実質性テスト。並列的な細分化ではなく、相互作用の効果を検討
• srhr-indicator-designer — 指標の質、細分化、測定フレームワークが提案で約束したアウトカムを追跡しているかどうか

大規模な提案や重要度の高い提案では、網羅性の確認と視点のテストを、基準のスコアリングと並行して専門家の呼び出しとして実施します。簡易チェックでは、その場で実施します。

---

対象範囲

• 提案書の作成には /proposal を使用します。委託条件書の採点には tor-procurement を使用します。受領したサプライヤーの提案書のレビューには procurement-offer-review を使用します。IPPF 認定基準に照らした加盟協会の採点には accreditation-desk-review を使用します。完成した文書の QA ゲートには check-deliverable を使用します。
• このスキルは何も提出せず、資金提供を決定せず、財務または法務上の見解を承認しません。
• 寄付者の採点結果を予測するものではありません。予測として受け取られるような出力は、実際以上のことを主張しています。どこに得点の要点があるかを予測するものであり、これは予測とは異なる、より有用な主張です。

エビデンス基盤： この手法の基礎となる較正記録（存在する場合は非公開の較正記録 ${WORK_FOLDER_ROOT}/agent-improvements/private-calibration/donor-proposal-scoring/cerv-2026-worked-example.md を使用し、ない場合は合成版の references/worked-example-synthetic.md を使用）、references/rights-holder-coverage.md、references/word-export.md。