契約管理の更新期限、見落としを防ぐには？ kintone×n8n×生成AIで「期限抽出はAI・判断は人」に分ける方法

契約の更新期限、結局どうやって管理するのが正解なのか

取引基本契約、リース、サブスクリプション、賃貸借。

会社には種類の違う契約が次々に増え、契約管理は少しずつ複雑になっていきます。

契約書が部署ごとのフォルダやキャビネットに分かれて保管され、更新期限は担当者が個別のファイルで管理されているケースは珍しくありません。

そもそも契約管理とは、契約書の保管から、更新期限や条件の把握、更新・解約の判断までを含む一連の業務です。

このうち保管や期限管理の手段には、紙のファイリング、共有サーバーへの保存、Excelの契約管理台帳、専用の契約管理システムといった選択肢があります。

紙や共有サーバーへの保存は、探すのに手間がかかり、期限が近づいても自動では知らせてくれません。

そこで「更新期限を見落とさない方法」を調べると、たいていは専用の契約管理システムを導入する話に行き着きます。

見落としをなくしたいなら、専用のシステムを入れるのが当たり前だ。

これが世間の常識です。

ただ、総務や法務を1人、あるいは少人数で兼務していると、専用システムの導入には「そこまでの規模ではない」と踏み込みづらい事情もあります。

本当に専用システムを買わないと、この問題は解決できないのでしょうか。

専用システムを買わなくても、kintoneで更新期限は仕組みで管理できる

先に結論をお伝えします。

やることは大きく2つです。

1つは、契約書から更新期限を生成AIに読み取らせて、kintoneの契約台帳に登録すること。

もう1つは、n8nを使い、期限が近づいたら段階的にアラートを出すことです。

この仕組みを組めば、専用の契約管理システムを買わなくても、更新期限の見落としは防げます。

ただし、丸ごと自動に任せてよいわけではありません。

勘所は「期限を抽出するのはAI、更新するか解約するかを判断するのは人」と、役割をはっきり分けることです。

なぜこの線引きが必要なのか、そしてどこでつまずきやすいのかは、このあと順番に説明します。

この仕組みで使う生成AIとn8nは、いずれも大きな初期投資を必要としません。

n8nはクラウド版であれば、年間契約の場合で月額数千円程度から始められるプランがあります（料金はn8n公式の料金ページで確認できます）。

生成AIの読み取りも従量課金で、契約1件あたりの費用は小さく収まります。

契約の件数が少ないうちは、こうした従量課金の組み合わせから小さく試せるのが利点です。

台帳が“不完全”になるのは、手入力の工程が破綻しているから

更新期限の見落としが起こる本当の原因は、担当者の不注意ではありません。

契約書を人が一件ずつ読んで、期限を台帳に手入力する工程が追いつかなくなることが原因です。

更新期限や、自動更新条項があるかどうかは、契約書の条文を読まなければわかりません。

読み取った内容を、担当者がExcelの契約管理台帳に一件ずつ手で入力していきます。

取引先や設備、サービスの契約が数十件に増えてくると、条文を1件ずつ読んで台帳に転記する作業は、片手間では回らなくなります。

総務や法務を兼務している担当者は、日々の別の業務も抱えているためです。

その結果、台帳への入力が後回しになり、いくつかの契約が抜け落ちたまま、虫食いの台帳ができあがります。

ここが見落としの本当の入り口です。

台帳が完全に整っていて初めて、通知の仕組みも意味を持ちます。

抜け落ちた契約の期限は、そもそも通知の対象にすらならないからです。

この点は、専用の契約管理システムを入れても変わりません。

システムを導入しても、契約書を読んで期限を入力する工程が人の手作業として残るなら、同じように台帳は虫食いになります。

つまり、手を入れるべきなのは「通知の仕組み」より前の、「台帳を埋める工程」なのです。

契約管理の台帳が不完全になる原因と、生成AIで手入力工程を肩代わりして台帳を埋めるBefore/Afterの図

この工程を生成AIに肩代わりさせれば、担当者は入力作業から解放され、本来やるべき判断に時間を使えるようになります。

なお、この仕組みは特別なエンジニアがいなくても構築できます。

kintoneでアプリを作れる担当者であれば、手が届く範囲です。

ただし、社内で構築や運用にあてる時間を確保できるかどうかは、また別の問題になります。

“システムを入れれば安心”のはずが、こんな見落としが起きる

総務と法務を兼務する担当者が置かれた、ある中小企業では、こんな見落としが起きていました。

取引基本契約やリース、サブスク、賃貸借といった契約書が部署ごとのフォルダやキャビネットに分散し、更新期限は個別のファイルで管理していたのです。

