はじめに
GAS (Google App Script) を社内システムで運用していますが、ちゃんと運用するにあたって気をつけたい (個人的にハマった) ことがあるのでメモしておきます。
この記事は、毎度お馴染みの YAMAP エンジニア Advent Calendar 2023 六日目の記事です。
公開 URL について
GAS を他のシステムと Webhook 連携させる場合、Webhook の URL として GAS の「公開 URL」を設定することがあると思います。この「公開 URL」は基本的にデプロイの度に変わってしまいますが、以下の手順で固定することが可能なので、可能な限り固定しておきましょう。
「バージョン」のプルダウンで「新しいバージョン」を指定すれば OK です。
実行ユーザーについて
公開 URL で実行されるスクリプトの実行ユーザーの設定については悩ましいところです。
上記の図では、「自分」 (スクリプトを書いた本人) となっていますが、もう一つの選択肢として「ウェブアプリケーションにアクセスしているユーザー」があります。
特に指定しない場合には「自分」が設定されますが、「自分」が退職等で組織の Google Workspace 上から削除された時、その GAS は以下のようなエラーを吐いて動かなくなります。
{
"insertId": "xxxxxxxxxxxxxxxxxx",
"jsonPayload": {
"message": "ユーザーが存在しません",
"serviceContext": {
...
}
これを解決する為には、GAS を運用する為の専用ユーザーを用意するしかなさそうです。
では、「ウェブアプリケーションにアクセスしているユーザー」にした場合にどうなるのでしょうか。ChatGPT に聞いてみると、以下のような返答を頂きました。
- アクセスしている各ユーザーの Google アカウントを認証情報として使用する (アクセスしているユーザーは Google アカウントを持っている必要がある)
- スクリプトは各ユーザーのアカウントで実行される為、ユーザーが許可されている範囲内でGoogleサービスにアクセス出来る
- 初回アクセス時に Googleアカウントでのログインと、スクリプトの権限承認を求められる
と、アクセスするユーザーが Google アカウントを持っていることが前提のようなので、基本的には実行ユーザーは「自分」としておく方が良さそうです。
トリガー設定について
トリガー設定についても「実行ユーザー」の時と同様に注意が必要です。
基本的には、スクリプトを書いた本人 (以後、自分) の権限でトリガー設定を行いますが、「自分」が組織の Google Workspace 上から削除されると、このトリガー設定は動かなくなります。(オーナーが「自分」になっている)
このトラブルを防ぐ為には、「実行ユーザー」のセクションでも書いた通り、GAS を運用する為の専用ユーザーを用意するか、GAS へのアクセス権を持つ他のユーザーがトリガーを設定しましょう。
ソースコード管理について
GAS でコードを書く際、ブラウザ上のエディタで書いて動かしてを繰り返してしまいますが、複数のメンバーでメンテナンスする場合、変更が管理されていないことで、デグレのリスクが一気に高まります。ここは、黙って Git 等のソースコード管理ツールを利用しましょう。どんなに小さいツールでも Github にぶちこんでおいた方が賢明です。
さいごに
ちょっとした Web サービスや社内ツールとして GAS はスプレッドシート等のアプリケーションとの親和性の高さや手軽にセットアップ出来ることから非常に便利だと思います。ただ、社内システムとしてちゃんと運用しようとすると、留意が必要なポイントがちょいちょいあるので気をつけて運用したいと思います。
Discussion