GASのスクリプトを承認できない5つの原因と対処｜自分で直せるか管理者依頼か

結論：GASを承認できない理由は「未確認アプリ」「管理者ブロック」「アカウント違い」「スコープ不一致」「組織外の共有」の5系統

Google Apps Script（GAS）を実行しようとしたときに、「このアプリは Google で確認されていません」「承認されていないアプリ」「このアプリはブロックされています」と出て先へ進めない。原因は次の5系統にほぼ収まります。

• ①未確認アプリの警告：機密性の高いスコープを使うのに、Googleの確認（verification）が済んでいないスクリプト。
• ②Workspace管理者がサードパーティ製アプリのアクセスを制限している：管理コンソール側の設定。
• ③アカウントの取り違え：スクリプトの持ち主と、いま承認しようとしているアカウントが違う。
• ④必要なスコープが実際のコードと食い違っている：appsscript.jsonのoauthScopesまわり。
• ⑤組織外から共有されたスクリプトを承認しようとしている：外部ドメインのスクリプトは組織のポリシーに引っかかりやすい。

この記事で一番大事なのは、この5つが「自分で解決できるもの」と「管理者に頼まないと絶対に解決できないもの」に分かれるという点です。ここを切り分けないまま、管理者がブロックしているものを自分で何十分もいじり続けることになります。

まず30秒で切り分ける：自分で直せるか、管理者に頼むか

画面に出ている文言で、ほぼ判別できます。

• 「このアプリは Google で確認されていません」＋「詳細」リンクがある → ①。自分で進める余地がある（ただし後述のとおり、出所の確認が前提）。
• 「このアプリはブロックされています」「管理者によってブロックされています」など、続行の選択肢が無い → ②または⑤。自分では解決できません。管理者に依頼します。
• 承認画面は出るが、最後に「アクセス権が必要です」「権限がありません」になる → ③または④。自分で直せます。

「詳細」リンクが出ているかどうかが、最初の分岐点だと思ってください。リンクごと出ない＝ユーザー側の操作で越えられる壁ではありません。

原因別の対処5手順

1.「このアプリは Google で確認されていません」＝未確認アプリの警告

これはエラーではなく警告です。Googleの公式ドキュメントによれば、この画面はアプリが機密性の高いスコープ（sensitive / restricted scopes）を使っているのに、OAuth同意画面での確認プロセスが完了していない場合や、コードが要求するスコープとOAuth同意画面で設定したスコープが食い違っている場合に表示されます（未確認のアプリに関する警告｜Google Cloud 公式ヘルプ）。

同じページには、未確認アプリの画面を表示するアプリには、合計100人までの新規ユーザーという上限がかかるとも明記されています。社内でスクリプトを配って回るときに効いてくる数字です。

ここで判断が分かれます。自分または社内の担当者が書いたスクリプトで、コードの中身を自分たちで確認できるなら、警告画面の「詳細」→「（プロジェクト名）に移動」から自分の責任で続行できます。これは「自分が書いたコードに、自分のデータへのアクセスを許す」という操作だからです。

一方で、出所の分からないスクリプト、ネットで拾ってきたコード、心当たりのないアドオンの場合は、この警告を越えてはいけません。この警告は「Googleがまだ中身を確認していない」という事実を伝えるもので、安全だと言っているわけではありません。コードを読んで何をするか説明できないものは、承認しないのが正解です。

ここで「詳細」リンクが見当たらないなら、原因は未確認アプリの警告ではありません。手順2へ進みます。

2. Workspace管理者がサードパーティ製アプリのアクセスを制限している

会社のGoogle Workspaceアカウントで起きやすいのがこれです。管理者は管理コンソールの「セキュリティ > アクセスとデータ管理 > API の制御」から、どのアプリにデータを渡すかを制御できます（Google Workspace のデータにアクセスできるアプリを管理する｜Google Workspace 管理者ヘルプ）。

