AIものさし

Apps Scriptのインストール型トリガーが別ユーザー権限で動かないとき、作成者と認可を確認する

インストール型トリガーが同じスプレッドシートを編集する別ユーザーの操作で失敗しても、その人の権限で処理が動くとは限りません。トリガーは、イベントを起こした人ではなく、トリガーを作成したGoogleアカウントの認可で実行されます。

AIものさし編集部

インストール型トリガーが同じスプレッドシートを編集する別ユーザーの操作で失敗しても、その人の権限で処理が動くとは限りません。トリガーは、イベントを起こした人ではなく、トリガーを作成したGoogleアカウントの認可で実行されます。まず「誰が作成したか」「その人が必要な認可を済ませているか」「その人が対象ファイルやサービスへアクセスできるか」を別々に確認してください。

共有ファイルを編集できることと、トリガー経由でDriveやGmailなどのサービスを使えることは別です。原因を切り分けずに、失敗した利用者へ追加権限を付けても解決しないことがあります。

目次

最初に分ける3つの主体

トリガーの障害では、次の三者を混同しないことが重要です。

表は横にスクロールできます

確認する対象何を表すか確認すること
イベントを起こした人シートを編集・送信したユーザーその操作がトリガーの対象イベントか。閲覧専用でファイルを開いただけでは、編集トリガーは発火しない
トリガー作成者インストール型トリガーを登録したアカウントそのアカウントのトリガー設定、実行履歴、認可状態
対象リソースの所有者・共有先スプレッドシート、Driveファイル、Gmail等トリガー作成者が必要なファイルやサービスを使えるか

トリガーが別ユーザーの操作をきっかけに動く場合でも、処理主体はトリガー作成者です。たとえば、Aさんがインストール型編集トリガーを登録し、Bさんが編集した場合、トリガー内の処理はAさんの認可で実行されます。Bさんに対象シートの編集権限があることだけでは、Aさんの認可不足やファイルアクセス不足は補えません。

誰がトリガーを作成したか確認する

  1. Apps Scriptプロジェクトを開き、左側の「トリガー」を確認します。

  2. ただし、インストール型トリガーの一覧はアカウントごとに管理されます。別アカウントが作成したトリガーは、自分の一覧に表示されない場合があります。

  3. 作成者候補ごとに、そのアカウントでApps Scriptの「マイトリガー」を開き、対象プロジェクト・関数・イベント種別を照合します。

  4. Apps Scriptダッシュボードの実行履歴またはプロジェクトの「実行数」から、失敗時刻、関数名、状態、エラーを確認します。対象期間を絞り、該当イベントの時刻と一致する実行を見ます。

  5. 失敗通知メールが届いている場合は、メール内のプロジェクトリンクとエラー概要も照合します。

「マイトリガー」やプロジェクトの実行履歴を確認できない場合、権限のないアカウントのトリガー設定を別の人が見られるとは限りません。プロジェクトを共有されている編集者でも、別ユーザーが作成したトリガーが自分の一覧に見えないことがあります。作成者本人または管理された運用担当者に確認を依頼し、見えないことを「トリガーが存在しない」と解釈しないでください。

エラーの種類から原因を分ける

実行履歴のエラー文を最初に確認し、次の順に切り分けます。

表は横にスクロールできます

症状・エラーまず確認すること次の対応
Authorization is required to perform that actionトリガー作成者が必要scopeを承認済みか。最近コードへ新しいサービスを追加したか作成者がスクリプトエディタから必要な関数を手動実行し、認可画面が表示されたら要求scopeを確認して承認する
File not found / You do not have permissionトリガー作成者が対象Spreadsheet、Driveファイル、フォルダへアクセスできるか。IDが正しいか対象IDと共有設定を確認。編集者本人のアクセスではなく、作成者のアクセスを確認する
Service invoked too many times / quota実行主体、実行時刻、サービス別の利用量認可エラーと混同せず、公式の現行割当・上限と実行量を確認する。再試行を増やして重複処理を起こさない
関数が呼ばれないトリガー種別、イベント条件、対象ファイル、実行履歴トリガーが意図するイベントに対応しているか、イベントが実際に発生したかを確認する
通知だけ届き、画面にエラーが出ないトリガーがバックグラウンド実行かApps Scriptの実行履歴・失敗通知の詳細を確認する。画面上に同期エラーが出ないことは成功の証拠ではない

