Claudeで作った業務GASが突然止まる｜トリガー・権限・実行時間の3大原因と復旧手順

「Claude Codeに書かせたGoogle Apps Script（GAS）が、昨日まで動いていたのに今朝は動いていない」。業務を自動化した人ほど、この場面に一度は出くわします。厄介なのは、コードは1文字も変えていないのに止まる点です。

先に結論です。Claudeで作った業務GASが突然止まる原因は、コードのバグより先に、次の3つのどれかを疑ってください。

• トリガー：自動実行の予約（トリガー）が無効化された・そもそも設定されていなかった
• 権限・承認：スクリプトの承認が切れた、実行するアカウントと権限がズレている
• 実行時間：処理が6分の実行時間制限を超えて途中で打ち切られた

この3つで、体感9割は説明がつきます。そして重要なのは、GASは「止まる前提」で設計しておけば、止まっても数分で復旧できるということです。この記事では、graciautoで本番運用しているGAS3本の実装をもとに、止まる原因の切り分け方と、最初から止まりにくく作る設計を具体的に示します。

対象は、Claude CodeでGASを書いて業務を自動化している店舗経営者・WEB担当者の方です。プログラマーでなくても、どこを見れば原因が分かるかまで持ち帰れる内容にしています。

まず「実行数」ログを見る。エラーは必ず記録されている

GASが止まったとき、最初にやることは1つだけです。Apps Scriptエディタの左メニューにある「実行数」（実行ログ）を開くこと。

ここには、その関数がいつ実行され、成功したか失敗したかがすべて残っています。手で押した実行も、トリガーによる自動実行も、外部から叩かれたWebアプリの実行も、全部記録されます。ステータスが「失敗」の行を開けば、エラーメッセージがそのまま読めます。

つまり、「なぜか止まった」という状態は本来ありません。止まった理由は必ずログに書いてある。ここを見ずに勘でコードをいじり始めるのが、一番時間を溶かすパターンです。

ログのエラー文面と、この記事の3大原因を照らし合わせれば、たいてい切り分けは終わります。以下、原因ごとに実例を挙げます。

原因1：トリガーが「設定されていない」または「無効化された」

一番多いのがこれです。GASには2つの実行のされ方があり、混同すると「動くはずなのに動かない」が起きます。

• 手動実行：エディタの実行ボタンを押したときだけ動く
• トリガー実行：時刻や編集イベントをきっかけに自動で動く

graciautoでは、スプレッドシートに開始日・終了日を入れると自動で色が付き、Googleカレンダーにも登録されるガントチャート管理のGASを運用しています（名古屋の美容サロンFCの新店舗オープン準備で使っているものです）。これはシート編集をきっかけに動く onEdit トリガーで組んでいます。

ここで正しい作り方はこうです。シートの編集で自動的に動かしたい処理は、そのスプレッドシートに紐づいた（コンテナ紐づき型）スクリプトに書き、トリガーを明示的に設定する。

なぜこれを最初に守るかというと、次の失敗が起こり得るためです。onEdit という名前の関数を書いただけで自動実行される「シンプルトリガー」と、管理画面から登録する「インストーラブルトリガー」は別物です。カレンダー登録のように外部サービスへ書き込む処理は、権限の都合でシンプルトリガーからは動きません。名前だけ onEdit にして「設定した気になっている」と、編集しても何も起きない——これが「トリガーが設定されていない」の正体です。

もう1つ、時間主導トリガー（毎朝9時など）は、実行が続けて失敗すると自動的に無効化されるという仕様があります。graciautoでは、期限が3日以内に迫ったタスクをSlackに通知する処理を朝のトリガーで回していますが、こうした定期実行は「ある日から通知が来なくなる」形で気づくことが多い。止まったのではなく、過去に何度か失敗した結果、GoogleがそのトリガーをOFFにしたわけです。復旧は、トリガー画面で失敗理由を確認し、原因を直したうえでトリガーを再登録するだけです。

判断基準はシンプルです。手で実行すると動くのに、放っておくと動かない。これはコードではなくトリガーの問題です。

原因2：権限・承認のズレ。「誰の権限で動くか」を最初に決める

コードもトリガーも正しいのに You do not have permission のようなエラーで止まる場合、権限・承認を疑います。

正しい設計は、「そのスクリプトを誰のアカウントで、どのリソースに対して動かすか」を作る前に決めておくことです。ここが曖昧なまま作ると、次のような形で止まります。

• スクリプトが新しくカレンダーやGmailなどに触れる処理を追加すると、追加のアクセス承認（OAuth）を求められる。承認し直すまでその関数は動きません。Claudeにコードを書き足してもらったあと急に動かなくなったら、まず手動実行して承認ダイアログが出ないか確認します。
• 外部から叩くWebアプリとしてデプロイする場合、「実行するユーザー（自分／アクセスしたユーザー）」と「アクセスできるユーザー（自分だけ／全員）」の設定次第で、他人や外部システムからのアクセスが弾かれます。

graciautoでは、チャットやスマホから送った文言を1枚のスプレッドシートにタスクとして自動登録する仕組みを、外部から叩けるWebアプリ（スタンドアロン型のGAS）として公開しています。この形にするときの勘所は、アクセス権を「全員（匿名を含む）」にしたうえで、実行は自分の権限で行う設定にそろえること。ここがズレると、「自分がエディタから叩くと動くのに、外部から送ると403で弾かれる」という、原因1とよく似た症状になります。

