tor-procurement

/tor-procurement — 調達用ToRを作成、レビュー、評価する

目的は一つです。調達用ToRをオープンマーケット水準に仕上げます。基本となるのは references/open-market-checklist.md です。22項目から成り、AI-for-Research ToRは4回の改訂（v0.4→v0.7、2026年7月）を経て、手作業でこの水準に到達しました。新しいToRはこの水準から作成し、既存のToRはこの基準に照らして評価します。

モードの振り分け

• build — まだToRがない場合、またはAneが新たに作り直したい場合。
• review — ToRがあり、Aneが強み・弱みと評価を求めている場合。読み取り専用です。
• respond — Aneが作成したToRに、指名されたレビュー担当者がコメントしており、Aneがその人に回答する必要がある場合。文書の編集ではなく、返信文を作成します。合意した譲歩がある場合に限り、最終化に引き継ぎます。
• finalise — レビューが行われた場合、またはAneが合意済みの改訂内容を提示した場合。それらを適用し、ほかには何も変更しません。

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

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

• ToRに手を加える前に、references/open-market-checklist.mdを読んでください。
• 事実の信頼性。 予算額、氏名、日付、住所、資金源を決して創作しないでください。未確認の情報は角括弧で囲み、「Internal preparation note — REMOVE BEFORE PUBLICATION」の削除リストにも記載してください（チェックリスト項目21）。公開済みのToRに記載された、もっともらしい仮置き情報は、事実として扱われるおそれがあります。
• 作成前の情報収集。 作成に着手する前に、重要な事実をAneに確認してください。作業ファイルは古くなるためです（セッション効率化プロトコル）。
• 公開するToRは外部向けです。平易な英語（Tier 1）を使い、翻訳可能性を確認してください（入札者には英語を母語としない読者が多いためです）。略語は初出時に正式名称を記載してください。
• ToRにMELの内容（指標、評価設計、学習に関する問い）が含まれる場合は、/mel-framework-citationを通じて引用基準を適用してください。

ビルドモード

1. 情報収集 — 重要な5つの事実を尋ねるメッセージを1回にまとめて送信します。（a）何を調達し、成果物は何か。（b）予算上限、VAT の扱い、資金源、寄付者資金の支出期限の有無。（c）日程の基準日 — 公開日、契約締結日、最終検収日。（d）評価委員会、および休暇中に質疑応答を担当する人。（e）契約の種類 — 個人／チーム／企業、コンサルティングかサービスか、一般競争か単独調達の免除か。
2. チェックリストを順に確認 — すべての項目を適用するか、該当しない理由を記録します（適用上の注意にはサービス契約と免除が含まれています）。作成に着手する前に、現実的なシニア人材の日数に照らして予算上限が妥当か確認します。両者に食い違いがある場合は明記してください — 評価で最も注意すべき点は、低すぎる入札です。
3. 出力 — scripts/tor_docx.py をプロジェクトに <project>/generators/gen_tor_v01_docx.py としてコピーし、ビルダーは変更せず、標準のセクション順にビルダー呼び出しを並べて ToR 本文を記述し、実行して docx が正しく出力されることを確認します。納品物の隣に置かれたジェネレーターが信頼できる唯一の原本です。docx を直接二重編集しないでください。ファイル名は v0.1、v0.2 のように増やします。
4. 実行結果ではなく、書き込まれたファイルを検証 — 保存した docx を開き直し、ヘッダー部分、ロゴのリレーションシップ、フッター帯が存在することをアサートします。ジェネレーターが正常終了しても、ブランディングが適用された証拠にはなりません。AI-for-Research ToR の v0.4 から v0.9 まではすべて成功を報告しましたが、ビルダーが空の Document() から開始したため、すべてブランディングなしで納品されました。python scripts/test_tor_docx.py は両方のヘッダーモードでこれらのアサーションを実行します。
5. 納品 — docx のパス、ジェネレーターのパス、Ane の判断が必要なチェックリスト項目、未解決の準備メモ項目を提示します。

ビルダーがレターヘッドを開く理由。 フォントや色はコードで設定できますが、ロゴ、ヘッダーの連絡先ブロック、柱状のフッター帯は ippf_en_letterhead_base.docx の中にしかありません。そのため TorBuilder はこのアセットを開いて、セクションのプロパティを維持したまま本文をクリアし、値を再記述せず ane_package.reporting.brand からブランド値をインポートします。ビルダー内で色を複製しても、テンプレートが変更されたときに追従できません。そのため、プロジェクトの CLAUDE.md では、これを QA による却下の理由としています。

