目次
「直したはずなのに、本番の動きが変わらない」——GASの運用でいちばん時間を溶かすのが、この状態です。
エラーは出ません。ログも正常です。だからつい、コードのロジックを疑って読み返してしまいます。ところが実際の原因は、書いたコードが本番に届いていないことでした。しかも原因は二段ありました。
この記事では、実案件（匿名）で追いかけた「修正が反映されない」の原因と、再発させないための確認手順を整理します。
この記事の結論
- 動きが変わらないときは、ロジックより先に反映経路を疑う
- clasp pushは成功表示でも反映されていないことがある
- WebAppは再デプロイするまで旧コードを配信し続ける
一段目の罠：clasp pushが成功しても反映されていない
GASをローカルで管理していると、clasp pushでコードをGoogle側へ送ります。このとき、コマンドは成功したという表示を返します。
問題は、成功表示が出ても実際にはコードが反映されていないケースがあることです。ターミナル上は何も異常がないので、開発者は「送信は済んだ」と信じて次の工程へ進みます。ここが最初の落とし穴です。
結果として、本番では前のコードが動き続けます。それでも動作自体は正常なので、エラー通知も出ません。「送ったのに変わらない」ときは、送れていない可能性を先に潰す必要があります。
二段目の罠：WebAppは再デプロイまで旧コードを配信する
コードが正しく反映されていても、まだ終わりではありません。GASをWebApp（/execのURLで外部から呼び出す形）として公開している場合、配信されるのは公開済みのバージョンです。
つまり、エディタ上のコードを新しくしても、新しいバージョンを選んでデプロイし直すまで、/execは旧コードを返し続けます。ここでもエラーは出ません。URLは生きていて、レスポンスも返る。ただし中身が古い、という状態です。
「エディタから手動実行すると直っているのに、URL経由だと直っていない」——この症状が出たら、ほぼこの罠です。
反映されない原因の切り分けフロー
二段の罠を踏まえると、確認の順序はこうなります。
大事なのは、ロジックを疑うのを最後に回すことです。コードを読み返す作業はいちばん時間がかかるのに、原因である確率は高くありません。先に経路を確認したほうが、圧倒的に速く終わります。
症状別の見分け方
| 症状 | 疑うべき箇所 |
|---|---|
| エディタ上のコードも古い | pushが反映されていない |
| エディタ上は新しいが/execは古い | 再デプロイをしていない |
| どちらも新しいが挙動が変わらない | ロジック／キャッシュ／設定値 |
まず「エディタ上のコードは新しくなっているか」を見る。これだけで、一段目か二段目かが分かれます。
対策：push後にpullして差分を検証する
一段目の罠は「成功表示を信じない」ことでしか防げません。そこで私たちは、次の手順を標準化しました。
clasp pushでコードを送る- 別ディレクトリに
clasp pullで取得する - 手元のコードと取得したコードの差分を取る
- 差分がなければ反映済み、あれば再push
ポイントは、作業中のディレクトリではなく別ディレクトリへpullすることです。同じ場所にpullすると、手元のコードを上書きしてしまい、比較になりません。「送ったつもり」を、機械的に検証できる形に置き換えるのが目的です。
WebAppの場合は、これに新しいバージョンを選んでデプロイし直す工程を足します。この2つをリリース手順書に書き込んでおけば、担当者が変わっても同じ事故は起きません。
なぜこの種のトラブルは長引くのか
理由はシンプルで、エラーが出ないからです。
システムのトラブルは、エラーメッセージが出れば調査の入口になります。しかし今回の二段の罠は、どちらも「正常に見える」状態で発生します。成功表示は出る、URLは応答する、ログも問題ない。手がかりがないので、消去法でコードを読み返すしかなくなります。
だからこそ、手順として先に潰すという発想が要ります。トラブルシューティングの技術ではなく、リリース手順の設計の問題として扱う。これが再発防止の考え方です。
なお、claspやGASのデプロイ周りの仕様は変わることがあります。最新の挙動は必ず公式ドキュメントで確認してください。
中小企業のGAS運用で押さえるべきこと
社内でGASを回している会社ほど、この問題は深刻になります。「作った人しか手順を知らない」状態だと、修正のたびに同じところで止まるからです。
持ち帰っていただきたい判断軸は一つです。
動きが変わらないときは、ロジックより先に反映経路（push → バージョン → デプロイ）を疑う。
そしてもう一つ。リリース手順を文書に残すこと。「pushしたらpullして差分を見る」「WebAppは新バージョンで再デプロイする」——たった2行でも、書いてあるかどうかで復旧時間が変わります。自動化の価値は、作ったときではなく、直し続けられるかどうかで決まります。
よくある質問
Q. GASを修正したのに動きが変わりません。何を確認すればいいですか？ コードのロジックより先に反映経路を疑ってください。clasp pushで実際にコードが上がったか、WebAppなら新しいバージョンでデプロイし直したか。この二点で大半が説明できます。
Q. clasp pushが成功と表示されれば、コードは反映されていますか？ 必ずとは言えません。成功表示が出ても実際には反映されていないことがあります。別ディレクトリへclasp pullして手元のコードと差分を取れば、反映済みかを客観的に確認できます。
Q. GASのWebAppで /exec が古い挙動のままなのはなぜですか？ WebAppは公開済みのバージョンを配信するため、コードを更新しても新しいバージョンを選んでデプロイし直すまで旧コードが返り続けます。エラーは出ないので気づきにくい挙動です。
まとめ
- 「直したのに変わらない」の原因は、コードではなく反映経路にあることが多い
- 一段目はclasp pushの成功表示。成功と出ても未反映の場合がある
- 二段目はWebAppのデプロイ。新バージョンで公開し直すまで
/execは旧コードを返す - 対策は、push後に別ディレクトリへpullして差分を検証し、手順書に残すこと
RENOYでは、GASの新規開発だけでなく、すでに動いている仕組みの「直せる状態」づくり——リリース手順の整備や属人化の解消もお手伝いしています。「社内で作ったGASが触れなくなっている」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。