2026年6月23日、Google Workspace Updates Blog にて GAS (Google Apps Script) が Google Workspace のコアサービスに格上げされたことが公式に発表されました。この記事では、情シス担当者が把握しておくべき設計判断の変化点を整理します。
この記事を読んだほうが良い人
- 社内に GAS スクリプトが複数稼働しており、誰が何を動かしているか把握しきれていない
- GAS のコアサービス化の発表は読んだが、自組織で何を変えるべきか判断できていない
- URLFetch の外部ドメイン許可リストなど、GAS 関連の管理コンソール設定を整備できていない
- GAS が処理するデータのコンプライアンス対応を組織として明確にしたい
Google Apps Script コアサービス化で何が変わるのか
GAS (Google Apps Script) は、Google Workspace の各サービス（Gmail・スプレッドシート・Drive など）を JavaScript で操作できる自動化プラットフォームです。
2026年6月23日以前、GAS はコアサービスの外に位置づけられていました。Gmail や Drive に適用されるデータ保護ポリシーとは別の扱いで、プラットフォームレベルのテクニカルサポートの対象外でもありました。
コアサービス化によって、GAS は Google Cloud Terms of Service および Google Workspace for Education Terms of Service のカバー対象になりました。Google Workspace Updates Blog の公式発表では、次の3点が変化として案内されています。
| 観点 | コアサービス化以前 | コアサービス化以後 |
|---|---|---|
| データ保護 | コアサービスとは別のポリシーが適用 | Gmail・Drive と同等のデータ保護ポリシーが自動適用 |
| 管理コントロール | 基本的なサービス ON/OFF のみ | 詳細な管理コントロールが整備 |
| テクニカルサポート | 対象外（自己解決が前提） | 標準テクニカルサポートの対象に |
公式発表ではあわせて「すでに有効化している組織は新しい保護に自動で登録される。無効化していた組織は、コアサービス化でコンプライアンス上の懸念が解消されたとして再有効化を検討できる」と案内されています。
コアサービス化で変わる情シスの3つの判断軸
1. データ保護ポリシーの自動継承：スクリプトのスコープ棚卸しが必要になる
コアサービス化により、GAS で処理されるデータは Gmail や Drive と同等のデータ保護ポリシーの対象になります。「GAS だから別扱い」という判断が成立しなくなったと考えると分かりやすいです。
情シスが確認すべきは「社内の GAS スクリプトがどのスコープ（権限）を要求しているか」という点です。全メールへのアクセス権限や Drive 内のすべてのファイルを読み書きできる権限を持つスクリプトがそのまま稼働しているなら、コアサービス化をきっかけに必要最小スコープへの絞り込みを検討する時期に入っています。
スコープの棚卸しには、Google Workspace 管理コンソールのレポート機能（監査と調査）や Apps Script の管理者向けダッシュボードが参照先になります。組織全体でどんな権限のスクリプトが動いているかを可視化するところから始めるのが現実的な進め方です。
特に注意が必要なのは、過去に構築してほぼ誰もメンテナンスしていないスクリプトです。退職した担当者のアカウントに紐付いたまま動き続けているスクリプトは、アカウントが無効化されると突然停止するリスクがあるだけでなく、データ保護の観点でも「誰が権限を持っているか分からない」という問題を抱えています。サービスアカウント（専用の非人格アカウント）への権限移行も一つの解決策ですが、まずは棚卸しを完了させることが先決です。
2. GAS URLFetch 許可リスト設計の見直し
GAS の URLFetch サービスは、スクリプトから外部の HTTP エンドポイントにアクセスする機能です。デフォルトでは任意の URL に接続できる設定になっているため、管理されていない状態では意図しない外部へのデータ送信経路になりえます。
管理コンソールのドライブとドキュメント設定から、GAS が接続できる外部ドメインを許可リストとして設定できます。この設定を有効にすると、許可リスト外への接続はスクリプト実行時にエラーを返します。スクリプト全体が停止するかどうかは、コード側の例外処理の実装によって異なります。
情シスの判断軸は「社内の GAS スクリプトがどの外部 URL に接続しているか把握できているか」という点です。把握できていなければ、まず管理コンソールの監査と調査から GAS の外部アクセス履歴を確認し、接続実績のあるドメインを整理した上で必要なものだけを許可リストに登録する流れが自然です。
設定を適用できるエディションは Business Plus・Enterprise Standard/Plus・Enterprise Essentials Plus・Education Standard/Plus・Frontline Plus に限定されています（Google Workspace 管理者ヘルプより）。対象外のエディションでは設定項目が表示されないため、その場合はスクリプトのコードレビュープロセスの整備を代替手段として検討することになります。
許可リストを設定する際に注意すべき点として、既存の稼働スクリプトが使っている外部接続先を事前に洗い出さないと、設定を有効にした直後にスクリプトが一斉にエラーになるリスクがあります。Slack の Incoming Webhook・Google 以外のクラウドサービス API・社内開発のバックエンド API など、GAS 経由で接続しているサービスを一覧化してから設定に進むことが重要です。段階的に導入する場合は、まず特定の OU（組織部門）に限定して許可リストを適用し、問題がなければ全体に展開する方法が現実的です。
3. テクニカルサポート対象化：「プラットフォーム問題」と「コード問題」の線引きを社内で決める
GAS がコアサービスになったことで、プラットフォームレベルの障害（例: GAS 実行インフラの問題）が標準テクニカルサポートの対象になります。ただし、社内の誰かが書いたカスタムスクリプトのバグはサポートの対象外です。
「コアサービスになったから Google に全部任せられる」ではなく、「プラットフォーム自体の挙動に関しては問い合わせできる」というスコープ感が正確です。スクリプトのコード品質・セキュリティ・可用性の責任は引き続き組織側にあります。
情シスが設計判断すべきは「社内 GAS スクリプトの所有者と品質基準を誰が管理するか」という内部ガバナンスの設計です。プラットフォームの安定性については Google が責任を持つようになりましたが、スクリプト自体の中身については従来通り組織側の課題として向き合う必要があります。
内部ガバナンスの出発点として最も手軽なのは、スクリプト台帳をスプレッドシートで管理することです。「スクリプト名 / 用途 / オーナー / 使用スコープ / 外部接続先 / 最終更新日 / 動作確認済み日」程度の項目を用意し、新規スクリプトを作るときは必ず台帳に登録するルールを社内に周知します。台帳を整備しておけば、URLFetch 許可リストを設定する際の接続先リスト作成にも流用できるため、一度作った資産を複数の目的に活用できます。
情シスが今すぐ確認すべきチェックリスト
コアサービス化対応として、優先的に確認する項目を5つ挙げます。
- GAS サービスの有効・無効を確認する: 組織全体または OU 単位で GAS が有効になっているか確認する。コンプライアンス懸念で無効化していた場合、コアサービス化でその懸念が解消されたかを再評価する
- 稼働中スクリプトのスコープを棚卸しする: 誰がどの権限のスクリプトを持っているかを一覧化し、不要なスコープを持つスクリプトは再設計または停止を検討する
- URLFetch の外部接続先を確認する: 管理コンソールの監査と調査から GAS による外部 URL アクセスの履歴を確認し、想定外の接続先がないかチェックする
- URLFetch 許可リストの設定方針を決める: 確認した接続先をもとに「許可する外部ドメイン」を決定し、対象エディションであれば設定を適用する。対象外の場合はコードレビュープロセスの整備など運用面での代替を検討する
- スクリプトのオーナーを明確にする: 担当者の退職などで誰もメンテナンスしていないスクリプトが稼働していないかを確認し、オーナー不明のスクリプトは一時停止を含めて対処を決める
この5項目をすべて完了するまでに、場合によっては数週間かかることもあります。優先度をつけるなら「オーナー不明スクリプトの洗い出し」と「URLFetch 外部接続先の確認」から着手するのが現実的です。この2項目だけでも完了できれば、組織内の GAS リスクの輪郭が大きく明確になります。
GAS ガバナンスを今すぐ見直す理由
GAS がコアサービスになったことは、Google がリスクを肩代わりしてくれるという意味ではありません。データ保護ポリシーの適用範囲が拡張された分、「GAS は社内ツールだから」という曖昧な位置づけのまま放置する余地が狭まりました。
裏を返せば、コアサービス化は組織内に滞留している「誰も把握していない GAS スクリプト」を棚卸しする正当な理由になります。URLFetch 許可リストの整備・スコープ最小化・スクリプトオーナーの明確化をまとめて「コアサービス化対応」として進められるタイミングが今です。
技術的な設定変更より、各部署と「GAS 利用ルールをどう整備するか」を合意形成する仕事のほうが本質的なケースもあります。コードを修正するだけなら技術担当だけで完結しますが、GAS ガバナンスのルールづくりは情シスが主導しなければ前に進みません。GAS に関わるすべてのスクリプトを把握して管理する状態を一度目指してみることを勧めます。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。
「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
※ この記事は DRASENAS Blog の転載です。オリジナルではコードや設定手順が随時アップデートされています。