KING OF TIME・ジョブカン勤怠はどこまで残すか｜シフト作成とAPI連携の制約

2026 10/09

2026年9月10日 2026年10月9日

KING OF TIME・ジョブカン勤怠はどこまで残すか｜シフト作成とAPI連携の制約

著者: Walkers編集部監修: 渡辺敦司（株式会社Walkers 代表取締役）公開: 2026年9月10日最終更新: 2026年10月9日監修者: AI駆動開発・FDE型AI導入支援の実務家

勤怠管理システムの導入でつまずきやすいのは打刻や集計ではありません。打刻や勤務時間の集計、法定の労働時間管理はそのままSaaSに残すのが基本です。一方で、現場固有の制約を満たすシフト作成や連携アドオン、API連携の制限、独自の手当計算という4か所で手作業が残りやすい傾向があります。KING OF TIMEやジョブカン勤怠を使っている会社ほど、標準機能の設定で表現できる範囲とその外側をどう線引きするかが判断の出発点になります。

残す／作り替えの判断表【早見表】

勤怠管理の業務を、感覚ではなく次の10項目で仕分けます。契約中の勤怠SaaSを1つずつ表に当てはめてみてください。

判定は3種類です。「残す」はSaaSに置くもの、「残す（プラン要確認）」は追加契約や契約プランにより対応範囲が分かれるもの、「作り替え候補」は標準設定では表現しきれず専用システムの検討対象になるものを指します。機能自体の有無と追加契約の要否を混同せず、自社の契約仕様を確認することが重要です。表の用語について、「アドオン」は標準機能に追加して契約する拡張機能、「API」はシステム同士が自動でデータをやり取りするための接続口、「変形労働時間制」は一定期間を平均して1週あたりの労働時間を調整する制度を指します。

業務	判定	理由
打刻	残す	ガイドラインが求める「客観的な記録」の手段としてSaaSの打刻を活用できる（確認・適正管理の法的責任は使用者が負う）
勤務時間の集計	残す	法定労働時間・残業時間の自動集計はSaaSの標準機能の中心
36協定・残業上限の管理	残す（プラン要確認）	KING OF TIMEは「残業時間の管理」「アラート管理」を勤怠管理の機能として公式サイトに掲載（2026-09-10確認）。他製品・プランでの提供範囲や通知仕様は契約内容で要確認
変形労働時間制・フレックスの集計	残す（プラン要確認）	KING OF TIMEは週・月・年単位の変形労働制や1〜3か月のフレックス集計に対応（公式サイト確認）。対応する変形労働制の種別や契約プランごとの対応状況は各製品で要確認
年次有給休暇の管理	残す（プラン要確認）	付与日数の自動計算や取得管理機能が標準に含まれるか、上位プランやオプションが必要かは契約製品ごとに要確認
給与連携（標準フォーマット）	残す（プラン要確認）	標準連携・CSV出力が基本機能に含まれる製品も多いが、連携先ソフトやプランに応じた追加契約の要否は事前確認が必要
シフト作成（標準パターン登録）	残す（プラン要確認）	固定シフトや交替制パターンの基本登録に対応する製品は多いが、シフト機能が別プラン・オプション扱いとなる場合があるため要確認
シフト作成（現場固有の制約条件・自動割当）	作り替え候補	資格者の必要配置人数、設備稼働に合わせたスキル制約、拠点間応援など、標準設定で解けない組み合わせ最適化は外側になりやすい
他システム連携（アドオン・API）	作り替え候補	連携要件が増えるほど追加費用やAPIの利用可能時間帯・レート制限といった制約への設計対応が必要になる
独自の手当計算	作り替え候補	現場固有の複雑な手当計算式は勤怠SaaSの標準項目に収まりきらず、表計算ソフトでの手作業が残りやすい

該当項目がある場合でも、すぐに専用開発へ進む必要はありません。まずは既存SaaSの設定変更や上位プラン、公式連携でカバーできないかを検証します。そのうえで、日々の手作業量、誤計算のリスク、アドオン等の追加費用を比較し、業務上のボトルネックになっている箇所から優先的に見直しを検討してください。

