12月31日で満了する契約を12月に確認しても、間に合わない場合があります。「60暦日前までに更新拒絶通知が到達すること」という条項と、社内判断に必要な二週間を考えると、作業期限は10月に移ります。
Budaで構築できる契約管理ワークフローでは、確認可能な更新カレンダーと義務一覧を準備できます。エージェントが根拠を整理し、契約責任者と法務が解釈と行動を決めます。
一つの契約に三つの日付
架空の契約A、A-R1版8ページを使います。「契約は2026年12月31日まで。更新拒絶通知はその60暦日前までに到達すること」。この説明例では、責任者が端点を含める追加調整のない単純な日付減算を確認したものとします。
- 満了日：2026年12月31日。
- 到達期限の候補：12月31日−60暦日＝11月1日。
- 社内判断日：11月1日−合意した14日＝10月18日。
14日は架空の社内準備期間であり、契約上の通知期間ではありません。11月1日も、この数え方による確認対象の候補です。通知方法、宛先、必要なタイムゾーン、関連条項による変更を確認します。発送と到達は区別します。
条件が決まるまで計算しない
架空の契約Bは月ごとの自動更新で、30日前の通知を求めます。まず、締結済み契約と変更合意から次の期間末を確定します。「毎月」だけでは日付も、通知がどの更新期へ効くかも決まりません。
契約Cは検収日から期限が発生しますが、検収日がありません。起算日不明として検収記録を求め、請求日・アップロード日・今日で代用しません。営業日で数えるのに適用カレンダーが不明なら、法務や責任者へ確認します。
変更合意が通知期間や宛先を変えることもあります。両方の原文、版、位置を残し、どの義務を置き換えたかを確認します。新しいファイル名だけで締結済み・適用済みとは判断しません。
義務一覧から判断カレンダーへ
許可された締結済み契約、変更合意、社内判断ルール、担当者表だけを使います。renewal-obligations.csvには契約ID、締結版、ページ、原文、満了日または起算日、通知条件、暦日・営業日の定義、到達要件、期限候補、算式、社内余裕日数、責任者、未決事項を残します。
Aには二段階の算式、Bには期間末未確定、Cには検収日欠落を記録します。空欄は不明であり、残日数ゼロや義務なしではありません。
decision-calendar.mdは満了日順だけでなく、最初に人が動く必要のある日で並べます。元の行と資料位置、担当者、次の確認を添えます。提案するファイルであり、契約システムへの自動書き込みではありません。
通知の状態を証拠で分ける
判断待ち、判断記録済み、通知案、送付承認済み、送付済み、到達証拠ありを別々に管理します。下書きやチェック欄だけでは有効な通知になりません。実在する受領証拠の出典を残し、条項に適合するかを確認者が判断します。
変更合意が出たら影響する項目だけを再計算し、旧計算と理由を保存します。担当者交代だけで契約期限は変わりません。
指示は「原文と位置を引用して義務表と社内判断日を準備する。起算日と数え方が確認済みの場合だけ計算する。不明と不存在を分ける。通知送付・契約変更・法的判断はしない」と具体化します。
よくある確認事項
検収日がない場合は？
派生期限を未計算のままにし、必要な記録と取得担当者を明示します。
契約と変更合意が矛盾したら？
両方の原文を保ち、締結状態と範囲を確認して責任者・法務へ照会します。更新時刻だけで選びません。
メール送信済みなら完了ですか？
真正な送信記録は送信の根拠です。到達、宛先、方法の要件は確認済み条項に従い、必要な証拠を別に残します。
祝日はどの暦を使いますか？
適用定義を確認してから使います。不明なら営業日計算を保留します。
小さな契約群で確認する
BudaのAgent Workspaceに締結文書、一覧、算式、確認結果をまとめます。一件ずつ点検できる範囲で受け入れ、抽出方法をSkillとして再利用します。Buda AIのMarketplaceで適切なSkillを検索・インストールできます。役立つカレンダーには、誰がいつ判断するか、日付の根拠と未確認事項が見えています。