AI自動化ワークフローは、固定プロセス、AI判断、trigger、失敗通知をつなぐ監視可能なsystemです。「全部AIに任せる」ことではありません。最初に、いつtriggerするか、失敗を誰が知るか、最後の動作を戻せるかを確認します。
AI自動化は「すべてをAIに任せる」ことではない
外向けの宣伝画像では、だいたい「すべて自動処理して」と一言投げると、AIが全部やってくれるように描かれます。実際に作ると、3つの問題にぶつかります。
- トリガーの種類：時間スケジュール、フォーム、Webhook、人のレビュー。ツールごとにできることが違います。
- 失敗戦略：API停止、token期限切れ、形式変更は必ず起きます。
- 可逆性：自動で走ると取り返しがつかない作業があります。送金、削除、外部送信などです。
この3つを先に置いてからツールを選ぶと、「順調に動くけれど、事故った後に誰も追えない」ワークフローを作りにくくなります。
主流の4ルートをどう分けるか
| ルート | 形態 | 課金 | 向いている用途 |
|---|---|---|---|
| Make / Zapier | no-code SaaS | Makeはcredits、Zapierはtasks | 個人、小チーム、app横断の中規模自動化 |
| n8n | self-hostまたはcloud | 自ホスト無料 / cloudはexecutions課金 | 技術チーム、データ自主管理、多段階フロー |
| 自作cron + LLM API | プログラム / スクリプト | 主にAPI呼び出し費 | 開発者、高頻度、ロジックと失敗戦略を完全管理したい場合 |
| Power Automate | M365内蔵 | per user / per botライセンス | すでにMicrosoft 365体系にいる会社 |
4ツールの詳しい比較は 自動化ツール比較（2026） にまとめています。
ツール選択表：n8n、Make、Zapier、Cron
| 需求 | まず見るもの | 理由 |
|---|---|---|
| Gmail / Notion / Sheetsをすぐつなぐ | Make / Zapier | connectorが多く、開始が速い |
| 長いworkflow、分岐、データ管理 | n8n | execution課金が長いflowに合い、自ホスト可能 |
| 会社がMicrosoft 365中心 | Power Automate | Outlook、Teams、SharePoint連携が深い |
| 開発者が高頻度・完全制御したい | Cron + LLM API | costは透明。ただし監視と保守は自分 |
n8nのintentは別枠で見ます。無料toolを探す人ではなく、systemを持つ覚悟がある人向きです。自ホストはSaaS実行費を抑える代わりに、backup、credentials、patch、incident responseを引き受けます。
まずトリガーを選ぶ：時間 / フォーム / Webhook / 人のレビュー
時間トリガー：毎日 / 毎時 / 15分ごとに実行。用途は朝刊、定期polling監視など。MakeとZapierの無料版は最短間隔が15分である点に注意。
フォーム / イベントトリガー：フォーム送信後、メール受信時、SNSの新規投稿時に開始。用途はlead受付、一次サポート、SNS監視。
Webhookトリガー：別システムがHTTPリクエストを送って開始。用途はシステム連携、CI/CD、第三者callback。
人のレビュートリガー：AIの下書きを受信箱に置き、人が「承認」を押してから送信。用途は外部メール、投稿公開、承認フロー。
2本の関連記事TL;DR
ツール比較：まず課金単位を見る
自動化ツール比較の要点は、Make、n8n、Zapier、Power Automateが同じものに課金していないことです。Makeはcredits、Zapierはtasks、n8n cloudはexecutions、Power Automateはlicenseです。長い多段workflowはZapierで高くなりやすい。自ホストとデータ管理が必要ならn8n。ただ2-3個のappを素早くつなぐだけならMake / Zapierの方が保守は軽いです。
排程：時間通りに動くだけでは足りない
AI排程システム実戦はcron、n8n schedule、Make scheduleの失敗面を扱います。時間triggerは始まりで、本当に設計するのはlog、retry、alert、人の承認gateです。日次レポートと5分ごとの監視ではcostも保守圧も違います。外部投稿、削除、送金はreviewなしで自動送信しません。
自動化に向いている仕事
- 繰り返し頻度が高い：毎日、毎週行い、流れが固定されている。
- 失敗コストが低い：壊れても再実行すればよく、取り返しのつかない損失にならない。
- 出力を検証しやすい：出てきたものを目で見て、合っているかすぐ判断できる。
例：ニュース要約、SNS予約投稿、定期レポート、データ集約、ファイル名の整理。
自動化すべきでない仕事
- 一回きりの判断仕事：フローを作る時間が、一度手作業する時間を超える。
- 取り返しのつかない外部アクション：レビューなしの自動メール送信、自動送金、自動削除。
- 失敗に気づきにくい仕事：間違って走っても誰も気づかず、後から追うコストが高い。
「取り返しのつかない」作業の折衷案：AIが下書きを作る → 人のレビューゲート → 送信。
初心者の最初のworkflow設計
- 毎日手作業していて、流れが固定され、低リスクなことを1つ選ぶ。
- トリガー条件 → ステップ → 期待する出力を書き出す。
- MakeかZapierで第1版を作り、最も楽観的な経路（happy path）を通す。
- 失敗通知を追加：失敗時に自動でメール / Slack通知 / log書き込み。
- 1週間試し、実際のcredits / tasks消費を見る。
- 安定を確認してから2本目へ広げる。
最もよくある「失敗通知なし」の問題は、自動化が3日止まってから発見され、すでにタイミングを逃していることです。設計時点で必須項目として扱います。
公開前に必ず入れる失敗通知
- タスク完了後に状態logを1件書く（成功 / 失敗 / スキップ）。
- 予定時間を超えて新しいlogがなければalertを出す。
- API失敗時は自動retryをN回行い、その後警告に昇格する。
- outbound動作（メール、公開、送金）には最後の人間confirmゲートを残す。
結論
自動化の最初の規律は、「時間通りに実行されること」と「安心して任せられること」は別物だということです。本当に設計すべきなのは、失敗がどう見えるか。低リスク・高頻度・検証しやすい仕事から始め、最初の安定したフローを育ててから拡張します。
こぺんぎんの体験談
OpenClawのcronシステムは、こぺんぎんが現在回しているdaily driverです。毎日決まった時間にデータを取りに行き、Claude系モデルで整理し、作業ノートに書き込み、エラーはTelegramへ警告として流します。全体はcode-basedの自作ルートで、Make / n8n / Zapierをつないだものではありません。そのため「自動化はどこで壊れるか」について体感があります。よく踏む落とし穴は、token期限切れ、APIのschema変更、クラウドサービスのrate limit変更の3つに集中します。この3つが失敗caseの大半で、AIの文章品質が悪いことはむしろ主因になりにくいです。
「一般の非エンジニアでもできるか」については、できます。ただしno-codeツールから始め、最初のフローを安定させ、失敗通知を作ってから自ホストを考えるのがおすすめです。Code-basedルートのハードルは「書けるかどうか」ではなく、「毎週メンテナンスする時間を取る気があるか」です。
関連記事
よくある質問
Q: n8nとMakeはどう選びますか？
早く始めたい、サーバー管理を避けたいならMake。自ホスト、データ管理、長いworkflow、技術チームの保守が必要ならn8nです。
Q: AI自動化と従来の自動化の違いは？
従来の自動化は固定if-thenが中心。AI自動化は内容を読み、要約し、分類するモデル段階が入り、非構造データに強い一方でalertとreviewが重要です。
Q: コードを書けなくてもAI自動化はできますか？
できます。Make、Zapier、n8n cloudは視覚的にAIとappをつなげます。最初は低リスクで検証しやすく戻せる作業から始めます。
Q: 自動化しない方がいい作業は？
不可逆、センシティブ、失敗に気づきにくい、一回限りの判断は直接自動化しません。送金、削除、法務、医療、未reviewの公開などです。
Q: Webhook、Cron、フォームtriggerの違いは？
Cronは時間、Webhookは別systemのevent、フォームはuser入力で始まります。先にtriggerを決めてからtoolを選びます。
— Penchan