🎯 10日間、スキ自動化が全件止まっていた——CMO時代に『エンゲージメント』と呼んでいたものを問い直した話

万歩計が、ある朝から記録をアプリに転送しなくなっていたとします。

腕のデバイスには、ちゃんと数字が出ています。

でもスマホのアプリには、10日分、何も届いていない。そんな状態を、あなたは気づけますか？

「あれ、おかしいな」と思う日が来るとすれば、それはいつでしょうか。

1週間後に「最近歩数が記録されていないな」と気づく人もいれば、1ヶ月後に「そういえば」となる人もいる。

数字が出なくなっていることに気づくより先に、確認する習慣がなくなっている方が、実は多いと思います。

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

• 自動化を「設定した」だけで、ちゃんと動いていると思い込んでいる • ツールがエラーを出さないと、正常だと判断してしまっている • 数字が増えていないのに、仕組みの見直しをしていない • 「確認するのが面倒」と感じて、ログをほとんど見ていない

先に結論を言います。

自動化は、「動き続けていることを確かめる仕組み」とセットで初めて完成します。

この記事では、noteのスキ自動化が10日間全件止まり続けた話と、それを機にLilyが「エンゲージメント」という言葉を問い直した経緯を書きます。

技術的な話ではなく、「何のための数字か」という問いを一緒に考える記事です。

スキ自動化が、静かに止まった

10/05から、何が起きていたのか

10月5日、noteのスキボタンの見た目が少し変わりました。表向きは、ほんの小さな変更です。

でも自動化ツールにとっては、まったく別の問題でした。

「ボタンがどこにあるか」を探す手順が通用しなくなり、全件「ボタンが見つからない」で失敗し続けていたんです。

ツールはエラーをログに書き続けていました。

ただし、Lilyが日常的に確認していた画面には、何も表示されていなかった。

1日目も、2日目も、3日目も、失敗。でもLilyは何も知らず、普通の毎日を過ごしていました。

ツールが自動で動いていると思っていたから、あえて確認する理由がなかったんです。

「設定済み＝動いている」という前提が、気づくチャンスを消していました。

こういう「静かな失敗」が、いちばん怖いと思っています。

派手なエラーで全部止まるより、気づかないまま続く方がずっとダメージが大きい。

エラーは出ていました。記録もされていました。

でもそれを見る人がいなかった。ツールの外にある問題でした。

「壊れた」のではなく「壊れたと知れない状態」になっていた。

これが今回の、もっとも大きな問題の本質です。

仕組みのどこかが完全に止まるわけではありません。

ただ、意図した結果だけが静かに出なくなっている。

それが一番気づきにくく、一番長く続いてしまう失敗の形です。

壊れていないから警告も来ない。でも意図した動きもしていない。

この「中途半端な停止」に、Lilyはずっと気づけなかったわけです。

気づいたのは、10日後の朝だった

10月15日の朝、ふとログを開いてみると「0件成功」が10日分並んでいました。

最初は「あ、そうか」という軽い感想でした（笑）。

でもすぐに「なぜ気づかなかったんだろう」という気持ちに変わりました。

1件も動いていない日が、10日も続いていたわけです。

「動いているはず」という前提が、確認する習慣を止めていました。

エラーは出ていたのに、それを見る仕組みが側になかった。

道具が壊れているのではなく、「壊れたことを知れない状態」になっていた。

これが今回の失敗の本質だと、Lilyは思っています。

ログを毎朝確認する習慣さえあれば、1日で気づけた話でした。

仕組みの問題ではなく、自分の運用の問題でもありました。

10日を「たった10日」と受け取るか、「10日も気づかなかった」と感じるかは人による。

Lilyは後者でした。毎朝の確認を後回しにしてきた積み重ねが、10日分の沈黙になっていました。

自動化したとき、「動いているから見なくていい」と思い始めた瞬間から、このリスクが育ち始めます。

「自動化＝考えなくていい」ではなく「自動化＝確認の仕方を変えるべき」です。

この認識の差が、長く安定して使い続けられるかどうかを決めます。

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

スキボタンの「中身」を、初めて真剣に考えた

画面の見た目が変わる、ということ

Webのサービスや画面は、予告なく変わります。

使っているサービスが内部の構造を変えれば、昨日まで動いていた自動化が翌日には止まることがある。

これはnoteに限った話ではありません。自動化を使っている人なら、いつか必ず出会う問題です。

そしてほとんどの場合、変更のお知らせは来ません。気づくのは、いつも「動かなくなってから」です。