ヘッダーモード。 TorBuilder(header="slim") がデフォルトで、複数ページの ToR に適しています。ブランド帯とロゴは残し、各ページの上部を圧迫しないよう連絡先ブロックを削除します。header="full" は連絡先ブロックを残すため、1ページのカバーノートに適しています。ジェネレーターの実行時に --header full|slim を指定して切り替えます。

ビルダーがすでに処理している2つの落とし穴 — 代替方法をテストしていない限り、変更しないでください。レターヘッドには Table Grid、List Bullet、List Number のスタイルがないため、表は独自に罫線を描画し、リストは独自の記号を書き込みます。これらのスタイル名を使おうとすると KeyError が発生し、後からその例外を捕捉すると孤立した段落が残ります。かつてすべての箇条書きが二重になったのはこのためです。また、連絡先ブロックは mc:Choice の描画と mc:Fallback の VML 複製として二重に格納されています。そのため、slim モードでは mc:AlternateContent の親要素全体を削除します。描画だけを削除すると、テキストが引き続き表示されます。

ジェネレーターが ane_package を見つけられない場合は、作業フォルダーを WORK_FOLDER_ROOT に設定します。ビルダーはまずこの変数を解決し、その後自身の場所から上位のディレクトリをたどります。ハードコードされたブランド値にフォールバックせず、明示的にエラーを出します。黙ってフォールバックした結果、ブランディングされていないファイルが見た目には問題なく納品される事態を防ぐためです。

レビューモード

読み取り専用です。このモードではToRを編集しません。docx入力の場合は、まずテキストを抽出してください（python-docx read）。Markdownまたはジェネレーターのソースの場合は、直接読み取ってください。

1. ToRとチェックリストを読みます。
2. 視点1 — シニア調達担当官。 手続きの妥当性と資金面を確認します：チェックリストのグループA、B、C、E。落札できなかった入札者、監査人、またはドナーから異議を申し立てられても、これは説明に耐えられますか？
3. 視点2 — 業務分野の専門家。 スコープの現実性、受入基準、上限日数に照らした日程の現実性、手法の適合性、優秀なコンサルタントが本文だけから適切に価格を提示できるかを確認します。
4. 出力は結論を先に述べます：判定文、優れている点、チェックリスト項目と修正案の文言を対応づけた弱点、評価（1～10）、バイアスに関する注記。

評価の目安：5以下＝公開不可、構造上の欠落あり；6～7＝明記した修正を行えば公開可能；8＝公開市場の標準；9～10＝外部レビューを通過したToRに限る。必須のバイアスに関する注記（常に記載）：

この文書に取り組んだモデル自身による自己評価はN/10です。上限の評価として扱ってください。公開前に、[最も弱いセクション]を[指名された同僚]が外部レビューすることを推奨します。

回答モード

レビューから最終確定までの段階です。指名されたレビュアーが条項に異議を唱えており、その相手に回答することが目的です。通常、正しい結論は文書を変更しないことです：4つの判定のうち3つでは、ToRは公開時のままにします。

判定	意味	ToRを変更するか
defend	条項は記載どおりに妥当であり、実際に何を定めているのかを説明します。	いいえ
concede	レビュアーの指摘は正しいです。必要最小限の修正だけを示し、それ以上は変更しません。	はい
defer	指摘には妥当性がありますが、この契約には適しません。後続業務の規模を見積もります。	いいえ
escalate	これはToRでは解決できないガバナンス上の問題です。責任者を明示します。	いいえ

複合回答では、主判定と副判定を1つずつ組み合わせます。defend + deferが基準ケースです：条項は維持し、レビュアーが求める業務は別契約として規模を見積もります。defend + concedeは認められません。条項が記載どおりに妥当であると同時に、修正が必要であるとはできないためです。

手順

1. ToR と references/open-market-checklist.md を読みます。 異議は、外部から届くチェックリストであることがよくあります。
2. 異議を抽出します。 python scripts/tor_respond.py extract "<ToR>.docx" --json round.json を実行します。各スレッド、そのスレッドがあるセクション、すでに回答済みかどうかが表示されます。コメント一覧にはない、次の3点がわかります。
   • アンカーは条項そのものではありません。 レビュアーはフレーズを選択し、その背後にある主張についてコメントします。回答を作成する前に、ハイライトされた語句だけでなく、セクション全体を読んでください。
   • 本人の余白へのメモは別に分けられます。 これらは作業メモであり、異議ではありません。返信を待っている人はいません。
   • also commented here は、別のスレッドで同じ段落にコメントした人を示します。Word では、返信ボタンを使った場合にのみ返信として記録されます。そのため、すでに入力済みの回答が異議の横に新しいコメントのように表示されることがあります。二重に回答する前に確認してください。
