Google Apps Script（GAS）で作った社内ツールを、コマンド一発で更新できるようにしていました。その一発で、別のお客様の稼働中システムを丸ごと上書きする寸前まで行ったことがあります。
幸い、実行する前に気づきました。ただ、気づけたのは運がよかっただけで、あと一手進んでいたら復旧できなかった類の事故です。この記事では、何が起きていたのか、なぜ気づきにくいのか、そして今は改修前に必ずやっている4つの確認をまとめます。
GASで社内ツールを作っている方、これから複数の案件を並行して触る方に向けた実体験の記録です。
何が起きていたか
GASのコードをローカルのパソコンで書いて、clasp push というコマンドでクラウド側へ送る運用をしています。どのプロジェクトへ送るかは、そのフォルダの中にある .clasp.json という設定ファイルに書かれた scriptId（プロジェクトごとの識別番号）だけで決まります。
問題はここでした。花屋さんの顧客管理システムのコードが入ったフォルダの .clasp.json が、電気工事会社の見積システムのscriptIdを指していたのです。
見積システムのほうは、すでに本番稼働中でした。毎日その画面から見積を作っている状態です。もしそのフォルダで clasp push を実行していたら、見積システムのコードが全部、花屋さんのコードで上書きされて消えていました。しかも clasp push はフォルダの中身をまるごと反映する動きなので、「一部だけ差し替わる」ではなく「全部入れ替わる」になります。
原因は単純なミスでした。ファイルのタイムスタンプを見ると、花屋さん側で15時21分、電気工事会社側で15時24分。電気工事会社の作業を始めるとき、直前まで開いていた花屋さんのフォルダで先にコマンドを打ってしまった残骸が、そのまま設定ファイルに残っていたわけです。3分の取り違えが、10日後に地雷として残っていたことになります。
なぜ気づきにくいのか
この事故が怖いのは、手前で誰も止めてくれないことです。
clasp push は「そのフォルダはこの前まで別のプロジェクトを指していましたよ」とは教えてくれません- コードの中身が全然違っても、警告は出ません。中身の一致は誰もチェックしていないからです
- 実行すれば「成功」と表示されます。壊れたことは、お客様から連絡が来て初めて分かります
そして最大の落とし穴は、自分の記憶が当てにならないことでした。「このフォルダはあの案件」という対応は、頭の中では正しく覚えているつもりでした。実際に狂っていたのは設定ファイルのほうで、こちらは開かない限り目に入りません。
私のパソコンには今、10個以上のGASプロジェクトのフォルダが同居しています。クライアント案件だけでなく、自社の問い合わせフォーム、チャットボット、Drive整理ツールなども全部同じ形式です。数が増えるほど、この地雷を踏む確率は上がっていきます。
改修前に必ずやる4つの確認
事故を寸前で止めたあと、本番へ反映する前のチェックを4つに固定しました。慣れれば1分もかかりません。
1. scriptIdを目で見て、案件の記録と照合する
まず、そのフォルダの設定ファイルを開いて中身を見ます。
cat .clasp.json
出てきたscriptIdを、案件フォルダに置いてある「案件サマリー」に記録してあるscriptIdと突き合わせます。ポイントは、案件ごとに正しいscriptIdをテキストで記録しておくこと。記録がないと照合しようがありません。私は案件フォルダを作った時点で必ず書き残すようにしました。
2. そのscriptIdが、別案件の記録にヒットしないか検索する
これが一番効きます。作業フォルダ全体を、そのscriptIdで検索します。
grep -rl "<scriptId>" ~/作業フォルダ
別の案件のサマリーやメモにヒットしたら赤信号です。今回のケースは、まさにこれで見つけられる形でした。「このIDは他の案件のものとして記録されている」が一目で分かります。
3. 送るファイルの一覧を確認する
clasp status
これで「push対象になっているファイル」の一覧が出ます。見覚えのないファイル名が並んでいたら、そのフォルダは自分が思っている案件ではありません。 中身で気づける最後の砦です。
4. 本番側との差分を取る（ローカルが古い事故を防ぐ）
scriptIdが正しくても、まだ安心はできません。手元のコードが古いまま push すると、その間に誰かが本番側で直した修正を巻き戻してしまうからです。
なので本番へ入れる前に、いったん本番側の最新を引っ張ってきて、手元のコードと見比べます。ここで注意点がひとつあります。案件フォルダの中で直接 clasp pull を実行してはいけません。 手元のコードが本番側の内容で上書きされ、書いたばかりの修正が消えます。
安全な手順は、作業用の一時フォルダに設定ファイルだけコピーして、そこで clasp pull して差分を見ることです。手元と本番、どちらが新しいかを確認してから反映します。
仕組みで防ぐ側に寄せる
チェックリストは有効ですが、疲れている日ほど飛ばしたくなります。なので、そもそも取り違えが起きにくい形にしておくのも合わせて必要でした。
- 案件フォルダの中に、別案件のコードを絶対に置かない。 今回の事故は「プロンプト集の中に、ある案件のGASコードを置いていた」ことが遠因でした。置き場所が案件と対応していないフォルダは、それだけで危険です
- 本番へ入れる前に、その時点のコードをバックアップフォルダへコピーしておく。 私は
_本番push前バックアップ_日付 というフォルダを作って残しています。戻せる状態を作っておくと、判断が慎重になります - 作業を切り替えるときは、ターミナルの現在地を必ず確認する。 「別案件を触った直後」が一番危ない瞬間です
まとめ
社内ツールを自分たちで直せるようにするのは、外注の待ち時間がなくなるという意味でとても価値があります。ただ、便利なコマンドは、間違ったフォルダで打っても同じ勢いで実行されます。
- 反映先のIDは、記憶ではなく設定ファイルと記録の照合で確かめる
- そのIDが他の案件にも出てこないか検索する
- 送るファイルの一覧を見て、中身で最終確認する
- 手元が古くないか、本番との差分を取ってから入れる
今回はたまたま気づけましたが、次も気づける保証はありません。仕組みで止まるようにしておくのが結局は一番早い、というのが得られた教訓です。
UMEO CREATEでは、GASを使った社内ツールの開発と、作ったあとに自社で安全に直していける体制づくりのご相談を承っています。「作ってもらったツールを触るのが怖い」「担当が変わって中身が分からない」という方は、お問い合わせフォームまたはLINEからお気軽にご相談ください。