Webサービスのボタンは、外から見えるのはデザインだけです。

その裏にある「構造」は、常に変わり得ます。

見た目が変わっただけでも、自動化ツールは敏感に反応します。

ツールは見た目ではなく、構造を頼りに動いているからです。

今回の変化は、ボタンを識別するための情報が変わったことでした。

探し方が変わると、ツールは「見つからない」と判断します。

エラーは出ます。でもそのエラーを誰も見ていなかった。

今回の失敗で、Lilyが「直す前に考えたこと」があります。

「押した後の状態を確認する形に変える」という発想への切り替えでした。

これは「ツールの動かし方」の話ではなく、「どこで正しさを確かめるか」の話です。

「ボタンを押せたか」ではなく「状態が変わったか」で確かめる

これまでの仕組みは、「ボタンを押す操作ができたか」を判定していました。

でも画面の作りが変わると、ボタンを探す方法自体が通じなくなる。

新しい判定の考え方は、「操作の後に結果がどうなったか」を確認することです。

スキが押せたかどうかを、スキの状態の変化で確認する。

一見、小さな発想の転換に思えます。でも実は大事な違いがあります。

「手順通りに動いたか」より「意図した結果になったか」の方が、本当に確かめたいことに近い。

「やった」ではなく「変わった」を確認する、という習慣の話です。

この考え方は、スキ自動化に限らず、あらゆる仕組みに応用できます。

「実行した」という記録より「変化した」という結果を確認する。

それだけで検知の精度が全然違います。

たとえば、メールを自動送信している場合もそうです。

「送信コマンドが実行された」を記録するより、「届いたかどうかの状態」を確認する方が、本当に知りたいことに近い。

前者は手段の確認で、後者は目的の確認です。

仕組みを設計するとき、「手順」より「状態」を確認する視点を持っておくと、画面が変わっても壊れにくくなります。

CMO時代に「エンゲージメント」と呼んでいたもの

週次レポートの中心にあった数字

今から数年前、Lilyはマーケティング組織を率いていました。

50人ほどのチームを統括していた頃の話です。

毎週月曜日の午前中、定例の会議がありました。

その場の中心に置かれていたのが「エンゲージメント」という言葉でした。

クリック率、開封率、いいね数、コメント数。

それらを一覧にしたレポートを前に、施策の成否を話し合います。

数字が先週より上がっていると、会議室の空気が少し明るくなる。

下がっていると、誰かが「原因は何か」を話し始める。

あの頃のLilyにとって、エンゲージメントは「次の施策を決めるための材料」でした。

数字が上がれば施策が正しく、下がれば何かを変えるサインでした。

それは毎週繰り返す、一種のルーティンでした。

疑う余地もなく、その数字が仕事の中心にありました。

週次レポートとは、参加者全員が同じ画面を見るための場でもありました。

「全員が同じ数字を共有した」という事実が、次の議論を前に進める燃料でした。

数字の意味より「共有すること」自体に価値が置かれていた部分が、今振り返るとあったと思います。

特に気になるようになったのは、「数字が下がった理由」を探す会議でした。

先週より下がった。だから何かを変えなければならない。

この結論が先に来てから、原因を探していたんです。

「数字が下がったこと」と「何かを変えるべきこと」が、同義になっていた。

今思うと、それはかなり乱暴な前提でした。

数字が「指標」になるとき、何かがずれていた

でも今、振り返ると気づくことがあります。

あの頃追いかけていた数字は、「誰かに届いたかどうか」を直接測っていなかった。

クリックされた。開封された。いいねが押された。

これらはすべて、行動の記録です。「誰かの何かが変わったか」とは、必ずしも一致しない。

大きな組織の中では、エンゲージメントを高めること自体が目的化していくことがあります。

数字を上げるための数字を追いかける、という状態です。

Lilyも、あの頃そういう状態に近かったかもしれない。これは正直、しんどい気づき方でした。

本当の問いは「誰かに届いたか」であるはずなのに、「数字が上がったか」だけを見ていた。

その差を、今のLilyはnoteで毎日実感しています。

スキ自動化が止まった10日間は、思わずこの問いに引き戻された時間でした。

「エンゲージメントとは何か」を、組織から離れて初めて自分の言葉で考えました。

組織の中にいると、数字は「議論を動かすための燃料」になりやすいです。

でもひとりでは、数字は「自分の判断を決める材料」になります。

同じ「クリック率」という言葉でも、用途がまったく変わります。

組織を出てから、この違いをやっと実感できました。

ひとりで動かすと、同じ数字がまったく別の問いになる

