労務管理システムで契約社員の更新日を通知する機能の設計｜アラート要件と作り込みの判断

労務管理システムの機能一覧に「契約更新アラート」と書かれていても、何を期限として検知し、誰に何日前に出すかは製品ごとに違います。契約終了日の一覧を出すだけの実装もあれば、無期転換申込権が発生する更新回を判定して人事へ回すものもあります。有期雇用の期限は、更新上限の明示、無期転換申込機会、雇止めの予告という性格の異なる三系統に分かれ、それぞれ起算点も通知先も別です。ここでは製品を比較する前に自社で書き出す通知要件を、根拠となる条文と告示から整理しました。

まとめ：契約更新の通知機能を要件にする前に決める三点

先に決めるのは三点です。一点目は、検知の起点を契約終了日だけに置かないこと。終了日から逆算するのは雇止めの予告だけで、無期転換申込権は通算開始日から数えた通算契約期間で決まり、更新上限は契約に設定した上限値との突き合わせで決まります。起点が三つある以上、契約行に持つ日付も三種類必要になります。

二点目は、通知先を現場管理者と人事で分けること。更新するかどうかを判断できるのは現場で、明示書面と説明の義務を負うのは人事です。同じ通知を全員へ一斉配信すると、誰も自分の作業だと認識しないまま満了日を迎えます。三点目は、通知の後に残す記録を先に決めること。更新上限を新設または短縮する場合は理由をあらかじめ説明する必要があり、その説明日と相手を後から示せなければ、通知機能があっても実務は守られません。

パッケージの標準機能で足りるのは、雇用形態が一つか二つで、契約期間が全員同じ長さに揃っていて、通算開始日が入社日と一致している会社です。この条件から外れる場合、たとえば有期の区分が三つ以上あり、在留期限や免許の有効期限も同じ画面で管理したいなら、既存の人事DBへ通知の仕組みを作り込むほうが結局早く収まります。判断の分かれ目は後半の章で条件付きで示します。製品ごとの機能範囲と費用の比べ方は労務管理システムとは？機能・勤怠管理との違いと比較の観点と労務管理システムの費用相場を先に見てください。既存システムへ通知と承認だけを足す設計はワークフローシステム開発で扱っています。

通知の対象になる期限：更新上限・無期転換申込機会・雇止め予告の三系統

有期雇用で管理する期限は一つではありません。三つの系統はそれぞれ別の法令を根拠に持ち、検知に使う日付も違います。まずこの分解をしないまま製品を見ると、「契約終了日が近い人の一覧」だけを見て要件を満たしたと誤認します。

2024年4月から明示義務となった更新上限の有無と内容という起点

2024年4月から、有期労働契約の締結と契約更新のタイミングごとに、更新上限の有無と内容を明示する義務が加わりました。更新上限とは、通算契約期間の上限または更新回数の上限を指します。上限を設けているなら「通算4年まで」「更新3回まで」といった値が契約に載るため、システム側はこの値を契約マスタの項目として保持できます。

厚生労働省の説明では、更新上限を新たに設ける、または短縮する場合、その理由を有期契約労働者にあらかじめ説明することが必要とされています。あらかじめ、という条件が付くため、上限を変える判断は更新面談より前に確定していなければなりません。通知の設計としては、上限に到達する一回手前の更新で人事へ知らせておきます。上限到達の更新時に初めて気づいても、説明の機会がすでに過ぎているからです。

労働契約法第18条の通算5年超とクーリングによる通算期間のリセット

無期転換申込権は、同一の使用者との有期労働契約の通算契約期間が5年を超えたときに発生します。労働契約法第18条にもとづく制度で、2013年4月1日に施行されました。通算対象になるのは2013年4月1日以後に開始した契約です。1年契約なら5回更新した後の6年目の契約期間中、3年契約なら1回更新した後の4年目の契約期間中に申込権が生じます。

検知を難しくしているのはクーリングです。有期労働契約が存在しない期間（無契約期間）が一定以上続くと、それ以前の契約期間は通算から除外される扱いです。厚生労働省の無期転換ポータルサイトのQ&Aでは、無契約期間の前の通算契約期間が1年以上ある場合、無契約期間が6ヶ月以上あればクーリングされ、6ヶ月未満ならクーリングされないと整理されています。通算契約期間が1年未満の場合は区分表で決まります。

この表がそのまま実装仕様です。通算開始日を入社日で固定して持つと、退職と再雇用をはさんだ社員で計算がずれます。制度そのものの適用範囲や申込手続きの解釈は無期転換ルールとは？適用要件と導入背景の解説に譲り、ここでは通算開始日を再計算できる形でデータを持つ、という設計要件だけを押さえます。

