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

Coworkの標準機能だけで勤怠異常検知が完結する理由

ジョブカンやSmartHRのような個別の勤怠SaaSには、公式のMCPサーバーが用意されていません。Claudeジョブカン連携のように非公式のコミュニティ製サーバーを導入する手はあります。ただし勤怠SaaS側の仕様変更に追随できるかは、開発者の対応次第という不確実さが残ります。

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

検知の仕組み全体像

仕組みは2つの標準機能の組み合わせです。Scheduled Tasksが週1回、指定したデータを読みに行って異常の有無を判定します。承認モードが「人事への通知」という書き込み操作の手前で人の確認を挟みます。この2段構えにより、検知の自動化と、誤検知をそのまま社内へ流さない安全弁を両立させます。

手順1: 勤怠データをClaudeから読める場所に用意する

勤怠SaaSからエクスポートしたExcel/CSVファイルは、次の2通りの置き方ができます。どちらを選ぶかでタスクの実行安定性が変わります。

• Google Sheetsに読み込む: connector経由でクラウド上のデータとして扱われます。タスクはクラウド側で動くため、パソコンがスリープ中やClaude Desktopアプリを閉じていても、設定した頻度どおりに実行されます
• パソコンのローカルフォルダに置く: Scheduled Task作成時に「どのフォルダで作業するか」を指定できます。ただしこの指定は、タスクをパソコン上のフォルダに常時紐づけるものではなく、その実行をローカル実行にする指定です。公式ヘルプも「ローカルのファイルやアプリが必要なタスクはローカルでのみ実行される」と明記しています

ローカルフォルダを指定した場合、実行はデスクトップアプリ側で行われるため、その時間帯はパソコンを起動しておき、Claude Desktopアプリも開いておく必要があります。週次で確実に検知したいなら、Google Sheetsへの読み込みを先に済ませておくのが安全です。

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

Scheduled Taskの作成方法は2通りあります。「Create with Claude」は、対話しながらClaudeに条件を詰めてもらい、最後に内容を確認してから登録する方法です。「Set up manually」は、タスク名・プロンプト・承認モード・頻度・(任意で)モデルと作業フォルダを、フォームに直接入力する方法です。検知条件を自分で細かく詰めたい今回のようなケースでは、後者の手動設定が向いています。

「Scheduled」をサイドバーから開き、「New task」→「Set up manually」を選びます。頻度は毎時・毎日・毎週・平日・手動から選べるので、ここでは「毎週」を選択します。曜日や時刻まで指定する項目は無いため、実行タイミングの細かい調整はできません。作成画面の各項目の細かい操作はCoworkスケジュールタスクの作成方法で扱っているので、初めて作る場合は先にひととおり目を通しておくと迷いません。プロンプトにはそのまま次のような指示を書きます。

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

このレシピの前提は、勤怠SaaSからのExcel/CSVエクスポートとGoogle Sheetsへの取り込みを、誰かが週次で手作業で行っていることです。Scheduled Tasksはこの取り込み作業そのものを代行しません。取り込みが止まった週があると、Claudeは古いデータのまま「今週は異常なし」と報告しかねないため、プロンプトに上記のような日付確認の一文を入れておきます。

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

作成画面には「使用するモデル」を選ぶ任意項目もあります。今回のような単純な集計・分類作業であれば、既定の上位モデルにこだわらず、軽量なモデルを指定してコストを抑える選択肢も検討に値します。判定結果に違和感が出るようなら、その回だけ上位モデルに切り替えて再実行し、精度を確認します。

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

検知そのものはここまでで終わりです。しかし結果を人事へ送る操作(Slackへの投稿やメール送信)は、承認モードの設定次第で挙動が変わります。Coworkには3つのモードがあり、connectorごとのツール権限(常に許可・要承認・ブロック)との掛け合わせで、実際に確認を挟むかどうかが決まります。

人事への通知は書き込み操作にあたります。メッセージ送信を担うconnectorのツール権限を「要承認」に設定し、タスクの承認モードをManually approveにしておきます。こうすると検知結果の内容をClaudeが提示したうえで、実際に送信するかどうかを毎回人が選べます。「Automatically approve」でも書き込み系ツールは都度Claudeが安全性を判定します。ただし内容そのものの妥当性まではチェックしません。誤検知をそのまま人事へ送りたくない場合は、Manuallyの方が確実です。

