Use Cases (更新: 2026/6/7)

定型業務の自動化: 何を自動化すべきか選び、cron・CIで回す手順

毎日の手作業をどう選び、スクリプト化し、cronやタスクスケジューラ・CIで定期実行するか。Claude Codeにスクリプトを書かせ、通知と失敗時の扱いまで実体験でまとめました。

定型業務の自動化: 何を自動化すべきか選び、cron・CIで回す手順

「この作業、先月も先々月もやったな」と気づいた瞬間が、自動化の入り口です。

僕の場合、それは毎週金曜の請求書集計でした。フォルダを開いて、CSVを7個ぜんぶ開いて、合計を出して、検算して、報告フォームに貼る。一回30分。手は動くけど、頭はほとんど使っていない。なのに金曜が来るたびに、その30分が消えていく。

ある金曜、寝坊して時間がなくて、焦って合計を一桁ずらしたまま提出しました。月曜に上司から「これ、ゼロ多くない?」と連絡が来て、冷や汗をかいた。そのとき決めたんです。「もう僕がやらない」と。

今そのルーティンは、毎週金曜の朝にスクリプトが勝手に走って、Slackに結果だけ流してくれます。僕は数字を眺めて、おかしくなければそのまま貼るだけ。今日は「どの作業を自動化すべきか」の選び方から、スクリプト化、定期実行、通知、失敗したときの後始末まで、コードを全部見せながら書きます。

この記事の要点

  • 自動化する作業は「頻度 × 手間」で選ぶ。毎日5分より、毎週30分の方が先に効く
  • いきなり全自動にしない。まず手で動くスクリプトを作り、安全を確認してから定期実行に載せる
  • 定期実行はローカルなら cron / タスクスケジューラ、リポジトリ単位なら GitHub Actions の schedule を使い分ける
  • スクリプト自体を Claude Code に書かせると速い。ただし削除・送信・公開は人間のボタンに固定する
  • 失敗は「黙って止まる」より「気づける形で止める」。終了コードと通知をセットで仕込む

まず「何を自動化するか」を頻度と手間で選ぶ

自動化で最初にやらかすのは、目についた作業から手をつけることです。僕も最初、毎朝の1分の点検を自動化して満足していました。でも1分 × 20日で月20分。仕組みを作る手間のほうが上回っていた。

判断はシンプルな表でやります。縦に「やる頻度」、横に「1回の手間」を取って、右上から潰す。

頻度 \ 手間軽い(数分)重い(15分以上)
毎日後回しでいい最優先
毎週2番目最優先
月1回やらない余裕があれば

毎週30分の作業を自動化すれば、年間で約26時間が浮きます。月1回5分の作業をいくら自動化しても、年1時間。同じ労力をかけるなら、右上から潰すのが圧倒的に得です。

もう一つ条件があります。手順が決まっていること。毎回やることが違う、人間の判断が中心、という作業は向きません。「請求書を集計する」「ログから異常を拾う」「メモを定型に整える」のように、誰がやっても同じ結果になる作業を選びます。逆に「どの案件を優先するか決める」みたいな仕事は、自動化ではなく自分で握る側です。

いきなり全自動にしない。まず手で動かす

自動化を「最初から無人で回るもの」と思っていると、必ず事故ります。順番はいつも同じで、3段で登ります。

  1. 手で実行できるスクリプトを作る。コマンドを叩けば結果が出る状態。まだ人間が見守る。
  2. 数日、手で叩いて様子を見る。変な結果が出ないか、エラーで止まらないか確認する。
  3. 安全だと分かったら定期実行に載せる。cron やタスクスケジューラ、CI に登録する。

この順番を守るだけで、夜中に勝手に走って事故る、という最悪のパターンが消えます。僕は1段目を飛ばして、いきなりタスクスケジューラに登録して痛い目を見ました。設定をミスっていて、毎朝同じスクリプトが2回ずつ走っていたんです(これは後で詳しく書きます)。

ここで一つ言葉を補足します。記事や解説でよく出る「harness(ハーネス)」。直訳は馬具ですが、要はAIを暴走させないための外枠のこと。何を入力し、どこまで許し、どう記録し、ダメなとき止めるか。この枠を先に決めておく、と覚えてください。線の引き方は承認とsandboxの線引き運用術で詳しく掘り下げています。

スクリプトを書く: 集計から通知までを1本に

実物を動かします。僕が毎週やっていた「フォルダのCSVを集計して、結果を通知する」をそのままスクリプトにします。Node.js と Anthropic の API キーがあれば動きます。scripts/weekly-report.mjs として保存してください。コメントは全部日本語にしてあります。

