目次
自動化の仕組みを入れたあと、画面には「成功」「有効」「正常」と表示されている。だから動いているはずだ——そう考えるのは自然なことです。
ところが私たちは、自社の仕組みと実案件の両方で、表示は正常なのに実態は動いていないという場面に4回出会いました。いずれもエラーは出ていません。だからこそ気づくのが遅れ、気づいたときには「しばらく止まっていた」という状態になります。
この記事では、その4つの実例と、表示に頼らず実態を確かめる方法を整理します。
この記事の結論
- 成功表示や「有効」は、実際に動いた証拠ではない
- 確かめるべきは設定画面ではなく、実行の結果の側
- 実行履歴・配信ダッシュボード・取り直した実データで確認する
表示と実態がずれた4つの実例
1. clasp push が反映されない・WebAppが旧コードのまま
GASをローカルで開発する際に使うclaspでは、pushが成功と表示されても反映されていないことがありました。
さらに厄介だったのがWebAppです。コードを更新しても、WebAppの公開URL（/exec）は新しいバージョンを選ぶまで旧コードを配信していました。手元のコードは新しい、pushも成功、それでも利用者が触っているのは古い仕組み、という状態です。
2. Zoho CRMのワークフローが「有効」なのに動かない
ある実案件（匿名）で、Zoho CRMのワークフロー設定を見ると、複数のワークフローが「有効」になっていました。ところが実行の記録を確かめると、実際に動いていたのはその一部だけでした。
ここで分かったのは、ONは起動の許可にすぎないということです。有効にしただけでは、想定どおりに起動している保証にはなりません。
3. メール送信APIは正常応答なのに、送信が止まっていた
メール送信のAPIは、呼び出すたびに正常な応答を返していました。しかし実際には、1回のバウンス（宛先不明などで戻ってきたメール）によって宛先がサプレッションリストに入り、その宛先への送信が止まっていました。
送る側のプログラムから見ればすべて成功。止まっていることは、配信側を見るまで分かりませんでした。
4. スプレッドシートの日付が、見た目は正しいのに中身がずれていた
スプレッドシート上の日付は、画面では正しく表示されていました。ところがセルの中身の値はずれていたのです。人が目で見る分には問題なく、そのデータを別の処理に渡したときに初めて食い違いが表面化します。
なお、各サービスの仕様は変わるため、最新の挙動は必ず公式の情報で確認してください。
「正常表示なのに動かない」の原因
4つを並べると、共通する構造が見えてきます。表示が伝えているものと、私たちが知りたいものが違うのです。
| 実例 | 表示が伝えていること | 本当に知りたいこと |
|---|---|---|
| clasp・WebApp | pushが完了した | 利用者に新しいコードが届いたか |
| Zoho CRMワークフロー | 起動してよい設定になっている | 実際に起動したか |
| メール送信API | 送信の依頼を受け付けた | 相手に届いたか |
| スプレッドシートの日付 | 画面上の見え方 | セルの中身の値 |
成功表示や設定画面は、途中までの状態を示しているにすぎません。最後まで処理が届いたかどうかは、別の場所を見なければ分からないのです。
エラーが出れば人は気づきます。しかしこのずれはエラーを出さないため、「問題なし」と判断されたまま運用が続いてしまいます。ここが一番の怖さです。
表示と実態のずれの対策：結果の側で確かめる
対策の考え方はひとつです。設定画面や成功表示ではなく、結果の側で確かめること。具体的には次の3つを見ます。
実行履歴：「動いた記録」があるか
ワークフローや定期処理は、実行履歴で確認します。「有効」かどうかではなく、想定したタイミングで実際に起動した記録が残っているかを見ます。Zoho CRMの例も、ここを見て初めて一部しか動いていないと分かりました。
配信ダッシュボード：相手に届いたか
メールは、送信APIの応答ではなく配信ダッシュボードで確認します。バウンスやサプレッションの状況は、送る側のプログラムからは見えにくいため、配信側の画面を定期的に見る運用が必要です。
取り直した実データ：中身は合っているか
データは、画面の見え方ではなく取り直した実データで確かめます。WebAppなら実際にURLを開いて挙動が変わったかを確認し、スプレッドシートなら表示ではなく値そのものを読み出して照合します。
運用に組み込むときの考え方
確認を「気づいたときにやる」にすると、結局やらなくなります。次の2点を、仕組みを作る段階で決めておくのがおすすめです。
- 更新したら必ず結果を確認する：push後、ワークフロー設定後など、変更のたびに実行履歴や実際の挙動まで見て完了とする
- 定期的に結果の側を見る：配信状況や実行履歴を、月次など決まったタイミングで確認する担当と手順を決めておく
「動いているはず」ではなく「動いた証拠を見た」状態を、運用の当たり前にすることが目的です。自動化は人の手を減らす仕組みですが、確認まで手放してよいわけではありません。
まとめ
- 自社と実案件で、表示は正常なのに動いていないずれが4回起きた
- clasp・WebApp、Zoho CRMワークフロー、メール送信API、スプレッドシートの日付は、いずれもエラーを出さずに止まっていた
- 成功表示や「有効」は途中までの状態にすぎず、最後まで届いたかは別の場所で確かめる必要がある
- 確認先は実行履歴・配信ダッシュボード・取り直した実データの3つ
よくある質問
Q. clasp pushが成功したのにWebAppに反映されないのはなぜ？ pushが成功と表示されても反映されていないことがあります。またWebAppの/execは、新しいバージョンを選んでデプロイし直すまで旧コードを配信し続けます。push後は表示ではなく、実際の挙動で確認するのが確実です。
Q. Zoho CRMのワークフローが有効なのに動かないのはなぜ？ ワークフローの「有効」は、起動してよいという許可にすぎず、実際に動いた証拠ではありません。設定画面だけでは分からないため、実行履歴を見て想定どおり起動しているかを確かめます。仕様は変わるため最新は公式で確認してください。
Q. 自動化が本当に動いているか確かめる方法は？ 設定画面や成功表示ではなく、結果の側を見ます。処理なら実行履歴、メールなら配信ダッシュボード、データなら取り直した実データです。「動いているはず」ではなく「動いた証拠」を見る習慣が、止まったまま気づかない事態を防ぎます。
RENOYでは、自動化の仕組みづくりだけでなく、「本当に動いているか」を確かめる運用の設計まで含めて伴走しています。「入れた自動化がちゃんと動いているか不安」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。