GAS 実行ログが出ない｜3系統の切り分けと再発防止

結論：ログが出ない原因は3系統しかない

GASで実行ログが出ないとき、原因は「そもそも実行されていない」「実行はされたがログが書かれていない」「ログはあるが見ている画面が違う」の3系統に必ず収まります。切り分けの起点は必ず実行数（Executions）画面で、この画面は公式ドキュメントが「自分がオーナー・編集者・閲覧者であるプロジェクトの、過去および実行中のすべての実行のログを表示する」と定義しているため、他人が作ったトリガーの実行は最初から一覧に載りません。

もう一点、時間の壁があります。エディタ下部の実行ログは公式に「軽量でリアルタイムに流れるが、保持されるのは短時間だけ」と書かれており、翌朝に開いても昨夜のログはもう残っていません。一方でCloud Loggingは「作成後、何日も保持される」とされ、実体は Cloud Logging の _Default バケットの既定保持期間30日（1〜3650日で変更可）です。Cloud Logging の割り当てと制限に明記されています。

つまり「ログが出ない」の多くは、ログ機能の不具合ではなく保持期間と権限の設計ミスです。以下では3系統の確定手順を示したうえで、同じ事故を二度起こさないための仕組みまで踏み込みます。

最初の切り分け表：3系統をどう確定するか

実務では、いきなりコードを読み始めると時間を溶かします。先に「どの系統か」を確定させてください。判定材料は実行数画面に行が出るか、行のステータスがどうなっているか、の2点だけです。

この表で①に落ちた場合だけがコードの問題ではありません。実務で一番多いのは①で、しかも原因はコードの外側にあります。

系統①：そもそも実行されていない

トリガーは作った人のアカウントで動く

インストール型トリガーについて公式は「常に、それを作成した人のアカウントで実行される」と明記しています。さらに厳しいのは可視性のほうで、インストール型トリガーのドキュメントには「あるアカウントは、別のアカウントからインストールされたトリガーを見ることができない。ただし、最初のアカウントはそのトリガーを起動させることはできる」と書かれています。

これが「ログが出ない」の最頻出パターンです。退職した担当者や、別の共有アカウントが作ったトリガーは、あなたのエディタのトリガー一覧にも実行数画面にも出てきません。動いているのに見えない、あるいは止まっているのに気づけない状態が、ここで生まれます。対処は1つで、トリガーを自分のアカウントで作り直すことです。

トリガーの合計実行時間を使い切っている

Googleサービスの割り当てによると、トリガーの合計実行時間は無料のGoogleアカウントで90分／日、Google Workspaceアカウントで6時間／日です。1実行あたりの上限は両者とも6分、同時実行数は30／ユーザーです。日次の合計を使い切ると、その日はそれ以降のトリガーが動かず、実行数画面には行そのものが出ません。

現場で多いのは「5分おきトリガー×重い処理」の組み合わせです。1回3分かかる処理を5分おきに回すと、無料アカウントなら1日の枠は1時間半で尽きます。実行時間そのものの削り方はGASの実行時間超過エラーの原因と対処で扱っています。

承認が切れている／未承認のサービスを触っている

公式のトラブルシューティングは「スクリプトがバックグラウンド（インストール型トリガーなど）で実行され、ユーザーが承認していないサービスを使おうとすると、即座に失敗する」と述べています。また「承認前、または承認の期限切れ後に発火するトリガーが、このエラーの原因になることが多い」とも書かれています。

この失敗は、Apps Scriptが失敗サマリーのメールを送ります。ただし宛先はトリガーを作ったアカウントなので、共有アカウント宛に飛んで誰も読んでいない、というのが実務でよくある姿です。承認そのもので詰まっているときはGASのスクリプトを承認できない原因と対処を、トリガー側の切り分けはGASのトリガーが動かない原因6系統を先に読んでください。

系統②：実行はされたがログが書かれていない

LoggerとconsoleはRhinoで挙動が変わる

公式のログ記録のドキュメントは、「組み込みの実行ログでは Logger と console のどちらのログサービスも使える」と書いたうえで、明確な例外を置いています。「Rhinoランタイムを使っている場合、Cloud LoggingはApps Scriptの Logger サービスをサポートしない。代わりに console サービスを使うこと」。

つまり古いスクリプトを引き継いだ場合、Logger.log だけで書かれたログはCloud Loggingに残りません。実行直後にエディタで見れば出ますが、翌朝には何も残っていない、という見え方になります。ランタイムは appsscript.json の runtimeVersion で決まり、値は V8 が V8、旧ランタイムが DEPRECATED_ES5 です（V8ランタイムの移行ガイド）。

後から追える形にしたいなら、開発中の確認は Logger.log、本番の記録は console.log と使い分けるのが実務的です。公式も実行ログを「開発とデバッグ中の確認を意図したもので、あまり長くは保持されない」と位置づけています。

ログの手前で抜けている

行はあるのにログが空、という場合は、ほぼ早期returnです。次のように関数の入口と出口を無条件で記録すると、どこまで進んだのかが一目で分かります。

• function syncSheet() {
•   console.log('start');
•   const rows = SpreadsheetApp.getActive().getSheetByName('data').getDataRange().getValues();
•   console.log('rows=%s', rows.length);
•   if (rows.length <= 1) { console.log('skip: no data'); return; }
•   console.log('done');
• }

