〜 外注100万円超の仕組みをAIで内製化するまでの全工程 〜
はじめに：ある日突然、封筒が届いた
先日、労働基準監督署（以下、労基）の定期点検の対象に当選しまいました。
労基いわく「10年に一度くらいの感覚で奈良県の事業者にお声がけしています」とのこと。弊社は23年間やってきて、初めての経験でした（笑）。
呼び出された先で言われたことがこちらです。
① 変形労働時間制の管理が不十分
② 年次有給休暇5日の計画的付与の記録がない
どちらも「知っていたけど、ちゃんと管理できていなかった」という話です。
外部の勤怠システムは導入しているものの、細かな設定がややこしくてほぼ機能していない状態でした。
そこで「重要な部分だけ自分で作ろう」と決め半日で作った記録です。
✅ GoogleスプレッドシートとGASで勤怠管理システムが作れる
✅ 外注100万円超の仕組みがAIで内製化できる
✅ 開発でハマっても「仕様書があれば即復旧」できる
✅ 労基対応に必要な記録が自動で蓄積される仕組みが作れる
1. 労基に指摘された2つの課題
▶ 課題① 変形労働時間制の管理
弊社では1年単位の変形労働時間制を採用しています。これは7月〜翌6月を1年として、年間の総労働時間が2,080時間以内に収まるように管理する制度です。
月によって勤務日数が違うため、毎月の所定勤務日数と所定労働時間を事前に届け出る必要があります。これが「ちゃんと記録できていない」と指摘を受けました。
▶ 課題② 年次有給休暇5日の計画的付与
2019年の法改正から、年10日以上の有給が付与される従業員に対して、会社が年5日の有給を取得させる義務が生じています。
取得させているかどうかの「記録」が必要で、これもあるんだけどわかりにくい状態でした。。
変形労働時間制
→ 月別の勤務日数・労働時間が記録されていない
→ 年間2,080時間以内の管理ができていない年次有給休暇5日の付与
→ 誰がいつ取得したかの記録がない
→ 未取得者への促しができていない
外部の勤怠システムで対応できればよかったのですが、設定がややこしくて断念。
そこでClaudeさんと一緒にGoogleスプレッドシート＋GASで自分で作ることにしました。
これも後日談にしますが、いま開発中の仕組みでも必要となったためわかりやすいものを作りました。
2. 作ったシステムの全体像
半日かけてClaudeと一緒に作り上げたシステムの全体像です。
① 管理シート（スタッフ情報の一元管理）
→ 入社日・出勤曜日・契約時間などを1か所で管理② 月次カレンダーの自動生成
→ 毎月25日に翌月分のシフトカレンダーが自動作成
→ 土曜定休日・パートの契約外曜日も自動入力
③ 有給管理の完全自動化
→ 取得数の自動カウント
→ 5日達成で自動的にセルが緑色に変わる
→ 年度をまたいだ記録の永久保存
④ シフト確認メールの自動送信（毎月25日）
⑤ 年度末バックアップのワンクリック化
⑥ スプレッドシート上の管理メニュー
⑦ シフト管理者向けマニュアル
シフト管理者がやることは「毎月のカレンダーに休みを入力するだけ」。あとは全部自動で動く設計にしました。
毎月25日
→ 翌月のシフトカレンダーが自動生成
→ シフト確認メールが自動送信毎月1日 深夜
→ 先月の有給取得日が年休管理シートに自動反映
毎日 深夜
→ 有給の取得数・期間が自動更新
→ 取得期間終了分は永久保存シートに自動転記
3. 開発の流れ：なぜ仕様書から始めたのか
最初からコードを書かせるのではなく、まず「どんなシステムを作りたいか」をClaudeと壁打ちしながら仕様書に落とし込みました。
この判断が後から大きく効いてきます。
▶ 仕様書を先に作る3つのメリット
- 要件の整理ができる（作りながら迷わない）
- トラブルが起きても仕様書を見れば即復旧できる
- 修正・追加があっても影響範囲がすぐわかる
今回は途中で「やっぱりこの列は不要」「この計算方法を変えたい」という変更が何度もありましたが、仕様書があったので修正が素早くできました。
・社員と短時間社員の管理方法の違い
・各列の計算ルール（出勤日数・所定時間・実働時間）
・有給の反映タイミングと保存方法
・変形労働時間制の年間スケジュール管理
4. ハマった話① 有給の取得数が0のまま動かない
有給管理システムを作っていて、こんな状況が発生しました。
カレンダーに「有休」と入力した
→ 年休管理シートに「4/1」という日付が記録された
→ でも取得数（D列）が0のまま変わらない！
▶ 原因
スプレッドシートに保存された日付の形式が「4/1」という文字列ではなく「2026-03-31T15:00:00.000Z」という日付オブジェクトになっていました。GASのコードが文字列として比較しようとしていたため、一致せずカウントされなかったというわけです。
▶ 解決方法
デバッグ用のログをコードに追加して実際の値を確認。日付型と文字列型の両方に対応したコードに修正してもらいました。
if (val instanceof Date) {
// 日付オブジェクトとして処理
} else {
// 文字列「4/1」として処理
}
「まず実際の値をログで確認する」というデバッグの基本が大事です。
5. ハマった話② シートをコピーしたら余分なデータが混入
月次カレンダーの自動生成で最も手こずった問題です。
「シフト」シートをコピーして「4月」シートを作る
→ 関係ないセルに「休」や「#ERROR!」が入ってくる
→ 何度修正してもまた出てくる…
▶ 原因
Googleスプレッドシートでシートをコピーすると、元シートの数式が新しいシートにも引き継がれます。さらにシートの行数が少ないと「範囲の座標がシートのサイズから外れています」というエラーが重なって発生していました。
▶ 解決までの道のり（4回目でようやく解決）
- clearContent()でクリア → コピー後に復活。ダメ。
- deleteRows()で物理削除 → 行数が足りずエラー。ダメ。
- 列追加してから行削除 → 別のエラー発生。ダメ。
- 行確保 → 列追加 → 余分な行を削除（順番が重要！）→ 解決！
「処理の順番」が重要でした。GASでシートを操作する時は実行順序を意識することが大切です。
6. ハマった話③ 年間休日の行番号がズレていた
開発が終わりかけた頃に気づいた問題です。
最初、年間休日スケジュールシートを1月〜12月の順番で作っていました。しかし変形労働時間制の管理は7月〜6月が正しい。GASが「1月は4行目」という計算で組まれていたため、シートを7月スタートに変えたら全部ズレていました。
これに気づいたのが開発の終盤。もし仕様書がなかったら、どこにその計算が使われているかを全部コードから探し直す羽目になっていました。
▶ 解決方法
月と行番号の対応表をコードに追加して解決しました。
var monthToRow = {
7:4, 8:5, 9:6, 10:7, 11:8, 12:9,
1:10, 2:11, 3:12, 4:13, 5:14, 6:15
};
var nenkyuRow = monthToRow[month];
勤怠システムを作る際は「会社の年度起算月」を最初に確認することをおすすめします。
7. 仕様書があったから即復旧できた（最大のポイント）
今回の開発で何度か「全部やり直しかも」という場面がありました。でもその都度、仕様書を見返せば即対応できました。
▶ 具体的な例：列構成の見直し
開発途中でカレンダーの列構成を大幅に見直すことになりました。「社員とパートで列の意味を変えたい」という要件が後から出てきたためです。
仕様書に「この列はこの計算をする」と明記されていたため、影響範囲をすぐ把握して修正できました。仕様書がなければ、コードを一行一行読み直すことになっていたと思います。
【仕様書なし】
修正のたびに「あれ、これどんな設計だったっけ？」
→ コードを読み返す時間が発生
→ 修正漏れが起きやすい
→ 同じエラーが別の場所で再発する【仕様書あり】
仕様書を見れば設計の意図がすぐわかる
→ 修正の方向性がブレない
→ 影響範囲を把握してから修正できる
→ 迷いなく進められる
「仕様書を先に作る」これだけで開発のスピードと品質が大きく変わります。
8. 完成したシステムの価値
要件定義・設計：20〜40万円
GAS開発・テスト：30〜60万円
マニュアル作成：5〜10万円
保守費用：月1〜3万円合計：初年度55〜110万円以上
これをAIを活用して内製化することで、費用をほぼゼロに抑えられました。
さらに大きなメリットがあります。自社で作ったシステムは自社で改修できます。外注だと機能を1つ追加するたびに費用が発生しますが、内製化すればその心配がありません。
そして今回の目的である「労基対応」についても、このシステムで以下が自動的に記録・管理されます。
・月別の所定勤務日数・所定労働時間（変形労働時間制の管理）
・年次有給休暇の取得日・取得数（5日義務付けの管理）
・スタッフごとの有給取得期間と達成状況
・過去の取得記録（年度をまたいで永久保存）
9. Claude活用で本当に大切なこと
今回の開発を通じて感じたのは「問い力」の重要性です。
Claudeは非常に優秀なツールですが、何を作りたいかを自分が明確に持っていないと、ただのコード生成ツールになってしまいます。
今回の開発で質が上がったのは、以下のような問いがあったからです。
こういった問いが出てくるのは、業務の実態をよく知っているからです。
AIはコードを書けますが、業務の実態を知っているのは現場の人間だけです。
AIが優秀であればあるほど、人間側が「正しい問い」を立てることの価値が上がります。
① 仕様書を先に作る（コードより先に設計を固める）
② ハマったらログで原因を特定してから修正する
③ 業務の実態をしっかり持ってAIに伝える（問い力）
10. まとめ
労働基準監督署に呼ばれたことをきっかけに、勤怠管理システムをClaudeと半日で作りました。
23年間経営してきて初めての労基対応でしたが、結果的にこれが「ずっと後回しにしていたデジタル化」を一気に進めるきっかけになりました。
基本、スタッフの働きやすい環境を作ろうと努力はしてますが、頭だけや簡単なエクセル管理などでは手間と不便が生まれます。
外部のシステムが使いにくいと感じている中小企業の経営者の方は、AIを使った内製化を検討してみてください。
・入力はシフトカレンダーへの休み入力のみ
・有給管理・集計・記録保存が全自動
・毎月25日に翌月カレンダーと確認メールを自動送信
・年度末バックアップがワンクリックで完了
・新スタッフが入ったら管理シートに1行追加するだけ
・労基対応の記録が自動で蓄積される
