「さっきまで普通に動いていたアドオンが、急に『承認が必要です』って言い出した……」そんな経験、ありませんか？ Googleスプレッドシートのアドオンを使おうとしたら、突然エラーが出て作業が止まってしまう。しかも英語で「Authorization is required to perform that action」なんて表示されると、もう何が何だかわからなくなりますよね。
安心してください。この記事を読めば、初心者でも迷わずにGoogleSheetsアドオンの承認エラーを解決できます。さらに、2026年に入って大きく変わったGoogleの認証システムの最新情報もしっかりカバーしているので、今後同じトラブルに悩まされることもなくなります。
- GoogleSheetsアドオンで「承認が必要です」エラーが発生する原因と、すぐに試せる7つの解決策の全手順
- 2026年に導入された「きめ細かいOAuth同意画面」や「Rhinoランタイム廃止」など最新の認証仕様変更への対応方法
- 複数アカウント問題・ポップアップブロック・権限スコープなど、見落としがちな落とし穴と予防策
- そもそもなぜGoogleSheetsのアドオンで「承認が必要です」と表示されるのか？
- 原因その1複数のGoogleアカウントでログインしている問題
- 原因その2初回承認のプロセスが正しく完了していない
- 原因その3ブラウザのポップアップブロックやCookieの設定
- 原因その42026年最新の「きめ細かいOAuth同意画面」への対応
- 原因その5Rhinoランタイム廃止に伴うスクリプトの動作停止
- 原因その6WEBアプリとしてデプロイしたスクリプトの認証切れ
- 原因その7Google Workspace管理者によるAPIの制限
- 情シス歴10年超の現場で実際に遭遇した「承認エラー沼」と脱出法
- 現場で即使えるGASプログラムコード集
- 「このアプリはブロックされています」が出たときの裏技的対処法
- トリガー実行時の承認エラーを未然に防ぐ設計パターン
- 「@OnlyCurrentDoc」アノテーションの威力と落とし穴
- 承認エラーのデバッグで知っておくべき実行ログの読み方
- 組織でGASを安全に運用するための「承認ガバナンス」の作り方
- 承認エラーを完全回避するためのChromeプロファイル運用術
- ぶっちゃけこうした方がいい！
- GoogleSheetsアドオンの承認エラーに関するよくある疑問解決
- 今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？
- まとめ
そもそもなぜGoogleSheetsのアドオンで「承認が必要です」と表示されるのか？
Googleスプレッドシートのイメージ
まず最初に、このエラーが表示される仕組みを理解しておきましょう。難しく考える必要はありません。要するに「このアドオンがあなたのGoogleアカウントのデータにアクセスしていいですか？」という確認が、まだ済んでいない（もしくは無効になった）状態なのです。
Googleはユーザーのセキュリティとプライバシーを非常に重視しています。そのため、アドオンやGoogle Apps Script（GAS）がスプレッドシートの中身を読み書きしたり、Gmailを操作したり、Googleドライブにファイルを作ったりするには、あなた自身が「許可します」とはっきり承認するプロセスが必要です。この承認が完了していなければ、スクリプトは一切動作せず、画面にエラーが表示されるというわけです。
ただし厄介なのは、一度承認したはずなのに再びエラーが出るケースがかなり多いということ。これにはいくつかの明確な原因があります。順番に見ていきましょう。
原因その1複数のGoogleアカウントでログインしている問題
実はこれが、GoogleSheetsアドオンの承認エラーで最も多い原因です。仕事用と個人用など、複数のGoogleアカウントに同時ログインしている方は非常に多いと思いますが、ここに大きな落とし穴があります。
Googleのアドオン認証は、ブラウザで最初にログインした「デフォルトアカウント」を基準に動作します。つまり、あなたが2番目や3番目にログインしたアカウントでスプレッドシートを開いていても、アドオンの認証は最初のアカウントで実行されようとするのです。この「アカウントのズレ」が原因で承認エラーが発生します。
これはGoogle Issue Trackerでも長年報告され続けている既知の問題で、2026年3月現在もまだ完全には解消されていません。ブラウザの仕様上、Googleが複数アカウントでのアドオン認証をうまく処理しきれていないのが根本的な原因です。
複数アカウント問題の解決手順
この問題を解決する方法はいくつかありますが、最も確実なのは以下の手順です。
- Chromeのアドレスバーに
accounts.google.comと入力してGoogleアカウント管理ページを開き、右上のアイコンから「すべてのアカウントからログアウト」をクリックします。
- 一度ブラウザを完全に閉じてから再起動し、アドオンを使いたいGoogleアカウントだけで最初にログインします。これにより、そのアカウントがデフォルトアカウントとして設定されます。
- その状態でGoogleスプレッドシートを開き、アドオンを実行すると、正常に承認画面が表示されて認証を完了できます。
もうひとつの方法として、Chromeの「ゲストウィンドウ」を使う手もあります。Chromeの右上にあるプロフィールアイコンをクリックし、「ゲストウィンドウを開く」を選択すれば、完全にクリーンな状態でログインできます。シークレットウィンドウ（Ctrl+Shift+N）でも代用可能ですが、ゲストウィンドウのほうがより確実です。
原因その2初回承認のプロセスが正しく完了していない
初めてアドオンやGASスクリプトを実行するとき、Googleは「このアプリは確認されていません」という少し怖い警告画面を表示することがあります。特に個人が開発したアドオンや、会員サイトからコピーしたスプレッドシートに埋め込まれたスクリプトでは、ほぼ必ずこの画面に遭遇します。
ここで多くの初心者が戸惑ってしまい、認証を中断してしまうのです。でも、自分が信頼できるソースから入手したスクリプトであれば、以下の手順で問題なく認証を進められます。
「このアプリは確認されていません」の突破方法
- スクリプトを実行すると「承認が必要です」というポップアップが表示されるので、「権限を確認」をクリックします。
- Googleアカウントの選択画面が表示されたら、スプレッドシートを所有しているアカウント（普段使っているアカウント）を選択します。
- 「このアプリはGoogleで確認されていません」という警告画面が出たら、左下にある「詳細」（英語表記なら「Advanced」）をクリックします。
- 展開されたテキストの中にある「（プロジェクト名）（安全ではないページ）に移動」というリンクをクリックします。
- 要求されている権限の一覧が表示されるので、内容を確認したうえで「許可」をクリックすれば承認完了です。
一度この認証を完了すれば、通常は同じスクリプトで再度承認を求められることはありません。ただし、スクリプトに新しい機能が追加されて必要な権限が増えた場合や、後述する「きめ細かいOAuth同意」の仕様変更に伴い、再承認が必要になるケースもあります。
原因その3ブラウザのポップアップブロックやCookieの設定
意外と見落とされがちですが、ブラウザの設定が原因でGoogleSheetsアドオンの承認プロセスが失敗するケースも少なくありません。具体的には、ポップアップブロッカーが承認画面の表示を妨げている場合と、サードパーティCookieが無効になっている場合の2つが主な原因です。
Googleの認証ライブラリは、サードパーティCookieとデータストレージの有効化を必須としています。Chromeの最近のプライバシー強化に伴い、初期設定でサードパーティCookieがブロックされている環境も増えています。もし承認画面が全く表示されない場合は、Chromeの設定画面から「プライバシーとセキュリティ」→「サードパーティCookie」を開き、少なくとも
accounts.google.com
を例外として追加してください。
ポップアップブロックについても同様です。Chromeのアドレスバーに
chrome://settings/content/popups
と入力し、Googleのドメインに対してポップアップを許可する設定を追加しましょう。
原因その42026年最新の「きめ細かいOAuth同意画面」への対応
ここからは、2025年から2026年にかけてGoogleが段階的に導入している認証システムの大きな変更について解説します。この変更を知らないと、今まで問題なく使えていたアドオンで突然エラーが発生する可能性があります。
従来のGoogleの認証は「全部許可するか、全部拒否するか」の二択でした。たとえばアドオンが「スプレッドシートの読み書き」と「Gmailの送信」の2つの権限を要求している場合、両方まとめて許可するしかなかったのです。ところが、2025年1月から段階的に導入された「Granular OAuth Consent（きめ細かいOAuth同意）」では、ユーザーが権限をひとつずつ個別に許可または拒否できるようになりました。
この変更は段階的に展開されています。
| 展開フェーズ | 対象 | 開始時期 |
|---|---|---|
| フェーズ1 | Apps Script IDE（スクリプトエディタ）での直接実行 | 2025年1月 |
| フェーズ2 | 公開済みのエディタアドオン（Sheets、Docs、Slidesなど） | 2025年12月 |
| フェーズ3 | 公開済みのウェブアプリとGoogle Workspaceアドオン | 2026年1月7日 |
| フェーズ4 | Google Chatアプリ（Apps Script製） | 2026年1月20日 |
この仕様変更が原因で、ユーザーが一部の権限だけを許可し、必要な権限を拒否してしまった結果、アドオンが正しく動作せずエラーになるケースが増えています。もし承認画面でチェックボックスが表示された場合は、そのアドオンが必要とするすべての権限にチェックを入れて許可するようにしましょう。
アドオン開発者の立場から見ると、この変更は非常に重要です。ユーザーが一部の権限を拒否しても、アプリが完全にクラッシュするのではなく、機能を段階的に制限しながら動作し続けるように設計する必要があります。具体的には、
ScriptApp
クラスや
AuthorizationInfo
クラスのメソッドを使って、どの権限が許可されているかをプログラム的にチェックするコードを実装しましょう。
原因その5Rhinoランタイム廃止に伴うスクリプトの動作停止
2026年に入ってから「今まで動いていたスクリプトが突然動かなくなった」という報告が急増しています。その原因として見逃せないのが、Google Apps ScriptのRhinoランタイムの廃止です。
Google Apps Scriptには「Rhino」と「V8」という2つの実行エンジンがありました。RhinoはJavaScriptの古い規格（ES5）をベースにした旧式のエンジンで、V8はChromeやNode.jsで使われている最新のエンジンです。Googleは2025年2月にRhinoの非推奨を正式に発表し、2026年1月31日以降、Rhinoランタイムで動作するスクリプトは実行されなくなりました。
これは承認エラーとは直接異なりますが、症状が似ているため混同されがちです。スクリプトが突然動かなくなり、「承認が必要です」に似たエラーメッセージが表示されるケースもあります。もしあなたが使っているアドオンやスクリプトが古いもので、最近まったく更新されていないのであれば、Rhinoランタイムのままである可能性を疑ってください。
V8への移行確認方法
自分のスクリプトがどちらのランタイムで動いているか確認するのは簡単です。スクリプトエディタを開き、左側の歯車アイコン「プロジェクトの設定」をクリックします。そこに「Chrome V8ランタイムを有効にする」というチェックボックスがあります。これがオンになっていればV8で動作しています。オフの場合はチェックを入れて保存するだけでV8に切り替わりますが、古いコードには互換性の問題がある可能性もあるため、切り替え後は必ず動作確認を行ってください。
特に注意が必要なのは、
for each...in
構文や、
Date.prototype.getYear()
、
const
変数の再代入など、Rhinoでは許容されていたがV8では動作しない書き方です。ネット上で見つけた古いGASのコードをコピーして使っている方は、V8移行後にエラーが出る可能性が高いので注意しましょう。
原因その6WEBアプリとしてデプロイしたスクリプトの認証切れ
Google Apps ScriptをWEBアプリとして公開（デプロイ）している場合、特有の承認エラーが発生することがあります。たとえば、会員サイトからコピーしたスプレッドシートにGASが埋め込まれていて、それをWEBアプリとして使うケースです。
デプロイとは、スクリプトにURLを発行して外部からアクセスできるようにする仕組みです。デプロイされたWEBアプリにアクセスすると、
https://script.google.com/macros/s/ランダムなID/exec
のようなURLが発行されます。このURLにブラウザからアクセスすると、スクリプトの機能がWEBサービスとして利用可能になります。
問題は、以前の承認が取り消された場合や、Googleアカウントのセキュリティ設定を変更した場合、ファイルの共有権限が変更された場合に、認証が無効になることです。この場合は、スクリプトエディタを開いて手動で関数を実行し、再度承認フローを完了させる必要があります。その後、デプロイを「新しいバージョン」として再公開すれば、承認エラーは解消されます。
デプロイの再公開を行う際は、「実行者」を「自分」に、「アクセスできるユーザー」を目的に合わせて「全員」または「全員（匿名含む）」に設定することを忘れないでください。この設定が不適切だと、外部からのアクセス時に権限エラーが発生し続けます。
原因その7Google Workspace管理者によるAPIの制限
企業や学校などのGoogle Workspaceアカウントを使っている場合、組織の管理者がDrive APIやApps Scriptの利用を制限しているケースがあります。この場合、個人の設定では解決できないため、IT管理者に問い合わせる必要があります。
Google Workspaceの管理者はドメイン全体でDrive APIを無効にする権限を持っており、この設定が有効になっていると、Driveサービスを使用するアドオンはインストール済みであっても動作しません。ただし、管理者がドメイン全体へのインストールとして承認したアドオンであれば、この制限の影響を受けずに機能します。
もしあなたが組織のアカウントを使っていて、個人のGmailアカウントでは問題なくアドオンが動作するのに組織アカウントではエラーが出る場合は、ほぼ確実にこの管理者制限が原因です。
情シス歴10年超の現場で実際に遭遇した「承認エラー沼」と脱出法
Googleスプレッドシートのイメージ
ここからは、私が企業の情報システム部門で10年以上にわたって対応してきた「現場でしか知り得ないトラブル事例」をお話しします。ネットで検索して出てくるような一般的な情報ではなく、実際にユーザーから問い合わせを受けて、泥臭く調査して、やっと原因がわかった……というリアルな体験です。
正直なところ、GoogleSheetsのアドオン承認エラーの問い合わせは「またか」と思うくらい定期的にやってきます。しかも、同じエラーメッセージなのに原因が毎回微妙に違う。これが情シス泣かせなんですよね。特に困るのが、ユーザーから「昨日まで動いてたのに今日動かない」と言われるパターン。再現性がないように見えるので、調査にものすごく時間がかかります。
朝イチだけ動かないトリガーの謎
ある日、経理部門から「毎朝8時に自動実行されるはずのスクリプトが、月曜日だけ動かない」という相談を受けました。火曜から金曜は問題なく動く。月曜だけ失敗する。最初はGoogleのサーバー側の問題かと思いましたが、調べていくうちに原因がわかりました。
その経理担当者は、金曜の夜にGoogleアカウントのパスワードを定期変更していたのです。パスワードを変更すると、OAuthトークンが無効化されることがあります。トリガーはスクリプト作成者のアカウント権限で動くため、パスワード変更によってトークンが失効し、月曜朝のトリガー実行が失敗していたわけです。火曜以降は、月曜にスプレッドシートを開いた時点で再認証が走るので復活する。このサイクルが毎週繰り返されていました。
対処法としては、パスワード変更後にスクリプトエディタを開いて任意の関数を手動実行し、再承認フローを完了させること。これだけで月曜問題は解消しました。地味ですが、こういうのは経験しないと絶対にわかりません。
共有スプレッドシートで「誰の権限で動いてるの？」問題
もうひとつ、企業でよくあるのが共有スプレッドシートに埋め込まれたGASの「権限主体」が曖昧になるケースです。たとえば、Aさんがスプレッドシートを作成してスクリプトを書き、トリガーを設定した。その後Aさんが退職して、Googleアカウントが無効化された。するとどうなるか？ トリガーはAさんのアカウント権限で実行されるため、アカウント無効化と同時にすべてのトリガーが死にます。
これは本当によくあるパターンで、引き継ぎが不十分だと「ある日突然、全部動かなくなった」という大惨事になります。対策としては、スクリプトのオーナーを組織のサービスアカウントや共有アカウントに移管しておくか、退職者が出る前にトリガーを別のアカウントで再作成しておく必要があります。後述するGASコードで、現在のトリガー一覧を定期的にチェックする仕組みを入れておくと安心です。
現場で即使えるGASプログラムコード集
ここでは、承認エラーの予防や診断に役立つ実践的なGASコードを複数紹介します。コピーしてそのまま使えるように書いていますが、必ず自分の環境に合わせて動作確認してから本番運用してください。
承認状態を自動チェックして通知するスクリプト
「きめ細かいOAuth同意」が導入された2026年以降、ユーザーが一部の権限だけ許可するケースが増えました。以下のスクリプトは、現在のスクリプトに必要な権限がすべて付与されているかをチェックし、不足があればログに出力するものです。
function checkAuthorizationStatus() {
var authInfo = ScriptApp.getAuthorizationInfo(ScriptApp.AuthMode.FULL);
var status = authInfo.getAuthorizationStatus();
if (status === ScriptApp.AuthorizationStatus.REQUIRED) {
var authUrl = authInfo.getAuthorizationUrl();
Logger.log("追加の承認が必要です。以下のURLで承認してください:");
Logger.log(authUrl);
// メールで通知する場合
MailApp.sendEmail(
Session.getActiveUser().getEmail(),
"【要対応】GASスクリプトの再承認が必要です",
"以下のURLにアクセスして権限を承認してください:\n" + authUrl
);
} else {
Logger.log("すべての権限が正常に承認されています。");
}
}
このスクリプトを時間ベースのトリガーで毎朝実行するように設定しておけば、承認切れに気づかないまま業務が止まるリスクを大幅に減らせます。ただし、注意点がひとつ。トリガー実行時には承認ダイアログを画面に表示できないため、メール通知でURLを送る形にしています。ユーザーがそのURLをクリックして承認フローを完了させる必要がある点だけ覚えておいてください。
きめ細かいOAuth同意に対応した権限チェックコード
2026年のGranular OAuth Consent導入以降、スクリプトが要求するすべてのスコープが許可されているとは限らなくなりました。次のコードは、特定のスコープが許可されているかを個別にチェックして、許可されていないスコープがあれば該当機能だけをスキップする実装例です。
function safeExecuteWithScopeCheck() {
// スプレッドシートのスコープを確認
var sheetAuth = ScriptApp.getAuthorizationInfo(
ScriptApp.AuthMode.FULL,
);
// Gmailのスコープを確認
var gmailAuth = ScriptApp.getAuthorizationInfo(
ScriptApp.AuthMode.FULL,
);
// スプレッドシートの処理
if (sheetAuth.getAuthorizationStatus() === ScriptApp.AuthorizationStatus.NOT_REQUIRED) {
var ss = SpreadsheetApp.getActiveSpreadsheet();
var sheet = ss.getActiveSheet();
sheet.getRange("A1").setValue("処理完了: " + new Date());
Logger.log("スプレッドシートの更新に成功しました。");
} else {
Logger.log("警告: スプレッドシートへのアクセス権が許可されていません。");
}
// メール送信の処理
if (gmailAuth.getAuthorizationStatus() === ScriptApp.AuthorizationStatus.NOT_REQUIRED) {
GmailApp.sendEmail("admin@example.com", "処理報告", "正常に完了しました。");
Logger.log("メール送信に成功しました。");
} else {
Logger.log("警告: Gmail権限が許可されていないため、メール送信をスキップしました。");
}
}
このパターンは、アドオン開発者だけでなく、社内ツールとしてGASを運用している方にも強くおすすめします。「権限が足りなければ落ちる」のではなく「権限が足りない部分だけスキップする」という設計思想は、2026年のGAS開発における必須のベストプラクティスです。
トリガーの棚卸しと再作成を自動化するスクリプト
先ほど触れた「退職者のトリガーが残っている問題」を未然に防ぐために、現在設定されているすべてのトリガーを一覧表示し、不要なものを削除して再作成するスクリプトです。
function auditAndResetTriggers() {
var triggers = ScriptApp.getProjectTriggers();
Logger.log("現在のトリガー数: " + triggers.length);
// 既存トリガーの情報をログに出力
triggers.forEach(function(trigger) {
Logger.log("関数名: " + trigger.getHandlerFunction());
Logger.log("イベントタイプ: " + trigger.getEventType());
Logger.log("トリガーID: " + trigger.getUniqueId());
Logger.log("");
});
// すべて削除して再作成する場合（実行前に十分確認してください）
// triggers.forEach(function(trigger) {
// ScriptApp.deleteTrigger(trigger);
// });
// createFreshTriggers();
}
function createFreshTriggers() {
// 毎日午前8時に実行するトリガーを作成
ScriptApp.newTrigger("dailyProcess")
.timeBased()
.atHour(8)
.everyDays(1)
.create();
Logger.log("新しいトリガーを作成しました。");
}
このスクリプトのポイントは、トリガーの削除と再作成を分離していることです。本番環境でいきなりトリガーを全削除すると大惨事になりかねないので、まず
auditAndResetTriggers
でログを確認し、問題がないことを確かめてからコメントアウト部分を有効にして再作成する、という二段階の運用をおすすめします。
権限スコープを最小化するマニフェスト設定
承認エラーのリスクを根本的に減らすもうひとつの方法が、マニフェストファイルでスコープを明示的に制限することです。GASは初期状態ではスクリプト内のコードをスキャンして自動的にスコープを判定しますが、この自動判定はしばしば過剰な権限を要求してしまいます。
スクリプトエディタの左側メニューから「プロジェクトの設定」を開き、「”appsscript.json”マニフェストファイルをエディタで表示する」にチェックを入れると、マニフェストファイルを直接編集できるようになります。以下は、スプレッドシートの現在のドキュメントのみにアクセスするよう制限した設定例です。
{
"timeZone": "Asia/Tokyo",
"dependencies": {},
"exceptionLogging": "STACKDRIVER",
"runtimeVersion": "V8",
"oauthScopes": [
"https://www.googleapis.com/auth/spreadsheets.currentonly",
"https://www.googleapis.com/auth/script.scriptapp"
]
}
ここで特に注目してほしいのが
spreadsheets.currentonly
というスコープです。これは「すべてのスプレッドシート」ではなく「このスクリプトが紐づいているスプレッドシートだけ」にアクセス権を限定するスコープで、ユーザーにとってもはるかに安心感があります。コード内で
/** @OnlyCurrentDoc */
というJSDocアノテーションを先頭に記述するだけでも同等の効果が得られますが、マニフェストで明示指定するほうがより確実です。
スコープを手動設定する場合の注意点として、スクリプトが必要とするすべてのスコープを漏れなく記載する必要があります。ひとつでも足りないと、そのサービスを使おうとした瞬間にエラーが発生します。自動検出に頼らない分、責任は自分にあるということですね。
「このアプリはブロックされています」が出たときの裏技的対処法
承認画面で「このアプリは確認されていません」ではなく、さらに厳しい「このアプリはブロックされています」（This app is blocked）というメッセージが出る場合があります。これは特に個人のGmailアカウント（@gmail.com）でスクリプトを実行しようとしたときに発生しやすく、「詳細」リンクをクリックしても先に進めないという、完全に行き止まりに見える状態です。
この問題の根本原因は、スクリプトがGoogleのデフォルトのCloud Platformプロジェクトを使っていることにあります。解決方法は、Google Cloud Console（console.cloud.google.com）で自分専用のGCPプロジェクトを作成し、そのプロジェクトをApps Scriptに紐づけることです。
具体的な手順としては、まずGoogle Cloud Consoleにアクセスして新規プロジェクトを作成します。次にそのプロジェクトで「OAuth同意画面」を設定し、アプリ名やサポートメールなどの基本情報を入力します。ユーザータイプは「外部」を選択します。その後、Apps Scriptのスクリプトエディタに戻り、「プロジェクトの設定」からGCPプロジェクト番号を入力して紐づけを完了させます。これで「ブロック」が解除され、通常の「確認されていません」の警告に変わり、「詳細」から先に進めるようになります。
ちなみにこの手法は、Google Workspace（旧G Suite）のアカウントでは不要なケースが多いです。組織のドメイン内であれば管理者が信頼済みアプリとして設定できるためです。しかし個人のGmailアカウントで自作スクリプトを使いたい場合は、この手順を知っているかどうかで天と地ほどの差が出ます。
トリガー実行時の承認エラーを未然に防ぐ設計パターン
情シスとして一番頭を抱えるのが、トリガー（自動実行）で動いているスクリプトの承認切れです。手動実行なら承認ダイアログが表示されますが、トリガー実行では画面に何も出ずにサイレントに失敗します。気づいたときには何日分ものデータ処理が止まっていた……なんてことも珍しくありません。
この問題を構造的に防ぐために、私が現場で実際に導入しているのが「トリガー実行前の承認プリチェック」パターンです。以下のコードでは、トリガーで実行されるメイン関数の冒頭で権限チェックを行い、問題があれば処理をスキップしてアラートを飛ばすようにしています。
function dailyProcess() {
try {
// 必要なスコープの承認状態を事前チェック
ScriptApp.requireScopes(ScriptApp.AuthMode.FULL, [
"https://www.googleapis.com/auth/spreadsheets",
"https://www.googleapis.com/auth/script.scriptapp"
]);
// ここにメインの処理を記述
var ss = SpreadsheetApp.openById("あなたのスプレッドシートID");
var sheet = ss.getSheetByName("データ");
// ... 実際のデータ処理 ...
Logger.log("日次処理が正常に完了しました。");
} catch (e) {
Logger.log("エラー発生: " + e.message);
// 承認エラーの場合はメールで管理者に通知
if (e.message.indexOf("Authorization") !== -1
|| e.message.indexOf("承認") !== -1) {
try {
MailApp.sendEmail(
"admin@yourcompany.com",
"【緊急】GAS承認エラー発生",
"日次処理で承認エラーが発生しました。\n" +
"スクリプトエディタを開いて再承認してください。\n\n" +
"エラー内容: " + e.message
);
} catch (mailError) {
Logger.log("メール送信も失敗: " + mailError.message);
}
}
}
}
このコードの肝は、try-catchの中にさらにtry-catchを入れているところです。なぜなら、承認エラーが発生している状態ではメール送信の権限も失効している可能性があるからです。外側のcatchで承認エラーを捕まえ、内側のtryでメール送信を試み、それもダメならログだけ残す。この「二重防御」は現場運用では本当に大事です。
さらに、
requireScopes
メソッドは2025年以降に追加された比較的新しい機能で、指定したスコープが未承認の場合にユーザーに承認を促すプロンプトを自動的に表示してくれます。ただし、トリガー実行中はプロンプトを表示できないため、トリガーのインストール時に
requireScopes
を呼び出しておくのがベストプラクティスです。こうすることで、トリガーが実際に動く前に必要な権限が確保された状態になります。
「@OnlyCurrentDoc」アノテーションの威力と落とし穴
GASの承認エラーを減らすうえで、実はもっとも手軽で効果的な方法のひとつが、スクリプトの先頭に
/** @OnlyCurrentDoc */
と書くことです。たった1行ですが、この効果は絶大です。
通常、GASがスプレッドシートのデータにアクセスする際は「ユーザーのすべてのGoogleスプレッドシートを閲覧・編集する」という広範な権限を要求します。これはユーザーにとって少し怖い要求ですし、組織のセキュリティポリシーに引っかかることもあります。しかし
@OnlyCurrentDoc
を付けると、要求される権限が「このスクリプトが紐づいているスプレッドシートだけを閲覧・編集する」に限定されます。
ただし落とし穴があります。このアノテーションを使うと、別のスプレッドシートを
SpreadsheetApp.openById()
で開く操作ができなくなります。複数のスプレッドシート間でデータをやり取りするスクリプトには使えないので、自分のスクリプトが何をしているのかをきちんと把握したうえで導入してください。「とりあえず付けておけばいい」というものではありません。
承認エラーのデバッグで知っておくべき実行ログの読み方
承認エラーが発生したとき、多くの人は画面に表示されるメッセージだけを見て対処しようとします。しかし情シスの視点から言うと、本当に有益な情報はApps Scriptの実行ログにあります。
スクリプトエディタの左側メニューにある「実行数」（Executions）をクリックすると、過去のすべての実行記録とそのステータスが確認できます。ここで「失敗」のステータスになっている実行をクリックすると、エラーメッセージの詳細やスタックトレースが表示されます。
承認関連のエラーでよく見かけるメッセージには、いくつかのパターンがあります。「Authorization is required to perform that action.」は先述の通り複数アカウント問題やトリガーの承認切れが原因です。「You do not have permission to access the requested document.」はファイルの共有設定の問題。「Exception: ScriptError」の後に「Authorization」の文字がある場合は、スコープ不足やきめ細かいOAuth同意で一部権限が拒否されているケースを疑ってください。
また意外と知られていないのが、Google Cloud Consoleのログエクスプローラを使ったデバッグです。Apps Scriptのプロジェクトに紐づいたGCPプロジェクトのログエクスプローラを開くと、Apps Scriptの実行ログよりもさらに詳細な情報が確認できます。特にOAuth認証フローのどの段階で失敗しているかがわかるので、複雑な承認エラーのトラブルシューティングには欠かせないツールです。
組織でGASを安全に運用するための「承認ガバナンス」の作り方
ここからは少し上級者向けの話になりますが、企業や組織でGASを大規模に使っている場合、承認エラーを「起きてから対処する」のではなく「起きないように仕組み化する」ことが重要です。私が実際に構築して運用している「承認ガバナンス」のフレームワークを共有します。
スクリプト台帳の作成と定期棚卸し
まず基本中の基本として、組織内で稼働しているGASスクリプトの一覧（台帳）を作成します。台帳には最低限、スクリプト名、紐づいているスプレッドシートのURL、オーナーアカウント、トリガーの種類と実行タイミング、最終更新日、使用しているOAuthスコープを記録します。
これを四半期に一度は棚卸しして、オーナーが退職・異動していないか、不要なスクリプトが残っていないかを確認します。面倒に思えるかもしれませんが、ある日突然「経理の月次処理が全部止まった」というインシデントを経験すると、この台帳のありがたみが身にしみてわかります。
Rhinoからの移行漏れを一括チェックする方法
2026年1月31日にRhinoランタイムが廃止されたにもかかわらず、移行を忘れているスクリプトがまだ組織内に潜んでいる可能性があります。Google Workspaceの管理者には、影響を受けるスクリプトの一覧がCSVファイルとしてメールで送られているはずですが、そのメールを見逃している管理者も少なくありません。
確認方法としては、Google Workspace管理コンソールの「セキュリティ」→「APIの管理」からApps Scriptの監査ログを確認するか、各スクリプトのマニフェストファイル（
appsscript.json
）で
"runtimeVersion"
の値が
"V8"
になっているかをチェックします。もし
"DEPRECATED_ES5"
という値が設定されている、またはruntimeVersionの記載自体がない場合は、そのスクリプトはRhinoのまま放置されている可能性が高いです。
承認エラーを完全回避するためのChromeプロファイル運用術
最後に、ユーザー側で実践できる最も根本的な予防策をお伝えします。それはGoogleアカウントごとに別々のChromeプロファイルを作成することです。
多くの人が「ひとつのChromeウィンドウで複数のGoogleアカウントを切り替えて使う」という運用をしていますが、これがアドオン承認エラーの最大の温床です。Chromeのプロファイル機能を使えば、完全に独立した環境として各アカウントを運用できます。
設定方法は簡単です。Chromeの右上にあるプロフィールアイコンをクリックして「追加」を選びます。新しいプロファイルが作成されたら、そこでGoogleアカウントにログインします。こうすることで、仕事用アカウントは仕事用プロファイル、個人用アカウントは個人用プロファイルと完全に分離されます。アドオンの承認はそのプロファイルのアカウントで処理されるため、デフォルトアカウント問題が構造的に発生しなくなります。
ブックマークや拡張機能もプロファイルごとに独立しているので、仕事とプライベートの境界も明確になります。一石二鳥どころか一石三鳥の方法です。情シスとしてユーザーに案内する場合も、「ログアウトしてログインし直してください」よりも「Chromeプロファイルを分けてください」のほうが説明しやすく、再発防止にもなります。
ぶっちゃけこうした方がいい！
ここまで読んでくれた方に、情シス10年超の経験から本音を言わせてもらいます。
ぶっちゃけ、GoogleSheetsのアドオン承認エラーで一番効率的な対処法は、「Chromeプロファイルを分ける」「スクリプトのスコープを最小限にする」「トリガーには必ずtry-catchとメール通知を仕込む」の3つを最初からやっておくこと。これだけで、承認エラーに関する問い合わせの8割は消えます。断言します。
実際のところ、承認エラーって「仕組みを理解しているかどうか」で対応のスピードが10倍くらい変わるんですよ。知らないと「エラーが出た→再インストール→また出た→もう使うのやめよう」ってなりがちですが、知っていれば「あ、複数アカウントか」「あ、スコープ不足か」って30秒で原因が特定できる。この記事で解説した内容を一度頭に入れておくだけで、今後のGAS運用がびっくりするほどスムーズになるはずです。
それと、2026年はGASの認証まわりが本当に激動の年です。Rhinoの廃止、きめ細かいOAuth同意のフェーズ3・4の展開、さらにはMapsサービスのクライアントID廃止（2026年5月）など、変更が立て続けに来ています。「今まで動いていたから大丈夫」という考えは捨てたほうがいい。動いているスクリプトこそ定期的にメンテナンスすべきです。
最後にひとつだけ。GASのスクリプトは「誰かが作って終わり」じゃなくて、「組織の資産として継続的に管理するもの」です。台帳を作る、オーナーを明確にする、トリガーの棚卸しをする。こういう地味な作業をサボると、いつか必ず痛い目を見ます。逆に言えば、ここをちゃんとやっている組織は、GASを驚くほど強力な業務改善ツールとして使いこなせる。承認エラーとの戦いは、実はGAS運用の成熟度を測るバロメーターなんです。ぜひ、この記事の内容を武器にして、承認エラーに振り回されない運用体制を作ってみてください。
このサイトをチップで応援
GoogleSheetsアドオンの承認エラーに関するよくある疑問解決
一度承認したのにまた「承認が必要です」と表示されるのはなぜ？
いくつかの原因が考えられます。最も多いのは前述の複数アカウント問題です。それ以外にも、アドオンの開発者がスクリプトを更新して新しい権限スコープを追加した場合や、あなたがGoogleアカウントのセキュリティ設定ページからアプリの連携を取り消した場合、OAuth認証トークンの有効期限が切れた場合などに再承認が求められます。また2026年からは「きめ細かいOAuth同意」の導入に伴い、新しい権限の追加時に承認画面が再表示されるようになりました。これは正常な動作なので、慌てずに権限を確認して再度許可してください。
「承認が必要です」エラーが出てアドオンのメニュー自体が表示されない場合は？
アドオンのメニューが表示されないケースは、トリガーの問題である可能性が高いです。Google Apps Scriptでは、スクリプトがトリガー（時限実行やスプレッドシートを開いたときに自動実行される設定）経由で動作する場合、承認ダイアログを画面上に表示できません。その結果、承認が完了していないスクリプトがトリガーで起動しようとして失敗し、メニューの表示すらできなくなるのです。この場合は、スプレッドシートのメニューから「拡張機能」→「Apps Script」でスクリプトエディタを開き、任意の関数を手動で実行して承認フローを完了させてください。
開発者として自分のアドオンを公開する際に承認エラーを防ぐにはどうすればいい？
アドオン開発者が特に注意すべきポイントは3つあります。まず、必要最小限の権限スコープだけをリクエストすること。マニフェストファイル（
appsscript.json
）で明示的にスコープを指定し、自動検出による過剰な権限要求を防ぎましょう。次に、2025年末から展開された「きめ細かいOAuth同意」に対応し、ユーザーが一部の権限を拒否してもアプリが優雅に機能を縮小できるように設計すること。そして最後に、RhinoランタイムではなくV8ランタイムで開発すること。Rhinoはすでに廃止されており、きめ細かいOAuth同意もV8でしか利用できません。
シークレットモードで試しても承認エラーが出続ける場合は？
シークレットモードでもダメな場合は、アカウント自体の問題かスクリプト側の問題が疑われます。まず別のGoogleアカウントで同じスプレッドシートにアクセスして試してみてください。それでも解決しない場合は、スクリプト内で使用しているライブラリのバージョンが原因の可能性があります。スクリプトエディタでインポートされたライブラリが「HEAD（開発版）」で参照されていないか確認し、もし開発版になっていれば、バージョン番号を指定したデプロイ済みのバージョンに変更することで問題が解消するケースが報告されています。
今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？
いま、あなたを悩ませているITの問題を解決します！
「エラーメッセージ、フリーズ、接続不良…もうイライラしない！」
あなたはこんな経験はありませんか？
✅ ExcelやWordの使い方がわからない💦
✅ 仕事の締め切り直前にパソコンがフリーズ💦
✅ 家族との大切な写真が突然見られなくなった💦
✅ オンライン会議に参加できずに焦った💦
✅ スマホの重くて重要な連絡ができなかった💦
平均的な人は、こうしたパソコンやスマホ関連の問題で年間73時間（約9日分の働く時間！）を無駄にしています。あなたの大切な時間が今この悩んでいる瞬間も失われています。
LINEでメッセージを送れば即時解決！
すでに多くの方が私の公式LINEからお悩みを解決しています。
最新のAIを使った自動応答機能を活用していますので、24時間いつでも即返信いたします。
誰でも無料で使えますので、安心して使えます。
問題は先のばしにするほど深刻化します。
小さなエラーがデータ消失や重大なシステム障害につながることも。解決できずに大切な機会を逃すリスクは、あなたが思う以上に高いのです。
あなたが今困っていて、すぐにでも解決したいのであれば下のボタンをクリックして、LINEからあなたのお困りごとを送って下さい。
ぜひ、あなたの悩みを私に解決させてください。
まとめ
GoogleSheetsアドオンの「承認が必要です」エラーは、原因さえ特定できれば決して難しい問題ではありません。この記事で紹介した7つの原因と対策を振り返ると、まず最初に試すべきは「複数アカウントのログアウト」です。これだけで大半のケースが解決します。それでもダメなら、ブラウザの設定確認、承認フローのやり直し、V8ランタイムの確認と、順番にチェックしてみてください。
そして2026年は、GoogleのOAuth認証システムが大きく変わった年でもあります。きめ細かいOAuth同意画面の導入やRhinoランタイムの廃止など、知っておかないと思わぬトラブルに巻き込まれる変更が続いています。今回この記事で得た知識は、今後のGoogleスプレッドシート活用においてきっと役立つはずです。もしこの記事を読んでも解決しない場合は、Googleの公式ドキュメントやApps Scriptのトラブルシューティングページも合わせて参照してみてください。あなたのスプレッドシート作業が、スムーズに再開できることを心から願っています。
コメント