契約と覚書から満了日・通知条件を根拠付きで出し、人が修正案を決めるデモ

想定した課題・業務フロー

管理表の日付だけを確認しても、満了日と通知期限の取り違え、覚書で変わった通知条件、通知方法の空欄を判断しきれません。本文と覚書の根拠に戻り、資料が足りない契約を保留したまま、人が修正案の採否と社内の判断日を決めることを課題にしました。

実施内容

架空の契約6件・覚書2件を管理表と照合した検証ラボをもとにしたデモです。契約ごとの比較画面、原文確認と理由付きの判断、社内の判断日と役割の必須化、確認票・修正案・履歴のJSON書き出し、手動取り込みを加えています。精度・正答率・期限の正しさや導入の可否は評価しておらず、時間短縮・費用効果も測定していません。

架空の契約と、比べる範囲

• 条項表8行・管理表6行・想定表6行を契約IDで対応させています。各表はCSVを編集・貼り付けして「CSVを反映」でき、行の追加も試せます。
• Cの覚書M1は通知条件を30暦日前の電子メール到達に変え、第12条に優先します。Eの覚書M2は別途合意した対象取引だけの変更ですが、その取引を特定する別途合意書は渡していません。
• 契約ごとに管理表、AIの候補と根拠、コードが暦日数を引いた日付と差（候補 − 管理表）を比べます。方法・根拠の欠落や日付の順序も確認します。日付は算術上の候補で、法的な期間計算ではありません。

デモで加えた人の判断と、変更後の扱い

• 原文を開き、覚書がある契約は覚書も開いて、判断・記録する役割・理由を入力します。「一致として採用」「修正案を作る」には、通知期限より前の社内の判断日と判断する役割も必要です。
• Bでは満了日を2027-06-30、通知期限を2027-05-31にする修正案と、第11条の根拠を記録できます。管理表そのものを書き換える機能はありません。
• Eは不足資料の別途合意書を求める「確認待ち」にします。不足資料・確認する役割・社内の回答予定日・理由が必須です。本文の60暦日前（2027-07-02、書面到達）とM2適用時の30暦日前（2027-08-01、電子メール到達）を残し、AIや計算でどちらかを選びません。
• 人が書く欄は空から始まり、記録後や開き直した後も理由・チェック・原文を開いた記録は引き継ぎません。版の切り替えや候補の取り込みで既存の判断を解除します。入力を変えた契約も判断を解除して履歴に残し、「再整理待ち」として保存済み候補を使わず、AIも再処理しません。
• 修正案・確認票・履歴を表示し、JSONで保存できます。未判断・再整理待ちの契約も確認票に残します。「抽出・区分の指示をコピー」で入力と指示を写し、任意の生成AIや人が作った候補をJSONで貼り付けて取り込めます。M2がある契約は適用未確定として本文・覚書の2通りを必須とし、デモから外部へは送信しません。

実演モードと、意図的な誤りの教材

• 実演モードは事前に用意したAIの出力例をJSONから再生します。その場でAIを呼ばず、外部API・APIキーは使いません。
• 教材は、EでM2を根拠なく全体へ適用する、Cで通知方法だけ変えて旧期限を残す、Fの更新期間を1年にする、Dで日付差0日だけを見て一致とする4種です。管理表だけを見る(a)と教材の版は、確認待ち・差し戻しの記録だけができ、確認済みには進めません。
• 照合用に意図的に入れた候補で、AIの自然な失敗を観察した結果やモデルの性能評価ではありません。AIやコードが誤りを検出できた結果としても扱いません。

使った技術

Node.js、JavaScript、ブラウザの画面、CSV、JSON。Node.js 22以上で動き、npm startでローカルサーバーを起動します。追加の依存パッケージはありません。MIT Licenseで公開されています。

AIと人の役割

検証で扱った課題・制約

• 元の検証ラボで管理表の値だけを確認した(a)は、Bの日付順の異常までは分かっても逆転の根拠がなく、日付順が自然なCでは覚書の未反映を特定できませんでした。Eを保留できたのは、管理表に「適用未確認」の注記があった条件です。
• Eは本文と覚書の2通りの日付を計算できても、別途合意書がなく適用する条件を選べませんでした。Dは日付差0日でも通知方法が空欄で、日付だけでは通知条件がそろいませんでした。

検証から得た学び

• 元の検証ラボで条項表と照合した(b)は、6件の区分と理由が事前の想定と一致しました。一致候補2件、取り違え・覚書の未反映・通知方法の欠落が各1件、判断材料不足1件です。想定表を固定した同じAIが参照できる条件の読み合わせで、独立した評価・人の評価や正答率ではありません。
• 日付を計算できることと、覚書を適用できることは別です。Eは本文とM2適用時の両方を残し、不足する別途合意書を確認対象にしました。
• 元の検証ラボの観察は架空資料の読み合わせまでです。契約ごとの比較画面、原文確認・社内の判断日と役割の必須化、Eの確認票、誤りの教材4種、再整理待ちと判断の解除、書き出し・手動取り込みはデモで加えたものです。

同様の取り組みが向いている条件

• 契約本文・覚書・管理表を対応させ、日付だけでなく通知方法と変更の根拠も確認したい場合。
• 不足資料を集め、適用範囲や期間計算を責任者・専門家に確認してから、人が修正案を判断できる場合。
• 原本と適用資料の管理、承認権限、履歴の保存、機密情報の保護を別途設計できる場合。

補足

実際の契約ファイルの読み込み、管理表の自動更新、通知文の作成・送信、外部接続、AIによる自由な操作・コード実行は行いません。入力と履歴はブラウザのメモリ内だけで、再読み込みで初期状態に戻ります。契約の有効性や解約の可否を確定する機能はありません。実際の契約全文、複数の変更合意、月単位の通知期間、月末・休日、発送と到達が曖昧な条項、更新を重ねた契約は未試行です。実業務には専門家による期間計算と法的確認、永続化と監査、個人情報・機密情報の保護が別途必要です。向いている条件は仕組みと限界から整理したもので、実案件への適用を確認したものではありません。