契約書の管理台帳と更新期限をAIで管理する｜締結後の契約情報の抽出と、自動更新条項の見落とし防止

締結した契約は、どこで見えなくなるか

契約は締結した時点で管理の対象になりますが、社内の関心はたいてい締結までで途切れます。レビューと押印までは工程が決まっていて担当者もいるのに、締結後は「どこかに保管されている」状態になります。

この状態で起きるのは、次のようなことです。

自動更新に気付かないまま更新される。 多くの契約には、期間満了の一定期間前までに申し出がなければ同一条件で更新するという定めがあります。使っていないサービスや、条件を見直したい取引が、誰も見ていないまま次の期間に入ります。

解約したいときに、通知が間に合わない。 解約を決めた時点で通知期限を過ぎていると、もう1期間分の義務が残ります。判断が遅れたのではなく、期限を知ったのが遅かっただけ、という状況です。

契約の内容を聞かれても、すぐに答えられない。 相手先ごとの有効期間、賠償の上限、再委託の可否といった条件が、原本を開かないと分かりません。問い合わせのたびにファイルを探す時間がかかります。

原因は担当者の注意力ではありません。契約の情報が原本の中にしかなく、期限が誰かの記憶か個人の予定表にしか無いことです。台帳という形で情報を外に出し、期限を仕組みが持てば、この3つは同時に減ります。

締結前のレビューをどう分担するかは契約書レビューをAIでで扱っています。この記事はその後ろの工程、締結してからの管理を対象にします。

台帳に載せる項目と、抽出をどこまで任せるか

台帳の項目は、多ければよいものではありません。埋まらない列が並ぶと、台帳全体が信用されなくなります。まず「期限を管理するために要る項目」と「聞かれたときに答えたい項目」を分けます。

抽出の任せ方も項目ごとに違います。契約書の中に一意に書かれている項目は機械側で確定できますが、複数の条項や別紙にまたがる項目、解釈が要る項目は人が確定させます。

台帳の項目	抽出の任せ方	そう分ける理由
契約書の名称、契約類型	抽出した値を提示し、担当者が確認	表題と実態がずれる契約がある。表題だけでは類型を確定できない
相手先の名称、当事者の別（委託者か受託者か）	機械側で確定してよい	前文と署名欄に一意に書かれている
契約締結日、期間の開始日と満了日	機械側で確定してよい	条文に日付として書かれている。開始日が締結日と違う契約は条文の記載を優先する
自動更新の有無、更新後の期間	機械側で確定してよい	更新条項の有無と期間は条文から取れる
解約の申し出の期限（何か月前までか）	機械側で確定してよい	条文に期間として書かれている。日付への変換は次節のとおり計算で持つ
契約金額、単価、支払条件	抽出した値を提示し、人が確定	別紙や個別契約に分かれ、改定の覚書が別にあることが多い
賠償の上限、再委託の可否、権利の帰属	抽出した値を提示し、人が確定	条件付きの書き方が多く、台帳上の一語に落とすと元の条件が消える
特約、覚書による変更	人が入力	本体の契約書だけを見ても存在が分からない
原本の保管場所、電子か紙か	機械側で確定してよい	取り込み時の情報として持てる
社内の管理部署、担当者	人が入力	契約書に書かれていない社内の情報

「機械側で確定してよい」としたのは、抽出結果をそのまま台帳へ書き込んでよいという意味です。それでも原本へのリンクは必ず持たせ、値の横から条文を開けるようにします。台帳の値が疑われたときに原本へ戻れないと、結局は全件を人が見直すことになります。

金額を人が確定させる側に置いているのは、精度の問題というより、金額が最も改定されやすい項目だからです。本体の契約書から正しく読み取っても、その後の覚書で変わっていれば台帳の値は間違いになります。抽出できたかどうかと、台帳の値として正しいかどうかは別の話です。

読み取りの仕組みをどう選ぶかは、原本の状態で変わります。定型の帳票と非定型の文書で選び方が違う点は AI-OCRと生成AIの違いで整理しています。契約書は書式が相手方ごとに違い、条項の並び順も一定ではないため、位置ではなく意味で読む側の構成になります。

解約通知期限は、保存する値ではなく計算する値にする

自動更新の見落としを防ぐうえで、設計が分かれるのがここです。

