契約管理台帳で更新期限を管理するには、締結済みの契約から満了日・自動更新の定め・解約の申し出期限を読み取って台帳に載せ、申し出の期限を満了日から計算して、判断が間に合う時期に担当者へ知らせます。読み取りと期限の計算と通知は仕組みに任せられますが、金額や特約の確定と、更新するかどうかの判断は人が持ちます。取り込みは、いま効力があって自動更新の定めがある契約から始めれば、全件を載せる前に見落としを止められます。

この記事の答え

  • 契約管理台帳には満了日・自動更新の有無・解約の申し出期限を持たせ、申し出の期限は日付で保存せず満了日から計算する
  • AIに確定させてよいのは期間や更新条件のように条文に一意に書かれた項目までで、金額・特約・更新の判断は人が持つ
  • まず自動更新の定めがある有効な契約だけを載せ、相手先・満了日・通知期限の3項目で通知を回すところから始める

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

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

契約の更新期限の管理で起きる3つの見落とし

締結後の契約で起きる見落としは、次の3つに分かれます。

自動更新に気付かないまま更新される

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

解約したいときに、通知が間に合わない

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

契約の内容を聞かれても、すぐに答えられない

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

見落としの原因と、台帳づくりの着手の順番

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

すでに社内にある契約をまとめて載せる場合は、着手の順番で負担が変わります。全件のスキャンから始めると紙の原本を探す作業で止まるため、いま効力があって自動更新の定めがある契約へ範囲を絞り、満了日と通知期限が分かる最小限の一覧から通知を回します。抽出の自動化や台帳の項目を増やすのは、そのあとでも間に合います。

締結前のレビューは別の工程として扱い、ここでは締結してからの管理を対象にします。

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

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

台帳の項目ごとの抽出の任せ方

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

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

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

金額を人が確定させる理由

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

契約書の読み取り方式の選び方

読み取りの仕組みをどう選ぶかは、原本の状態で変わります。契約書は書式が相手方ごとに違い、条項の並び順も一定ではないため、紙面の位置ではなく文の意味で読む方式が向きます。決まった書式の帳票を読む場合とは選び方が違います。

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

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

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

台帳には日付ではなく更新の条件を持たせる

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

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

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

期限の計算で先に決めておく3つのこと

計算の決まりは、契約を載せ始める前に決めておきます。

「3か月前まで」の数え方

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

期限が休日に当たるときの扱い

期限が休日に重なるときに前倒しするかどうかを決めます。実務上は、期限そのものより先に社内の判断が終わっている状態を作るほうが大切です。

期間が「1年間」以外の契約

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

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

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

締結済み契約の取り込みから、期限の通知までの流れ 仕組みが契約書を読み取って項目を抽出し、金額や特約は人が確定する。仕組みが台帳へ反映して満了日から通知期限を計算し、担当者へ通知する。更新するか解約するかは人が決め、結果を台帳へ戻す。 ・読み取り・計算・通知は仕組み、金額や特約の確定と更新の判断は人 ・判断の結果を台帳へ戻さないと、次の期間の満了日がずれたまま通知が動き続ける 仕 組 み 担 当 者 取り込みと抽 出 ・原本をテキス ト化 ・満了日・更新 条件を読む 確定 ・金額・特約は 人が決める 台帳へ反映 ・原本へのリン クを添える 期限の計算と 通知 ・満了日から通 知期限を出す 更新か解約か ・取引の実績や 来期の計画で決 める 結果を台帳へ 戻す ・次の満了日へ 進める 契約管理台帳(満了日・更新の条件・申し出の期限・原本へのリンク)
抽出と期限の計算と通知は仕組みが持ち、金額や特約の確定と更新の判断は人が持ちます。
判断の結果を台帳へ戻すところまでが1周です。

判断の結果を台帳へ戻す経路を作る

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

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

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

有効な契約と期限の管理の要否で範囲を決める

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

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

原本の状態ごとの取り込み方

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

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

取り込みの完了条件と、通知から始める進め方

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

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

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

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

通知先と通知の時期

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

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

通知に載せる内容と、返してもらう答え

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

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

期限までに回答がない契約の扱い

仕組みの側で解約を選ぶことはできないため、未回答の契約は人の側で引き取る経路を決めます。上位の役職者へ知らせる、未回答の一覧を定期的に出す、といった形です。

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

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

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

抽出結果を3種類の誤りで数える

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

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

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

任せる範囲を項目ごとに決める

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

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

確認の記録を残して、任せる範囲を広げる

人が直した項目と、その前の抽出結果を両方残すと、どの項目の抽出が弱いかが分かります。抽出の指示を直す材料になり、任せる範囲を広げる判断の根拠にもなります。導入の前後で確認の時間がどれだけ変わったかも、同じ記録から測れます。

契約管理台帳の鮮度を保つ

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

台帳の更新が止まる4つの箇所

次の4つの経路を、台帳を作るのと同時に用意します。

新しく締結した契約が載らない

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

覚書や変更契約が本体に紐づかない

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

解約・満了の結果が戻らない

更新か解約かの判断の結果を台帳へ戻す経路が無いと、満了日がずれたまま通知が動き続けます。判断を受け取る形と、台帳へ書き戻す担当を決めておきます。

台帳の項目を増やしすぎる

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

既存の仕組みとのつなぎ方を決める

台帳を既存の文書管理や購買の仕組みとどうつなぐか、既製の契約管理サービスを使うかは、社内の他の仕組みと突き合わせたい項目の多さで決まります。突き合わせが少なければ既製のサービスで足り、多ければ自社で組む余地が出てきます。

自社で組む場合は、抽出の精度をどこまで確かめてから本番の台帳へ書き込ませるかを、着手の前に決めておきます。

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

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

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

自社専用のAIエージェントを作りませんか?

Augue AX サービス資料 Service Guide

作るか既製品を使うか、費用の目安から相談できます。使うほど育ち、成果が続くAIエージェントの開発をご支援します。開発の進め方と事例はサービス資料でご覧いただけます。

資料をダウンロードする無料相談に申し込む

よくある質問

契約管理台帳はExcelやスプレッドシートで始めてもよいですか?

始められます。最初に要るのは相手先、満了日、自動更新の有無、申し出の期限、担当者の列と、原本の置き場所です。件数が増えて同時に編集する人が増えたり、覚書の履歴を契約ごとに追いたくなったりした時点で、専用の仕組みへ移すかを考えれば足ります。表計算で始める場合も、申し出の期限は手で書かずに満了日から計算する式にしておくと、移すときに作り直す箇所が減ります。

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

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

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

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

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

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

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

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