公式ヘルプによると、アプリのアクセス権は「信頼できる」「制限付き」「特定のGoogleデータへのアクセスを許可」「ブロック中」に分けて設定でき、さらに「未設定のサードパーティ製アプリ」についても、ユーザーに任せる／基本情報のみのアプリに限る／すべて禁止する、の3つから既定の動作を選べます。つまり、管理者が「すべて禁止」に寄せている組織では、社内で作った小さなGASすら、個人の操作では一切承認できません。

そして同じヘルプには、組織が自分で開発した内部アプリについて「内部アプリを信頼する」設定があることも書かれています。社内GASを回す場合、管理者に頼むのはまさにここです。

見分け方として分かりやすいのは、同じスクリプトを個人のGmailアカウントで開いてみることです。個人アカウントでは承認画面が出て進めるのに、会社アカウントでは同じ画面で止まるなら、原因はコードではなく組織のポリシー側だと断定できます（ただし会社のデータを個人アカウントで扱うのは避け、切り分けの確認だけにとどめてください）。

この設定が原因かどうかは、ユーザー側の画面からは断定できません。「ブロックされています」と出て続行の選択肢が無いなら、ここを疑って管理者に確認するのが最短です。

3. アカウントを取り違えている

会社アカウントと個人アカウントの両方でログインしている環境では、これが驚くほど多く起きます。URLの/u/0//u/1/が示すプロフィールと、スクリプトを共有された側のアカウントがずれていると、承認画面までは出るのに最後で弾かれます。

確認すべきは3つです。スクリプトエディタの右上のアカウント、承認ポップアップで選んだアカウント、スクリプトが触りに行くスプレッドシートやカレンダーの共有先アカウント。この3つが揃っているか見てください。個人アカウントで開いたスクリプトから会社のシートを触ろうとしていた、というのが典型です。

ブラウザのプロフィールを分ける（Chromeで会社用プロフィールと個人用プロフィールを別ウィンドウにする）と、この事故はほぼ消えます。共有そのものが通っていない場合は、「権限がありません」と出てスプレッドシートを共有できない時の対処もあわせて確認してください。

正しいアカウントで開き直しても同じ画面なら、原因はアカウントではありません。手順4へ進みます。

4. 必要なスコープがコードと食い違っている

Apps Scriptはコードをスキャンして、必要なスコープを自動的に判断します。公式リファレンスは、ほとんどのスクリプトはこの自動検出で足りるとしたうえで、appsscript.jsonマニフェストのoauthScopesフィールドを編集すれば明示的に指定できると説明しています（スコープ｜Google Apps Script 公式ドキュメント）。同じページは「常に最小限の権限のスコープを使用してください」とも明記しています。

ここで起きるのが、手で書いたoauthScopesが、実際のコードが要求するスコープを網羅していないというズレです。承認は通るのに実行時に権限エラーになったり、逆に不要に広いスコープを書いたせいで管理者のポリシーに引っかかったりします。

もう1つ見落としやすいのが、コードを更新して新しいサービスを使い始めると、追加の承認が求められるという挙動です。Apps Scriptの公式ガイドは、これがコメントアウトされたコードでも起こりうると注意しています（承認｜Google Apps Script 公式ドキュメント）。「昨日まで動いていたのに今日から承認を求められる」の正体はたいていこれです。

対処は、使っていないコード（コメントアウトを含む）を消す、oauthScopesを手書きしているなら一度外して自動判定に戻す、そのうえで必要最小限に絞り直す、の順です。GmailやDriveの広いスコープが紛れ込んでいると、管理者の制限に触れる確率が跳ね上がります。

スコープを絞っても「ブロックされています」が消えないなら、やはり管理者側の設定です。

5. 組織外から共有されたスクリプトを承認しようとしている

取引先や外部の制作会社から共有されたスクリプト、ネットで配布されているスクリプトのコピーは、組織にとっては「外部のサードパーティ製アプリ」です。手順2で触れた「内部アプリを信頼する」の対象にはならないため、内部で作った同じ内容のスクリプトなら通るのに、共有されたものだけ通らない、ということが起きます。