契約書に書かれているのは「期間満了の3か月前までに書面で申し出ない限り、同一条件でさらに1年間更新する」といった条件です。台帳に「解約通知期限：2027年2月28日」と日付だけを保存すると、更新が1回起きた時点で古い値になります。誰かが手で更新しない限り、台帳は前の期間の期限を指し続けます。

そのため、台帳には条件の側を持たせます。

現在の期間の満了日
更新の有無と、更新後の期間の長さ
申し出の期限（満了日の何日前、または何か月前か）
申し出の方法（書面、電磁的方法など、条項に定めがあれば）

そのうえで、通知期限は満了日から計算します。満了日を過ぎたら、更新条項に従って次の満了日を算出し、期限も再計算します。この形にすると、更新が何度起きても台帳の期限が自動で先へ進みます。

計算では次の3つを決めておきます。

「3か月前まで」の数え方。 満了日の3か月前の応当日を期限とするのか、その前日までとするのかで1日ずれます。契約ごとの文言に差があるため、機械的に一律で計算する場合は、どちらの解釈を採るかを決めたうえで、余裕を持たせた日付を通知に使います。

通知が営業日に当たらない場合の扱い。 期限が休日に重なるときに前倒しするかどうかを決めます。実務上は、期限そのものより先に判断が終わっている状態を作るほうが重要です。

期間の記載が「1年間」以外の契約。 更新後の期間が本体と違う契約、更新に上限回数がある契約、期間の定めがない契約があります。定めがない契約は満了日が空になるため、台帳では別の状態として持ち、期限の通知の対象から外します。空欄のまま同じ列に混ぜると、抽出漏れなのか定めがないのかが区別できません。

抽出から台帳への反映、通知までの流れ

工程で見ると次のようになります。

抽出と計算と通知は仕組みが持ち、金額や特約の確定と、更新するかどうかの判断は人が持ちます。判断の結果を台帳へ戻すところまでが1周です。

7で決めた内容を台帳へ戻す経路を作っていないと、しばらくして台帳と実態がずれます。解約を申し出た契約が満了日を迎えても更新扱いのままになり、条件を変えて更新した契約は古い条件を指したままになります。通知を出すところまでで作り終えたつもりになりやすい箇所です。

既存契約をどこまで遡って載せるか

新しく締結する契約を台帳に載せるのは難しくありません。負担が大きいのは、すでに社内にある契約の取り込みです。ここで範囲を決めずに「全件やる」と始めると、紙の原本を探す作業で止まります。

判断の軸は、締結年ではなく「いま効力があるか」と「期限の管理が要るか」です。

取り込みの候補	判断	理由
現在有効で、自動更新の定めがある契約	最初に入れる	放置すると更新される。台帳を作る目的に直結する
現在有効で、期間の定めがない契約（基本契約など）	次に入れる	期限の通知は不要だが、条件を問い合わせられる対象になる
現在有効で、満了日が決まっていて更新の定めがない契約	次に入れる	満了の前に継続の要否を判断する必要がある
満了・解約済みだが、秘密保持義務など存続条項が残る契約	存続期間の管理が要る範囲だけ入れる	全項目を埋める必要はない。相手先と存続条項の期限で足りる
完全に終了し、存続条項も切れている契約	台帳には入れない	保存の要否は文書の保存規程の側で決める

取り込みは原本の状態でも分けます。テキストを持つ電子ファイルは抽出をそのまま通せますが、紙をスキャンした画像やテキスト化されていないPDFは、読み取りの段階を挟むぶん確認の手間が増えます。

電子ファイルでテキストを持つもの … 抽出を通し、確認が要る項目だけ人が見る
スキャン画像・テキストのないPDF … 読み取りを挟む。押印の重なりや手書きの追記で値が崩れやすいため、日付と期間は目視で確認する
紙の原本しか無いもの … 全件をスキャンする前に、期限の管理が要る契約だけを選ぶ。それ以外は、必要になった時点で足す形にする

先に決めておくとよいのは、取り込みの完了をどう定義するかです。全件を載せることを完了条件にすると終わりません。「現在有効で自動更新の定めがある契約が、すべて台帳にあり期限が計算されている」といった形にすると、そこまでで一度運用に入れます。残りは運用しながら足します。

