🔔 3回失敗で人に頼む、告知投稿の固定を自動化するとき、逃げ道を先に設計した話

レシートが出なかったとき、レジの画面には「エラー」と表示されます。

何も表示されないよりも、エラーと表示される方が、実は安全なんです。

あなたは今、こうなっていませんか？

• 自動化したはずなのに、うまくいったかどうか確認するのを忘れていた • 失敗していても誰も気づかず、そのままになっていたことがある • 全部を自動で終わらせようとして、かえって不安になっている • 「動くはずだから大丈夫」と思いながら、なんとなく怖い

先に結論を言います。自動化の信頼性は、精度ではなく「失敗の見え方」で決まります。

この記事では、立ち上げ告知の固定投稿を自動化したとき、Lilyが「失敗しても投稿本体に響かせない逃げ道」をどう設計したか、そこに気づくまでの話を書きます。

固定投稿を手動でやっていた頃の話

「告知を固定し忘れた」を何度も繰り返した

Xで何かを立ち上げるとき、最初にやることの1つが「告知投稿の固定」です。

プロフィールのトップに、その案件の告知を固定しておく作業のことです。

プロフィールを見に来た人が最初に目にするのが、この固定投稿です。

立ち上げ直後の最初の3日間は注目が集まりやすく、固定できているかどうかで届き方がまったく変わります。

でも、これが意外と抜け漏れやすい作業でした。

立ち上げの日は他にやることが山積みで、「固定しようと思っていたのに、気づいたら2日後だった」という体験を、Lilyは何度も重ねていました。

告知の固定が遅れるということは、いちばん大切なタイミングに整っていない状態で人を迎えてしまうということです。

本来届けたかった人に、届けたいものが届いていない、そういうことです。

その頃、Lilyは複数の案件をほぼ同時に動かしていました。

手元にある作業リストはいつも20件以上あって、どれも「今日やること」になっていました。

そういう状態で「固定を忘れないようにしよう」と思っても、なかなか難しいんです。

記憶力の問題というよりも、「注意を向けるだけの余裕がない」という状態です。

「意識の問題」として解決しようとした

最初は、意識を変えようとしていました。

タスクリストに入れたり、スマホにアラームをセットしたりして、「忘れないようにする」方向で解決しようとしていたんです。

でも、立ち上げ当日というのは本当にバタバタしています。

確認しようと決めていたのに3日連続で忘れたあと、「これ、意識の問題じゃなくて仕組みの問題だ」とはっきり気づきました。

人間が忙しければ忙しいほど、手動管理は機能しなくなります。

「もっとちゃんとしよう」ではなく、「仕組みで解決しよう」という発想への転換が、ここから始まりました。

「自分が変わる」より「仕組みを変える」方が、長続きするし、再現性があります。

これは当たり前のように聞こえますが、実際に実感するのには少し時間がかかりました。

📕 AIエージェントと自動化の全工程をまとめた総集編 手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

「自動化すれば解決する」と思っていた

自動化を試みた背景

Lilyはもともとマーケティングの仕事をしていて、月3,000万円の広告を動かしていた時期があります。

その頃から、「自動化できるものは自動にする」という発想が身についていました。

解雇されてから半年、個人でできることを一から作り直す中で、AIを使った仕組み作りを少しずつ学んでいきました。

コードはほぼ0行のまま、Claude（AI）に指示を出して動かすやり方です。

最初は「AIって何でもできるんじゃないか」と思っていたくらいです。

それは少し大げさでしたが、「専門知識がなくても仕組みが作れる」というのは本当でした。

「告知の固定も、AIに動かしてもらえばいいんじゃないか」、そう思ったのは、自然な流れでした。

AIがあれば、自分が忘れても自動で動いてくれると信じていたんです。

最初の設計は「動けばいい」だった

最初に作った仕組みはシンプルなものでした。

立ち上げのイベントが発生したら、XのAPIを通じて自動で投稿を固定する、それだけです。

APIというのは、外部のサービスと連携するための通信経路のことです。