3. 回答する前に、異議を最も強い形で述べます（反論を前提とする姿勢）。最も弱い解釈に回答すると、ひとつの異議が4回のやり取りに膨らみます。レビュアーの指摘が正しければ認めてください。すべてを弁護しても、誰も納得しません。
4. 文書の記載内容に基づいて回答します（事実の信頼性）。弁護する場合はすべて、その根拠となる ToR のセクションまたはガバナンス文書を引用します。出典を示せない組織上の事実を断言してはいけません。2026-07-31 の返信案には、「DPO がいない可能性がある」という補足が含まれていましたが、確認されておらず、事実として外部の読み手に伝わるところでした。ガードは、何も引用していない弁護を拒否します。
5. 返信は2つの長さで作成します。 メールや会議向けの全文版と、Word のコメント欄向けの簡潔版です。一読で収まらない返信は、コメント欄では読まれません。上限はデフォルトで500語と180語ですが、固定値ではなく設定です。
6. 判定が保留の場合は、後続作業の規模を見積もります。 選択肢、コンサルタントのプロフィールがどう異なるか、費用未算定と明記した概算レンジ、そして委託を正当化する発動条件を示します。正当な指摘を禁止事項で退けると次のやり取りを招きますが、計画で回答すれば決着します。
7. コンパイルします。 python scripts/tor_respond.py compile round.json --out <dir> --docx を実行します。replies.md（各異議について、2種類の長さの返信と規模の見積もり）と response-register.md（各異議につき1行、および finalise モードで使用する改訂リスト）を書き出します。--docx を指定すると、両方をブランド仕様の Word 文書として出力します。

ガードが拒否するもの

compile は書き込み前にすべてのガードを実行し、矛盾する内容を含むやり取りを拒否します。finalise モードがその内容に基づいて処理するためです。ブロック対象は、互いに矛盾する判定の組み合わせ、譲歩以外に結び付けられた編集、編集内容を特定していない譲歩、後続作業の規模を見積もっていない保留、出典のない弁護、空の返信、日数をゼロと見積もった選択肢です。警告のみで、書き込みは続行されるものは、長すぎる返信、スティールマンの欠如、および ane_package.qa.prose_lint による定型的な文章上の指摘（曖昧な表現、冗長な記述、エムダッシュ）です。

境界線は、誤りが Ane 以外の人に届くところにあります。長さや文体は、コメント欄で本人が直せる作業上の問題です。矛盾や出典のない主張は、名前の明らかな外部レビュアーに伝わり、後から取り消すコストは事前に見つけるコストを上回ります。--force はこれを上書きし、その旨を明示します。

見積もりのスケッチに、何も創作しません。 誰も見積もっていない選択肢は、ゼロ日とせず未算定のままにします。また、調達ルートは、提示されたしきい値に照らしてのみ評価します。このスキル自体はしきい値を持ちません。

回答後

譲歩した異議だけが、finalise モードの改訂リストに入ります。それ以外はすべて返信で決着します。Ane が返信を Word のコメント返信として送る場合は、本人が貼り付けます。このモードが文書に書き込むことはありません。

最終化モード

1. 合意した修正リスト（レビューまたはAneからのもの）を確認します。作業範囲はそのリストのみです。
2. 対象ファイルが存在する場合は、mel_wiki/wiki/concepts/edit-preservation-protocol.md を適用します。Aneの現行コンテンツが正式なベースラインです。まず読み、Editツールを使って範囲を限定して編集し、範囲外の内容はバイト単位で同一に保ち、範囲外で気づいた点はEDIT-PRESERVATION DELIVERY形式で報告します。最初から作り直してはいけません。
3. docxの成果物では、編集対象は生成元です。現在の gen_tor_v0N を v0N+1 にコピーし、合意した修正を適用して再実行し、新しいdocxのパスを報告します。docxのバイナリは編集してはいけません。
4. 最後に、合意した各項目と反映先を列挙し、公開前に対応が必要な準備メモの項目があれば示します。

範囲の境界

• 調達チャネルでの公開、財務およびVATの確認、契約主体、法務承認は各担当者が対応します。確認が済むまで、ToRには各項目のプレースホルダーを残します。
• Ane自身のToRにコメントしたレビュー担当者への返信は、上記の応答モードです。Aneがコメントした第三者の草案をレビューするのは逆方向の作業であり、このスキルの対象ではありません。こちらでは、Aneはレビュー担当者ではなく、受け取ったコメントに回答する作成者です。どちらかをもう一方から作り直してはいけません。
• 受領したオファーの評価と、免除パックの整合性の維持は、次のライフサイクル段階（2026-07-22に構築された procurement-offer-review）にあたり、このスキルの対象ではありません。
• IPPF外で公開するToRは、AI支援による公開にあたります。mel_wiki/wiki/concepts/ai-use-in-publications.md に基づき、標準のコロフォンを提示します（通常の文法のみの修正は対象外です）。