GASの権限承認エラー｜原因別の確認と対処

GAS（Google Apps Script）の権限承認エラーが出たら、止まった画面と実行方法を分けて確認します。初回の承認、Googleサービスを追加したあとの再承認、対象ファイルの共有、トリガーの制限では、対処する場所が違います。トリガーは時刻やシートの操作などをきっかけに処理を自動実行する仕組みです。

まずエラーメッセージ、実行した関数、使ったGoogleアカウントを控えてください。コードやシートの共有範囲を変える前に、どの権限が不足しているかを調べます。この記事ではGoogle公式資料を基に確認順を整理し、シートを書き換えない読み取り用の例を示します。

GASの承認エラーで見分ける6つの症状

同じ「権限がない」という表示でも、原因は一つではありません。承認画面で止まるのか、処理の途中で失敗するのかを確認すると、調べる範囲を絞れます。

Authorization is required to perform that action. は承認状態を調べる手がかりです。ただし、エラーメッセージだけで原因を決めず、手動・トリガー・Webアプリのどれから実行したかも合わせます。表示文言や画面の順序は利用環境によって異なります。

GASの初回承認と再承認の手順

Googleサービスを使うスクリプトは、必要に応じてユーザーの承認を求めます。初回の承認と、コード変更後の再承認を分けて確認してください。

① 実行するプロジェクトと関数の確認

対象のApps Scriptプロジェクトを開き、上部の関数一覧から実行したい関数を選びます。別のスプレッドシートに紐付くプロジェクトや、以前作ったテスト用の関数を開いていないかを確かめます。複数のGoogleアカウントを使っている場合は、エディタを開いているアカウントも確認します。

コードを保存して手動実行し、承認の案内が出たら要求される権限を読みます。メール送信のない処理でGmailの権限を求められるなど、想定と違う場合はコードやライブラリを確認してください。内容を確認していないコードの権限をそのまま許可しないことが判断の基準です。

② 新規テスト用シートでの読み取り確認

次は新規のテスト用スプレッドシートから「拡張機能」→「Apps Script」で開いたプロジェクトに置く例です。シートの値を変更せず、データがある最終行の番号だけをログへ出します。既存の業務用コードへ混ぜず、確認用のプロジェクトで使ってください。

/**
 * @OnlyCurrentDoc
 */
function checkCurrentSheetAccess() {
  const spreadsheet = SpreadsheetApp.getActiveSpreadsheet();
  if (!spreadsheet) {
    throw new Error('テスト用スプレッドシートからApps Scriptを開いてください。');
  }
  const sheet = spreadsheet.getActiveSheet();
  console.log('データのある最終行: ' + sheet.getLastRow());
}

関数一覧から checkCurrentSheetAccess を選び、手動で実行します。必要な承認が終わり、空のシートを読み取れた場合の想定ログは データのある最終行: 0 です。セルに値がある場合は、その最終行番号になります。セルの内容やファイルIDはログへ出していません。

@OnlyCurrentDoc は、対応するサービスについて現在のファイルに必要な権限へ範囲を絞る注釈です。他のファイルを開く処理へ一律に追加するものではありません。既存の処理が必要とする範囲とは分けて考えます。仕様はGoogle公式の承認ガイドで確認できます。

③ サービス追加後の再承認

シート集計へメール送信を追加するなど、コードが新しいサービスを使うようになると、以前の承認だけでは足りなくなる場合があります。変更した関数をエディタから手動実行し、新たに必要となる権限を確認します。共有者やトリガーの作成者が別の人なら、その実行者側の承認状態も調べます。

実行アカウント・スコープ・共有の確認

OAuthの承認と、ファイルの共有設定は別の確認項目です。必要な権限を承認していても、実行者が対象ファイルへアクセスできなければ処理は失敗します。

必要なスコープと部分的な同意

スコープは、スクリプトがGoogleのデータを扱う範囲です。通常はコードから必要な範囲が判断されますが、マニフェストの appsscript.json に oauthScopes を明記している場合は、その設定も確認します。新しいサービスを追加したのに必要なスコープが含まれていない場合、再承認だけでは解決しません。

同意画面で一部の権限だけを許可した場合は、許可した範囲で動く機能と、動かない機能が分かれることがあります。失敗する機能と、その機能が使うサービスを照合してください。エラーが消えるまで広いスコープを足す方法は、不要なデータへのアクセスも増やします。必要範囲の考え方はGoogle公式のスコープ解説が参考になります。

対象ファイルと実行者の照合

コードが指定するファイルを、実行するGoogleアカウントで開けるか確認します。ブラウザで見えているファイルとコード内のIDが違う場合や、別アカウントだけに共有している場合もあります。スクリプトの共有者と、処理対象ファイルの共有者が同じとは限りません。

Webアプリからの実行では、デプロイ時に設定した実行主体も関係します。自分の手動実行が成功したことだけで、すべての利用者も同じ権限で実行できるとは判断できません。対象ファイルを広く公開する前に、どのアカウントで処理が動く設定かを確かめます。

