Apps Scriptの業務自動化を担当者任せにしない保守ルール【所有者・権限・更新日の台帳】
スプレッドシートの自動化は、動いた瞬間よりも止まらない仕組みが大事です。
担当者が変わっても困らないように、所有者・権限・更新日から見直してみませんか？
Apps Script 業務自動化は、スプレッドシートの転記、メール通知、日報集計のような小さな作業を減らせる便利な仕組みです。
ただし、社内で本当に困るのは「作れない」ことより、作った人がいないと直せないことです。
特にGoogle スプレッドシート 自動化は、最初の1本が動くと現場で広がりやすい反面、誰のアカウントで動いているのか、どの権限を使っているのか、最後にいつ見直したのかが曖昧になりがちです。
退職者や異動者のアカウントにトリガーが残っていると、月末処理や通知が突然止まるリスクもあります。
先に決めることはシンプルです。Apps Scriptを業務で使うなら、コードより先に台帳です。所有者・権限・更新日を用意してください。
以下では、Google公式情報で確認できる仕様を前提に、担当者任せにしない保守ルールを整理します。
Apps Scriptは便利だが、個人管理に寄りやすい
Google Workspace公式は、Apps ScriptをGoogle Workspaceの自動化、統合、拡張に使える仕組みとして説明しています。Gmail、Google Sheets、Google Driveなどをまたぐ小さな処理を作りやすく、社内の「毎回同じ手作業」を減らす入口になります。
出典: Google Workspace「Apps Script」
便利な一方で、現場発の自動化は個人のGoogleアカウント、個人のDrive、個人の判断に寄りやすくなります。
「Aさんが作った月次集計」「Bさんしか知らない通知スクリプト」が増えると、動いている間は問題が見えません。問題が見えるのは、止まった後です。
要点Apps Scriptは小さく始められる分、管理も小さく置き去りになりやすい
作成者、トリガー、権限、接続先、最終更新日を残していない自動化は、便利な仕組みではなく属人化した業務インフラになります。
最初に見るべきリスクはトリガーの所有者
Apps Script 権限 管理で最初に見るべきなのは、誰がトリガーを作ったかです。Google公式ドキュメントでは、インストール型トリガーは作成したユーザーのアカウントで実行されると説明されています。
出典: Google for Developers「Installable Triggers」（英語）
この仕様を知らないまま、退職予定者のアカウントで月次通知や自動転記を動かしていると、アカウント停止や権限変更のタイミングで処理が失敗する可能性があります。
社内自動化 退職者 リスクを下げるには、退職時のGoogle Workspaceデータ整理と同じく、退職者のWorkspaceデータ引き継ぎの対象にApps Scriptも含める必要があります。
また、トリガーは「毎朝9時に実行」「フォーム送信時に実行」「スプレッドシート更新時に実行」のように、業務のタイミングと直結します。
トリガーが誰のものか分からない状態は、業務の起動スイッチが誰の手元にあるか分からない状態です。
担当者任せの状態
作成者だけが場所を知っている
個人アカウントのトリガーで動く
エラー通知の行き先が個人メール
保守できる状態
台帳に所有者と副担当がある
実行条件と接続先が説明できる
停止時の連絡先と復旧手順がある
台帳に残す8項目
保守用の台帳は、きれいな管理表でなくてもかまいません。最初はスプレッドシート1枚で十分です。
ただし、次の8項目は必ず入れてください。ポイントは、コードを読める人だけが分かる情報ではなく、管理者と現場責任者が判断できる情報にすることです。
| 台帳項目 | 書く内容 | 防げるリスク |
|---|---|---|
| 業務名 | 月次集計、フォーム通知、請求確認など | 用途不明のスクリプトを減らす |
| 所有者 | 業務責任者と技術担当を分けて記載 | 退職・異動時の放置を防ぐ |
| 副担当 | 最低1名の確認者 | 単独担当化を防ぐ |
| 実行条件 | 時刻、フォーム送信、編集時など | 止まった時間帯を特定しやすくする |
| 接続先 | Sheets、Gmail、Drive、外部URLなど | 情報の出入りを確認する |
| 権限範囲 | 読み取り、送信、編集、外部接続の有無 | 過剰権限を見つける |
| 最終更新日 | コード・権限・トリガーを最後に見た日 | 古い自動化を放置しない |
| 停止時対応 | 通知先、復旧担当、手動代替手順 | 月末や締め日に慌てない |
似た考え方はAPI連携にも使えます。外部サービスとの接続がある場合は、API連携の台帳管理と同じく、接続先、権限、担当者、更新日を1か所で見られる状態にしてください。
注意「スクリプト名」だけでは管理できない
ファイル名が「自動化.gs」や「フォーム通知」のままだと、何を止めてよいか判断できません。台帳では、業務名、実行条件、影響範囲を人間の言葉で書きます。
権限はスコープと管理者設定の両方で見る
Apps Scriptの権限は、コードの中だけで完結しません。Google公式は、OAuthスコープをスクリプトがアクセスできるデータや操作の範囲として説明しています。
つまり、Gmailを送る、Driveファイルを読む、外部URLへ接続する、といった操作は、それぞれ権限範囲として確認する必要があります。
出典: Google for Developers「Authorization Scopes」（英語）
一方で、確認はGoogle Workspace管理者側にも及びます。Googleの管理者向けヘルプでは、管理者がユーザーごとにApps Scriptの利用可否を制御できると説明しています。
外部接続URLについても、Apps ScriptやSheetsから接続できる先を許可リストで制限できるか確認してください。
出典: Google Workspace Admin Help「Turn Apps Script on or off for users」（英語）
出典: Google Workspace Admin Help「Allow only certain external connections for Apps Script and Sheets」（英語）
ここで避けたいのは、現場担当者に「気をつけて」と言うだけで終わる運用です。
社内のAIツールでも、権限は人の注意力ではなく仕組みで棚卸ししてください。全体の見方は、AIツールの権限棚卸しと同じ考え方で整理できます。
月1回のレビューで見るポイント
Apps Scriptにはサービスごとのクォータがあります。Google公式ドキュメントでは、日次クォータが最初のリクエストから24時間後にリセットされると説明しています。
この情報は、細かな上限値を覚えるためのものではありません。突然の停止時に「権限エラーなのか、クォータなのか、接続先なのか」を切り分ける材料にします。
出典: Google for Developers「Quotas for Google Services」（英語）
月1回のレビューでは、次の順番で見てください。すべてを技術担当だけに任せるのではなく、業務責任者、管理者、技術担当で分担します。
台帳
所有者と更新日
→
権限
スコープと接続先
→
復旧
止まった時の手順
月1回、台帳を起点に所有者・権限・停止時対応を確認する
- 所有者と副担当が現在の在籍者になっているか
- トリガー作成者が退職予定者や異動者のままではないか
- Gmail送信、Drive閲覧、外部接続などの権限が用途に対して過剰ではないか
- エラー通知が個人メールだけに届く状態になっていないか
- 手動で代替できる手順が1枚にまとまっているか
承認の考え方はAIエージェントにも近いです。閲覧、下書き、実行、送信を分けて考えるほど、事故は減ります。自動化の操作範囲を決めるときは、AIエージェントの承認フローと同じく、人が承認する境界を決めてください。
新しく作る時の保守ルール
新しいApps Scriptを作る時は、完成してから台帳に書くのではなく、動かす前に最小限の保守ルールを決めてください。
進め方は次の順番が扱いやすいです。
- 業務責任者を決める
- 技術担当と副担当を決める
- トリガーの種類と実行アカウントを台帳に書く
- 利用するGoogleサービスと外部接続を台帳に書く
- エラー通知の送信先を個人ではなく共有先にする
- 停止時の手動代替手順を残す
- 最初の見直し日を1か月以内に設定する
Google公式は、Apps Scriptプロジェクトの共同作業や共有についても案内しています。個人の手元だけで完結させず、共同編集、共有先、所有の扱いを決めておくと、引き継ぎ時の混乱を減らせます。
出典: Google for Developers「Collaborating with other developers」（英語）
メモApps Scriptの保守は、コードレビューだけでは足りません。
誰のアカウントで、どの権限で、どの業務を動かしているかを説明できる状態にしておくことが、社内自動化の最低ラインです。
まず既存スクリプトを棚卸しする
すでにApps Scriptが社内にある場合は、新規開発よりも棚卸しを優先してください。
全社一斉に調べる必要はありません。まずは、月末処理、請求、問い合わせ、顧客対応、役員報告のように、止まると困る業務から見ます。
最初の棚卸しで完璧な資料を作る必要はありません。重要なのは、止まったら誰が気づき、誰が直し、手動ではどう代替するかを決めることです。
ここまで決まっていれば、Apps Scriptは担当者の便利ツールではなく、会社で管理できる業務自動化に近づきます。
Apps Scriptの業務自動化でよくある質問
QApps Script 業務自動化で最初に管理すべきことは何ですか？
A最初に管理すべきなのは、所有者、トリガー、権限、最終更新日です。コードの内容より先に、誰のアカウントで動き、どの業務に影響し、止まった時に誰が対応するかを台帳に残します。
QApps Scriptのトリガーはなぜ退職者リスクになりますか？
AGoogle公式では、インストール型トリガーは作成したユーザーのアカウントで実行されると説明されています。退職者や異動者のアカウントに依存したままだと、権限変更やアカウント停止時に業務処理が止まる可能性があります。
QGoogle スプレッドシート 自動化の台帳には何を書けばよいですか？
A業務名、所有者、副担当、実行条件、接続先、権限範囲、最終更新日、停止時対応を書きます。特にメール送信、Drive閲覧、外部接続がある場合は、権限範囲を必ず確認します。
QApps Script 権限 管理は現場担当者だけでできますか？
A現場担当者だけでは不十分です。スクリプトのスコープは技術担当が確認し、Apps Scriptの利用可否や外部接続の制限はGoogle Workspace管理者が確認します。業務影響は業務責任者が判断します。
Q既存のApps Scriptはどこから棚卸しすればよいですか？
A月末処理、請求、顧客対応、問い合わせ通知、役員報告など、止まると困る業務から棚卸しします。すべてを一度に見るより、業務影響が大きい順に台帳化する方が現実的です。
QApps Scriptの保守レビューはどれくらいの頻度で行うべきですか？
A最初は月1回がおすすめです。所有者、トリガー、権限、エラー通知、手動代替手順を確認します。安定後も、退職・異動・権限変更・外部サービス変更のタイミングでは必ず見直します。
