Coworkで勤怠異常検知を週次自動化する方法

勤怠SaaSとつながなくても勤怠異常検知を組める理由

打刻漏れや残業超過のチェックだけなら、勤怠SaaSに直接つながなくても成立します。お使いの勤怠システムにエクスポート機能があれば、打刻データをExcelやCSVで書き出せます。そのファイルをGoogle Sheetsに読み込んでおけば、あとはCoworkのScheduled Tasksと承認モードの組み合わせだけで週次の異常検知が回ります。

勤怠SaaS側へ直接つなぐ方法もあります。たとえば経費精算・ワークフロー向けですが、Claudeジョブカン連携のように、非公式のコミュニティ製サーバーを導入する手です。ただしSaaS側の仕様変更に追随できるかは開発者の対応次第です。シートを介する構成なら、特定のSaaSに依存せず、乗り換えにも強くなります。

検知の仕組み全体像

担当は2つの標準機能です。Scheduled Tasksが週1回、指定したデータを読みに行って異常の有無を判定します。承認モードは「人事への通知」という書き込み操作の手前で、人の確認を挟みます。検知を自動化しつつ、誤検知をそのまま社内へ流さないための組み合わせです。公式ヘルプの利用例にも、Google Driveやスプレッドシートのデータを週次レポートにまとめる使い方が載っています。

手順1: 勤怠データの置き場所と、タスクが動く場所

エクスポートしたExcel/CSVの置き方は2通りあります。どちらを選ぶかは、タスクがどこで動くかに関わります。

• Google Sheetsに読み込む: connector経由でクラウド上のデータとして扱います。公式ヘルプでは、スケジュールタスクはリモートで動くと説明されています。パソコンがスリープ中でも、Claude Desktopアプリが閉じていても、設定した頻度で実行されます
• パソコンのローカルフォルダに置く: 作成フォームに「どのフォルダで作業するか」を指定する任意項目があります。公式ヘルプはこのとき、ローカルのファイルやアプリが必要なタスクはローカルでのみ実行されると説明しています

公式ヘルプの中でも、ローカルのファイルの扱いは書き方が分かれています。

この食い違いは、手元で動くタスクとクラウドで動くタスクが併存する移行期の記述として読めます。ProまたはMaxで新しく作る勤怠タスクは、クラウド側で動く前提で設計します。Team・Enterpriseについては、この変更の対象としてヘルプに書かれているのはProとMaxのみなので、手元のフォルダを使う構成は実行履歴で動きを確かめてから運用に乗せます。

週次で確実に検知したいなら、データをGoogle Sheetsに先に読み込んでおく構成が最も前提が少なくて済みます。

手順2: 週次のScheduled Taskを作成し、検知条件を書く

勤怠データの条件は会社ごとに違うため、検知条件を細かく書ける作り方を選びます。

手動フォームの頻度は5つの選択肢のみで、曜日や時刻を指定する項目は列挙されていません。「Create with Claude」は、対話しながら条件を詰め、最後に「Schedule」を押して登録する方法です。新しいClaudeの体験では、「毎週月曜の朝9時に〜」のように会話の中で頻度を伝えて登録する流れが、公式ヘルプに例として載っています。

作成画面の各項目の細かい操作はCoworkスケジュールタスクの作成方法で扱っています。初めて作る場合は先に目を通しておくと迷いません。プロンプトの例を次に示します。

毎週の実行時に、[Google Sheetsのシート名]から先週分の勤怠データを読み、
まずデータの最終更新日を確認してください。先週分に更新されていない場合は
「データが未更新のため判定できません」とだけ報告してください。
更新されていれば、以下の異常を検出してください。
1. 打刻の欠落(出勤または退勤のどちらかが未入力の行)
2. 週の残業時間が [自社の基準時間] を超えている従業員
異常があれば、対象者名・異常の種類・具体的な数値を一覧にまとめてください。
異常が無ければ「今週は異常なし」とだけ報告してください。

このレシピの前提は、勤怠SaaSからのエクスポートとGoogle Sheetsへの取り込みを、誰かが週次で手作業で行っていることです。Scheduled Tasksは取り込みそのものを代行しません。取り込みが止まった週は、Claudeが古いデータのまま「今週は異常なし」と報告しかねません。プロンプト冒頭の最終更新日の確認は、そのための保険です。

対象を絞りたいときは、プロンプトに「対象は営業部と開発部のみ」のように部署名を書きます。部署ごとに別々のタスクを作り、承認モードや通知先を変える運用もできます。氏名や部署名はエクスポート元とシートで表記(全角・半角、旧姓併記など)が揺れることがあるので、「表記ゆれがあれば正規化してから判定する」と一文足しておくと、集計から漏れる従業員が減ります。

