自動化×AI：部品コピペで始めて、保守地獄に落ちない設計原則（Gmail・カレンダー・スプレッドシート運用に効く）
「まずはコピペで動かす」。業務自動化の世界では、これが最速で成果を出す正しいやり方だと言われています。実際、ネット上には便利なスクリプトやテンプレートが溢れていて、コピペするだけでGmailの振り分けやスプレッドシートへの自動転記が動き始めます。
ただ、本当の問題はその後に待っています。動いた瞬間から始まる”保守地獄”です。
人が増える。例外が増える。権限が変わる。仕様が変わる。気づけば、誰も中身を理解できない自動化が積み上がり、最後は「もう止めるしかない」という結論に行き着く。こんな経験、心当たりがある方も多いのではないでしょうか。
この記事では、Gmail・Googleカレンダー・Googleスプレッドシートといった日々の業務基盤を前提に、部品コピペで始めつつ、壊れない形に育てる設計原則を整理します。小手先のテクニックではなく、「長生きする構造」を作るための考え方です。
なぜ自動化は半年後に壊れるのか
自動化が壊れる原因は、実は技術的な問題よりも運用面に寄っています。特に多いのが以下の3つのパターンです。
例外が仕様を飲み込む
最初は「このメールが来たらラベルを付ける」「この予定が入ったらシートに記録する」というシンプルなルールで成立します。ところが現場は、必ず例外を持ち込んできます。
「この顧客だけ別対応で」「この件名パターンは除外して」「この担当者のときだけ通知して」——こうした要望が少しずつ増え、いつの間にかルールがパッチワーク状態になっていきます。最初の設計思想は影も形もなくなり、なぜそうなっているのか誰も説明できない自動化が残ります。
権限・接続が運用で変わる
Google Workspace周りの自動化は、権限設計の影響を強く受けます。担当者の異動、退職、共有ドライブへの移行、外部共有の解除。こうした”人の都合”による変化は日常的に起きるものです。
厄介なのは、自動化の入口（トリガー）は生きているのに、出口（書き込み先）が死んでいる状態。エラーが出ずに静かに止まっていることも珍しくありません。
変更履歴と責任者がいない
「誰がいつ何を変えたか」が追えない自動化は、壊れたときに直しようがありません。さらに厄介なのは、壊れているのに気づかない状態です。目に見えるエラー通知や監査ログがないと、データの漏れや重複が静かに溜まり続けます。
半年後、年度末の棚卸しで「あれ、この数字おかしくない？」と発覚する。そのときにはもう手遅れ、というのがよくあるパターンです。
設計原則1：自動化を「部品」に分解する
保守地獄の最大要因は、1つの自動化に”全部”を詰め込むことです。長生きする自動化は、最初から機能ごとに分割されています。
「入力」「判断」「実行」を分ける
たとえばGmail起点の自動化なら、次の3つの部品に分けて考えます。
入力では、メール本文・件名・差出人などを取得して、後続の処理で扱いやすい共通の形に整えます。判断では、そのメールが要対応か対応不要か、どの案件に紐づくかを決めます。AIを使う場合はここに組み込みます。実行では、ラベル付け、シート記録、カレンダー作成、通知送信といった具体的なアクションを行います。
この分け方の良いところは、AIの精度が変動しても「判断」の部品だけを差し替えれば済む点です。逆に、判断と実行が一体化していると、AIの揺れがそのまま事故（誤ラベル、誤通知、誤登録）に直結します。部品化しておけば、影響範囲を限定できるわけです。
設計原則2：AIは”決定”ではなく”提案”に置く
AIを自動化に組み込むとき、最初に決めるべきは「どこまでの権限を渡すか」です。AIに決定権を渡すほどスピードは上がりますが、事故のリスクも比例して増えます。
経験上、最初からフルオートにしない方が、結果的に早く成果が出ます。
段階は3つで十分
最初の段階は**提案（人が確認）**です。AIが要対応候補や次アクションを出し、人が採用するかどうかを決めます。AIは下書きを作るだけで、最終判断は人間です。
次の段階は**条件付き自動（安全弁あり）**です。AIの確信度が高いものだけ自動で処理し、曖昧なものは保留して人の確認を待ちます。
最後の段階が**フル自動（監査前提）**です。監査ログとロールバックの仕組みが整ってから、ここに進みます。
現場で最も運用しやすいのは2番目の段階です。すべてを人が見るのは正直しんどい。しかし、すべてをAIに任せるのは怖い。だからこそ、「高確信のものだけ自動」「曖昧なものは保留」という中間地点が、最も現実的に回ります。
設計原則3：冪等性（同じ処理を何度しても同じ結果）を守る
保守で一番つらいのは、重複登録・二重通知・二重作成といった事故です。これはたいてい、同じイベントに対して処理が複数回発火したときに起きます。
「一意キー」を先に決める
この問題を防ぐには、最初に「一意キー」を決めておくことが重要です。
Gmailであればスレッドid（threadId）やメッセージID（messageId）を使います。カレンダーであればイベントIDがそのまま使えます。スプレッドシートの場合は、行ごとに独自の行IDを発番し、データのソースIDと組み合わせて管理します。
そして、処理を実行する前に「このIDは処理済みか？」を必ず確認し、処理済みなら何もしないようにします。たったこれだけのことで、事故の8割は防げます。
設計原則4：例外処理は”握りつぶさず”ログに残す
壊れない自動化は、失敗を隠しません。むしろ失敗を前提にして、復旧できる形を最初から作っておきます。
最低限ほしいログは3種類
まず処理ログ。いつ、何を、どこまでやったか。成功したのか失敗したのか。これがないと、そもそも何が起きているか把握できません。
次に失敗理由。権限エラーなのか、対象データの不正なのか、AI判定の失敗なのか。原因がわからなければ対処のしようがありません。
最後に再実行の手がかり。対象ID、入力データの要約など、もう一度処理を流すために必要な情報です。
「ログなんて面倒」と感じるかもしれません。ただ、先に結論を言うと、ログは保守コストを劇的に下げます。ログがあれば自動化の”修理”ができるようになるからです。ログがなければ、壊れたら作り直すしかありません。
設計原則5：設定値をコードから追い出す
保守地獄の典型パターンが、「担当者が変わるたびにコード修正」問題です。ラベル名、通知先、対象条件、シートIDなどをコードに直接埋め込んでいると、人が増えるほど変更依頼が増えます。
設定は「設定シート」か「管理画面」に寄せる
最初から大層な管理画面を作る必要はありません。スプレッドシートで十分です。
対象ラベル名、除外ルール（特定ドメインや件名のパターン）、通知先（SlackやGoogle Chatやメール）、担当者の割当ルールなど、運用で変わりそうな値はすべて外に出します。
運用担当者が自分で触れる部分を増やすと、開発側への依頼が減り、自動化が現場に定着しやすくなります。「ちょっとした変更のたびにエンジニアに頼む」という状況は、お互いにとってストレスです。
設計原則6：権限設計は「運用の設計」とセットでやる
Google Workspaceは便利な反面、「誰の権限で動いているか」が事故に直結します。技術的な話というより、業務の所有者を決める話です。
よくある事故パターン
個人アカウントで作った自動化が、その人の退職と同時に停止する。これは本当によくある話です。共有ドライブへの移行で参照先が変わり、ファイルが見つからなくなる。外部共有の解除で、連携していた書き込み先にアクセスできなくなる。
対策はシンプルで、実行者（サービスアカウントや共有アカウント）を個人から分離することです。そして「権限が変わったらどこが壊れるか」を事前に棚卸ししておきます。権限変更は必ず起きるものだと想定して、影響範囲を把握しておくわけです。
設計原則7：テストデータとロールバックを先に用意する
“動いた”をゴールにすると、壊れたときに詰みます。長生きする自動化は、最初から「戻し方」を決めています。
最小のロールバック例
Gmailのラベル操作であれば、付けたラベルを外せるようにしておきます。スプレッドシートへの登録であれば、作った行に「sourceId」と「作成日時」を入れておき、条件指定でまとめて削除できるようにします。カレンダーのイベント作成であれば、説明欄に識別子を入れておき、一括削除できるようにします。
加えて、テスト用のダミーデータ（ダミーメール、ダミー予定、ダミー行）を用意しておき、変更時に必ず試せる状態にします。これがあるだけで、改善のスピードが落ちません。「本番で試すしかない」状態は、怖くて誰も触れなくなります。
“部品コピペ”で始めるときの現実的な進め方
ここまで7つの設計原則を紹介しましたが、全部を一度にやる必要はありません。順番が大事です。
最初の1週間：壊れない骨格だけ作る
まずは入力/判断/実行を分けること、一意キーで重複を防ぐこと、失敗ログを残すこと（最低限でOK）。この3つだけで、致命的な事故はかなり防げます。
次の2〜4週間：運用に合わせて強くする
設定値を外に出して設定シート化する、確信度で自動/保留を分けてAIを安全に使う、権限の棚卸しをして実行者を分離する。運用が回り始めてから、この辺りを整備していきます。
2ヶ月目以降：改善を”止まらない形”にする
変更履歴と責任者を明確にする、ロールバックとテストデータを整える、例外を増やす前にルールを標準化する。ここまで来れば、自動化が「育てられる状態」になっています。
まとめ：保守地獄を避けるのは、技術ではなく「構造」
自動化×AIは、うまくいけば現場の入力作業と確認作業を大幅に減らしてくれます。ただし、無計画に積み上げると、未来の自分たちの首を絞めることになります。
今日から意識してほしいポイントは3つです。
自動化を部品に分けること。入力・判断・実行を分離しておけば、どこかが壊れても影響を限定できます。AIは提案から始めて、確信度で自動範囲を絞ること。いきなりフルオートにせず、段階的に任せる範囲を広げていきます。冪等性とログで”壊れても直せる”状態を作ること。重複を防ぎ、何が起きたか追えるようにしておけば、修理ができます。
部品をコピペして終わりではなく、コピペした部品が長生きする設計に変えていく。それが、最短で成果を出しながら保守地獄に落ちない、一番の近道です。