50人のチームと、ひとりの机の違い

CMO時代の話を書いたのは、過去を懐かしむためではありません。

「エンゲージメント」という言葉が、今のLilyには全然違う意味を持つからです。

今Lilyは、チームではなくひとりで動いています。

noteを書き、仕組みを作り、売上に直接つなげる必要がある。

組織では「エンゲージメントが高い」と次の予算が通りやすくなります。

でもひとりでは、エンゲージメントが高くても、収入に変わらなければ意味がない。

同じ「いいね」という数字が、まったく別の問いを迫ってきます。

「これは誰に届いているのか」「届いた先に、続きがあるか」という問いです。

そしてそれは、数字だけでは答えが出ない問いです。

記事を読んだ人が、次に何をしたかを直接確認する方法はありません。

「スキが増えた」という事実と「誰かの行動が変わった」という事実は、別の話だということです。

大きな組織の中にいた頃は、その区別をあまり考えていなかった気がします。

チームで動いていると、ひとつの数字に複数人の目が当たります。

「なぜ上がったか」「なぜ下がったか」を、複数人で解釈する。

間違った解釈をしても、誰かが別の見方を出してくれることがあります。

でもひとりでは、その目が自分だけです。

解釈が偏っても、誰も指摘してくれない。

だからこそ「確認する仕組み」が余計に必要になります。

「自分の解釈が正しいかどうか」を問い直す仕組みも、合わせて持つ必要があります。

「届いた」の定義が、文脈によって全然違う

正直に書かせてください。スキ自動化を直す前に、Lilyは少し立ち止まって考えました。

「スキを自動で押すのは、誰かに届けることと同じか？」という問いです。

答えは簡単ではありません。相互に気づくきっかけにはなる。でも「内容が届いた」とは別の話です。

CMO時代は「タッチポイントを増やす」という言葉をよく使っていました。

今のLilyには、タッチポイントより「意味のある接点」の方が大切に思えます。

タッチポイントとは「触れた回数」のことです。

意味のある接点とは「何かが変わった回数」のことです。

この違いを、組織の中にいる間はあまり意識していませんでした。

これは答えではなく、今も持ち続けている問いです。

「自動化された接触」には、量を増やす力があります。

でも量と深さは別のものです。

1回の深い接触が、100回の浅い接触より大きく人を動かすこともあります。

この感覚を持ちながら、どう自動化を使うかを考えること。

それが今のLilyにとっての、エンゲージメントへの問い直しです。

止まっていた10日間、記事は読まれていたか

10日間の、実際のデータについて

正直に言うと、スキ自動化が止まっていた10日間も、記事のPVはほとんど変わりませんでした。

これはLilyにとって、少し予想外でした。

スキが減れば露出が下がり、読まれなくなる——そう思い込んでいたんです。

でも数字の変化は、あまり大きくなかった。

もちろん、10日という短い期間での判断なので断言はできません。

ただ「スキの数が直接PVを決めるわけではない」という感覚を持つようになりました。

この感覚は、今後の判断に使えると思っています。

「スキを増やすこと」と「読まれること」は、直結していないかもしれない。

「接点を増やす仕組み」と「内容で引きつける力」は別のものです。

自動化は前者を助けることはできます。

でも後者は、書く人間にしかできない部分です。

スキという行動は、誰かが記事に気づくきっかけになり得る。

でも気づいた先に「読みたい」と思ってもらえるかは、また別の話です。

今回の10日間は、その区別をもう一度考える機会になりました。

スキの「量」より「タイミング」が大切かもしれない

ここからは仮説の話です。スキの数より、「いつ押されるか」の方が重要な可能性があります。

新着のうちに多くのスキが集まると、noteの仕組みの中で推薦されやすくなる——という話は以前から聞いていました。

でも「古い記事に毎日スキが押され続けることの効果」は、実はLilyにはまだよくわかっていません。

これは引き続き確かめていくつもりです。

止まった10日間が、改めて「何を確かめていなかったか」を教えてくれました。

「動いているから大丈夫」ではなく「何のために動かしているか」を問い直す機会でもありました。

自動化は道具。道具の目的を見失わないようにする、という話です。

ひとつ確信を持って言えることがあります。

「動いていない10日間よりも、動いている1日の方が、仕組みの目的に近い」ということです。

だからこそ、止まっていることに気づける仕組みが必要になります。

「動いているかどうか」を毎日確認できる状態が、自動化を長く使う上での基本です。

直し方よりも先に考えたこと

判定の方向を逆にする、という発想

