GAS「このアプリは確認されていません」の消し方と進め方

Google Apps Script（GAS）で作ったスクリプトを初めて実行すると、「このアプリは Google で確認されていません」という赤い盾の画面が出て、そこから先に進めない。自分で書いたコードなのに「確認されていません」と言われ、社内のメンバーに配ったら「これ大丈夫なんですか」と止まってしまった——GAS で社内の自動化を始めた現場でほぼ必ず通る場面です。

結論から書くと、これはエラーではありません。スクリプトが壊れているわけでも、書き方を間違えているわけでもなく、Google の審査を受けていないアプリが、機密扱いのデータにアクセスしようとしているという事実を利用者に伝えている画面です。だから「直す」のではなく、進めるか、出ないようにするかの二択になります。この記事では公式ドキュメントの記述に当たりながら、その場で進める手順と、社内配布で警告を根本から消す設定を整理します。

結論：やることは「進める」「公開対象を内部にする」「スコープを絞る」の3つ

この警告への対応は、無数にあるように見えて実際は次の3つに束ねられます。

• ① その場で進める — 警告画面の「詳細」から先に進んで権限を許可する。自分のスクリプトを自分で動かすだけなら、これで終わりです。
• ② 公開対象（User type）を「内部」にする — Google Workspace の組織内だけで使うなら、これが根本解決です。公式ドキュメントは「アプリの所有者とすべての利用者が同一の Google Workspace ドメイン（またはお客様）に属する場合、確認（verification）は不要」と明記しています。
• ③ スコープを絞る — 要求する権限が機密スコープを含まなければ、そもそも警告の対象になりません。

①は応急処置、②③が恒久対策です。なお、この警告は認可の話なので、認可を通したあとに処理が途中で止まる場合は別件です（GASの実行時間超過エラーの原因と対処を参照してください）。社内ツールとして配るなら②、スプレッドシートに紐づく小さなスクリプトなら③が最短ルートになります。

なぜ自分が書いたスクリプトでも「確認されていません」と出るのか

この画面の正体は、OAuth 同意画面に挟まる「未確認アプリ（Unverified App）」の警告です。判定しているのは「誰が書いたか」ではなく、「そのアプリが Google の確認を通っているか」と「要求しているスコープ（権限の範囲）が機密扱いかどうか」の2点だけです。作成者が自分であることは、Google 側からは一切考慮されません。

そして GAS は、コードを走査して必要なスコープを自動で決めます。公式ドキュメントには「Apps Script はコード内の関数呼び出しを走査して必要なスコープを自動的に判定する」「Apps Script は時に寛容（permissive）なスコープを自動で割り当てる」と書かれています。つまり SpreadsheetApp や GmailApp を1行書いただけで、意図より広い権限が要求され、その広さのせいで警告の対象に入る、という順序です。コメントアウトしたコードも走査対象に含まれる点も公式に注意書きがあります。

ここを押さえると、「自分のスクリプトだから安全なのに、なぜ」という引っかかりが解けます。警告は作成者を疑っているのではなく、権限の広さと審査の有無だけを機械的に見ているのです。

いま進める手順：「詳細」→「（安全ではないページ）に移動」→「許可」

その場で先に進むだけなら、手順は3クリックです。

1. 警告画面の左下にある「詳細」をクリックする（初期状態では折りたたまれています）。
2. 開いたリンク「〈プロジェクト名〉（安全ではないページ）に移動」をクリックする。
3. 要求されている権限の一覧を読み、「許可」をクリックする。

「安全ではないページ」という強い文言に手が止まりますが、ここでの「安全ではない」は「Google が中身を確認していない」という意味であって、「危険なコードが見つかった」という意味ではありません。

この操作を「安全」と言い切れる条件

とはいえ、警告を無条件に通すのは勧められません。実務では次の3つがそろっているかで判断しています。

• そのスクリプトの作成者が自分または自社である（ネットで拾ったコードをそのまま貼った場合は、中身を読むまで条件を満たしません）。
• 画面に出ている権限の一覧を自分で説明できる。「Gmail のメールの閲覧、作成、送信、完全な削除」が出ているのに身に覚えがないなら、進めずにコードを読み直す。
• プロジェクト名が自分のつけた名前になっている。見覚えのない名前なら、別のスクリプトの承認画面を踏んでいます。

