毎日の作業を自動で回す型｜自動化していい仕事・してはいけない仕事

自動化で最初に決めるのは、道具ではありません。「何を任せるか」の選び方です。

選び方は1行で言えます——回数が多く、手順が毎回ほぼ同じ仕事から。そして、判断が要る仕事と、失敗が高くつく仕事は先に外す。この記事は、その選び方を、実際に手を動かせる手順まで丁寧にやります。

この記事で分かることは4つです。自動化する仕事の見分け方、AIに任せる部分と任せない部分の線引き、最初の1本を安全に動かす手順、そして毎日回し続けるための見張り方です。

最初の1本は「回数×固定度×戻せるか」で選ぶ

まず、普段の作業を思いつくまま書き出します。その横に、次の4つを書き足します。

1. 回数 — どのくらい繰り返すか(毎日・毎週・年に一度)。
2. 手順の固定度 — 「最初にこれ、次にこれ」と説明できるか。説明の途中で「その時による」が何度も出る仕事は、まだ自動化しません。
3. 失敗したときの影響 — 間違えたら誰が困るか。お金や外部への送信が絡むか。
4. 戻せるか — 失敗しても、元のデータからやり直せるか。

この4つ目が大事です。回数が多い仕事でも、一度の間違いを取り消せないなら、最初の1本には選びません。AIエージェントを作るためのOpenAIの公式ガイドも、任せる作業の危険度を「読むだけか、書き換えるか」「元に戻せるか」「どんな権限が要るか」「お金に影響するか」で評価するよう勧めています。

早見表にすると、こうなります。

作業の例	回数	手順の固定度	失敗したら戻せるか	最初の1本に向くか
決まったフォルダのファイル名をそろえる	毎日	高い	元ファイルが残っていれば戻せる	◎ 向いている
受け取った文章の要約・下書き作り	毎週	中くらい(AIの出力は揺れる)	下書きの段階なら戻せる	○ 人の確認つきで
お客さまへの最終返信の送信	毎日	低い(相手ごとの判断が要る)	送った後は戻せない	× 下書きまでにする
データの削除・支払い	月に数回	高い	戻せない	× 自動実行から外す

反対に、年に一度しかない資料作りは、手間がかかっても最初の候補には向きません。仕組みを作る時間を取り戻しにくいからです。

AIに任せる工程・任せない工程を線引きする

同じ「自動化」でも、中身は2種類に分かれます。

一つは、答えが一つに決まる工程です。ファイル名の変更や、決まった形式への変換がこれです。ここは、AIではなく普通の自動処理(=毎回同じ結果が出る仕組み)に寄せます。

もう一つは、結果が揺れる工程です。文章の要約や、内容を見て分類する作業がこれです。ここだけAIに任せます。ただし、AIの出力をそのまま送信・公開してはいけません。「どこで人が確認するか」を、作る前に決めておきます。

先ほどのOpenAIのガイドは、人が介入する条件として、失敗の回数が上限を超えたときと、機密性が高い・元に戻せない・重要性が高い操作を挙げています。米国の標準技術研究所(NIST)がまとめたAIリスク管理の枠組みも、人とAIの役割分担を文書に残し、意図と違う結果を出したら止められる仕組みを求めています。国の機関と開発元の両方が、同じことを言っているわけです。

具体的には、次の仕事を最初の完全自動化から外します。

• データの削除
• 支払い
• 外部への公開・送信
• お客さまへの最終回答
• 個人情報を扱う処理

これらも「全部を手作業のままにする」のではありません。読み取りと下書きまでを自動化し、外へ出す直前で止めるという分け方をします。あわせて、自動化に渡す権限は必要最小限にします。GitHubの公式のセキュリティ案内も、自動化に使う認証情報(=仕組みに渡す鍵)は最小の権限にし、パスワードなどの秘密を設定ファイルへそのまま書かないよう求めています。渡す権限が小さいほど、失敗したときの被害も小さくなります。

最初の1本は「読む→直す→確認用に出す」で作り、まず手で動かす

最初は、数分で終わる単純な作業を一つ選びます。作りは次の型にします。

1. 元のデータは読むだけにする(書き換えない・消さない)。
2. 結果は確認用の場所へ出す(別フォルダや下書きなど、本番とは別の場所)。
3. 合格の条件と、失敗と判定する条件を先に決める。1回に処理する最大件数も小さく決めておきます。
4. 手で起動して、何度か試す。普通のデータ、空のデータ、想定外のデータの3パターンを流します。
5. 失敗したときに止まること、元のデータが残っていることを確かめる。

たとえば「受け取った文章を、日付ごとの名前で保存する」作業なら、元の文章は残したまま、保存前に予定のファイル名を表示し、人が見てから実行する形にします。これだけで、同じ日に別の名前ができるような取り違えを防げます。

「手で起動する」ための仕組みは、たいていの自動化サービスに用意されています。一例を挙げると、GitHub Actions(GitHubの自動実行サービス)では、workflow_dispatch という設定を足すと画面のボタンから手動実行できます。NISTの枠組みも、導入前に実際の環境に近い条件で試験することを求めています。いきなり毎日動かさない、が原則です。

定期実行へ移すときは、通知・記録・停止手段をセットにする

