GASの動きを見える化して原因を切り分ける
GASを書いていて一番つまずきやすいのは、「なぜこの結果になるのか分からない」という状態です。
特にスプレッドシート操作や条件分岐が絡むと、頭の中の想定と実際の動作がズレやすくなります。
このズレを埋めるために使うのが Logger.log です。
Logger.logは、処理の途中で値や状況をログとして出力し、あとから確認できる仕組みです。
この記事では、Logger.logの基本から、実務で役立つログの出し方、よくある失敗パターンまでを整理します。
「どこで」「何が」想定と違うのかを、ログで切り分けられるようになりましょう。
目次
Logger.logとは何か
Logger.logは、GASの実行中に情報を出力するための標準機能です。
出力したログは、実行後にエディタ上で確認できます。
ログを使うメリットは、処理の途中経過を「証拠」として残せることです。
変数の値、分岐に入ったかどうか、ループの回数など、動作の実態を確認できます。
画面に表示されない処理（例：スプレッドシートの裏側で動く処理）ほど、ログがないと原因特定が難しくなります。
「動かない」「結果が違う」と感じたら、まずログを仕込むのが基本です。
ログの確認方法と基本の書き方
Logger.logの書き方はシンプルです。
確認したい値やメッセージを渡すだけでログに残せます。
function logBasic() {
Logger.log('処理を開始します');
const x = 10;
Logger.log(x);
Logger.log('処理を終了します');
}
10
処理を終了します
ログは、GASエディタの実行結果画面から確認できます。
実務では「どこまで処理が進んだか」を追う目的で、開始・終了ログを入れるだけでも効果があります。
また、ログは「何を確認したいか」を明確にするほど価値が上がります。
単に値を出すのではなく、「この値は何か」が分かるメッセージを添えるのがコツです。
function logWithLabel() {
const sheetName = 'Sheet1';
Logger.log('sheetName=' + sheetName);
}
値の型と中身を安全に確認する
GASのデバッグでよく起きるのが、「思っていた型と違う」という問題です。
例えば、数値だと思っていたら文字列だった、配列だと思ったらnullだった、などです。
この手の問題は、ログで型と中身を一緒に確認すると早く解決します。
function logType() {
const a = '10';
const b = 10;
Logger.log('a=' + a + ', type=' + typeof a);
Logger.log('b=' + b + ', type=' + typeof b);
}
b=10, type=number
配列やオブジェクトの中身を確認したい場合は、文字列化して出力すると見やすくなります。
GASではJSON.stringifyを使うのが基本です。
function logObject() {
const user = { name: 'taro', age: 20 };
Logger.log(JSON.stringify(user));
}
ただし、巨大なデータを文字列化するとログが読みにくくなることがあります。
その場合は、キーを絞って出す、件数だけ出す、といった工夫が有効です。
ループと条件分岐でのログ活用
GASの実務で多いのは、「ループして条件に合うものだけ処理する」パターンです。
ここはバグが混ざりやすいので、ログで流れを追えるようにしておくと強いです。
例えば、配列を走査して正の数だけログに出す処理は次のようになります。
function logLoopAndIf() {
const numbers = [3, -1, 0, 5];
for (let i = 0; i < numbers.length; i++) {
Logger.log('i=' + i + ', value=' + numbers[i]);
if (numbers[i] > 0) {
Logger.log('positive=' + numbers[i]);
}
}
}
positive=3
i=1, value=-1
i=2, value=0
i=3, value=5
positive=5
ここでのポイントは、ループの各回で「今どこを処理しているか」を出している点です。
値が想定と違う場合、何番目の要素でズレたのかが即座に分かります。
条件分岐の中に入ったかどうかが分からない場合も、ログで「入った証拠」を出すと切り分けが簡単になります。
実務で使えるログ設計のコツ
Logger.logは便利ですが、やみくもに出すと逆に読めなくなります。
実務では「短時間で原因を特定する」ために、ログの出し方にコツがあります。
おすすめは、次の3点です。
- 開始・終了を必ず出す（どこまで進んだか分かる）
- 境界を出す（分岐に入った、例外に入った、ループの何回目など）
- 識別子を出す（行番号、ID、キーなど。後で追跡できる）
例えば、スプレッドシートの行処理なら「row=何行目」をログに混ぜるだけで効果が大きいです。
データが多いほど、識別子の有無でデバッグ難易度が変わります。
また、ログは「確認が終わったら減らす」意識も大切です。
本番運用では必要最低限のログにしておくと、読みやすさと保守性が上がります。
よくある失敗と対処
最後に、Logger.logでありがちな失敗パターンを整理します。
注意：ログが出ない場合は、そもそも関数が実行されていない可能性があります。関数選択と実行ボタンを見直してください。
次に多いのが、「エラーで止まってログまで到達していない」ケースです。
この場合は、ログをもっと手前に置いて、どこまで進んだかを確認します。
また、オブジェクトや配列のログが読みにくい場合は、JSON.stringifyで整形するのが基本です。
ただし、データ量が大きいとログが埋もれるので、件数や一部の要素だけ出すのが実務的です。
Logger.logは「魔法」ではありませんが、正しく使えば原因切り分けの速度が大幅に上がります。
次回の「よくあるエラー」記事でも、ログが前提として活躍します。
まとめ
この記事では、GASのデバッグに必須のLogger.logについて、基本から実務での使い方まで整理しました。
値・型・処理の流れをログで見える化できるようになると、GASの開発効率は一気に上がります。
次回は、GASでよくあるエラーをまとめて整理します。
ログとあわせて原因の当たりを付けられるようになると、トラブル対応が楽になります。
参考リンク
0 件のコメント:
コメントを投稿