告示第357号が定める雇止め予告30日前と予告が不要になる契約の条件

更新しないと決めた場合に意識すべき期限も別です。「有期労働契約の締結、更新及び雇止めに関する基準」（平成15年10月22日厚生労働省告示第357号）の第1条は、契約を3回以上更新している、または雇入れの日から起算して1年を超えて継続勤務している者について、契約を更新しないこととしようとする場合には、少なくとも契約期間の満了する日の30日前までに予告しなければならないと定めています。ただし、あらかじめ契約を更新しない旨が明示されているものは除かれます。

ここから読み取れる実装条件は二つです。更新回数と継続勤務期間のどちらか一方でも条件を満たせば予告対象になること、そして契約時に「更新しない」と明示済みのフラグが立っていれば対象外になることです。フラグを持たない設計にすると、予告不要の契約にも通知が出続け、通知そのものが読まれなくなります。

同告示の第2条では、雇止めの予告後に労働者が理由の証明書を請求した場合、および雇止めの後に請求された場合、遅滞なく交付しなければならないとされています。証明書の交付は通知の後工程です。第3条では、1回以上更新し1年を超えて継続勤務している者との契約を更新する場合、契約の実態と本人の希望に応じて契約期間をできる限り長くするよう努める、とされています。更新のたびに機械的に同じ期間を設定し続ける運用は、この配慮と噛み合いません。

検知ロジックの設計：契約データのどの項目から何日前を計算するか

三系統の期限が分かれば、次は契約データの構造です。既存の人事マスタが社員1人1行で「契約終了日」を1項目しか持っていない場合、更新のたびに上書きされて履歴が消えます。この状態では通算契約期間も更新回数も再現できません。

通算開始日と更新回数を再現するための契約履歴テーブルの行構造

契約は社員マスタの属性ではなく、独立した履歴として1更新1行で持ちます。1行に必要なのは、契約開始日、契約終了日、契約期間の長さ、更新回数の連番、前契約の終了日から当契約の開始日までの空白日数、更新上限の有無と値、更新しない旨の明示フラグの七項目です。空白日数を行に持たせておけば、前掲のクーリング表と突き合わせて通算開始日を毎回計算し直せます。

通算契約期間は、この履歴を通算開始日から積み上げた値として求めます。導出値をテーブルに保存すると、後から契約日を訂正したときに再計算されず、5年到達の判定だけが古いまま残ります。参照のたびに計算する実装にしておくほうが安全です。入社時に契約情報をどう受け取り、どこへ引き渡すかは労務管理システムで雇用契約手続きを完結させる要件で扱っています。

期限種別ごとに変わる通知リードタイムと起算に使う日付の対応関係

「何日前に出すか」を一律にすると破綻します。雇止めの予告は満了日の30日前が法定の下限ですが、更新しないという判断そのものは、予告日より前に社内で確定していなければ間に合いません。無期転換申込機会の明示は更新のタイミングに紐づくため、契約書の作成に着手する時点で分かっている必要があります。

通知の目安は法定期限そのものではなく、社内で作業が終わる時刻から逆算した値を入れます。45日前という数字に法的な根拠があるわけではなく、30日前の予告に間に合わせるための社内リードタイムです。承認を1段はさむなら、その分だけ前へずらします。

通知の対象から外す条件：特例認定と更新しない旨の明示済み契約

全員を同じ条件で通知すると、出す必要のない通知が混ざります。除外の条件は三つに整理できます。

• 専門的知識等を有する有期雇用労働者等に関する特別措置法の第二種認定を受けており、定年後に引き続き雇用されている高齢者。認定を受けた対象期間中は無期転換申込権が発生しません
• 同法の第一種認定を受けた高度専門的知識等を有する者。年収1,075万円以上で一定の期間内に完了する業務に就く場合が対象で、特例の上限は10年です
• 契約締結時にあらかじめ更新しない旨を明示している契約。告示第357号第1条の予告義務の対象から外れます

除外は社員単位ではなく契約単位で判定します。第二種認定の対象になるのは定年後に引き続き雇用されている期間であって、その人の全期間ではないためです。認定の有無を人事マスタの属性として持つと、定年前の有期契約まで除外され、5年到達の検知が丸ごと落ちます。

通知先と承認フロー：現場管理者・人事・本人へ何をいつ渡すかの設計

通知が届いても更新手続きが止まるのは、宛先の設計を後回しにしたときです。誰が何を判断するのかを先に決め、その判断に必要な情報だけを載せます。