契約の棚卸しは四半期に一度がやっとで、その間に期限が過ぎていないかは、担当者の記憶と個別ファイルだけが頼りでした。

その結果、2つのことが起こります。

1つは、自動更新条項のある契約が、見直すつもりだったのに気づかないうちに1年更新されてしまったこと。

もう1つは、逆に更新の手続きを忘れて、必要な契約が失効しかけたことです。

「契約管理システムを導入すれば解決する」と考えて検討もしました。

しかし、結局はすべての契約の期限を誰かが手入力する必要があり、その入力が追いつかずに頓挫したのです。

こうした失敗の裏には、いくつかの共通したつまずきがあります。

順番に見ていきましょう。

AIに契約書を読ませても、そのまま台帳に入れると誤抽出が紛れる

「契約書を生成AIに読ませれば、期限の入力はなくせる」と考えて、抽出した結果をそのまま台帳に流し込む。

これが最初のつまずきです。

契約書は、条項の言い回しが1通ごとに異なります。

「更新」「延長」「継続」といった言葉の使い方も契約によってさまざまで、自動更新条項があるかどうかの表現も一定ではありません。

生成AIはこうした文章の読み取りに強い一方で、条文が複雑な契約では期限を読み違えたり、条項の有無を取りこぼしたりすることがあります。

抽出した内容を人が確認しないまま台帳に登録すると、不正確な台帳のうえで通知が動き、結局は見落としにつながります。

「契約満了日」と「解約通知の期限」を混同すると、アラートが手遅れになる

2つ目のつまずきは、台帳に「契約満了日」しか持たせないことです。

自動更新条項のある契約では、満了日の一定期間前までに更新しない意思を通知しないと、自動的に更新されてしまうものが少なくありません。

この通知期間は契約書ごとに定められており、一律ではありません。

自社の契約書の条文を、まず確認しておく必要があります。

いずれにしても、本当に管理すべき期限は満了日そのものではなく、その手前にある「解約通知の期限」です。

満了日だけを台帳に登録してアラートを出すと、気づいたときには通知の期限をとうに過ぎている、という事態になりかねません。

そのため、満了日と解約通知の期限は、台帳のなかで別の項目として持つ必要があります。

契約管理の時間軸で解約通知の期限が満了日の手前にあることを示すタイムライン図

アラートを一度きり・無人任せにすると、結局見落とす

3つ目のつまずきは、通知の出し方です。

期限が近づいたときに、1回だけ通知を出す。

一見よさそうですが、多忙な兼務担当者は、その1通を他のメールに埋もれさせてしまいがちです。

かといって、見落としを恐れるあまり「AIが期限を判断して、更新や解約まで自動で実行する」仕組みにするのは危険です。

前述のとおり、AIの抽出には誤りが紛れます。

誰の目にも触れないまま更新や解約が実行されると、誤った判断がそのまま取り返しのつかない結果になりかねません。

kintone×n8nで「抽出はAI・判断は人」に組み立てる

3つのつまずきに、1つずつ対応する形で設計を考えます。

全体像は次のとおりです。契約書を読み取って台帳を埋める上段の流れと、期限が近づいたら段階的に知らせる下段の流れの、2つで組み立てます。

生成AIの抽出は“台帳の下書き”。人が一度確認して確定する二段構えにする

まず、契約書のPDFを生成AIに読ませ、更新期限、解約通知の期限、自動更新条項の有無といった要点を構造化して抽出します。

実際に生成AIのノードを動かすと、更新期限・解約通知の期限・自動更新条項の有無が構造化された形で出力されます。

抽出した内容は、いきなり確定させず、kintoneの契約台帳に「未確認」の状態でいったん登録しておくのがポイントです。

抽出結果が入ったkintoneの契約台帳のレコードは、確認ステータスが「未確認」のまま、人の確認を待っている状態です。

そのうえで、担当者が抽出結果を一度だけ確認し、問題がなければ「確認済み」に切り替えて確定させます。

ここで大切なのは、AIの役割はあくまで台帳の下書きを埋めることまでと割り切る点です。

全文を人が読んで手入力する作業はなくなりますが、最終的に台帳の内容を確定させるのは、あくまで人です。

この二段構えにすれば、AIの誤抽出が確認の段階で止まり、不正確な台帳のまま通知が動く事態を防げます。

生成AIに契約書のような文書を読み取らせる基本的な考え方は、kintoneユーザーのための生成AI実践大全でも解説しています。

台帳には「通知期限」を必ず別項目で持ち、そこを起点にアラートする

次に、kintoneの契約台帳の項目設計です。

