Googleスプレッドシートに連動した自動処理を引き継いだ。シートは開けるし、コードも見える。それなのに毎朝の処理が来ない。こういうとき「スクリプトの中身が壊れた」と決める前に、誰がトリガーを作り、誰の権限で動く設計かを確かめたい。
GASのインストール型トリガーは、原則としてそのトリガーを作成したアカウントの権限で動く。シートの編集者が変わっても、実行者が自動で新担当へ移るわけではない。引継ぎではコードだけでなく、トリガーの所有者・必要な権限・実行履歴・失敗通知の届き先を一組で確認する。
Google公式のインストール型トリガーの説明は、トリガーが作成者のアカウントで実行されることを明記している。この記事では、毎朝の集計やシート更新のような一般的な自動化を想定する。特定企業の内部システムや認証情報を公開せず、担当交代時に確認できる範囲を整理する。
Amazonのアソシエイトとして、親父のスコアブックは適格販売により収入を得ています。
まずは記事とGoogle公式資料で確認できます。「権限やトリガーを基礎から整理したい」なら、この入門書も選択肢です。購入は必須ではありません。
Amazon｜紙の本
詳解！ Google Apps Script完全入門［第3版］
ISBN 9784798064741
商品画像は掲載していません。版・在庫・販売者・配送条件は商品ページで確認してください。
楽天ブックス｜紙の本
詳解！ Google Apps Script完全入門［第3版］
ISBN 9784798064741
楽天ブックスの公式商品画像付きリンク（書籍の表紙）
2021年刊行の第3版です。現在の画面や仕様、退職時の引継ぎ手順まで本書だけで確かめられるとは限りません。
「シートの持ち主」と「トリガーの作成者」を分ける
一つのスプレッドシートには、所有者、編集者、スクリプトを編集できる人、時間主導トリガーを作った人が関わる。これらを同じ「担当者」として覚えると、交代後の不調を見逃しやすい。新担当がシートを編集できても、前担当が作ったトリガーの実行主体まで引き受けたことにはならない。
たとえば、毎朝7時にデータを集計する関数を、前担当のアカウントでインストール型トリガーへ登録した場合。新担当がシートに編集権限を得て関数を手動実行できたとしても、それは前担当の時間主導トリガーが正常に動く証明にはならない。反対に前担当の実行が残っているところへ新担当も同じ処理を登録すれば、二つの入口ができる。結果の二重処理を防ぐには、既存の入口を把握してから切り替える。
「誰のトリガーか」は共有画面で見え方が違う
Google公式は、あるアカウントが作成したインストール型トリガーを別のアカウントから見られない場合があると説明する。新担当の画面にトリガーが表示されないことだけで「トリガーは存在しない」と断定しない。前担当が連絡可能なら、そのアカウントでプロジェクトとトリガー一覧を確認する。難しい場合は管理者や現在の管理手順に沿って、実行履歴と結果から現状を照合する。
トリガーが実行するコードは、権限を必要とするGoogleサービスや外部APIへ接続していることがある。担当者が変わると、同じ関数でも見られるファイルや使えるサービスが変わる。新担当で手動テストする際は、実データを書き換える関数をいきなり本番で試さない。まず対象ファイルと書込範囲、通知先、外部送信先を読み取りで確認する。
時間主導は分単位の約束と考えない
Google公式によると、時間主導トリガーは指定した時間帯の中で少しランダム化されることがある。「朝9時」の毎日実行を設定しても、毎回9時00分ちょうどを約束するものではない。実行が少し遅いだけなのか、予定時間帯を過ぎても履歴がないのかを分ける。社外公開や請求送信など時刻が重要な工程では、トリガーが動いた事実と、実際の送信完了を別に記録する必要がある。
動いていない朝は、実行履歴から始める
「今朝のシートが更新されていない」と分かったら、確認は三段階だ。まず予定時刻とトリガーの設定。次にApps Scriptの実行履歴。最後にシートや送信先の実際の結果。実行履歴がなければ、トリガー自体・アカウント・プロジェクトを調べる。履歴に失敗があれば、そのエラーと必要な権限を見る。成功と表示されていても出力がないなら、コードが対象行を選んだか、書込先を間違えていないかを調べる。
GoogleのApps Scriptダッシュボードでは、実行ごとの開始時刻、時間、状態、起動元などを確認できる。インストール型トリガーの失敗は画面を開いていない間に起きるため、公式説明は失敗通知メールと実行ログの確認を案内している。ただしメールが来ないことを無失敗の証拠にしない。通知の設定、受信先、迷惑メール処理も関わる。一次確認は実行履歴と実際の成果物だ。
コードを直す前に、止まった場所を言葉にする
「トリガーが起動しない」「起動したが権限エラー」「関数は成功したが対象データがない」「データはできたが外部投稿は未確認」。この四つを同じ「動かない」にまとめない。たとえば外部投稿APIが失敗したなら、シートの時刻トリガーを増やしても解決しない。むしろ送信不明の状態で再実行を重ねると二重投稿の危険がある。送信先の公式状態を確認してから、未完分だけ再開する。
Googleサービスには利用枠と制限があり、時間主導の実行には実行時間の上限もある。昨日まで動いていた処理が今日失敗した場合、権限だけでなく枠や処理量も候補に入る。ただしエラーを読まずに「きっと上限だ」と決めない。発生時刻、実行ID、失敗した関数と公式エラーを安全な内部記録に残す。ログに個人情報やAPIキーを出力しない。
担当交代の前に、二重起動を防ぐ切替順を決める
自動化を引き継ぐとき、最も避けたいのは「止まるのが怖いから新しいトリガーを足し、古いものも残る」状態だ。先に旧トリガーの作成者、関数名、実行頻度、直近結果を把握する。次に新担当が必要なアクセスを正規の管理手順で取得し、影響の小さい検査用データで手動確認する。その上で旧入口の停止と新入口の有効化の順を決める。削除前に設定と再開手順を記録する。
Googleのインストール型トリガーはプロジェクト画面または公式のScriptサービスで管理できる。ただし他人の認証を借りて操作する方法ではない。前担当が退職・異動した場合、組織の管理者や所有者の手続きに従う。個人アカウントで作った自動化なら、同じ問題を繰り返さないよう、今後の管理主体や復旧手段を決めておく。アカウントを共有するのではなく、権限の付与と引継ぎ記録を整える。
| 確認点 | NG（✕） | OK（◯） |
|---|---|---|
| 所有者 | シート編集者＝実行者と決める | トリガー作成者を別に確認 |
| 切替 | 旧トリガー不明のまま新規追加 | 旧入口と新入口の時刻・状態を照合 |
| 失敗 | 結果がないだけで再送 | 実行履歴と送信先を確認 |
| 引継ぎ | パスワードを渡す | 正規の権限と手順を管理 |
同時実行の対策は、重複投稿対策の一部
同時に二つの実行が同じ行を選んでしまう処理なら、GoogleのLockServiceで共有資源に触れる区間を保護する方法がある。ただしロックだけで、外部サービスへの送信が成功したか不明なケースまで解決するわけではない。処理ごとに一意のIDを持ち、送信前後の状態と外部の実結果を照合する設計が必要だ。ロックは「同時に触る」を抑え、送信の同一性確認は「もう一度送ってよいか」を判断する。役割を混同しない。
自動投稿・メール送信・請求処理など外部に影響する関数を、原因不明のまま手動で何度も実行しない。現在の対象行、公式送信先の状態、実行履歴を照合し、未完と確認した範囲だけ再開する。パスワードやトークンをシートや公開ログに貼らない。
無料の手順で作成者・履歴・処理結果を確かめたあと、GASの仕組みをまとめて復習したい人向けです。引継ぎや復旧の判断は、組織の管理手順とGoogleの現行資料で確認してください。
Amazon｜紙の本
詳解！ Google Apps Script完全入門［第3版］
ISBN 9784798064741
商品画像は掲載していません。版・在庫・販売者・配送条件は商品ページで確認してください。
楽天ブックス｜紙の本
詳解！ Google Apps Script完全入門［第3版］
ISBN 9784798064741
楽天ブックスの公式商品画像付きリンク（書籍の表紙）
同じISBNの紙の本を2社で確認できます。価格・在庫・販売者・配送条件は各商品ページで確かめてください。ここでは金額や最安を比較しません。
「毎朝動く」を、確認できる運用に変える
自動化の目的は、人が毎日ボタンを押さないことだ。ただし「設定済み」だけで「完了」とは言えない。運用表には、処理の責任者、実行予定の時間帯、トリガー作成者、対象関数、成功時に残る結果、失敗時の確認先を短く記す。毎朝ダッシュボードを眺め続ける必要はないが、結果がなかったときにどこを見るかを決める。シートの更新時刻だけでなく、外部投稿なら公式URLも確認できる形にする。
実行履歴は「関数が走った」証拠、公開URLは「読者が見られる」証拠。両者の間には認証、アップロード、相手側の受付、表示などいくつもの段階がある。記事の公開であれば、APIの応答が成功しても、投稿先アカウントや本文・画像が意図通りかを公式画面で確認する。失敗した媒体があっても、成功した媒体を再送しない。対象と再開位置を記録して、次の定時実行へ渡す。
引継ぎ資料にはコード全文より先に、入口と出口の地図が役立つ。「この時間主導トリガーがこの関数を起こし、この行を読み、このサービスへ送る。最後はこの公式画面で確かめる」という一文だ。その地図があれば、担当者が替わっても次の一手が分かる。逆に関数名だけのリストでは、止まったときに何を守るべきか判断しにくい。
個人で副業やメディアを運営している場合も同じだ。Googleアカウントを一つしか使わないから関係ない、とは限らない。権限の再認証、ファイルの移動、APIの仕様変更、実行枠などで処理が止まることはある。毎日の完全な無人化を保証するより、止まった場所が分かり、同じ仕事を二度送らずに再開できることを目標にする。これなら外出中でも状況を説明できる。
最初に手を付けるなら、既存のトリガー一覧と直近の実行履歴を見比べる。稼働していない関数はあるか。前担当の名義のままの入口はあるか。失敗通知は誰に届くか。対象のシートと送信先を読み取り、処理が必要な場合だけ正規の権限で変更する。これが担当交代の「いつの間にか止まった」を減らす、地味だが効く確認だ。
よくある質問（Q&A）
シートの編集者になれば、前担当のトリガーも自分の権限で動きますか？
原則として動かない。インストール型トリガーは作成したアカウントの権限で動く。シート編集権限とトリガーの実行主体を別に確認し、変更が必要なら旧入口の状態を確かめてから新しい権限で設定する。
今朝の更新がない場合、すぐ手動実行してよいですか？
まず実行履歴と出力先を確認する。予定時間帯の遅れ、実行中、失敗、送信成功だが表示未反映などを分ける。外部への送信が不明なまま再実行すると重複する可能性があるため、未完と確認した範囲だけ再開する。
仕様の確認日は2026年9月25日。Apps Scriptの画面や利用枠は変更され得るため、操作時は上記のGoogle公式資料と現行画面を確認してください。
自動化の説明を聞くと、スイッチ一つで全部片付くように見えます。でも現場で大切なのは、誰が責任を持ち、何が終わり、どこから直せるかが分かること。便利な仕組みほど、止まった朝の手順を先に作っておきたい。仕事と暮らしの間で考えたことは『親父の奮闘記』にも書いています。
コメント