自動更新が止まったサイトに、運営者は最初に気づけるか。自作の動画検索サイトObQAを直した飯塚浩也さんの動画から読む

私は、発信で「ここで躓きました」も見せる、と決めています。うまくいった話だけを出さない。カッコつけない。失敗も財宝だって、考えています。

飯塚さんは、その形を先にやって見せています。謝罪を動画の頭に置く。コメントで指摘された場所を、画面で再現する。直すところまで映す。黙って直す道もあったと思います。

見せるのは、全部の途中経過ではありません。判断の材料になる過程です。飯塚さんが映したのは、コメントの再現、原因の仮説、AIへの渡し方、直した結果でした。どれも、見た人が自分のサイトで使える材料です。

経営者の立場で考えると、ミスを自分から先に言うのは、怖い場面だと思います。推測: お客さんから見ると、先に言ってくれる人のほうが、次に止まった時も先に知らせてくれそうに見えると思います。

見せたことで、視聴者は、同じ穴が自分のサイトにないかを確かめる材料を受け取れます。直した本人が「ミス」と呼んだところに、いちばん学べる材料が残っている。だから、この動画は、復旧の手順より先に、この姿勢から読みます。それが、出発点です。

ここで分かれていたのは、二つの部品です。言葉から動画を探す検索の部分と、見つけた動画を開く先のページの部分。検索は、新しい動画をちゃんと拾っていました。止まっていたのは、ページを作る側だけです。

検索結果の一覧は、出ます。古い動画は開くので、サイト全体が壊れているようには見えません。押した人にしか見えない壊れ方は、作った本人が自分で押さない限り、気づく機会がありません。飯塚さんも、コメントが届くまでは、気づいていませんでした。

料理に例えると、コンロの火が点いていても、お皿が客席に出ていなければ、お客さんにとっては何も出ていないのと同じです。ObQAでは、最初に気づいたのは視聴者のコメントでした。

だから、見る場所は、検索が動いたかではなく、押した先のページが開くかに置きます。

大事なのは、失敗じゃなかった、ってことです。エラーが出て止まったのではなく、走るはずの処理が走っていなかった。

「私のミスで」と、飯塚さんは、止まった責任を自分の持ち場に置いています。仕組みを作った本人だから、止まった日を、自分のこととして数えられます。見張りを足すのも、その延長だと思います。責任の置き場所が先です。

動かなかった日の記録は、残りません。予定と記録を並べないと、動かなかった日は見えません。私の現場の番人は、予定の時刻と、最後に動いた時刻を並べて、動いていないものを見つけています。

止まっていた期間が長いほど、直した後に確かめる範囲も広がります。推測: 再ビルドはサイト全体を作り直すので、止まっていた間に増えた動画まで、ページが開くかを確かめることになります。直す作業より先に、止まっていた期間を知ることが、確かめる範囲を決めます。

だから、自動化の出来は、動いた日ではなく、人が触らなかった日に動いたかで見ます。

飯塚さんは、AIに聞く前に、自分で仮説を立てていました。Cloudflareの更新が止まっているのでは、という一本です。人間は縦に掘る。AIは横に広げる。仮説は、飯塚さんが縦に掘った一本でした。

頼み方に、順番がありました。現象・仮説・URLを渡して、原因なのかと問う。そのうえで、本当に再現するかの確認を足している。答えを受け取る前に、現象が実在するかを確認させる順番です。

仮説を1行で言うには、自分のサイトの仕組みを知っている必要があります。飯塚さんの仮説は、その上に立っていました。

AIは、その一本を渡されたから、再現の確認、止まった日付、対策の提案へ、横に広げられたんだと思います。推測: 仮説なしで「サイトが変です」と渡していたら、広げる先がばらけたはずです。縦に掘るのは、人です。

画面には、境目も見えました。Claude Codeの説明に、「オーナー操作が必要な2件」という項目があり、「私の権限では実行できないため手順を記します」と書かれています。実際、Cloudflareの管理画面へ行って入れ直しを押したのは、飯塚さん本人です。人の仕事として残る所が、はっきりあるんです。

壊れている時にホームへ戻る挙動は、壊れていることを隠していました。404ページは、壊れたことを、見える形にする足し方です。

毎晩の自動再ビルドは、手で1回直した後に足す、次の一手です。手で直して終わりにしない順番を、飯塚さんは置いています！見えるようにする。それが先です。

