便利だけど怖いGASは変わるのか？コアサービス化で期待したい管理者機能

GASのコアサービス化で期待したい管理者向け機能

まず期待したいのは、組織内GASの一覧化

最も期待したいのは、管理者が組織内で作成・実行されているGASを一覧で把握できる機能です。これまでGASは、個人のマイドライブ上に作成されたり、スプレッドシートに紐づくコンテナバインドスクリプトとして作成されたりすることが多く、管理者が全体像を把握しにくいという課題がありました。

誰が、いつ、どのスクリプトを作成したのか。現在も動いているスクリプトはどれか。どのファイルに紐づいているのか。どのユーザーの権限で実行されているのか。こうした情報が管理コンソール上で一覧化されれば、GASのシャドーIT化を大きく抑制できます。

GASの問題は、単に危険なコードが存在することではありません。管理者が存在を知らないまま、自動処理が動き続けてしまうことです。業務に深く入り込んだGASほど、担当者が異動・退職した後にブラックボックス化しやすくなります。

そのため、管理者向けには「組織内のGAS台帳」のような機能が必要です。スクリプト名、作成者、最終更新者、実行状況、紐づくファイル、利用スコープ、トリガー、外部通信の有無などを一覧で確認できれば、GASを業務システムの一部として管理しやすくなります。

OAuthスコープの可視化と制御

次に期待したいのは、OAuthスコープの可視化と制御です。GASは、Gmail、Googleドライブ、Googleカレンダー、スプレッドシートなど、Google Workspace上のさまざまなデータにアクセスできます。この柔軟性はGASの大きな魅力ですが、企業利用ではリスクにもなります。たとえば、Gmail本文の読み取り、Googleドライブ全体へのアクセス、外部URLへの通信、カレンダー情報の取得などは、扱い方を誤ると情報漏洩につながりかねません。

理想としては、管理者が組織単位で「許可するスコープ」「警告対象にするスコープ」「管理者承認が必要なスコープ」「禁止するスコープ」を設定できるようにな制御機能が強く求められます。

たとえば、単純なスプレッドシート内の計算処理であれば自由に利用可能にする。一方で、Gmail本文の読み取りや外部APIへの送信を伴うGASは管理者承認を必須にする。こうした段階的な制御ができれば、GASを一律禁止するのではなく、リスクに応じて使い分けることができます。

今後の企業利用では、「GASを使えるかどうか」ではなく、「どの権限まで使ってよいか」を管理する発想が重要になります。

情報漏洩リスクが高い外部通信先の制御

GASで特に注意すべきなのが、外部サービスとの連携です。

GASはUrlFetchAppなどを使うことで、外部APIやWebhookに情報を送信できます。これは非常に便利です。SlackやGoogle Chatへの通知、CRMとの連携、外部システムへのデータ登録、生成AI APIへの問い合わせなど、業務自動化の幅が大きく広がります。しかし、外部通信は情報セキュリティ上の重要な論点です。スプレッドシートに含まれる顧客情報、契約情報、個人情報、社内機密が、GASを通じて外部サービスへ送信される可能性があるためです。そのため、管理者向けには外部通信先を制御する機能が求められます。

具体的には、GASからアクセスできる外部ドメインを許可リスト方式で制御する機能です。たとえば、会社として承認済みのSaaSやAPIエンドポイントには通信を許可し、それ以外の未知の外部サービスへの通信はブロックまたは管理者承認にする、といった運用です。

さらに、どのGASが、いつ、どの外部URLに通信したのかをログとして確認できることも重要です。外部通信そのものをすべて禁止すると現場の利便性が落ちますが、通信先を可視化し、必要に応じて制御できれば、安全性と利便性を両立できます。

トリガーの一元管理

GASには、時間主導型トリガー、フォーム送信時トリガー、スプレッドシート編集時トリガーなどがあります。これにより、ユーザーが手動で実行しなくても、処理を自動的に動かせます。この仕組みは便利ですが、管理されていない場合は「見えない自動処理」になります。