手動で成功と失敗の両方を確かめたら、はじめて「毎日決まった時刻に動かす」へ移します。ここで知っておくべき注意が3つあります。

1つ目、時刻指定はぴったりを保証しません。 GitHub Actionsの例では、時刻指定(schedule)は cron という書き方で行い、既定は世界標準時(UTC)、最短間隔は5分です。そして公式の説明に、混雑時は遅れることがあり、混み方によっては実行が破棄される場合もある、と明記されています。締切に直結する処理は時間に余裕を持たせ、「動かなかったこと」に気づける別の確認を用意します。数字や仕様は変わり得るので、2026-07-25時点の公式案内で確認してください。

2つ目、失敗に気づける通知を付けます。 動いたことより「おかしいときに気づけること」が大切です。GitHub Actionsなら、実行結果の通知を設定でき、失敗した実行だけ知らせる形も選べます。記録は難しくなくてよく、実行日時・処理件数・成功と失敗の数・止まった工程が分かれば十分です。実行履歴のログを見れば、どの工程で失敗したかを後から追えます。

3つ目、止める手段を先に確かめます。 失敗をやり直す再実行、進行中の中止、仕組みそのものの無効化(=全体を止めるスイッチ)が使えるかを、動かす前に一度試しておきます。GitHub Actionsでは再実行・中止・無効化が公式に用意されています。同じ失敗を無限に繰り返させず、「何回失敗したら人へ戻す」という上限も決めておきます。

なお、ここではGitHub Actionsを例にしましたが、すべての自動化にGitHubが必要という意味ではありません。どの道具を使う場合でも、手動テスト→通知→記録→停止手段という型は同じです。そして、手順やAIのモデルを変えた日は、定期実行へ戻す前にもう一度手で試します。仕事のやり方が変わったのに古い仕組みだけが動き続ける場面が、一番詰まりやすいからです。

よくある質問

最初に自動化するなら、どんな作業が向いていますか？

回数が多く、手順と入力・出力を説明でき、失敗しても元のデータからやり直せる小さな作業が向いています。頻度だけで選ばず、書き換える権限が要るか、お金に影響するかも含めて比べてください。

AIにメール送信や支払いまで任せてもよいですか？

最初の自動化では、下書きや候補作りまでに留め、送信・支払いの直前で人が確認する形をおすすめします。開発元であるOpenAIの公式ガイドも、元に戻せない操作や重要性の高い操作には人の監督を入れるよう案内しています。将来もずっと不可能という意味ではなく、業務ごとの評価を別に行ってから広げてください。

毎日決めた時刻に設定すれば、必ずその時刻に動きますか？

仕組みによりますが、少なくともGitHub Actionsの時刻指定は、混雑時に遅れたり、実行が破棄されたりする場合があると公式に書かれています。締切に直結する処理は余裕を持たせ、「実行されなかったこと」を検知する確認を別に用意してください。

自動化の記録には何を残せばよいですか？

最低限、実行日時・処理件数・成功と失敗・失敗した工程を残します。工程ごとの状態を追えるログがあれば、同じ失敗が再発していないかの確認と、原因調べに使えます。

何回試したら、手動から毎日の自動実行へ移せますか？

「何回成功すれば安全」という決まった数字はありません。回数ではなく、普通のデータ・空のデータ・想定外のデータ・途中での失敗、の4パターンで期待どおりに動く(失敗時はきちんと止まる)ことを確認できたかで判断してください。移した後も、監視は続けます。

まとめ

• 普段の作業を書き出し、「回数・手順の固定度・失敗の影響・戻せるか」の4項目で比べて、最初の1本を選ぶ。
• 削除・支払い・送信・個人情報は最初の完全自動化から外し、元データを残した「読む→直す→確認用に出す」の型で作って、まず手で動かす。
• 毎日の定期実行へ移すときは、失敗の通知・実行の記録・止めるスイッチの3つを先に用意し、手順を変えた日は手動テストからやり直す。

公式一次情報

確認日: 2026-07-25

• Events that trigger workflows: 時刻指定(schedule)はcronで書き、既定はUTC・最短5分。混雑時は遅延し、実行が破棄される場合もあると明記されている。
• Manually running a workflow: workflow_dispatchを設定すると画面・CLI・APIから手動実行できる。実行には書き込み権限が必要。
• Secure use reference: 自動化に渡す認証情報は必要最小限の権限にし、秘密情報を設定ファイルへ平文で書かないことが案内されている。
• Notifications for workflow runs: 実行完了時に成功・失敗などの状態を通知でき、失敗した実行だけ通知する設定も選べる。
• Managing workflow runs: 失敗ジョブの再実行(最初の実行から30日以内)、進行中の中止、ワークフロー自体の無効化・再有効化ができる。
• Viewing workflow run history: 各実行にジョブ・ステップごとの状態を含むログがあり、CLIでも履歴と詳細を確認できる。
• A practical guide to building agents: AIに渡す道具の危険度を可逆性・権限・金銭的影響などで評価し、高リスクな操作や失敗の上限超過では人へ引き継ぐ考え方を示している。
• AI RMF Core: 人とAIの役割・想定する損失を文書化し、導入前試験と運用中の監視、意図と違う結果を出すシステムを停止・無効化できる仕組みを求めている。