AIものさし

Google Apps ScriptのWebアプリを更新しても古いコードが動くときの確認

Apps Script Webアプリの修正が反映されないとき、/devと公開URLを区別し、既存deploymentを新しいversionへ更新する方法を解説します。

AIものさし編集部

目次

最初に見るのは保存状態ではなくdeployment

Apps Scriptのコードを保存したのに、公開Webアプリが古い動作を続けることがあります。多くの場合、編集画面の最新コードと利用者が開くversioned deploymentは別の状態です。公開中deploymentを更新するには、新しいversionを作成し、そのdeploymentを新versionへ切り替えます。既存deploymentを編集すれば、通常は同じURLとdeployment IDを維持できます。

まず「どのURLで、どの利用者が、どの動作を見たか」を記録します。編集者用のtest deployment URLを開いているのか、利用者へ配布したversioned deployment URLなのかを区別してください。プロジェクトの保存・実行履歴だけで、利用者のURLが新しいversionを使っているとは判断できません。

表は横にスクロールできます

状態使うコードURL・用途
現在の編集コード保存した最新コード編集者の作業中状態
Test deployment最新コードを使うhead deploymentテスト用。編集権限のある利用者向け
Versioned deployment指定された固定version利用者へ公開中のリリース

Webアプリ用のtest deployment URLは末尾が/devで、スクリプトを編集できるユーザーだけがアクセスできます。一般ユーザー向けの公開URLと混同しないでください。テストで最新コードが動いたとしても、それだけではversioned deploymentの更新が完了した証拠になりません。

1. 実際に呼ばれているURLを特定する

利用者、ブックマーク、HTML内のリンク、外部サービス、別のスクリプトなどが呼ぶURLを一つずつ集めます。Apps ScriptのDeploy > Manage deploymentsで、active deploymentの説明、ID、種類、versionを確認し、呼び出し元が使うURLと対応づけます。

表は横にスクロールできます

確認するもの記録例目的
呼び出し元Sheet、Web page、外部API、利用者どこが古いURLを保持するか特定
URL/exec または /dev などtest/publicの取り違え確認
deployment IDManage deployments上のID正しいdeploymentを選ぶ
現在のversion管理画面の表示公開中コードの特定
期待する動作入力と返る結果QAを具体化

projectが複数ある場合は、Script IDやDrive上の名前だけで判断せず、利用中URLがどのprojectのdeploymentか照合します。同じコードをコピーした別projectや、過去に作ったdeploymentが残っていると、正しいprojectを更新しても利用者が別URLを見続けることがあります。

URLを特定できないときは、呼び出し元を順に調べてください。Webページのリンク、Properties/設定値、外部サービスのWebhook URL、Sheetやフォームのボタン、ドキュメント内の共有リンクなどを確認します。古いURLを全部置き換える前に、どの利用者がどのdeploymentを必要としているかを把握します。不要と確認できないdeploymentは削除しません。

2. Test deploymentとVersioned deploymentを使い分ける

Apps Scriptのhead deploymentは、プロジェクトの現在のコードに同期するテスト用です。Versioned deploymentは特定の不変versionを使う公開リリースです。したがって、test URLで変更を確認することと、公開deploymentへ変更を反映することは別操作です。

編集者として最新コードの動作を見るだけなら、Deploy > Test deploymentsからWeb appを選び、/dev URLを使います。権限がないユーザーはアクセスできないため、/devを一般公開先として配布しないでください。

実際の公開先を更新するときは、既存deploymentを選び、新しいversionを作成して、そのdeploymentが新versionを使うように編集します。新しいdeploymentを追加すると別のURL/IDが発行されるので、配布済みURLを維持したい場合は、同じdeploymentを編集対象に選んでいるかを確認します。

3. 既存URLを維持して更新する

変更を公開する前に、対象deploymentのID、現在version、アクセス設定、実行ユーザーを記録します。そのうえで次の順に進めます。

  1. 現在のprojectに編集内容が保存されていることを確認する。

  2. まずtest deploymentで、今回直した分岐・入力・出力を確認する。

  3. Deploy > Manage deploymentsを開き、利用中URLに対応するactive deploymentを選ぶ。

  4. EditでVersionからNew versionを選択する。

  5. Deployment ID・URL・アクセス範囲・実行ユーザーが意図した設定のままか確認する。

  6. Deployを実行して、既存deploymentが新しいversionを参照するよう更新する。

  7. 配布済みの既存URLを開き、同じ入力で期待動作を確認する。

  8. 管理画面からdeployment versionを読み戻し、変更記録へ残す。

