契約書の更新期限をAIで整理するには｜起算日・通知条件・原文照合のPoC設計

契約書は保存していても、更新の判断に必要な日付を一覧にできていない。担当者がPDFを開き直し、「いつまでに、誰へ、どの方法で知らせるのか」を探している会社では、期限候補と根拠の整理をAIで補助できるか検証する余地があります。

最初のPoCは、一種類の契約について「条文を探す、条件を抜き出す、担当者へ確認を回す」までに絞ります。AIが期限を確定して通知を送る構成にはせず、原文を読んだ担当者が台帳への登録を決める設計です。

契約の終了日と、通知が必要な期限を分ける

契約書には締結日、効力が生じる日、期間の満了日、更新を断るための通知期限などが書かれています。単に日付を拾うだけでは、管理すべき期限を取り違えます。

まず既存台帳の列を確認し、何の判断に使う日付なのかを決めます。「更新するかの社内確認日」と「相手方への通知期限」も別の項目です。前者を早めに設定しても、後者の解釈が正しい証拠にはなりません。

抽出値と原文を隣に表示できると、確認者が根拠を探し直す負担を比較しやすくなります。日付が明記されている場合と、条件から計算が必要な場合も分けて保存します。

以下は検証手順を考えるための仮例です。ある契約に「期間満了の一定期間前までに書面で通知」とあり、別紙には開始条件、後の変更契約には契約期間の変更が書かれているとします。

本文だけを読み込んで満了日を計算すると、変更を見落とすおそれがあります。このケースでは、AIが日付を埋めるよりも、関連する書類を示し「変更契約との関係を要確認」と止められることを評価します。

日付や条文が読み取れない、起算条件の成立日が分からない、複数の条項が食い違う、参照先の別紙がない場合は保留にします。「記載を見つけられなかった」と「契約に条件がない」は同じではありません。

通知の効力、条項の優先関係、期間計算に解釈が必要な場合は、社内の法務担当者や必要に応じて専門家が確認します。このPoCの範囲は情報整理であり、法的判断や期限の正確性をAIだけで保証するものではありません。

契約管理サービスに必要な抽出欄、原文表示、確認フローがそろっていれば、専用開発より導入や設定の検証を先に進める方法があります。すでに登録済みの期限を知らせるだけなら、台帳の整備や通知設定で足りる場合もあります。

文書抽出APIにも対応条件があります。たとえばMicrosoftのDocument Intelligenceの契約モデルは、確認時点の公式資料で英語文書対応とされています。日本語契約にもそのまま使えると考えず、利用する方式の対応言語、対象項目、読み取り品質を確認します。

自社の契約群に合わせた関連書類の束ね方や、既存台帳への確認待ち出力が必要なら、その差分を開発対象として整理します。

検証資料は、定型契約だけでなく、スキャン不鮮明、変更契約あり、条件付き開始、必要資料不足などに分けます。実資料を使う前に、利用権限、機密性、外部サービスへの送信範囲、保存・削除方法を確認します。

担当者が原文と関連資料を確認した正解表を用意し、調整に使った資料とは別の契約でも評価します。少数のきれいな契約だけで合格にしないことが重要です。

合格水準は、誤登録時の影響と確認体制に応じて着手前に合意します。高い抽出率でも、確認に従来以上の時間がかかるなら対象を狭める必要があります。逆に、保留が適切に分かれ、担当者が無理なく確認できるなら、限定した契約種類で継続検証する判断につながります。

開発見積りでは、読み取り部分だけでなく、関連契約のひも付け、原文表示、確認待ち一覧、台帳出力、権限管理を分けます。運用側には文書処理の利用料、原資料の保管、確認者の時間、契約変更時の再確認が発生します。

AiPHAのPoC開発・検証は20万円からで、対象業務と開発範囲に応じた見積りです。AIサービス利用料などの別途費用、継続保守や追加開発の範囲は事前に確認します。LPには「10日で納品」とありますが、今回扱う契約群、資料の準備、連携範囲を含む具体的な進め方は相談時にそろえます。

原本や変更履歴をそろえられない、最終確認者を置けない、期限確定から対外通知まで無人化したい場合は、この範囲のPoCには向きません。先に管理方法や責任分担を整える方が進めやすくなります。

相談時は、契約の種類、月に確認する件数の目安、いま探し直している項目、使用中の台帳、確認担当者を共有してください。契約書の実物をいきなり送らず、機密情報の扱いを確認してから必要なサンプルを準備します。

「どこまで抽出し、どこから人が判断するか」を決める段階から、開発対象を整理できます。