一次を現場管理者・二次を人事に振り分ける二段階リマインドの構成

一次通知は、契約終了日の60日前に現場の管理者へ出します。ここで求めるのは更新可否の意思表示だけです。二次通知は、一次に応答がないまま45日前を過ぎた契約について、人事へ回します。人事が現場へ催促するか、更新しない前提で予告の準備に入るかを選べる状態にしておきます。

本人への通知は、更新可否が確定してから出す設計が適切です。判断前の段階で本人に「契約終了日が近づいています」とだけ届くと、更新の可否を尋ねる問い合わせが人事へ集中します。無期転換申込機会の明示のように本人へ必ず届ける必要がある通知は、契約書の交付と同じ経路に載せて、明示書面の一部として扱うほうが記録も揃います。

更新可否の判断と説明の証跡を残すための承認フローの記録項目の設計

承認フローに載せるのは、更新するかどうかの選択と、その理由、そして誰がいつ承認したかです。更新上限を新設または短縮する場合は、あらかじめ理由を説明する必要があるため、説明した日付と相手と方法を記録項目として持たせます。面談で説明した、という事実だけをメモ欄に書く運用は、後から範囲を特定できません。

雇止めの理由の証明書は、請求があってから遅滞なく交付する義務の対象です。更新しないと決めた時点で理由を選択式と自由記述で残す設計が有効です。労働関係に関する重要な書類は労働基準法第109条により5年間の保存が求められ、附則第143条第3項により当分の間は3年間と読み替えられています。承認記録の保存年限もこれに合わせます。

通知が届いても更新が止まる三つの失敗パターンと再送の設計要件

失敗の形はおおむね決まっています。一つ目は、全社の人事担当メーリングリストへ一斉配信する設計です。宛先が組織になると、自分の担当分がどれか分からず全員が放置します。宛先は契約ごとの管理者アカウントに解決してから送ります。

二つ目は、管理者の異動で宛先が消える形です。管理者を契約行に直接持つと、異動後に通知の行き先が失われます。所属組織を経由して現在の管理者へ解決する参照にしておけば、異動しても宛先が追随します。三つ目は、月次バッチで月初にまとめて送る設計です。月末満了の契約は通知から満了までの日数が足りず、月初満了の契約は前々月に通知されて忘れられます。日次で判定し、該当日に送るほうが誤差は小さくなります。

未応答の扱いも決めます。応答がないまま二次通知の期日を過ぎた契約は、人事の作業一覧へ自動で積み、通知の再送だけで終わらせないことです。通知を送った事実ではなく、更新可否が確定した事実を完了条件にします。

パッケージの標準機能で足りる条件と人事DBへ作り込む条件の分かれ目

ここは明確に言い切れる部分です。契約更新の通知は、条件が揃えば既製の労務管理システムで完結しますし、揃わなければ既製品を入れても運用でしのぐことになります。判断は機能の有無ではなく、自社の契約構造で決まります。

既製の労務管理システムのままで運用が回る三つの判定条件と具体例

次の三つを全て満たすなら、パッケージの契約更新管理機能で足ります。有期の雇用区分が一つか二つに収まっていること。契約期間が区分ごとに同じ長さで、個別の期間設定が例外的であること。そして、通算開始日が入社日と一致していて、退職と再雇用をはさんだ社員がいないことです。

この条件下では、通知に必要な計算が契約終了日からの単純な減算と、更新回数の連番だけで完結します。SmartHRやfreee人事労務、ジンジャー人事労務といった製品が備える契約更新管理やアラートの機能は、この範囲を対象にしています。標準機能で足りるなら作り込まないのが正解で、通知のためだけに開発費を出す理由はありません。

既存の人事DBへ通知を作り込む判断になる四つの典型パターンの整理

逆に、次のいずれかに当たるなら、パッケージの標準機能から外れます。

• 有期の雇用区分が三つ以上あり、区分ごとに更新上限も承認者も違う。区分の追加のたびに設定で吸収できず、分岐が本体側の制約に当たります
• 契約更新以外の期限を同じ画面で扱う。在留期間の満了日、免許や資格の有効期限、試用期間の満了、健康診断の期日などを一本の通知基盤に載せる場合です
• グループ会社間の出向や転籍があり、通算契約期間の判定に他社での期間を含める必要がある。使用者が同一かどうかの判断が入るため、単純な社員単位の集計では計算できません
• 既存の人事給与システムを残す前提で、契約データの正がそちら側にある。二重入力を避けるなら、通知だけを外に置いて参照する構成になります

