# GAS Webアプリの「原因不明の失敗」切り分けチェックリスト Google Apps Script（GAS）のHtmlService Webアプリで「エディタで手動実行すると成功するのに、アプリ経由(`google.script.run`)だと失敗する」という現象に繰り返し遭遇したときの、費用対効果の高い切り分け順序。 ## 症状パターン - `google.script.run`の`withSuccessHandler`に`res = null`が渡ってくる - エラーメッセージにコロン以降の詳細（`err.message`）が付かず、内容が空に見える - Apps Scriptエディタの「実行数」を見ても、Webアプリ経由の呼び出しに該当する実行記録が見当たらない - 同じ操作をApps Scriptエディタから手動で実行すると、一瞬で正常完了する ## やりがちな遠回り 処理が重い/遅いと決めつけて、いきなりサーバー側の最適化（キャッシュ導入、ループの高速化、タイムアウト対策）に着手してしまう。実際にそれが原因のこともあるが、**着手前に1分でできる切り分けを飛ばすと大きく遠回りになる**。 ## 正しい切り分け順序 1. **デプロイバージョンの確認**（1分） `clasp deployments` で、実際に配信されているデプロイの`@番号`が、直近の`clasp push`後に作られた最新バージョンと一致しているか確認する。古いバージョンのままだと、ソース上は直しても本番には反映されていない。 2. **別端末で同じ操作を試す**（1分・最優先） iPad/PCで失敗していたら、**スマホ（別ブラウザ/別デバイス）で全く同じ操作を試す**。別端末で正常に動けば、サーバー側のロジックは無罪だと即座に確定できる。この1ステップで「処理が重い」という思い込みを排除できる。 3. 別端末で成功したら → 失敗している端末のブラウザキャッシュを疑う - Safari: 設定→Safari→「履歴とWebサイトデータを消去」、またはタブを完全に閉じて再度開き直す - Chrome/Edge: ハードリロード（Cmd/Ctrl+Shift+R）→ 直らなければサイトデータ削除 → シークレットウィンドウで再試行 - シークレットウィンドウで直れば「拡張機能かキャッシュ」、シークレットでも同じなら次のステップへ 4. 別端末でも同じ失敗が再現する場合のみ → サーバー側を疑う - 手動実行で成功するのにWebアプリ経由だけ失敗するなら、**実行アカウントの違い**（Webアプリは`executeAs`で指定した固定アカウントで動くが、エディタでの手動実行は今ログインしている自分のアカウントで動く）による権限差を最優先で疑う。関係するスプレッドシート/フォルダが、Webアプリの実行アカウントに共有されているか確認する。 - 一時的に`alert(JSON.stringify(res))`や`alert(err.message)`を差し込んで、圧縮された画面表示では見えない詳細を強制的に見えるようにする。原因特定後は必ず削除する。 ## 既存コードの「握りつぶし」を疑う 新機能を追加したときだけ問題が表面化した場合、**その新機能だけがエラーをそのままユーザーに見せる作りで、既存の類似コードはtry/catchで例外を握りつぶして`{}`や空配列を返していた**、というケースがある。同じスプレッドシート/フォルダにアクセスする既存関数を横断的に確認し、同じ握りつぶしパターンが無いか点検する。 ```js // 悪い例: 失敗が完全に見えなくなる function getSomething() { try { // ... return result; } catch(e) { Logger.log(e.message); // ログにしか残らない return {}; // 呼び出し元は「データが無い」と区別できない } } ``` 失敗を握りつぶすこと自体が悪ではないが（呼び出し頻度が高く軽微な失敗を許容したい場合は妥当）、**同じ原因が別の新機能で致命的な形で露出したときに「なぜ今まで気づかなかったのか」を素早く説明できるよう、握りつぶし箇所は把握しておく**。 ## 適用範囲 Google Apps Script（HtmlService Webアプリ、`executeAs: USER_DEPLOYING`構成）全般。`google.script.run`を使う実装であれば業務内容を問わず有効。 ---