情報セキュリティ観点から見たこれまでのGASの問題点
Google Apps Script（GAS）は、Google Workspaceを利用する企業にとって非常に便利な自動化・拡張ツールです。Googleスプレッドシートの処理を自動化したり、Gmailを送信したり、Googleフォームの回答を起点に業務フローを動かしたりと、現場の小さな業務改善に大きな力を発揮します。
一方で、情報セキュリティやガバナンスの観点では、これまで扱いが難しい存在でもありました。便利であるがゆえに、現場部門が独自に作成し、情報システム部門や管理者が把握しないまま業務に組み込まれていくケースがあったためです。
特に近年は、生成AIの登場により、非エンジニアでもGASのコードを簡単に作れるようになりました。これにより、GASの活用範囲はさらに広がっています。
そんな中、これは最近の話になりますが、GASがGoogle Workspaceのコアサービスになるというニュースが飛び込んできました。Googleの発表をそのまま引用すると、「GASが正式にGoogle Workspaceのコアサービスとなり、エンタープライズグレードのデータ保護、管理者向け制御、標準サポートの対象になった」とのことです。
ただ、この発表は逆に言えば「これまでGASはエンタープライズレベルのサービスではなかった」とも言えます。
今回は、情報セキュリティ観点から見たこれまでのGASの問題点について解説します。
コアサービス化された背景の考察
生成AIの登場によって生まれたGASの再評価
私はここ数年前まで、そもそもGoogleはGASに対して大きな期待を持っていなかったと考えています。長い間、コアサービスに採用されてこなかったことがそれを証明しています。それが生成AIの登場によって状況が一変しました。
ローコードで動作し、ブラウザベースで簡易的に実行できるというこの手軽さは生成AIと相性が良かったのだと思います。その結果、ユーザーの参入障壁が大幅に下がり、全体の利用率が向上し、GoogleとしてもGASを再評価することになったのだと考えています(※1)。
これまで「GASは便利だが管理しづらい」と考えていた企業も、今後は一律に禁止するのではなく、統制しながら活用する方向へ進んでいくのではないかと考えています。
※1 アクティブユーザー数をシビアにモニタリングし、伸びないと判断した場合容赦無くプロダクトを廃止してきたGoogleが長い年月を経て、GASを正式にコアサービスに採用したことは非常に興味深い事実です。
これまでGASがセキュリティ部門に警戒されてきた理由
去年の話ですが、私は弊社の顧客である企業を10社程ピックアップし、GASの利用状況や課題について、情シス部門にヒアリングする機会を得ることができました。
このヒアリングで分かったのは、GASの利活用よりも「GASを利用することによるセキュリティリスク」に課題を感じている企業が多かったことです。
GASが情シス部門に警戒されてきた理由は、単に「セキュリティホールが存在するコードが生み出されるリスク」だけではありません。
本質的な問題は、GASがGoogle Workspace上の重要な業務データにアクセスできるにもかかわらず、その利用実態が見えにくかった点にあります。
たとえば、ある部門の担当者が、顧客リストを管理するスプレッドシートに対してGASを作成し、定期的にメールを送る仕組みを作ったとします。業務効率化としては有効です。しかし、誰がそのスクリプトを管理しているのか、どのデータにアクセスしているのか、外部サービスに通信していないのか、退職時に誰が引き継ぐのかが曖昧なままだと、企業としては管理できているとは言えません。
GASは、現場改善と相性が良い一方で、情報システム部門の管理外で増えやすい特徴があります。そのため、セキュリティ部門から見ると、シャドーIT化、属人化、過剰な権限付与、監査性の不足といった課題が生まれやすい、管理的には扱いにくいサービスに映ってしまいます。
なぜ企業にとって情報セキュリティが重要なのか
情報セキュリティとは、企業や組織が保有する情報資産を、漏えい・改ざん・消失・不正利用などのリスクから守るための考え方や取り組みの総称です。情報資産には、顧客情報、契約情報、営業資料、設計書、ソースコード、メール、チャット履歴、クラウド上のファイルなど、業務に関わるあらゆるデータが含まれます。
情報セキュリティは、「機密性」「完全性」「可用性」の3要素がベースになります。機密性は、必要な人だけが情報にアクセスできる状態を保つこと。完全性は、情報が正確で改ざんされていない状態を守ること。可用性は、必要なときに情報やシステムを利用できる状態を維持することです。
ただし、実務ではこれだけでは十分ではなく、例えば、利用者や送信元が本物であることを確認する「真正性」、誰がいつ何をしたかを追跡できる「責任追跡性」、後から操作や承認を否認できないようにする「否認防止」、システムが期待どおりに動作する「信頼性」も重要です。
特にGoogle Workspaceのようなクラウド環境では、情報は社内だけでなく外部共有、アプリ連携、自動化処理を通じて広がります。GASは便利な一方で、メール送信、ファイル操作、外部API連携など強力な処理を実行できるため、利便性だけでなく、誰が作成し、どの権限で動き、どの情報にアクセスするのかという情報セキュリティの考え方が不可欠になります。
企業や個人によって異なるGASのセキュリティリスクに関する考え方
まず大前提として、情報セキュリティにはコストがかかります。先ほど「企業はGASのセキュリティリスクに課題を持つ企業が多かった」と書きましたが、これには前提条件があります。
「社員数が数千人以上」や「株式上場している」という共通点を持つ企業です。特に上場する企業になれば、社会的な責任も大きくなり、さらにコーポレートガバナンスコードに沿った企業統治が必要になります。そのため、セキュリティに関しては、ソフトウェアやハードだけでなく、人的資本（社員）にも様々な教育投資を実施しています。
ただ、私が所属する企業も含めて、日本は99%が中小企業であり、情報セキュリティを重要視し、企業の戦略・ガバナンス観点で多額のコストをかけている企業は、（業種によっては偏りはあると思いますが）現状はそう多くはないと思います。
そういった事情から、企業や個人によってGASのセキュリティに関する考え方は異なります。世の中に溢れるGASに関する情報が、情報セキュリティ上の問題点よりも、利便性の部分のみフォーカスされてしまう傾向が高いのは、そのような背景もあると考えています。
GASは個人の責任の範囲で使う分には良いかもしれないですが、企業としてGASを活用していく場合には、セキュリティ・ガバナンスの観点から、運用を設計する必要があると考えています。
情報セキュリティ観点でGASが抱えていた問題点
問題①権限の強さと扱える情報範囲の広さ
GASは、Google Workspace上のさまざまなデータにアクセスできます。GASには、Gmail、Googleカレンダー、GoogleドライブなどのGoogle Workspaceアプリケーション向けの組み込みライブラリが用意されており、それ以外にも30以上の組み込みサービスを通じて、ユーザーデータ、Googleシステム、外部システムと連携することができます。
ここで問題になるのが「権限の広さ」です。GASはユーザーの承認に基づいて動作しますが、ユーザーが承認したスコープによっては、個人のメール、ドライブ、カレンダー、スプレッドシートなどにアクセスできるようになります。
情報セキュリティの観点では、必要最小限の権限で運用することが基本になりますが、現場で作成されるGASでは、権限設計が十分に意識されないことがあります。サンプルコードをコピーして使った結果、本来不要な権限まで要求してしまうケースもあります。
これにより、機密性の低下が発生し、アクセスすべきでない情報までスクリプトが扱える状態になれば、誤送信、誤共有、外部流出のリスクが高まります。
問題②管理者がスクリプトを追跡できない
前述した通り、情報セキュリティでは責任追跡性も重要です。つまり、何か問題が起きたときに、誰が、いつ、何をしたのかを追える必要があります。しかし、GASの利用実態が管理者に見えなければ、問題発生時の調査や再発防止が難しくなります。
一般的な業務システムであれば、システム部門が開発・管理し、ソースコード管理、変更管理、権限管理、監査ログなどを整備します。しかしGASは、個人のGoogleドライブ上に作成されることも多く、現場部門の中で小さな自動化として広がっていきます。
その結果、管理者が以下のようなことを把握しづらい状況が生まれます。
誰がどのGASを作成したのか。
どのスクリプトが現在も動いているのか。
どのデータにアクセスしているのか。
どの外部サービスと通信しているのか。
退職者が作成したスクリプトが残っていないか。
Google Workspaceの管理コンソールでは、ドライブ上の操作ログを確認できるため、管理者はGASをファイルとして捉えた場合のログについては確認することが可能です。
つまり、「誰が作成したのか」は確認することができますが、「どのデータにアクセスしているのか」「どの外部サービスと通信しているのか」のようなログは確認することができません(これまでのGASでは)。
問題③外部サービス連携による情報漏えいリスク
GASはGoogle Workspace内の自動化だけでなく、外部サービスとの連携にも利用できます。たとえば、チャットツールへの通知、外部CRMへのデータ送信、生成AI APIへの問い合わせ、Webhookによるシステム連携などです。
この柔軟性は大きな強みが、情報セキュリティ上は外部送信リスクになります。
特に注意すべきなのは、スプレッドシートやドキュメントに含まれる情報が、GASを通じて外部APIに送信されるケースです。送信先が会社として承認したサービスであればよいですが、個人が試験的に使っているサービスや、利用規約・データ保持方針を確認していないサービスに送られると、情報管理上の問題になります。
生成AIの普及により、このリスクはさらに高まっています。たとえば、GASでシートの内容を読み取り、外部の生成AI APIに投げて要約させるような処理は、技術的には簡単に実装できます。しかし、そのシートに顧客名、契約条件、個人情報、社内機密が含まれていた場合、外部送信の可否を慎重に判断しなければなりません。
GASの外部連携は便利ですが、「どの情報を、どこに、何の目的で送信しているのか」を管理できなければ、機密性を損なう原因になります。
問題④ソースコード管理・変更管理が属人化しやすい
情報セキュリティでは、コードの変更管理も重要です。誰が、いつ、どのような変更を行ったのかを記録し、問題があれば戻せる状態にしておく必要があります。
しかし、GASは個人や小規模チームで作成されることが多く、GitHubなどによるソースコード管理が行われないまま運用されるケースがあります。スクリプトエディタ上で直接修正し、そのまま本番処理が動く状態になっていることも珍しくありません。この場合、次のような問題が起きます。
誤った修正によって業務処理が止まる。
誰が変更したのか分からない。
以前の正常な状態に戻しにくい。
レビューされていないコードが本番実行される。
退職者や異動者しか仕様を知らない。
これは完全性と可用性の問題です。データを誤って更新する、誤った宛先にメールを送る、重要な処理が止まるといった事故につながります。
GASを業務利用するなら、個人の便利ツールとして扱うのではなく、業務システムの一部として、ソースコード管理、レビュー、テスト、リリース手順を整備するのが本来はベターです。
問題⑤トリガー実行による「見えない自動処理」のリスク
GASでは、時間主導型トリガーやフォーム送信時トリガー、スプレッドシート編集時トリガーなどを設定できます。これにより、ユーザーが手動で実行しなくても、自動的に処理を動かせます。
これは便利な一方で、管理されていない場合は「見えない自動処理」になります。
たとえば、毎日深夜に顧客リストを集計して外部に送信するスクリプト、フォーム回答があるたびにメールを自動送信するスクリプト、スプレッドシート更新時にファイル権限を変更するスクリプトなどが、管理者の知らないところで動き続ける可能性があります。
特に問題になるのは、作成者が退職・異動した後もトリガーが残るケースです。処理の目的や仕様を理解している人がいなくなった状態で、自動処理だけが動き続けると、障害時の対応が難しくなります。
情報セキュリティにおける可用性や責任追跡性の観点からも、GASのトリガーは棚卸しが必要です。どのスクリプトが、いつ、誰の権限で、何を実行しているのかを定期的に確認するべきです。
問題⑥個人アカウント依存のリスク
GASは、作成者個人のアカウントや権限に依存して動作することがあります。これも企業利用では注意が必要です。
たとえば、ある社員が自分のアカウントでGASを作成し、部署の業務を自動化していたとします。その社員が異動、休職、退職した場合、スクリプトの管理者が不明になったり、権限変更によって処理が動かなくなったりする可能性があります。
また、個人のドライブに保存されたGASが重要業務を担っている場合、組織としては大きなリスクです。業務システムであるにもかかわらず、管理主体が個人になっているためです。
これは可用性の問題であり、ガバナンスの問題でもあります。企業としてGASを活用するなら、個人アカウントに依存しない管理方法、共有ドライブでの管理、オーナー移管、運用責任者の明確化などが必要です。
GASのGoogle Workspaceコアサービス化で何が変わるのか
ここまで説明してきた問題を解決に導いてくれることを期待したいのが、先日発表されたGASのGoogle Workspaceコアサービス化です。
これは、企業にとって非常に重要な変更です。これまでGASを「便利だが、企業としては使わせにくい」と見ていた組織にとって、契約・サポート・管理の前提が整理されることは大きな安心材料になります。
ただ、Googleのいう「他のコアサービスと同様のエンタープライズグレードのデータ保護、管理者向け制御、標準技術サポートが提供される」の具体が公開されていないため、ここまで説明してきた問題点を具体的にどう解決していくのかを現状示すことができないため、Googleからの続報を待ちたいと思います。
コアサービス化しても解決しない問題
コアサービス化は重要な前進ですが、誤解してはいけない点があります。それは、コアサービス化したからといって、すべてのGASが自動的に安全になるわけではないということです。
たとえば、過剰な権限を要求するスクリプト、外部サービスに機密情報を送信するスクリプト、退職者のアカウントに依存したトリガー、レビューされていないコード、誰も存在を把握していない自動化などは、コアサービス化後もリスクとして残ります。
つまり、コアサービス化は「Google Workspace上で動作するGASが無条件に安全になった」という意味ではありません。これは企業が正式に管理対象として扱いやすくなったという意味で捉えるのが正しいです。
今後重要になるのは、GASを使わせるかどうかではなく、どのようなルールで、どの範囲まで、どのように管理しながら使うかです。
今後Googleに期待したいガバナンス機能
GASがGoogle Workspaceのコアサービスになったことは、企業利用において大きな前進です。ただし、エンタープライズで安心して活用するには、さらに強力なガバナンス機能の拡充が必要だと考えます。
まず期待したいのは、管理コンソール上で組織内のGASを一覧化できる機能です。誰が、いつ、どのスクリプトを作成し、どのGoogleサービスにアクセスし、どのトリガーで動作しているのかを、管理者が一元的に把握できるようにしてほしいです。
次に、OAuthスコープの可視化と制御です。たとえば、Gmail本文の読み取り、Googleドライブ全体へのアクセス、外部通信、カレンダー予定の取得など、リスクの高いスコープを利用する場合は、管理者承認を必須にできる仕組みがあると理想的です。
また、外部通信先の制御も重要です。GASからアクセスされるURLの監視・許可リストの制御、GAS単位・ユーザー単位・組織部門単位で外部通信を管理できる機能も欲しいところです。
スクリプトの変更履歴、実行ログ、エラーログ、実行ユーザー、処理対象データを監査しやすくする機能も重要だと思います。特に、個人情報や機密情報を扱うGASについては、管理者が後から追跡できる状態にしておく必要があります。
理想を言えば、GASにもDLPやアクセスコンテキスト管理と連動した制御がほしいところです。たとえば、個人情報を含むスプレッドシートを外部APIへ送信しようとした場合に警告する、またはブロックする。社外ネットワークからの実行を制限する。高リスクなスコープを使うスクリプトは管理者レビューなしでは実行できない。こうした仕組みがあれば、企業はGASをより安心して活用できます。
GASは現場改善に非常に向いているツールです。だからこそ、現場に任せきりにするのではなく、企業として安全に使えるガバナンス機能の進化を期待したいところです。
