スプレッドシート勤怠管理ボタンの作り方｜GASコード・スマホ対応と限界

2026年6月27日2026年8月18日

SkillStack Lab（スキスタ）運営者の「スタック」です。

GoogleスプレッドシートとGAS（Google Apps Script）を使えば、出勤・退勤ボタンを押した時刻を自動記録する勤怠管理の仕組みを自作できます。

結論から言うと、PC中心・固定勤務・少人数なら自作も選択肢です。ただし、スマホ打刻、打刻修正、残業計算、変形労働時間制、法改正対応まで必要になると、専用の勤怠管理システムへ移行した方が安全かつ管理負担を抑えやすくなります。

私は実際に、Excel VBAで社員ごとの勤怠ファイルを作成・集計する仕組みを運用した後、Googleフォーム＋スプレッドシート＋GASによるクラウド型の勤怠管理も自作しました。

後者では「Googleフォームで出退勤を入力 → スプレッドシートへ記録 → GASで日次・月次の労働時間や残業時間を集計 → 月末に給与計算用CSVを生成」という流れまで構築し、小規模な部署で実運用しています。

その経験から分かったのは、打刻ボタンを作ること自体より、その後の運用を維持する方が難しいということです。

この記事では、実際に使えるGASのサンプルコードから、スマホ打刻の注意点、Googleフォームを使った代替方法、そして私が自作からクラウド勤怠へ移行した判断基準まで解説します。

※本記事には広告・プロモーションが含まれています。

この記事で分かること

GASで出勤・退勤ボタンを作る具体的な方法
スマホで図形ボタンが使えない理由と代替方法
私がGoogleフォーム＋GASで実際に運用した構成
打刻漏れ・修正・残業計算で自作勤怠が苦しくなる理由
クラウド勤怠へ移行する具体的な判断基準

表計算ソフトによる自作勤怠管理の初期費用の低さと、法改正対応や属人化など運用上の課題を比較した図解

スプレッドシートで勤怠管理ボタンを作る方法

まずは、Googleスプレッドシート上に「出勤」「退勤」の2つのボタンを作り、クリックした時刻を記録する基本形から見ていきましょう。

数名程度の固定勤務で、「まず勤怠管理をデジタル化してみたい」という段階なら、この仕組みだけでも十分に自動化を体験できます。

勤怠表の基本構成を作る

分かりやすくするため、まず「勤怠」という名前のシートを作り、次の3列を用意します。

列	項目	記録内容
A列	日付	勤務日
B列	出勤	出勤ボタンを押した時刻
C列	退勤	退勤ボタンを押した時刻

1行目を見出しとして、2行目以降へ日ごとの勤怠記録を追加していく構成です。

GASで出勤・退勤時刻を記録する

スプレッドシートから「拡張機能」→「Apps Script」を開き、次のようなスクリプトを作成します。

function clockIn() {
  recordTime_(2);
}

function clockOut() {
  recordTime_(3);
}

function recordTime_(column) {
  const ss = SpreadsheetApp.getActiveSpreadsheet();
  const sheet = ss.getSheetByName('勤怠');

  if (!sheet) {
    throw new Error('「勤怠」シートが見つかりません。');
  }

  const now = new Date();
  const timeZone = ss.getSpreadsheetTimeZone();
  const today = Utilities.formatDate(now, timeZone, 'yyyy-MM-dd');
  const lastRow = sheet.getLastRow();

  let targetRow = -1;

  if (lastRow >= 2) {
    const dates = sheet.getRange(2, 1, lastRow - 1, 1).getValues();

    dates.forEach((values, index) => {
      if (!values[0] || targetRow !== -1) {
        return;
      }

      const dateString = Utilities.formatDate(
        new Date(values[0]),
        timeZone,
        'yyyy-MM-dd'
      );

      if (dateString === today) {
        targetRow = index + 2;
      }
    });
  }

  if (targetRow === -1) {
    targetRow = Math.max(lastRow + 1, 2);
    sheet.getRange(targetRow, 1)
      .setValue(now)
      .setNumberFormat('yyyy/MM/dd');
  }

  const targetCell = sheet.getRange(targetRow, column);

  if (targetCell.getValue() !== '') {
    throw new Error('この項目はすでに打刻されています。');
  }

  targetCell
    .setValue(now)
    .setNumberFormat('HH:mm:ss');
}