認可の問題とファイル共有の問題は別です。スクリプトの必要scopeが承認済みでも、作成者が対象の共有ファイルを開けなければ処理は失敗します。逆に、作成者が対象ファイルを開けても、DriveやGmail等の新しいscopeをまだ承認していなければ、そのサービスを使う処理は止まります。

認可scopeが不足している場合

Apps Scriptはコードから必要なGoogleサービスを判定し、必要なOAuth scopeを求めます。コードにDriveやGmailなどのサービス利用を追加した場合、以前に認可したプロジェクトでも追加の認可が必要になることがあります。

インストール型トリガーは利用者の操作なしにバックグラウンドで実行されます。そのため、実行中に不足scopeの認可画面を出して、利用者に承認させることはできません。不足した権限をトリガーが自動で取り直すこともありません。Googleの案内では、新しい権限が必要になった場合、作成者がスクリプトエディタで関数を手動実行し、認可を完了する手順が示されています。

安全な再認可手順は次のとおりです。

  1. 失敗した実行の関数名とエラーを記録する。個人情報やトークンをログへ貼らない。

  2. トリガー作成者本人が対象プロジェクトを開く。

  3. 変更されたコードが要求するscopeと、処理に必要なサービスを確認する。不要なscopeが含まれる場合は、承認する前にコードやマニフェストを見直す。

  4. トリガーが呼び出す関数、または必要scopeを通る安全なセットアップ関数を、作成者がエディタから手動実行する。

  5. Googleの認可画面に表示されるアプリ名・要求権限を確認し、業務上必要な範囲のみ承認する。

  6. 実行履歴で手動実行が成功したことを確認し、その後に少量の安全なテストイベントでトリガー実行を確かめる。

  7. テスト後、重複メール・重複更新・外部送信が起きていないことを確認する。

関数の手動実行が副作用を起こす設計なら、本番データに対して直接実行しないでください。まずテスト用コピーや副作用のない認可確認用関数を使えるか、実装担当者と確かめます。利用者に不要な広範囲のGoogleアカウント権限を追加することは、認可エラーの一般的な解決策ではありません。

対象ファイルへのアクセスを確認する

共有スプレッドシートを編集できる利用者がいても、トリガー作成者が関連ファイルすべてにアクセスできるとは限りません。特に、コードが固定IDで別のスプレッドシートやDriveファイルを開く場合、起点のシートと処理先のファイルを分けて確認します。

表は横にスクロールできます

資源確認ポイント
トリガーが紐づくファイル作成者がそのファイルへアクセスできるか。トリガーが編集・送信等の対象イベントに適した種類か
コードが開く別SpreadsheetファイルID、作成者の閲覧・編集権限、対象シート名が一致するか
Driveのファイル・フォルダ作成者が読み書きする操作に必要なアクセス権を持つか。共有ドライブの組織ポリシーも確認する
Gmail等のサービス必要scopeが認可済みか、作成者のアカウントで対象操作が許可されているか
外部APIGoogle OAuthとは別の認証情報やAPI制限の問題ではないか。秘密値を実行ログへ出さない

失敗した処理がopenByIdなどで別ファイルを開いているなら、そのIDが誤っていないことを確認します。次に作成者アカウントで対象ファイルを開けるかを確認し、その後、コードが行う操作に必要な権限があるかを見ます。「エディタを共有したから参照先も使える」とは限らないため、参照先を一つずつ確認します。

担当者が変わるときの安全な引き継ぎ

インストール型トリガーには、既存トリガーの所有者を別アカウントへ移す一般的な引き継ぎ方法がある、と決めつけないでください。Googleの公開ドキュメントは、トリガーが作成者の認可で実行されることと、アカウントごとにトリガー管理が分かれることを説明しています。退職・異動・アカウント停止の後も既存トリガーがどのように継続するかは、組織設定やアカウント状態を含む個別条件を確認せずに保証できません。

引き継ぎが必要なら、新担当者が自分のアカウントで運用できるかを管理者・スクリプト管理者と確認し、次の手順で再作成を計画します。

  1. 現在のトリガー種別、関数、イベント条件、対象ファイル、実行頻度を記録する。

  2. 新担当者がプロジェクトと対象リソースへ必要最小限のアクセスを持つか確認する。

  3. 新担当者が必要scopeを確認し、自分のアカウントで認可したうえで、新しいトリガーを作成する。

  4. 重複実行によるメール送信・データ更新・外部API呼び出しを防ぐ。移行期間に二重トリガーが走るなら、冪等性や停止時刻を先に決める。

  5. テストイベントで実行主体・結果・副作用を確認する。

  6. 新しいトリガーが正常と確認できた後、旧作成者のトリガーを旧作成者のアカウントで停止または削除する。

  7. 監査記録に変更者、時刻、対象プロジェクト、ロールバック手順を残す。