Xの機能をプログラムから操作するには、この経路を通じて「お願い」を送る必要があります。

テスト環境では問題なく動きました。「これで告知の固定忘れはゼロになる」と思っていました。

でも、ここに大きな見落としがありました。

「動く」と「ちゃんと動き続ける」は、まったく別のことだということを、このあと体感することになりました。

仕組みが動くかどうかと、仕組みが信頼できるかどうかは、別の話です。

テストが通ることと、毎日安定して動くことも、別の話です。

最初の仕組みが、静かに失敗していた

2日間、誰も気づかなかった

仕組みを組んでから最初の1週間は、順調に動いているように見えていました。

でも8日目、プロフィールを確認したとき、固定されているはずの告知が反映されていないことに気づきました。

おかしいと思ってログを確認すると、2日前から自動固定が動いていなかったことがわかりました。

通知は何も届いていません。エラーが画面のどこかに出ているわけでもありません。

ただ静かに、何もなかったように止まっていたんです。

2日間、告知が固定されていない状態が続いていたと知ったとき、かなりしんどかったです、、、

立ち上げ直後のいちばん大切な時期に、整っていない状態が続いていた。

発見したときには、もう回収できない部分がありました。

その2日間に来てくれた人たちは、固定されていない状態のプロフィールを見ていたことになります。

「最初の印象」は、後から取り返せません。

原因は「無音での失敗」だった

あとから調べると、原因はAPIのレート制限でした。

レート制限というのは、「短時間に何度も呼び出すと、一定回数を超えたあとは受け付けない」というルールのことです。

コップの水に例えると、一気に飲みすぎると「もうしばらく待って」と言われる感じです。

仕組みは内部では「失敗した」と認識していました。

でもその失敗をどこにも報告していなかったんです。

自分で気づかない限り、ずっとわからないまま続く、そういう状態でした。これが「無音での失敗」です。

「無音での失敗」は、発見が遅れるほど被害が大きくなります。

気づいたときにはすでに、対応できるタイミングを過ぎていることが多い。

「動いているはず」という思い込みの怖さ

このとき、あることに気づきました。

自動化した仕組みに対して、人は「動いているはず」という前提で動いてしまうんです。

手動でやっているときは「今日やったかな？」

と確認する動機がありますが、自動化すると「任せたから大丈夫」という安心感が確認を妨げます。

これは意識の問題ではなく、自動化の構造が生む落とし穴です。

精度が上がれば上がるほど、失敗したときに気づきにくくなる、その矛盾が、最初の設計に隠れていました。

完璧に動いているときほど、「確認しなくていい」と思います。

でも完璧でなくなったとき、その確認のなさが一番効いてきます。

「信頼しきっているから確認しない」→「失敗しても気づかない」→「被害が広がる」、このループが、無音での失敗の怖さです。

「完璧に動かす」を目標にするのをやめた

完璧な仕組みはない

この失敗のあと、設計の考え方を根本から変えることにしました。

「どうすれば失敗しないか」より先に、「失敗したとき、誰がどうやって気づくか」を決める、そっちを先に設計する方向です。

正直に言うと、完璧に動き続ける仕組みというのは存在しません。

ネットワークの不安定さ、APIの仕様変更、外部サービスのメンテナンス、どれか1つが絡むだけで、動いていたものが突然動かなくなることがあります。

それは精度の問題ではなく、外部環境の変化だから、どれだけ丁寧に作っても完全には防げないんです。

だったら、「失敗しない」を目標にするのではなく、「失敗したとき必ず誰かが知れる」を目標にすべきだと気づきました。

失敗の確率を下げることと、失敗したときの被害を下げることは、別のアプローチです。

両方大切ですが、「どちらを先に考えるか」が設計の方向を決めます。

失敗は「ゼロ」にするのではなく「見える」にする

発想を変えると、参考になる比喩がいくつか浮かびました。

レジのエラー表示が安全なのは、失敗を消しているからではなく、失敗を見えるようにしているからです。

火災報知機が信頼されるのも、火を消すからではなく、火があることを知らせるからです。

