GASを使うべきか否かの判断材料

GASは手軽に使える便利な言語ですが、なんでもGASでやろうとすると苦労することもある…ということでこれGASでやるべきか？という視点でGASのメリット・デメリットを書いてみようと思います。
なお、一部のデメリットはG Suite Business以上なら解消できるものもあります。

#GASを選択する理由
##Googleのサービスにアクセスする

• Googleカレンダー
• スプレッドシート
• Googleドライブ
• AdminDirectoryサービス（G Suite管理者なら）

他の言語などからアクセスする場合、GoogleCloudPlatformでプロジェクト作成→認証情報の作成…といった手順を踏む必要がありますし、認証鍵の管理の手間も発生してしまいます。
GASならコード書いて最初の実行時に承認すればいいです（厳密にはGASに紐づくGCPプロジェクトが作成されていますが通常は意識する必要はありません）

##定期的に実行したい
GASはデフォルトで定期実行機能を備えています。定期実行のためのサーバーを用意したりサービスを利用する必要がありません。

##開発環境の準備が不要
GASの直接のメリットではないですが、特に環境構築をしなくてもすぐブラウザでコードを書き始めて実行できるのは大きなメリットだと思います。

#GASを諦めたほうがいい理由

処理が6分を超えるような処理をする場合

各所で散々言われていることですが、GASは1処理6分を超えると強制的に終了してしまいます。

対処方法はいろいろありますが、そもそも他の言語や環境ならば考慮しなくていいはずの部分なので、わざわざGASでやるべきかは考えてみたほうがいいでしょう。

G Suite Business以上のアカウントの場合は1処理30分まで処理時間が延長されているのでよほどじゃなければあまり気にしなくてもよくなると思います。
Quotas for Google Services

大量の処理をする必要がある

GASは簡単にAPIアクセスや定期実行ができますが、それぞれの回数や頻度には制限があります。
Quotas for Google Services

特にトリガーでの実行時間とUrlFetchの回数は、使用頻度の高さも相まって普通に使っててもネックになりやすいと個人的に感じています。

トリガーの実行時間は無料アカウントの場合、90分/1日となります。
例えば処理が5分もかかるような場合、1日に18回までしか実行できないことになります。
1時間毎の実行にしているともうアウトです。

UrlFetchの実行時間は無料アカウントの場合、20,000回/1日となります。
スクレイピングを大量に行ったり、ファイルを外部に頻繁にPOST/GETしていると引っかかる可能性があります。
なおUrlFetchは以前は1日の転送容量にも制限がありましたが、現在では50MB/1callと変わっています。
UrlFetchの制限が緩和されました

これらはアカウントごとの合計なので、1つのGASだけならなんとかなっても複数のプロジェクトを使用すると制限に引っかかるため、原因以外のプロジェクトでエラーが発生することにもなってしまいます。
原因の調査もしづらくなります。

大容量ファイルやデータを扱う処理をする

大きいファイルを扱い始めると「メモリの上限を超えました」のエラーが発生します。

複数のファイルの内容をまとめてJSONを作ろうとしていたときにこのエラーに遭遇しました。
具体的な制限などの記述を見つけられませんでしたが、体感的には扱うデータがおよそ40〜50MBくらいになった辺りから発生していました。¹

大容量のデータを扱うには不向きと言えるでしょう。

複数人で開発する必要がある

GASのエディターはドキュメントやスプレッドシートと違って同時編集することはできません。（同じファイルを同時編集したいかはともかく）
編集権限を付与して複数人が編集することは可能ですが、標準でバージョン管理がないのでclaspを使うなりchrome拡張を使うなりする必要があります。

複数人トリガーの管理

GASのトリガーはGoogleアカウントごとの設定なので管理が煩雑になります。
一応、トリガーがG Suite Developer Hubに移ってからは他ユーザーのトリガーも確認できるようになりましたが、確認できるようになっただけで他人のトリガーを編集や無効にしたりはできません。表示されるトリガーのオーナーも「自分」か「他のユーザー」の二択のようです。

複数人でのWebアプリケーション公開設定の管理

Webアプリケーションとして公開する場合、ウェブアプリを有効化/無効化出来るのはスクリプトのオーナーだけとなります。
他の編集可能ユーザーはWebアプリのバージョンを更新・変更することはできますが、実行ユーザー、アクセス可能ユーザーもスクリプトのオーナーしか変更できません。

アプリケーションにアクセスできるユーザーを「自分だけ」にしていると、最後に公開設定を更新した人しかWebアプリにアクセスできなくなります。（別のユーザーが最新のURLからアクセスしてもファイルが見つかりませんエラーになる）

アプリケーションの実行ユーザーを「自分」にしている場合、最後に公開設定を更新した人がアプリの実行を承認していないと「その操作には承認が必要です」と出て実行できなくなります。

##ローカルのファイルにアクセスする必要がある
できないのであきらめましょう。
ただしGoogleDrive経由なら可能です。

#とはいえ…
GASを諦めたほうがいい理由をつらつらと書いてはみましたが、正直ひっかかってから考えてもいいような気はします。
環境構築しなくてもすぐコードを書き始められるのがGASの大きなメリットだと思うので、まずはGASで書き始めるというのは悪くないと思います。

実際、上記も自分が実際に引っかかって初めて意識し始めた部分だったりします。
その後、別言語での実装を試みましたが結局GASのメリットがほしくて方針を変えてGASで実装したりしています。

#あとがき
GASは強力ですがこういう罠もありますよという紹介でした。

1. 分かる人がいたら教えてください。 ↩