トリガーの削除や切替は、処理停止や二重実行につながる運用変更です。作成者と運用責任者を確認し、停止時間・再実行時の重複対策を決めてから作業します。どのアカウントで既存トリガーを管理できるか不明な場合は、管理者と作成者に確認するまで既存トリガーを削除しないでください。

退職・アカウント停止時の注意

退職者のアカウント停止・削除後にトリガーが必ず動き続ける、または必ず止まると一般化しないでください。ここで参照した公式資料は、トリガー実行者が作成者であることを示しますが、組織のアカウント停止後の個別挙動を一律に保証するものではありません。組織のGoogle Workspace管理者が、アカウント停止・削除・データ移管の各条件を確認してください。

そのうえで、個人アカウントに依存する定期処理や業務処理は、担当者の変更前に管理された運用主体へ移す計画を作ります。サービスアカウントが使えると決めつけず、Apps Scriptの実行形態・組織ポリシー・対象サービスの条件を確認してください。実行主体を変えると認可scopeやファイル共有も変わるため、単にトリガーを新規作成すれば同じ結果になるとは限りません。

5分で進める切り分けチェックリスト

  • 失敗した時刻、関数、トリガー種別、エラー全文を実行履歴から確認した。

  • そのトリガーを作成したGoogleアカウントを確認した。

  • イベントを起こした人の権限と、トリガー作成者の権限を分けた。

  • 作成者本人の「マイトリガー」に該当設定があるか確認した。

  • コードが使う各Spreadsheet・Driveファイル・Gmail等について、作成者のアクセスを確認した。

  • 最近追加・変更したサービスscopeがないか確認した。

  • 認可不足なら、作成者が安全な関数をエディタから実行して再認可した。

  • quota、外部API認証、ファイルID間違いをOAuth認可不足と混同していない。

  • 再テストは副作用を管理できるデータで行い、実行履歴と重複処理を確認した。

最後まで確認しても作成者が特定できない場合、または作成者アカウントへアクセスできない場合は、権限を広く配る前に管理者へエスカレーションします。トリガー一覧が見えない別ユーザーへ追加権限を付けても、作成者の認可を復旧できるとは限りません。

次の担当者へ引き継ぐ記録

障害を再発させないため、次の項目を運用台帳へ残します。ユーザーのOAuthトークンや認証情報は記録しません。

  • Apps ScriptプロジェクトのURLと管理責任者

  • トリガーを管理するアカウントまたは担当ロール

  • 関数名、トリガー種別、イベント条件、対象ファイル

  • 必要なOAuth scopeと、その確認・承認日

  • 参照するSpreadsheet IDやDrive資源、および必要な最小アクセス権

  • 実行履歴の確認手順と障害通知の受信先

  • 担当交代時の新規トリガー作成、重複防止、旧トリガー停止の順序

  • テスト方法、期待結果、失敗時の切り戻し方法

認可の記録は「誰がいつ、どのscopeを承認したか」を必要な範囲で管理し、秘密のトークンそのものは保存しません。業務で個人アカウントへ依存している場合は、管理者と運用主体の見直しを行い、変更の影響をテストしてから切り替えます。

判断のまとめ

まず実行履歴からエラーを取り、トリガー作成者を特定します。Authorization is requiredなら作成者の認可scope、permission deniedやfile not foundなら作成者の対象リソースアクセス、quotaエラーならサービス別の利用量を確認します。作成者の認可が必要な場合、イベントを起こした別ユーザーではなく作成者本人が再認可します。

担当交代では既存トリガーの所有権が移せると仮定せず、新担当者の認可・対象資源アクセス・重複処理対策を整え、新規トリガーを検証してから旧トリガーを止めます。アカウント停止後の挙動は個別に確認し、公式保証のように書かないことが大切です。

Sources

確認日：2026-10-15。公式資料は現行の作成者・認可・scope・実行履歴の条件確認に使用しました。記事内の手順は公式条件から導いた運用上の診断案で、実際のApps Script環境での実測を主張しません。