GAS業務システムの属人化を防ぐ、
5つの運用ルール

GAS業務システムが「属人化」で止まる典型パターン

GASは追加のサーバー代がかからず、月額運用費0円で業務システムを運用できるのが強みです。一方で、作った人のGoogleアカウントに紐づいて動いているため、担当者の退職や異動で突然止まることがあります。ラスタージ（Lustage）が引き継ぎ相談で見かける原因は、ほぼ次の3つです。

• スクリプトが個人のマイドライブにあり、アカウントが停止されると開けなくなる
• トリガー（定時実行の設定）の持ち主が退職者で、実行されなくなる
• APIキーや宛先メールアドレスがコードに直接書かれていて、誰も場所を把握していない

ルール1：スクリプトの所有者を会社管理にする

スプレッドシートとGASは、個人のマイドライブではなく共有ドライブ（Google Workspaceの場合）または会社専用のGoogleアカウントに置きます。個人アカウントしかない場合は、少なくとも2人以上を編集者に加え、所有者が1人にならないようにします。

• 所有者と編集者の一覧を、台帳（スプレッドシートの1シート）に書いておく
• 退職・異動の手順に「GASの所有権移行」を1行加える

ルール2：実行ユーザーとトリガーの持ち主を確認する

Webアプリは「自分として実行」か「アクセスしたユーザーとして実行」かで動作が変わります。トリガーは作成したユーザーのものとして登録されるため、そのユーザーが使えなくなると止まります。担当者が変わったら、新しい担当者でトリガーを作り直します。

• トリガー一覧（実行画面の「トリガー」）を月に1回確認する
• 実行ユーザーが退職者のアカウントになっていないかを見る

ルール3：設定値をコードから分ける

宛先メール、フォルダID、APIキーなどをコードに直接書くと、変更のたびにコードを触る必要があり、他人が追いにくくなります。スプレッドシートの「設定」シートや、スクリプトプロパティ（PropertiesService）に分けておくと、コードを直さずに差し替えられます。

APIキーはシートに平文で書かず、スクリプトプロパティに入れます。具体的なコードは関連記事で解説しています。

• 変更される値は設定シートに
• 秘密情報はスクリプトプロパティに

ルール4：変更履歴と設計メモを残す

GASのエディタにもバージョン管理はありますが、変更理由までは残りません。「いつ・誰が・何の目的で直したか」を1行ずつ書く変更履歴シートと、処理の流れを書いたA4一枚程度の設計メモを同じフォルダに置くだけで、引き継ぎの手間が大きく減ります。

開発を外部に依頼している場合は、設計メモと変更履歴を納品物に含めるよう依頼時に確認しておくと安心です。

• 設計メモ：目的、入力、出力、トリガー、使っているデータの場所
• 変更履歴：日付、変更内容、理由、担当者

ルール5：エラー通知と月1回の点検

動かなくなっても誰も気づかないことが、属人化の一番の問題です。処理の最後に失敗したらメールやチャットで通知する仕組みを入れ、さらに月に1回、トリガーの実行履歴と上限（実行時間・メール送信数など）に近づいていないかを確認します。

Googleの仕様変更で調整が必要になる場合もあるため、点検のときに公式の変更情報を見る担当を決めておきます。

• エラー通知：try/catchで例外を捕まえて通知
• 月1回の点検：実行履歴、トリガー、上限に対する余裕

まとめ

GAS業務システムは月額運用費0円で運用できますが、「所有者」「トリガー」「設定値」「履歴」「エラー通知」の5つを決めておかないと、担当者の変更で止まるリスクがあります。難しい作業ではなく、最初に30分決めておけば防げるものがほとんどです。

ラスタージは、業務システム開発とDX化支援を低コストで行っており、引き継ぎしやすい構成での構築や、既存のGASの確認・整理もご相談いただけます。