ポイントは「スキップした理由もログに書く」ことです。return の直前に理由を1行置くだけで、「動いたが何もしなかった」と「動かなかった」が区別できるようになります。

系統③：ログはあるが見ている画面が違う

既定プロジェクトのままではCloudコンソールで見られない

Apps Scriptのプロジェクトには既定（default）のCloudプロジェクトと標準（standard）のCloudプロジェクトがあり、Cloudプロジェクトのドキュメントは「Google CloudコンソールでスクリプトプロジェクトのGoogle Cloudログを表示するには、スクリプトが標準プロジェクトを使っていなければならない」と述べています。Error Reportingも同じで、標準プロジェクトに切り替えると「実行時エラーがGoogle Cloud Error Reportingに自動的に記録される」ようになります。

既定プロジェクトのままでも、Apps Scriptダッシュボードには「Cloudログの簡易版」が表示されます。ここが混乱の元で、「Cloudコンソールに出ないからログが取れていない」と誤解されがちですが、実際にはダッシュボード側に出ています。逆に、細かいフィルタや長期の追跡が必要になった時点で標準プロジェクトへの切り替えが必要になります。

実行数画面のフィルタと表示範囲

実行数画面には実行種別のフィルタがあり、Add On / Execution API / Time Driven / Trigger / Webapp / Editor から選べます。時間主導型トリガーを探しているのに Editor だけが表示される設定になっていれば、当然何も見えません。

もう1つ知っておきたい仕様があります。公式は「実行リストには、実行を開始した最初の関数だけが表示される。その実行中に呼ばれたすべての関数は表示されない」と明記しています。ライブラリや内部関数の名前で探しても見つからないのは、この仕様どおりの挙動です。

実務の落とし穴

Workspaceアカウントと個人アカウントの混在

ブラウザに複数のGoogleアカウントでログインしていると、スクリプトは会社のWorkspaceアカウントで作られているのに、実行数画面を開いているのは個人アカウント、という状態が起きます。前述のとおり実行数画面は「自分がオーナー・編集者・閲覧者であるプロジェクト」しか出さないため、この場合は1件も表示されません。URLの /u/0/ /u/1/ を見て、どの口で開いているかを先に確定させてください。

共有ドライブ配下のスクリプト

共有ドライブのファイルに紐づくスクリプトは、ファイルの権限とスクリプトプロジェクトの権限が別物です。ファイルは見えるのにスクリプトプロジェクトの閲覧者でない、という状態だと実行ログにも到達できません。共有ドライブで運用するなら、スクリプトプロジェクトの権限を担当者全員に明示的に付けておくのが安全です。

ログを出しすぎると逆に追えなくなる

ループの中で毎行ログを出すと、探したい1行が数千行に埋まります。Cloud Logging側には「LogEntry のサイズは 256 KiB。この上限は引き上げられない」という制限もあるため、巨大なオブジェクトをそのまま流すのは避けてください。出すのは「処理件数」「スキップ理由」「例外の内容」の3つに絞り、明細は必要なときだけ一時的に有効化するのが現実的です。

ログに個人情報を書かない

公式も「ログを記録する際は、メールアドレスなどユーザーの個人情報を記録しないのが良いプライバシー慣行」と注意しています。ユーザーの識別が必要なら Session.getTemporaryActiveUserKey で得られる一時キーを使えば、身元を明かさずにCloudログ上で一意のユーザーを見分けられます。

本題：黙って止まる自動化を、次は気づける形にする

ログの出し方を覚えても、「ログを見に行こうと思う」きっかけがなければ事故は繰り返します。自動化が止まったことに気づくのは、たいてい月末に数字が合わなかったときです。差を埋めるのは、ログではなく通知と記録の置き場所です。

正常時も1行残す

エラーだけを通知する設計は、実行そのものが起きなかった場合を検知できません。トリガーの枠切れ・承認切れ・トリガー消失は、すべて「エラーが出ない停止」です。処理の最後にスプレッドシートへ日時・処理件数・所要秒数を1行追記しておけば、行が増えていないことが停止のサインになります。ログと違い、この記録には保持期間がありません。

例外はその場で人が読む場所へ送る

try/catch で例外を捕まえ、要約をメールやチャットへ送ります。宛先は共有アカウントではなく、実際に読む個人にしてください。トリガー失敗時にGoogleが送るサマリーメールは、トリガーを作ったアカウントに届く仕様なので、それだけを頼りにしないことが重要です。GASでスプレッドシートからメールを自動送信する手順の要領で、通知側も重複を防ぐ作りにしておきます。

誰の口で動いているかを台帳にする

トリガーは作成者のアカウントで動き、他のアカウントからは見えません。ならば、スクリプト名・トリガー種別・作成アカウント・通知先を1枚の表にしておく以外に、引き継ぎ時の事故を防ぐ手はありません。担当者が変わるたびにこの表を見て、トリガーを新しい担当者のアカウントで作り直します。地味ですが、これが最も効きます。

保持期間を業務の周期に合わせる

月次で締める業務なら、既定30日の保持では月初の確認時にぎりぎりです。標準Cloudプロジェクトに切り替えたうえで、_Default バケットの保持期間を業務の周期より長く設定しておくと、後追いの調査ができます。設定可能な範囲は1日から3650日です。