目次
GAS（Google Apps Script）の開発をローカルで行うとき、多くの現場が使っているのがclaspです。手元のエディタでコードを書き、clasp pushでGAS側へ反映する——この流れは快適ですが、複数人で触っていると静かに事故が起きます。
clasp push --forceは、GASエディタ側で他の人が加えた編集を、警告なく上書きします。
実案件（匿名）で、共同開発者が直接エディタで直した内容が、無言で失われたことがありました。エラーも警告も出ません。気づいたのは後になってからです。この記事では、なぜそれが起きるのか、そして「ロックがない前提」でどう設計するかを整理します。
この記事の結論
- GASには競合検知がなく、pushは常に上書きになる
- 数秒のズレでも他者の編集は警告なく消える
- 担当分離・事前宣言・安全push・Gitの4層で防ぐ
clasp push --forceで変更が消える原因とは
一般的なバージョン管理やAPIには、更新の衝突を検知する仕組みがあります。ETag（内容が変わったかを示す識別子）や楽観ロック（自分が読んだ時点から変わっていたら更新を拒否する仕組み）です。これがあれば「あなたが読んだ後に、誰かが更新しています」と教えてくれます。
GASにはこの仕組みがありません。
そのため、clasp pushは「ローカルの内容をリモートの正解として書き込む」動作になります。リモート側が自分のpull以降に変わっていても、判定しないまま上書きします。
怖いのは、この隙間が数秒でも成立する点です。pullしてから自分の修正を書き、pushするまでの短い時間に相手がエディタで1行直せば、それは消えます。「今は誰も触っていないはず」という前提が、そのまま事故の原因になります。
なお、claspやGASの仕様は変わるため、最新の挙動は公式ドキュメントで確認してください。
起きる事故の性質：エラーが出ないから気づかない
この事故が厄介なのは、失敗として現れないところです。
| 通常の競合 | GASのpush上書き |
|---|---|
| エラーやコンフリクトで止まる | 正常終了する |
| その場で気づける | 後日、動作の違和感で気づく |
| 差分を見て解決できる | 消えた内容が残っていない |
つまり「注意して作業する」では防げません。注意力に頼る対策は、静かに失敗する事故には効きません。 仕組みの側で、競合そのものが起きない状態を作る必要があります。
対策：GASにロックがない前提の4層防御
私たちが実案件（匿名）で敷いたのは、次の4層です。1つで完璧を狙わず、抜けても次の層で止める構成にしています。
1. 担当ファイルを分ける（競合の発生源を消す）
まず、同じファイルを2人が同時に触らない状態を作ります。機能単位でファイルを分割し、「この.gsはこの人」と決めておくだけです。
技術的な仕掛けは要りません。それでも効果が最も大きいのはこの層です。競合は「同じ場所を同時に触る」から起きるので、そこを分けてしまえば、後段の防御が働く場面自体が減ります。
2. push前に宣言する（人の側のロック）
ツールにロックがないなら、人が代わりにロックします。clasp pushの直前に、チャットで「今からpushします」と一言送るだけのルールです。
原始的に見えますが、これはロックのない仕組みに、擬似的なロックを外付けする発想です。相手がエディタを開いていれば「今直してる」と返ってきます。数秒の隙間を、宣言によって塞ぎます。
3. 安全pushスクリプト（差分を見てから送る）
3層目で、機械的なチェックを入れます。いきなりpush --forceせず、次の順で動くスクリプトにします。
- 先に
pullして、リモートの現状を取得する - 自分の手元の内容との差分を表示する
- 想定していない変更が混じっていないか目で確認する
- 問題なければ
pushする
やっていることは単純ですが、これで「知らないうちに誰かが直していた」を送信前に発見できます。ポイントは、pushコマンドを直接叩く習慣をやめ、必ずこのスクリプト経由にすることです。手順を覚えるのではなく、手順を1つのコマンドに固定します。
4. Gitで履歴を保全する（最後の砦）
それでも上書きが起きたときのために、GAS側だけを正とせず、ローカルをGitで管理します。commitが残っていれば、消えたコードの多くは復元できます。
GASエディタにも版の管理機能はありますが、普段の作業単位で細かく残せるのはGit側です。「戻せる状態を常に持っておく」ことが、事故を事故のまま終わらせない条件になります。
この4層の使い分けと優先順位
全部を一度に入れる必要はありません。少人数の現場なら、次の順で始めるのが現実的です。
| 層 | 導入の手間 | 効果 | まず入れるべきか |
|---|---|---|---|
| 担当ファイル分離 | 小 | 大 | 最優先 |
| push前の宣言 | 小 | 中〜大 | すぐ入れる |
| 安全pushスクリプト | 中 | 大 | 2人以上なら必須 |
| Git管理 | 中 | 保険 | 早めに入れる |
上2つは今日から始められます。下2つは初回の準備が必要ですが、一度作れば以後は考えずに済みます。
持ち帰る判断軸：ツールに競合検知がなければ、運用で起こさない
この話はclaspに限りません。中小企業の業務システムでも、同じ構造の事故が起きます。共有ファイルの上書き、同じ台帳への同時入力、SaaS間の連携で片方のデータが後から来た値に潰される——いずれも競合を検知する仕組みがないところに、同時アクセスを持ち込んだ結果です。
判断軸はシンプルです。
- ツール側に競合検知があるか（ないなら、それを前提に設計する）
- ないなら、同時に触らせない（担当分離・宣言）
- それでも触るなら、送信前に差分を見る（スクリプト化）
- 最後に、戻せる状態を持つ（履歴保全）
「気をつける」で埋めようとしないことが肝心です。エラーが出ない事故は、注意では見つかりません。
よくある質問
Q. clasp push --forceで他人の変更が消えるのはなぜですか？ GASにはETagや楽観ロックのような競合検知の仕組みがないためです。pullからpushまでの数秒の間にエディタ側で加えられた編集も、警告なくローカルの内容で上書きされます。
Q. clasp pushする前に確認すべきことは何ですか？ リモート側が自分のpull時点から変わっていないかです。安全pushスクリプトで一度pullして差分を取り、想定外の変更がなければpushする手順にすると事故を防げます。
Q. GASを複数人で開発するときのルールはどう決めればいいですか？ ファイル単位で担当を分け、pushの直前にチャットで宣言する運用が基本です。あわせてGitで履歴を残せば、万一上書きしても直前の状態に戻せます。
まとめ
- GASには競合検知がなく、
clasp push --forceは常に上書きになる - pullからpushまでの数秒でも、他者の編集は警告なく消える
- 対策は4層：担当分離・push前の宣言・安全pushスクリプト・Git管理
- 一般化すると、競合検知のないツールは運用とスクリプトで競合を起こさない設計にする
RENOYでは、GASを使った業務自動化の開発だけでなく、複数人で安全に保守できる開発ルールの整備まで含めてお手伝いしています。「社内で作ったGASが誰も触れなくなっている」「作った人以外が直せない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。