現況:巡回は動いているのに、候補が7月末から1件も増えていなかった
うちではAI秘書に、SNSやOSSの情報を毎日巡回させ、使えそうなネタを拾って評価し、優先順位をつけて記事や改善のタネにする仕組みを組んでいます。巡回自体は動いていて、候補のリストも一応存在していました。
ところが2026年9月8日の夕方、巡回後の点検で数を突き合わせると、巡回の記録は毎日増えているのに、評価済みの候補は7月末から1件も増えていませんでした。点検で数えて初めて分かったことです。
そこで、実際にジョブがいつ動いたのかを1件ずつ確認しました。巡回そのものと、巡回結果を採点する処理は別の工程に分かれており、前者は動いていても後者が止まっていれば、候補は増えずに滞留し続けます。定期実行の設定一覧を調べると、この採点処理はどこにも載っていませんでした。
対応:採点結果の記録を遡ると、7月29日を最後に一度も動いていなかった
その記録で採点が動いていたのは、7月29日、この処理を作ったその日だけでした。9月8日まで数えると、41日間、この処理は一度も実行されずに放置されていたことになります。
調べると、問題が二つ重なっていました。止まっていた直接の原因は、この採点処理を定期実行の一覧(どのジョブをいつ動かすかを管理する設定ファイル)に一度も登録していなかったことです。もう一つは、採点に使っていたローカルのAIモデルが9月上旬から応答しなくなっていて、手で動かしても採点がすべて失敗する状態だったことです。ローカルのAIモデルが止まっていること自体は別の監視で分かっていましたが、採点の失敗はエラーとして表に出ない作りでした。壊れて止まったジョブならエラーログが残りますが、呼ばれてすらいないジョブはログにも残らないため、機械的な異常検知では気づけませんでした。この「エラーは出ないが、そもそも動いていない」という状態が、今回いちばん見つけにくかった部分です。
対処として、まず毎日19時にAI秘書へ採点の実行を指示する定期ジョブを新設し、定期実行の一覧に正式に登録しました。あわせて、ローカルのAIモデルが応答しない時はクラウド側のAIへ自動で切り替えるフォールバックも組み込みました。9月8日はローカル側が止まっていたため、当日の採点はすべてクラウド側で行っています。9月8日の時点では、片方の経路が止まっても採点を続けられる形にしました。
さらに、同じ見落としを繰り返さないために、「定期実行の一覧に載っているか」「定期実行の仕組みが動いているか」「(記録が見つかれば)最後にいつ実行されたか」の3点を1コマンドで確認できる小さなチェッカーを作りました。似たような確認をしたいという要望は前日にも出ていたのですが、その時はその場しのぎの手作業で済ませていました。今回、41日分の放置という具体的な実害が出たことで、道具として作り切る決断をしました。
結果:採点は9月8日に再開。ただし一覧に載せただけでは安定しなかった
修理の途中で手で流した採点に続き、新しい定期ジョブも9月8日の19時に初めて動いて、止まっていた採点済みの候補はその日のうちに再び増え始めました。ただ、その後の1週間(9月9日〜15日)の記録を見返すと、AI秘書が指示に応答できず採点が動かなかった日や、切り替え先のクラウド側でも採点が全件失敗した日がありました。一覧に載せただけでは安定しない、というのも今回の学びです。さらに2026年10月26日時点の記録では、採点結果が最後に残っているのは10月13日で、それ以降は再び止まっています。確かめたい処理を指定してチェッカーを実行すれば、一覧への掲載・定期実行の仕組みが動いているか・(記録が見つかれば)最終実行時刻がすぐ分かります。ただし全部の処理を自動で見回る仕組みではないので、最終実行時刻が古くなっていないかは、定期的に読んで確かめる必要があります。
今回の件で得た教訓はシンプルです。「動いているはず」という前提は、思っているより簡単に崩れます。壊れて止まったものは目立ちますが、そもそも呼ばれていない仕組みは静かに存在し続けるだけで、誰かが実際に数えて確かめない限り気づけません。そして、確認したいという要望が2、3回出た時点で、それは一度きりの手作業ではなく道具にしてしまったほうが早い、という判断基準も改めて確認できました。
こうした「気づきにくい停止」を放置しない体制づくりは、社内の業務改善だけでなく、経営者や現場責任者が抱える「本当に手が回っているか分からない」という不安にも通じる話だと感じています。
日々の確認作業、AIに任せてみませんか 「本当は毎日やるべきなのに、後回しになっている確認作業」は、多くの現場に眠っています。ラポ秘書は、そうした地味だけれど大事な確認をAIに任せるための入口です。まずは気軽にご相談ください。 ラポ秘書に無料で相談する