レシピのメモが5枚になったとき、料理の腕が上がったとは言えません。
最初の1枚は「塩は最後に入れる」でした。次が「中火より少し弱め」でした。
3枚目が「焦げやすいから目を離さない」。4枚目が「小麦粉は最初に全量入れない」。
そして5枚目——「冷蔵庫から出してから20分待つ」。
料理は毎回できあがります。でも毎回、5枚のメモをめくりながら作っています。
メモは増えていく一方で、レシピが簡単になったわけではありません。
作るたびに注意する場所が増えて、気がつくと「料理の腕を磨く」よりも「メモを管理する仕事」になっていました。
あなたは今、こうなっていませんか。
• 自動化したはずの作業に「このときだけは手動で確認する」というステップが積み重なっている • 不具合のたびに回避策を追加してきたが、今いくつあるか数えたことがない • 「止めればいいかも」と思いながら、もったいない気がしてそのまま続けている • そのツールや仕組みに、週どのくらいの時間がかかっているか正直に把握していない
先に結論を言います。詰まる工程は、直すよりも外す方が速くて安全です。
この記事では、Reel の自動投稿レーンを廃止するまでの経緯と、「直す」か「外す」かを判断するときに使った基準を書きます。
最初の不具合——Escape キーひとつで投稿が消えた
何が起きたのか
私は o81 というアカウントで、複数のブランドを並走させています。
それぞれのブランドが Instagram に自動で投稿する仕組みを作っていました。
自動投稿というのは、画面を操作する作業をスクリプト（プログラムのようなもの）に任せる仕組みのことです。
人間が毎回手を動かさなくても、決まった手順通りに投稿が完了するようにしています。
もう少し具体的に説明します。
ブラウザを自動で操作するライブラリを使って、「投稿ボタンを押す」「テキストを入力する」「次の画面に進む」という一連の操作を、プログラムが代わりにやってくれる仕組みです。
人が手で操作するのと同じ画面を、プログラムが順番に操作していく——それだけです。
だから、人間が操作するときに起きるエラーは、自動操作でも同じように起きます。
ある日、Reel（短い動画形式の投稿）の作業途中で、誤って Escape キーが押されました。
入力していたテキストが全部消えて、投稿ウィンドウが閉じました。
人が手で操作しているなら「もう一度やり直せばいい」で済みます。
でも自動投稿の途中で起きると、そうはいきませんでした。
スクリプトは「ウィンドウが閉じた状態」を想定していなかったため、次の操作ができずに止まります。
そして、この仕組みは1つのブランドの処理が終わってから次へ進む構造になっています。
1件が止まると、後続のすべてのブランドが待機状態のままになります。
その日の投稿が全件失敗しました。
対処のために、その夜だけで1時間以上を使いました。
ログを確認して、どこで止まったかを特定して、再現テストをして——その繰り返しでした。
最初の対処と「これで解決」という感覚
最初の対処はシンプルでした。
「Escape キーが押されても投稿が壊れないようにする処理を入れる」——それだけです。
具体的には、投稿ウィンドウが開いているかどうかを定期的に確認して、もし閉じていたら自動で再度開き直す処理を追加しました。
回避策を1つ書き足して、翌日テストして、問題なく動きました。「解決した」と思いました。
このとき私は、これが積み重なっていく問題の「1枚目のメモ」だとは思っていませんでした。
小さなバグが出て、直せた——その程度の感覚でした。
「こういう問題はたまにあるもの」と思っていたのが、正直なところです。
でも実際には、これがずっと続いていく問題の始まりでした。
📕 AIエージェントと自動化の全工程をまとめた総集編 手順・コード・テンプレをそのまま渡しています
🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新
回避策が積み上がっていくとき
4種類の不具合が揃うまで
Escape キーの問題が落ち着いてから2週間もしないうちに、別の不具合が出ました。
投稿直前の確認画面で、ボタンの位置がウィンドウサイズによってズレる問題です。
自動操作は「このボタンを押す」という指示を、画面上の座標や要素の位置で指定します。
画面のサイズが変わると、ボタンの位置もずれます。ずれると押せません。
「ウィンドウサイズを固定する処理を入れる」——また回避策を1つ書き足しました。
その後も続きました。
特定の絵文字や記号を含む文章を入力フォームに入れると、文字が正しく表示されない問題がありました。
想定していない文字コードが混入したとき、入力が途中で止まることがあります。
「入力前に文字列を変換する処理を入れる」——3枚目のメモです。
ブランドによっては投稿ボタンを押しても反応しない問題も出ました。
ページの読み込みが完了しているように見えても、ボタンが操作できる状態になっていないことがある——。
「ボタンが押せる状態かどうかを確認してから押す処理を入れる」——4枚目です。
1か月の間に、不具合の種類は4種類になっていました。
メモが1枚増えるたびに「これで安心」と思いました。
でも実際には、毎回そのメモの分だけ次のリスクが増えていました。
回避策が回避策を壊す構造
4種類の回避策が全部組み込まれると、一見「万全」に見えます。
でも実際には、それぞれの回避策が互いに干渉し合っていました。
ウィンドウサイズを固定する処理が、文字を入力するタイミングと衝突することがあります。
サイズを固定しようとする処理と文字入力の処理が同時に走ると、どちらかが中断されます。
入力が遅くなって、今度は「時間がかかりすぎた」という判定で処理が止まる——新しい問題の誕生です。
文字化け対策で特殊文字を変換する処理を入れると、今度は通常の文章の一部が予期せず変換されることがありました。
「直した」つもりの回避策が、既存の回避策と組み合わさって、別の不具合を生む構造になっていたわけです。
回避策を増やすほど、壊れる場所が増えていきました。
何かを直すたびにどこかが壊れる——そのたびに「今度こそ直った」と思って、また壊れる。
「直していない」のではなく、「直すたびに別の何かが壊れている」状態でした。
この状態は奇妙な感覚をともないます。
スクリプトの行数は増えているのに、動くかどうかの信頼性が下がっていく——。
コードが育っているのに、安心感が減っていく——これに気づいたとき、何かが根本的に違うという感覚がありました。
会社にいたころの「直す」は、今の私には使えない
組織の中にいたころの感覚
会社員として働いていたころ、私はマーケティングの仕事をしていました。
部門全体の施策を束ねる立場にいた時期も、特定のチャンネルの担当として深く入る時期もありました。
詰まったチャンネルや施策があれば、担当者を増やして対処しました。
ツールに問題があれば、予算をつけて開発チームに依頼しました。
月3,000万円以上の広告費を動かすプロジェクトにいた時期には、1本の施策が止まるだけで翌月の数字が大きく変わる緊張感がありました。
だからこそ、「止める」という判断はできるだけ後回しにして、「直す」「体制を整える」「代替施策を入れる」を先に検討するのが当たり前でした。
人手があれば直せる。予算があれば専門家に頼める。
その前提があったから、「直す」は常に有効な選択肢でした。
問題が出るたびに「どうすれば直せるか」から考えていたのは、その環境が作った習慣でした。
「外す」という発想は、どうしても最終手段の位置にありました。
今は時間が唯一のリソース
でも今の私は、基本的に1人で動いています。
不具合を直すのも、回避策を書くのも、テストするのも、全部1人です。
エンジニアに依頼するという選択肢は、この作業のためには使っていません。
1時間は1時間でしかありません。
Reel の不具合対処に使った1時間は、記事を書く時間でも、別の仕組みを作る時間でもなく、消えます。
頭では分かっていました。でも実際に行動が変わるまでに、かなり時間がかかりました。
「もう少し直せばうまくいくかも」という感覚は、なかなか手放せないものです。
組織にいたころに染みついた「詰まったら直す」という発想が、判断を遅らせていたと思います。
資源の種類が変わっているのに、使い方の発想が変わっていない——それが何か月も続いていました。
いつか安定するはず——そう思い続けた期間が、何か月もありました。
その間も、不具合は静かに積み重なっていました。
「連続保留」ルールを設計したとき
ブランドが止まり続ける問題
Reel レーンの問題が続く中で、もう少し前の段階——ブランドの運用レベル——でも同じ構造の問題が起きていました。
複数のブランドを並走させているとき、特定のブランドの投稿準備が毎回うまくいかないことがあります。
素材が揃わない、テーマが決まらない、前回の投稿と内容が被る——そういった理由で、保留になります。
あるブランドが3回連続で同じ理由で保留になりました。
毎回「もう少しで動けるかも」と思って、その場しのぎの対処をしていました。
「今週は素材が揃わなかっただけ。来週は大丈夫」という言い訳を、自分に対してしていました（笑）。
4回目も5回目も同じ状態が続きました。
「いつか直るかも」が、「ただの先延ばし」になっていました。
これは、Reel レーンで起きていたこととまったく同じ構造でした。
「何かが詰まっている」のに「少し待てば動き出すはず」と思い続けて、結果として問題の発見と解決が両方遅れる——。
その構造が、複数の場所で同時に起きていました。
感情ではなく数字で動くルールにした
「次こそは動けるかも」という期待は、なかなか切れません。
そこで、感情で判断するのをやめることにしました。
同じブランドが3回連続で保留になったら、次のサイクルからはローテーションから外す——このルールを作りました。
理由は問いません。状況がよくなる見込みも考えません。
ただ「3回連続保留になったら外す」だけです。
「3回」という数字に特別な根拠があるわけではありません。
「1回で外す」は厳しすぎて、偶発的な問題で外れてしまいます。
「5回まで様子を見る」は緩すぎて、先延ばしが続きます。
「2回様子を見て3回目に決断する」という感覚で、3回にしました。
このルールを作るときに意識したのは、「例外を作らない」ことでした。
「今回は事情があって」「来月には動き出すはず」という理由で例外を認めると、ルールの意味がなくなります。
明確な基準があると、迷わずに済みます。
「今回は事情があって……」という言い訳を、自分に対してしなくてよくなります。
ルールを入れてから気づいたことがありました。
外してみたブランドの半数以上は、なくても特に困りませんでした。
「いつか動き出すかも」という期待が、判断を遅らせていただけでした。
この体験が、Reel レーン全体を止める判断に直接つながりました。
Reel レーンを廃止した日
5日間連続の不具合
ある週、Reel レーンが5日間連続で何らかの問題を出しました。
月曜日に Escape キーの問題が再発して、回避策を組み直しました。
火曜日も何かが壊れていて、水曜日にまたデバッグしました。
木曜日に「今度こそ直った」と思って、金曜日にまた別の問題が出ました。
5日間で、私はデバッグに合計3時間以上を使っていました。
投稿できた本数は、その週の目標を大きく下回りました。
手間に対して、成果がまったく釣り合っていませんでした。
金曜日の夜に、スクリプトのログを見ながら、少し気持ちが重くなりました。
エラーの内容を確認して、原因を特定して、修正案を考えて——それをまた繰り返す。
「来週も同じことをするかもしれない」と思ったとき、この週が5日間連続の不具合で終わったことが、ただの偶然ではなく、構造の問題だと感じました。
「外す」を選んだ瞬間
ここで初めて、「このレーン自体を外す」という選択肢を本気で考えました。
自分に3つ問いました。
「直すために次に何時間かかるか」——見当がつきませんでした。
「このレーンがなくなっても、目的は他の方法で達成できるか」——できそうでした。
「今の状態をあと3か月続けると、どうなっているか」——同じデバッグをしている自分が浮かびました。
3つ目の問いで、決めました。
Reel の自動投稿スクリプトをオフにしました。
代わりに「既存の Reel 投稿を削除するスクリプト」を追加しました。
投稿するレーンをなくして、整理するレーンに変えた、ということです。
「出す」をやめて「片づける」に切り替えた、と言った方が分かりやすいかもしれません。
作ることをやめて、残っているものを整理することに切り替えた——そういう判断でした。
廃止してから変わったこと
廃止した翌週、Reel レーン関連のデバッグはゼロになりました。
当然です——動かしていないので、壊れません。
最初はこれを「失敗」のように感じていました。
「うまく動かせなかった」「諦めた」——そう見える気がしていました。
実際、廃止してからしばらく、どこかすっきりしない感覚が続きました。
「本当はもう少し粘れば直せたかもしれない」という気持ちは、すぐには消えませんでした。
でも2週間ほど経って、はっきり分かったことがあります。
詰まったレーンを止めたことで、他のレーンの安定度が上がりました。
1か所の問題に引っ張られなくなったぶん、別の自動化に使える時間が増えました。
廃止は諦めではなく、リソースの再配置でした。
Reel レーンに割いていた時間と注意が、別の仕組みに移って、全体のアウトプット量が以前より増えました。
「外す」ことで全体が改善する——これは実際に体験するまで、なかなか信じられないことでした。
「直す」か「外す」かを判断する3つの問い
問いの立て方が変わった
Reel レーンの廃止を通じて、問いの立て方が変わりました。
以前は「どうすれば直せるか」から始めていました。今は「本当に直す必要があるか」から始めています。
この順番の違いは、結果に大きく影響します。
「どうすれば直せるか」から始めると、「直す方法があるかどうか」を探すことになります。
たいていの場合、直す方法は見つかります。でも「直す価値があるかどうか」は、別の問いです。
2つの問いは似ているようで、まったく違う答えを出します。
自分が使うようになった3つの問いを書きます。
1つ目——「この問題を直すために、次に何時間かかるか」
見当がつかないなら、それ自体がひとつのサインです。
繰り返し壊れている問題は、直した先にまた次の問題が待っている可能性が高いです。
1時間で直せる問題と、何時間かかるか分からない問題では、判断が変わります。
見当がつかないということは、問題の根がどこにあるか分かっていない、ということでもあります。
根が分からない問題を「直す」ことは、なかなか難しいです。
判断に使う残り2つの問い
2つ目——「このレーンがなくなっても、目的は達成できるか」
「Reel で投稿すること」が目的ではなく「アカウントを運用すること」が目的なら、Reel でなくてもよいかもしれません。
手段と目的が混ざると、この問いに答えにくくなります。
問いに答えるとき、「この仕組みがなくなって困るのは、何のためか」を具体的に言えるかどうかを確かめます。
言えないなら、その仕組みへの執着は目的からではなく「作ってしまったから」という惰性から来ているかもしれません。
「作ったから続ける」と「必要だから続ける」は、見た目が似ていて中身が違います。
3つ目——「今の状態をあと3か月続けると、どうなっているか」
私がいちばん効いた問いです。
3か月後も同じデバッグをしている自分を想像したとき、「外す」が答えになりました。
「今の状態」を時間軸に乗せると、続けることのコストが見えやすくなります。
1回の対処時間が1時間なら、週1回のペースで3か月続くと12時間以上になります。
その12時間で何ができるかを具体的に考えると、判断が変わります。
この問いは「少し粘れば直るかもしれない」という気持ちを、数字と時間で確かめる作業でもあります。
「外す」という判断には、どこか失敗のイメージがつくかもしれません。
でも1人で動かす自動化では、「何を外すか」の判断がそのまま全体の品質に直結します。
回避策の上に回避策を積み重ねた構造は、どこかで一気に壊れます。
壊れる前に外す方が、ずっと健全です。
複雑さと向き合うひとりの自動化
複雑さは静かに積み重なる
自動化を組んでいると、複雑さが静かに増えていきます。
最初はシンプルだったスクリプトに、条件が一つ追加されます。次に例外処理が入ります。
次に回避策が入ります。
ある日、以前書いたスクリプトを読み返したとき、何をしているか分からない——そういうことが起きます。
コメントを見ても、「なぜこの処理が入っているのか」が分からない。削除していいのかも判断できない。
こうなると、スクリプトは「触れないもの」になります。
壊れたら直さなければならないのに、何かを変えることが怖くなる——という状態です。
これは、自動化が「複雑さを管理する仕事」に変わっている状態です。
本来の目的——時間を作ること——が逆転しています。
時間を作るために組んだ仕組みが、時間を食うようになる。私がいちばん避けたい状態です。
その状態に気づくのが難しいのは、「1つ追加するたびに問題が解決している」という感覚があるからです。
1つのバグを直すたびに前進している気がします。でも全体の複雑さが増していることには気づきにくい。
そのギャップが、じわじわと時間を侵食していきます。
今の判断基準と「削る勇気」
今の私は「詰まったら外す」を基本ルールにしています。
1つのレーンで不具合が3回連続で出たら、一時停止を検討します。
回避策が3つ以上積み重なったら、そのレーンの必要性を見直します。
スクリプト内に「なぜこの処理があるか分からない」箇所が出てきたら、思い切って削除してテストします。
動かなくなれば原因が分かり、動いたままなら不要な処理だったと分かります。
「壊してみる」ことで、どの処理が本当に必要かを確かめる——テスト環境と本番環境を分けておけば、本番への影響が出る前に確認できます。
複雑さに気づいた時点で削減を始める——これが今の基準です。
「もう少し直せばうまくいくかも」という感覚は、まだ完全には消えていません。
でもそのたびに、レシピのメモが何枚あるかを数えるようにしています。
仕組みの全体の構造については、Claude Code の自律環境についてまとめた有料記事があります。
興味があれば、フッターのリンクからどうぞ。
この記事で伝えたかったのは、技術の話ではありません。
「直せないなら外す」という選択肢を、最初から持っておいてほしい、ということです。
詰まったレーンを何か月も抱えてから廃止した私が言えることは、1つだけです。
もっと早く外してよかった。
レシピのメモが5枚になる前に——あなたが判断するとしたら、何枚目で決めますか。
📕 この記事の内容を、実装まで全部まとめた有料記事があります
手順・コード・テンプレをそのまま渡しています
AIで「寝てても回る仕組み」を30日で組む全手順｜コード不要・特典40ファイル・毎月更新
この記事の販売者