clockIn()が出勤、clockOut()が退勤です。

今日の日付に該当する行を探し、まだ今日の行がなければ新しく追加します。さらに、すでに打刻済みの場合は上書きしないようにしています。

実際の運用では、スプレッドシート側のタイムゾーンも確認してください。日本国内の勤務管理なら、意図した日本時間で表示・集計される状態にしてからテストします。

図形へスクリプトを割り当てる

次に、スプレッドシートの「挿入」から画像や描画を配置し、「出勤」「退勤」と分かるボタンを作ります。

作成した図形のメニューから「スクリプトを割り当て」を選び、出勤ボタンにはclockIn、退勤ボタンにはclockOutと入力します。

関数名の後ろに()は付けません。

従業員がボタンを押し、GASが当日の日付を特定して出勤または退勤時刻を記録する流れ

Google公式でも、スプレッドシートに挿入した画像や描画へApps Scriptの関数を割り当てて実行できる仕組みが案内されています。

詳しい現在の仕様は、Google Apps Script公式ドキュメントでも確認できます。

NOW関数ではなくGASを使う理由

「現在時刻を表示するだけならNOW関数でもよいのでは？」と思うかもしれません。

しかし、NOW関数は再計算されるため、勤務実績として「その瞬間の時刻を固定して残す」用途には向きません。

勤怠記録では、ボタンを押した時点の値を静的なデータとして保存する方が扱いやすいため、GASからnew Date()をセルへ書き込む構成にします。

初回実行時は権限の承認が必要になる場合がある

Apps ScriptがGoogleサービスへアクセスする内容によっては、初回実行時にGoogleアカウントで権限を承認する画面が表示されます。

ただし、「このアプリはGoogleで確認されていません」という警告が全員に必ず表示されるわけではありません。使用するOAuth権限やGoogle Workspace環境、利用するアカウントなどによって認証フローは異なります。

スマホでは図形に割り当てたGASを実行できない点と、Apps Script利用時の権限承認について説明した図解

社内展開する場合は、必要以上に広い権限を要求しない設計にし、実際に社員アカウントで初回操作をテストしてからマニュアルを作成してください。

スマホではスプレッドシートの打刻ボタンを実行できない

ここは勤怠管理として非常に重要です。

画像や描画にApps Scriptを割り当てる方法は、PCのWebブラウザでは利用できますが、スマートフォンで画像・描画をタップしてもスクリプトは実行されません。

これはGoogle公式ドキュメントにも明記されている仕様です。

そのため、営業担当者、現場作業員、テレワーク社員などがスマホで出退勤する会社では、PC向けの図形ボタンをそのまま勤怠システムとして展開するのは現実的ではありません。

私が実際に使ったのはGoogleフォーム＋GAS

私自身もスプレッドシート＋GASで勤怠管理を構築しましたが、スマホ利用まで考えると、最終的に採用した入力方法はGoogleフォームでした。

実運用では「Googleフォームで出退勤を入力 → スプレッドシートへ打刻記録 → GASで日次・月次の労働時間や残業時間を自動計算 → 月末に給与計算用CSVを生成」という仕組みを自作し、小規模な部署で運用していました。

Googleフォームなら、スマートフォンのホーム画面へ入力ページのショートカットを置いておけば、社員はブラウザからフォームを開いて送信できます。

社員に勤怠集計用のスプレッドシート自体を直接触らせる必要もなくなるため、計算式を誤って削除されるリスクも下げられます。

私が実運用した構成

社員：Googleフォームから出勤・退勤を入力
記録：回答をスプレッドシートへ保存
集計：GASで日次・月次の勤務時間を計算
残業：GASで残業時間を集計
給与：月末に給与計算用CSVを生成

単純な「出勤」「退勤」だけなら、この方式は比較的扱いやすいです。

一方で、後述する修正申請、残業管理、有休、複雑な勤務制度まで自作し始めると、一気に保守負担が増えていきます。

チェックボックス＋onEditも代替案になる

もう一つの方法として、スプレッドシート標準のチェックボックスをスマホから変更し、その編集をonEditなどで検知して時刻を記録する方法もあります。

ただし、勤怠表そのものを社員へ編集させる構成になるため、権限設計や誤操作への対応が必要です。