残業時間の基準は会社ごとに異なります。36協定の上限を判断材料にするなら、協定内容と基準を揃えておきます。協定届の点検はClaudeで36協定届の旧テンプレートを点検する方法にあります。

作成画面には「使用するモデル」を選ぶ任意項目もあります。今回のような単純な集計・分類なら、軽量なモデルを指定してコストを抑える選択肢があります。判定結果に違和感が出たら、その回だけ上位モデルで再実行して比べます。

手順3: 検知結果を承認モード経由で人事へ通知する

検知そのものは手順2で終わりです。結果を人事へ送る操作(Slackへの投稿やメール送信)は、承認モードとconnectorごとのツール権限の掛け合わせで挙動が決まります。承認モードは、Manually approve(Manual)・Automatically approve(Auto)・Skip all approvals(Skip)の3つです。ツール権限も「常に許可」「要承認」「ブロック」の3つがあります。

見落としやすいのは、1行目の「常に許可」です。書き込み系のツールを「常に許可」にしていると、Manualでも確認なしで送信されます。人事への通知に使うツールは、権限を「要承認」にしたうえで、タスクの承認モードをManually approveにします。こうすると送信の直前に、内容を見て許可するか拒否するかを人が選べます。

Autoでは、Claudeが各アクションの安全性(情報の持ち出しやプロンプトインジェクションの疑い)を判定し、危険と見たものをブロックします。ブロックが続くと、Manualと同じく都度の確認に戻ります。この判定は安全性が対象で、検知結果の中身が正しいかは見ません。誤検知をそのまま人事へ送りたくないなら、Manualのほうが確実です。さらにAutoは、ほかのモードより使用量を多く消費します。新しいClaudeの体験では、メッセージ欄の権限設定にAutoとManual(既定)が出ます。

Team・Enterpriseプランでは、個人設定の上に組織管理者の設定があります。Autoを使えるかどうかは管理者が決め、オフにするとモード選択に出なくなります。書き込み系connectorのツールに毎回の承認を求める組織もあり、その場合は「常に許可」の設定が効かないことがあります。公式ヘルプでは、TeamとEnterpriseのCowork自体も管理者のトグルで制御されると説明されています。人事部門で導入するときは、承認モードを選ぶ前に、管理者側の設定を確認します。承認モードの階層構造と組織設定の関係は、Cowork Approval Gatesを部門ごとに設計する考え方にまとめています。

勤怠データを扱うタスクで、通知を誰の目に通すか

公式の安全ガイドは、スケジュールタスクを使うときの注意を4点挙げています。簡単なタスクから始めること、機微なデータや取り消しにくい操作を避けること、実行のたびに結果を見直すこと、使わないタスクは一時停止または削除することです。避けるべき例には、機微なファイルへのアクセスや、本人に代わるメッセージ送信が入っています。

勤怠データは従業員個人の労働時間で、人事への送信は本人に代わるメッセージ送信にあたります。レシピの全体が、このガイドが避けたい側に寄っています。そのため、通知の出し方を段階で変える設計にします。

運用が定着したあとも、検知結果は毎回見直します。担当者の異動などで使わなくなったタスクは、削除せずに一時停止して残す方法もあります。再開(Resume)すれば、設定をそのまま使えます。人事評価や懲戒のような、取り消しにくい判断に検知結果を直接流用しないことも決めておきます。

よくあるつまずき

予定した週にタスクが実行されていない

ローカルのファイルやアプリを使うタスクは、ローカルでのみ実行されます。2026年10月6日以降にProやMaxで作る新しいタスクはクラウドで動くため、この項目は当てはまりません。実行されない週があるときは、Scheduledページの過去の実行履歴で、その時間帯に実行が記録されているかを見ます。同じ状況が続くなら、Google Sheetsへの切り替えを検討します。

検知結果が来ているのに人事に届いていない

Manually approveでは、Claudeは検知結果を示したあと、送信の許可を待って止まります。許可(Allow)を選ぶまで、Slack投稿やメール送信は行われません。承認待ちが溜まっていないか、実行のたびに確かめます。

止めたはずのタスクが動いている

Scheduledページの一覧で、対象のタスク名と状態を見てから、一時停止や削除の操作をします。部署ごとにタスクを分けているなら、名前に部署名を入れておくと取り違えを防げます。

まとめ

このレシピは、勤怠データの取り込みを誰かが週次で続けられることが前提です。着手前に、取り込みの担当と、使っているプランを確かめます。ProとMaxなら新しいタスクはクラウドで動き、Team・Enterpriseなら管理者の設定が承認モードの選択肢を左右します。