告知の固定でも、同じことが言えます。

「固定を失敗させない」ではなく、「失敗したとき必ず誰かが気づける」、この切り替えが、再設計の核心でした。

失敗が見えれば、動けます。動ければ直せます。直せれば、配信の信頼性は保たれます。

「失敗が見えない状態」と「失敗が見える状態」では、同じ失敗回数でも結果がまったく違います。

見えない失敗は積み重なり、見える失敗は一つひとつ解決できます。

リトライ3回・その後チャット通知の設計

新しい仕組みの3つの要点

仕組みを組み直すにあたって、最初に3つを決めました。

1つ目は「失敗したら最大3回まで自動でやり直すこと」です。

一時的な問題（通信の瞬断やサービスの短いメンテナンス）なら、少し時間を置いて3回試せばたいてい解決します。

2つ目は「3回全部失敗したらチャットに通知を送ること」です。「告知の固定ができませんでした。

手動でお願いします」という短い依頼が、Lilyのスマホに直接届く設計にしました。

3つ目は「投稿本体には一切触らないこと」です。

固定できるかどうかの失敗が、投稿の内容や他の動作を壊さないようにする、これが一番重要でした。

この3つを決めてから設計を始めると、作るべきものがかなり明確になりました。

「何を防ぐか」ではなく「何を伝えるか」に集中できるようになったんです。

「3回」という数字はどう決めたか

最初、リトライ回数をいくつにするか迷いました。2回でも5回でも、理屈上はどちらでも成立します。

でも実際に動かしてみると、1回目が失敗するケースの9割以上が、3回以内に解決していたんです。

これは最初の4週間を計測して確かめた数字です。

逆に3回全部ダメだったケースを調べると、APIの仕様が変わっていたり、アカウントの権限設定が変わっていたりしていました。

一時的な問題ではなく、構造的に何かが変わっているサインでした。

「3回」は「自動で粘ってよい限界」として、ちょうどよかったんです。

この数字に納得するまでに、地味に2週間かかりました（笑）

4回以上リトライさせると、今度は「何度も同じことを試みて、それでも来ない」という状況になります。

自動化が粘りすぎると、通知が届いたときにはすでに手遅れになることがあります。

「3回やってダメなら人に伝える」、この設計は、自動化と人間の役割をちょうどよく分けてくれます。

「投稿本体に触らない」という原則

もう1つ大切にしたのは、固定の失敗が投稿本体を壊さないことです。

自動化の仕組みの中で、「固定する」操作と「投稿を編集する」操作が混在していると、失敗したときに予期しない副作用が起きることがあります。

それを防ぐために、固定に関わる処理だけを完全に独立させました。

失敗しても、投稿の内容や他の自動化の動作には何も影響が出ない、そこだけは絶対に守る設計です。

これは「投稿本体を守る」というより、「失敗の被害を最小限に閉じ込める」という考え方です。

失敗は起きます。でも、その失敗がどこまで広がるかは設計で決まります。

「ここから先には広がらない」という境界線を先に引いておくことが、安全な自動化の基本だと思っています。

実際に動かして気づいたこと

最初の通知が届いたとき

仕組みを組み直してから2週間後、最初の「失敗通知」が届きました。

「告知の固定ができませんでした。手動でお願いします」というメッセージです。

そのとき、正直「しまった」よりも「よかった！」という気持ちが先に来ました。

失敗したことへの焦りより、ちゃんと気づけたという安心感の方が上回ったんです。

すぐにスマホから手動で固定して、5分以内に対応完了しました。

もし通知がなければ、また数日気づかなかったかもしれない、そう思うと、通知の価値を改めて感じました。

この「5分の手作業」が怖いかどうか、というのは、設計の前と後でまったく違って見えます。

設計前は「手作業があるなら自動化の意味がない」と感じていました。

でも設計後は「手作業が必要なときだけ連絡が来る」に変わります。

ほとんどの場合は自動で完結して、本当に手作業が必要なときだけ、確実に知らせてくれる。