社内のメンバーに配るときは、この3点を一言添えるだけで「怖がられて止まる」事故がほぼ消えます。逆に、何も説明せずに「安全ではないページを押してください」とだけ伝えるのは、社内のセキュリティ教育と真正面から矛盾するので避けてください。説明なしで通す習慣がつくと、本当のフィッシングも同じ手つきで通してしまいます。

社内配布の根本解決：アプリの公開対象を「内部」にする

Google Workspace のアカウントで使うなら、ここが本命です。Google Cloud プロジェクトの OAuth 設定で公開対象（User type）を「内部（Internal）」にすると、同じ組織のアカウントには未確認アプリの警告が出ません。公式ドキュメントも、Apps Script の OAuth クライアント確認について「所有者と利用者が同一の Google Workspace ドメインまたはお客様に属する場合、確認は不要」とし、組織内に公開したアプリはそのドメインのアカウントに対して未確認フローを発生させないと説明しています。

前提と設定の勘所

• Google Cloud 組織（Cloud Organization）が必要です。 公式には「Google Cloud 組織に紐づくプロジェクトでは、認可リクエストを組織のメンバーに限定する Internal を設定できる」とあります。Google Workspace を契約していれば通常これに該当します。
• 個人の @gmail.com アカウントでは「内部」を選べません。 組織がないため選択肢自体が出ません。個人アカウントで作ったスクリプトを個人アカウントで使う場合は、①のその場で進める方法が現実的な上限です。
• 組織外のアカウントは弾かれます。 内部にしたプロジェクトに組織外のユーザーが認可しようとすると org_internal エラーになります。業務委託先や顧客に使わせる予定があるなら、内部は選べません。社外の人に何かを提出させる仕組みを考えている場合は、Googleフォームのファイルアップロードを外部の人に使わせるときの制約も先に見ておくと、方式選びをやり直さずに済みます。

「外部（External）」のまま運用する場合に効いてくる上限

公開対象を外部にしたまま運用すると、公開ステータス（Testing / In production）によって挙動が変わります。ここは見落とすと「ある日突然みんなが入れなくなる」原因になります。

「7日ごとに再承認を求められる」症状の正体はほぼこれです。 スクリプトのバグを探しても見つかりません。外部＋テスト中のまま社内に配ってしまった、という設定の問題です。

私たちは、スプレッドシートと GAS で回していた業務をそのまま入力画面として作り直す支援もしています。記事の途中で恐縮ですが、「警告の出し方を社内で説明し続けるより、画面を1枚用意したほうが早い」という結論になる現場も多いので、よろしければ合わせてご覧いただけたら嬉しいです。

スコープを絞ると、警告の文言も審査の要否も変わる

Google の OAuth スコープは「非機密（non-sensitive）」「機密（sensitive）」「制限付き（restricted）」の3段階に分かれています。公式ドキュメントは「機密または制限付きに分類されるスコープへのアクセスを要求するアプリは、Google の OAuth アプリ確認を完了しなければならない」と明記しています。非機密スコープだけなら確認は必須ではありません。

ここで効くのが、スクリプトが触る範囲を「いま開いているファイルだけ」に狭めるやり方です。スクリプトファイルの先頭に @OnlyCurrentDoc の注釈を置くと、要求スコープが spreadsheets.currentonly のような「現在のファイルのみ」版に絞られます。この狭いスコープは単体では警告の対象にならないと説明されており、万一スクリプトにバグや改ざんがあっても被害が実行中のファイル1つに限定されます。

明示的に指定したい場合は、プロジェクトの設定で appsscript.json（マニフェスト）を表示し、oauthScopes に必要なスコープだけを並べます。公式ドキュメントの言い方は一貫して「常に可能な限り権限の狭いスコープ集合を使う」です。自動検出に任せると広いスコープが付きがちなので、社内に配るスクリプトほど、ここを手で絞る価値があります。

Google の「確認」が本当に必要になるのはどういう時か

審査を受けなければならないのは、次の2つが重なったときだけです。裏返すと、社内の自動化で審査が必要になる場面はほとんどありません。

• 組織外の人に使わせる（＝公開対象を外部にして、Workspace ドメインの外のアカウントが認可する）。
• 機密または制限付きスコープを要求している。

