contract-delivery-kickoff

/contract-delivery-kickoff — 上限を決めるセッション

目的は一つです。契約が締結され、業務が始まろうとしている段階で、最初のセッションにより、限られた日数をどう使うかが決まります。/tor-procurement がToRを作成し、selection-toolkit が選定を実施しました。ここでは、締結後に行うことを扱います。

このスキルがある理由

デリバリー契約は、派手に破綻することはありません。少しずつ逸脱していきます。最初のセッションで課題一覧を確認し、妥当な項目すべてに合意します。そして、最後のトランシェに残り日数がないことが5か月目に判明します。参照事例は、2026年6月12日のAbortion Dashboard Phase IIセッションです。契約上の14コンポーネントに対し、技術作業9日、調整作業4日で、すべて手作業で実施されました。

つまり、成果物は算術です。 準備ブリーフとアジェンダは、その算術を会議の場に届けるためのものです。美しい文書を作っても、日数の予算がなければ、何も作っていないのと同じです。

ここであらゆることを支配するルール

何も創作しません。 契約上の日数、単価、トランシェはすべて契約書から取得し、確認できない場合はAneが解決すべき不足情報として報告します。類似契約から読み取った日当も、セルに入力してしまえば本物と見分けがつかなくなり、その金額をもとにセッションで確約してしまいます。read は不足情報を補いません。build は _gaps が残っている間は処理を拒否します。さらに、validate_spec はその後に実際の不足があれば処理を拒否するため、ギャップ一覧を削除しても、何かをこっそり通すことはできません。

この仕組みが実装する5つの手順

5つすべてが、2026年6月12日のセッションで実証されています。どれも単なるスタイルの好みではなく、セッションで起こり得る問題を一つずつ防ぎます。

1. すべての項目をレーンに分けます。 クライアントが用意するコンテンツ（最終文面、ラベル、定義、ファイル）は、引き渡された後、サプライヤー側の作業コストがほとんどかかりません。構築作業には日数がかかり、その日数には限りがあります。レーン分けは、通常、この1時間で最も低コストでスコープを調整できる方法です。
2. 項目を一つずつ確認する前に、上限に合意します。 そのため、ワークブックでは、手作業で作成した版とは順序を逆にして、01 Day budget を 02 Triage より前に配置しています。もっともらしい項目が14個並ぶリストを先に読むと、「9日間で何ができるか」を契約ではなくリストに照らして考えることになります。
3. 最初のセッションですべてのトランシェについて見積もりを求めます。 今すぐ始まるトランシェだけではありません。見積もりのないトランシェは、コストがないトランシェではありません。ワークブックでは、ゼロを入力する代わりに not priced と記載し、エンジンでは None として保持するため、合計の中に隠れることはありません。
4. 保護対象の項目を最初に明示します。 危害防止、信頼性、コンプライアンスに関わる欠陥は、上限があっても対応が必要であり、その枠を巡って競合するものではありません。トレードオフの話し合いが始まる前にこれを明言すれば、対象を削る案が出るのを防げます。
5. ほかの確認に先立ち、署名状況を確認します。 契約が未署名なら、支出を確約できません。また、最初の契約上の成果物がすでに遅れている場合も多くあります。validate_spec は、署名状況が不明な仕様を拒否するため、この確認が抜け落ちることはありません。

コードの場所

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

• ane_package.reporting.delivery_kickoff — 仕様、日数予算エンジン、ワークブックビルダー。
• ane_package.reporting.markdown_docx — Markdown形式の成果物をブランド仕様のWord文書としてレンダリングします。
• ane_package.officeops.extract — document_tables は契約書の予算表を空欄を保持したグリッドとして読み込みます。extract_text は本文を読み込みます。
• scripts/contract_kickoff.py — ドライバーです。予算表の検出、数値の解析、署名状況の読み取り、仕様の組み立て、成果物のテキスト作成、検証を行います。

境界を明確にしておきます。再検討の余地はありません。Officeファイルを開く処理は、すべてモジュールに置きます。 ドライバー内で文書を開く関数は load_document の一つだけであり、それが常に一つだけであることをテストで確認します。後続処理はすべてオブジェクトを受け取るため、.docx のテスト用フィクスチャを一つも使わずにパーサー全体をテストできます。

Office関連のコードを書く前に office-repair にある references/officeops-excel-api.md を読み、この1時間の進め方については、ここにある references/session-moves.md を読んでください。

実行方法

1. 契約を読み込む

python scripts/contract_kickoff.py read "Agreed offer.docx" \
    --supplier "Supplier A" --contract "Phase II delivery" \
    --out kickoff-spec.json

検出された契約上の役割、トランシェ、候補項目、すべてのギャップを出力します。ギャップは Ane に確認してください。よくあるものを、出現頻度の高い順に示します。

