シャドーITの温床から管理されたインフラへの転換
これまでの章では、開発効率や機能実装の側面に焦点を当ててきましたが、Google Apps Script（GAS）を組織全体で運用する場合、避けて通れないのがセキュリティとガバナンスの課題です。GASは、Googleアカウントさえあれば誰でも手軽に開発を始められるという利点がある一方で、情報システム部門が関知しないところで業務上重要なツールが乱立する「シャドーIT」の温床となりやすい性質を持っています。個人レベルのツールであれば許容されたリスクも、組織のデータを扱うシステムとなれば話は別です。
退職者のアカウントに紐付いたスクリプトが突然停止して業務が滞る、過剰な権限を持ったスクリプトが悪用されて情報漏洩が発生する、といった事態は現実に起こり得ます。企業利用に耐えうるシステムとしてGASを運用するためには、開発者と情報システム担当者が協力し、適切な統制環境を構築する必要があります。本章では、GASを単なる便利ツールではなく、企業のITインフラの一部として安全に管理・運用するための高度なセキュリティ対策とガバナンス設計について解説します。
最小権限の原則に基づくOAuthスコープの厳格な管理
GASスクリプトを実行する際、初回に「権限の承認」を求められた経験は誰しもあるはずです。このとき、多くの開発者は提示されたスコープ（権限範囲）を無意識に承認してしまいがちですが、企業ユースにおいてはここに重大なリスクが潜んでいます。デフォルトの設定では、例えばスプレッドシートを操作するメソッドを一行書いただけで、そのユーザーが持つ「すべてのスプレッドシートの閲覧・編集権限」をスクリプトに要求することがあります。これは、万が一スクリプトが悪用された場合、そのユーザーのマイドライブ内の全ファイルが危険に晒されることを意味します。これを防ぐためには、「最小権限の原則」を徹底する必要があります。
具体的には、マニフェストファイル（appsscript.json）を直接編集し、oauthScopesフィールドに必要な権限のみを明示的に記述します。例えば、全ファイルへのアクセス権ではなく、現在アクティブなスプレッドシートのみを操作できる @currentonly などの限定的なスコープを指定することで、セキュリティリスクを大幅に低減できます。開発者は自動付与されるスコープに甘んじることなく、意図した権限のみが要求されているかを常にレビューする義務があります。
標準Google Cloudプロジェクトとの紐付けによる管理レベルの向上
織が管理する「標準のGoogle Cloudプロジェクト」に紐付ける（バインドする）ことで、管理レベルを格段に引き上げることができます。標準プロジェクトへ切り替えることにより、GASの実行ログをCloud Loggingに転送して長期保存したり、Cloud Monitoringを用いてエラー検知のアラートを設定したりすることが可能になります。また、後述するSecret Managerなどの高度なGoogle CloudサービスをGASから直接利用するためにも、この紐付け作業は必須となります。
情報システム担当者の視点では、GASをGoogle Cloudのいちリソースとして管理下に置くことで、利用状況の可視化や課金管理、IAM（Identity and Access Management）によるきめ細かな権限統制が可能となり、ガバナンスを効かせやすくなります。企業で本格的なGAS開発を行う際は、デフォルトプロジェクトのまま運用せず、必ず管理されたGoogle Cloudプロジェクトへの移行を行うべきです。
サービスアカウントの活用と実行主体の分離
GASにおける最大の運用リスクの一つに、スクリプトの実行権限が「ユーザー」に依存している点が挙げられます。定期実行トリガーを設定した社員が退職や異動でアカウントを削除されると、そのトリガーも停止し、業務フローが突然寸断されるというトラブルは後を絶ちません。
この問題への恒久的な対策として、Google Cloudの「サービスアカウント」の概念を理解し、活用することが推奨されます。GAS自体は直接的にサービスアカウントとして動作することはできませんが、GASからGoogle CloudのAPIを呼び出す際や、外部システムからGASをWebhookとして呼び出す際の認証にサービスアカウントを利用することで、特定個人のアカウントへの依存を排除できます。
また、AppSheetなどのノーコードツールと連携させる場合も、データソースへのアクセス権をサービスアカウントに集約することで、人事異動の影響を受けない堅牢なシステムを構築可能です。開発者は「誰が実行するのか」という視点から脱却し、「システムが実行する」アーキテクチャを設計する必要があります。
Secret Managerによる機密情報のセキュアな管理
外部APIとの連携に使用するAPIキーやアクセストークン、データベースの接続パスワードなどの「機密情報」の扱いは、セキュリティ上の最重要課題です。これまでの章でScript Properties（スクリプトプロパティ）の使用を紹介しましたが、企業利用の観点ではこれでも不十分な場合があります。
スクリプトプロパティは、そのGASプロジェクトに編集権限を持つユーザーであれば誰でも閲覧できてしまうためです。より高いセキュリティレベルを確保するために、Google Cloudの「Secret Manager」を利用しましょう。Secret Managerは機密情報を暗号化して保存・管理する専用のサービスです。
GASを標準Google Cloudプロジェクトに紐付けた上で、Secret Manager APIを有効化すれば、コード内からはシークレットの名前を指定するだけで安全に値を取得できます。この方法であれば、GASの編集権限を持つ開発者であっても、Google Cloud側でSecret Managerへのアクセス権限が付与されていなければ機密情報を閲覧することはできません。コードと機密情報を完全に分離し、権限管理を厳格化することが、情報漏洩を防ぐ最後の砦となります。
外部ライブラリの利用制限とサプライチェーンリスク対策
GASには、世界中の開発者が公開しているライブラリをID一つで導入できる便利な機能がありますが、企業利用においてはこれが「サプライチェーンリスク」となります。悪意のある第三者が作成したライブラリや、メンテナンスが放棄され脆弱性が放置されたライブラリを組み込んでしまうと、そこから情報が漏洩したり、スクリプトが不正な挙動を起こしたりする可能性があります。実際に、信頼されていたライブラリが突如として悪意あるコードに書き換えられる事件はWeb開発の世界では珍しくありません。
組織のガバナンスとして、外部ライブラリの利用を原則禁止するか、あるいは情報システム部門がソースコードを監査し、安全性が確認された特定のバージョンのみを利用許可するホワイトリスト方式を採用すべきです。また、重要なロジックについては外部ライブラリに依存せず、自社でコードを管理・保守する内製化を選択することも、長期的な安全性と安定性を確保する上で重要な判断となります。
監査ログの活用と不審なアクティビティの監視
開発されたGASが実際にどのように利用されているかを把握することは、ガバナンスの要です。Google Workspaceの管理コンソールでは、組織内のGASに関する監査ログを確認することができます。誰がいつスクリプトを作成し、編集し、実行したのか、そしてそのスクリプトがどのファイルにアクセスしたのかといった詳細なアクティビティを追跡可能です。
情報システム担当者は、これらのログを定期的にモニタリングし、異常な頻度での外部通信や、許可されていないスコープの利用、大量のファイルへのアクセス権限を持つスクリプトの出現などを監視する必要があります。また、Google CloudのCloud Loggingと連携させることで、特定のエラーや不審な挙動を検知した際に管理者に即座に通知を飛ばす仕組みも構築できます。「作らせっぱなし」にするのではなく、稼働状況を常に監視できる体制を整えることが、シャドーITを管理されたITへと昇華させる鍵となります。
ウェブアプリケーション公開時の権限設定とアクセス制御
GASをウェブアプリケーションとしてデプロイ（公開）する場合、その公開範囲と実行権限の設定には細心の注意が必要です。デプロイ設定には「次のユーザーとして実行」と「アクセスできるユーザー」という項目があります。特に危険なのが、「自分（開発者）として実行」かつ「全員（匿名ユーザーを含む）」にアクセスを許可する設定です。これは世界中の誰もが、開発者の権限でそのスクリプトを実行できてしまう状態を意味し、意図しないデータの書き換えや情報漏洩に直結します。
企業内利用であれば、アクセスできるユーザーを「ドメイン内のユーザーのみ」に限定することが鉄則です。また、Webhookとして利用する場合など、どうしても外部からのアクセスを許可必要がある場合は、前章で触れたような検証トークンによる認証ロジックをコード内に必ず実装し、正当なリクエスト以外は拒否する仕組みを設ける必要があります。デプロイ設定は一度間違えると取り返しがつかないため、ダブルチェックを必須とする運用ルールを設けるべきです。
エラーハンドリングとインシデントレスポンスの設計
個人利用のツールであればエラーで止まっても自身が困るだけですが、業務システムとして運用する場合、停止時間はビジネス損失に直結します。そのため、予期せぬエラーが発生した場合のハンドリング（例外処理）と、管理者への通知フローを設計段階で組み込むことが求められます。
try-catch構文を用いてエラーを捕捉することはもちろん、エラーが発生した際には単にログに出力するだけでなく、SlackやGoogle Chatなどのチャットツール、あるいはインシデント管理システムへ自動的にアラートを送信する仕組みを実装します。これにより、ユーザーからの申告を待つことなく、管理者が能動的に障害を検知し、対応を開始できます。
また、APIのレート制限などで一時的に処理が失敗した場合に備えて、一定時間後に自動で再試行する「リトライ処理」を実装しておくことも、システムの可用性を高める上で重要です。止まることを前提とし、止まった時にどう動くかを定義しておくことが、プロフェッショナルの仕事です。
組織全体でのガイドライン策定と教育の重要性
技術的な対策だけでなく、それらを運用する「人」への教育とルール作りも欠かせません。どの部署がGASの開発・保守責任を持つのか、機密情報を扱う際の承認フローはどうするのか、コードのレビュー体制はどうあるべきか、といったガイドラインを策定し、全社に周知する必要があります。
また、従業員に対してセキュリティリスクに関する教育を行い、安易にネット上のコードをコピペしない、不明な権限リクエストを承認しないといったリテラシーを向上させることも重要です。GASは強力な武器ですが、使いこなすためには相応の責任が伴います。
技術的なガードレール（制限）と、運用面でのガイドライン（教育）の両輪でガバナンスを効かせることで初めて、組織はGASのポテンシャルを安全かつ最大限に引き出すことができるようになります。