四つ目が最も多い形です。人事給与を入れ替える判断は数年単位になりますが、通知の不備は次の更新までに直したい。この時間差が、既存DBを参照する通知の作り込みという選択に落ち着く理由です。

通知だけを外付けするときの実装範囲と費用の見積もりの取り方の基準

作り込むといっても、人事システムを作り替えるわけではありません。範囲は三つに絞れます。契約履歴を日次で読み取って期限を判定するバッチ、通知先を組織から解決する参照テーブル、更新可否を受け取って記録する承認画面です。既存DBは参照に徹し、更新はしない構成にすると、既存システムの改修を伴わずに済みます。

費用の桁を決めるのは、通知の種類と承認の段数です。期限が契約更新の一種類で承認が一段なら費用は小さく収まる一方、在留期限や免許期限まで含めて種類が増え、区分ごとに承認者が変わる場合、分岐の数に応じて費用が膨らむ構造です。見積もりを取る前に、期限の種類と承認の段数を先に数えて渡すと比較しやすくなります。承認と通知の基盤をどう組むかはワークフローシステム開発で個別に設計しています。勤怠の打刻データを判断材料に加えたい場合の考え方は勤怠管理システムとは？機能・種類・費用と選び方を参照してください。

よくある質問

契約更新の通知機能について、要件を書き出す段階で迷いやすい点をまとめました。

契約更新の通知は法律で義務づけられているのですか？

通知機能そのものを義務づける規定はありません。義務があるのは、更新のタイミングごとの労働条件明示（更新上限の有無と内容、無期転換申込機会、無期転換後の労働条件）と、告示第357号第1条にもとづく雇止めの予告です。通知は、この明示と予告を期限内に行うための社内の仕組みという位置づけになります。したがって通知の宛先も日数も社内で決めてよく、法定の30日前という数字は予告の下限であって通知の基準ではありません。

無期転換の通算契約期間はいつから数え始めればよいですか？

通算対象になるのは2013年4月1日以後に開始した有期労働契約です。それ以前から継続していた契約は、2013年4月1日以後に開始した契約から数えます。途中に無契約期間がある場合はクーリングの判定が入り、直前の通算契約期間が1年以上なら無契約期間6ヶ月以上でリセットされます。1年未満の場合は区分表に従うため、システム側は入社日ではなく契約履歴から通算開始日を毎回導出する形にしてください。

雇止めの予告は対象者全員に30日前で出す必要がありますか？

対象になるのは、契約を3回以上更新している者、または雇入れの日から起算して1年を超えて継続勤務している者です。ただし、あらかじめ契約を更新しない旨を明示している契約は除かれます。つまり初回契約で期間満了により終了する場合は予告の対象外です。システムでは更新回数と継続勤務期間の両方を判定し、更新しない旨の明示フラグで除外する三条件の組み合わせで抽出します。

勤怠管理システムのアラート機能で代用できますか？

難しいと考えてください。勤怠側のアラートは打刻や労働時間の集計値を対象にしており、判定に使うのは日々の実績データです。契約更新の通知に必要なのは契約履歴と通算期間で、データの持ち主が違います。勤怠側に契約終了日を手入力して通知させる運用は作れますが、更新のたびに二重入力が発生し、通算開始日の再計算もできません。契約データを正としている側で判定するのが素直です。

在留期限や免許の有効期限も同じ仕組みで通知できますか？

同じ通知基盤に載せられますが、期限の性格が違う点は設計に反映してください。契約更新は更新可否の判断が先にあり承認を伴いますが、在留期間の満了や免許の更新は本人の手続きが主で、会社側は督促と確認にまわります。承認フローを共通化すると在留期限の通知にも承認者が必要になり、運用が重くなります。判定と通知の基盤は共通、承認の要否は期限種別ごとに切り替える構成が扱いやすい形です。

関連記事

• 労務管理システムとは？機能・勤怠管理との違いと比較の観点・個別開発の判断軸を解説【2026年】：システム全体の機能範囲と選定の観点です。
• 労務管理システムの費用相場とは？クラウド・無料・受託開発のコストと選び方を解説【2026年】：導入と開発にかかる費用の内訳です。
• 無期転換ルールとは？法律改正で導入された制度の目的、適用要件、導入背景などを詳しく解説：通知の根拠になる制度そのものの解説です。
• 労務管理システムで雇用契約手続きを完結させる要件｜電子交付の条件と入社書類の設計：契約データが生まれる入社時の設計です。
• 勤怠管理システムとは？機能・種類・費用と失敗しない選び方を解説【2026年】：隣接する勤怠側の機能範囲です。