自動処理が「成功」と出ているのに反映されないとき｜終了コードではなくデータ側で健全性を見る
自動処理が「成功」と出ているのに反映されないとき｜終了コードではなくデータ側で健全性を見る
自動化を入れた店舗さんから、ときどきこういう相談が来ます。
- 毎日届いていたレポートのメールは来ているのに、中身の数字が先月から変わっていない
- 予約データの取り込みが「正常終了」と出ているのに、画面には新しいデータが出てこない
- エラー通知は一度も来ていない。ログにも赤い文字はない。でも反映されていない
先に結論を書きます。
自動処理の健全性は「動いたかどうか」ではなく、「出てきたデータが新しいかどうか」で見てください。 監視すべき数値はたった1つ、成果物の最終更新日時です。
なぜかというと、自動処理には「エラーを出さずに空振りする」という壊れ方があるからです。プログラムとしては最後まで正常に走り切っているので、終了コードは成功（0）を返します。ログにも異常は残りません。通知の仕組みを「エラーが出たら知らせる」で作っていると、エラーが出ないこの型だけは永久に検知できません。
この記事では、その静かな失敗がどう起きるのかを3つの型に分けて整理し、3分でできる確認手順と、最初からその壊れ方を検知できる仕組みの作り方まで書きます。プログラムを書かない立場の方でも、外注先や担当者に何を確認すればよいかまで持ち帰れる内容にしています。
なお、エラーメッセージがきちんと出て止まっているケースは別問題です。そちらは実行ログにすべて残っているので、原因の切り分け方はClaudeで作った業務GASが突然止まる｜トリガー・権限・実行時間の3大原因と復旧手順にまとめています。この記事が扱うのは、ログを見に行っても何も書いていないタイプです。
まず押さえる：処理の「成功」は3段階ある
「動いている」という言葉は、実は3つの意味を含んでいます。ここを分けて考えるだけで、確認の精度が一段上がります。
| 段階 | 意味 | 確認方法 |
|---|---|---|
| ①起動した | 決めた時刻にプログラムが立ち上がった | 実行履歴・ログの有無 |
| ②完走した | 途中で落ちずに最後まで走った | 終了コード・エラーの有無 |
| ③反映された | 目的のデータが正しく書き換わった | データ側の最終更新日時 |
多くの現場で監視しているのは①と②までです。ところが業務で困るのは③が起きていないときだけで、①②が成功していても③が起きないことは普通にあります。
たとえば、外部サービスからデータを取りに行く処理を考えます。認証が切れていて「権限がありません」という応答が返ってきたとしても、プログラムは「応答を受け取る」という仕事は完了しています。受け取った中身が空だっただけです。書き込む対象がゼロ件なので、何も書き込まずに正常終了する。ここでエラーを出すかどうかは、作った人が明示的にそう書いたかどうかでしか決まりません。
だから、正しい設計はこうです。成否の判定を、処理の側ではなくデータの側に置く。 「最後にデータが入った日時が、想定より古くないか」だけを見れば、①②③のどこで失敗していても等しく検知できます。
静かに失敗する3つの型
実務で遭遇する空振りは、だいたい次の3つに分類できます。それぞれ見え方が違うので、型ごとに確認する場所も変わります。
型A：処理は走ったが、中身が空だった（認証・権限の失効）
一番多いのがこれです。外部サービスと連携する処理は、必ず認証情報を使います。この認証情報には有効期限があったり、パスワード変更や仕様変更で無効になったりします。
無効になった瞬間から、処理は「認証エラーの応答を受け取って、0件を処理して、正常終了する」というループに入ります。毎日きちんと動いて、毎日きちんと何もしない状態です。
実際にあった例で言うと、名古屋の美容サロンFC向けに運用している売上ダッシュボードで、毎日深夜2時に走る同期処理が52日間この状態でした。処理の中でログイン経路を通っており、そのログインが失敗して権限のない状態のまま同期APIを叩き続けていた。売上データの最終日が2か月近く前で止まっていましたが、処理側は一度もエラーを出していません。
似た型で、広告アカウントの日次チェックが32日間、毎朝きれいなレイアウトの空レポートを生成し続けていたこともあります。原因は認証トークンの失効で、データ取得部分だけが失敗し、レポート生成部分は成功していました。レポートが届いていることが、かえって安心材料になってしまうのがこの型のいやらしいところです。
ここから引き出せる設計上の教訓は2つあります。
- 同一サーバー内の処理を、わざわざ外から呼び出さない。 内部の処理を内部から直接呼べば、ログインという壊れやすい経路そのものが存在しなくなります。認証を挟むほど、静かに壊れる箇所が増えます。
- 0件で正常終了させない。 「取得件数が0なら異常として扱う」という判定を1行入れておくだけで、この型は最初の1日で発覚します。
型B：そもそも起動していなかった（登録と実行は別物）
定期実行の設定が管理画面に「登録されている」ことと、それが「実際に発火している」ことは、まったく別の事実です。
ここで厄介なのは、起動そのものに失敗した場合、エラーログにも何も残らない点です。プログラムが立ち上がっていないのですから、そのプログラムが書くはずのログも当然存在しません。「ログが空＝異常なし」と読んでしまうと、完全に見落とします。
Macの定期実行（launchd）で、登録済み・設定ファイルも正常・エラーログも空、それでも28日間1度も実行されていなかったケースがありました。原因はプログラム側ではなく、ログの出力先フォルダがOSのプライバシー保護対象だったことです。書類・デスクトップ・ダウンロードの各フォルダはOSが保護しており、自動実行の仕組みがそこにログファイルを作れない。結果、ログが開けないという理由だけでプロセスの起動自体が中止されていました。
正しい作り方は次のとおりです。
- 自動実行のログ出力先は、OSの保護対象フォルダの外に置く。 具体的には書類・デスクトップ・ダウンロードの各フォルダを避け、ログ専用の場所を使います
- 定期実行を1日1回・単一の時刻にしない。 パソコンがスリープしている時刻に当たると、その日は丸ごと飛びます。1日3回に分ける、起動時にも走らせる、といった冗長化で取りこぼしが減ります
- 1本直したら、同じ作り方の他の自動処理も点検する。 実際にこのケースでは、原因が判明したあとに全部の定期実行を棚卸ししたところ、同じ理由で止まっていたものがほかに3本見つかりました。1本の不具合は「その1本の問題」ではなく「その作り方をした全部の問題」だと考えたほうが、結果的に早く終わります
型C：書き込んだが、見ている場所が違う（古い成果物が残る）
3つ目は、処理が失敗しているのに画面が正常に見えてしまう型です。
サイトの表示に使うファイルを自動生成している場合、生成に失敗しても前回の成果物がそのまま残り続けます。訪問者から見れば普通に表示されているので、異常はまったく分かりません。壊れているのは「新しい内容が反映されない」という一点だけです。
同じ理屈で気をつけたいのが、確認方法そのものが的を外している場合です。ページが正しく200で応答するか、特定のファイルが存在するか、といった確認は、こういう壊れ方では全部合格してしまいます。サイトは正常に動いているのですから当然です。
この型に対しては、確認したい中身そのものを直接測るしかありません。たとえば「検索エンジン向けに生成したページが生きているか」を確かめたいなら、公開URLを実際に取得してタイトルタグの中身を照合する。ファイルの有無やステータスコードでは判定できません。
実装寄りの例もひとつ挙げておきます。記事数がちょうど100の倍数になった日だけサイトのビルドが失敗する、という境界のバグがあります。「取得件数が上限未満なら終了」という条件だけで組むと、総数がぴったり割り切れる日に存在しないページを取りに行って失敗するためです。この場合も本番サイトは前回の成果物を配信し続けるので、外から見て壊れている様子は一切ありません。
こうした境界は、件数が特定の値になった日にしか発生せず、日常の動作確認では踏めません。設計時に「総数を取得して、それに達したら終了する」と明示的に書いておくのが唯一の予防策です。
3分でできる確認手順
ここまでを踏まえて、「反映されていないかも」と思ったときに最初にやることを順番に並べます。プログラムを触らなくてもできる範囲です。
- 成果物の最終更新日時を見る。 出力先のフォルダやファイル、あるいは画面上の「最終更新」表示を確認します。今日の日付になっているか。ここが古ければ、それ以降の調査は全部後回しでかまいません
- 中身の最新データの日付を見る。 ファイルの更新日時は新しいのに、中に入っているデータの最終日が古い、というパターンがあります。これは型Aです。ファイルは毎日きれいに上書きされ、中身が空のまま更新されています
- 件数を数える。 想定より極端に少なくないか。1店舗分しか入っていない、1日分しか入っていない、という取り込み事故は、金額の桁が小さくなるだけで形式は完全に正常なので、ファイルを開いても気づけません
- その処理と同じ作りの、他の自動処理も同じ観点で見る。 型Bで書いたとおり、1本壊れているときは同じ理由で他も壊れています
この順番が大事です。ログを開くのは、この4つを見たあとで十分です。
静かな失敗を検知する仕組みの作り方
一度気づいたあとにやるべきことは、原因を直すことではなく、次に同じ型で壊れたときに自動で分かる状態にすることです。原因は毎回違いますが、壊れ方の型は同じだからです。
最終更新日時を専用の項目として持つ
データベースを使っている場合、「最終同期日時」は専用の項目を用意して、処理側で明示的に書き込んでください。
一般的なデータベースには「行が更新されたら日時を自動で記録する」という便利な仕組みがありますが、これは値が実際に変化したときだけ動きます。同じ内容を何度上書きしても、中身が変わっていなければ更新日時は動きません。つまり「毎日同期しているが取得できる新しいデータがない」という正常な状態と、「同期処理が空振りしている」という異常な状態を、この日時では区別できないということです。
処理の最後に「この処理が正常に完走した日時」を専用項目へ書き込む。たった1項目の追加ですが、これが監視の土台になります。
「N時間更新されていない」を返す仕組みを最初から作る
最終更新日時を持ったら、それを判定する処理を必ずセットで用意します。「最後の更新から24時間以上経っている対象を一覧で返す」というだけの単純なもので十分です。
ポイントは、これを人が見に行く画面としてではなく、機械が判定できる形で作ることです。異常があれば処理として失敗を返すようにしておけば、そのまま定期実行に繋いで通知を出せます。人の記憶に頼る確認は、忙しい週に必ず飛びます。
複数店舗のサイトを運用する場合であれば、店舗ごとに主要ページの状態を並列で確認し、1つでも異常があれば異常として返す確認スクリプトを用意しておきます。「最後に必ずこれを叩く」を人の意志ではなく道具に持たせる、という考え方です。
通知は「異常があったら」ではなく「正常だったら」も送る
エラー時だけ通知する設計は、この記事で扱っている型に対しては無力です。エラーが出ないのですから、通知も出ません。
対策はシンプルで、成功したときも短い通知を送ることです。「本日の同期完了：最新データ 8月13日／件数 42」のような1行でかまいません。これがあると、届かなくなったこと自体が異常のサインになりますし、届いていても中の日付が動いていなければ型Aだと分かります。
沈黙を正常とみなさない。 これがこの記事で一番持ち帰ってほしい考え方です。
指示を足したら、そのために必要なデータが渡っているか確認する
AIを使った自動生成でも、同じ型の空振りが起きます。生成の指示に「前月の課題がクリアされたかを必ず確認すること」というルールを足しても、前月の内容そのものを渡していなければ、その確認は毎回スキップされます。しかも「データがなければスキップしてよい」と書いてあると、出力は一見それらしく完成するので誰も気づきません。
指示を追加したときは、その指示が要求するデータが実際に供給されているかを必ず突き合わせてください。ルールを書くことと、ルールが働くことは別です。
数字が「ゼロ」のときも、まず計測を疑う
最後に、集客・広告まわりで頻発する派生形に触れておきます。
管理画面で問い合わせ数やコンバージョン数が0のとき、多くの方は「成果が出ていない」と読みます。しかしその前に確認すべきは、そもそも測れる状態になっているかです。
計測タグがページから消えている状態では、何人訪問しようと数字は構造上ゼロにしかなりません。実際に、広告経由で30日間に212クリック・約8,900円を投じながらコンバージョン0だった案件を調べたところ、原因は成果の不足ではなく、サイト更新の際に計測タグが失われていたことでした。成果ゼロではなく計測ゼロです。
判断を間違えると打ち手も逆方向に進みます。「成果が出ていないから予算を止める」「キーワードを増やす」といった判断は、計測が生きていることが前提です。数字がきれいに0のとき、あるいは特定の指標だけが不自然に0のときは、まず計測の生死を確認してから解釈してください。
同じ理屈で、広告の表示回数が0なら、それは予算の問題ではなく入札や審査の問題です。「消化率が低い」という指標だけを見ていると、原因と逆の打ち手を選びます。
アクセス解析側で特定のイベントだけ記録されていない場合の切り分けは、GA4のイベントが1件も届かないときの調べ方｜ページビューだけ記録されている状態の見分け方で詳しく扱っています。
外注・担当者に確認しておく3つの質問
自社で実装していない場合は、次の3点を聞いておくと、静かな失敗の大半は事前に潰せます。
- この自動処理が正常に動いたことは、どこを見れば分かりますか。 「ログを見ます」と返ってきたら、この記事の型A・型Bは検知できません。データの最終更新日時で判定しているかを確認してください
- 処理が0件で終わったとき、通知は出ますか。 出ない設計なら、出るように変えてもらう価値があります
- 止まったことに、最短で何日で気づけますか。 「毎朝メールが来ています」だけでは不十分です。その通知に最新データの日付や件数が入っているかまで確認してください
いずれも実装が大掛かりになる話ではありません。むしろ、後から2か月分のデータを取り直す作業に比べれば、はるかに安く済みます。
まとめ
- 自動処理にはエラーを出さずに空振りする壊れ方があり、終了コードやログでは検知できない
- 健全性は成果物とデータの最終更新日時で判定する。「動いたか」ではなく「新しくなったか」を見る
- 静かな失敗は3つの型に分かれる。認証切れで中身が空／そもそも起動していない／書き込みに失敗しても古い成果物が残る
- 確認は、成果物の更新日時 → 中身のデータ日付 → 件数 → 同じ作りの他の処理、の順に見る
- 検知の仕組みは、専用の最終更新日時・N時間更新なしを機械が判定・成功時も通知の3点で足りる
- 数字が0のときは、成果ではなく計測の生死を先に疑う
自動化は「作って終わり」ではなく、「壊れたときに気づける状態にして終わり」です。沈黙を正常とみなさない設計にしておけば、2か月分のデータを失う事態はまず起きません。
自動化の設計や、すでに動いている仕組みの健全性チェックについてご相談があれば、お問い合わせからお気軽にどうぞ。