今回の自動化失敗を直す時、Lilyがこだわったのは「判定方法を変える」ことでした。

「ボタンを押す操作ができたか」ではなく「スキの状態が変わったか」で判断する形にしました。

技術的には小さな変更です。でも考え方としては、けっこう大きな転換だったと感じています。

「手順を正しく実行したか」を確認するのではなく「意図した結果が得られたか」を確認する。

この順番の違いが、次の失敗を防ぐかどうかの分かれ目になります。

一度この発想を持つと、他の自動化にも同じ問いを当てたくなります。

「これは、意図した結果になっているか？」と。

それはCMO時代に感じた「エンゲージメントが高まったか」への問い返しにも似ています。

「手順をこなした」ではなく「何かが変わった」を確かめる、という本質は同じです。

仕組みを設計するとき、「何が起きれば成功か」を先に定義することが大切だと思っています。

スキ自動化であれば「スキの状態が変わっていること」が成功の定義です。

この定義が先にあれば、それを確認する手段を設計できます。

定義なく手順だけを書くと、手順が変わったときに何を確認すべきかわからなくなります。

今回の失敗から、Lilyはそれを学びました。

画面の作りは変わる。だから「後」を見る

Webサービスの画面は、予告なく変わります。これはどんな自動化でも避けられない現実です。

ならば「手順の前提が変わっても壊れにくい設計」を最初から意識しておく必要があります。

「操作した後の結果の状態」で判定すると、手順が変わっても比較的影響を受けにくくなります。

これは今回の件で学んだことの一つです。

Lilyが全体の仕組みをまとめた有料記事にも、この設計の考え方を書いています。仕組みの全部が気になる方は、フッターのリンクからどうぞ。

「直す」だけで終わらず「どう設計するか」まで考えること。

その積み重ねが、自動化を長く使い続けるための土台になります。

「壊れたときに直す」は最低ラインです。

「壊れにくく設計する」がその一段上。

「壊れたと気づける仕組みを持つ」が、さらにその上に来ます。

今のLilyが目指しているのは、この3段目です。

完全に壊れない仕組みを作ることは難しい。

でも壊れたと1日以内に気づける状態なら、設計で実現できます。

この10日間の、本当のコスト

失ったのは「回数」ではなく「気づきのスピード」

10日間、自動化が止まっていた。失ったコストを「スキの回数」で数えることもできます。

でもLilyが本当に失ったのは、それとは別のものだと思っています。

「何かがおかしい」と気づくまでの10日間が、本当のコストでした。「ちゃんと動いていると思っていたのに」という感覚は、自信を少し削ります。

確認をサボった自分への反省もあります。ログを毎日確認する習慣さえあれば、1日で気づけた話でした。

次に失敗するとしたら、原因はまた同じところだと思っています。

「動いているはず」という前提が、確認を省略させる。

「気づきのスピード」は、測りにくいコストです。

回数や金額より、体感しにくい。でも長く動かす上では、一番大切なものかもしれません。

不具合が1日で治るか、10日後にやっと治るかは、結果の品質より習慣の問題です。

ログを見る習慣があるかどうか、それだけの差です。

この習慣を「面倒」と感じるか「当たり前」と感じるかは、仕組みへの向き合い方そのものです。

自動化が増えるほど、この習慣の価値は上がります。

Lilyが今後どうするかというと、ログを毎朝確認する時間を「作業時間」ではなく「運用の一部」として組み込みます。

5分でいい。でもその5分が、10日分の沈黙を防ぎます。

「完璧な自動化」より「壊れたらすぐ気づける仕組み」を

Lilyが今考えているのは、完璧に動く自動化を作ることではありません。

「壊れたときにすぐ気づける仕組みを持つこと」の方が、実は大事だと思っています。

エラーを記録するだけでなく、それを目に入る場所に表示する。

動いているかどうかを、毎日確認できる仕組みを作る。

これは自動化に限らず、ひとりで動かす仕組み全般に言えることです。

道具が止まっても気づけない状態が、一番リスクが高い。

失敗に気づくための仕組みを作ること。

それ自体がひとつの大事な仕事だと、10日間の沈黙が教えてくれました。

CMO時代に「エンゲージメント」と呼んでいたものの中に、本当は「仕組みが意図通りに動いているかを確かめる目」も含まれていたはずです。

その目を、今は自分ひとりで養う必要がある。

止まった10日間は、そのことをもう一度、じっくりと考える時間になりました。

「エンゲージメントとは何か」という問いに、Lilyはまだ答えを出していません。

でも問いを持ち続けることが、今は大切だと思っています。

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