Google公式の説明では、既存deploymentを更新すると同じURLまたはdeployment IDを保ったまま新versionを使えます。新deploymentを作る方法もありますが、URLを変えたくない場合は、旧deploymentを編集する手順が適切です。実際に公開されているURL、アクセス権、実行ユーザーの選択を変更する場合は、コード更新と別の変更として影響を確認します。

4. 更新したのに古い動作に見える場合

表は横にスクロールできます

観察次に確認すること
/devでは新しいが/execでは古い利用者が使うversioned deploymentを編集したか
新しいURLだけ新しい既存deploymentと別のdeploymentを更新・作成していないか
一部利用者だけ古い利用者が別URL、別project、別アカウントで開いていないか
Webアプリ応答が変わらない期待するdeployment IDと実際のURLを照合
呼び出し元が古いURLを保持Sheet、サイト、外部サービスの設定元を特定
新versionへ切替後も一部処理が失敗実行ユーザー、アクセス設定、OAuth権限、入力条件を確認

「保存したのに反映されない」という現象だけでキャッシュを原因と決めつけないでください。まずdeploymentが参照するversionと実際の呼び出しURLを確認し、その後にブラウザや呼び出し元のキャッシュを調べます。キャッシュを消したりURL末尾へ任意の値を付けたりする方法は、deploymentのversionを更新する代わりにはなりません。

テスト結果は、画面を一度開いただけでPASSにせず、変更した経路と既存動作の両方で確認します。doGet / doPostの違い、query parameter、ユーザー認証、データ書き込みなど、該当projectのReader Jobに関わる入力で試してください。実データの変更を伴う操作はテスト用データを使い、二重登録や通知送信などの副作用を避けます。ユーザー権限や実行主体に依存するWeb appでは、編集者だけでなく想定利用者のアクセス条件も確認します。

5. 誤更新を避ける公開前チェック

  • 呼び出し元が使うdeployment URLを特定した。

  • 正しいScript projectとactive deploymentを選んだ。

  • test URLと公開URLを区別した。

  • 公開前のdeployment ID・version・アクセス設定を記録した。

  • 更新でアクセス範囲や実行ユーザーを意図せず変えないことを確認した。

  • 新versionを既存deploymentへ設定した。

  • 配布済みURLで変更後動作を確認した。

  • 呼び出し元が別のdeployment URLを保持していないか確認した。

  • 更新前のversionと戻す方法を記録した。

新しいdeploymentを作るべきか既存を更新するべきかは、URLの互換性と利用者への影響で判断します。既存URLを変えずにコードを更新したいなら、既存deploymentのversionを更新するのが標準手順です。公開URLを変える必要があるなら、利用者、呼び出し元、権限設定、旧URLをいつまで維持するかを先に決めます。古いdeploymentが不要に見えても、依存先を確認せずに削除しないでください。

6. 変更を戻すとき

versioned deploymentは、特定のversionを利用者へ提供します。更新後に問題があれば、Manage deploymentsで対象deploymentを確認し、正しいprevious versionへ戻す手順を用意します。Project historyの過去コードを現行プロジェクトへコピーして保存する操作と、deploymentが使うversionを切り替える操作は異なります。

復旧前に、問題のあるdeployment ID、現在version、切り戻すversion、障害が出た入力、データへの副作用、利用者への影響を記録します。データ更新を伴った場合は、versionを戻すだけでデータが元に戻るとは限りません。コードの切り戻しとデータの修復は別に計画します。権限やOAuth認可が変わった場合も、コードを戻すだけで元の認可状態へ戻るとは限らないため確認します。

公式情報と確認範囲

Google for DevelopersのApps Script公式資料を2026-10-15に確認しました。Deploymentsはhead/testとversioned deploymentの違い、active deploymentの編集、既存URL/IDを変えずに新versionへ更新する手順を説明します。Versionsは保存時のコードとdeploymentが異なる概念であること、既存deploymentを更新するにはnew versionを作成してdeploymentを編集することを説明します。Web Appsは/devが編集権限を持つ利用者向けtest deploymentであることを案内します。対象projectの実URL、deployment、権限、アクセス動作は未確認です。

・Create and manage deployments：https://developers.google.com/apps-script/concepts/deployments（新しいタブで開く）

・Versions：https://developers.google.com/apps-script/guides/versions（新しいタブで開く）

・Web Apps：https://developers.google.com/apps-script/guides/web（新しいタブで開く）