たとえば、毎日深夜に顧客リストを集計してメール送信するGAS、フォーム回答を受けて外部システムにデータを送るGAS、スプレッドシートの編集をきっかけにファイル権限を変更するGASなどが、管理者の知らないところで動き続ける可能性があります。

特に問題になるのは、作成者が退職・異動した後もトリガーだけが残るケースです。仕様を理解している人がいないにもかかわらず、処理だけが動き続ける状態は、障害対応や監査の観点で大きなリスクになります。

そのため、管理者が組織内のトリガーを一覧で確認し、必要に応じて停止・削除・オーナー変更できる機能があると非常に有用です。「誰の権限で」「いつ」「どの処理が」「何を対象に」実行されるのか。これを把握できるだけでも、GASの運用リスクは大きく下がります。

実行ログと監査ログの強化

GASを企業で利用する場合、問題発生時に追跡できることが重要です。誰が実行したのか。どの関数が実行されたのか。成功したのか、失敗したのか。どのファイルやデータにアクセスしたのか。外部通信を行ったのか。エラーが発生した場合、どのような内容だったのか。

こうした情報を管理者が確認できなければ、事故が起きた後の原因調査が難しくなります。現場の小さな自動化であっても、業務データを扱う以上、監査性は必要です。特に、個人情報、契約情報、請求情報、営業情報などを扱うGASについては、実行ログや変更履歴が追える状態になっていることが望ましいです。

理想的には、Google Workspaceの監査ログとGASの実行ログが連携し、管理コンソール上で検索・エクスポートできるようになるとよいと思います。これにより、GASを「個人が作った便利ツール」ではなく、「監査可能な業務自動化基盤」として位置づけやすくなります。

DLPやアクセスコンテキスト管理との連動

さらに期待したいのは、GASとGoogle Workspaceのセキュリティ機能との連動です。たとえば、DLPと連動し、個人情報や機密情報を含むスプレッドシートの内容を外部APIへ送信しようとした場合に警告またはブロックする。アクセスコンテキスト管理と連動し、社外ネットワークや未管理端末からの高リスクなGAS実行を制限する。こうした制御ができれば、GASの安全性は大きく向上します。

GASはGoogle Workspaceのデータに近い場所で動く自動化基盤です。だからこそ、単独のスクリプト管理だけでなく、Workspace全体のセキュリティポリシーと連動することが重要です。

今後は、GASを単なる開発ツールとして見るのではなく、Workspace上のデータを処理する実行基盤として捉える必要があります。その前提に立つと、DLP、監査ログ、アクセス制御、外部共有制御などとの統合は、非常に重要なテーマになります。

コアサービス化はゴールではなくスタート

GASのコアサービス化は、企業利用において非常に大きな前進です。Googleによれば、GASはすべてのGoogle Workspace顧客に対してコアサービスとして提供され、すでに有効化している管理者には追加対応は不要とされています。過去にコンプライアンス、セキュリティ、サポート上の懸念から制限していた場合も、改めて有効化を検討できる位置づけになりました。

ただし、コアサービス化したからといって、すべてのGASが自動的に安全になるわけではありません。過剰な権限を要求するスクリプト、外部サービスへ機密情報を送信するスクリプト、退職者のアカウントに依存したトリガー、レビューされていないコード、誰も存在を把握していない自動処理は、コアサービス化後もリスクとして残ります。

重要なのは、GASを禁止するか許可するかという二択ではありません。どのようなルールで、どの範囲まで、どのように管理しながら使うかです。

GASは、現場の業務改善に非常に強いツールです。生成AIの普及によって、その活用範囲はさらに広がっていくでしょう。だからこそ、企業には「自由に使わせる」だけでなく、「安全に使える環境を整える」ことが求められます。

今後、管理コンソールでのGAS一覧化、OAuthスコープ制御、外部通信先の管理、トリガーの棚卸し、実行ログの強化、変更管理、DLP連動などが拡充されれば、GASはより安心して企業内に展開できる自動化基盤になるはずです。

GASのコアサービス化は、終着点ではありません。むしろ、これから企業がGASを本格的に管理し、活用していくためのスタート地点だと考えています。