どこから着手するかを迷う場合は、台帳の自動生成より先に通知だけを作る選択もあります。相手先・満了日・通知期限の3項目だけの一覧を人が作り、期限が近づいたら担当者へ通知する仕組みを先に回す形です。抽出の精度に関係なく動くため、更新の見落としだけは早く止められます。抽出の自動化は、その後で件数と手間を見て決められます。

通知は、誰に何を返させるかまで決める

期限が近づいたことを知らせるだけの通知は、しばらくすると読まれなくなります。受け取った人が何をすればよいかが書かれていないためです。

決める項目は次のとおりです。

通知先。 契約ごとに管理部署と担当者を持たせます。担当者が異動したときに宛先が消えるため、個人だけでなく部署も持たせます。契約に紐づく担当者が空の契約は、通知が誰にも届きません。台帳を作る段階で、この列が埋まっているかを確認します。

通知の時期。 通知期限の当日に知らせても間に合いません。社内で継続の要否を判断し、決裁を取り、相手方へ通知するまでの時間を逆算します。判断に時間がかかる契約ほど早く出します。1回で終わらせず、余裕のある時点と、期限が迫った時点の複数回に分けます。

通知に載せる内容。 相手先、契約の名称、満了日、通知期限、更新後の条件、原本へのリンク。受け取った人が原本を探さずに判断できる状態にします。

返してもらう答え。 「更新する」「解約する」「条件を変えて交渉する」のいずれかを選ぶ形にします。自由記述で受けると、後から集計できず、台帳へも戻せません。

未回答の扱い。 期限までに回答がない契約をどうするかを決めます。仕組みの側で解約を選ぶことはできないため、上位の役職者へ知らせる、未回答の一覧を定期的に出す、といった形になります。

通知が読まれるかどうかは、置き場所にも左右されます。普段使っているチャットや業務システムの中に出すほうが、専用の画面へ見に行く形より反応が残ります。

抽出の精度をどう確かめ、任せる範囲を決めるか

抽出を自動化する前に、どこまで信用できるかを確かめます。項目ごとに正解が明確なので、契約書レビューの一次レビューより測りやすい領域です。

すでに台帳に入っている契約か、人が読んで値を確定させた契約を用意し、抽出結果と突き合わせます。見るのは項目ごとに次の3つです。

見るもの	数え方	出たときに直す場所
取れなかった項目	該当する条項があるのに、値が空で返った件数	条項の呼び方の揺れを拾えていない。抽出の指示に別の言い方を足す
違う値を返した項目	値は返ったが、条文と一致しなかった件数	参照した箇所を出力に含める設計にし、どこを読んで間違えたかを見る
該当が無いのに値を返した項目	定めがないのに値が入った件数	「該当なし」を返せる形になっていない。空を許す出力の形にする

3つ目は見落とされやすい割に影響が大きい項目です。自動更新の定めがない契約に更新の期間が入ると、実在しない期限の通知が流れます。数回続くと、通知そのものが信用されなくなります。

項目ごとに任せる範囲を決めます。 全項目をまとめて「精度が足りない」と扱うと、確認の手間が減りません。日付と期間は自動、金額と特約は人、というように項目単位で線を引きます。

どの水準なら自動でよいか、一律の値は置けません。 契約の類型、原本の状態、間違えたときに何が起きるかで変わります。満了日を1日間違えるのと、賠償の上限を読み違えるのでは、影響の大きさが違います。項目ごとに、間違いが後から気付ける仕組みがあるかで決めます。

確認の記録を残します。 人が直した項目と、その前の抽出結果を両方残すと、どの項目の抽出が弱いかが分かります。抽出の指示を直す材料になり、任せる範囲を広げる判断の根拠にもなります。導入後に何が変わったかの測り方は AI導入の効果測定と投資判断を参照してください。

台帳の鮮度を保つ

台帳が使われなくなる原因は、作った直後の精度ではなく、更新が止まることです。止まる箇所は決まっています。

新しく締結した契約が載らない。 締結の工程と台帳への登録が別々だと、登録が個人の作業になります。締結の完了をもって取り込みが動く形にしておきます。電子契約サービスを使っている場合は、そこから取り込める項目を取り込み、紙で締結した契約は登録の経路を別に用意します。

覚書や変更契約が本体に紐づかない。 金額の改定、期間の延長、条項の追加は、別の文書として締結されます。台帳が本体の契約書だけを見ていると、値が古いまま残ります。本体と紐づける形で登録し、変更後の値を台帳の現在値として持ちます。変更前の値も履歴として残します。

