お知らせ・ブログ一覧へ戻る

GASのWebアプリURLをそのまま配ってはいけない|自社ドメイン経由にする構成とURL変更に強い運用


GASのWebアプリURLをそのまま配ってはいけない|自社ドメイン経由にする構成とURL変更に強い運用

GASのWebアプリURLをそのまま配ってはいけない|自社ドメイン経由にする構成とURL変更に強い運用

Google Apps Script(GAS)でWebアプリを作ると、https://script.google.com/macros/s/.../exec という長いURLが発行されます。発注フォームや日報入力など、店舗スタッフに使ってもらう業務ツールをこのURLのまま配っている会社は多いはずです。

結論から書きます。GASのWebアプリURLを現場に配るなら、script.google.com の直リンクは配らず、自社ドメインの固定URLを入口にしてください。 さらに、その固定URLは「GASへ転送するだけ」では足りません。自社ドメイン内で画面を配信し、送信だけをサーバー間でGASへ渡す構成にしておくのが正解です。

理由は2つあります。1つ目は、スマホでscript.google.comのリンクを開くとGoogleドライブアプリに横取りされ、「ファイルを開くことができません」と表示されて何も起きない既知の問題があること。2つ目は、GASは「新しいデプロイ」を作った時点でURLが変わり、配布済みのリンクが全滅することです。どちらも、配る相手が多いほど被害が大きくなります。

この記事では、名古屋の白髪染め専門サロンFC(21店舗)の発注フォームで実際に組んだ構成をもとに、なぜ直リンクを配ってはいけないのか、転送方式ではなぜ直らなかったのか、どう組めばURLを二度と変えずに済むのかを、手順と判断基準まで書きます。

結論:配るのは自社ドメインの固定URL、GASは裏で動かす

配布する構成は次の形です。

店舗のLINE・QRコード
  → https://自社ドメイン/order.php?s=店舗コード   ← 配るのはこれだけ
  → 自社サーバーがGASから店舗別フォームのHTMLを取得し、自社ドメインで表示
  → 送信ボタン → 自社サーバー → GASの doPost → スプレッドシート記録・メール送信

利用者のブラウザは、最初から最後まで自社ドメインの中にいます。script.google.com へは一度も遷移しません。GASはあくまで裏側のデータ処理とメール送信を担当します。

この形にすると、次の3つが同時に手に入ります。

  • URLが変わらない。GASを作り直してURLが変わっても、サーバー側の転送先を1か所直すだけで、店舗に配ったリンクとQRコードはそのまま使えます
  • スマホのドライブ横取りが起きない。端末側はscript.google.comのURLに触れないので、誤ルーティングの余地がありません
  • 表示側の改修にGASの再デプロイが要らない。価格表示や色分けなど、画面の見せ方はサーバー側で変えられます

「転送(リダイレクト)で自社ドメインを挟むだけ」との違いは後述しますが、先に言っておくと、転送方式は横取り問題を解決しません。

なぜ script.google.com の直リンクを配ってはいけないのか

理由1:スマホのGoogleドライブアプリが横取りする

Googleアカウントの設定もデプロイ設定も正しいのに、特定のスマホでだけ「ファイルを開くことができません」というドライブアプリの画面が出て、フォームが表示されない。これはGASのコードやアクセス権の問題ではなく、端末側でscript.google.comのURLがドライブアプリに誤って渡される既知の不具合です。Googleの公開バグトラッカーにも同じ症状が登録されています。複数のGoogleアカウントでログインしている端末で、URLに /u/1/ のようなアカウント番号が勝手に付き、同じエラーになるケースもあります。

厄介なのは、再現しない環境の方が多いことです。PCでは開ける。未ログインのブラウザでも開ける。サーバーからcurlで叩けばHTTP 200が返る。デプロイ設定は「全員(匿名ユーザーを含む)」で正しい。開発側で確認できることはすべて正常なのに、現場の一部のスマホだけで開けない。「設定は正しい」と「使える」は別物だ、という典型例です。

理由2:「新しいデプロイ」でURLが変わる

GASのWebアプリは、同じデプロイIDのまま「新バージョン」を発行すればURLは変わりません。しかし、誰かが「新しいデプロイ」を押した瞬間に別のURLが発行され、以前のURLは古いコードのまま取り残されます。この違いはGAS開発でデプロイの急所を解説した記事に書いたとおりですが、配布の観点ではもっと深刻です。

LINEのグループトークに送ったリンクは、あとから差し替えられません。レジ横に貼ったQRコードも同じです。URLが変わったら、全店舗に「新しいリンクに変えてください」と再周知することになります。21店舗なら21回、それぞれの店で古いリンクを使い続ける人が出ます。

理由3:配布先が多いほど、直せない場所が増える

直リンクを配るということは、「変えられない場所」にURLを埋め込むことです。グループLINEのメッセージ、印刷したQRコード、スタッフのホーム画面のブックマーク。これらは一度配ったら回収できません。だから、配るURLは最初から「二度と変えないURL」にしておく必要があります。それができるのは自社ドメインだけです。