私なら、スマホ前提で自作するのであれば、社員用の入力画面と管理用の集計表を分離できるGoogleフォーム型を優先します。

スタック

スマホ打刻まで必要なら、私はシート上のボタンにこだわりません。社員が触る入力画面と、管理者が使う集計表を分けた方が運用しやすかったです。

勤怠管理で難しいのは打刻より集計と修正

打刻時刻を保存できるようになると、次は労働時間や残業時間を自動計算したくなります。

ここからが、自作勤怠管理の難易度が上がるポイントです。

日付と時刻をセットで保存する

夜勤や日またぎ勤務がある場合は、「22:00」「6:00」のように時刻だけを保存するより、出勤・退勤とも日付を含む日時データとして記録する設計をおすすめします。

たとえば「2026/08/18 22:00」から「2026/08/19 06:00」までを記録しておけば、退勤日時－出勤日時という考え方で勤務時間を扱いやすくなります。

一方、時刻だけを管理している場合は、退勤時刻が出勤時刻より小さいときに翌日として処理するなど、追加の条件分岐が必要です。

深夜・残業・休日を入れるとロジックが複雑になる

固定勤務なら比較的シンプルですが、実務では次のような条件が加わります。

法定時間外労働
深夜労働
休日労働
日またぎ勤務
シフト勤務
変形労働時間制
フレックスタイム制
遅刻・早退・中抜け

さらに就業規則や雇用区分によって勤務条件が変われば、同じGASを全社員へそのまま適用できないケースも出てきます。

技術的に作れることと、給与計算の基礎データとして長期間安全に運用できることは別問題です。

実際に一番手間だったのは月末の打刻忘れ

私が勤怠管理の実務で最も時間を取られたのは、計算式を作る作業ではありません。

圧倒的に手間だったのは、月末の打刻忘れを回収し、本人へ事実確認を行い、上長の承認を取り直して勤怠データを修正する作業です。

システムがどれだけ自動計算してくれても、打刻を忘れる社員は一定数います。

締め日になってから「この日は直行でした」「実際は21時まで残業していました」と申告されれば、単純にセルを直して終わりにはできません。

本人へ勤務実態を確認する
必要に応じて上長へ確認する
修正内容を承認する
勤怠データを修正する
給与計算へ正しい数字を連携する

という一連の処理が発生します。

スタック

勤怠システムを選ぶなら、集計機能だけでなく「打刻忘れをどう検知し、誰がどう修正・承認するか」まで必ず確認します。月末の負担を左右するのはここです。

有休管理もExcelでは神経を使う

有給休暇についても、残日数を表示するだけならExcelやスプレッドシートで作れます。

しかし実務では、付与日、取得日、残日数、社員ごとの基準日などを正しく管理する必要があります。

私自身、年次有給休暇の取得状況や残日数を管理する業務にも関わってきましたが、手作業やExcelへの依存が大きいほど確認項目が増え、ヒューマンエラーにも神経を使います。

給与計算用CSVまで作れば終わりではない

私はGASで月末に給与計算用CSVを生成し、給与計算ソフトへ連携する仕組みも作っていました。

CSV出力まで自動化できるとかなり便利ですが、給与ソフト側の項目順や社員コード、勤怠項目との対応関係が変われば、出力ロジックも修正しなければなりません。

「一度作ればずっと無料で動くシステム」ではなく、業務ルールや周辺システムが変わるたびに保守が必要な社内システムだと考えた方が現実に近いです。

打刻忘れ修正、月次処理、法改正対応、作成者への属人化など自作勤怠管理で発生する見えないコストを示した図解

スプレッドシート勤怠管理の改ざん・権限リスク

勤怠管理では、計算の正しさだけでなく「記録を誰が変更できるのか」も重要です。

Googleスプレッドシートにはシートや範囲を保護する機能があり、編集できるユーザーを制限できます。

ただし、Google自身もシート保護をセキュリティ対策として使用するものではないと案内しています。

社員が勤怠表そのものを編集する構成では、権限設計、修正履歴、管理者による承認といった運用も含めて考える必要があります。

「セルを保護したから勤怠データの信頼性は十分」とは考えない方が安全です。入力方法、編集権限、修正履歴、承認方法をセットで設計してください。

勤怠管理では労働時間の客観的な把握も重要

勤怠管理は、単なる社内集計表ではありません。