手動実行とトリガーの権限の違い

手動実行と自動実行では、承認画面を出せる条件や実行者が違います。「手動では成功する」だけではトリガーでも動く確認になりません。

シンプルトリガーの制限

onOpen(e) や onEdit(e) などのシンプルトリガーは承認が必要なサービスを利用できません。たとえば、メニューを追加する処理と、Gmailでメールを送る処理では条件が違います。一度エディタで手動承認しても、シンプルトリガー自体の制限がなくなるわけではありません。

シンプルトリガーにもスクリプトに紐付くファイルの操作など、許される範囲があります。Gmailの送信や他のファイルへのアクセスと、紐付くシートで許される操作を分けて確認してください。

制限に該当するなら、処理をメニューから呼び出す構成や、用途に合うインストール型トリガーを検討します。選ぶ前に、自動で動かす必要がある処理と、利用するサービスを整理してください。制限の詳細はGoogle公式のシンプルトリガーガイドにあります。

インストール型トリガーの作成者と再承認

インストール型トリガーはそのトリガーを作成したアカウントの権限で動きます。ファイルを共有している別の人の手動実行が成功しても、作成者の承認やアクセス権が不足していれば自動実行は失敗します。どのアカウントがトリガーを作ったかを確認します。

バックグラウンドの実行中には足りない権限の承認画面を出せません。コード変更で新しい権限が必要になったときは、作成者がエディタから対象関数を手動実行し、必要な権限を承認します。その後のトリガー実行結果を確認してください。トリガーを増やすだけでは承認不足の解決にはなりません。

未確認アプリとWorkspace組織のブロック

「このアプリは確認されていません」という案内と、Workspace組織によるアクセス制限は分けて扱います。自分で判断できる範囲と、開発者や管理者の対応が必要な範囲を確認します。

発行元・コード・要求権限の確認

未確認アプリの案内が出た場合は、発行元、コードの内容、要求される権限が想定どおりかを確認してください。知らない発行元のアプリに、警告を無視して進む案内は適用しません。自分で開発したアプリでも、使うスコープや公開対象によってOAuth検証の要否が変わります。

外部の利用者へ配布する開発者は、Google公式のOAuthクライアント検証ガイドで要件を確認します。利用者側のクリック手順だけで、アプリの検証状態が変わるわけではありません。

Workspace管理者へ伝える情報

会社や学校のGoogle Workspaceでは、管理者がアプリのデータアクセスを制限できます。組織によるブロックは、個人の再承認だけでは解決しない場合があります。アプリ名、必要なサービス、エラー文、実行した日時をまとめて管理者へ確認します。

相談時の画面共有には認証コード、アクセストークン、個人情報を含めないでください。組織の制限を避けるために業務データを個人アカウントへ移すのではなく、Google公式のアプリアクセス制御に沿って、許可できる用途と範囲を確認します。

承認後も失敗するGAS｜実行履歴からの切り分け

承認が済んでも処理が失敗する場合は、エディタの「実行数（Executions）」で該当する実行を開きます。発生日時、関数名、実行の種類、最初のエラーをまとめて確認し、承認以外の原因も調べます。

• どのアカウント・実行方法で失敗したか
• 直前の変更でサービス、対象ファイル、関数名を変えていないか
• 承認前と承認後で、同じエラーが出ているか
• ファイルがない、名前が違う、利用上限に達したなど、別の原因が出ていないか

複数の設定をまとめて変えると、どの変更で結果が変わったか追えなくなります。確認した項目と結果を残し、一つずつ条件を変えてください。ログに書く情報と実行履歴の見方は、GASのエラーログを確認する方法で詳しく説明しています。

GASの権限承認に関するFAQと関連記事

承認の判断に迷うときは、誰が、どの方法で、何のデータを扱うかへ戻って確認します。手動実行の成功と、共有者やトリガーでの成功は分けて確かめます。

実行するたびに承認は必要ですか？

同じユーザーが承認済みの範囲で使う場合、通常は毎回の承認は必要ありません。新しいサービスの追加や、承認の取り消しなどがあれば、再承認が必要になる場合があります。毎回求められるときはアカウントと要求スコープの変化を確認してください。

作成者が承認すれば共有者も使えますか？

実行方法で異なります。エディタから実行する共有者には、その人自身の承認が必要になる場合があります。インストール型トリガーは作成者、Webアプリはデプロイ設定に応じた実行主体で動くため、プロジェクトの共有だけで承認が引き継がれるとは考えません。

権限を確認したあとは何を見ますか？

まず対象の1回の実行結果を確認し、その後でトリガーや共有者からの実行を確かめます。GASの実行方法を整理したい場合はGASの基本と始め方へ、メニューから画面を開く処理を作りたい場合はHTML Serviceでサイドバーを作る方法へ進んでください。

仕様の確認日は2026年10月31日です。承認画面の説明はGoogle公式資料に基づき、特定のアカウントでのエラー解消やトリガー成功を実測した記録ではありません。