打刻・集計をSaaSに残す根拠｜「客観的な記録」と管理監督者も対象になる労働時間の状況の把握

厚生労働省の「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」は、使用者に対し、労働者の労働日ごとの始業・終業時刻を確認し、記録することを求めています。確認・記録の原則的な方法として挙げられているのは、次の2つです。

（ア）使用者が自ら現認して確認する方法
（イ）タイムカード、ICカード、パソコンの使用時間の記録等の客観的な記録を基礎として確認する方法

これらによらず自己申告制で行わざるを得ない場合には、追加の措置を講じることが求められます。なお、このガイドラインが労働時間の適正な把握の対象とする労働者は、労働基準法第41条に定める者（管理監督者等）及びみなし労働時間制が適用される労働者を除く全ての者です。一方、労働安全衛生法に基づく労働時間の状況の把握は、管理監督者や裁量労働制の適用者も対象に含まれます。

労働時間の状況の把握について、厚生労働省の資料は「事業者は労働者の労働時間の状況を把握し、長時間の時間外・休日労働等をしている労働者に対して医師による面接指導を行い、医師の意見を勘案して必要と認める場合は適切な措置を実施しなければならない」（労働安全衛生法第66条の８等）としています。把握の方法は「タイムカードによる記録、パーソナルコンピュータ等の電子計算機の使用時間の記録等の客観的な方法その他の適切な方法」（労働安全衛生法第66条の８の３、労働安全衛生規則第52条の７の３第１項）と示されています。

打刻・集計・法定の労働時間管理を勤怠SaaSに残す判断は、客観的な記録の手段として既存の仕組みを合理的に維持するための実務的な選択です。なお、SaaSを導入したこと自体で使用者の法的責任が免除されるわけではなく、実際の記録状況の確認や必要に応じた実態調査、是正措置を行う責任は使用者にあります。自社の運用が法令やガイドラインに適合しているかの個別判断は、社会保険労務士等の専門家に確認することをおすすめします。

KING OF TIME・ジョブカン勤怠の公表情報とAPI連携の確認範囲【2026年9月9日確認】

KING OF TIMEの公式サイトによれば、初期費用は0円、月額1人あたり300円（公式サイトの料金表示に税込・税抜の明記なし）で、最低利用人数の定めはなく1名から利用できます。人事労務・勤怠管理・給与計算・データ分析・システムログという連携サービスが、追加料金なしのワンプライスに含まれると案内されています（単体契約は不可と注記）。一方、電子契約は追加費用が必要な「オプションサービス」として案内されています。API連携については、公式のWebAPIドキュメント（developer.kingtime.jp）において利用禁止時間帯やレート制限などの規定が明記されており、外部システムと連携する際はこれらの仕様に従ったデータ取得設計が必要です。

ジョブカンシリーズの料金プランページは、2026年9月9日の確認時点で価格表がページ読み込み後に動的に表示される構成であったため、本稿では料金数値を引用していません。また、同シリーズのノーコードアプリ作成サービス「ジョブカンApps」の公式サイトでは、Appsと勤怠管理の連携によるレポート化などが案内されていますが、これはApps製品を介した連携仕様であり、勤怠管理システム単体のWeb API仕様とは前提が異なります。各社勤怠APIの具体的な制限値や連携条件については、契約中のプランに合わせた最新の公式開発者ドキュメントをご確認ください。

両社に共通するのは、標準機能とは別に「連携」「オプション」の区分が用意されている点です。この区分の外側にあるものが、作り替えを検討する対象になります。どちらが優れているかを比較する記事ではありません。

勤怠管理システムで手作業が残りやすい4つの代表例

勤怠管理システムを導入しても手作業が残りやすい代表的な論点として、本稿では次の4か所を取り上げます。