実例:21店舗の発注フォームで、転送方式では直らなかった

名古屋の白髪染め専門サロンFCで、各店舗の商材発注をGASのWebアプリに載せ替えました。店舗ごとに専用URLを発行し、各店のグループLINEに配布。フォームで商品と数量を選んで送信すると、スプレッドシートに記録され、仕入先別に発注メールが自動で飛ぶ構成です。

起こりうる症状:設定は正しいのに、一部のスマホで開けない

この構成でまず想定しておくべきなのが、前述のドライブ横取りです。実際、配布後に「リンクを押してもドライブのエラーが出る」という報告が出ました。確認したのは次の点です。

  • デプロイの公開設定は「全員」=未ログインを含む匿名アクセス可
  • Cookieなしのcurlで本番URLはHTTP 200・リダイレクト0回
  • 未ログインのブラウザで店舗別フォーム(商品一覧・送信ボタン)まで正常表示
  • スプレッドシートに載せた店舗別URLは全件、現行デプロイIDの /exec?s=店舗コード 形式

すべて正常でした。念のため同じデプロイIDのまま新バージョンを発行して再デプロイしても、症状は変わりません。ここで、GASのコード・公開設定・再デプロイのどれを触っても直らない=端末側の誤ルーティングだと切り分けられます。

落とし穴:自社ドメインからGASへ「転送」しても直らない

最初に試すことになるのが、自社ドメインに固定URLを置き、GASのURLへ転送する方式です。店舗コードをホワイトリストで検証し、正しいコードだけGASへ転送、不明なコードは404を返す。21店舗すべてHTTP 200、LINEアプリ内ブラウザのUser-Agentでも200。ここまでは合格に見えます。

しかし実機では直りませんでした。入口が自社ドメインでも、最終的に script.google.com へ画面が遷移する以上、端末側の横取りは避けられないからです。転送方式は「URLを変えない」目的には効きますが、「スマホで開けない」問題には効きません。ここを勘違いすると、「直した」と報告したあとに同じ報告が返ってきます。

正解:自社ドメイン内で画面を配信し、送信だけをサーバー間でGASへ渡す

最終的に採った構成は次のとおりです。

  1. GAS側に doPost の受付口を追加し、共有トークンを検証したうえで既存の送信処理を呼ぶ。同じデプロイIDのまま新バージョンとして更新(URLは不変)
  2. 自社ドメインの中継スクリプト(PHP)を全面変更。GASが生成する店舗別フォームのHTMLをサーバー側で取得し、自社ドメインから直接配信する
  3. 送信は、ブラウザ → 自社サーバー → GASの doPost というサーバー間通信に変更。利用者の画面は script.google.com へ一度も遷移しない

固定URLは転送方式のときと同じものを使い続けたので、スプレッドシートの店舗別URL一覧も、各店への再共有一覧も、変更する必要がありませんでした。

検証したのは、21店舗すべてでHTTP 200・リダイレクト0回であること、店舗名・商品一覧・送信ボタンが自社ドメインのまま表示されドライブエラーが出ないこと、そして送信経路が「担当者名を入力してください」という既存のバリデーションまで到達すること(発注ログとメール送信は発生させずに確認)です。LINEアプリ内ブラウザのUser-Agentでの200は転送方式の段階で確認済みでした。切り替えの翌日には、店舗からの実際の発注がこの固定URL経由で届き始めています。curlで200が返るだけでは合格にしない。今回の症状はcurlでは再現しないからです。

副次効果:画面の改修をGASの再デプロイなしで進められた

自社ドメイン側で画面を配信する形にしたことで、その後の改修が楽になりました。商品ごとの税込単価と小計、配送グループ別の合計、税抜3万円未満なら「送料必要」・以上なら「送料無料」のバッジ表示、数量を入れた行の色反転。これらはすべてサーバー側で実装し、GAS本体には触っていません。Apps Scriptのエディタを開けない状況でも、要望が出たその日のうちに反映できました。

ただし副作用もあります。単価をサーバー側にも持たせたため、商品マスタ(スプレッドシート)とサーバー側の価格表の二重管理になりました。単価を変えるときは両方を同時に更新するルールを暫定で置いています。恒久策はGASから単価を渡す改修ですが、それまでは「片方だけ直す」事故を防ぐ運用が必要です。

配布:固定URLを一度だけ再共有し、QRコードも固定URLで作る

過去に配ったscript.google.comのリンクは消せないので、固定URLを各店に一度だけ再共有しました。あわせて店舗名入りのQRコードを21枚作成し、印刷物としても配布できるようにしています。QRコードは全件を機械で読み取り直し、スプレッドシートの店舗別URLと21件すべて一致することを確認してから配りました。QRコードのリンク先を読み出して突き合わせる手順は別記事にまとめています。

実装の手順と、転送で足りるかどうかの判断基準

