Apps Script Webアプリを公開するときは、「誰がURLを開けるか」と「スクリプトが誰の権限で動くか」を別々に決めます。アクセスできる利用者を絞っても、実行主体がオーナーなら、そのスクリプトはオーナー権限でGoogleサービスへアクセスする設計になり得ます。逆に、利用者として実行する設定では、その人の認証・権限・OAuth同意が処理結果に影響します。URLを知っている人の範囲だけで安全性を判断せず、処理対象のデータ、必要なscope、実行主体、利用者の公開範囲を表にしてからdeploymentを作成します。
目次
【先に決める2つの軸】
表は横にスクロールできます
| 軸 | 選択時に答える問い | 影響するもの |
|---|---|---|
| 実行主体 | スクリプト所有者か、アクセスする利用者か | Drive/Sheets等の呼び出し権限、OAuth同意、データの記録主体 |
| アクセス対象 | どのアカウントや組織がWebアプリを開けるか | 認証要求、利用者の範囲、URLを共有できる相手 |
この2軸は独立しています。例えば「ドメイン内の人だけがURLを開ける」と設定しても、データアクセスを実行者権限に切り替えたとは限りません。また「アクセスユーザーとして実行」でも、公開範囲を意図せず広げれば安全とはいえません。
【実行主体の違い】
所有者として実行すると、アクセスする人に関係なくスクリプトはデプロイしたユーザーの権限で動きます。利用者が対象スプレッドシートを直接開けなくても、スクリプトが所有者権限で読み取る設計なら結果を表示する可能性があります。このため、利用者別のアクセス制御、表示データの絞り込み、入力の検証、監査記録をアプリ側で適切に設計しないと、URL利用者へ過剰なデータを返す危険があります。所有者として動かす場合は「どの利用者に、どのデータを、どの処理で返すか」をサーバー側で明確に制限します。ブラウザー側の画面非表示だけをアクセス制御にしないでください。
アクセスユーザーとして実行すると、処理はアクティブユーザーの権限を使い、そのユーザーへOAuth consentが表示される場合があります。Googleの現行ガイドは、granular OAuth permissionsで必要scopeを利用者が選択的に許可・拒否する可能性に触れ、必要scopeが付与されているかを確認する方法も案内しています。利用者が権限を持たないデータへアクセスできるようになるわけではありません。ユーザー数が多い場合、各利用者の認証やscope付与、アカウント状態を運用する必要があります。
【設定前の設計表】
表は横にスクロールできます
| 処理内容 | 対象データ | 必要な権限 | 実行主体候補 | アクセス範囲 | テスト条件 |
|---|---|---|---|---|---|
| 例：申請者が自分の申請を登録 | 申請用sheetの必要列 | 追加先への書込 | 所有者または利用者 | 組織内利用者 | 他人の行を読めないことを確認 |
| 例：管理者向け一覧表示 | 管理対象records | 管理者の閲覧権限 | 利用者として実行が候補 | 管理者グループ | 一般利用者が開けないことを確認 |
| 例：公開フォームから問い合わせ受付 | 入力と受付先 | 受付先への追記 | 所有者実行を検討する場合あり | 公開範囲とspam対策を限定 | 不正入力、連投、個人情報の扱いを確認 |
この表は設計の例で、特定の設定を推奨するものではありません。実際に必要なscope、認証方式、公開対象は、利用するサービス、組織のWorkspace設定、契約条件で変わります。
【デプロイ前の確認手順】
- doGetまたはdoPostと返却内容を確認する
Webアプリは、GETに応答するdoGet(e)、POSTに応答するdoPost(e)などの入口関数と、HTML serviceのHtmlOutputまたはContent serviceのTextOutputを返す構造が必要です。query parameterやPOST bodyに個人情報・秘密値を含めない設計にし、不要な入力を処理しないよう検証します。URL parameterは利用者に見えるため、認証情報やprivate dataを入れません。
- 呼び出すGoogleサービスを列挙する
Spreadsheet、Drive、Gmail等のサービス、read/writeするファイル、保存先、実行回数を具体的に記録します。スクリプトに要求するOAuth scopeは処理に必要な範囲へ絞り、manifestや認可画面で期待しないscopeがないか確認します。公開利用者が増えても、scopeが安全になるわけではありません。
- 実行主体を機能要件から決める
各利用者が自分の権限でデータへアクセスする必要があるか、共通の受付先へ書き込むなど所有者権限が必要かを判断します。オーナー権限を使うなら、利用者の入力を検証し、利用者ごとに許可された範囲だけを返すこと、管理・監査ログ、担当者不在時の運用を確認します。利用者権限にするなら、承認されないscopeやアクセス拒否時の説明・停止条件を設けます。
- URLを利用できる人の範囲を決める
Google Apps Scriptのdeployment設定で、アクセス対象者として表示される選択肢を確認します。個人アカウント、組織内アカウント、広い公開などの条件や選択肢は、アカウント種別・Workspace管理設定で異なることがあります。共有リンクはアクセス許可の代わりにならず、URL転送後も認証と権限チェックが働くか確認します。
- テスト用deploymentで最小ユーザーを試す
GoogleのTest deploymentsは、URLが/devで終わり、編集権限があるユーザーのみアクセスでき、最新の保存コードを動かすテスト用途とされています。これは一般利用者向けの公開確認と同じではありません。編集者、想定利用者、権限のないテストアカウントを区別し、表示・読み書き・認証・拒否の結果を記録します。
- 公開前に失効・停止方法を確認する
deployment URL、対象project、owner、公開範囲、認可scope、変更担当、停止・更新担当を台帳に残します。古いdeploymentを放置しないよう、利用停止や新バージョンへの切替手順も確認します。プロジェクトの所有者が別domainへ移るなど、アカウント・共有driveの状態変化でdeploymentが動かなくなる条件も公式資料で確認します。
【共有ドライブでは「所有者」を誰と読むか】
Googleの現行Web Apps資料は、共有ドライブ内のスクリプトには所有者がいないため、「自分として実行」でデプロイすると、デプロイしたユーザーの権限で動くと説明しています。共有ドライブを組織が所有することと、Webアプリが無条件に組織全員の権限で実行されることは同じではありません。Google：Web Apps — Permissions（新しいタブで開く）
この記事でいう所有者実行の説明を共有ドライブへ当てはめるときは、実際のデプロイ実行者を確認します。
表は横にスクロールできます
| 配置・設定 | 確認する主体 | 記録すること |
|---|---|---|
| 個人所有のスクリプトを自分として実行 | デプロイに使うユーザー | 対象ファイルへのアクセスと必要scope |
| 共有ドライブ内を自分として実行 | そのWebアプリをデプロイしたユーザー | deploy担当と、実行に使われる権限 |
| アクセスするユーザーとして実行 | 各利用者 | 本人の認可と対象データの権限 |
共有ドライブへ置けば担当者の権限確認が不要になる、という設計にはしません。異動・退職・担当変更に備え、deployment ID、実行設定、デプロイ担当、対象データ、保守担当を関連付けます。設定を変える前に、一般利用者と権限のない利用者の両方で期待する結果を確認できる検証計画を用意します。
この節は公式資料に基づく権限モデルの説明です。実際の共有ドライブやWorkspaceで実行主体を検証した結果ではありません。
【オーナー権限を使う場合の注意】
サーバー側でowner権限を使うWebアプリでは、ユーザーが入力したIDやファイル nameをそのまま検索・返却に使わないようにします。利用者が書き換えられる値を、アクセス制御の根拠にしてはいけません。認証済み利用者の識別、対象データとの関連付け、操作の許可、返す列・行、異常入力の拒否をサーバー側で確認します。OAuth tokenをクライアントへ返さないこともGoogleの公式案内で警告されています。
例として、全社が使う申請フォームがowner権限で共通sheetへ書く場合、送信者が他の申請を読み出すAPIを持っていないか、送信先sheetの共有設定が誰に見えるか、入力値に数式・URL・想定外サイズがないかをテストします。ownerが変更・退職したときの保守担当、Google Workspace管理者がdeploymentを止める方法も含めます。共通処理を作ることと、全利用者へデータ閲覧権限を与えることは別の設計です。
【利用者権限で実行する場合の注意】
ユーザー本人の権限で動かすなら、利用者が必要なファイルへアクセスできるか、ファイル共有とApps Script scopeが別々に承認されているかを検証します。Googleのconsent画面でscopeを拒否した場合、アプリは権限不足として停止・説明できる必要があります。scopeが不足する状態で処理を続けたり、別のowner権限へ切り替えて回避したりしないでください。新規ユーザーのauthorization rateにもApps Scriptの制限があるため、大人数に展開する前に公式の現在条件を確認します。
【公開前のテストケース】
・許可された利用者が期待する画面を開ける
・ログインしていない利用者または対象外アカウントは、設計した通り拒否される
・別の利用者IDやファイル IDへ書き換えても、許可されていないデータを読めない
・必要scopeを拒否したとき、何ができないか説明し、安全に停止する
・処理失敗時に個人情報、OAuth token、秘密値を画面やログへ出さない
・入力を二重送信・空送信・不正形式で送っても、想定外の更新にならない
・owner実行なら、ownerが見られる範囲とユーザーに返す範囲が区別されている
・公開URLを別アカウントへ転送しても、アクセスpolicyが維持される
実データではなくtest sheet・dummy recordsを使い、結果をテスト担当、account種別、実施日とともに記録します。
【判断に迷ったとき】
「owner実行なら認証不要」「アクセスユーザー実行なら全て安全」といった短いルールで選ばないでください。利用者の主体、対象データ、実行権限、公開範囲、必要なOAuth scopeをセットで確認します。権限モデルが説明できない、個人情報をowner権限で扱う、匿名アクセスが必要、またはscopeが広すぎる場合は、公開範囲を広げず、Workspace管理者・Security担当と設計を確認します。
【次の行動】
まずWebアプリの利用者、処理対象、読み書き範囲を設計表へ記入します。次に、実行主体とアクセス対象者を別々に決め、OAuth scope、公開URL、データ所有者、テストユーザーを確認します。テストでは、許可ユーザーだけでなく権限のないアカウントの拒否も確かめます。scopeやdata boundaryを説明できなければ本番deploymentへ進まず、権限者と設計を見直してください。
Sources（確認日：2026-10-15）
・Google Apps Script, Web Apps: https://developers.google.com/apps-script/guides/web（新しいタブで開く） (last updated 2026-09-03 UTC)
・Google Apps Script, Web apps and API executables manifest resource: https://developers.google.com/apps-script/manifest/web-app-api-executable（新しいタブで開く）
・Google Apps Script, Create and manage deployments: https://developers.google.com/apps-script/concepts/deployments（新しいタブで開く）