GASのWebアプリ化｜doGet・公開範囲・画面作り

GASのWebアプリ化とはスクリプトにURLを持たせて、ブラウザから開けるようにすることです。doGetという関数を用意して公開すると、同僚にスプレッドシートの操作を覚えてもらわなくても、ブラウザの画面から使ってもらえます。

doGetでWebアプリを公開する手順と、社外に公開してしまう事故を防ぐ公開範囲の決め方を紹介します。HTML Serviceで簡単な画面を作る方法も合わせて扱います。公式ドキュメントの内容は2026年10月時点のものです。コードはApps Scriptの上では動かしていません。Node.jsの代用オブジェクトで、関数の戻り値と成功・失敗時の文字列の受け渡しだけを確認しています。実際の画面表示、認証、デプロイは未確認です。

GASのWebアプリ化とdoGetの役割

Webアプリとして公開できる条件は、公式ドキュメントに2つ書かれています。URLのパラメータの受け取り方と合わせて見ます。

• 公開できる2つの条件
• URLのパラメータを受け取る

公開できる2つの条件

公式によると、スクリプトをWebアプリとして公開するには、doGet関数またはdoPost関数があり、その関数がHTML ServiceのHtmlOutputか、Content ServiceのTextOutputを返す必要があります。ブラウザでURLを開いたときはdoGetが、プログラムからPOSTで送られたときはdoPostが動きます。

URLのパラメータを受け取る

URLの末尾に ?name=山田 のように付けた値は、doGetの引数 e のe.parameterで受け取れます。次の例は名前を受け取って挨拶を返します。

function doGet(e) {
  const name = e.parameter.name || 'ゲスト';
  return ContentService.createTextOutput('こんにちは、' + name + 'さん');
}

代用の環境では?name=山田 のときは「こんにちは、山田さん」、パラメータなしのときは「こんにちは、ゲストさん」を返しました。

c と sid は、システムが使う名前なので、URLのパラメータには使えません。公式によると、使うとHTTP 405のエラーになることがあります。

GASのWebアプリの権限｜アクセスできるユーザーと実行するユーザー

公開範囲の設定は「誰が開けるか」と「誰の権限で動くか」の2つです。公式のマニフェストでは access と executeAs という名前で、決まった値が定められています。

• アクセスできるユーザー（access）
• 実行するユーザー（executeAs）
• 安全な組み合わせの選び方
• 「自分として実行」のときの注意

アクセスできるユーザー（access）

表のうち、社外の人が開けるのはANYONEとANYONE_ANONYMOUSの2つです。この2つを選ぶのは、誰に見られてもよいページだけにします。

実行するユーザー（executeAs）

USER_DEPLOYINGはデプロイした人の権限で動かす設定です。公式によると、誰が開いても、常にスクリプトの持ち主として動きます。USER_ACCESSINGは開いた人本人の権限で動かす設定です。後者では、ユーザーが承認するとき、スクリプトの持ち主のメールアドレスが表示されると説明されています。

持ち主の権限で動かすと、開いた人にシートを見る権限がなくても、スクリプトはシートを読めます。便利な反面、アクセスできる人を広げるほど、自分の権限を広く貸すことになります。

安全な組み合わせの選び方

筆者なら、社内向けはまずDOMAIN と USER_ACCESSING の組み合わせから始めます。開いた人本人の権限で動く、という公式の説明にもとづく選び方です。DOMAIN は「同じドメインのユーザー」を指すので、会社のGoogle Workspaceのアカウントで作る場合の選択肢です。

この設定はプロジェクトの appsscript.json にある webapp という項目に、次の形で書かれます。デプロイ画面の日本語の項目名は確かめていないので、この記事では公式の値の名前で説明しています。

{
  "webapp": {
    "executeAs": "USER_ACCESSING",
    "access": "DOMAIN"
  }
}

「自分として実行」のときの注意

公式のSessionクラスの説明によると、「自分として実行」でデプロイしたWebアプリでは、アクセスした人のメールアドレスを、getActiveUser から取れません。開発者本人が実行する場合や、同じGoogle Workspaceドメインのユーザーには、この制限は通常当てはまらないとも書かれています。

そのため、メールアドレスで許可する人を絞るコードを書いても、意図どおりに動かない場合があります。絞り込みはコードではなく「アクセスできるユーザー」の設定で行います。

GASのWebアプリのデプロイ｜テスト用と公開用

デプロイには、テスト用と公開用があります。公式の手順に沿って、順に進めます。

• ① テスト用URLで動かす
• ② 新しいデプロイで公開する
• ③ 更新と古いデプロイの整理

① テスト用URLで動かす

エディタ右上の［デプロイ］＞［テスト］（英語表示では Deploy > Test deployments）で、種類にウェブアプリを選び、表示されたURLをブラウザに貼ります。公式によると、このURLは /dev で終わり、スクリプトの編集権限を持つ人だけが開けます。いつも最後に保存したコードで動くので、開発中のテスト専用です。

② 新しいデプロイで公開する

1. エディタ右上の［デプロイ］＞［新しいデプロイ］をクリックする
2. ［種類の選択］の横の歯車から、［ウェブアプリ］を選ぶ
3. ［デプロイ構成］の欄に、説明と、実行するユーザー・アクセスできるユーザーを入れる
4. ［デプロイ］をクリックする
5. アクセス権を渡した相手に、表示されたURLを共有する

