--- title: "クラウド型勤怠管理システムとは？オンプレとの判断基準・打刻端末・SLAの確認点【2026年】" url: "https://www.issoh.co.jp/column/details/18250/" published: 2026-10-11 updated: 2026-10-11 categories: ["DX"] publisher: "株式会社一創" --- # クラウド型勤怠管理システムとは？オンプレとの判断基準・打刻端末・SLAの確認点【2026年】 クラウド型の勤怠管理システムは、契約したその月から打刻と集計を始められる手軽さが売りです。一方で、工場の入口に据えたICカードリーダーがつながるか、自社の手当計算を設定だけで再現できるか、サービスが止まった朝に打刻をどう残すかは、料金表を見ても分かりません。この記事では、クラウド型とオンプレミス型の違いを運用の責任分担から整理し、打刻端末との接続、設定でできる範囲、稼働率やデータ返却といったSLAの読み方を、IPAの手引きと労働基準法の規定に沿って確かめます。最後に、クラウド型で足りる条件と、オンプレミス型や受託開発に切り替える条件を示します。 ## まとめ：クラウド型の勤怠管理システムを選ぶ前に固める3つの確認点 多くの企業にとって、勤怠管理システムはクラウド型で足ります。法改正に合わせた計算ロジックの更新をベンダーが担い、サーバーの保守も要らないためです。迷う余地があるのは、次の3点のどれかで引っかかる場合に限られます。 1つ目は打刻端末です。既存のタイムレコーダーや入退館ゲートを使い続けたいなら、そのクラウド製品が対応する機器と接続方式を先に確認します。2つ目は設定の範囲で、独自の勤務区分や手当がパラメータで表現できるかを、自社で最も複雑な就業規則を使って試してください。3つ目はSLAで、稼働率の保証値、障害時の連絡、解約時に打刻の生データを返してもらえるかを契約前に書面で確かめます。 この3点で詰まらなければクラウド型を選び、詰まるなら連携部分だけを開発で補うか、オンプレミス型や受託開発に切り替えます。判断の具体的な線は後半の章で示します。 ## クラウド型とオンプレミス型の勤怠管理システムを運用の責任分担で比べる 両者の違いは「どこにサーバーがあるか」より、「誰が何に責任を持つか」で比べると判断に直結します。 ### サーバー保守・法改正対応・障害復旧を担う主体の違いを表で整理 クラウド型ではベンダーがアプリケーションから基盤までを運用し、利用企業は設定と利用者管理を受け持ちます。オンプレミス型では、サーバーの調達から障害対応まで自社か保守委託先の仕事になります。 | 項目 | クラウド型 | オンプレミス型 | | -------------- | ------------ | ------------- | | サーバー調達・保守 | ベンダー | 自社または保守委託先 | | 法改正に伴う計算ロジック更新 | ベンダーが製品更新で対応 | 保守契約の範囲で個別に改修 | | 障害時の復旧 | ベンダー次第・自社は待つ | 自社で手順を組める | | カスタマイズ | 用意された設定の範囲内 | ソースや設計から変更可能 | | データの保管場所 | ベンダーのデータセンター | 自社の管理下 | 表のうち、実務上もっとも効いてくるのは2行目です。割増賃金率や時間外労働の上限規制が改正されるたびに、オンプレミス型では改修の見積もりと検証が発生します。クラウド型はこの負担がない代わりに、障害時の復旧を自社で早められません。どちらの不自由を受け入れるかが選択の本質です。 ### IPAの手引きが挙げるクラウド利用時の制約5項目と勤怠での現れ方 IPAの[中小企業のためのクラウドサービス安全利用の手引き](https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme%5Fguideline%5Fv4.0%5Fapp%5Fcloudservice.pdf)（2026年6月版）は、クラウド利用で留意すべき事項として、コンピュータを自ら管理しない制約、データを社外に預ける不安、利用量の増加に伴う使用料の急増、カスタマイズの制約、アプリケーション間のデータ連携の制約やコスト増、の5つを挙げています。 勤怠管理に当てはめると、重いのは後ろの2つです。カスタマイズの制約は独自手当の計算に、データ連携の制約は給与計算や基幹システムへの受け渡しに直結します。使用料の増加は、勤怠製品の多くが従業員数に応じた月額課金なので、人員計画をもとに予測できるものです。料金の相場感は[勤怠管理システムの機能・種類・費用を整理した総合ガイド](https://www.issoh.co.jp/column/details/15081/)にまとめているので、ここでは制約の側に絞って確認を進めます。 ## クラウド型の勤怠管理システムと打刻端末をつなぐ方式と事前の確認事項 競合の解説ではあまり触れられませんが、クラウド化でつまずきやすいのは打刻の入口です。 ### スマホ・PC・ICカードリーダー・入退館ゲートの4方式で変わる接続条件 打刻の経路は大きく4つに分かれ、方式ごとに確認すべき点が違います。 - スマホアプリ・ブラウザ打刻：端末の準備は不要。位置情報の取得可否と、私物端末を使わせる社内規程の整備が論点 - PCのログオン・ログオフ記録：PCに常駐ソフトを入れる製品が多く、情報システム部門の配布手順が要る - ICカードリーダー：据え置きのタブレットやPCにリーダーをUSB接続する製品と、ネットワーク接続の専用端末を使う製品がある。既存の社員証カードの規格に対応するかを必ず確認する - 入退館ゲート・既存タイムレコーダー：クラウド製品側に標準の連携がなければ、ゲート側のログをCSVやAPIで取り込む連携の開発が必要になる 既存の社員証やゲートをそのまま使いたい企業ほど、4つ目で費用が膨らみます。製品の対応機器一覧に自社の機種名が載っているかを、見積もりより前に確かめておくと手戻りがありません。打刻方式そのものの選び方は[打刻の方式6種と客観的な記録の条件を解説した記事](https://www.issoh.co.jp/column/details/17276/)で詳しく比較しています。 ### 回線断やサービス停止の朝に打刻を失わないオフライン時の記録設計 クラウド型は、職場の回線やベンダーのサービスが止まると打刻を受け付けられません。始業時刻に止まれば、数十人から数百人分の打刻が一度に抜けます。 対策は2段構えです。まず、端末側で打刻を一時保存し、回線の復旧後に送信する機能が製品にあるかを確認します。無い場合は、停止時に紙の出勤簿か別経路の打刻に切り替える手順を就業規則の運用ルールとして決め、復旧後に管理者が修正入力する流れまで用意してください。修正入力は誰がいつ行ったかを履歴に残せる製品を選ぶと、後で記録の正しさを説明できます。 ### 厚生労働省ガイドラインの客観的な記録をクラウド上で満たす条件 厚生労働省の[労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン](https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/koyou%5Froudou/roudoukijun/roudouzikan/070614-2.html)（平成29年1月20日策定）は、始業・終業時刻をタイムカード、ICカード、パソコンの使用時間の記録などの客観的な記録で確認することを原則としています。 クラウド型でこの原則を満たすには、スマホやブラウザの自己入力だけに頼らない構成にします。ICカードやPCログのような機械的な記録を主にして、自己申告は補正用に使う形です。テレワークの比率が高く、PCログとの突き合わせが中心になる企業は、[テレワークの打刻と中抜けの管理方法を整理した記事](https://www.issoh.co.jp/column/details/15452/)もあわせて確認してください。 ## クラウド型の勤怠管理システムで設定できる範囲とカスタマイズの限界 クラウド型の「カスタマイズできない」は、正確には「用意されたパラメータの外に出られない」という意味です。境界を知れば、事前に見極められます。 ### 勤務区分・締め日・承認経路など標準設定で吸収できる勤怠の典型項目 主要なクラウド製品は、次のような項目を管理画面の設定で持てるのが一般的です。 - 雇用形態ごとの所定労働時間・休日カレンダー・締め日 - フレックスタイム制・変形労働時間制・シフト制の勤務パターン - 残業・休暇申請の承認経路と代理承認 - 時間外労働の上限に近づいたときのアラートのしきい値 - 給与計算ソフト向けのCSV出力レイアウト このうち最初に試すべきは勤務パターンです。自社で最も複雑な部署の就業規則を1つ選び、無料トライアルの期間中に実際に設定して1か月分を集計させると、設定で足りるかがはっきりします。無料プランの範囲で検証するときの人数や機能の制限は、[勤怠管理システムの無料プランの上限を整理した記事](https://www.issoh.co.jp/column/details/17475/)で確認できます。 ### 独自手当の計算式や基幹システム連携が設定の外に出る失敗パターン 設定で吸収できないのは、計算式そのものを書き換える必要がある要件です。現場ごとに単価の違う作業手当、深夜と休日が重なったときの社内独自の加算、生産管理システムの作業実績と勤怠を突き合わせた工数配賦などが典型です。 失敗しやすいのは、こうした要件を「運用で何とかなる」と判断して契約し、毎月Excelで手計算を足す運用が残るパターンです。クラウド化で消したかった集計作業が、形を変えて戻ってきます。給与計算側で吸収できるか、APIで外部の計算処理へ渡せるかを契約前に確認し、どちらも無理なら次の章の判断に進みます。 ## クラウド型勤怠管理システムのSLAと利用終了時のデータ返却の確認項目 SLA（サービスレベル合意書）は、料金表の次に読むべき書類です。勤怠データは記録の保存義務があるため、可用性とデータの扱いを分けて確認します。 ### 稼働率99.9%と99.5%で月の停止許容時間が変わる計算と障害時の連絡 IPAの手引きは、選定時の確認ポイントとして稼働率、障害発生頻度、障害時の回復目標時間、計画停止の事前通知、障害発生時の通知とサービス状態の表示を挙げています。数字の意味を、30日の月で換算しておくと比べやすくなります。 | 稼働率の保証値 | 30日間で許容される停止時間 | | ------- | -------------- | | 99.9% | 約43分 | | 99.5% | 約3.6時間 | | 99.0% | 約7.2時間 | 確認したいのは保証値だけではありません。計画停止を稼働率の計算から除く契約が多いため、メンテナンスの時間帯が始業時刻や締め日の集計にかからないかを見ます。保証値を下回ったときの返金の有無、障害の連絡がメールかステータスページかも、契約書と付属文書で確かめておきます。そもそもSLAを公開していない製品は、24時間体制の工場や病院のように打刻が止まると業務に響く職場では選ばないほうが安全です。 ### 労働基準法の保存期間から逆算する解約時のエクスポートと消去条件 [労働基準法](https://laws.e-gov.go.jp/law/322AC0000000049)第109条は、出勤簿やタイムカードを含む労働関係の重要な書類の保存期間を5年と定め、第143条の経過措置で当分の間は3年とされています。クラウド型を解約すると、この期間内の記録を手元に残す必要があります。 IPAの手引きは利用終了時の確認事項として、全データの返却やダウンロード、データの互換性と移植性、残留データの完全消去を挙げています。勤怠では、確定した月次集計だけでなく、打刻の生データと修正履歴まで出力できるかが要点です。修正前後の記録が無いと、労働基準監督署から記録の正しさを問われたときに説明できません。年に1回は全件をエクスポートし、自社のストレージに複数世代で保管する運用にしておくと、ベンダーの撤退や乗り換えのときも慌てずに済みます。 ### データ保存先の地域とISMAP・ISO/IEC 27017などの第三者認証の見方 勤怠データには氏名、所属、勤務時間のほか、休暇の理由として健康に関わる情報が入ることがあります。IPAの手引きは、データセンターが所在する国・地域の確認と、外国にある第三者への提供に関する個人情報保護法の規定への注意を求めています。 事業者の信頼性を見る材料として、手引きはISMAP（政府情報システムのためのセキュリティ評価制度）、ISO/IEC 27001に加えてクラウド固有の管理策ISO/IEC 27017を認証するISMSクラウドセキュリティ認証、クラウド情報セキュリティ監査制度、ASP・SaaS情報開示認定制度を紹介しています。どれかの取得を必須とするかは自社のセキュリティ規程で決め、選定の早い段階で候補を絞る条件に使います。 ## クラウド型で足りる企業とオンプレミス型や受託開発に切り替える条件 ここまでの確認結果を、判断の線に落とします。結論を先に言えば、大半の企業はクラウド型で決めてよく、例外は条件で特定できます。 ### 標準の勤務ルールと汎用の給与ソフトならクラウド型で決めてよい理由 次の3つがそろうなら、クラウド型を選び、オンプレミス型や開発は検討から外します。 - 勤務パターンと手当が、トライアルで設定と集計を通せた - 給与計算ソフトが広く使われる製品で、勤怠製品側に標準の連携がある - 打刻端末が製品の対応機器一覧に載っている、または新たに揃えてよい この条件で個別開発に進むのは過剰です。法改正のたびに改修費がかかり、5年単位で見ると保守費が利用料を上回りやすくなります。「自社の運用は特殊だ」という感覚だけで開発を選ぶ前に、運用側を製品の標準に寄せられないかを先に検討します。 ### クラウド型で足りない場合に受託開発へ切り替える判断条件と進め方 一方、次のいずれかに強く当てはまる場合は、クラウド型だけでは要件を満たせません。 - 独自手当や工数配賦の計算が給与計算側でも吸収できず、毎月の手計算が残る - 既存の入退館ゲートや社員証、生産管理システムとリアルタイムに近い頻度でつなぐ必要がある - 社内規程で人事データの社外保管が認められない、または閉域網で基幹システムと接続している この場合でも、全面開発が唯一の答えではありません。打刻と集計の標準部分はクラウド製品に任せ、ゲート連携や手当計算の部分だけを開発でつなぐ構成なら、法改正への追随をベンダーに残せます。[既存の打刻端末や基幹システムに合わせた勤怠管理システムの受託開発](https://www.issoh.co.jp/service/business%5Fsystem/attendance-management/)では、こうした連携部分だけの構築から、閉域網で動く勤怠の中核の開発まで切り分けて提案できます。規模ごとの開発費の目安を確認する際の参照先は、[勤怠管理システム開発の費用相場を機能別・規模別に解説した記事](https://www.issoh.co.jp/column/details/16296/)です。拠点や就業規則が多い企業は、[多拠点・複数就業規則に対応する大企業向けの選び方](https://www.issoh.co.jp/column/details/18248/)も判断の材料になります。 ## クラウド型の勤怠管理システムの導入検討でよく寄せられる質問と回答 クラウド型の勤怠管理システムを検討している人事・総務・情報システムの担当者から多い質問に答えます。 ### クラウド型の勤怠管理システムは障害で止まったらどうなりますか？ 止まっている間は打刻も申請も受け付けられません。端末側で打刻を一時保存して復旧後に送る機能があれば記録は残りますが、無い製品では紙の出勤簿などの代替手段に切り替え、復旧後に管理者が修正入力します。事前に、SLAの稼働率保証、計画停止の時間帯、障害の連絡方法を確認し、停止時の手順を社内ルールとして決めておくと、始業時刻に止まっても記録の抜けを防げます。 ### オンプレミス型からクラウド型へ移行するときの注意点は何ですか？ 過去の勤怠データの扱いが最初の論点です。労働基準法では記録の保存期間が当分の間3年、本則では5年とされているため、旧システムを停止する前に、打刻の生データと修正履歴を新システムか参照用の保管先へ移します。あわせて、オンプレミス型で作り込んでいた独自の計算ロジックがクラウド製品の設定で再現できるかを、同じ月のデータを両方で集計して突き合わせて確認します。 ### 既存のタイムカードやICカードはクラウド型でも使えますか？ 製品によります。紙のタイムカードはそのままでは取り込めないため、ICカードやスマホなどの電子的な打刻に切り替えるのが一般的です。社員証のICカードは、製品が対応するカードリーダーと規格に合えば使い続けられます。入退館ゲートのログを勤怠に使いたい場合は、標準連携が無ければCSVやAPIでの取り込み開発が必要になるため、見積もりの前に対応機器一覧で確認してください。 ### クラウド型の勤怠管理システムのセキュリティは安全ですか？ 安全性は製品ごとに差があり、クラウドかどうかだけでは決まりません。通信の暗号化、多要素認証、操作ログの保存に加え、ISMAPやISO/IEC 27017などの第三者認証の取得状況とデータセンターの所在地を確認します。利用者側の責任も残るため、退職者のアカウント削除や管理者権限の絞り込みは自社で担う運用です。IPAの手引きのチェックシートを社内の確認表として使うと、抜けを防げます。 ### 小規模な会社でもクラウド型の勤怠管理システムを入れる意味はありますか？ あります。従業員が10人前後でも、シフト制や時間外労働の上限管理、年次有給休暇の取得状況の把握は必要で、手集計では締め日の作業が重くなりがちです。クラウド型はサーバーの準備が要らず、法改正への対応もベンダー側で行われるため、専任の労務担当を置きにくい会社ほど負担が減ります。無料プランや少人数向けの料金から始め、人数が増えた段階で有料プランに移る進め方も取れます。 ## 関連記事 - [勤怠管理システムとは？機能・種類・費用と失敗しない選び方を解説【2026年】](https://www.issoh.co.jp/column/details/15081/)：機能・種類・費用相場の全体像を押さえたい方に。 - [打刻とは？客観的な記録の条件と方式6種の使い分け、設計要件](https://www.issoh.co.jp/column/details/17276/)：ICカードやPCログなど打刻方式を比べたい方に。 - [勤怠管理システムの無料プランはどこまで使えるか｜人数と機能の上限と有料へ移る線【2026年】](https://www.issoh.co.jp/column/details/17475/)：クラウド型を無料で試すときの上限を知りたい方に。 - [テレワークの勤怠管理とは？打刻・中抜け・不正防止の方法と選び方【2026年】](https://www.issoh.co.jp/column/details/15452/)：在宅勤務の打刻とPCログの扱いを確認したい方に。 - [オンプレミス型とクラウド型の基幹システムの違いと選定ポイント](https://www.issoh.co.jp/column/details/7449/)：勤怠以外の基幹システムでも導入形態を比べたい方に。 --- 出典: [クラウド型勤怠管理システムとは？オンプレとの判断基準・打刻端末・SLAの確認点【2026年】]()（株式会社一創）