自動化がうまく回っているかは、担当を何個に分けたかではなく、指示の入口が1つにまとまっているかで決まります。うちは1日で14の「係」を作ったあと、note下書きの自動化を司令塔に一本化しました。この記事は1本の自動化の作り方ではなく、複数持ったあとに何が壊れたかの記録です。
対象は、ひとりで事業や配信を回していて、AIに事務作業を任せ始めたら管理そのものが増えてしまった人。2026年9月18日から21日までの実作業ログをそのまま書きます。うまくいった話より、詰まった場所のほうを多く書きます。
結論：自動化の点検は「係の数」ではなく「入口の数」で見る
自動化が増えて苦しくなったときに見るべきは、担当をいくつ作ったかではありません。指示を出す入口と、報告が返ってくる出口が1本にまとまっているかです。うちの場合は、係を一気に増やした時期に手直しが増え、入口を1つに戻した時点で朝に見る場所が減りました。
先に言葉を揃えておきます。
| 記事内の言葉 | 言い換え |
|---|---|
| 係 | 特定の作業だけを受け持たせた自動処理の単位（note係、X係など） |
| 司令塔 | すべての指示と報告が通る、1つの窓口 |
| ジョブ | 決まった時刻に自動で走らせる処理 |
| 生存確認 | その処理がちゃんと動いているかを見張る仕組み |
担当を分けるほど、つなぎ目の手直しが増える
分けること自体は悪くありません。壊れたときに、その係だけ直せばいい。狙いは正しかったと今でも思っています。
問題は、分けた数だけ「つなぎ目」ができることでした。どの係にどう指示を出すか、結果をどこに返すか。ここが係ごとにバラバラだと、係を1つ足すたびに、つなぎ直す手作業が1つ増えます。
入口が1つなら、詰まった場所がすぐ分かる
入口と報告先が1か所にまとまっていれば、朝そこを見るだけで「どれが止まっているか」が分かります。逆に入口が分かれていると、係の数だけ見に行く場所ができます。うちが9月21日にやったのは、係を減らす作業ではなく、この入口だけを1つに戻す作業でした。
以下、9月18日から21日までを時系列で書きます。
前提：noteの下書き自動化は「どこまで自動にするか」で作りが変わる
まず一般論として共有しておきたい前提があります。noteには外部プログラムから操作するための公式な窓口（API）が公開されていません。非公式の手段やブラウザの自動操作を使う方法は語られていますが、規約面・アカウント面のリスクが伴います。
noteに公式APIがない以上、投稿の最後は手元に残る
この前提があるので、多くの人が「書く」と「出す」を分ける結論に落ち着きます。うちも同じです。自動化したのは、下書きを作ってファイルに書き出すところまで。公開ボタンは自分で押しています。
うちは「書く」までを自動、「出す」は手元に置いた
9月21日の一本化で決めた形は、こうです。
- 記事が合格判定を通る
- 通ったものだけ
Documents/note下書きへ自動で書き出す - 同じものを iCloud にも書き出す
- あとは自分で開いて、note に貼って出す
ここまでが前提です。本題は「1本をどう作るか」ではなく、この手の自動化を何本も持ったあとに何が起きるかのほうです。
読みながら気になったことは、そのままLINEで
「うちの場合はどうなる？」という個別の質問に、担当者がLINEでお答えします。
公式LINEで相談する質問だけでも大丈夫です。担当者がLINEでお返事します。
9-18：1日で14の「係」を作って、夜のジョブに全部つないだ
2026年9月18日、1日で14の係を作りました。名前を挙げると、展開係、X係、note係、TikTok係、Instagram係、アフィリエイト係、ポートフォリオ係、Brain係、数値係。ここまで立てて、夜に自動で走るジョブに接続しました。
展開係・X係・note係…どこまで分けたか
分けた動機は正直に書きます。担当を分ければ、壊れたときにその係だけ直せばいいと思っていたからです。1つの巨大な処理にしておくと、どこで転んだか分からなくなる。だから細かく割った。この判断自体は、今も間違いだとは思っていません。
分けた直後は気分がいい。問題は翌日から出る
同じ日に、朝7:30にDiscordへ指示書を出すジョブも登録しました。さらに、すでに動いていた4つのジョブには、司令塔へ報告を返す処理を後から足しました。
書いていて気づくのですが、この時点ですでに「後から統合する作業」が発生しています。新しく作るときは統合を前提に組めても、既に動いているものには後付けになる。係を14個に増やした日のうちに、その後付け作業が4件出ていたわけです。ここが後の伏線になりました。
9-19〜9-20：係が増えるほど、手直しが増えた
note開設と記事2本、Xの実測を見て集客方針を変えた
9月19日にnoteを開設して、記事を2本出しました。同時に、Xの実測を見て集客の方針を見直しています。仕組みを作って終わりではなく、出した結果を見て方針側を変えた形です。
見直した先は、リプライと紹介者の開拓。数字の中身は手元で見ているだけなので出しませんが、「投稿を増やす」方向ではなく「関係を作る」方向に寄せた、という事実だけ記録しておきます。
画像指示のずれ検知を足したら、指示文4枚を書き直すことになった
9月20日、画像指示のずれ検知を足しました。指示文と、実際に生成される画像が食い違っていないかを見る仕組みです。
その結果、「ホームページはAIで自作か依頼か」という記事の指示文4枚を書き直すことになりました。ここが今回いちばん学びがあった逆説です。
自動化を1つ足すと、別の手作業が新しく生まれる。
検知を足したから、直す作業が発生した。検知そのものは必要だったし、入れてよかったと思っています。でも、係が増えるほどこの「発生源」も増えていきます。
うちの場合、この時点でどの係が今どうなっているかを把握する時間が、実際の作業時間より長くなり始めました。管理コストが作業コストを追い越す地点です。
9-21：止まった1本が、note係ごと止めていた
ここがこの記事の核です。
1記事の詰まりが全体の停止になる構造だった
note係の中で、処理が止まった記事が1本あると、その記事だけでなくnote係そのものが止まる作りになっていました。1本の詰まりが、そのまま全体の停止になる。
技術的なミスというより、構造の欠陥です。1件失敗したら、その1件を飛ばして次に進む、という作りになっていなかった。
分けたことが、かえって原因の特定を遅らせた
気づきにくかった理由も書いておきます。係を分けていたので、見た目には「note係だけ止まっている」ように映りました。だから最初はnote係の設定や接続を疑ったんです。原因が特定の1記事にあるとは、すぐには思いませんでした。
分けたことで責任範囲がはっきりするはずが、この場面では分けたことが原因の特定を遅らせました。ここは想定外でした。
生存確認をどこに付けるかを間違えていた
対処としてやったのは3つです。
- 詰まった記事が全体を止めないように修正した
- 生存確認を note係に付け替えた
- 既存の自動投稿設定（
com.note.autopost）は、再登録が不要だと確認した
2つ目が地味に効きました。見張りをどこに置くかで、異常の見え方が変わります。上の管理側だけを見張っていると「管理側は動いています」という報告だけが返ってきて、下の処理が止まっていることに気づけません。実際に記事を処理している係そのものに付け替えました。
3つ目は、逆の判断です。壊れたからといって全部作り直すのではなく、触らなくていい部分を確認して残す。com.note.autopost は再登録が不要だと確認できたので、そのままにしました。直す範囲を広げすぎないのも判断のうちだと思っています。
入口を1つに戻す：司令塔への一本化で実際にやったこと
9月21日にやった一本化を、自分の環境に置き換えられる粒度で書きます。
指示も報告も司令塔を通す形にした
- 指示の入口を司令塔1つにする。どの係への指示も、まず司令塔を通す
- 各係からの報告先も司令塔に統一する。既存のジョブには報告を後から足した（9-18の4ジョブがこれ）
- 合格判定を通ったものだけ書き出す。
Documents/note下書きと iCloud の2か所へ自動で - 生存確認を、実際に動く係に付ける
- 再登録が不要な既存設定は触らない
一本化しても、係はなくしていない
ここは区別を明確にしておきたいところです。係は14個のまま残しています。展開係もX係もnote係も消していません。
変えたのは、指示の入口と報告先だけ。処理は分けたまま、窓口を1つに戻した。「一本化＝まとめて1つの巨大な処理にする」ではありません。
効果として言えるのは、朝に見る場所が1つになったこと。処理が速くなったかどうかは測っていないので書きません。実感としてあるのは、見に行く場所が減ったという1点だけです。
自分の自動化を点検する5つの質問
増やす前、あるいは今詰まっている人に当てはめてもらう形にしました。
- 指示を出す入口はいくつあるか。 2つ以上なら統合を検討する
- 各処理の報告先は同じ場所か。 バラバラなら、見に行く場所がその数だけある
- 1件の失敗が全体を止める作りになっていないか。 1件飛ばして続行できるか
- 生存確認は、実際に動いている処理そのものに付いているか。 管理側だけを見張っていないか
- 自動化を1つ足すとき、それが生む新しい手作業を見積もったか。
5番目は、9-20の画像指示ずれ検知がそのまま実例です。検知を足したら、指示文4枚の書き直しが発生しました。足す価値はありましたが、「足したら手作業がゼロになる」ではなく「足したら別の手作業が生まれる」と見積もっておくべきでした。
うちがこの順で直した理由
優先順位は、連鎖停止の修正 → 入口の統合 → 生存確認の付け替え の順でした。止まるバグが一番損失が大きいと判断したからです。気づかないまま何日も止まるのが一番まずい。
ただし、この順番が誰にでも当てはまるとは思っていません。止まっても影響が小さい処理なら、先に入口を整えたほうが楽なはずです。環境によって変わります。
これから自動化を増やす人へ：うちが今も迷っていること
係を分ける設計が間違いだったとは思っていません。分けたから、note係の中の1記事という単位まで原因を追えました。問題だったのは、入口まで一緒に分けてしまったことです。
まだ答えが出ていない点も正直に書きます。
- どこまでを1つの係にまとめるべきか、線引きがまだ決められていない
- 自動で出すか、手元で確認するかの境目。うちは今のところ、note投稿の最後は手元に残している
- 係を14個まで増やしたのが適正だったのかも、まだ判断がついていない
ETERNALd.c.t（代表・畑 和寿、2025年5月設立）はAI導入支援を事業に持っていますが、社内の自動化も同じように詰まります。うちが大切にしている約束の1つが「丸投げにさせない、置き去りにしない」で、もう1つが「専門用語より、中学生にも伝わる言葉で説明する」。この4日間で、ツールを渡して終わりにはできないと改めて実感しました。組んだ翌日から手直しが始まるからです。
なお、この記録は2026年9月時点のものです。note側の仕様も、うちの運用も変わる可能性があります。
よくある質問
Q1. 係を分けずに、1つにまとめたほうが早いですか？
分けること自体は有効だと思っています。切り分けるのは処理、まとめるのは入口と報告先、という区別で考えるのがうちの結論です。処理まで1つにすると、今度はどこで転んだか分からなくなります。
Q2. note下書きの自動書き出し先はどこがいいですか？
うちの場合は Documents/note下書き と iCloud の両方に書き出して、どの端末からでも開ける状態にしました。端末構成によって最適解は変わるので、ここは一般論として受け取ってください。
Q3. 生存確認はどの処理に付けるべきですか？
うちは、実際に記事を処理している係（note係）に付け替えました。上位の管理側だけに付けると、管理側は動いているという報告だけが返ってきて、下の処理が止まっても気づけない場合があります。
Q4. 既存の自動投稿設定は作り直すべきですか？
うちは com.note.autopost について、再登録は不要だと確認しました。まず再登録が要るかを確かめてから触る。壊れた前提で全部作り直すと、直さなくていいものまで壊すことがあります。
続きの運用記録について
この自動化は今も毎日書き換えていて、詰まった箇所はその日のうちにXに書いています。同じようにひとりで自動化を組んでいる人は、X @kazuto_AI_auto をフォローして続きの記録を見てもらえたら嬉しいです。
うちはAI導入支援も事業にしていますが、この記事のとおり自社の自動化も詰まりながら直している最中です。「自分の環境でどこから手を付けるか分からない」という段階の相談だけでも大丈夫ですし、即決していただく必要もありません。
- 公式LINE ID:
@585fuemj - メール:
info@eternaldct.net
ETERNALd.c.t（代表・畑 和寿）／本記事は2026年9月21日時点の作業記録です。