解約・満了の結果が戻らない。 前の節のとおりです。判断の結果を台帳へ戻す経路を作ります。

台帳の項目を増やしすぎる。 使われない列が増えるほど、登録が面倒になります。増やすときは、その列を誰がいつ見るかを決めてから足します。

台帳を既存の文書管理や購買の仕組みとどうつなぐか、既製の契約管理サービスを使うかは、自社の状況で変わります。判断の材料は AIエージェントは自作か既製ツールかで整理しています。作る側の進め方、どこまでを検証してから本番に載せるかは AIエージェント開発の進め方を参照してください。

まとめ：契約の管理台帳と更新期限をAIで管理するときの要点

締結後に契約が見えなくなるのは、情報が原本の中にしかなく、期限が個人の記憶や予定表にしか無いため
台帳の項目は「期限の管理に要る項目」と「聞かれたときに答えたい項目」を分け、抽出の任せ方も項目ごとに変える
相手先・締結日・期間・自動更新の有無・申し出の期限は機械側で確定してよい。金額・賠償の上限・特約は人が確定させる
金額を人が持つのは精度の問題ではなく、覚書で改定されやすい項目だから
解約通知の期限は日付として保存せず、満了日と申し出の期間から計算する。更新が起きても台帳が古くならない
期間の定めがない契約は、満了日が空の状態として別に持つ。抽出漏れと区別できなくなる
既存契約の取り込みは締結年ではなく、いま効力があるか、期限の管理が要るかで範囲を決める
完了条件を「全件」にすると終わらない。自動更新の定めがある契約が載った時点で運用に入れ、残りは運用しながら足す
台帳の自動生成より先に、相手先・満了日・通知期限の3項目だけで通知を回す進め方も取れる
通知は、時期・載せる内容・返してもらう答え・未回答の扱いまで決める。知らせるだけの通知は読まれなくなる
抽出の精度は、取れなかった項目・違う値を返した項目・該当が無いのに値を返した項目の3つで数える
台帳が使われなくなるのは、新規契約・覚書・解約の結果が入らなくなったとき。この3つの経路を先に作る

Augueでは、書類から必要な項目を読み取って既存の管理表や業務システムへ反映し、期限や条件を通知するところまでの仕組みの開発に対応しています。自社の契約管理をどこから仕組みに寄せられるか整理したい方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

台帳の自動生成と期限の通知は、どちらから作るとよいですか？

通知からです。台帳の自動生成は抽出の精度を確かめる期間が要りますが、通知は相手先・満了日・通知期限の3項目が埋まっていれば動きます。手入力の台帳でも先に通知を回し、更新の判断が期限前に上がってくる状態を作ってから、抽出の自動化に取りかかる順序が崩れにくいです。

台帳を作り始める前に、社内で何を数えておけばよいですか？

3つあります。現在有効な契約の件数と類型の数、原本のうち検索できるテキストを持たないものの割合、いま期限を誰がどう管理しているか。この3つで取り込みの手間と、作る範囲の見当がつきます。費用の目安は件数と紙の割合、つなぎ先のツールで変わるため、これらを数える前に一律の値は出せません。

契約管理の既製サービスを使う場合と、自社で組む場合の違いは何ですか？

既製サービスは台帳の項目や通知の形が決まっている代わりに、導入してすぐ使えます。自社で組むと、既存の文書管理や購買の仕組みへつなぎ込み、自社の承認の流れに合わせられます。分かれ目は契約の件数より、社内の他の仕組みと突き合わせたい項目がどれだけあるかです。

電子契約サービスに入っている契約は、別に台帳を作る必要がありますか？

電子契約サービス上の一覧は、そのサービスで締結したものしか含みません。紙で締結した過去の契約や、相手方の環境で締結した契約は入らないため、全体を見るには別に台帳が要ります。電子契約側から取り込める項目は取り込み、台帳を全体の一覧として置く形が扱いやすいです。

更新の判断そのものをAIに任せられますか？

任せません。更新するかどうかは、取引の実績、相手との関係、来期の計画といった契約書の外にある材料で決まります。仕組みの側が持つのは、判断が必要な契約を期限前に、判断に要る情報を添えて担当者へ渡すところまでです。