手順

  1. GASは「同じデプロイIDのバージョン更新」で運用する。「新しいデプロイ」は押さない。誰が触っても迷わないよう、更新手順を1枚に書いて共有しておく
  2. GASに doPost を追加し、共有トークンで呼び出し元を検証する。中継サーバー以外からの送信は受け付けない
  3. 自社ドメインに中継スクリプトを置く。店舗コードはホワイトリスト方式にし、不明なコードは404。外部URLを受け取る仕組みにしない(オープンリダイレクトを作らない)
  4. 画面はサーバー側で取得して自社ドメインから配信し、送信はサーバー間で渡す
  5. 検証は「全店舗URLが200・リダイレクト0回・スマホのUser-Agentで200・実機で開ける」の4点。実発注が発生しない形で送信経路も通す

転送で足りる場合、足りない場合

配る相手・配り方 転送方式 自社ドメイン内完結
PCの社内担当者だけ、口頭で伝えられる 十分 過剰
スマホで使う現場スタッフ 不十分(横取りが残る) 必要
LINEグループ・QRコード・印刷物で配布 URL固定には効く 必要
画面の見せ方を頻繁に変えたい 効かない 有利

URLを固定したいだけなら転送で足ります。スマホで、しかも回収できない場所に配るなら、自社ドメイン内で完結させてください。

設計時に決めておくこと

  • 単価やマスタをサーバー側にも持たせるか。持たせるなら二重管理のルールを先に決める
  • GAS側の直URLを緊急用に控えておく。中継サーバーが落ちたときの逃げ道になる
  • 中継スクリプトのバックアップ。改修のたびに日付付きで残しておくと、戻せる

起こりうるリスクと予防策

「設定は正しいのに開けない」報告が来たときの初動。デプロイ設定やコードを疑う前に、その人が実際に押したURLを文字列のまま取得し、現行のURLと完全一致で比較してください。スプレッドシートの共有URL、テスト用の /dev URL、旧デプロイのURL、途中で欠けたURLのいずれかであることも多いです。完全一致していて開けないなら端末側の問題です。

転送方式で「直った」と思い込む。curl・PC・未ログインブラウザで200が返っても、実機で確認するまで完了にしないでください。今回の症状は開発環境では再現しません。

中継サーバーが単一障害点になる。GASの直URLを控えておき、サーバー障害時はそちらを臨時で案内する手順を決めておきます。

GAS側の検証を中継が迂回する。中継はGASの入力チェックを代替するものではありません。トークン検証を入れ、GAS側のバリデーション(必須項目・重複送信判定など)は残したままにします。

配布済みリンクは回収できない。だからこそ最初から自社ドメインで配ります。すでに直リンクを配ってしまっている場合は、固定URLへの再共有を「一度だけ」やり、その後は変えない運用に切り替えてください。

まとめ

  • GASのWebアプリURL(script.google.com)を現場のスマホに直接配ると、ドライブアプリの横取りで開けない問題と、再デプロイでURLが変わる問題に当たる
  • 配るのは自社ドメインの固定URL。ただし転送するだけでは横取り問題は直らない
  • 正解は、自社ドメイン内で画面を配信し、送信だけをサーバー間でGASの doPost へ渡す構成。URLは二度と変えずに済み、画面の改修もGASの再デプロイなしで進められる
  • 検証はcurlの200で終わらせず、スマホのUser-Agentと実機まで確認する
  • 単価などをサーバー側にも持たせるなら、二重管理のルールを先に決める

GASは業務ツールを素早く作れる反面、「配る」段階の設計が抜けがちです。作る前に、URLを誰に・どこに・どう配るかを決めておくと、あとから全店舗に再周知する事態を避けられます。

よくある質問

Q. 転送(リダイレクト)方式でも、URLを固定する目的なら十分ですか?

十分です。GASを作り直してURLが変わっても、転送先を1か所直すだけで済みます。ただしスマホで開けない問題には効かないので、現場スタッフがスマホで使うツールなら、自社ドメイン内で画面を配信する構成にしてください。

Q. 自社ドメイン側にPHPなどのサーバーが必要ですか?

必要です。共用レンタルサーバーで動くPHPで足ります。画面をサーバー側で取得して配信し、送信をGASへ渡すだけなので、特別な環境は要りません。

Q. すでにscript.google.comのURLを配ってしまいました。どうすればいいですか?

固定URLを用意したうえで、各店舗へ「一度だけ」再共有してください。古いリンクは回収できないので、しばらくは両方が使える状態にしておき、以後は固定URLだけを案内します。QRコードも固定URLで作り直します。

関連記事

2026.09.18

店舗写真は縮小表示で判断しない|サムネイルでは見えない旧店名・旧ロゴの写り込みと、公開前に等倍で確認する箇所

2026.09.17

AIに書かせた文章に英語が混ざるときの止め方|プロンプトで直さず出力側で落とす設計と、店名のローマ字を巻き込まない条件

2026.09.17

公開前の商品をマスタに登録するときは表示側を先に用意する|有効フラグだけでは画面に出てしまう経路と、伏せたまま準備する順番


お知らせ・ブログ一覧へ戻る