現場固有の制約を満たすシフト作成: 変形労働時間制などの法的な勤務制度自体はSaaSで集計できる場合でも、「有資格者を必ず各直に2名配置する」「特定設備の操作担当を常駐させる」「拠点間での応援調整」といった現場固有の複雑な制約を満たすシフト案の作成は、標準機能の範囲を超えて表計算ソフト等の手作業に戻りやすい領域です
連携アドオンの積み上げ: 外部システム連携は、標準に含まれる範囲と追加契約が必要な範囲がSaaSごとに分かれます。KING OF TIMEのように人事労務や給与計算を追加料金なしで提供する例もあれば、有償オプションとなる機能もあります。連携先が増えるほど、対象範囲の確認や設定管理の負担が積み上がります
API連携の制約対応: SaaSの公式APIを利用してデータを自動取得する場合、各社が定める呼び出し制限（レートリミット）や夜間バッチ停止などの利用禁止時間帯に配慮した設計が求められます
独自の手当計算: 現場環境手当、複雑な資格手当、独自の交替勤務手当など、会社特有の算式は標準集計項目に収まりきらず、締め日後に担当者が表計算ソフトで手作業集計する運用になりがちです

これらはSaaSの欠陥ではなく、汎用ソフトウェアの設定範囲と各社の個別運用とのギャップです。法令対応の打刻・集計はSaaSに残し、手作業や費用負担が大きい周辺業務を切り分けて見直すのが現実的なアプローチです。

基幹データベースを正として維持しながら、AIや専用ツールが担う範囲を安全に切り分けたアーキテクチャの考え方は、事例集の〈CASE 06｜業務DBと生成AIを、あえて分ける〉（※勤怠・シフト事例ではなく業務DB連携の検証事例）で確認できます。

併用設計 — 勤怠SaaSをマスターとして、手作業の周辺業務を切り分ける

実務的な進め方は、勤怠SaaSからの全面移行ではなく併用です。打刻・勤務時間集計の確定データは勤怠SaaSを正（マスター）とし、その前工程であるシフト作成や、後工程である独自の手当計算を専用システムで支援する構成をとります。

ここで、設計のモデルケースとして従業員80名の製造業（架空の試算例）を想定します。交替制勤務自体はSaaSの勤務形態で設定できているものの、「現場ごとの資格者配置ルールを満たすシフト作成」と「特殊環境手当の計算」が標準設定で対応できず表計算運用になっているケースです。この場合、専用システムは予定シフトを作成して担当者確認後に勤怠SaaSへ登録（APIまたはCSV取込機能による）します。月末の締め処理では、勤怠SaaSで確定した勤務実績データを専用システムが読み込み、独自の手当を計算して確認済みの給与ソフト連携フォーマットへ渡します。確定した勤務時間を専用システム側で再作成して戻すような循環は避け、データの確定元を一元化します。なお、APIやCSVでの取り込み可否・対応項目は各製品の仕様確認が必要であり、削減効果や期間もシフトの複雑さによって変動します。

勤怠SaaS（実績確定元）と専用システム（周辺支援）の併用データフロー

1. 予定シフト案の作成 現場の資格者配置や設備稼働要件などの独自制約を考慮し、専用システムが予定シフト案を作成
2. 管理者確認・勤怠SaaSへ登録 管理者が確定したシフト予定データを、APIまたはCSV経由で勤怠SaaSのスケジュールへ登録（※取込仕様の事前確認が必要）
3. 打刻記録と集計・使用者による実績確定 勤怠SaaSが打刻を記録し労働時間を集計。使用者が適用設定と実態を確認したうえで、勤務実績を確定マスターとして確定
4. 独自手当の計算 勤怠SaaSから確定した勤務実績データを取得し、専用システムで現場固有の特殊手当を算出
5. 給与システムへの連携 担当者の確認後、手当データを給与ソフトへ連携。勤怠SaaSの基本集計項目は既存の標準連携を活用

勤怠SaaSを勤務実績の確定マスターとし、専用システムは前工程のシフト予定作成と後工程の手当計算に役割を分離します。