Team・Enterpriseプランでは、この個人設定より上に組織管理者の設定があります。管理者は「Automatically approve」の使用可否や、書き込み系connectorのツールに毎回の承認を必須にするかどうかを組織全体で強制できます。人事部門で導入する場合は、担当者が承認モードを選ぶ前に、管理者側の設定を確認しておきます。そもそもCowork自体の利用を有効にするかどうかも管理者のトグルで制御されています。承認モードの階層構造や組織設定との関係はCowork Approval Gatesを部門ごとに設計する考え方にまとめています。

個人の勤怠データを扱うタスクだからこその注意点

公式のセキュリティガイドは、Scheduled Tasksを使う際の注意として「まずは低リスクなタスクから始める」「機微な情報や取り消しにくい操作を含むタスクは避ける」「実行結果を都度レビューする」「使わなくなったタスクは一時停止する」を挙げています。勤怠データは従業員個人の労働時間という機微な情報にあたるため、この4点は他のタスクよりも意識する価値があります。

具体的には、最初の数週間は検知結果を自分だけが見る場所(自分宛のSlack DMなど)に送るところから始め、検知精度に問題が無いことを確認してから人事の共有チャンネルへ切り替えるという段階運用が安全です。運用が定着したあとも、検知結果は毎回レビューし、担当者が異動して使わなくなったタスクは一時停止しておきます。人事評価や懲戒のような、取り消しにくい判断に検知結果をそのまま流用しないことも意識しておきます。

よくある質問

特定の部署だけを検知対象にできますか

できます。プロンプトに「対象は営業部と開発部のみ」のように部署名を明記すれば、Claudeはその範囲だけを読んで判定します。全社一括ではなく部署ごとに別々のScheduled Taskを作り、それぞれの承認モードや通知先を変える運用も可能です。

通知先はSlack以外でも良いですか

はい。Scheduled TasksはSlackの検索・投稿に限らず、接続済みのconnectorやpluginを使ってメール送信やファイル生成なども行えます。人事側が使っているツールに合わせて、通知手段をSlack投稿にするかメール送信にするかを選べます。どちらを選んでも、書き込み系のツールである以上、承認モードの設計は同じように効きます。

よくあるつまずき

予定していたタイミングでタスクが実行されていない

ローカルのExcelファイルをフォルダ指定で使っている場合、実行はデスクトップアプリ側で行われます。パソコンが起動していない、またはClaude Desktopアプリが閉じている時間帯に実行予定が重なると、その回は実行されません。「Scheduled」ページで過去の実行履歴を確認します。同じ状況が続くようならGoogle Sheetsへの切り替えを検討します。

データが先週分に更新されていない

エクスポートと取り込みの手作業が止まっていると、Claudeは古いデータのまま判定してしまいます。プロンプトにデータの最終更新日を確認させる一文を入れておけば、「データが未更新のため判定できません」という報告に切り替わり、古いデータでの誤った「異常なし」報告を防げます。

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

承認モードをManually approveにしていると、Claudeは検知結果を提示した時点で送信の許可を待って止まります。タスクの実行結果画面で許可(Allow)を選ぶまで、実際のSlack投稿やメール送信は行われません。この待機を放置していないか、実行のたびに確認します。

部署名や従業員名の表記ゆれで異常が抜け落ちる

エクスポート元の勤怠SaaSとGoogle Sheets側で氏名の表記(全角・半角、旧姓併記など)が揺れていると、集計から漏れる従業員が出ます。プロンプトに「表記ゆれがあれば正規化してから判定する」と一文足しておくと、抜け漏れを減らせます。

タスクを止めたはずなのに実行され続ける

一時停止(Pause)したつもりが、実際には別の似た名前のタスクを止めていたというケースがあります。「Scheduled」ページの一覧で、対象のタスク名と頻度を確認してから一時停止・削除の操作を行います。特に部署ごとにタスクを分けている場合、名前を具体的に付けておくと取り違えを防げます。

まとめ

CoworkのScheduled Tasksで勤怠データを週次で読みに行きます。承認モードで人事への通知手前に人の確認を挟みます。この2つの標準機能だけで、個別の勤怠SaaSに依存しない打刻漏れ・残業超過の検知が組めます。ポイントは2つです。データの置き場所をGoogle Sheetsにするかローカルフォルダにするかで実行の安定性が変わること、そして通知という書き込み操作の承認モードをManually approveにして誤検知をそのまま社内へ流さない設計にすることです。勤怠SaaS自体との連携を強化したい場合は、非公式MCPサーバーを使う選択肢と組み合わせて検討します。全社の離職率のような集計済みKPIを俯瞰したい場合は、扱う粒度が異なる点に注意しながら別のデータ分析基盤を検討する価値もあります。