失敗通知は「仕組みが動いている証拠」でもある

この体験で、もう1つ気づいたことがあります。

失敗通知が届くということは、「仕組みが失敗を検知して、ちゃんと報告している」ということです。

つまり、通知が来ること自体が「正しく動いている証拠」でもあるんです。

静かなまま何も来ない状態より、「失敗しました、手動でお願いします」と来る状態の方が、実は安全で信頼できます。

この感覚を体験したのは、最初の通知が届いたときが初めてでした。

以来、Lilyにとって失敗通知は「悪い知らせ」ではなく、「仕組みが生きているサイン」になっています。

この感覚の変化が、一番大きかったかもしれません。

通知が来る仕組みは、失敗したときに「安心」を届けてくれます。

これは、通知がない仕組みには絶対にできないことです。

「逃げ道を先に作る」という発想の転換

逃げ道は「諦め」ではなく「設計」

「リトライ3回でダメなら人に頼む」という設計を話したとき、「それって完全自動じゃないですよね」と言われたことがあります。

その通りです。3回失敗したあとは、手動になります。

でもLilyにとって、これは「自動化に失敗した」ではなく、「設計として正しい」んです。

目標は「全部を自動で終わらせること」ではなく、「投稿本体に影響を出さずに、失敗を必ず誰かに知らせること」だったから。

逃げ道を作ることは、完璧主義を諦めることではありません。失敗に備えることそのものが設計です。

「逃げ道」という言葉はネガティブに聞こえるかもしれませんが、Lilyの中では違います。

「失敗したときに、次の人が動ける経路」というイメージです。

自動化の「信頼性」とは何か

ずっと自動化を使ってきて、「信頼できる仕組み」には共通点があると感じています。

それは、失敗したとき次に動ける人に確実にバトンが渡ることです。

それが次の処理へ自動で進めるなら最高ですが、そうでなければ人に渡せばいい。

大切なのはバトンが渡ることであって、バトンを人間が持つかどうかではないんです。

「無音での失敗がゼロ」——これが、Lilyが考える自動化の信頼性の定義です。

月商160万の仕組みを広告費0円で回すようになった今も、この考え方はすべての自動化の土台になっています。

告知の固定だけでなく、投稿の配信、コンテンツの更新、通知の送信——どれも「失敗したとき、誰が気づくか」を先に設計しています。

自動化の精度を上げることに時間をかけるより、「失敗通知の経路を作る」ことに時間をかける方が、早く信頼できる仕組みになります。

これは、何度か失敗して気づいたことです。

今日からできる1つのこと

難しいことは何もありません。

今使っている自動化の仕組みを1つ思い浮かべて、こう問いかけてみてください。

「これが失敗したとき、わたしはいつ気づけますか？」

答えが「わからない」か「通知が来ない」なら、まず通知の経路を1本作ることから始められます。

通知先はメール1通でも、チャットのメッセージ1件でも構いません。

「失敗しても気づける仕組みがある」というだけで、精神的な安心感がまったく変わります。

これは体験してみないとわからない感覚なんですが、本当に変わります。

自律環境の全体的な設計については、別の有料記事にまとめています。

仕組みの全体像が気になる方は、そちらも読んでみてください。

まとめ——失敗は隠さない方が強い

自動化の相談を受けるとき、「どうすれば失敗しなくなりますか」とよく聞かれます。

Lilyの答えはいつも同じです。

「失敗しないようにするより、失敗を見えるようにする方が先です」

静かな失敗が一番怖い——これが今回の話の核心でした。失敗が見えれば動けます。動ければ直せます。

直せれば、仕組みは信頼に変わります。

リトライ3回、チャット通知、投稿本体を守る設計——この3つを決めただけで、告知の固定に関するストレスがほぼゼロになりました。

完璧な自動化を目指すと、どこかで行き詰まります。

でも「失敗したとき必ず気づける仕組み」は、完璧でなくても機能します。

配信の信頼性は、自動化の精度ではなく、失敗の見え方で決まる——Lilyが確信していることです。

仕様チェック

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順