自社のどの業務が標準機能の外側にあるかを整理したい場合は、無料のAI自動化診断が出発点になります。

専用開発を組み合わせると、契約構成や開発はどう変わるか

現場固有のシフト作成や手当計算を自社専用システムで構築する場合、契約構成は「勤怠SaaSの基本契約」を維持したうえで「自社専用システム」が加わる形になります。一部の有償アドオンを外せる可能性はありますが、勤怠SaaSの基本利用料は継続して発生します。画面やロジックは自社の現場ルールに完全準拠できる一方、SaaSの月額費用とは別に、専用システムの初期開発費用や保守・インフラ運用費用が発生する点を総合して費用対効果を判断する必要があります（費用の目安は開発費用の相場解説を参照）。

進め方の選択肢として、本稿を運営するWalkersでは、エンジニアが業務の分解から実装・定着まで一貫して伴走するFDE（Forward Deployed Engineer：現場展開型エンジニア）型の体制を提案しています（FDE型AI導入支援とは）。まずは対象業務を棚卸しし、シフト作成など最も負荷の高い1業務に絞ってMVP（Minimum Viable Product：実務で検証できる最小限のプロダクト）を構築し、効果を確認してから段階的に広げる手順を推奨しています。一方、標準的な勤務設定で無理なく運用できており、手作業が少ない企業は専用開発を行う必要はなく、勤怠SaaSの標準機能のまま使い続けるのが合理的です。

手作業の巡回・転記作業を専用の自動化ロジックへ引き取った考え方の実例は、事例集の〈CASE 02｜毎日の巡回・転記を、AIが引き取る〉（※Web巡回・データ収集の検証事例）で確認できます。

よくある質問

勤怠SaaSを使っているのに、なぜシフト管理だけ大変なのですか？

変形労働時間制などの法的な勤務制度自体はSaaSで管理できても、資格保有者の配置条件、設備の稼働要件、相性や希望といった「現場固有の制約を満たすシフト作成」は標準機能の設定範囲を超えやすく、表計算での手作業が残りやすいためです。

KING OF TIMEやジョブカン勤怠を、AI駆動開発システムに完全に置き換えるべきですか？

いいえ。打刻・勤務時間の集計・法定の労働時間管理は、客観的な記録管理を安定して行うため勤怠SaaSに残すのが基本です。専用開発の検討対象は、標準設定で解けないシフト作成や独自の手当計算など周辺業務に限られます。

API連携の制約は、どこまでが「標準機能の外側」なのですか？

専用システムを構築しても各社SaaSのAPI利用制限（レート制限や利用禁止時間帯）を超えて通信できるわけではありません。日中のリアルタイム同期が必要な要件に対し、API制限内で差分取得や集約処理を設計できるか、または仕様上満たせないかの見極めが検討課題となります。

残す／作り替えを判断するとき、最初に何を確認すればよいですか？

契約中の勤怠SaaSで設定可能な勤務形態やシフト機能を精査し、自社の運用ルールのうち「設定変更で解決できる範囲」と「標準機能ではどうしても表現できない固有要件」を明確に切り分けることが最初の一歩です。

勤怠管理システムの導入で、よくある失敗にはどのようなものがありますか？

シフト作成時の現場固有ルールの見落とし、連携アドオン費用の想定外の増加、API制限への考慮不足、複雑な独自手当の未対応などが挙げられます。打刻や集計自体ではなく、周辺業務との接続部分で手作業が残ってしまうケースが代表的です。

業務別の判断基準は、CRM・SFA・請求・見積・在庫・発注の各記事でも扱っています。SaaS費用の考え方を横断的に整理する場合は「SaaS is dead」とは何か、残す／置き換えの基本は残すSaaSと置き換えるSaaSの見極め基準、契約中の全SaaSの棚卸し手順はSaaS費用の棚卸し実務、解約・データ移行等の個別論点は脱SaaSのよくある質問20をご覧ください。

自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。本記事は、FDE型のAI導入支援を行う株式会社Walkersが運営しています。