「契約満了日」だけでなく、「解約通知の期限」と「自動更新条項の有無」を、それぞれ別の項目として持たせます。

下の画面が、その項目設計にそって作った契約台帳です。「契約満了日」とは別に「解約通知期限」の列があり、契約ごとに確認ステータスもひと目で分かります。

そして、アラートの起点は満了日ではなく、解約通知の期限に置くのがポイントです。

ここで押さえておきたいのは、kintone単体でもできることと、n8nを足して初めてできることの線引きです。

実は、日付を基準にした段階的な通知そのものは、kintone標準のリマインダー機能でも設定できます（設定方法はkintone公式ヘルプのリマインダー通知の説明にまとまっています）。

解約通知の期限を基準に、複数の条件で事前に知らせる運用は、標準機能の範囲でも十分に組めます。

一方で、Teamsなど社外ツールへの通知や、次に説明する「決裁者への更新可否伺い」という分岐を含む流れは、標準機能だけでは組みにくいものです。

この部分をn8nで補うことで、抽出から通知、判断の依頼までを一続きにできます。

n8nで段階的にアラートし、最後は決裁者への“更新可否伺い”に回す

最後に、通知と判断依頼の流れです。

n8nを使い、解約通知の期限に向けて段階的にアラートを出します。

たとえば期限の60日前、30日前、そして直前と、複数回にわたってTeamsなどに通知を送る形です。

何日前にどの段階の通知を出すかは、下の画面のようなしきい値のマスタに切り出しておくと、運用しながら調整できます。

1回きりの通知と違い、段階的に知らせることで、多忙な担当者が見逃す確率を下げられます。

n8nが各契約の残り日数を判定し、解約通知の期限までの日数に応じて段階が振り分けられます。まだ確認していない契約や、すでに更新・解約が済んだ契約は対象から外れます。

そして最終段では、更新するか、条件を交渉するか、解約するかを決める決裁者へ、更新可否の伺いを自動で回します。

このとき、決裁者が検討する時間を見込んだタイミングで伺いを出すことが大切です。Teamsでは、担当者への段階アラートと、決裁者への更新可否の伺いが、それぞれ届きます。

期限を抽出して知らせるところまではAIと自動化に任せ、最後の判断は人が担う。この線引きが、丸ごと自動化との決定的な違いになります。

契約書PDFの生成AI抽出からkintone台帳・n8n段階アラート・決裁者の更新可否判断までの流れと役割分担を示す図

台帳が自動で埋まれば、人は“判断”だけに集中できる

仕組みが一通り整うと、契約管理の景色が変わります。

手入力で埋めていた台帳が、生成AIの抽出と人の確認で埋まるようになるのです。

担当者の仕事は、ゼロから入力することではなく、AIが用意した下書きを確認することへと移ります。

そして、つまずきやすい場所は、次の3つです。

  • 抽出結果を確認せずに台帳へ流し込むこと
  • 満了日と解約通知の期限を混同すること
  • 通知を一度きり、あるいは無人任せにすること

この3か所を先に押さえておけば、専用の契約管理システムを買わなくても、更新期限の管理は自社の手で組めます。

費用の面でも、月額数千円程度から使えるn8nと、契約1件あたりの利用料が小さい生成AIの組み合わせなら、契約件数が少ないうちから小さく始められます。

もっとも、技術的に組めることと、社内で構築や運用の時間を確保できることは別の問題です。

そこは体制の話として切り分けて考える必要があります。

まとめ

契約更新の見落としで本当に破綻しているのは、契約書を人が一件ずつ読んで台帳に手入力する工程です。

ここが追いつかないから台帳が不完全になり、通知の仕組みも機能しません。

だからこそ、期限を抽出するのは生成AIに任せてkintoneの台帳を埋め、n8nで段階的にアラートを出します。

そして、更新するか解約するかの判断を握るのは、あくまで人です。

この「抽出はAI・判断は人」の二段構えなら、専用システムを買わなくても、兼務体制のまま見落としを防げます。

なお、この記事で扱ったのは契約を結んだあとの「更新期限の管理」です。

契約を結ぶ段階、つまり契約書の送付から締結後の処理までを自動化する方法については、kintone×クラウドサイン×n8nで契約締結の前後を自動化する記事で紹介しています。

最後に

自社の契約の種類や社内の運用は会社ごとに違い、どこでつまずくか、どう組むのが最適かも変わります。

「自社の場合はどう組めばいいのか」「そもそも自社で運用できるのか」で判断がつかない場合は、一度ご相談ください。

kintoneと生成AI、n8nを組み合わせた業務自動化について、ものづくりAI自動化ファクトリーの無料相談でお手伝いします。

関連記事