権限まわりでもう1つ実務的に効くのが、外部サービス側の認証情報の失効です。Slack通知のWebhook URLや、WordPressへ投稿するためのアプリケーションパスワードは、GAS側は無傷でも相手側で失効・再発行されると通信が通らなくなります。GAS本体を疑う前に、外部連携の鍵が生きているかを確認すると早い。実際、WordPress連携が突然401で通らなくなる事象では、パスワードそのものより「サーバーがAuthorizationヘッダーをアプリに渡していない」といった経路側の問題が原因になることもあります。「コードは無傷、鍵か経路が原因」という視点を持っておくと復旧が速くなります。

原因3：実行時間の6分制限。ループで全行を走査すると超える

GASには、1回の実行は6分までという制限があります（無料アカウントの場合）。これを超えると Exceeded maximum execution time で強制終了します。

厄介なのは、データが少ないうちは3秒で終わっていた処理が、行数が増えた半年後に突然6分を超えて止まる点です。コードは変えていないのに止まる、の典型がこれです。

正しい作り方は、セルを1個ずつ読み書きするループを避け、範囲でまとめて読み書きすること。graciautoの月次シートコピーやガントチャートのGASでは、getRange().getValues() で必要な範囲を一括取得し、加工してから setValues() で一括反映する形にしています。1行ずつ getRange().getValue() を回すと、行数×通信回数だけ遅くなり、データが育った時点で6分の壁に当たります。

これは「起こってから直す」より「最初から一括処理で書く」ほうが圧倒的に楽です。Claudeにコードを書かせるときも、プロンプトに「セル単位のループではなく範囲一括で読み書きして」と一言入れておくと、実行時間で詰まる将来のリスクを先に潰せます。それでも重い処理は、対象を分割して複数回に分ける・時間主導トリガーで少しずつ処理する、といった設計に切り替えます。

「直したのに止まったまま」は、反映のされ方の違いが原因

3大原因とは別に、復旧作業そのものでつまずくポイントがあります。コードを直したのに症状が変わらないというケースです。

これはGASの2つの形態で、コードの反映のされ方が違うために起きます。

• スプレッドシートに紐づいたスクリプト（ガントチャート・月次コピーなど）：保存すれば次の実行から新しいコードで動く
• Webアプリとして公開したスタンドアロンのスクリプト（外部から叩くタスク登録など）：保存だけでは公開中のURLに反映されない。デプロイを更新して初めて反映される

「直したのに止まったまま」に見えるとき、実は古いコードが動き続けている——これが起こり得ます。Webアプリ型を修正したら、デプロイの更新まで必ずセットで行う。これを手順に組み込んでおくだけで、原因不明の「直らない」を1つ減らせます。

なお、外部からGASのWebアプリを叩くときは、コマンドラインの curl だと、GASのリダイレクト仕様でPOSTがGETに化けて意図通り動かないことがあります。連携スクリプトはPythonなどリダイレクトを正しく処理する方法で叩く、と決めておくと安定します。

止まる前提で作るための、作成時チェックリスト

3大原因を踏まえると、Claudeにコードを書かせる段階で織り込んでおくべきことが見えてきます。復旧を速くする一番の近道は、最初の設計です。

1. 自動実行が必要な処理は、トリガーを明示的に設定したか（名前を onEdit にしただけで満足しない）

2. 外部サービスに触れる処理は、承認と実行アカウントを確定させたか

3. 行数が増えても耐えるよう、範囲一括で読み書きしているか

4. Webアプリ型は、修正時にデプロイ更新まで行う運用にしたか

5. 止まったらまず「実行数」ログを見る、を手順化したか

この5つを最初に押さえておけば、GASが止まっても「どこを見ればいいか分からない」状態にはなりません。

よくある質問

Q. コードは変えていないのに、ある日から動かなくなりました。なぜですか。

A. 多くは「トリガーが失敗続きで無効化された」か「データが増えて6分の実行時間制限を超えた」かのどちらかです。まず実行ログを開き、失敗した行のエラーメッセージを確認してください。

Q. 手で実行すると動くのに、自動では動きません。

A. トリガーの問題である可能性が高いです。トリガー画面で登録状況と失敗理由を確認し、原因を直してから再登録します。関数名を onEdit にしただけでは、外部サービスへ書き込む処理は動きません。

Q. 自分は使えるのに、他の人や外部システムから叩くとエラーになります。

A. Webアプリのアクセス権と実行ユーザーの設定を確認してください。「アクセスできるユーザー＝全員」「実行するユーザー＝自分」にそろえるのが基本です。修正後はデプロイの更新も忘れずに。

Q. エラー内容を読んでも意味が分かりません。

A. エラーメッセージをそのままClaudeに貼り付け、「このGASのエラーの原因と直し方を教えて」と聞くのが速いです。実行ログの文面と、この記事の3大原因を突き合わせれば、たいていは切り分けられます。

まとめ

Claudeで作った業務GASが突然止まったら、コードを疑う前に「トリガー・権限・実行時間」の3つを順に確認します。原因は必ず実行ログに残っているので、勘で直し始めないことが最短の復旧ルートです。

そして、止まりにくいGASは復旧時ではなく作成時に決まります。トリガーを明示し、権限と実行アカウントを確定させ、範囲一括で書き、Webアプリ型はデプロイ更新まで運用に組み込む。この設計を最初に入れておけば、自動化は「作って終わり」ではなく「動き続ける仕組み」になります。graciautoでは、こうした業務自動化の設計から本番運用までを一貫して支援しています。GASでの自動化がうまく動き続けずお困りの場合は、お気軽にご相談ください。