GASで「承認が必要です」「アクセスが拒否されました」と表示されたら、まず誰のアカウントで、どの方法から実行しているかを確認します。
同じコードでも、エディターでの実行、トリガー、ウェブアプリでは権限の扱いが異なります。
承認画面が出ない、必要な権限を許可できない、承認したはずなのに失敗する。
この記事では、この3つを分けて確認する手順を説明します。
承認エラーとファイルへのアクセス権は別に確認する
GASがGoogleサービスのデータにアクセスするには、必要な承認が求められます。
一方、承認したユーザーが対象ファイルを閲覧・編集できるかも別の条件です。
スクリプトにスプレッドシートへのアクセスを許可したからといって、他人の非共有ファイルまで扱えるわけではありません。
| 確認するもの | 確認する場所 |
|---|---|
| 実行中のGoogleアカウント | エディター・ブラウザー・ウェブアプリのアカウント表示 |
| 必要な承認スコープ | 承認画面、コードが利用するサービス、マニフェスト |
| 対象ファイルの共有権限 | 同じアカウントで開いたファイルの共有設定 |
| 組織の利用制限 | Google Workspace管理者への確認 |
| トリガーの実行者 | トリガーを作成したアカウント |
表示されたエラー文は、要約する前にそのまま控えます。
「承認が必要」と「ファイルが見つからない」を同じ原因として扱わないことが大切です。
ウェブアプリでは、デプロイ時に選んだ実行者も確認します。
「自分として実行」ならデプロイした側、「アクセスしているユーザーとして実行」なら利用者側の承認とファイル権限を調べます。
後者で利用者に権限がない場合、作成者がエディターから実行できても解決したことにはなりません。
1．複数アカウントの取り違えを確認する
個人用と会社用のGoogleアカウントを同じブラウザーで使っていると、シートを開いているユーザーとスクリプトを実行するユーザーが想定と違う場合があります。
- 使用するアカウントを1つ決める。
- そのアカウントだけでログインしたブラウザープロファイルを開く。
- 対象のスプレッドシートやDriveファイルを開けるか確認する。
- 同じアカウントでApps Scriptを開き、実行する関数を確認する。
Googleのトラブルシューティングでも、複数アカウントへの同時ログインがApps Scriptやウェブアプリへのアクセスに影響する場合が案内されています。Google公式：複数アカウントの問題
ブラウザーを分けて解決した場合も、会社のアカウントに必要なファイル権限があるかを再確認します。
動いた個人アカウントへ業務データを移すことが、正しい解決とは限りません。
2．エディターから承認対象の処理を確認する
コードを変更して新しいGoogleサービスを使うようになると、以前に承認したスクリプトでも追加の承認が必要になることがあります。
たとえば、シートの集計だけだった処理にメール送信を追加した場合です。
まずコードの処理内容を確認し、意図したプロジェクトから実行します。
承認画面ではアプリ名、利用アカウント、要求されるアクセス範囲を読み、必要な権限だけを確認してください。
権限を一部だけ許可した場合、許可されていないサービスを呼び出す処理は失敗することがあります。
プロジェクト左側の「概要」にある「プロジェクトのOAuthスコープ」で、要求する範囲を確認できます。
コードを追加しても承認に反映されなければ、保存してエディターを更新します。
appsscript.jsonでoauthScopesを明示している場合は、新たに利用するサービスの必要スコープが含まれるかも確認します。
なお、関数によっては実行した瞬間にメール送信やデータ更新が始まります。
「承認画面を出すため」だけに、本番の一括送信関数を無確認で動かさないでください。
テスト対象や実行範囲を決めてから操作します。
3．「このアプリは確認されていません」が出た場合
アプリの確認に関する警告は、単なる数式エラーとは異なります。
Googleの確認を受けていないアプリが、機密性のある権限を要求すると表示される場合があります。
自分が作ったスクリプトなのか、社内で管理しているものなのか、外部から渡されたものなのかを区別します。
提供元とコードの処理内容が不明な場合は、警告を無視して進めず、管理者や作成者に確認してください。
他のユーザーへ配布するアプリでは、開発用の承認手順を利用者へ案内するだけで済ませず、公開範囲、OAuth同意画面、必要な審査を整理します。
会社内限定のアプリと一般公開アプリでは、求められる対応が異なります。
4．トリガーでだけ失敗するときは、作成者と権限を確認する
エディターからは動くのに定期実行で失敗する場合、手動で実行したユーザーとトリガーを作ったユーザーが違わないかを確認します。
インストール可能なトリガーは、そのトリガーを作成したアカウントの権限で動きます。
担当者が変わった、アカウントが停止された、ファイルの共有権限が変わったといった運用上の変更も確認対象です。
現在の担当者がファイルを開けるだけでは、以前の担当者が作ったトリガーの権限は確認できません。
トリガーの実行中には承認ダイアログを表示できないため、追加承認が必要なら、作成者のアカウントでエディターを開き、処理範囲を確認した関数を手動実行して承認します。
その後、実際のイベントまたは次の予定実行で結果と実行履歴を確認します。
また、onEdit(e)などのシンプルなトリガーには、承認が必要なサービスの利用制限があります。
関数名を変えたり、実行ボタンを押したりするだけで同じ条件になるとは限りません。
用途に合う実行方式をシンプルなトリガーの公式仕様で確認します。
編集イベントそのものが動いていない可能性もあるため、onEditが動かないときの確認方法と分けて調べましょう。
5．会社のアカウントで拒否される場合
Google Workspaceでは、管理者のポリシーによってアプリやサービスへのアクセスが制限される場合があります。
「個人アカウントなら動く」という結果は、組織側の制限を調べる手掛かりになりますが、そのまま個人アカウントで業務を続ける理由にはなりません。
管理者へは、使用するプロジェクト、必要なGoogleサービス、表示されたエラー、処理の目的を伝えます。
管理者は組織のルールに沿って、承認可能なアプリやスコープを判断します。
Google公式：Apps Scriptのデータアクセス管理
確認が終わったら、同じ実行方法で再テストする
- 意図したアカウントで、対象ファイルへアクセスできる。
- 実際の処理に必要な承認が揃っている。
- 手動実行だけでなく、使用中のトリガーやウェブアプリからも結果を確認した。ウェブアプリのテスト用/dev URLはスクリプト編集権限のあるユーザー専用なので、一般利用者にはデプロイ済みのURLで確認してもらう。
- 不要になったトリガーや古い連携が残っていない。
- 失敗時の通知先と、次の担当者が調べる場所を決めた。
共有ファイルの権限と、アプリへの承認、実行者のアカウントを分けて考えると、どこを直すべきかが見えてきます。
エラー全般の入口が必要な場合は、GASのエラー別の確認方法も参照してください。
