入口のボタンを押しても、GASの管理画面が開かない。そんなときは、起動URL、Google側の転送、画面内リンクを分けて見ると、次に調べる場所を絞れます。この記事では、単独のタブと入口のiframe内で開いた結果を比べ、修正後の確認まで進める手順をまとめます。
わたしが記録している環境では、GASで作った複数のアプリを、ひとつの入口から開けるようにしています。2026年10月19日、その入口のボタンから管理画面へ進むと、表示に失敗する状態を修復しました。
今回、同じChromeのプロファイルで開き方を比べると、通常のURLでは途中で「/u/1/」を含む経路へ転送されて失敗し、ドメインを指定した経路では表示できました。入口に設定した起動URLと、管理画面内のリンクを修復した後は、管理画面の単独表示と、新しい入口のiframe内での表示を確認できています。
ただし、これだけでGoogle側の転送の原因まで確定したわけではありません。スマートフォンの実機でも、まだ確認していません。
この記事では、2026年10月19日の修正で観測できたことと、同じように「リンクを押すと開けない」ときに試せる確認順をまとめます。
入口と管理画面を分けて考える
今回の構成は、複数のアプリを開くための入口と、その先にある管理画面です。入口からは、管理画面をiframeという別のページを表示する枠に読み込む経路があります。管理画面自身にも、別のページへ移動するリンクがあります。
この構成で「開けない」と言われたとき、少なくとも次の場所を分けて見る必要があります。
- 入口のボタンに登録されているURL
- Google側の転送を経た後のURL
- 管理画面が単独のタブで表示されるか
- 入口の枠内でも表示されるか
- 管理画面内のリンクを押した後の移動先
最初の画面が出たとしても、その中のリンクが正しいとは限りません。反対に、入口から失敗しても、管理画面そのものが止まっているとは限りません。
同じブラウザで開き方を比べた
修正時に手がかりになったのは、同じChromeのプロファイルで、URLの経路によって結果が変わったことでした。
通常のURLから開くと、途中で「/u/1/」を含む経路に転送され、その先で表示に失敗しました。一方、ドメインを指定した経路では、同じプロファイルから管理画面を表示できました。
この比較から分かったのは、少なくとも調べた条件では、URLの経路を変えると結果が変わることです。「管理画面がどの経路でも動かない」という状態ではありませんでした。
一方で、「/u/1/が見えたから、このアカウントが原因だ」とは断定できません。今回の記事では、転送された事実と表示結果までを記録しています。Google側がその経路を選んだ理由や、別の端末でも同じ結果になるかまでは確認していません。
以前の記事では、ドメインを含むURLを汎用の形へそろえる方法を紹介しました。ただ、今回の確認では、ドメインを指定した経路で表示できています。過去の対処をすべての環境に当てはめず、利用するアカウントと開き方ごとに確かめる必要がありました。
今回直したところと確認できたところ
今回修復したのは、入口に設定していた管理画面の起動URLと、管理画面内のリンクです。管理画面の更新版はv82です。
改善前は、入口から管理画面へ進む経路で表示に失敗していました。改善後は、修復した経路で管理画面を単独表示でき、新しい入口のiframe内でも表示できることを確認しています。
ここでの確認は、表示に関するものです。管理画面内のすべての操作、すべてのアカウント、すべてのブラウザでの動作確認が済んだ、という意味ではありません。
また、今回の対応を「公開範囲を広げれば解決する」「複数アカウントへの対応が完了した」という手順にはしません。表示を直すために何を変えるのかと、誰に利用を許可するのかは、分けて確かめます。
同じ症状を調べるための確認順
ここからは、今回の観測をもとにした切り分けの手順です。自分が管理しているアプリか、確認を許可されている環境で行ってください。設定を一度に何か所も変えず、比較する条件を一つずつ変えると、どの変更が効いたのかを追いやすくなります。
1 入口に設定されたURLを控える
まず、入口のボタンが実際にどこを開こうとしているかを確認します。表示されているボタン名だけで判断せず、設定されたリンク先と、本来開きたいデプロイのURLを比べます。
確認するのは、対象のアプリ、デプロイ、末尾のパス、ページ指定のパラメータです。たとえば説明用の「/exec?page=settings」なら、アプリのURLだけでなく「page=settings」も含めて見ます。この例には実際の設定値やIDは入れていません。
なお、開発用の「/dev」は、編集権限を持つ人が最新の保存済みコードを試すためのURLです。利用者向けの確認と混ぜないようにします。Google公式のWebアプリガイドでも、この用途の違いが説明されています。
2 同じプロファイルで単独表示を試す
入口を経由せず、目的の管理画面を同じブラウザの別タブで開きます。まずはブラウザやログイン状態を変えず、入口を経由するかどうかだけを変えます。
- 単独でも失敗する場合は、デプロイ先、ログイン、利用許可なども確認候補になります。
- 単独では開くのに入口の枠内で失敗する場合は、埋め込み方や遷移先を追加で調べます。
- 入口からも単独でも開くのに、画面内のリンクだけ失敗する場合は、そのリンクのURLと開く先を確認します。
これは原因を決める表ではありません。次にどこを見るかを絞るための分け方です。
3 押す前のURLと転送後のURLを分けて記録する
失敗した画面では、最初に指定したURLと、ブラウザのアドレス欄に残ったURLをそれぞれ控えます。今回なら、通常のURLから「/u/1/」を含む経路へ変わったことが比較材料になりました。
入口がiframeを使う場合、アドレス欄に見えるのは入口側のURLです。枠の中で使われたURLと同じとは限りません。単独表示の結果と、入口に設定された枠の読み込み先を別々に記録します。
共有する記録では、実際のドメイン、メールアドレス、デプロイID、トークンや秘密のパラメータを除きます。URLをそのまま質問サイトへ貼る必要はありません。「通常の経路で失敗、組織のドメインを指定した経路で表示」のような説明でも、比較した内容は残せます。
4 ログイン条件を変える試験は別に行う
Google公式のトラブルシューティングでは、複数のGoogleアカウントへ同時にログインする状態は、Apps ScriptやそのWebアプリでサポートされていないと説明されています。問題が起きる場合の確認方法として、対象アカウントだけでログインすることや、シークレットウィンドウを使う方法が案内されています。公式の複数アカウントに関する説明
そのため、同じプロファイル内でのURL比較を終えた後に、対象アカウントだけで開いた結果も別に確認します。ここで成功しても、普段の複数ログイン環境まで直ったとは記録しません。
今回のドメイン指定経路での成功も、その環境で確認できた結果です。複数アカウントの制約を解消する一般的な方法としては扱いません。
5 画面内リンクのURLと開く先を見る
管理画面が表示されたら、次は画面内のリンクです。移動先を指定するURLに加えて、リンクをどの枠やタブで開くかを決めるtargetも確認します。
GoogleのHTML Serviceはiframeによる制限を持ち、公式資料ではリンクのtargetに「_top」または「_blank」を指定する説明があります。「_top」は最上位の画面への移動、「_blank」は新しいタブなどの閲覧先を指定します。ユーザーがリンクを押したとき、ページ全体を移動させたいのか、別の閲覧先を開きたいのかを、画面の設計と合わせて確認します。HTML Serviceの制限
「?page=settings」のような相対URLを使う場合も、どのURLを基準に解決されるのかを見る必要があります。入口、埋め込まれた画面、別タブでは、期待する移動先が同じとは限りません。
ただし、targetを書き換えるだけで、ログインや利用許可の問題まで直るわけではありません。URL、表示する枠、認証の結果を分けて確認します。
6 変更を反映した後に同じ経路をたどる
修正したコードや設定を保存したら、利用者が開くデプロイに反映されていることを確認します。開発中のコードが動くことと、いつもの入口から新しい版を開けることは別です。
バージョン付きデプロイを更新する場合は、新しいバージョンを作り、既存のデプロイが参照する版を編集する手順が公式に案内されています。既存デプロイのURLを維持したまま更新できますが、入口側に登録したURLがそのデプロイを指しているかも確認します。デプロイの作成と管理
反映後は、最初に失敗した入口から、同じ順番で操作します。単独のタブだけで確認を終えず、実際の入口、画面内リンク、戻る動作も確認対象にします。書き込みを伴うボタンは、本番データを変えてよい範囲を決めてから試してください。
更新後に残しておく確認表
次の項目を、成功、失敗、未確認のいずれかで記録しておくと、次の更新時に比較できます。空欄を成功として数えないことが大切です。
- 確認日時と対象のデプロイ版
- ブラウザとプロファイルの条件
- アカウントが一つだけの状態か、複数ログイン状態か
- 管理画面を単独のタブで開いた結果
- 入口のiframe内で開いた結果
- 画面内リンクから移動した結果
- 再読み込みと戻る操作の結果
- 許可されていないアカウントを拒否すること
- スマートフォン実機での表示と操作
今回確認できたのは、修復後の管理画面の単独表示と、新しい入口のiframe内での表示です。スマートフォン実機、すべてのアカウント条件、すべての画面内操作は、この記録では確認済みに含めていません。
小さな更新でも再現できる記録を残す
今回の更新は、新しい機能を大きく増やしたものではありません。入口から管理画面へ進むURLと、画面内のリンクを修復した記録です。
それでも、「どこから開くと失敗したか」「同じ条件で何を変えると表示できたか」「修正後はどこまで確認したか」を残せば、次に似た症状が起きたときの手がかりになります。
同じようにGASの画面が開けないときは、まず、入口を経由した場合と単独表示を比べてみてください。そのうえで、URLの転送、画面内リンク、ログイン条件を一つずつ分けて確かめると、調べる場所を絞れます。
認証の実行ユーザーと管理権限の設計については、管理画面とAPIの実行ユーザーを分けた記録にまとめています。今回の表示経路の問題とは分けて読むための関連記事です。
本稿の図は、確認する場所を整理した説明図です。実運用画面のスクリーンショットや、今回の動作確認を撮影した実画像ではありません。
コメント