公式は一般に公開するときはバージョン付きのデプロイを使うよう説明しています。テスト用の /dev のURLを、同僚に配る用途には使いません。初回の承認で止まったら、許可が必要なサービスと、組織の管理者が制限していないかを確認します。許可されないアカウントのために、公開範囲を全員へ広げないようにします。

③ 更新と古いデプロイの整理

コードを直したあとは、新しいバージョンを作り、既存のデプロイを編集して、そのバージョンに切り替えます。公式はこれがURLやデプロイIDを変えずにアプリを更新する標準の方法だと説明しています。

「新しいデプロイ」を作るたびに、別のURLが増えます。この点が事故のもとになります。公式によると、有効なバージョン付きデプロイは同時に複数持てて、削除はできず、アーカイブだけできます。公開範囲を絞り直したつもりでも、古いデプロイが有効なまま残っていれば、そのURLは古い設定で開ける可能性があります。［デプロイ］＞［デプロイを管理］で一覧を開き、使わないものはアーカイブします。

GASのWebアプリの画面｜HTML Serviceと非同期通信

HTML ServiceではHTMLファイルをブラウザへ返すことができます。最初は共有シートを読まず、固定の文字を返すだけの接続テストにすると、権限とデータ取得の問題を分けて確認できます。

• HTMLを返すサーバー側の関数
• 成功と失敗を受け取る画面
• 画面を付けても残る権限の注意

HTMLを返すサーバー側の関数

Code.gsには次の関数を置きます。ここまでの挨拶用doGetを試したプロジェクトでは、doGetを2つ残さず差し替えます。同じ名前の関数を併記すると、どちらが使われるか分かりにくくなります。

function doGet() {
  return HtmlService.createHtmlOutputFromFile('Index')
    .setTitle('接続テスト');
}

function getMessage() {
  return '接続できました';
}

createHtmlOutputFromFileのIndexは、次に作るHTMLファイルの名前です。getMessageは固定の文字列を返すだけで、スプレッドシートのIDやAPIキーは不要です。

成功と失敗を受け取る画面

HTMLファイルを追加し、名前をIndexにします。入力は次の例です。google.script.runは非同期なので、呼び出し直後の行で結果を読まず、成功時の関数で表示を変えます。

<!DOCTYPE html>
<html>
  <head><base target="_top"></head>
  <body>
    <p id="message">読み込み中です</p>
    <script>
      google.script.run
        .withSuccessHandler(function (text) {
          document.getElementById('message').textContent = text;
        })
        .withFailureHandler(function () {
          document.getElementById('message').textContent = '読み込めませんでした';
        })
        .getMessage();
    </script>
  </body>
</html>

成功はwithSuccessHandler、失敗はwithFailureHandlerで受け取ります。Node.jsの代用環境で確認した文字列は次の2つです。GAS上の実行結果ではありません。

成功時: 接続できました
失敗時: 読み込めませんでした

textContentは文字として表示するための代入先です。この例では固定文だけを返しています。入力値やシートの値をHTMLとして組み立てる処理を足す場合は、別途その扱いを確認します。

画面を付けても残る権限の注意

画面にボタンを置いていない関数でも、サーバー側で何が呼べるかを考えます。公式には、名前がアンダースコアで終わる関数はgoogle.script.runから呼べないとあります。ただし、末尾に_を付けることだけでアクセス制御全体が完了するわけではありません。

業務データを返すときは、呼び出す人にそのデータを見せてよいかをサーバー側でも確認します。画面で非表示にするだけでは、返してしまったデータの保護にはなりません。最初の公開テストには個人情報の入っていない専用データを使います。

GASのWebアプリの公開前チェックリスト

公開範囲を決めたら、URLを配る前に、次の項目を確かめます。

誰が開けるかは設定で決め、別のアカウントで開いて確かめる。設定の指定と、実際に開ける範囲の両方を確認します。コードが返すデータや認可も別に点検します。最後の項目は公式の手順ではなく、筆者が勧める確認方法です。

GASのWebアプリ｜よくある質問

Webアプリの公開について、よくある疑問をまとめました。

Webアプリにすると、社外の人にも見られてしまいますか？

アクセスできるユーザーの設定しだいです。社外の人が開けるのは、ANYONE（ログインしているすべてのユーザー）と、ANYONE_ANONYMOUS（ログインしていない人を含む全員）です。MYSELF と DOMAIN なら、自分か同じドメインの人に限られます。

URLを知らなければ、他の人に開かれませんか？

公式はURLを共有する相手を、アクセス権を渡したユーザーとして説明しています。URLを秘密にすることだけに頼らず、アクセスできるユーザーの設定で絞ります。

GASのWebアプリの公開範囲と別アカウントでの確認

GASのWebアプリ化で押さえる点を整理します。

最初は、自分だけが開ける設定と、テスト用のURLで画面を作り、動きを確かめてから公開範囲を広げていくのが近道です。

関連する話題は次の記事でも扱っています。

• GASでWordPress下書きを作る手順
• 技術記事の検証環境と出典の書き方
• GASとは？できること・始め方・学習順を初心者向けに解説

参考資料
ウェブアプリ | Apps Script
デプロイの作成と管理 | Apps Script
ウェブアプリのマニフェスト | Apps Script
HTML Service | Apps Script
HTML Serviceとサーバー通信 | Apps Script