03章で「予定があったかは後で分かる」と書いた答えが、ここです。画面の説明では、予約は7月19日付の設定ファイルで、前から登録されていました。この動画で足したのは、動かすためのURLをVaultへ入れる作業です。動かなかった理由は、動画の範囲では確かめられません。推測: 予約が7月19日付であるのに止まっていたので、動かす鍵（URL）が入っていなかったのかもしれません。

動画では、翌朝に動いたかどうかは、飯塚さんが自分で見に行くと言っています（13:58〜）。ここから先は、私の現場の話に置き換えます。

私は、委ねた先が嘘をついたり、やらなかったりするなら、委ねられない、と考えています。信頼できる仕組みが先、です。自動で回す仕事は、止まったことを誰も知らせてくれないと、委ねた先がやらなかったのと同じ形になります。推測: 静かに止まることと、やらないことが同じ結果になる、という接続は、私の読みです。

私の現場では、自動実行の管理画面に登録しているものが340件あり、そのうち有効なのは126件です（2026年10月1日に数えました）。

9月26日に、AI秘書の凛ちゃんが、自動実行の止まり方を3種類に分けて見せてくれました。1つ目は、番兵（失敗が続いた仕事を自動で止める仕組み）の凍結で、スイッチはオンのまま、中身が止まります。2つ目は、管理画面（Cockpit）が印を付けて自動でオフにするもの。3つ目は、印がないオフで、誰も見ていませんでした。私は、見張りを、毎日決まった時刻に見回る番人1本にまとめる案を選びました。最初の朝の報告は、9月27日7時23分でした。

番人（autorun-scheduler-guardian）は、毎日7時23分と19時23分に動きます。1つ目は報告し、2つ目と3つ目は自動で戻します。3つ目は1回5件までで、止めたい自動実行は、除外リスト（keep-off.md）に書けば戻しません。朝の報告は、Chatworkの私のチャットへ届く短い報告です。見出しと、番兵の凍結の件数と、「異常なし」の3行で、記録は9月27日から10月1日まで5日分あります。10月1日7時23分に番人が動いた記録は、自動実行の一覧（autoruns.json）の「最後に動いた時刻」で見ました。

旧い見張り（sentinel-watch）は、この統合で止めています。その冒頭の説明には、番兵が凍結しても、止まったことを誰も報告しないと、静かに止まって気づけない、という動機が書かれています。この動機は、番人1本に引き継いでいます。

見張りが見ているのは、予約が動いたか、失敗して凍結したか、設定ミスで自動オフになったか、です。

別の実例があります。内部の計測物（記事別の閲覧数、YouTube解析、Xのエンゲージメント、経営の数字、バックアップ）には、走ったかではなく、成果物ファイルの更新日時で見る番人がいます。スクリプトは2026年6月17日に作り、いまは毎日8時27分に回っています。この番人自体が、一度、黙らされました。2026年9月5日の記録では、8月27日から9月5日まで、Xのエンゲージメントが18.6日、更新されていませんでした。番人が異常を見つけた瞬間に、その便が失敗扱いで凍結され、誰も気づきませんでした。直したのは、異常を見つけたことと、番人が正常に動いたことを、分ける作りです。

この更新日時で見る番人は、内部の計測物には既にあります。お客さんが触る公開ページには、確認した範囲では置いていません（10月1日に、自動実行の一覧と番人のコードで確認）。これは提案です（未実装です）。公開ページにも、更新日時で見る番人を足して、期待した間隔より古ければ知らせる。走ったかではなく、お客さんが触る物が、いつ新しくなったかを見る。

「毎晩動く」の次に置くのは、「動かなかった時に、自分が先に知る場所」です。

私は医師ではないので、医療の話を、自分の体験には重ねません。ただ、直して終わりではなく、経過を見るところまでが仕事、という並べ方は、自動で回すものにそのまま使えます。

夜に直してリリースする話も、アフタートークに出てきます。夜に直した翌朝は、いちばん見に行く価値がある時間だと思います。

見に行くと決めるのは、人です。見に行く先を用意するのは、仕組みです。この2つは、別の仕事だと思います。飯塚さんは、「こちらで確認したい」と、前者を自分の持ち場として言い切っています。

直した直後は、直ったように見えます。ObQAも、手で1回押した直後は、ページが開きました。でも、それは明日も直っている保証ではありません。確かめるのは、明日です。

判断の理由と同じで、動いたか動かなかったかも、書き残さないと辿れません。翌朝に動いたか、動かなかったか。その記録が1行残っていれば、次に止まった時に辿れます。動いたけれど遅れていた、も、止まりかけのサインです。記録は、1行でいい。