#!/usr/bin/env node
import { spawnSync } from "node:child_process";
import { existsSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
import { join } from "node:path";

const logDir = ".auto-logs";
const lockFile = join(logDir, "weekly.lock"); // 二重起動を防ぐ鍵
const stamp = new Date().toISOString().slice(0, 10);
const reportFile = join(logDir, `report-${stamp}.md`);

// 終了コードを立てて止める小さなヘルパー
function fail(message) {
  console.error(`[NG] ${message}`);
  notify(`週次レポート失敗: ${message}`); // 失敗も通知する(大事)
  process.exit(1);
}

// 通知。ここではSlackのIncoming Webhookに投げる例
function notify(text) {
  const url = process.env.SLACK_WEBHOOK_URL;
  if (!url) return; // Webhook未設定なら黙って何もしない
  spawnSync("curl", ["-s", "-X", "POST", "-H", "Content-type: application/json",
    "--data", JSON.stringify({ text }), url], { encoding: "utf8" });
}

// 鍵を入れ忘れたら、何もせず止まる
if (!process.env.ANTHROPIC_API_KEY) fail("ANTHROPIC_API_KEY が未設定です。");

mkdirSync(logDir, { recursive: true });
if (existsSync(lockFile)) fail(`前回の処理がまだ動いています: ${lockFile}`);
writeFileSync(lockFile, String(process.pid));

try {
  // 1. AIに材料を渡して、集計と「平均から外れた行」だけ報告させる。
  //    書き込み・送信は一切させない(--permission-mode plan = 読むだけ)。
  const prompt = [
    "あなたは経理の集計係です。data/ 配下のCSVを全て読み、",
    "合計と、平均から大きく外れた行だけをMarkdownの表にまとめてください。",
    "ファイルの削除・編集・送信は一切しないこと。読むだけ。",
  ].join("\n");

  const result = spawnSync("claude", [
    "-p", prompt,
    "--max-turns", "8",
    "--permission-mode", "plan",   // 読むだけモード。書き換えさせない
    "--output-format", "text",
    "--max-budget-usd", "0.50",    // 暴走しても上限0.5ドルで止まる
  ], { encoding: "utf8", shell: process.platform === "win32" });

  if (result.status !== 0) {
    fail(`claude が異常終了 (code ${result.status})。${result.stderr || ""}`);
  }

  // 2. レポートを保存して、結果だけ通知する
  const report = result.stdout || "(出力なし)";
  writeFileSync(reportFile, report);
  notify(`週次レポート完成 → ${reportFile}\n${report.slice(0, 1500)}`);
  console.log(`[OK] 書き出しました → ${reportFile}`);
} finally {
  // 終わったら必ず鍵を外す(これを忘れると翌週ずっと弾かれる)
  rmSync(lockFile, { force: true });
}

実行はこれだけ。

node scripts/weekly-report.mjs

数十行ですが、自動化に必要なものが全部入っています。材料をAIに渡す、読むだけに制限する、予算で上限を切る、鍵で二重起動を防ぐ、ログを残す、成功も失敗も通知する。あなたの作業が別物なら、data/ のCSVを集計する部分を、自分が普段やっている処理に差し替えるだけです。--permission-mode plan--max-budget-usd の意味は公式のCLIリファレンスが一次情報なので、引数で迷ったらまずそこを見てください。

スクリプト自体を Claude Code に書かせる

ここからが本題かもしれません。上のスクリプトを一から自分で書く必要はありません。自動化スクリプトそのものを Claude Code に書かせるのが、いちばん速い。

ただし「自動化スクリプト作って」だと、欲しいものは出てきません。僕が使っている頼み方はこうです。

claude -p "scripts/weekly-report.mjs を作って。要件は次の通り:
1. data/配下のCSVを集計するが、集計の中身はclaude -pに任せる
2. 削除・送信・編集は一切しない(読むだけ)
3. 二重起動をロックファイルで防ぐ
4. 成功・失敗どちらもSLACK_WEBHOOK_URLに通知する
5. ANTHROPIC_API_KEY未設定なら即終了する
コメントは日本語で。Windowsでも動くように。"

ポイントは、やってほしいことではなく、守ってほしい制約を先に並べることです。「集計して」だけだと、AIはエラー処理も通知もない最短コードを書きます。一方で「削除はするな」「ロックを入れろ」「通知を入れろ」と制約を渡すと、安全側に倒れたコードを書いてくれる。

書かせた後は、必ず自分の目で2点だけ確認します。

  • 危ない操作が混ざっていないかrm -rf、本番DBへの書き込み、外部への送信。ここだけは目視する。
  • 失敗したとき止まるか。終了コードを立てているか、エラーを握りつぶしていないか。

この2点さえ押さえれば、本体ロジックは多少雑でも後で直せます。コードレビューを習慣にしたい人はCLAUDE.md×権限の実用レシピで、危険な編集を事前に止める設定をまとめています。

定期実行に載せる: cron / タスクスケジューラ / CI

手で動かして安全だと確認したら、いよいよ定期実行です。場所は3つから選びます。

1. ローカルで毎日決まった時刻に走らせる(cron / タスクスケジューラ)

自分のマシンで完結する作業ならこれが手軽です。Linux / macOS なら crontab に登録します。

# 毎週金曜の朝8時15分に実行。出力はログに追記する
15 8 * * 5 cd /path/to/repo && /usr/bin/node scripts/weekly-report.mjs >> .auto-logs/cron.log 2>&1

Windows ならタスクスケジューラに登録します。

# 毎週金曜8:15に登録。-NoProfile で余計な初期化を飛ばす
schtasks /Create /TN "WeeklyReport" /SC WEEKLY /D FRI /ST 08:15 /F /TR "powershell -NoProfile -ExecutionPolicy Bypass -Command `"cd C:\path\to\repo; node scripts\weekly-report.mjs`""

2. リポジトリ単位で定期実行する(GitHub Actions の schedule)

マシンの電源に左右されず、チームで共有したいなら CI が向いています。GitHub Actions なら schedule トリガーで cron 構文がそのまま使えます。.github/workflows/weekly.yml を置きます。

name: weekly-report
on:
  schedule:
    - cron: "15 8 * * 5"   # 毎週金曜 08:15 UTC。日本時間ではないので注意
  workflow_dispatch: {}      # 手動でも回せるようにしておく
jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "20"
      - run: node scripts/weekly-report.mjs
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

workflow_dispatch を入れておくと、スケジュールを待たずに手動で動作確認できます。schedule の時刻は UTC なので、日本時間の朝8時に回したいなら cron: "15 23 * * 4"(前日の23:15 UTC)になります。ここはハマりやすいので、慣れるまでは手動実行で確認しながら調整するのが安全です。CIまわりの組み方はClaude Code CI/CD設定ガイドで詳しく扱っています。

3. どちらを選ぶか

ざっくり、自分しか使わない・ネットに出したくない作業はローカルの cron / タスクスケジューラ。チームで共有する・マシンの電源に依存させたくないなら CI、と分けると迷いません。

通知と失敗時の扱いを必ずセットにする

自動化で一番こわいのは、暴走ではなく「黙って止まっていたこと」です。気づかないうちに止まっていて、3週間ぶんのレポートが欠けていた、というのが本当にこわい。だから、設計の最初から2つを必ずセットにします。

終了コードを正しく立てる。失敗したら process.exit(1) で終わる。これで cron のログや CI の画面に「失敗」が残ります。成功時は0で終わる。当たり前のようで、エラーを try/catch で握りつぶして0で終わらせてしまう事故がよくあります。

成功も失敗も通知する。上のスクリプトでは Slack の Incoming Webhook に投げました。ここで大事なのは、失敗のときこそ通知すること。成功通知だけだと、通知が来なかった日に「成功したのか、そもそも動かなかったのか」が分かりません。失敗時にエラー内容を一行流すだけで、朝の通知欄を見れば状況がつかめます。

失敗したスクリプトを再実行できるようにしておくのも効きます。途中まで進んで止まったとき、最初からやり直して二重処理にならないか。これは「冪等(べきとう)」、つまり何回流しても結果が同じになる設計を意識すると安全です。同じファイルに上書きする、処理済みに印をつけてスキップする、といった工夫で実現できます。本番の障害をどう拾って戻すかは本番障害対応ガイドが参考になります。

僕がやらかした失敗3つ

かっこつけずに書きます。最初の自動化は事故の連続でした。

ひとつ目。いきなり定期実行に載せて、二重起動した。 タスクスケジューラの設定をミスって、同じスクリプトが朝2回ずつ走っていました。読むだけの処理だったから大事には至らなかったけど、これが「書き込む系」だったら、同じレポートが2通生成されて後始末に追われていた。ロックファイル(鍵)を3行入れてからは、後から来た方が弾かれて一発で解決。手で数日動かしてから載せていれば、そもそも気づけた失敗です。

ふたつ目。ログを全部プロンプトに突っ込んだ。 親切のつもりで何万行も渡したら、肝心の失敗行が埋もれて、AIが全然違う場所を「ここが問題ですね」と指してくる。料金と時間だけ膨らんで、結局自分で読み直すはめに。今は末尾だけ渡す(slice(-12000) のように)か、--max-budget-usd で上限を切るようにしています。エラーは最後に出る。AIも末尾を一番よく読む。だから末尾で十分なんです。

みっつ目。失敗を通知し忘れた。 成功通知だけ仕込んで満足していたら、ある週スクリプトが起動失敗していて、通知が来ないことに3日気づきませんでした。「便りがないのは良い知らせ」は自動化では通用しません。今は失敗時こそ赤い文字で通知が飛ぶようにしています。沈黙は、自動化において一番たちが悪い状態です。

よくある質問

Q. cron とタスクスケジューラと CI、結局どれを使えばいい? 自分のマシンだけで完結する作業はローカルの cron(Linux/macOS)かタスクスケジューラ(Windows)。チームで共有したい、マシンの電源に依存させたくないなら GitHub Actions の schedule。まずはローカルで動かし、共有が必要になったら CI に移すのがスムーズです。

Q. API キーを cron や CI にどう渡せばいい? スクリプトに直接書くのは絶対に避けてください。ローカルなら環境変数や .env(リポジトリに入れない)で。CI なら GitHub の Secrets に登録し、上のYAMLのように ${{ secrets.XXX }} で渡します。ログに鍵が出ていないかも一度確認しておくと安心です。

Q. 自動化が暴走してお金がかかったりしない? --max-budget-usd で1回あたりの上限ドル額を切れます。さらに --max-turns でAIのやり取り回数も制限できます。最初は低めに設定して、足りなければ上げるのが安全です。

Q. 失敗したかどうか、どうやって気づく? 終了コードを正しく立て(失敗は exit 1)、失敗時に Slack やメールへ通知を飛ばすのが基本です。CI なら失敗が画面に赤く残り、通知設定で受け取れます。「成功通知だけ」にすると沈黙との区別がつかないので、失敗通知を必ず入れてください。

Q. Windows でも cron みたいなことはできる? できます。タスクスケジューラが cron に相当します。上の schtasks のコマンドをそのまま使うか、GUI から「タスクの作成」で時刻と実行コマンドを設定すれば同じことが実現できます。

実際に試した結果

正直に言うと、最初の1週間はスクリプトの方が手作業より時間がかかりました。鍵を入れ忘れて止まる、ログが多すぎて変な答えが返る、CIの時刻が UTC だと知らず深夜に動く。全部手で直しました。

でも2週目から効いてきた。今は金曜の朝、デスクに戻ると Slack に「週次レポート完成」と、合計と外れ値の表だけが流れています。僕は数字を眺めて、おかしくなければそのまま貼る。あの30分の手作業と、一桁ずらす恐怖から解放されました。

振り返ると、効いたのは賢いプロンプトではなく、地味な土台でした。頻度×手間で作業を選ぶ。手で動かしてから載せる。失敗を通知する。この3つを守るだけで、自動化はちゃんと味方になります。

まとめ

定型業務の自動化は、大げさなパイプラインの話ではありません。毎週・毎日くり返している、頭をほとんど使わない作業を機械に渡すこと。それだけです。

順番はいつも同じ。①頻度×手間で作業を選ぶ → ②手で動くスクリプトを作る(Claude Codeに書かせてもいい) → ③数日見守る → ④cron・タスクスケジューラ・CIで定期実行 → ⑤通知と失敗時の扱いをセットにする。まずは自分の「毎週やっているあれ」を一つ選んで、上のスクリプトを差し替えるところから始めてみてください。

もっと体系立てて学びたい、あるいはチームの作業をまとめて自動化したいなら、教材一覧に手を動かしながら学べるものをそろえています。自分のケースで相談したい人は、そこから声をかけてもらえれば。

#claude-code #自動化 #業務効率化 #cron #ワークフロー
無料

無料PDF: Claude Code はじめてのチートシート

まずは無料PDFで基本コマンドと最初の使い方をまとめて確認してください。登録後はそのままテンプレート集や導入相談にも進めます。

スパムは送りません。登録情報は厳重に管理します。

Claude Codeを仕事で使える形にしませんか?

まず無料PDFで基本を固め、繰り返し使う作業はGumroad教材へ、チーム導入や権限設計は導入相談へ進めます。

Masa

この記事を書いた人

Masa

Claude Codeの実務活用、導入設計、収益導線改善を検証しているエンジニア。10言語の技術メディアを運営中。

PR

関連書籍・参考図書

この記事のテーマに関連する書籍を楽天ブックスで探せます。

※ 当サイトは楽天市場のアフィリエイトプログラムに参加しています。上記リンクから商品をご購入いただくと、運営者に紹介料が支払われる場合があります。