• 署名状況。 オファーには、相手側も署名済みかどうかがほとんど記載されていません。このギャップはほぼ確実に発生します。パーサーの不具合ではなく、ステップ 5 が機能した結果です。
• トランシェごとの日数配分。 契約書にはトランシェが記載されていますが、個別の価格が示されることはまれです。これは最初のセッションで確認する項目です。
• すべての項目のレーンと重大度。 パーサーではクライアントのコンテンツとサプライヤーの構築作業を判別できません。また、項目が誤って Client, content とマークされていると、実際はそうでないのに無料であるかのように表示されます。これらは Ane と一緒に設定し、推測で決めないでください。

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

仕様ファイルは「この契約の日数が 9 日なのはなぜか」を示す監査証跡です。パックと一緒に保管してください。

3. ビルドする

python scripts/contract_kickoff.py build kickoff-spec.json --out "Session 1"

ワークブックに加え、PREP-brief.md、AGENDA-to-supplier.md、NOTE-template.md を出力し、それぞれをブランド仕様の Word 文書に変換します。Markdown が正本です。 .md を編集して再実行してください。.docx を編集しても、再ビルド後に変更が残るとは限りません。

build は、契約自体の提案内容もエンジンで処理し、契約の上限内に収まるかを報告します。購入済みの日数が 9 日なのに契約で 10 日を提案している場合、どのセッションでも交渉で解決できない問題があります。議題の作成中に判明させるほうが、会議の場で判明するよりはるかに低コストです。

build は、既存のワークブックを上書きしません。セッションで一度使用すると、その中の見積もりと決定事項はほかの場所には存在しなくなります。

4. 実行して検証する

python scripts/contract_kickoff.py verify "Session 1" --spec kickoff-spec.json

ワークブックのコピーを作成し、Excel COM を通じてサンプルの日数を入力し、完全な再計算を実行します。そして、Excel が算出した数値を、数式の作成に使用したものと同じ Python エンジンの結果と照合し、数式エラーのセルがないことを検証します。

正しく見えても計算結果が間違っているワークブックは、ここで想定される失敗パターンです。 数式を読み返しても、書き込んだ数式と同じ数式が書き込まれていることしか確認できません。検証はコピー上で実行されるため、サンプルデータが有効な契約記録に書き込まれることはありません。

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

5. 出力をコミットする

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

ワークブックの内容

00 Guide（署名状況、時間枠の進め方、重大度とレーンの語彙の順）、01 Day budget（役割ごとに、トランシェ、提案日数と合意日数、時間、割合、金額を表示し、その後に合計、契約日数、残日数を表示。レーン別の内訳はトリアージシートからリアルタイムに計算）、02 Triage（候補項目ごとに 1 行を割り当て、セッションで入力する列を網掛け）、03 Decision log、98 REF（契約上のパラメーターを記録し、監査証跡をファイルとともに保管）。

注意すべき点

1. 別の言語で書かれた契約書です。 予算表の見出し、単価を示す語句、署名欄の文言は、英語、フランス語、スペイン語、ルーマニア語、ドイツ語の間で、アクセントを無視して照合されます。英語のみを対象にしたチェックでは、フランス語の提案書から予算表を見つけられず、文書の問題ではなくパーサーの問題による不備が報告されます。この問題は3回連続の作業で発生しています。
2. 上記5言語のうち4言語では、1.234は千二百三十四です。 これを1.234と読み取ると、日単価がわずかな金額になり、予算全体が気づかれないまま無意味なものになります。parse_numberは規則を決めつけず、実際に使われている区切り記号から表記規則を推定します。
3. 合計行はリソースの明細ではありません。 合計行を明細として読み取ると、契約日数が2倍になり、その結果、上限に十分な余裕が生まれて、予算超過がまったく検知されなくなります。
4. Noneと0.0は同じ日数ではありません。 価格が提示されていないトランシェと、価格が0のトランシェは、合計値の中では区別できなくなりますが、契約を破綻させるのは前者です。エンジンはNoneを引き継ぎ、ワークブックにはnot pricedと記載します。
5. 早期警告は、予算がまだ残っている段階で発動します。 合意された日数が契約書に記載された提案日数の1.5倍を超えるバケットは、合計がまだ上限内であっても警告を発します。超過してからしか警告しない制約では手遅れになります。このスキルはその失敗を防ぐためのものです。
6. 議題はサプライヤーに渡します。 署名に関する警告、保護対象項目の一覧、契約の弱点に関するAneの見立ては、準備用ブリーフに留めます。テストでは、これらが漏れないことを確認します。
7. 希望を伝える前に、見積もりを依頼します。 先に結果を指定すると数字が固定され、その数字を基に予算全体が組み立てられてしまいます。

対象外の範囲

ToR（/tor-procurement）の作成、選考委員会の運営（selection-toolkit）、個別の提案書の分析（procurement-offer-review）、IPPFが受け取るドナー助成金の追跡（implementation-pack）は行いません。初回セッション後の契約管理や、対象範囲から外す内容の決定も行いません。このスキルはツールを作成し、計算を行います。決定するのはAneとサプライヤーです。