GmailやGoogleカレンダー、スプレッドシートの自動化は、テンプレートをコピーすればすぐ動きます。一方で、例外ルールの継ぎ足し、共有設定や担当者の変更が重なると、半年ほどで誰も中身を説明できない状態になりがちです。
保守できる自動化にするには、処理を「入力・判断・実行」の部品に分け、部品同士が受け渡すデータを1枚のシートの列として決めておきます。そのうえで、処理済みかを確かめる一意のIDと処理ログを持たせ、「最後に成功した時刻」で静かな停止に気づけるようにします。Apps Scriptのトリガーは作成した人のアカウントで動き、他の人からは見えないため、担当者が替わる前にトリガーと実行アカウントを棚卸しして引き継ぎます。
要点
- 自動化は入力・判断・実行の部品に分け、部品同士が受け渡すデータを1枚のシートの列と状態の値で決めると、どこで止まったかを追えます。
- トリガーが失敗しても画面にエラーは出ないため、最後に成功した時刻と処理件数を見て、静かに止まった自動化に気づける仕組みを足します。
- Apps Scriptのトリガーは作成者のアカウントで動き他の人から見えないため、担当交代の前にトリガーと実行アカウントを棚卸しして作り直します。
なぜ自動化は半年後に壊れるのか
自動化が壊れる原因は、実は技術的な問題よりも運用面に寄っています。特に多いのが以下の3つのパターンです。
例外が仕様を飲み込む
最初は「このメールが来たらラベルを付ける」「この予定が入ったらシートに記録する」というシンプルなルールで成立します。ところが現場は、必ず例外を持ち込んできます。
「この顧客だけ別対応で」「この件名パターンは除外して」「この担当者のときだけ通知して」——こうした要望が少しずつ増え、いつの間にかルールがパッチワーク状態になっていきます。最初の設計思想は影も形もなくなり、なぜそうなっているのか誰も説明できない自動化が残ります。
権限・接続が運用で変わる
Google Workspace周りの自動化は、権限設計の影響を強く受けます。担当者の異動、退職、共有ドライブへの移行、外部共有の解除。こうした”人の都合”による変化は日常的に起きるものです。
厄介なのは、自動化の入口（トリガー）は生きているのに、出口（書き込み先）が死んでいる状態。エラーが出ずに静かに止まっていることも珍しくありません。
変更履歴と責任者がいない
「誰がいつ何を変えたか」が追えない自動化は、壊れたときに直しようがありません。さらに厄介なのは、壊れているのに気づかない状態です。目に見えるエラー通知や監査ログがないと、データの漏れや重複が静かに溜まり続けます。
半年後、年度末の棚卸しで「あれ、この数字おかしくない？」と発覚する。そのときにはもう手遅れ、というのがよくあるパターンです。
なお、AIの判断が怪しいときに自動で止める仕組みそのものは、AIエージェント時代の自働化で扱っています。この記事は、小さな自動化を長く直しながら使い続けるための設計に絞ります。
部品に分け、受け渡すデータを列で決める
保守が難しくなる最大の原因は、1つのスクリプトに取得・判断・書き込み・通知を全部詰め込むことです。処理を「入力」「判断」「実行」の3つの部品に分けると、AIの判定方法を変えるときも判断の部品だけを直せば済みます。
たとえばGmail起点の自動化なら、入力では、メール本文・件名・差出人などを取得して、後続の処理で扱いやすい共通の形に整えます。判断では、そのメールが要対応か対応不要か、どの案件に紐づくかを決めます。AIを使う場合はここに組み込みます。実行では、ラベル付け、シート記録、カレンダー作成、通知送信といった具体的なアクションを行います。判断と実行が一体化していると、AIの揺れがそのまま事故（誤ラベル、誤通知、誤登録）に直結しますが、部品化しておけば影響範囲を限定できます。
部品に分けたら、部品同士がどのデータを受け渡すかを決めます。おすすめは、受け渡し用のシートを1枚用意し、各部品が読む列と書く列を固定する方法です。Gmailの問い合わせを分類して担当者へ通知する自動化なら、次のような列になります。
| 列 | 書き込む部品 | 読む部品 | 役割 |
|---|---|---|---|
| sourceId（GmailのメッセージID） | 入力 | 判断・実行 | 処理済みかを確かめる一意のID |
| 受信日時、差出人、件名、本文の要約 | 入力 | 判断 | 判断に必要な情報だけを渡す |
| AIの分類結果、確信度、判定理由 | 判断 | 実行・人 | 自動で進めるか保留するかの材料 |
| 状態（未処理／保留／実行済み／エラー） | 各部品 | 各部品・人 | どこまで進んだかを1列で示す |
| 処理日時、エラー理由 | 実行 | 人 | 失敗の原因と再実行の手がかり |
各部品は「状態」が自分の担当の値になっている行だけを処理し、終わったら状態を次へ進めます。たとえば判断の部品は「未処理」の行だけを読み、分類を書いたら「保留」か「実行待ち」に変えます。こうしておくと、どの部品で止まったかがシートを見るだけで分かり、AIの判定を人が上書きしたいときも該当行を直せば後続の部品がそのまま動きます。
壊れない自動化の設計原則
部品と受け渡しのデータを決めたら、次の原則を順に当てはめます。
AIは「決定」ではなく「提案」に置く
AIを自動化に組み込むとき、最初に決めるべきは「どこまでの権限を渡すか」です。AIに決定権を渡すほどスピードは上がりますが、事故のリスクも比例して増えます。段階は3つで十分です。
最初の段階は提案（人が確認）です。AIが要対応候補や次アクションを出し、人が採用するかどうかを決めます。AIは下書きを作るだけで、最終判断は人間です。
次の段階は条件付き自動（安全弁あり）です。AIの確信度が高いものだけ自動で処理し、曖昧なものは保留して人の確認を待ちます。
最後の段階がフル自動（監査前提）です。監査ログとロールバックの仕組みが整ってから、ここに進みます。
現場で最も運用しやすいのは2番目の段階です。すべてを人が確認する運用は続きにくく、すべてをAIに任せる運用は事故が怖いため、「高確信のものだけ自動」「曖昧なものは保留」という中間地点が、最も現実的に回ります。
一意のIDで同じ処理を二度実行しない
保守で一番つらいのは、重複登録・二重通知・二重作成といった事故です。これはたいてい、同じイベントに対して処理が複数回発火したときに起きます。防ぐには、最初に「一意キー」を決めておくことが重要です。
Gmailであればスレッドid（threadId）やメッセージID（messageId）を使います。カレンダーであればイベントIDがそのまま使えます。スプレッドシートの場合は、行ごとに独自の行IDを発番し、データのソースIDと組み合わせて管理します。
そして、処理を実行する前に「このIDは処理済みか？」を必ず確認し、処理済みなら何もしないようにします。処理済みのIDを確認してから実行するだけで、二重登録や二重通知の多くを防げます。
失敗を握りつぶさずログに残す
壊れない自動化は、失敗を隠しません。むしろ失敗を前提にして、復旧できる形を最初から作っておきます。最低限ほしいログは3種類です。
まず処理ログ。いつ、何を、どこまでやったか。成功したのか失敗したのか。これがないと、そもそも何が起きているか把握できません。
次に失敗理由。権限エラーなのか、対象データの不正なのか、AI判定の失敗なのか。原因がわからなければ対処のしようがありません。
最後に再実行の手がかり。対象ID、入力データの要約など、もう一度処理を流すために必要な情報です。
ログがあれば自動化の”修理”ができるようになります。ログがなければ、壊れたら作り直すしかありません。
設定値をコードの外に出す
保守が重くなる典型パターンが、「担当者が変わるたびにコード修正」問題です。ラベル名、通知先、対象条件、シートIDなどをコードに直接埋め込んでいると、人が増えるほど変更依頼が増えます。
最初から大層な管理画面を作る必要はありません。設定シートとしてスプレッドシートを1枚用意すれば十分です。対象ラベル名、除外ルール（特定ドメインや件名のパターン）、通知先（SlackやGoogle Chatやメール）、担当者の割当ルールなど、運用で変わりそうな値はすべて外に出します。
運用担当者が自分で触れる部分を増やすと、開発側への依頼が減り、自動化が現場に定着しやすくなります。「ちょっとした変更のたびにエンジニアに頼む」という状況は、お互いにとってストレスです。
テストデータと戻し方を先に用意する
“動いた”をゴールにすると、壊れたときに詰みます。長生きする自動化は、最初から「戻し方」を決めています。
Gmailのラベル操作であれば、付けたラベルを外せるようにしておきます。スプレッドシートへの登録であれば、作った行に「sourceId」と「作成日時」を入れておき、条件指定でまとめて削除できるようにします。カレンダーのイベント作成であれば、説明欄に識別子を入れておき、一括削除できるようにします。
加えて、テスト用のダミーデータ（ダミーメール、ダミー予定、ダミー行）を用意しておき、変更時に必ず試せる状態にします。これがあるだけで、改善のスピードが落ちません。「本番で試すしかない」状態は、怖くて誰も触れなくなります。
部品コピペで始めるときの進め方
ここまでの原則を、全部一度にやる必要はありません。順番が大事です。
最初の1週間：壊れない骨格だけ作る。まずは入力/判断/実行を分けること、一意キーで重複を防ぐこと、失敗ログを残すこと（最低限でOK）。この3つだけで、致命的な事故はかなり防げます。受け渡しシートの列と状態の値も、この段階で決めておきます。
次の2〜4週間：運用に合わせて強くする。設定値を外に出して設定シート化する、確信度で自動/保留を分けてAIを安全に使う、権限の棚卸しをする。運用が回り始めてから、この辺りを整備していきます。次の節で扱う「最後に成功した時刻」の確認と、通知先のチーム化もここで入れます。
2ヶ月目以降：改善を”止まらない形”にする。変更履歴と責任者を明確にする、ロールバックとテストデータを整える、例外を増やす前にルールを標準化する。トリガーの一覧と実行アカウントを設定シートに記録し、引継ぎの手順も決めます。ここまで来れば、自動化が「育てられる状態」になっています。
止まったことに気づく：変更検知の仕組み
保守で一番困るのは、エラーが表に出ないまま処理が止まっていることです。GoogleのApps Scriptのインストール型トリガーの解説によると、トリガーで動く関数が失敗しても画面にはエラーが表示されず、失敗をまとめた通知メールが送られます。通知を見落としたり、受け取る人が異動していたりすると、誰も気づかないまま処理が止まり続けることがあります。
そこで、失敗通知だけに頼らず、処理ログから「止まっていないか」を確かめる仕組みを部品として足します。
| 見る値 | 気づける異常 | 確認のしかた |
|---|---|---|
| 最後に成功した時刻 | トリガーの停止、権限切れ、書き込み先の消失 | 想定の実行間隔を超えて更新されていなければ担当者へ通知する |
| 1日あたりの処理件数 | 入力の条件変更（ラベル名や送信元の変更）で対象が拾えなくなった | 普段の件数から大きく外れた日、特にゼロ件の日を確認する |
| 状態が「保留」「エラー」の行数 | AIの判定が揺れている、特定の入力で失敗が続いている | 増え続けていないかを週次で見る |
| 設定シートの変更履歴 | 担当者が通知先や除外条件を変えた | 変更した人と日時をシートの版の履歴で確認する |
通知先は個人のメールアドレスではなく、チームのChatスペースやグループのアドレスにしておくと、担当者が替わっても通知が途切れません。
担当者が替わる前に：トリガーと実行アカウントの引継ぎ
Google Workspaceの自動化は「誰の権限で動いているか」に強く左右されます。同じApps Scriptの解説によると、インストール型トリガーは、作成した人のアカウントで常に実行されます。たとえばトリガーがメールを送る処理なら、送信元は作成者のアドレスになります。さらに、あるアカウントが作ったトリガーは、別のアカウントからは見えません。共同編集者がスクリプトを開いても、他の人が作ったトリガーは確認できないということです。
このため、担当者の異動や退職が決まったら、本人のアカウントが使えるうちに次の順で引き継ぎます。
- 旧担当のアカウントで、スクリプトごとのトリガー一覧（関数名、実行の種類、間隔）を書き出す。
- 処理が読み書きするファイル、ラベル、カレンダー、通知先を、受け渡しシートと設定シートで確認する。
- 新担当、または業務用に用意した実行用アカウントで同じトリガーを作り直し、テストデータで動作を確かめる。
- 新しいトリガーの成功を処理ログで確認してから、旧担当のトリガーを削除する（両方が動くと二重実行になる）。
- 引継ぎ日、旧担当、新担当、対象スクリプトを設定シートの管理欄に記録する。
共有ドライブへの移行や外部共有の解除でも、書き込み先にアクセスできなくなることがあります。ファイルの置き場所や共有設定を変えるときは、受け渡しシートに書かれた読み書き先を先に確認します。
共有設定と権限を変える前の確認表
Google Workspace とスプレッドシートの運用では、権限、監査、AI利用の順番を間違えると混乱しやすくなります。自動化の読み書き先になるファイルについて、先に運用の土台を揃えるための整理表です。
| 運用テーマ | 先に確認する項目 | 事故が起きやすい理由 | 最初に固定するルール |
|---|---|---|---|
| 共有設定 | 閲覧・編集・外部共有の境界 | 共有リンクが便利すぎて責任者が曖昧になる | 正本ファイルと閲覧用ファイルを分ける |
| 権限管理 | 誰が変更できるか、誰が申請するか | 役職ベースで編集権限を配ると破壊的変更が起きる | 変更依頼の受付レーンと承認者 |
| AI関数の利用 | どの列で使うか、どこまで自動化するか | 生成結果をそのまま正本に流し込むと監査不能になる | 下書き列と確定列を分ける |
| 監査ログ | 誰がいつ見返すか | ログはあるが定例確認の担当がいない | 週次で見る項目とエスカレーション先 |
よくある質問
小さな自動化でも部品に分ける必要がありますか？
処理が1つのスクリプトで数十行に収まるうちは、関数を入力・判断・実行に分けるだけでも十分です。受け渡しシートを用意するのは、AIの判定を入れる、通知先が複数ある、担当者が複数いるなど、後から変更が入りやすい自動化からで構いません。
AIの判定結果はそのまま実行してよいですか？
最初は提案として受け渡しシートに書き、人が確認してから実行する形が安全です。確信度が高いものだけを自動で実行する段階に進むのは、処理ログと戻し方が整ってからにします。
トリガーの失敗に気づく一番簡単な方法は何ですか？
処理ログに最後に成功した時刻を書き、想定の間隔を超えて更新されていなければチームの通知先へ知らせる部品を足す方法です。失敗の通知メールは見落とすこともあるため、それだけに頼らないようにします。
担当者が退職する前に最低限やることは何ですか？
本人のアカウントでトリガーの一覧を書き出し、新しい担当者か業務用の実行アカウントで作り直して動作を確認し、旧いトリガーを削除することです。読み書きするファイルや通知先も、設定シートで一緒に引き継ぎます。