厚生労働省の「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」では、使用者が労働日ごとの始業・終業時刻を確認し、記録することが示されています。

原則的な確認方法としては、使用者による現認、またはタイムカード、ICカード、PC使用時間などの客観的な記録を基礎とする方法が示されています。

厚生労働省「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」

自己申告を使うこと自体が直ちに禁止されているわけではありませんが、自己申告と実際の労働時間に乖離がないか確認するなど、適正な運用が求められます。

私が直行直帰やテレワークでスマホ打刻の必要性を強く感じた理由もここにあります。

PC限定や紙ベースで運用すると、「会社へ戻ってから」「翌日に」「月末にまとめて」と後追い入力が増えやすく、実際の始業・終業時刻との差を確認する作業が増えてしまいます。

日々の15分・30分単位の切り捨ては避ける

もう一つ注意したいのが、労働時間の端数処理です。

日々の労働時間について「15分未満は切り捨て」「30分単位で残業申請」といった一律の切り捨てを行い、その分の賃金を支払わない運用は避ける必要があります。

厚生労働省は、1日の労働時間について1分単位で計算し、切り捨てを行わない考え方を案内しています。

一方で、1か月間の時間外労働・休日労働・深夜労働の各合計に1時間未満の端数が生じた場合には、30分未満を切り捨て、30分以上を1時間へ切り上げるなど、一定の端数処理が認められています。

勤怠システムを自作する場合は、安易に「15分単位で丸める関数」を入れず、自社の就業規則や給与計算方法も含めて確認してください。

本記事は一般的な勤怠管理の考え方を解説するもので、個別企業の法的判断を行うものではありません。変形労働時間制、フレックスタイム制、割増賃金などをシステムへ実装する場合は、就業規則との整合性を確認し、必要に応じて社会保険労務士などの専門家へ相談してください。

自作勤怠からクラウドへ移行した3つの判断基準

私はExcel VBAとGoogleスプレッドシート＋GASの両方で勤怠管理を自作してきました。

そのうえで、自作を続けるか専用システムへ移行するかは「人数が10人を超えたら」といった単純な基準では判断していません。

私が実際に移行を判断した基準は、次の3つです。

1. 法改正への対応が重くなった

残業上限規制、有休取得管理、割増賃金など、勤怠管理に関係するルールが変わるたび、自作したExcel関数やGASが正しいか確認し、必要なら改修・テストしなければなりません。

給与計算の基礎になる仕組みなので、「たぶん合っている」では済みません。

この保守責任を社内で抱え続けるリスクが大きいと判断したことが、移行理由の一つでした。

2. 作った本人しか直せなくなった

自作システムで私が特に危険だと考えるのが属人化です。

「GASでエラーが出たら作った本人しか直せない」「担当者が休むと月末の給与処理が止まる」という状態になれば、便利な自動化ではなく事業継続上のリスクになります。

スタック

エラーを直せるのが自分一人になった時点で、私は「自動化できた」ではなく「会社を自分に依存させてしまった」と考えます。勤怠や給与では特に避けたい状態です。

3. 勤務制度が複雑になった

9時〜18時の固定勤務だけなら、自作でも比較的管理できます。

しかし、変形労働時間制やフレックスタイム制、複数シフトなどが加わると、残業時間の判定ロジックは一気に複雑になります。

勤務制度が複雑化した時点で、私は専用システムを比較する方が合理的だと判断します。

人数よりも「法改正対応」「属人化」「勤務制度の複雑さ」の3点を見る方が、自作からSaaSへ移行するタイミングを判断しやすくなります。

自作で課題を把握し、要件を整理したうえで専用の勤怠管理システムへ移行する流れを示した図解

さらに詳しい移行判断については、勤怠管理をExcelで続ける限界とクラウド移行の判断基準でも整理しています。

クラウド勤怠へ移行するなら何を確認するか

自作の限界を感じたからといって、どの勤怠管理システムでもよいわけではありません。

私は勤怠SaaSへの移行プロジェクトで、要件定義、製品選定、初期設定、社員向け説明まで担当してきました。

その経験から、少なくとも次の項目は実際の運用で確認した方がよいと考えています。

社員がスマホから迷わず打刻できるか
直行直帰やテレワークへ対応できるか
打刻漏れを自動で検知できるか
本人の修正申請と上長承認をどう処理するか
自社の勤務制度へ対応できるか
給与ソフトへ渡すCSVを使いやすい形で出力できるか
月末締めまで管理部門の作業を減らせるか

