Claude CodeでGAS開発を回す実務フロー｜「直したのに反映されない」を防ぐデプロイの急所
Claude CodeでGAS開発を回す実務フロー｜「直したのに反映されない」を防ぐデプロイの急所
Claude CodeにGAS（Google Apps Script）を書かせること自体は、もう難しくありません。シート構造と要件を渡せば、動くコードは数分で返ってきます。実際にハマるのはコードではなく、そのあとの「反映」です。コードを直したのに動作が変わらない、デプロイし直したらURLが変わって呼び出し側が全部壊れた——GAS開発の手戻りは、ほぼここで起きます。
先に結論です。Claude CodeでGAS開発を回すときは、次の3点を押さえた開発ループを最初に作ります。
- 「保存だけで反映されるGAS」と「再デプロイしないと反映されないGAS」を区別する。トリガーで動く関数は保存のみでよく、doGet/doPostのWebアプリはバージョン更新が必要
- Webアプリの更新は「新しいデプロイ」ではなく「デプロイを管理→編集→新バージョン」で行い、URLを変えない
- 反映確認はエディタ上のテスト実行ではなく、実際の呼び出し経路（curlや呼び出し元の画面）で行う
graciautoでは、チャットからのタスク自動登録、月次シートの自動コピー、ガントチャートの色付け＋カレンダー連携、社内の案件管理ボード（Webアプリ配信）といったGASをClaude Codeで書き、いずれも本番運用しています。この記事では、その運用で実際に踏んだ「反映まわりの落とし穴」を、予防策とセットで共有します。プロンプトの書き方そのものは別記事「ClaudeにGASを書かせるプロンプトの型」にまとめているので、本記事は「返ってきたコードを本番に反映して回し続ける」工程に絞ります。
Claude Code×GASの開発ループ全体像
うちで回している開発ループは次の形です。
- GASコードはローカルの.gsファイルとして管理し、Claude Codeに書かせる・直させる
- 出来上がったコードをApps Scriptエディタに貼り付けて保存する
- Webアプリ（doGet/doPost）の場合は「デプロイを管理」からバージョンを更新する
- 実際の呼び出し経路（curl・スプレッドシート・呼び出し元の画面）で反映を確認する
- エラーや仕様変更が出たら、エラーメッセージと現象をそのままClaude Codeに渡して修正版を作らせる
ポイントは、コードの正本をApps Scriptエディタではなくローカルに置くことです。エディタ上で直接直し始めると、ローカルとエディタの内容がズレて「どちらが最新か分からない」状態になります。Claude Codeは自分が書いたローカルファイルを差分で修正できるので、正本をローカルに固定しておけば、コードの履歴と一貫性を保ったまま修正のループを回せます。
なお、Apps Scriptにはclaspという公式のCLIツールがあり、ローカルのコードをコマンドでpushできます。エディタへの貼り付け作業を根本からなくしたいならclaspが正攻法です。ただ、うちは現時点でclaspを入れずに貼り付け運用で回しています。GASの本数が数本で、更新頻度も週に数回程度なら、貼り付け運用でも実務は十分回るというのが実感です。逆に、毎日のように更新するGASが増えてきたら、貼り付け起因のミス（後述します）が積み上がるので、claspへの移行を検討する段階だと判断しています。
急所1: 保存だけで反映されるGASと、されないGASがある
最初に押さえるべきはここです。GASは実行のされ方によって、コード更新の反映条件が違います。
- スプレッドシートに紐づくトリガー型（onEditや時間主導トリガー、メニューから手動実行する関数）: エディタで保存すれば次の実行から新コードが動く。再デプロイ不要
- Webアプリ型（doGet/doPostをURL経由で呼ぶもの）: 保存しただけでは公開中のURLは古いバージョンのまま。バージョン更新（再デプロイ）で初めて反映される
この区別を知らないと、「コードを直して保存したのに、URLを叩くと古い動作のまま」という状態になります。しかも見た目上は何のエラーも出ないため、コードのバグを疑ってしまい、原因特定に時間を溶かします。
うちの実例だと、タスク自動登録のGASはスプレッドシート紐づきのトリガー型なので、9列対応などの仕様変更は保存だけで反映されてきました。一方、案件管理ボードはWebアプリ型なので、機能追加のたびにバージョン更新が必要です。同じ「GASの修正」でも反映の手順が違うため、Claude Codeにコードを書かせる時点で「これはトリガー型かWebアプリ型か」を意識しておくと、反映漏れを防げます。
貼り付け運用では「エディタに貼ったが保存していなかった」「保存したがバージョン更新を忘れた」という抜けが起こりえます。実際にうちでも、修正が反映されない原因を調べたら保存忘れ・バージョン選択ミスだった、というケースが複数回ありました。対策は根性ではなく手順の固定化です。うちでは「貼り付け→保存→（Webアプリなら）バージョン更新→実経路で確認」を1セットとして、確認まで終えて初めて完了扱いにしています。
急所2: 「新しいデプロイ」はURLが変わる。更新は「新バージョン」で
Webアプリの更新でもう1つハマりやすいのが、デプロイの仕方そのものです。Apps Scriptのデプロイには2つの操作があります。
- 新しいデプロイ: 新しい/exec URLが発行される
- デプロイを管理→編集→バージョン: 新規作成: URLは変わらず、中身だけ新コードに更新される
コードを更新するときに使うべきは後者です。「新しいデプロイ」を選ぶとURL自体が変わるため、そのURLを呼んでいるHTML・スクリプト・外部サービスの設定をすべて書き換える必要が出ます。呼び出し元が1か所ならまだしも、ダッシュボードやタブレット表示など複数の画面から同じGASを呼んでいる構成だと、書き換え漏れが起きた箇所だけ古いGASを叩き続けることになります。
うちの案件管理ボードでは、画面表示用とデータAPI用で複数のデプロイが同じプロジェクトに共存する構成になっており、URLが変わる更新をすると影響範囲の確認だけで一仕事です。だからこそ、通常の更新は「同じURLのままバージョンだけ上げる」を原則にしています。
補足として、デプロイ管理画面のバージョン選択ドロップダウンが操作に反応しない、というUI上の不具合に遭遇したこともあります。こうしたとき、復旧を急いで「新しいデプロイ」で逃げると、今度はURL変更の影響が呼び出し側に波及します。UIの不調時こそ、ブラウザや環境を変えて「同じURLのままバージョンを上げる」手段を先に探すのが安全です。
急所3: 反映確認は「実際の呼び出し経路」で行う
コードを反映したら、最後は動作確認です。ここで大事なのは、エディタ上のテスト実行ではなく、本番と同じ経路で確認することです。GASのWebアプリには、エディタからのテスト実行では見えない経路特有の挙動がいくつかあります。
- POSTで送ったはずがGETとして届く: GASのWebアプリはリクエストをリダイレクト経由で処理するため、送り方によってはPOSTがGETに変わって届くことがある。curlでテストして「手元では成功したのに本番から動かない」となりやすい。うちではタスク登録GASへの送信をcurlからPythonのurllibに変えて解決した。詳しい切り分けはGAS中継の実装記事にまとめている
- 複数のGoogleアカウントにログインしたブラウザでWebアプリURLが開けない: URLにアカウント切り替えのパスが差し込まれて認証エラーになることがある。ブラウザのプライベートウィンドウか、ログインしていない環境（curl等）で確認すると切り分けられる
- スプレッドシートの型自動変換で比較が壊れる: GASから文字列として書き込んだ値をスプレッドシートが数値や日付に自動変換し、読み出し時に厳密比較（===）が一致しなくなることがある。削除フラグを'1'という文字列の一致で判定していると、数値に変換された後は一致せず「消したはずのデータが復活して見える」事態が起こりうる。書き込み時に先頭へアポストロフィを付けて文字列固定するか、比較を真偽値判定に寄せる設計にしておくと防げる
3つ目は反映確認というよりGAS本体の仕様ですが、「エディタでは正しく動くのに、あとからおかしくなる」という形で表面化するため、実経路での確認と日を置いた再確認をセットにしておくと早期に気づけます。
もう1つ、貼り付け運用特有のリスクとして、新旧コードの混在があります。古い関数を消さずに新コードを追記していくと、同名の補助関数が二重定義になったり、消したはずの関数を参照して「〇〇 is not defined」が出たりします。うちでもガントチャートGASの更新時にこの型のエラーを踏みました。修正版を貼るときは差分の継ぎ足しではなく、ファイル全体を全削除してから貼り直すのが確実です。
Claude Codeに任せる範囲と、人が握る範囲
ここまでの内容を踏まえると、分担は自然に決まります。
- Claude Codeに任せる: コードの新規作成・修正、エラーメッセージからの原因特定、スプレッドシートの構造に合わせた実装、型変換対策のような防御的な書き方
- 人が握る: エディタへの反映と保存、バージョン更新の実行、本番経路での動作確認、認証まわりの設定
特にデプロイと動作確認は、権限とブラウザ操作が絡むため人側の仕事です。逆に言えば、人がやるのはこの数分の定型作業だけで、頭を使う部分はほぼClaude Codeに寄せられます。LINE連携のような外部サービスが絡む構成でも、この分担は同じです（LINE Bot構築の工程はこちらの記事で解説しています）。
よくある質問
Q. claspは最初から導入すべきですか？
GASが1〜2本で更新頻度が低いうちは、貼り付け運用で十分です。claspの導入自体にもNode.js環境や認証の設定コストがあるため、最初の1本を動かす前に入れる必要はありません。判断の目安は「貼り付け起因のミス（保存忘れ・貼り間違い・新旧混在）を月に何度も踏むようになったら」です。そうなったら、Claude Codeとの相性という点でもローカル正本をそのままpushできるclaspに移行する価値があります。
Q. コードを直したのに動作が変わらないとき、何から確認すればいいですか？
順番に3つです。まず、エディタで保存されているか（貼り付けただけで保存していないケース）。次に、Webアプリ型ならバージョン更新をしたか（保存だけでは公開URLに反映されません）。最後に、確認している経路が本番と同じか（エディタのテスト実行や複数アカウントのブラウザでは、本番と挙動が違うことがあります）。経験上、この3つで大半は説明がつきます。ここまで確認して変わらない場合に、初めてコード本体を疑います。
Q. Claude Codeではなく、ブラウザ版のClaudeでもGAS開発はできますか？
コードを書かせるだけならブラウザ版でも可能です。ただし、コードの正本をローカルファイルとして管理し、修正を差分で依頼し、エラーログを貼って原因を特定させる、というループを回すならClaude Codeのほうが向いています。どちらを使う場合でも、渡すべき情報（シート構造・実行方法・制約）は同じなので、指示の作り方はプロンプトの型の記事を参考にしてください。
Q. GASの更新を自動化しきれば、人の作業はゼロにできますか？
現状、完全ゼロは推奨しません。デプロイの実行と本番確認まで自動化すると、壊れたコードがそのまま本番に載るリスクを止める関門がなくなります。うちでも「コードを書くのはAI、本番に載せる判断と確認は人」という線引きは維持しています。
まとめ: GAS開発の手戻りは「反映の手順化」でほぼ消える
Claude CodeとGASの組み合わせは、コードを書く工程を劇的に短くします。その分、残った手作業——貼り付け・保存・バージョン更新・動作確認——が品質の急所になります。最後にチェックリストとしてまとめます。
- トリガー型かWebアプリ型かを最初に確認する（反映条件が違う）
- Webアプリの更新は「デプロイを管理→新バージョン」でURLを変えない
- 貼り付けは全削除→貼り直しで新旧混在を防ぐ
- 反映確認は本番と同じ経路で行う
- 「貼り付け→保存→バージョン更新→実経路確認」を1セットの手順として固定する
graciautoでは、こうしたGAS・スプレッドシート・LINEを組み合わせた業務自動化を、自社と店舗ビジネスの現場で構築・運用しています。「社内の定型作業をGASで自動化したいが、作ったあと回せるか不安」という段階のご相談も歓迎です。まず何から自動化すべきかの判断からお手伝いします。