実務的な解決はコピーを自社側に作り直すことです。スクリプトの中身を自社のアカウントで新規プロジェクトとして作成すれば、「自社で開発した内部アプリ」として扱えるようになります。外部から受け取ったコードをそのまま承認するより、中身を読んでから移す方が安全でもあります。

補足：一度承認したものをやり直したいとき

スコープを絞り直したのに古い承認が残っていて挙動が変わらない、というときは、承認そのものを一度外します。Googleアカウントの「サードパーティとの接続」のページから、対象のアプリを選び、「詳細を表示」→「アクセス権を削除」で解除できます（サードパーティ製のアプリとサービスとの接続を管理する｜Google アカウント ヘルプ）。解除したあとで実行すれば、いまのコードに対応した承認画面が改めて出ます。

このとき承認画面に並ぶスコープの一覧を読んでください。想定より広い権限（Gmailの全メールの閲覧、Driveの全ファイルなど）が並んでいたら、それがそのまま管理者の制限に引っかかっている理由です。ここで一覧を控えておくと、次の依頼がそのまま書けます。

管理者に依頼するときに書くべき4点

「GASが動きません、許可してください」だけでは、管理者は何を許可すればいいか判断できません。以下の4点が揃っていれば、たいていその日のうちに片が付きます。

1. スクリプトの出所：社内で作ったものか、外部から共有されたものか（＝内部アプリとして扱えるかの判断材料）。
2. OAuthクライアントID／プロジェクト名：管理コンソールの「API の制御」でアプリを特定するのに必要です。
3. 要求しているスコープの一覧：appsscript.jsonのoauthScopesをそのまま貼る。「なぜそのスコープが要るか」を1行ずつ添えると通りやすくなります。
4. 誰が使うか・何のためか：対象部署と業務。全社解禁ではなく組織部門単位で許可できるので、範囲を絞って出す方が承認されます。

逆に書かない方がいいのは「全部のアプリを許可してほしい」という依頼です。管理者は断るしかなく、往復が1回増えるだけになります。

毎回この壁で止まるなら、GASで回す設計そのものが限界かもしれません

ここまでの5系統を見て気づくと思いますが、①②⑤はコードの問題ではありません。組織のセキュリティ設計とGASの承認モデルが噛み合っていない、という構造の問題です。だから、スクリプトを直しても再発します。

そして、承認が通った後も同じ性質の問題は続きます。作った人しか承認の経緯を知らない、その人が異動すると誰も直せない、スコープを足すたびに全員が再承認を求められる。GASでスプレッドシートからメールを自動送信する仕組みのように、便利なほど業務の真ん中に置かれ、止まったときの影響が大きくなります。

もう1つの限界はコストです。承認や権限の設計まで含めて外に頼むといくらかかるのかは、GAS開発を外注する費用の相場で整理しています。小さなスクリプトのつもりが、運用・保守まで見ると案外そうでもない、というのはよくある話です。シートそのものが限界に来ている場合は、スプレッドシート管理の限界とアプリ化の判断基準も参考になります。

正直に言うと、承認の壁は「越え方」を覚えるより、越えなくていい形に作り替える方が早いことが多いです。Mihataでは、業務に合わせたAIの仕組みづくりをご相談から一緒に設計しています。今の運用のどこが詰まっているかを話すだけでも、進め方が見えるはずです。

まとめ

GASの承認エラーは、「詳細」リンクが出ているかどうかで自力解決できるかがほぼ決まります。出ていれば未確認アプリの警告で、自分や社内が書いたコードなら続行できます。出ていなければ管理者側の設定なので、出所・クライアントID・スコープ・用途の4点を揃えて依頼するのが最短です。そして、同じ壁に毎月ぶつかっているなら、それは直すべきなのはスクリプトではなく仕組みの方だ、というサインです。