公式には、確認を申請する場合は Google Cloud プロジェクトの OAuth 同意画面にアプリ名・ロゴ・プライバシーポリシーの URL・承認済みドメイン・スコープをそろえる必要があるとされています。所要日数は「24〜72時間」と案内されていますが、制限付きスコープを含む場合はセキュリティ評価が入るため、この見立てで予定を組まないほうが安全です。

なお、Google Workspace Marketplace にアドオンとして公開する場合は、OAuth の確認とは別に Marketplace 側の審査があります。 公式の「よくある却下理由」には、OAuth 同意画面の設定誤り（公開対象が Internal のまま／公開ステータスが Testing のまま）や、コードが要求するスコープと同意画面のスコープが一致していないことが挙げられています。社内向けの「内部」設定と、一般公開に必要な設定は真逆だと覚えておくと混乱しません。

設定は合っているのに警告や拒否が出る時の切り分け

「内部にしたのに警告が出る」「許可を押したのに弾かれる」ときは、ほぼ次のどれかです。上から順に確認すると速く終わります。

承認は通ったのに動かない、という場合は認可ではなく起動側の問題です。GASのトリガーが動かないときの原因と直し方に、設定したはずのトリガーが実行されない条件をまとめています。

4つめは、自分の設定をいくらいじっても解決しません。Google Workspace の管理者は「API の制御」で、各アプリを「信頼できる」（すべての OAuth スコープにアクセス可）／「制限」（アクセス制限のない Google サービスのみ）／「ブロック中」（一切アクセス不可）に設定できます。ブロック時には管理者が設定したカスタムメッセージが利用者に表示されます。社内で作ったスクリプトを広く配る前に、管理者側に「すべての内部アプリに対して API アクセスを許可する」設定があることも共有しておくと、配布後のつまずきが減ります。

エラーの出方そのものが分からないときは、実行ログ側から追うほうが早い場合もあります。GASの実行ログが出ないときの原因と見る場所に、ログが空になる条件をまとめています。

ライブラリ・アドオンにすると何が変わるか

同じコードでも、置き方を変えると権限の見え方が変わります。

• ライブラリとして読み込む場合：利用する側のプロジェクトに、ライブラリ内のコードが必要とするスコープも乗ってきます。手元のコードには GmailApp が1行も無いのに Gmail の権限を求められるのは、この経路です。公式には、ライブラリをプロジェクトに含めるにはそのライブラリに対して少なくとも閲覧権限が必要とあり、スコープの扱いは認可のガイド側に委ねられています。「ライブラリのスコープが呼び出し側に合算される」という挙動を、スコープ継承として明記した公式ページは今回見つけられませんでしたので、実際の承認画面に出るスコープ一覧で確認するのが確実です。
• スプレッドシートに紐づくスクリプト（コンテナバインド）の場合：@OnlyCurrentDoc が最も効きます。そのファイルの中だけで完結する処理なら、権限を1ファイルに閉じ込められます。
• エディタアドオン／Marketplace 公開の場合：OAuth 確認とアドオン審査の両方が必要になり、審査する担当も別だと公式に説明されています。社内配布とは完全に別の作業として見積もってください。

まとめ：警告は「設定の状態」を映しているだけ

• 「このアプリは Google で確認されていません」はエラーではなく未確認アプリの警告。自分が作ったスクリプトでも、機密スコープを要求すれば出る。
• その場で進めるなら「詳細」→「（安全ではないページ）に移動」→「許可」。進める前に、作成者・権限一覧・プロジェクト名の3点を自分で説明できる状態にする。
• 社内配布の根本解決は公開対象を「内部」にすること。同一 Workspace ドメイン内なら確認（審査）は不要。個人 Gmail では選べない。
• 外部＋テスト中のまま配るとテストユーザー100人・認可7日で失効、本番・未確認でも未確認画面を見たユーザー累計100人で詰まる。
• @OnlyCurrentDoc やマニフェストでの明示指定でスコープを狭めると、警告そのものを避けられる場合がある。
• 審査が必要なのは「組織外に配る」かつ「機密・制限付きスコープを使う」ときだけ。

GAS で作った自動化を社内に広げる段階になると、警告の出し方の説明より、誰が何に権限を持つかの設計のほうが悩みどころになります。権限の説明コストが毎回かかるようなら、社内アプリを自分で作るべきかどうかの判断軸も合わせて検討の材料になります。この警告を消す設定だけでも、どこまでを社内で持ちどこから外に出すかの判断が必要なので、切り分けからお手伝いできます。