Google Apps Script

解決する課題

サーバーを用意せず、Google Workspace（スプレッドシート・ドキュメント・Gmail・ドライブ・カレンダーなど）を自動化したいときに使えます。

• スプレッドシートやメールに関わる 定型作業を自動化 したいが、専用サーバーやインフラは持ちたくない
• 「毎朝レポートをメール送信」「フォーム回答を別シートへ集計」といった 業務の自動化 を、ローコードで素早く作りたい
• スプレッドシートに 独自メニューやカスタム関数 を足して、利用者の操作を効率化したい
• 簡単な社内向けの Web フォームや簡易 API を、フレームワークやデプロイ基盤なしで公開したい
• 外部 API とスプレッドシートを つなぐ連携処理 を、最小限のコードで実現したい

主要概念と用語

• Apps Script: Google のサーバー上で動く JavaScript ベースの実行基盤。Google Workspace の各サービスへ標準で連携し、ローコードで自動化・拡張を行う
• スクリプトプロジェクト: コードとその設定（マニフェスト）をまとめた単位。ブラウザのエディタで作成・編集する
• マニフェスト（appsscript.json）: 実行ランタイム・タイムゾーン・必要な権限スコープ・依存ライブラリなどを宣言する設定ファイル
• コンテナバインド型／スタンドアロン型: 特定のスプレッドシートやドキュメントに紐づくのがコンテナバインド型、単独で存在するのがスタンドアロン型
• トリガー（Trigger）: コードを起動するきっかけ。ファイルを開いた時などに動く シンプルトリガー（onOpen / onEdit など）と、明示的に登録する インストール型トリガー（時間主導・イベント主導）がある
• 時間主導トリガー: cron のように一定間隔・指定時刻でコードを定期実行する仕組み
• Web アプリとしてのデプロイ: doGet / doPost を実装して URL を公開し、簡易な Web ページや API として動かす形態
• サービス: Apps Script から呼べる API 群。標準提供の 組み込みサービス（SpreadsheetApp・GmailApp など）と、有効化して使う 高度なサービス（Advanced Services）がある
• OAuth スコープ: スクリプトが必要とする権限の範囲。初回実行時に利用者が承認する

仕様・制限・クォータ

• 言語は JavaScript で、モダンな構文に対応する V8 ランタイム 上で動作する
• 1 回の実行には 実行時間の上限 があり、長時間バッチには向かない。重い処理は分割して時間主導トリガーで小分けに回す設計が必要
• メール送信数・外部 HTTP 取得（URL Fetch）回数・トリガーの起動時間など、機能ごとに 1 日あたりの割り当て（クォータ） が設定されている。無償アカウントと Workspace 契約で上限が異なる
• 同時実行数やトリガー数にも上限があり、大量並列処理には不向き
• 具体的な上限値（実行時間・1 日あたりの送信数など）は変更され得るため、断定せず 公式ドキュメントで都度確認する
• スクリプトプロジェクトは背後で Google Cloud プロジェクト に紐づく。高度なサービスや OAuth 同意画面の詳細制御には、既定プロジェクトではなく標準の Cloud プロジェクトへ切り替える

内部の仕組み

Apps Script は、書いたコードを Google のマネージドな実行基盤上で動かします。利用者はサーバーの用意・スケール・パッチ適用を意識する必要がありません。コードはトリガー（手動実行・時間主導・イベント・Web アプリへのリクエスト）をきっかけに起動され、組み込みサービスを通じてスプレッドシートや Gmail などへアクセスします。

• 各組み込みサービス（SpreadsheetApp・GmailApp・DriveApp など）は、対応する Google Workspace の API への高水準ラッパーとして提供される
• スクリプトの実行には OAuth スコープ による承認が必要で、利用者が初回に同意した範囲でのみ各サービスへアクセスできる
• 背後では Google Cloud プロジェクト が紐づき、高度なサービスの有効化や OAuth 設定はその Cloud プロジェクト側で管理される
• 実行は隔離された環境で行われ、状態は基本的に残らない。永続化が必要なデータはスプレッドシートや Properties サービス、外部ストレージに保存する

設計パターン / ベストプラクティス

• 定期処理は時間主導トリガー: 「毎朝集計してメール送信」などの定期実行は、cron 代わりに時間主導トリガーで組む
• 重い処理は分割する: 実行時間の上限に当たらないよう、件数の多い処理はバッチを区切り、複数回に分けて実行する
• API 呼び出しはまとめる: スプレッドシートのセルを 1 件ずつ読み書きせず、範囲（Range）でまとめて取得・更新してクォータと実行時間を節約する
• 設定値や認証情報は Properties に置く: API キーなどをコードへ直書きせず、Properties サービスに保存して分離する
• Web アプリは用途を限定: 簡易フォームや軽い API には向くが、本格的な Web サービスは Cloud Run / App Engine など専用基盤へ寄せる
• 共有が前提なら標準 Cloud プロジェクトへ: チーム配布・高度なサービス利用・OAuth 同意画面の管理が必要なら、既定プロジェクトでなく標準の Cloud プロジェクトに紐づける

運用・監視

• エディタの 実行ログ や Logger / console での出力で、処理の動作と失敗箇所を確認する
• 標準の Cloud プロジェクトに紐づければ、実行ログを Cloud Logging 側でも追跡できる
• トリガーの一覧 から、時間主導・イベント主導の登録状況と直近の実行結果（成功・失敗）を確認する
• 想定どおり動かない → トリガーが有効か、承認スコープが足りているか、実行時間やクォータの上限に達していないかを切り分ける
• クォータ超過のエラーが出る → 1 日あたりの送信数や外部取得回数を見直し、処理の頻度・件数を下げる
• 不要になったトリガーやプロジェクトは整理し、意図しない定期実行を残さない

コスト

Apps Script 自体には基本的に追加の利用料金がなく、Google アカウント／Workspace 契約に含まれる 割り当て（クォータ）の範囲 で利用します。コストの観点は金額よりも「クォータをいかに使い切らないか」が中心になります。

セキュリティ

• スクリプトは OAuth スコープ 単位で権限を要求する。マニフェストで必要最小限のスコープだけを宣言し、過剰な権限要求を避ける
• API キーやトークンを コードへ直書きしない。Properties サービスなどに分離し、共有時の漏洩を防ぐ
• 配布・共有時は、スクリプトを編集できる人と実行できる人の アクセス範囲 を絞る
• Web アプリとして公開する場合、誰がアクセスでき、どのアカウントの権限で実行されるか（実行ユーザーの設定）を必ず確認する
• 高度なサービスや OAuth 同意画面を扱うときは標準の Google Cloud プロジェクト に紐づけ、組織のポリシー配下で管理する

関連サービス・比較

同じ「サーバーレスでコードを動かす」用途でも、Google Workspace の自動化に特化した Apps Script と、汎用のサーバーレス関数である Cloud Functions では位置づけが異なります。

ハンズオン / CLI例

Apps Script はブラウザのエディタで完結しますが、ローカルでコード管理したい場合は公式 CLI の clasp を使えます。

# clasp をインストール（Node.js 環境）
npm install -g @google/clasp

# Google アカウントでログイン
clasp login

# 新しいスタンドアロン型プロジェクトを作成
clasp create --title "my-automation" --type standalone

# ローカルのコードを Apps Script 側へ反映
clasp push

# Apps Script 側のコードをローカルへ取得
clasp pull

# Web アプリとして新しいバージョンをデプロイ
clasp deploy --description "first release"

# 実行ログを確認
clasp logs