Relix勤怠はスマホ・GPS・打刻忘れアラートに対応

低コストで試せる候補の一つがRelix勤怠です。

私はRelix勤怠を実際に導入・利用した経験はないため、ここでは現在公開されている公式情報と、管理部門長として自社導入時に確認するポイントを分けて紹介します。

項目	Relix勤怠の公開情報
スマホ打刻	PC・スマートフォンからWeb打刻可能
GPS	位置情報取得に対応
打刻漏れ	予定時刻を過ぎても打刻がない場合、管理者へメール通知
シフト	始業・終業、勤務地、残業時間、公休、特別休暇などを管理
CSV	集計データをCSV出力可能
料金例	10アカウント月額3,000円（税別）
初期費用	0円
無料期間	登録月とその翌月

2026年8月18日時点の公式料金では、1アカウントあたり最大300円（税別）と案内されており、料金例は10アカウント3,000円、30アカウント8,500円、50アカウント13,750円です。

無料期間は「登録した月とその翌月」で、登録日から一律60日間ではありません。

月次締めまで試したいなら、月初から開始した方が検証期間を取りやすくなります。

私が実際に選定するなら、CSVを自社の給与ソフトへそのまま取り込めるか、高度な残業管理や承認フローが自社要件を満たすかまで無料期間中に確認します。公式サイトに明記されていない仕様は契約前に確認してください。

Relix勤怠自体の料金・機能・注意点は、Relix勤怠の料金・無料期間・デメリットを解説した記事で詳しく整理しています。

登録月＋翌月で、打刻から月末締めまで試せます。

無料利用条件を確認する

料金や無料期間、機能、契約条件は変更される可能性があります。申し込み前に遷移先の最新情報を確認してください。

スプレッドシート自作とクラウド勤怠を比較

ここまでの内容を整理すると、次のようになります。

比較項目	スプレッドシート＋GAS	クラウド勤怠
初期費用	既存環境なら抑えやすい	製品による
PC打刻	○	○
スマホ	図形ボタンは不可。フォーム等の工夫が必要	スマホ対応製品が多い
自由度	高い	製品仕様の範囲
打刻修正	自社で設計	製品ごとに確認
法改正対応	自社で確認・改修	ベンダーの対応範囲を確認
保守	自社担当者	主にベンダー
属人化	起こりやすい	比較的抑えやすい
複雑な勤務制度	設計・保守難易度が上がる	対応製品を選択可能

「クラウド勤怠なら何でも法令対応できる」という意味ではありません。

自社の就業規則や勤務制度に対応できる製品を選び、設定内容を正しく合わせる必要があります。

複数製品から選びたい方は、中小企業向けの主要製品を料金・無料利用・勤務形態で比較しています。

勤怠システム7選を見る

スプレッドシート勤怠管理ボタンのよくある質問

Googleスプレッドシートだけで勤怠管理できますか？: 固定勤務・少人数など条件がシンプルであれば、スプレッドシートとGASで打刻・集計の仕組みを構築できます。ただし、打刻修正、残業、有休、複雑な勤務制度まで管理すると保守負担が大きくなります。
スマホから出勤・退勤ボタンを押せますか？: 画像や描画へApps Scriptを割り当てる方式は、スマートフォンからタップしてもスクリプトが実行されません。スマホ前提ならGoogleフォームなど別の入力方法を検討してください。
スプレッドシートで勤怠管理すること自体は違法ですか？: スプレッドシートを使うこと自体が直ちに違法になるわけではありません。重要なのは、実際の労働時間を適正に確認・記録し、賃金計算や修正運用を適切に行える仕組みになっているかです。
何人になったらクラウド勤怠へ移行すべきですか？: 人数だけでは判断できません。私なら「法改正対応が重い」「作成者しか保守できない」「変形労働やフレックスなど勤務制度が複雑になった」のどれかが発生した段階で専用システムへの移行を検討します。
Relix勤怠を実際に使った感想ですか？: いいえ。私はRelix勤怠を導入・無料登録した経験はありません。本記事のRelix勤怠に関する仕様・料金は公開情報を確認して掲載し、選び方については勤怠SaaSの導入経験をもとに管理部門長としての確認ポイントを説明しています。