目次
「開発中は問題なく動いていたのに、お客様の環境では途中で止まる」——これは自動化の現場でよく起きる、そして原因の特定に時間を取られやすいトラブルです。
先日の実案件（匿名）でも、まさにこれに当たりました。GASで作ったWebアプリ（Webブラウザから開いて使う仕組み）が、開発者のアカウントでは完璧に動くのに、顧客ドメインのアカウントで開くと途中で無言で失敗する。しかもエラーメッセージが一切出ないため、真因にたどり着くまでに遠回りをしました。
この記事では、その原因だったGAS WebAppの「誰の権限で実行するか（executeAs）」という設定について、何が起きたか、どう切り分けるべきだったか、そして今後同じ轍を踏まないための判断表とチェックリストを整理します。
GAS WebAppには「実行者の権限」の設定がある
GASで作ったWebアプリを公開（デプロイ）するとき、そのプログラムを誰の権限で動かすかを選ぶ設定があります。これがexecuteAsで、選択肢は2つです。
- USER_ACCESSING：アプリを開いた人（利用者）の権限で実行する
- USER_DEPLOYING：アプリをデプロイした開発者の権限で実行する
見た目には同じアプリでも、この設定次第で「誰のアカウントの権限を使ってファイルやサービスにアクセスするか」が変わります。ここが今回のトラブルの震源でした。
なお、GASやデプロイ画面の仕様は変わることがあるため、最新の設定項目や名称は必ず公式ドキュメントで確認してください。
何が起きたか：エラーが出ないまま失敗する
事象を整理するとこうです。
- 開発者アカウントでアプリを開く → 最後まで完璧に動く
- 顧客ドメインのアカウントで同じアプリを開く → 途中で無言で失敗する
やっかいだったのは、エラーが表示されないことでした。処理が止まっているのに理由が画面に出ないため、「特定の入力で重複判定に引っかかっているのでは」「データの形式が違うのでは」といった、まったく別の仮説を立てて迷走してしまいました。
原因を絞りきれないまま、動く条件と動かない条件を比べていくと、共通していたのは誰が開いたかだけでした。ここでようやく実行者の権限を疑い始めました。
真因：利用者のトークンでは、開発者側のリソースを通れなかった
このアプリには、開発者側のGCP（Google Cloud）に用意した Vertex AIのOCR（画像から文字を読み取る処理）を呼ぶ工程がありました。そしてデプロイ設定は USER_ACCESSING（開いた人の権限で実行）になっていました。
つまり、こういう構図です。
OCRの実体は開発者のアカウント側にあるリソースです。ところがUSER_ACCESSING設定のため、実際にアクセスしにいくのは顧客のトークン（認証情報）。顧客のアカウントには、その開発者側リソースへの権限がありません。結果、認証を通れずに止まっていた——これが真因でした。
開発者アカウントで動いていたのは当然で、自分のリソースに自分の権限でアクセスしていただけだったのです。「本番で動かない」ではなく「本番の実行者では権限が足りない」という話でした。
教訓1：オーナー専用リソースを使うならUSER_DEPLOYING一択
今回のように、自社のGCP・自社のDrive・自社で用意したAPIなど、開発者（オーナー）だけが権限を持つリソースを処理の中で使う場合、答えは明確です。
利用者ではなく開発者の権限で実行する（USER_DEPLOYING）にしないと、利用者側に権限がないため必ず止まります。逆に、利用者本人のファイルやメールだけを扱うアプリなら、利用者の権限で動くUSER_ACCESSINGが適切です。判断の軸は「処理の中で触るリソースは誰のものか」です。
| 処理内容 | 使うリソース | 適した設定 |
|---|---|---|
| 自社GCP・自社DriveのAPIを呼ぶ | オーナー専用 | USER_DEPLOYING |
| 開いた人自身のGmail・Driveを操作 | 利用者本人 | USER_ACCESSING |
| 誰が使っても同じ結果を返す（オーナー資産を利用） | オーナー専用 | USER_DEPLOYING |
| 利用者ごとに扱う権限・データが変わる | 利用者本人 | USER_ACCESSING |
教訓2：「開発では動く・本番では動かない」は実行者の権限をまず疑う
エラーが出ないまま止まる事象で、私たちは重複判定やデータ形式を先に疑い、遠回りしました。今回の反省は、「開発では動くのに本番では動かない」という切り分けでは、実行者の権限を最初に確認するということです。
このパターンでは、プログラムのロジックそのものは正しいことが多く、動く／動かないの境目が「誰が実行しているか」に一致するのが典型的なサインです。ロジックを疑う前に、実行者の権限（executeAs設定）を先に確認していれば、切り分けは大幅に短縮できました。
教訓3：実機テストは本番想定のアカウントで行う
そもそもの予防策は単純です。テストを開発者アカウントだけで済ませないこと。
開発者アカウントは、開発の都合上あらゆるリソースに権限を持っています。そのアカウントで動作確認をしても、「利用者の権限で足りるか」は永遠に検証できません。実機テストは、必ず本番で実際に使う側（顧客側）のアカウントで行う——これが今回の一番の学びです。開発では見えない権限の壁は、本番想定のアカウントを通したときに初めて姿を現します。
executeAsの選び方チェックリスト
導入・改修の前に、次の順で確認します。
- 処理の中で触るリソースを洗い出す：自社GCP・自社Drive・自社APIなど「オーナー専用」か、利用者本人のGmail・Driveか。
- executeAsを決める：オーナー専用リソースを使う工程が1つでもあればUSER_DEPLOYING。利用者本人のデータだけならUSER_ACCESSING。
- 本番想定のアカウントでテストする：開発者アカウントだけの確認で終わらせない。顧客側の権限で最後まで通ることを確かめる。
- 無言で止まる事象は権限を最初に疑う：エラーが出ないまま、かつ動く／動かないが「誰が開いたか」で分かれるなら、実行者の権限を確認する。
この順番なら、「開発では動くのに本番で動かない」という時間泥棒のトラブルを、設計段階で避けられます。
まとめ
- GAS WebAppには誰の権限で実行するか（executeAs）の設定があり、USER_ACCESSING（利用者の権限）とUSER_DEPLOYING（開発者の権限）の2種類がある
- 自社GCP・自社Driveなどオーナー専用リソースを使う処理はUSER_DEPLOYING一択。利用者の権限では認証を通れず、エラーも出ないまま止まることがある
- 「開発では動く・本番では動かない」の切り分けでは、実行者の権限を最初に疑う
- 実機テストは必ず本番想定（顧客側）のアカウントで行う
- 各サービスの仕様は変わるため、設定項目や認証まわりの最新情報は公式で確認する
RENOYでは、GASを使った業務自動化の設計・開発から、本番環境で確実に動くところまでの伴走を行っています。「開発では動いたのに現場で止まる」といったトラブルの切り分けや、権限まわりを見据えた設計のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。