「毎朝 9 時に、どこからともなくメールで集計レポートが届くんです。便利なんですが、それを作った人はもう退職していて、中身も止め方も誰も分からなくて」——Google Apps Script（GAS）を長く使ってきた会社から、この種の相談をよく受けます。スプレッドシートに仕込まれた集計、フォーム送信時の自動通知、深夜に走るデータ連携。どれも業務に溶け込んで当たり前のように動いているのに、ソースを開ける人も、何をしているか説明できる人も、社内に一人もいない。動いているうちは誰も困りませんが、動いているからこそ誰も触らず、ブラックボックスのまま時間だけが過ぎていきます。
GAS は、Google スプレッドシートやドライブ、Gmail を手軽に自動化できる優れた仕組みです。一方で、その手軽さゆえに、特定の担当者が一人で書き、ドキュメントも残さず、その人の異動や退職とともに「動いているが誰も中身を知らないコード」として取り残されやすい。しかも 2026 年は、こうした放置スクリプトが自然に壊れる引き金がいくつも重なる年でもあります。本記事では、引き継いだブラックボックスの GAS をどう棚卸しし、止まる前にどう立て直すかを、受託で保守を引き受ける立場から整理します。
なぜ GAS は「動くブラックボックス」になりやすいのか
GAS が属人化しやすいのには、技術というより構造的な理由があります。
第一に、誰でも、どこにでも書けることです。GAS はスプレッドシートやフォームの裏側に直接コードを書けるため、IT 部門を通さず現場の一担当者が思いついた自動化をその場で作れます。これは長所ですが、裏を返せば、会社のどこにいくつスクリプトが存在するのかを誰も把握していない、という状態を生みます。
第二に、トリガーで見えないところで動くことです。時間主導のトリガーやフォーム送信時のトリガーで動くスクリプトは、画面のどこにもボタンが出てきません。結果（届くメールや更新される行）だけが見えて、本体は背後に隠れている。だから問題が起きるまで存在を意識されず、起きたときには「そもそもどこに何があるのか」の調査から始めることになります。
第三に、書いた人の頭の中にしか仕様がないことです。動けばよいという発想で書かれた GAS は、コメントもドキュメントもなく、変数名も本人にしか分からない。その人が異動・退職すれば、コードは残っても意図は消えます。この「動いているが誰も説明できない」構図は、認証の自前実装を引き継ぐときの不安を扱った 引き継いだ認証コードの記事 と、まったく同じ性質のものです。
2026 年、放置した GAS が壊れ始める
「動いているなら、わざわざ触らなくてもいいのでは」と思われるかもしれません。ですが 2026 年は、放置したスクリプトが自分から壊れにいく要因が重なります。
最も分かりやすいのが、旧ランタイム Rhino の終了です。GAS は以前 Rhino という古い JavaScript エンジンで動いていましたが、現在は V8 ランタイムが標準で、Rhino は 2026 年 1 月 31 日以降に順次廃止される方針が示されています。長く放置されたスクリプトの中には、いまだ Rhino 前提で書かれ、V8 では動作が変わったりエラーになったりするものが残っています。Rhino と V8 には非互換があり、移行時にはスクリプトを点検して問題箇所を直す必要がある、と Google 自身が案内しています。つまり「ずっと動いていたから今後も動く」とは限らない。
加えて、GAS が叩いている各サービスの API やライブラリも、年々仕様が変わります。Gmail やドライブ、外部サービスの仕様変更に追従していないスクリプトは、ある日突然、前触れなく止まる。業務が依存しているスクリプトほど、止まったときの影響は大きく、しかも止まって初めて存在に気づく——これが、ブラックボックスを放置するいちばんの怖さです。
受託で立て直す: 可視化してから、直す
引き継いだ GAS の立て直しは、いきなり書き換えから入りません。まず全体を見えるようにし、それから直すという順序が肝心です。
| 段階 | やること | 目的 |
|---|---|---|
| 棚卸し | どこに・いくつ・どんなトリガーで動くスクリプトがあるかを洗い出す | 存在の把握 |
| 可視化 | 各スクリプトが読む・書く・送る対象と業務上の役割を台帳化 | 中身の把握 |
| 健全化 | V8 への対応、危険な権限や共有の是正、エラー処理の追加 | 止まらない・漏れない |
| 文書化 | 仕様・運用手順・再実行の方法を Runbook に残す | 属人化の解消 |
| 内製化支援 | 担当者が読み・直せるよう引き渡し、教育する | 継続できる体制 |
最初の棚卸しと可視化が、実は最も価値があります。「会社のどこに、何のために、何を触るスクリプトが、いくつあるのか」を一覧にするだけで、止まったら困る重要なものと、もう使われていない放置物の区別がつく。そのうえで、重要なものから V8 対応やエラー処理の追加、危険な共有設定の是正を進めます。この「運用を見える化して、止まらない形に整える」流れは、Google Workspace CLI で情シス運用を自動化する記事 で扱った棚卸し起点の考え方と一貫しています。
そして忘れてはならないのが、最後の文書化と内製化支援です。せっかく立て直しても、また一人の担当者の頭の中に仕様を戻してしまえば、数年後に同じ相談を繰り返すことになる。仕様と運用手順を Runbook として残し、担当者自身が読めて直せる状態にするところまでが、保守の受託としての仕事です。
弊社の事例: 退職者の GAS が決算直前に止まりかけた
具体例を挙げます。ある卸売業の中堅企業（社名は伏せます）から、「経理が毎月使っている集計スプレッドシートの自動処理が、たまに数字が合わなくなる。作った担当者は半年前に退職していて、誰も中身が分からない」という相談を受けました。決算期が近づき、さすがに放置できなくなって、というタイミングでした。
中を開けてみると、複数のスプレッドシートにまたがって時間主導トリガーのスクリプトが動いており、一部は Rhino 前提の古い書き方のまま、エラーが起きても何事もなかったかのように処理を続ける作りになっていました。だから「たまに数字が合わない」という曖昧な症状になっていたのです。途中でデータ取得に失敗しても止まらず、欠けたまま集計を進めてしまう。誰も気づかないまま、月によって結果がぶれていました。
私たちはまず、関係するスクリプトとトリガーをすべて洗い出して一覧にし、それぞれが何を読んで何を書くのかを経理の担当者と一緒に確認しました。そのうえで、V8 で安全に動くよう書き直し、データ取得に失敗したら処理を止めて担当者に通知する仕組みを入れ、最後に「この処理は何のために・いつ・何を触るか」を一枚の手順書にまとめて渡しました。派手な機能追加は一切していません。見えなかったものを見えるようにし、黙って間違えるコードを、間違えたら止まって知らせるコードに変えただけです。決算直前に数字が静かにずれる、という最悪の事態は、これで避けられました。
不安が小さいうちに棚卸しを
引き継いだ GAS への対処で大事なのは、止まってから慌てるのではなく、動いているうちに棚卸しをしておくことに尽きます。重要な処理ほど、止まったときの代償は大きく、復旧の手がかりも残っていません。まだ動いている今こそ、何がどこで動いているかを一覧にし、止まったら困るものから順に健全化しておく。これが、いちばん安く済むタイミングです。
毎朝動いている正体不明のスクリプトが不安、退職者が残した GAS を誰も触れずに困っている、Rhino 終了で何が止まるのか棚卸ししておきたい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現存するスクリプトとトリガーを洗い出し、どれが業務の急所で、どれが安全に整理できるかを可視化したうえで、止まらず・漏れず・自社で育てられる形へ立て直します。
