GAS（Google Apps Script）は、コードを書いた本人ではなく承認したGoogleアカウントの権限で動く。この一点を押さえないまま「次のユーザーとして実行＝自分」「アクセスできるユーザー＝全員」でウェブアプリを公開すると、URLを知っただけの第三者が、オーナー権限でスプレッドシートを読み書きできる状態が生まれます。Googleが公式ドキュメントで繰り返し警告しているのも、コードの書き方より先にこの公開設定とOAuthスコープの扱いです。2026年6月23日にApps ScriptはGoogle Workspaceのコアサービスへ移り、適用される規約と管理者側の前提も変わりました。設定ごとに何が起きるかを、マニフェストの定義値と管理コンソールの実際の設定項目に沿って整理します。
まとめ：GASの安全性は実行ユーザー・公開範囲・OAuthスコープの3設定でほぼ決まる
- 実行ユーザー：マニフェストの
executeAsがUSER_DEPLOYINGならオーナー権限で常時動く。利用者を識別したいならUSER_ACCESSINGを選ぶ。 - 公開範囲：
accessのANYONE_ANONYMOUSは「ログインしていないユーザーも含む」という定義。URLは秘密情報として扱えない。 - OAuthスコープ：Apps Scriptはコードを走査してスコープを自動判定する。
appsscript.jsonで明示指定し、spreadsheets.currentonlyのように範囲の狭いスコープへ絞る。 - 認証情報：スクリプトプロパティは「スクリプト、アドオン、ウェブアプリのすべてのユーザー」で共有される。利用者ごとの秘密には使えない。
- 管理者統制：監査ログは管理コンソールの「ドライブのログイベント」、実行状況は「アプリレポート＞Apps Script」（過去6か月）。外部接続の許可リストは上位エディション限定。
- ランタイム：旧Rhinoは2026年1月31日で実行停止済み。現行はV8のみ。
- コアサービス化：2026年6月23日以降、Apps ScriptはGoogle Cloud利用規約およびGoogle Workspace for Education利用規約の適用対象。すでに有効なら管理者の作業は不要。
GASの実行権限モデル
承認アカウントの権限を借りる実行の仕組み
GASはブラウザやPC上ではなくGoogleのインフラで実行されます。スクリプトがスプレッドシートやGmailに触れるとき使われるのは、そのスクリプトを承認したアカウントのOAuthトークンだ。「スクリプトに権限がある」のではなく「承認した人の権限をスクリプトが借りている」状態だと捉えてください。
認可ガイドによれば、Apps Scriptはスクリプトを走査して使用サービス（SpreadsheetAppやGmailAppなど）を特定し、必要なスコープを決める。書いたコードの中身が、そのまま要求される権限の広さになる設計です。この委譲は標準的なOAuth 2.0の認可フローであり、OAuth 2.0とは？仕組み・認可フローと認証・認可の違いをわかりやすく解説で扱う「認証」と「認可」の区別がそのまま当てはまります。
「GAS Interpreter」の実体はApps Scriptの実行ランタイム
検索で見かける「GAS Interpreter」という名前の製品・ツールは、Googleの公式ドキュメントにもnpmレジストリにもGitHubにも存在しない。実体に近いのはApps Scriptの実行ランタイムです。Apps Scriptは以前MozillaのRhino JavaScriptインタープリタで動作しており、2020年2月18日以降、自動互換性テストに合格した既存スクリプトが段階的にV8ランタイムへ移行されました。
そしてこの選択肢はすでに残っていません。サンセット一覧によると、Rhinoランタイムは2025年2月20日に非推奨となり、「Rhino で実行されているスクリプトは 2026 年 1 月 31 日まで引き続き機能しますが、それ以降は実行されなくなります」と明記されています。つまりappsscript.jsonのruntimeVersionに"DEPRECATED_ES5"を指定したスクリプトは、本記事の更新時点ですでに動きません。現行の指定は"V8"だけだと考えてください。V8ではlet／const、アロー関数、クラス構文、分割代入、テンプレートリテラルが使えます。
一方でブラウザ由来のsetTimeout、setInterval、fetch、Blob、URL、Crypto APIは利用できません。代替はApps Script側のAPIで、外部通信はUrlFetchApp.fetch、ハッシュや署名はUtilities.computeDigest()とUtilities.computeHmacSha256Signature()、待機はUtilities.sleep()を使います。セキュリティ設計上は、この「ブラウザのAPIが使えない＝Googleのサンドボックス内で動く」点が前提になる。GASそのものの機能範囲はGAS（Google Apps Script）とは？できること・制限・始め方を開発者目線で解説にまとめています。
ウェブアプリの実行ユーザーと公開範囲が事故の分岐点
「自分として実行」×「全員」が最も危険な組み合わせ
ウェブアプリのデプロイでは「次のユーザーとして実行」と「アクセスできるユーザー」を別々に選びます。ウェブアプリのガイドは前者について、「自分として実行」はスクリプトのオーナーであるユーザーとしてスクリプトが常に実行される、「ウェブアプリにアクセスするユーザーとして実行」はアクティブユーザーのIDでスクリプトが実行されると説明しています。後者では、ユーザーがアクセスを承認するとスクリプトオーナーのメールアドレスが表示される。マニフェストの定義値と対応させると、危険度は組み合わせで決まります。
| 実行（executeAs） | 公開範囲（access） | 動く権限 | 主なリスク |
|---|---|---|---|
| 自分（USER_DEPLOYING） | 全員（ANYONE_ANONYMOUS） | オーナー | 未ログインの第三者がオーナー権限で実行 |
| 自分（USER_DEPLOYING） | Googleアカウントを持つ全員（ANYONE） | オーナー | 社外アカウントでも実行可能 |
| 自分（USER_DEPLOYING） | 組織内の全員（DOMAIN） | オーナー | 全社員がオーナーのデータへ到達 |
| アクセスするユーザー（USER_ACCESSING） | Googleアカウントを持つ全員（ANYONE） | 実行者本人 | 利用者ごとの承認が必要 |
| アクセスするユーザー（USER_ACCESSING） | 組織内の全員（DOMAIN） | 実行者本人 | 承認頻度の制限に当たる場合あり |
| アクセスするユーザー（USER_ACCESSING） | 自分のみ（MYSELF） | 実行者本人 | 実質的に個人利用 |
マニフェストの定義はANYONEが「ログインしているすべてのユーザー」、ANYONE_ANONYMOUSが「ログインしていないユーザーも含むすべてのユーザー」です。デプロイ画面の「全員」は後者にあたり、Googleアカウントへのログインを前提にしない。URLさえ手元にあれば実行できるため、URLをアクセス制御の手段として扱うのは誤りです。共有時のチャットログ、ブックマーク同期、社外へ転送されたメールのいずれからも漏れる。なおウェブアプリのガイドは、不正使用を防ぐためユーザーとして実行されるウェブアプリを新しいユーザーが承認できる頻度に制限が設けられているとも明記しています。社内へ一斉展開する際は、承認が集中して弾かれる可能性を見込んでおきます。なおデプロイ画面のDOMAINに相当する項目は組織名が入るため、Workspaceでは「〇〇株式会社内の全員」のように表示されます。
実行者設定とgetActiveUserの取得可否
「誰が実行したか」を記録する設計は、実行ユーザーの設定に縛られます。Sessionクラスのリファレンスによると、Session.getActiveUser().getEmail()は次の場面で空文字を返します。
- 単純トリガーの
onOpen(e)、onEdit(e) - Googleスプレッドシートのカスタム関数
- 「自分として実行」でデプロイされ、利用者ではなく開発者が承認したウェブアプリ
ただし開発者自身が実行する場合や、アクセスした人がスクリプトオーナーと同じGoogle Workspaceドメインに属している場合は、これらの制限が通常は適用されません。つまり同じ設定でも、社内からのアクセスではメールアドレスが取れ、社外からのアクセスでは空になります。getActiveUserを認可の唯一の根拠にしてはいけない理由がここにある。一方Session.getEffectiveUser()はスクリプトが動いている権限の持ち主を返し、「自分として実行」のウェブアプリでは開発者のアカウント、インストール可能なトリガーではトリガー作成者のアカウントになります。
監査証跡を残したいなら、実行者を「アクセスするユーザー」にしたうえで、入口で呼び出し元を確認します。
function doGet(e) {
const email = Session.getActiveUser().getEmail();
if (!email || !email.endsWith('@example.co.jp')) {
return ContentService.createTextOutput('forbidden');
}
console.log('access by %s', email);
return HtmlService.createHtmlOutputFromFile('index');
}「自分として実行」のまま社外へ公開するとemailが空になり、条件式が成立して全員が弾かれます。逆に判定を外せば全員が通る。ログイン画面が出ないことを「便利」と受け取らず、誰の権限で動いているかを毎回確認してください。なおconsole.logの出力先は実行ログ（Cloud Logging）です。
OAuthスコープの最小化とappsscript.jsonでの固定
Apps Scriptはコードからスコープを自動判定しますが、認可ガイドはより詳細な制御が必要な場合はプロジェクトマニフェスト（appsscript.json）でスコープを明示的に設定できるとし、公開されたスクリプトでは必要な最小限の権限を使用することを推奨しています。自動判定に任せると、一時的に書いたデバッグコードが広いスコープを呼び込み、それが承認画面に出続けます。
{
"timeZone": "Asia/Tokyo",
"runtimeVersion": "V8",
"oauthScopes": [
"https://www.googleapis.com/auth/spreadsheets.currentonly",
"https://www.googleapis.com/auth/script.external_request",
"https://www.googleapis.com/auth/userinfo.email"
]
}ここで見落としやすいのが3行目です。oauthScopesを明示した時点で自動判定による追加は止まります。前節のdoGetのようにSessionクラスを使うならuserinfo.emailが必須で、書き漏らすと実行時に権限エラーになる。明示指定に切り替えるときは、使っているサービスのリファレンスで必要スコープを1つずつ確認してください。
spreadsheets.currentonlyは、そのスクリプトが紐づくスプレッドシートだけに範囲を限定するスコープで、全ファイルを対象にするspreadsheetsとは影響範囲が桁違いです。承認画面に「すべてのGoogleスプレッドシートの表示、編集、作成、削除」と出たら、スコープが広すぎるサインだと考えてください。
認可ガイドは、プライベートデータにかかわるスコープを使用するウェブアプリやその他のスクリプトはGoogleによる審査の対象となり、承認時に「未確認」であるという警告画面が表示されることがあるとも説明しています。社内展開でこの画面が出ること自体は異常ではない。ただし利用者に「詳細→安全ではないページに移動」を毎回踏ませる運用は、フィッシングへの耐性を組織的に下げます。警告はスコープが重い合図と捉え、先にスコープの削減を検討してください。
認証情報の置き場所とスクリプトプロパティの共有範囲
外部APIのキーをコードに直書きすると、スクリプトの閲覧権限を持つ全員に見えます。代わりに使うのがPropertiesServiceですが、3種類のストアで誰に共有されるかが違う点を取り違えると別の穴になる。
| ストア | 取得メソッド | 共有される範囲 | 公式の用途例 |
|---|---|---|---|
| スクリプトプロパティ | getScriptProperties() | すべてのユーザー | 外部データベースの認証情報 |
| ユーザープロパティ | getUserProperties() | 現在のユーザー | ユーザー固有の設定 |
| ドキュメントプロパティ | getDocumentProperties() | 開いている文書のアドオン利用者 | ドキュメント固有のデータ |
プロパティサービスのガイドはスクリプトプロパティの共有範囲を「スクリプト、アドオン、ウェブアプリのすべてのユーザー」と定義しています。つまり利用者ごとに異なる秘密（個人のAPIトークンなど）をスクリプトプロパティに入れてはいけません。それはユーザープロパティの役割だ。さらにスクリプトプロジェクトの編集権限を持つ人は、エディタのプロジェクト設定画面からスクリプトプロパティの値を読めます。これは「暗号化された保管庫」ではなく「コードから分離しただけの置き場」だと理解しておいてください。
const props = PropertiesService.getScriptProperties();
const apiKey = props.getProperty('EXTERNAL_API_KEY');
const res = UrlFetchApp.fetch(endpoint, {
headers: { Authorization: 'Bearer ' + apiKey },
muteHttpExceptions: true
});値はすべてKey-Valueペアの文字列として保存され、非文字列型は自動的に文字列へ変換されます。オブジェクトを入れる場合はJSON.stringifyを通す前提で設計してください。スクリプトプロジェクトの共有相手を絞ることが、この保護の実効性をそのまま決めます。
HtmlService製UIのサンドボックス制約と遷移の実装
ウェブアプリの画面をHtmlServiceで作る場合、サンドボックスモードはIFRAMEに一本化済みです。制限事項のページには、NATIVEおよびEMULATEDモードは廃止され、以前にこれらを使用していたアプリは自動的にIFRAMEモードを使用するようになると記載されています。
IFRAMEサンドボックスに設定されるキーワードはallow-same-origin、allow-forms、allow-scripts、allow-popups、allow-downloads、allow-modals、allow-popups-to-escape-sandbox、そしてスタンドアロンのスクリプトプロジェクトに限りallow-top-navigation-by-user-activation。一方でallow-top-navigationは制限されており、サンドボックスの属性として設定されていません。JavaScriptから勝手にトップレベルのリダイレクトを行うことはできない、という意味です。
実装側の対処ははっきりしています。リンクのtarget属性に_topまたは_blankを指定するか、<head>内に<base target="_top">を置いて既定を上書きする。これを忘れると、リンクを押してもiframeの内側で遷移しようとして何も起きません。通信面では、スクリプト、外部スタイルシート、XmlHttpRequestなどのアクティブコンテンツはHTTPではなくHTTPS経由で読み込む必要があると明記されており、社内の古い管理画面をHTTPで参照させる実装はそもそも読み込まれない。
これらはブラウザ側の枠組みにすぎず、受け取った値の検証は自前で行う必要があります。フォームから受けた文字列をそのままinnerHTMLへ流せば、IFRAMEモードでもスクリプトは動く。テンプレートへ値を差し込むときはテキストノードとして挿入するか、サーバ側でエスケープしてから返す実装に統一してください。
ライブラリとコピペコードが持ち込むリスク
他人のスクリプトIDを指定してライブラリとして取り込むと、そのコードは自分のプロジェクトの承認済み権限の中で動きます。ライブラリのガイドは両者の関係を「共有リソースとは、ライブラリと含めるスクリプトの両方が、リソースの同じインスタンスに組み込みのアクセス権を持っていること」と説明しています。
そのうえで、取り込んだコードはデバッガから追えません。ガイドは「ライブラリを含むスクリプトをデバッグする場合、ライブラリのコードにステップインしたり、その中にブレークポイントを設定したりすることはできない」とし、さらに「ライブラリのバージョンにHEAD（開発モード）を使用しても、ライブラリへのステップインやブレークポイントのヒットが可能になるわけではない」と補足している。バージョンを固定していても中身は追えない、というのが正確な理解です。
そのHEADがもう一段のリスクになります。ライブラリ追加時にバージョン番号ではなくHEADを選ぶと、ライブラリ所有者が保存した最新コードが常に参照される。所有者がコードを差し替えれば、こちらのスクリプトの挙動は通知なしに変わります。中身を追えないうえに黙って変わる、という最悪の組み合わせです。外部のライブラリはバージョン番号で固定するのが原則になります。
ガイドはライブラリを使用するスクリプトは、すべてのコードが1つのスクリプトプロジェクトに含まれている場合ほど高速には実行されないとも警告し、この理由からGoogle Workspaceアドオンではライブラリの使用を控えるべきだと推奨しています。数十行の共通処理なら、依存を増やすよりプロジェクト内へ取り込むほうが性能と監査性の両面で有利。ブログ記事からコピーしたスニペットも危険度は同じで、UrlFetchAppで見知らぬエンドポイントへPOSTする行が混ざっていれば、それは承認済み権限で取得したデータの外部送信です。取り込む前にUrlFetchAppとMailAppの呼び出し箇所を必ず読んでください。
管理者側の統制：監査ログ・アプリレポート・外部接続の許可リスト
個々の開発者の心がけだけでは、退職者が残したトリガーや誰も把握していない自動処理は消えません。管理コンソール側の統制手段は次のとおり。
- 監査ログ：レポート＞監査と調査＞ドライブのログイベントで、「ドキュメントタイプ」フィルタに「Googleスクリプト」を指定して検索します。
- 利用状況：レポート＞アプリレポート＞Apps Scriptで、過去6か月のデータが表示され、スクリプトの実行がすべて含まれる。データはダウンロードできます。
- 組織全体の有効／無効：Apps Scriptを組織内のユーザー全体に対して有効または無効にできます。
- 特定プロジェクトの停止：関連付けられているCloudプロジェクトを削除すると、そのスクリプトプロジェクトの実行がすべて停止する（削除にはそのCloudプロジェクトの権限が必要）。
OAuthスコープ単位の統制は、セキュリティ＞アクセスとデータ管理＞APIの制御にある「アプリのアクセス制御」で行います。アプリはGoogle所有／社内／サードパーティの3タイプに分けられ、それぞれ信頼できる（制限付きと制限なしの両方を含むすべてのGoogleサービスへアクセス可）、限定（制限なしのサービスのみ）、特定のGoogleデータ（指定したスコープのみ）、ブロック（一切アクセス不可）から選ぶ。「内部アプリを信頼する」をオンにすると、自組織が作成した内部アプリが制限付きのGoogle Workspace APIにアクセスできるようになります。未設定のサードパーティ製アプリの既定は「任意のサードパーティ製アプリにGoogleでログインできます」なので、統制を効かせたい組織はここを既定のまま放置しないでください。
外部への送信そのものを絞るなら、外部接続の許可リストを使います。対象はApps ScriptのUrlFetchAppとスプレッドシートのIMPORTXMLなどのインポート関数で、既定ではすべてのURLへのアクセスが許可されています。設定は管理コンソール＞アプリ＞Google Workspace＞ドライブとドキュメント＞機能とアプリケーション＞「URLからのインポートと取得」で、「次のURLからのみインポートと取得を許可します」を選んで保存する。登録できるURLは最大1,000件、ワイルドカードは1つだけという制約があるため、切り替え前に監査と調査の「URLへのアクセスがありました」イベントで現状の通信先を洗い出す手順が欠かせません。
注意点として、対応エディションの記載はGoogleのページ間で一致していません。外部接続の許可リストの解説ページはFrontline Plus、Business Plus、Enterprise Standard、Enterprise Plus、Education Standard、Education Plus、Enterprise Essentials Plusを挙げ、開発者向けのモニタリング解説ページはBusiness Plus、Enterprise、Education Standard、Teaching and Learning Upgrade、Education Plusを挙げている。自社の契約エディションで実際に設定項目が現れるかは、管理コンソールの該当画面で確認してください。管理作業をコマンド側から自動化したい場合はgws（Google Workspace CLI）とは？Google Workspace APIをコマンド1本で操作する使い方と導入判断が参考になります。
2026年6月のコアサービス化で変わった前提
Google Workspace Updatesは2026年6月23日に、Google Apps ScriptをGoogle Workspaceのコアサービスとして提供すると発表しました。Apps ScriptはGoogle Cloud利用規約およびGoogle Workspace for Education利用規約の適用対象となり、他のコアサービスを保護しているのと同じエンタープライズ級のデータ保護、堅牢な管理者制御、標準テクニカルサポートが及びます。提供範囲はすべてのGoogle Workspaceのお客様で、Rapid ReleaseとScheduled Releaseの両ドメインで提供済み。
実務上の変化は稟議の通し方に出ます。従来のApps Scriptは追加サービス扱いで、規約もサポート範囲もGmailやドライブとは別建てでした。「業務データを扱う自動化をコアサービス外に載せてよいのか」という論点が情報システム部門の承認を止めていた組織では、その論点自体が消える。
ただし公開設定やOAuthスコープの危険性は何ひとつ変わっていません。規約の適用範囲が広がることと、匿名公開したウェブアプリが安全になることは無関係です。すでに有効な組織では管理者の作業は不要なので、この機会にアプリレポートで実行され続けているスクリプトの持ち主を洗い出すほうが実利がある。管理外の自動化が業務に入り込む構図は、シャドーAIとは？無断利用が招く情報漏洩リスクと企業の対策を解説【2026年版】で扱うシャドーITとまったく同じ形です。
GASに載せてはいけないデータと処理の線引き
GASは無料でGoogleサービスに触れられる代わりに、載せるべきでない対象があります。事故に直結する順で並べます。
- 法令上の安全管理措置が必要なデータは置かない。 マイナンバー、クレジットカード番号、健康情報などをスプレッドシートに置くと、保護の実体は「そのファイルの共有設定」だけになります。共有リンクの誤操作1回で範囲が広がり、スクリプトプロパティも編集権限者から読める。責任分界の考え方はクラウドセキュリティとは？リスクと責任共有モデルから見た企業の守り方の責任共有モデルがそのまま当てはまり、この層の保護は利用者側の責任範囲です。
- 「全員」公開が避けられない用途は、書き込み専用に絞る。 社外からの問い合わせ受付のように匿名アクセスが要件になる場合、
doPostで受け取って追記するだけの処理に限定し、読み出し系のメソッドをコードから外します。実行がオーナー権限である以上、読み出しを1行でも残せば、そこが全公開の窓口になる。 - 認証の主体をGASに置かない。 スクリプトプロパティに合言葉を入れて
doGetで照合するような自前認証は、パスワード管理・失効・総当たり対策のいずれも自作になります。Googleアカウントで識別できる範囲に用途を留め、それを超える要件が出た時点で別の基盤へ移すべきです。 - 監査証跡が必須の処理は、実行者設定と併せて設計する。 前述のとおり「自分として実行」では社外アクセス時にメールアドレスが空になる。「誰がいつ承認したか」を残す必要がある承認ワークフローを、匿名実行のまま作らないでください。
- 攻撃側にも使われる前提を持つ。 Kasperskyは2021年7月30日の記事で、攻撃者がApps Scriptで作成したスクリプトへのリンクをフィッシングに悪用する手口を報告しています。Googleの正規Webサイトへのハイパーリンクは不審なものとは見なされないので、メールサーバーレベルのフィッシング対策機能はメールをフィルタリングしないためだ。自社ドメインではなくGoogleのドメインでウェブアプリを公開することは、利用者に「Googleのドメインだから安全」という誤った学習をさせることでもあります。社外向けの窓口は、可能な限り自社ドメイン配下に置いてください。
よくある質問
GASは安全ですか。社内で使わせても問題ありませんか。
プラットフォーム自体はGoogleのインフラ上で動き、コアサービス化以降は他のコアサービスと同じデータ保護と管理者制御の対象です。危険が生じるのは設定のほうで、ウェブアプリの公開範囲、OAuthスコープの広さ、外部への通信先を統制できているかで安全性が決まります。使わせる前に、アプリレポートで現状のスクリプト実行を可視化しておいてください。
ウェブアプリを「全員」に公開すると、スプレッドシートの中身も見られますか。
スプレッドシート自体の共有設定が変わるわけではありません。ただしUSER_DEPLOYINGで公開した場合、スクリプトはオーナー権限で動くため、スクリプトが返す内容はすべて第三者に届きます。シート全体を読んで返す実装なら、実質的に中身が公開されているのと同じです。
APIキーをコードに直接書いてはいけませんか。
書くべきではありません。スクリプトの閲覧権限を持つ全員に見え、コピーされたプロジェクトにも残ります。PropertiesServiceへの退避が基本ですが、前述のとおりプロジェクトの編集権限者からは読めます。キーの価値が高い場合は、GAS側に置かず外部の認証基盤を経由させる設計に切り替えてください。
退職者が作ったGASの自動処理はどうなりますか。
インストール可能なトリガーはトリガー作成者のアカウントの権限で実行されます。アカウントを停止・削除すれば実行も止まるのが通常ですが、業務がその処理に依存していた場合は無言で停止することになる。管理コンソールのアプリレポートで実行が続いているスクリプトを洗い出し、退職前にオーナーを移管するのが確実です。個別に止めたい場合は、管理者側の統制で触れたCloudプロジェクトの削除が最も確実な手段になります。
個人のGoogleアカウントで使う場合も、同じセキュリティ設定になりますか。
スクリプト側の設定（実行ユーザー、公開範囲、OAuthスコープ、PropertiesService）は共通です。違うのは組織側の統制で、監査ログ、アプリレポート、外部接続の許可リスト、アプリのアクセス制御はいずれもGoogle Workspaceの管理コンソールの機能。個人アカウントではこれらが使えず、公開範囲をDOMAINに絞ることもできません。コアサービス化もGoogle Workspaceのお客様が対象です。業務でGASを使うなら、Workspaceのアカウントに寄せてください。
