DX・システム
勤怠管理アプリを自社に合わせて作るとき、AIに「勤怠管理アプリを作って」と一行頼むだけでは、運用に必要な条件は決まりません。今回の開発動画では、Claude Codeへの依頼から、作られた内容の確認までを扱います。この記事では「ドヤ勤怠」を題材に、Claude Codeで勤怠管理アプリを自作する際の要件と検証手順を整理します。
ドヤ勤怠の機能・使い方を見る ／ 開発動画を見る（2026年10月2日公開予定・8分45秒）
勤怠管理アプリを自作する前に決めること
最初に、利用人数、勤務形態、締め日、打刻方法、申請・承認者、給与計算への受け渡し方法を決めます。出退勤の記録だけなら簡単でも、休憩、日付をまたぐ勤務、休日、残業、打刻忘れを扱うと条件が増えます。実際の就業規則や給与計算の判断を、AIの一般的な回答だけで確定しないことが必要です。
ドヤ勤怠のサービスページでは、ブラウザでの出退勤打刻、日次・月次の集計、申請・承認を中心機能として紹介しています。ページ内の従業員名や打刻時刻は操作イメージであり、実在の利用データではありません。
Claude Codeへの開発依頼を具体化する手順
1. 最小の業務フローを決める
従業員が出勤・退勤を記録し、管理者が月次の一覧を確認するところまでを最小構成にします。誰がどの記録を閲覧・修正できるか、修正履歴を残すかも決めます。画面の見た目より先に、入力・保存・修正・承認の流れを文章にします。
2. AIへの依頼に例外を入れる
通常の打刻だけでなく、同じ日に二度出勤を押した場合、退勤を忘れた場合、深夜0時をまたいだ場合、休憩時間を変更した場合を指定します。ルールが未定ならAIに仮定させず、決めるべき項目を質問として出してもらいます。
3. 作られた画面とデータを確かめる
「ボタンを押せた」だけで完成とは判断しません。保存後に再読み込みしても記録が残るか、別の従業員の記録が見えないか、管理者の集計が元の打刻と一致するかを確認します。動画は開発依頼と実装内容の確認を紹介するもので、労務運用への適合や長期間の稼働実績を保証するものではありません。
そのまま使える要件整理プロンプト
あなたは業務アプリの設計者です。次の条件で勤怠管理アプリのMVP仕様を作ってください。利用人数：［記入］。勤務形態：［記入］。締め日：［記入］。対象機能：出退勤打刻、休憩、記録の修正申請、管理者承認、月次一覧。従業員と管理者の閲覧・編集権限を分け、打刻忘れ・重複打刻・日付をまたぐ勤務・途中退勤を例外として扱ってください。出力は画面一覧、保存項目、権限、計算ルールで未決定の項目、受け入れテストの順に示してください。未決定の就業ルールや法的判断を推測で埋めないでください。
これは読者向けの設計例であり、ドヤ勤怠の開発時に実際に使った非公開プロンプトではありません。生成された仕様は、社内の運用担当者と実装担当者が確認してから開発に進みます。
公開前に試したいテストケース
通常の出勤・休憩・退勤と、保存後の再表示。
二重打刻、退勤忘れ、日付をまたぐ勤務、未入力の休憩。
打刻修正の申請・承認・却下と変更履歴。
従業員が他人の記録を閲覧・変更できないこと。
月次集計と元の打刻の突き合わせ、CSV出力の文字化け。
集計ルールの正しさや法令適合は、実際の就業規則と専門家による確認が必要です。動画で画面が動いたことと、実務で安全に運用できることは区別します。
自作と既製品、どちらを選ぶか
独自の申請フローや社内システム連携を重視するなら内製には価値があります。一方、運用開始までの速さ、法改正への追随、障害対応を重視するなら既製サービスも比較対象です。比較するときは月額料金だけでなく、設計・保守・権限管理・バックアップにかかる人の時間を含めて判断します。
よくある質問
Claude Codeだけで勤怠システムは完成しますか？
コードの作成を助けられますが、勤務ルールの確定、データと権限の検証、運用手順の決定は人が担います。画面が動くことをもって実務で利用可能とは判断できません。
最初に実装する機能は何ですか？
出退勤の記録と管理者による確認から始め、休憩、修正、月次集計、申請・承認を運用条件に合わせて追加すると検証しやすくなります。
開発動画とサービス
Claude Codeで「ドヤ勤怠」を作る動画を見る。公開予定は2026年10月2日10時45分です。ドヤ勤怠の詳細はこちら。