GASで「新しいデプロイ」を押してしまったときの正しい戻し方|既存URLは無傷。直すのは既存デプロイの「新バージョン」だけ
GASで「新しいデプロイ」を押してしまったときの正しい戻し方|既存URLは無傷。直すのは既存デプロイの「新バージョン」だけ
Google Apps Script(GAS)でWebアプリを運用していて、コードを直したあとにデプロイ画面を開き、目立つ位置にある「新しいデプロイ」を押してしまった。押した瞬間に別のURLが表示されて、「配布済みのURLが変わってしまったのでは」と血の気が引く——この操作は、GASを手作業で更新している限り、いつか必ず踏みます。
先に結論を書きます。
「新しいデプロイ」を押しても、すでに配ってあるURLは壊れません。別IDのデプロイが1本増えるだけで、既存のデプロイは旧バージョンのまま動き続けています。やることは、既存デプロイの行を「新バージョン」で更新することと、誤って作られた側をアーカイブして1本に戻すことの2つだけです。
弊社graciautoは名古屋でホームページ制作とLINE公式アカウント構築を手掛けており、支援先の多店舗チェーン向けに、GASのWebアプリで動く発注フォームやスタッフ向け配信ツールを本番運用しています。この記事は、その運用中に実際に発生した誤操作と、そのとき実測で確認した挙動をもとに書いています。
何が起きているのか:URLはコードではなくデプロイIDに紐づく
戻し方の前に、なぜ慌てなくていいのかを押さえておくと判断が速くなります。
GASのWebアプリURLは https://script.google.com/macros/s/{デプロイID}/exec という形をしています。このデプロイIDは、スクリプトでもコードのバージョンでもなく「デプロイ」という単位に紐づいています。
つまり、こういう関係になっています。
| 操作 | デプロイID(=URL) | 出てくるコード |
|---|---|---|
| 既存デプロイを「新バージョン」で更新 | 変わらない | 最新になる |
| 「新しいデプロイ」を作成 | 新しいIDが発行される | 新デプロイ側だけ最新 |
| コードを保存しただけ | 変わらない | 変わらない(旧バージョンのまま) |
ここで大事なのは3行目です。Webアプリとして公開しているGASは、コードを保存しただけでは公開側に反映されません。反映させる操作がデプロイであり、その操作画面に「新しいデプロイ」と「既存デプロイの編集」が隣り合って置かれているために誤クリックが起きます。
そして「新しいデプロイ」を押した場合に起きるのは、IDの発行であって、既存IDの上書きではありません。実際に21店舗が使っている発注フォームで誤クリックが発生したときも、既存IDのURLはHTTP 200で応答を返し続け、店舗側の画面には旧バージョンのフォームがそのまま表示されていました。壊れていたものは何もなく、単に「最新コードが出ていない状態が続いている」だけでした。
正しい戻し方:既存デプロイの行を「新バージョン」にする
手順は次のとおりです。まずGASエディタを開き、上から順に進めます。
- エディタ右上の「デプロイ」→「デプロイを管理」を開く
- 一覧から既存デプロイの行を特定する(説明文と、URL末尾のIDが配布済みURLと一致するかで判断)
- その行の鉛筆アイコン(編集)をクリック
- バージョンのプルダウンで「新バージョン」を選ぶ
- 説明欄に日付と変更内容を書き(例:
2026-09-04 発注数量チェック追加)、「デプロイ」を押す
これでURLは1文字も変わらないまま、最新コードが公開されます。配布済みのリンク、スプレッドシートのハイパーリンク式、店舗グループに送信済みのメッセージ、QRコード——どれも差し替え不要です。
行の特定を目で頑張らないのがコツです。デプロイIDは70文字前後あり、大文字の「I」と小文字の「l」のように判別できない文字が混ざります。スクリーンショットや画面の見た目からIDを読み取ろうとすると誤読します(実際に SIj を Slj と読み違えた例があります)。画面のコピーボタンでURLを取得し、配布済みURLとテキストとして完全一致で比較してください。
誤って作られたデプロイは、アーカイブして1本に戻す
更新できたら、そこで終わりにせず、誤って作られた側を同じ画面の鉛筆アイコンから「アーカイブ」しておきます。
放置しても直接の害はありません。害が出るのは、しばらく経ってからです。
アクティブなデプロイが複数あると、どのURLが本番なのかが人間側から判別できなくなります。別の案件で、管理画面用のGASにアクティブなデプロイが2本残っていたことがありました。片方は最新のバージョン5、もう片方は数時間前のバージョン2のまま。URLが2本存在し、古い方を開くと当然、旧UIが表示されます。「画面を直したはずなのに直っていない」という報告の原因が、実は担当者のブックマークが古い方のURLを指していただけ、という事態が起こり得ます。
さらに厄介なのは、LINEのWebhookのように外部サービスへ登録済みのURLがある場合です。登録先がどちらのIDを指しているかは、GAS側の画面からは分かりません。外部サービスの設定画面を開いて突き合わせる作業が必要になります。
アクティブなデプロイは1本に保つ。これだけで、この種の調査時間はまるごと消えます。
新しく作られた方に「乗り換える」のは避ける
「もう新しいデプロイができてしまったのだから、こちらを本番にすればいいのでは」と考えたくなりますが、これは避けてください。乗り換えは二重に事故ります。
1つ目:アクセス設定を作り直す必要がある。新しいデプロイは、公開範囲の設定を引き継ぎません。未ログインの利用者に開かせたいWebアプリなら「アクセスできるユーザー」を「全員」に設定し直す必要があります。ここで注意したいのが、選択肢に「Googleアカウントを持つ全員」という似た項目が並んでいることです。この2つは別物で、後者を選ぶと未ログイン端末では開けません。設定し直すたびに、この取り違えのリスクが発生します。
2つ目:呼び出し側の修正が必要になる。Webアプリを自社サイトやPHPから呼んでいる構成では、デプロイIDを定数として持っています。乗り換えると、GAS側の設定とサーバー側の定数の2箇所を同時に直すことになり、片方だけ直した状態が生まれます。
既存デプロイを新バージョンにすれば、この2つはどちらも発生しません。触る場所が少ない方が正解です。
反映確認は「実際に配ったURL」で行う
デプロイし直したあとの確認で、意外と多いのが確認方法の取り違えです。
エディタのプレビューや /dev で終わるテストURLは、保存しただけのコードが即座に反映されます。つまり、デプロイが成功していなくても最新の画面が見えてしまう。ここで確認しても「反映されたかどうか」の答えにはなりません。
確認は必ず、利用者に配ってあるURLそのもので行ってください。ブラウザにログイン状態が残っていると判定を誤るため、プライベートウィンドウか、コマンドラインからの取得が確実です。
curl -sIL "https://script.google.com/macros/s/{デプロイID}/exec"
最終的にHTTP 200が返り、ブラウザで開いた画面に今回追加した要素が出ていれば完了です。
あわせて、疎通確認用の軽い応答をコード側に用意しておくと運用が楽になります。doGet の冒頭で ?health=1 のようなパラメータを見て、alive という短い文字列だけを返す分岐を置いておくやり方です。ログイン不要・数バイトで生死が判定でき、例えば外部の監視サービスから定期的に叩くといった使い方もできます。
ただし、これは生きているかどうかしか分かりません。前述のアクティブ2本のケースでは、両方のURLが alive を返しました。バージョンの新旧までは判定できないので、応答にバージョン番号を含めておくとさらに使えます。
そもそも押しても困らない設計にしておく
誤クリックを根絶するより、踏んでも影響が出ない形にしておく方が現実的です。取れる手は3つあります。
1. 配布するURLを自社ドメインにする。script.google.com の直リンクを配らず、自社ドメイン上の固定URLを1枚かぶせておきます。将来どうしてもデプロイIDが変わる事態になっても、直すのはサーバー側の1箇所だけで済み、配布済みのリンクは無傷です。多店舗へ配布するようなケースでは、これが効きます。
2. デプロイURLを、設置した時点で必ず記録する。WebアプリURLはコードにもスプレッドシートにも残りません。記録がないと、あとから調べるためにブラウザでエディタを開き、デプロイ管理画面まで辿る作業が発生します。手順書の最終ステップに「発行したURLを台帳に貼る」を必ず入れてください。特に、開発者ではない担当者が自分でデプロイする運用では、記録が残る経路が他にありません。
3. 手順書に、誤操作した場合の1行を添えておく。「もし『新しいデプロイ』を押してしまったら、既存デプロイの鉛筆→新バージョンで戻せます。既存URLは変わっていません」。この1行があるだけで、担当者が慌てて余計な操作をするのを防げます。
起こりうるリスクと予防策
| 起こりうること | 原因 | 予防策 |
|---|---|---|
| 直したのに反映されない | 保存しただけでデプロイしていない | 更新の最後は必ず「新バージョン」でデプロイ |
| 一部の人だけ古い画面を見ている | アクティブなデプロイが複数ある | 誤作成分は即アーカイブし、常に1本に保つ |
| デプロイ後に誰も開けなくなった | 新デプロイでアクセス範囲が既定に戻った | 既存デプロイの更新で運用し、新規作成を避ける |
| 呼び出し元だけ旧IDを見ている | 乗り換え時に片方しか直していない | IDを変えない運用にする/変える場合は変更箇所を一覧化 |
| URLが分からなくなった | 設置時に記録していない | 手順書の最終ステップにURL記録を組み込む |
よくある質問
Q. 「新しいデプロイ」を押した時点で、配布済みのURLは死にますか?
いいえ。既存のデプロイIDとURLはそのまま生きています。増えるのは新しいIDのデプロイ1本だけです。既存URLは、あなたが最後に「新バージョン」で反映したコードを返し続けます。
Q. 誤って作ったデプロイを削除ではなくアーカイブにするのはなぜですか?
GASのデプロイ管理では、アクティブなデプロイを一覧から外す操作が「アーカイブ」です。実務上の目的は、アクティブなURLを1本に絞って、どれが本番か迷わない状態を作ることにあります。放置しても直ちに壊れませんが、次に更新する担当者がどちらの行を編集すべきか判断できなくなります。
Q. 「新バージョン」のプルダウンがクリックしても反応しません。
このプルダウンは、環境や自動操作ツール経由で選択が反映されないことがあります。ブラウザを変える、拡張機能を切る、別のウィンドウで開き直すあたりで解決することが多いです。それでも解決しない場合、その場しのぎで「新しいデプロイ」を作るとURLが変わって配布物の差し替えが発生します。配布済みURLがある本番環境では、URLを変えない方を優先し、時間を置いて再挑戦するか、コマンドライン(clasp)からのデプロイに切り替える判断が安全です。
Q. バージョンを戻したい(前のコードに戻したい)ときはどうしますか?
同じ画面の鉛筆アイコンから、プルダウンで過去のバージョン番号を選んでデプロイすれば戻せます。デプロイした各バージョンはスナップショットとして残るため、これは「戻す」操作として使えます。ただし残るのはデプロイ時点のもので、保存しただけの状態は残りません。区切りのいいところで説明文を付けてデプロイしておくと、あとで戻れる地点が増えます。
まとめ
GASの「新しいデプロイ」誤クリックは、失うものがほとんどない事故です。要点を3つに絞ります。
- 既存URLは無傷。別IDのデプロイが1本増えるだけで、配布済みのリンクは何も変わっていない
- 戻し方は「デプロイを管理→既存デプロイの鉛筆→新バージョン」だけ。誤作成した側はアーカイブして、アクティブなデプロイを1本に保つ
- 乗り換えない。新デプロイ側を本番にすると、アクセス範囲の再設定と呼び出し側の修正という2つの事故要因を自分で作ることになる
そのうえで、配布するURLを自社ドメイン側に置き、設置時にURLを台帳へ記録しておけば、この操作は「戻し方を知っていれば1分で終わる作業」になります。
弊社graciautoでは、名古屋を中心に店舗ビジネス向けのホームページ制作・LINE公式アカウント構築と、こうした業務ツールの設計・運用支援を行っています。GASで作った仕組みが属人的になっている、更新のたびに反映されたか不安になる、といった状態でしたら、運用手順の整理からご相談いただけます。