GASを実行すると、「完了」と表示される。
スプレッドシートにも、
「処理済み」「送信済み」「投稿済み」と記録されている。
それなのに、
メールは届いていない。
SNSには投稿されていない。
外部サービスにデータが登録されていない。
画面の上では成功している。
でも、現実には何も起きていない。
このとき疑うべきなのは、
コードが動いたかどうかだけではありません。
その仕組みが、何をもって「成功」と判定しているか。
まず、そこを確認する必要があります。
「処理が終わった」と「目的を達成した」は別
GASやAPI連携には、いくつかの段階があります。
コードがエラーで停止しなかった。
外部サービスへリクエストを送れた。
外部サービスがリクエストを受け付けた。
実際にメール送信、投稿、登録などが完了した。
この四つは、同じではありません。
コードが最後まで走っただけで、
「成功」と記録されている場合があります。
外部サービスへ情報を送った直後に、
「処理済み」へ変更している場合もあります。
しかし、外部サービス側で拒否されていれば、
目的の処理は完了していません。
大事なのは、
GASが止まらなかったことではなく、現実側で結果が発生したこと
です。
1．成功表示は、どの時点で出ているか
最初に確認したいのは、
「成功」「処理済み」などを記録する位置です。
外部サービスへ送信する前に、
先に処理済みへ変更していないか。
リクエストを送っただけで、
成功扱いにしていないか。
外部サービスから成功した応答を受け取ったあとに、
ステータスを変更しているか。
送信前や送信直後に成功扱いにすると、
途中で失敗しても管理表だけは成功した顔をします。
その結果、
現実には処理されていない。
しかし、次回以降の対象からも外れてしまう。
という状態が起こります。
2．外部サービスの応答を確認しているか
GASからリクエストを送ると、
外部サービスから何らかの応答が返ってきます。
HTTPステータスコード。
エラーコード。
成功メッセージ。
作成されたデータのID。
こうした応答を確認せず、
「リクエストを送れたから成功」
としていないかを見ます。
GAS側の処理が終わっていても、
外部サービス側からエラーが返っている可能性があります。
ログに残すべきなのは、
「送信処理を実行した」という事実だけではありません。
外部サービスから何が返ってきたか。
ここまで記録して、初めて検証できます。
3．結果を証明する情報が残っているか
処理が本当に成功したなら、
あとから確認できる情報を残した方が安全です。
SNS投稿なら、投稿IDや投稿URL。
データ登録なら、登録IDや管理画面のURL。
ファイル作成なら、ファイルIDや保存先URL。
カレンダー登録なら、イベントID。
「処理済み」という文字だけでは、
本当に成功したのかをあとから追えません。
結果を証明するIDやURLがなく、
ステータスだけが成功になっている場合は注意が必要です。
4．エラーを握りつぶしていないか
GASでは、エラーが起きても、
処理を止めずに続行させることがあります。
それ自体が悪いわけではありません。
問題は、エラーを受け取ったあとに、
何も記録せず処理を進めてしまうことです。
エラーが起きても、
最後に「処理済み」と書き込む。
成功したときと同じ処理を続ける。
失敗の内容をログにも残さない。
このような作りでは、
失敗しても管理上は成功になります。
最低限、エラー時には、
発生日時。
対象の行やデータ。
エラーコード。
エラーメッセージ。
どの処理で止まったか。
を残した方がよいです。
5．状態を四つに分けているか
管理ステータスを、
「未処理」と「処理済み」
だけにすると、途中の状態が見えません。
できれば、次の四つに分けます。
未処理
処理中
成功
失敗
処理を始める前に「処理中」へ変更する。
現実側の成功を確認してから「成功」にする。
エラーが発生したら「失敗」にする。
こうしておけば、
処理中のまま止まった。
失敗して再確認が必要。
成功したので対象から外してよい。
という違いが見えるようになります。
6．外部サービス側で実体を確認できるか
最終的な確認先は、
GASの実行ログではありません。
実際に処理される外部サービスです。
メールなら、受信先や送信履歴。
SNS投稿なら、実際のアカウント画面。
データ登録なら、外部サービスの管理画面。
ファイル作成なら、保存先フォルダ。
GASの画面だけを見ていると、
GASの都合でしか成功を判断できません。
処理の目的が達成されたかどうかは、
目的地で確認する必要があります。
7．再実行で重複しないか
「成功表示なのに反映されない」と気づくと、
すぐ再実行したくなります。
しかし、ここにも注意が必要です。
実は外部サービス側では成功していて、
管理表への記録だけが失敗していた。
この場合、もう一度実行すると、
同じメールや投稿、登録が重複する可能性があります。
再実行する前に、
外部サービス側に結果が存在しないか。
成功IDが返ってきていなかったか。
同じ内容をすでに処理していないか。
を確認します。
未処理を防ぐだけでなく、
重複処理を防ぐ設計も必要です。
私がこの問題を意識するようになった理由
私自身も、Xの自動投稿で似た状態を経験しました。
管理上は「POSTED」。
処理も完了したように見える。
けれど、実際のXには投稿がない。
画面の上では、うまくいっていました。
だからこそ、しばらく疑いませんでした。
そこで分かったのは、
管理表の成功と、現実の成功を分けて考えなければいけない
ということです。
この考え方は、SNS投稿だけに限りません。
メール送信。
API連携。
データ登録。
ファイル作成。
カレンダー登録。
外部サービスとつなぐ処理なら、
ほぼ同じ確認が必要になります。
ChatGPTに確認を頼むときの依頼文
コードをすべて自分で読めない場合は、
ChatGPTに検査役を頼むこともできます。
ただし、
「このコードは正しいですか」
だけでは、確認が甘くなりやすいです。
次のように依頼します。
以下のGASまたはAPI連携では、管理画面上は「成功」「処理済み」と表示されますが、外部サービス側に結果が反映されていない可能性があります。
正しく動いている前提ではなく、失敗している可能性を優先して確認してください。
特に、次の点を調べてください。
-
外部処理が完了する前に、成功ステータスへ変更していないか
-
外部サービスから返された応答内容を確認しているか
-
成功を証明するIDやURLを保存しているか
-
エラーを握りつぶし、処理だけ続行していないか
-
未処理・処理中・成功・失敗を区別できているか
-
管理上の成功と、外部サービス側の実際の成功を分けて確認できるか
-
再実行時に重複処理が起きる可能性はないか
確認できたこと、確認できていないこと、推測を分けて回答してください。
大事なのは、AIに
「大丈夫です」
と言ってもらうことではありません。
どこが壊れている可能性があるかを、洗い出してもらうこと
です。
最低限確認したいチェックリスト
□ 成功表示は、外部処理の完了後に出ているか
□ 外部サービスの応答内容を確認しているか
□ 成功を証明するIDやURLが残っているか
□ エラー内容が記録されているか
□ 未処理・処理中・成功・失敗を分けているか
□ 外部サービス側で結果を確認したか
□ 再実行しても重複処理が起きないか
画面の成功ではなく、現実の成功を見る
GASやAPI連携は、動き始めると頼もしく見えます。
シートが更新される。
ログが流れる。
成功の文字が並ぶ。
画面の上では、仕組みが完成したように見えます。
でも、最後に見るべきなのは画面ではありません。
メールが届いたのか。
投稿が存在するのか。
データが登録されたのか。
ファイルが作成されたのか。
現実側に結果があるか。
そこです。
動いたように見えることと、
目的を達成したことは違います。
成功を確認できる仕組みまで作って、
ようやく自動化は道具になります。
自分の案件に当てはめるには、
確認項目を毎回ゼロから考えるより、共通の型を持っておく方が安全です。
この記事で触れた確認項目を、
コード・集計・自動化へ共通して使える形にしたテンプレをnoteにまとめています。
▶ AIで“できた気になる”を防ぐ検証テンプレ 初版
