「完全自動化」を目指して分かった。止まる自動化と、回り続ける自動化の違い

### 「完全自動化」を目指して分かった。止まる自動化と、回り続ける自動化の違い

「一度自動化したら、あとは放置で動く。」

AIやn8nを触り始めたころ、僕は自動化にそんなイメージを持っていました。

実際、Aethel HoldingsではNotionに投稿ネタを置き、n8nが取得し、OpenAIが文章を作り、Threads APIへ投稿し、最後にNotionを「投稿済み」へ更新する仕組みまで作りました。

ここまでつながると、かなり自動化できたように見えます。

でも、実運用を始めると分かりました。

**workflowが完成することと、仕事が自動で回り続けることは別です。**

今回は、Threads投稿の自動化を実際に動かす中で起きた失敗から、「止まる自動化」と「回り続ける自動化」の違いを整理します。

### 自動化は「成功した1回」では完成しない

最初にThreadsへの自動投稿が成功したときは、かなり嬉しかったです。

Schedule Triggerから始まり、Notion、OpenAI、Threads API、Notion更新まで処理が流れる。

手動で投稿ボタンを押さなくてもThreadsへ投稿できました。

ただ、その後の運用では別の問題が出ました。

たとえば、ローカルPCでn8nを動かしている場合、PC側がスリープ状態になると、予定したScheduleが期待どおり動かないことがあります。

つまりworkflowそのものが正しくても、**workflowを動かしている環境が止まれば自動化も止まる**ということです。

ここで初めて、「処理の設計」だけではなく「稼働環境の設計」も必要だと分かりました。

### 一番怖いのは「途中まで成功した失敗」だった

もう一つ厄介だったのが、処理の途中でエラーになるケースです。

Threadsへの公開処理は成功した。

でも、その後のNotion更新だけ失敗する。

この場合、n8nの実行履歴だけを見ると「エラー」に見えます。

そこで何も考えずworkflow全体をもう一度実行すると、Threads側にはすでに投稿が存在するため、同じ内容を重複投稿する可能性があります。

この経験から、僕の中で自動化の考え方が変わりました。

**エラーが出たかどうかではなく、外部で何がすでに実行されたかを見る。**

これが重要でした。

自動化では、0か100かで成功・失敗が分かれるとは限りません。

投稿は成功、管理更新は失敗。

メール送信は成功、DB記録は失敗。

決済は成功、通知は失敗。

こうした「途中まで成功」がある前提で設計しないと、復旧操作そのものが次の事故になります。

### Notionのエラーで分かった「状態管理」の重要性

Notion連携でもvalidation errorにぶつかりました。

Database ID、プロパティ名、プロパティ型、Selectの値など、workflow側とNotion側の前提がずれると処理は止まります。

ここで重要だったのは、Notionを単なるネタ置き場にしないことでした。

僕たちの運用では、少なくとも「未使用」と「投稿済み」という状態を持たせています。

投稿前なのか。

すでに外部公開されたのか。

次回の処理対象にしていいのか。

この状態が分からなければ、自動化は安全に次へ進めません。

AIに文章を書かせることより、**仕事の状態を機械が判断できる形にすること**のほうが重要な場面があります。

### 「止まる自動化」に足りなかった3つ

実際に動かしてみて、僕は自動化を3つに分けて考えるようになりました。

#### 1. 実行する仕組み

ScheduleやWebhookなど、仕事を始めるきっかけです。

ここが止まれば、workflowの中身が完璧でも何も起きません。

#### 2. 状態を管理する仕組み

未処理なのか、処理中なのか、完了したのか。

外部サービスへの操作がある場合、この状態管理が重複実行を防ぐ土台になります。

#### 3. 失敗から戻す仕組み

どこまで成功したのかを確認し、必要な場所だけ直して再開する。

「エラーなら最初から再実行」ではなく、すでに起きた外部操作を確認してから復旧することが必要です。

この3つが揃って、ようやく「動いたworkflow」から「運用できるworkflow」に近づきます。

### AIを増やすだけでも完全自動化にはならない

これはAI社員についても同じでした。

Research AI、Marketing AI、Writer AI、QA AIのように役割を増やしても、人間が毎回「次はあなた」「次はこれを確認して」と指示していたら、その指示自体が仕事として残ります。

だからAethel Holdingsでは、AIの能力だけではなく、**誰が何を受け取り、何を出力し、次に誰へ渡すか**という工程を決める方向へ進めています。

完全自動化に近づくために必要なのは、「すごいAIを1つ入れること」よりも、仕事が次へ進む条件を明確にすることなのかもしれません。

### 僕が今考える「完全自動化」

今の段階で、Aethel Holdingsが完全自動化できたとは言いません。

むしろ、実際に作っているからこそ、人間がまだ必要な場所が見えてきました。

認証。

例外処理。

外部サービスの仕様変更。

失敗時の判断。

そして、本当に公開してよいかという最終判断。

こうした部分を一つずつ減らしていくのが、今やっていることです。

なので僕にとって完全自動化は、「workflowを作ること」ではありません。

**正常時は人間が触らなくても進み、異常時には何が起きたか分かり、安全に戻せる状態を作ること。**

今はそう考えています。

### まとめ

Threads自動投稿を実際に運用して分かったのは、次のことでした。

- workflowが1回成功しても、自動運用が完成したとは限らない
- 実行環境が止まればScheduleも止まる
- 外部公開後に管理更新だけ失敗する「途中成功」がある
- 状態管理がないと重複処理の危険が増える
- 復旧方法まで決めて初めて運用に近づく

AIやn8nを使うと、以前なら難しかった自動化をかなり小さく始められます。

でも、本当に人の仕事を減らしたいなら、「どう動かすか」と同じくらい「止まったらどうするか」を設計する必要があります。

Aethel Holdingsでは、この失敗も含めて、AI中心の会社をどこまで自動運転に近づけられるかを引き続き公開していきます。

実際に使っているThreads自動投稿の構成を自分の環境で試したい人向けには、n8n workflow・セットアップ手順・Notion DB設計・エラー対応などをまとめた**Threads自動投稿スターターキット v0.1**も公開しています。

販売ページ: https://note.com/hot_kiwi3742/n/n959121d8651f

まず仕組みを理解したい人は、この記事の内容だけでも自動化設計のチェックに使ってください。