スプレッドシートに仕込んだGASが突然動かなくなって、途方に暮れた経験はありませんか？昨日まで問題なく動いていたスクリプトが、今日になって急に反応しなくなる。エラーメッセージすら表示されず、何が原因かもわからない。そんな状況に陥ると、本当に困りますよね。
この記事では、スプレッドシートでGASが動かない原因を徹底的に分析し、初心者から上級者まで実践できる解決策を網羅的にご紹介します。2026年1月31日に廃止されたRhinoランタイムの影響から、権限設定の罠、トリガーの落とし穴まで、あらゆるケースに対応できるようになります。
- GASが動かない主要な原因10パターンとその具体的な解決手順
- 2026年のRhinoランタイム廃止による影響とV8移行の完全ガイド
- デバッグとログ確認の実践的テクニックでトラブルを自力解決する方法
- GASが動かなくなる主な原因を理解しよう
- 2026年のRhinoランタイム廃止とV8移行について
- コードに起因するエラーの対処法
- ブラウザやシステム環境に関する問題
- デバッグとログ確認の実践テクニック
- Webアプリとして公開している場合の注意点
- Googleのサービス終了とAPI変更への対応
- 情シス経験者が教える現場で本当に起きるGASトラブルの真実
- 現場で使える実践的なGASコード集
- 誰も教えてくれない「あるある」トラブル解決法
- 運用を楽にする情シス流の管理術
- 本当によくある質問と本音の回答
- ぶっちゃけこうした方がいい！
- スプレッドシートでGASが動かないことに関する疑問解決
- 今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？
- まとめ
GASが動かなくなる主な原因を理解しよう
Googleスプレッドシートのイメージ
GASが動作しない原因は実に多岐にわたります。単純なコードミスから、Googleのシステム変更による影響まで、様々な要因が絡み合っています。まずは、よくある原因を体系的に整理していきましょう。
権限承認が完了していない
GASを初めて実行する際、もしくはスクリプトに新しい機能を追加した際には、アクセス権限の承認が必要になります。これはGASがスプレッドシートやGmail、Googleドライブなどの各種サービスにアクセスするために不可欠なプロセスです。
「承認が必要です このプロジェクトがあなたのデータへのアクセス権限を必要としています。」というメッセージが表示されたら、慌てずに「権限を確認」ボタンをクリックしましょう。続いてアカウントを選択し、「詳細」をクリックしてから「プロジェクト名（安全ではないページ）」をクリックすれば、承認画面に進めます。
ここで注意すべきなのは、無料のGmailアカウントを使用している場合、「このアプリは確認されていません」という警告が表示されることです。自分で作成したスクリプトであれば、「詳細」から「安全ではないページに移動」をクリックして進んで問題ありません。ただし、他人が作成した内容不明のスクリプトについては、セキュリティ上の観点から慎重に判断してください。
トリガー設定の誤り
トリガーが正しく機能しないケースは非常に多く見られます。よくある設定ミスとして、スプレッドシートの更新をトリガーに設定したつもりが、実際には時間ベースのトリガーを設定してしまっていたというパターンがあります。
トリガー設定を確認する際は、以下の点をチェックしましょう。まず、イベントの種類が意図したものになっているかを確認します。「スプレッドシートから」「時間主導型」「カレンダーから」など、ソースが正しく設定されているかがポイントです。次に、実行する関数名が正しく紐づけられているかを確認してください。複数の関数をスクリプトに記述している場合、意図しない関数がトリガーに設定されていることがあります。
時間ベースのトリガーについては、タイムゾーンの設定も重要です。GASの実行ログを確認し、トリガー設定で指定した時間が自身のタイムゾーンと一致しているかを再確認してみてください。日本時間を想定しているのに、UTCで設定されていたというケースは意外と多いものです。
実行制限の超過
GASには様々な実行制限が設けられています。これらの制限を超過すると、スクリプトは途中で停止したり、全く実行されなくなったりします。
無料アカウントの場合、トリガーで実行した処理時間は1日あたり最大90分までという制限があります。また、1スクリプト内で1ユーザーが設定できるトリガー回数の上限は20回です。さらに、1回のスクリプト実行は6分までという時間制限もあります。Google Workspaceアカウントの場合はこれらの制限が緩和されていますが、それでも無制限ではありません。
制限に達した場合、「Limit exceeded」や「Service invoked too many times」といったエラーメッセージが表示されます。このようなエラーが出た場合は、処理を分割したり、Utilities.sleep()を使って実行間隔を空けたりすることで対処できます。
2026年のRhinoランタイム廃止とV8移行について
2026年1月31日をもって、GASの旧ランタイムであるRhinoランタイムが完全に廃止されました。これは2025年2月20日に非推奨となってから約1年間の移行期間を経た措置です。Rhinoランタイムで動作していたスクリプトは、V8ランタイムに移行しないと実行できなくなっています。
V8ランタイムへの移行が必要な理由
V8ランタイムは、ChromeやNode.jsでも採用されている高性能なJavaScriptエンジンです。V8に移行することで、アロー関数やテンプレートリテラル、分割代入といったモダンなJavaScript構文が使えるようになります。また、処理速度の向上も期待できます。
しかし、RhinoとV8には互換性のない部分があるため、古いスクリプトをそのまま実行すると動かなくなることがあります。特に注意が必要なのは、for each…in構文の使用、Date.prototype.getYear()メソッドの使用、constで宣言した変数への再代入、XML リテラルやXMLオブジェクトの使用などです。
V8への移行手順
移行作業自体は比較的シンプルです。まず、スクリプトエディタを開き、左側のメニューから「プロジェクト設定」をクリックします。「Chrome V8ランタイムを有効にする」のチェックボックスをオンにして保存すれば、基本的な設定は完了です。
ただし、これだけでは不十分な場合があります。appsscript.jsonマニフェストファイルで確認する場合は、「runtimeVersion」フィールドが「V8」になっていることを確認してください。「DEPRECATED_ES5」となっている場合は、Rhinoランタイムのままになっています。
移行後は必ずスクリプトをテスト実行し、正常に動作することを確認してください。前述の非互換な構文を使用している場合は、エラーが発生するのでコードの修正が必要になります。
コードに起因するエラーの対処法
GASが動かない原因として、コード自体に問題があるケースも当然考えられます。構文エラーからロジックの誤りまで、様々なパターンを見ていきましょう。
構文エラーの発見と修正
構文エラーは最も基本的なミスですが、意外と見落としがちです。括弧の閉じ忘れ、セミコロンの抜け、スペルミスなど、細かな部分で引っかかることがあります。V8ランタイムでは、コードの評価時にこれらのエラーを検出してくれますが、時として「未キャッチエラー」となり、保存時にはエラーが出ないものの実行時に失敗するケースもあります。
スクリプトエディタにはデバッグ機能が搭載されています。コードの左側にある行番号をクリックすることでブレークポイントを設定し、上部メニューの虫のアイコンをクリックしてデバッグ実行することで、処理の途中で一時停止させて変数の中身を確認できます。
外部データとの連携エラー
外部APIやkintoneなどのサービスと連携している場合、フィールドの設定不一致がエラーの原因になることがあります。例えば、Googleフォームからkintoneにデータを送信する際、kintone側のフィールドでリンクフィールドを「メールアドレス」に設定しているのに、送信データの形式が「WebサイトのURL」になっていると、データが正しく登録されません。
このような問題を解決するには、APIのレスポンスをログに出力して確認することが有効です。try-catch構文でエラーをキャッチし、Logger.logやconsole.logでエラーメッセージを記録することで、問題の特定がしやすくなります。
非同期処理と実行順序の問題
GASでは、処理が同期的に実行されるため、大量のデータを扱う場合に6分の実行時間制限に引っかかることがあります。また、SpreadsheetAppのメソッドを繰り返し呼び出すと、処理速度が大幅に低下します。
対策として、getValues()でデータを一括取得し、メモリ上で処理してからsetValues()で一括書き込みを行うバッチ処理方式を採用しましょう。セルを1つずつ読み書きするよりも、はるかに効率的に処理できます。
ブラウザやシステム環境に関する問題
コードやトリガーに問題がないのに動かない場合、ブラウザやGoogleのシステム側に原因がある可能性があります。
Chromeの仕様変更による影響
過去には、Chromeのバージョンアップによってクロスオリジンiframe内でのalert()やwindow.confirm()が使用できなくなるという変更がありました。GASのWebアプリでこれらのダイアログを使用していた場合、ある日突然動かなくなるという事態が発生しました。
このような場合の対処法として、ダイアログをGAS側の機能（SpreadsheetApp.getUi().alert()など）に置き換えることが有効です。また、HTMLServiceを使ったカスタムダイアログに変更することも検討してください。
キャッシュとCookieのクリア
「Bad Request Error 400」のようなエラーが発生した場合、ブラウザのキャッシュやCookieが原因であることがあります。シークレットモードで試してみて正常に動作する場合は、通常モードのキャッシュに問題がある可能性が高いです。
script.google.comのCookieをクリアしたり、別のGoogleアカウントでログインし直したりすることで解決するケースもあります。複数のGoogleアカウントでログインしている場合は、アカウントの切り替えが正しく行われているかも確認してみてください。
Googleサービスの障害
稀ではありますが、Google側のサービス障害によってGASが動かなくなることがあります。Google Workspace Status Dashboardを確認し、Apps Scriptに障害が発生していないかチェックしましょう。障害が発生している場合は、復旧を待つしかありません。
デバッグとログ確認の実践テクニック
GASのトラブルシューティングにおいて、ログの確認は最も重要なスキルの一つです。適切にログを出力し、確認することで、問題の原因を効率的に特定できます。
Logger.logとconsole.logの使い分け
GASでログを出力する方法には、Logger.log()とconsole.log()の2種類があります。基本的にはconsole.log()の方が機能が豊富で、ログレベル（info、warn、error）を明確に分けられるためおすすめです。一方、Logger.log()はスプレッドシートへのログ出力と相性が良いという特徴があります。
出力されたログは、スクリプトエディタの左サイドバーにある「実行数」から確認できます。直近の実行ログは「実行ログ」ペインで確認でき、過去の実行結果は実行数の一覧から該当する実行を選択することで詳細を見ることができます。
スプレッドシートへのログ出力
トリガーで実行されるスクリプトや、doPost関数のように通常のログ確認が難しい場合は、スプレッドシートに直接ログを出力する方法が効果的です。タイムスタンプとともにログ内容をスプレッドシートに書き込むことで、外部からのリクエスト内容や処理の進行状況を「見える化」できます。
この方法のメリットは、GASプロジェクトを開かなくてもログを確認できること、そしてGASに詳しくない人でもスプレッドシートの画面からログを確認できることです。チームで運用している場合に特に重宝します。
GCPログエクスプローラの活用
より高度なデバッグが必要な場合は、Google Cloud Platform（GCP）のログエクスプローラを活用することをおすすめします。GASプロジェクトをGCPプロジェクトに紐づけることで、通常では確認できないdoPost関数の実行ログも取得できるようになります。
設定には少し手間がかかりますが、複雑なWebアプリや外部サービス連携を行っている場合には、このログエクスプローラが強力なデバッグツールになります。過去のログも蓄積されるため、問題発生時の状況を後から確認することも可能です。
Webアプリとして公開している場合の注意点
GASをWebアプリとしてデプロイしている場合、特有の問題が発生することがあります。安定稼働していたWebアプリが突然動かなくなるケースは、意外と多いものです。
デプロイのやり直しで解決する場合
「その操作を実行するには承認が必要です」というエラーが表示される場合、コードを1文字も変更していなくても、デプロイをやり直すことで解決することがあります。スクリプトエディタから「デプロイ」→「新しいデプロイ」を選択し、新しいバージョンとしてデプロイし直してみてください。
これはGoogleのシステム側の変更によって、古いデプロイが正常に動作しなくなることがあるためです。特に長期間放置していたWebアプリでは、この方法が効果的なことが多いです。
アクセス権限の設定確認
Webアプリの「アクセスできるユーザー」設定も確認してください。「自分のみ」「ドメイン内の全員」「全員」のいずれに設定されているかによって、アクセス権限が異なります。想定しているユーザーがアクセスできる設定になっているか、確認することが重要です。
また、「次のユーザーとして実行」の設定も重要です。「自分」として実行する場合と「ウェブアプリにアクセスしているユーザー」として実行する場合で、スクリプトがアクセスできるデータの範囲が変わってきます。
Googleのサービス終了とAPI変更への対応
GASを長期間運用していると、Googleのサービス終了やAPI変更の影響を受けることがあります。予期せずスクリプトが動かなくなるリスクを最小限に抑えるための心構えを持っておきましょう。
サービス終了の事前把握
Googleは比較的頻繁にサービスの終了や変更を行います。例えば、Contactsサービスは2022年12月に非推奨となり、People API Advanced Serviceへの移行が必要になりました。また、Classic Google Sitesサービスも廃止されています。
このような変更に備えるために、Google Apps Scriptのリリースノートを定期的にチェックすることをおすすめします。また、ベータ版のサービスは本番環境での使用を避けるなど、手堅い運用を心がけることも大切です。
Google Issue Trackerの活用
GASで問題が発生した際、Google側のバグである可能性もあります。Google Issue Trackerで類似のバグ報告がないか検索してみましょう。同じ問題を抱えている人がいれば、回避策が共有されていることもあります。
重要なのは、GASにはGoogleの公式サポートがないということです。有償のGoogle Workspace契約者であっても、「UIから再現できないことはサポート外」とされています。そのため、コミュニティでの情報収集や自己解決能力を高めておくことが重要になります。
情シス経験者が教える現場で本当に起きるGASトラブルの真実
Googleスプレッドシートのイメージ
ここからは、企業の情報システム部門で10年以上の経験を持つ視点から、一般的な解説記事では触れられない現場ならではのトラブルと、その解決策をお伝えします。ネット検索しても出てこない、でも確実に多くの人が遭遇している問題ばかりです。
退職者が作ったGASが突然動かなくなる問題
これは本当に多いです。ある日突然、毎日動いていた自動処理が止まる。調べてみると、3年前に退職した社員のアカウントで作成されたGASだった、というケース。Googleアカウントが削除されたり、Google Workspaceのライセンスが解除されたりすると、そのアカウントで設定されていたトリガーも一緒に消えるんです。
さらに厄介なのは、スクリプト自体は残っているのに、トリガーだけが消えているパターン。コードを見ても問題なさそうに見えるので、原因特定に時間がかかります。トリガー一覧を開いて「あれ？トリガーがない…」と気づくまでに半日かかった、なんてこともザラにあります。
この問題を根本的に解決するには、共有用の専用アカウントでGASを作成・管理する運用ルールを設けることです。例えば「gas-admin@会社ドメイン.com」のような専用アカウントを作り、重要な自動処理はすべてこのアカウントで作成します。退職者が出ても、このアカウントは残り続けるので、トリガーが消える心配がありません。
トリガーの所有者問題という落とし穴
GASのトリガーには「所有者」という概念があります。これがまた厄介で、トリガーを作成した人のアカウントで実行されるという仕様になっています。つまり、Aさんがトリガーを設定すると、Bさんがスプレッドシートを編集しても、トリガーで動くスクリプトはAさんの権限で実行されます。
これが問題になるのは、例えばAさんには見えるフォルダがBさんには見えない場合。トリガーで実行されるスクリプトがそのフォルダにアクセスしようとすると、Aさんの権限で動くので正常に動作しますが、Bさんが手動でスクリプトを実行しようとするとエラーになる、という不思議な現象が起きます。
逆に、Aさんがトリガーを設定した後、Aさんのアクセス権限が変更されると、トリガー実行時にエラーになります。本人は何も変更していないのに、情シス側でアクセス権限を整理した結果、GASが動かなくなる。こういう「誰も悪くない」パターンが一番困るんです。
共有ドライブに置いたスプレッドシートでGASが動かない
Google Workspaceの共有ドライブ（旧チームドライブ）にスプレッドシートを置くと、マイドライブに置いた場合とは挙動が異なることがあります。特に、SpreadsheetApp.getActiveSpreadsheet()がnullを返すケースが報告されています。
共有ドライブ上のファイルでGASを使う場合は、SpreadsheetApp.openById()でスプレッドシートIDを直接指定する方法が確実です。また、共有ドライブのアクセス権限設定によっては、GASからのファイル操作が制限されることもあるので、「コンテンツ管理者」以上の権限があるか確認してください。
現場で使える実践的なGASコード集
ここでは、トラブル対応や運用を楽にするための実践的なコードを紹介します。コピペしてそのまま使えるものばかりなので、ぜひ活用してください。
エラー発生時に自動でメール通知を送るコード
トリガーで自動実行しているGASがエラーで止まっても、気づくのが遅れることがあります。以下のコードをスクリプトに組み込んでおけば、エラー発生時に即座にメールで通知を受け取れます。
function myMainFunction() {
try {
// ここにメインの処理を書く
const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();
const data = sheet.getDataRange().getValues();
// ... 処理内容 ...
} catch (error) {
// エラーが発生したら通知を送る
sendErrorNotification(error);
throw error; // エラーを再スローして実行ログにも残す
}
}
function sendErrorNotification(error) {
const recipient = 'あなたのメールアドレス@example.com';
const subject = '【GASエラー通知】スクリプトでエラーが発生しました';
const body = `
以下のエラーが発生しました。
■ 発生日時
${new Date().toLocaleString('ja-JP')}
■ エラーメッセージ
${error.message}
■ スタックトレース
${error.stack}
■ スプレッドシート
${SpreadsheetApp.getActiveSpreadsheet().getUrl()}
`;
GmailApp.sendEmail(recipient, subject, body);
}
このコードのポイントは、try-catchでエラーをキャッチしつつ、最後にthrowで再スローしている点です。こうすることで、メール通知を送りながら、GASの実行ログにもエラーを残すことができます。
同時実行を防ぐロック機能のコード
複数人が同じスプレッドシートを操作している環境で、編集トリガーが設定されていると、同時に複数のスクリプトが実行されてデータが壊れることがあります。以下のコードで同時実行を防げます。
function onEditWithLock(e) {
const lock = LockService.getScriptLock();
try {
// 最大30秒待ってロックを取得
lock.waitLock(30000);
// ロックが取得できたらメイン処理を実行
processEdit(e);
} catch (error) {
// ロック取得に失敗した場合
console.log('ロック取得に失敗しました。他のスクリプトが実行中です。');
} finally {
// 必ずロックを解放
lock.releaseLock();
}
}
function processEdit(e) {
// 実際の編集処理をここに書く
const sheet = e.source.getActiveSheet();
const range = e.range;
// 処理内容...
}
LockServiceを使うと、同時に1つのスクリプトしか実行されないように制御できます。特に、データの整合性が重要な処理（連番の採番、在庫数の更新など）では必須のテクニックです。
処理時間を監視して6分制限を回避するコード
大量のデータを処理する際、6分の実行時間制限に引っかかることがあります。以下のコードは、処理の途中で時間をチェックし、制限に近づいたら続きを次のトリガーに委ねる仕組みです。
function processLargeData() {
const startTime = new Date();
const MAX_EXECUTION_TIME = 5 * 60 * 1000; // 5分（余裕を持って）
const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('データ');
const properties = PropertiesService.getScriptProperties();
// 前回の処理位置を取得（初回は0）
let lastRow = parseInt(properties.getProperty('lastProcessedRow') || '0');
const data = sheet.getDataRange().getValues();
for (let i = lastRow; i < data.length; i++) {
// 経過時間をチェック
const elapsedTime = new Date() - startTime;
if (elapsedTime > MAX_EXECUTION_TIME) {
// 制限時間に近づいたら、現在位置を保存して終了
properties.setProperty('lastProcessedRow', i.toString());
console.log(`時間切れのため中断。${i}行目まで処理完了。`);
// 1分後に続きを実行するトリガーを設定
ScriptApp.newTrigger('processLargeData')
.timeBased()
.after(1 * 60 * 1000)
.create();
return;
}
// ここに各行の処理を書く
processRow(data, i);
}
// 全件処理完了
properties.deleteProperty('lastProcessedRow');
console.log('全データの処理が完了しました。');
// 一時的に作成したトリガーを削除
deleteTriggers('processLargeData');
}
function processRow(row, index) {
// 各行の処理内容
Utilities.sleep(100); // 処理が重い場合の例
}
function deleteTriggers(functionName) {
const triggers = ScriptApp.getProjectTriggers();
triggers.forEach(trigger => {
if (trigger.getHandlerFunction() === functionName) {
ScriptApp.deleteTrigger(trigger);
}
});
}
PropertiesServiceを使って処理位置を保存し、時間切れになったら自動で続きのトリガーを作成します。これにより、数万行のデータでも確実に処理を完了させることができます。
スクリプトの実行状況をスプレッドシートに自動記録するコード
「いつ実行されたか」「正常に終わったか」を記録しておくと、トラブル時の原因調査が格段に楽になります。
function logExecution(functionName, status, details = '') {
const logSheetName = '_実行ログ';
const ss = SpreadsheetApp.getActiveSpreadsheet();
let logSheet = ss.getSheetByName(logSheetName);
// ログシートがなければ作成
if (!logSheet) {
logSheet = ss.insertSheet(logSheetName);
logSheet.appendRow);
logSheet.setFrozenRows(1);
}
// ログを追記
logSheet.appendRow[
new Date(),
functionName,
status,
details,
Session.getActiveUser().getEmail()
]);
// 古いログを削除（1000行を超えたら古い順に削除）
const lastRow = logSheet.getLastRow();
if (lastRow > 1000) {
logSheet.deleteRows(2, lastRow - 1000);
}
}
// 使用例
function myFunction() {
logExecution('myFunction', '開始');
try {
// メイン処理
// ...
logExecution('myFunction', '正常終了');
} catch (error) {
logExecution('myFunction', 'エラー', error.message);
throw error;
}
}
このログ機能を組み込んでおくと、「昨日の夜中に何か動いたはずだけど、ちゃんと動いたかな？」という確認が、スプレッドシートを見るだけで済みます。
誰も教えてくれない「あるある」トラブル解決法
ここでは、マニュアルや公式ドキュメントには書かれていない、でも現場では頻繁に遭遇する問題とその解決法を紹介します。
「さっきまで動いてたのに」問題の正体
GASを手動で実行すると動くのに、トリガーで実行すると動かない。これ、非常に多いパターンです。原因の多くはSession.getActiveUser()やSpreadsheetApp.getActiveSpreadsheet()といった「アクティブ」系のメソッドにあります。
手動実行時は、あなたがスプレッドシートを開いた状態で実行するので、「アクティブなスプレッドシート」が明確です。しかし、時間トリガーで実行される場合、誰もスプレッドシートを開いていないので「アクティブ」なものが存在しません。結果、nullが返ってきてエラーになります。
解決策は、IDを直接指定する方法に書き換えることです。
// NG: トリガー実行時に動かない可能性がある
const ss = SpreadsheetApp.getActiveSpreadsheet();
// OK: 確実に動く
const ss = SpreadsheetApp.openById('スプレッドシートのIDをここに入れる');
// スプレッドシートIDの取得方法
// URLの「https://docs.google.com/spreadsheets/d/XXXXXX/edit」
// このXXXXXXの部分がID
シート保護とGASの権限が衝突する問題
スプレッドシートの特定範囲を保護して編集できないようにしている場合、GASからもその範囲を編集できなくなることがあります。「自分で保護を設定したのに、自分のGASで書き込めない」という混乱が生じます。
これは、シート保護の設定で「この範囲を編集できるユーザー」にGASの実行ユーザー（またはトリガーの所有者）が含まれていない場合に起きます。解決策は2つあります。
1つ目は、シート保護の編集可能ユーザーにGAS実行ユーザーを追加する方法。2つ目は、GASでシート保護を一時的に解除してから編集し、再度保護をかける方法です。後者のコード例を示します。
function editProtectedRange() {
const sheet = SpreadsheetApp.openById('ID').getSheetByName('シート名');
const range = sheet.getRange('A1:B10');
// 保護を取得
const protections = sheet.getProtections(SpreadsheetApp.ProtectionType.RANGE);
let targetProtection = null;
protections.forEach(protection => {
if (protection.getRange().getA1Notation() === 'A1:B10') {
targetProtection = protection;
}
});
// 保護を一時的に解除
if (targetProtection) {
targetProtection.remove();
}
// 編集処理
range.setValue('新しい値');
// 保護を再設定
const newProtection = range.protect();
newProtection.setDescription('GASによる再保護');
newProtection.addEditor(Session.getEffectiveUser());
}
importRange関数があるシートでGASが遅くなる問題
IMPORTRANGE関数で他のスプレッドシートからデータを取得しているシートで、GASの処理が異常に遅くなることがあります。これは、GASがシートを読み込む際にIMPORTRANGEの再計算が走ってしまうためです。
対策として、IMPORTRANGE関数の結果を別シートに値として貼り付けておき、GASはその値貼り付け済みのシートを参照するようにします。定期的にIMPORTRANGEの結果を値として更新するGASを別途作成しておくと、メインの処理が安定します。
function updateImportedData() {
const ss = SpreadsheetApp.openById('ID');
const sourceSheet = ss.getSheetByName('IMPORTRANGE元');
const targetSheet = ss.getSheetByName('値コピー用');
// IMPORTRANGEの結果を値として取得
const data = sourceSheet.getDataRange().getValues();
// 値として貼り付け
targetSheet.clear();
targetSheet.getRange(1, 1, data.length, data.length).setValues(data);
}
onEdit関数が発火しない謎の現象
onEdit関数を設定したのに、セルを編集しても何も起きない。この問題、原因は複数考えられます。
まず確認すべきは、シンプルトリガーの制限です。onEdit()はシンプルトリガーなので、認証が必要なサービス（GmailApp、DriveAppなど）を使用すると動きません。認証が必要な処理をしたい場合は、インストール可能なトリガーとして設定する必要があります。
次に、スクリプトによる編集では発火しないという仕様があります。Range.setValue()などGASから行った編集では、onEditは実行されません。人間が手動で編集した場合のみ発火します。
さらに、読み取り専用モードでスプレッドシートを開いている場合もonEditは動きません。閲覧権限しかないユーザーが編集しようとしても、そもそも編集ができないので当然ですね。
// シンプルトリガー（認証不要な処理のみ可能）
function onEdit(e) {
// OK: スプレッドシート操作
e.source.getActiveSheet().getRange('A1').setValue('編集されました');
// NG: Gmail操作は認証が必要なので動かない
// GmailApp.sendEmail('test@example.com', '件名', '本文');
}
// 認証が必要な処理をしたい場合は、インストール可能なトリガーを使う
function onEditInstallable(e) {
// この関数を「編集時」のインストール可能なトリガーに設定する
GmailApp.sendEmail('test@example.com', '編集通知', 'シートが編集されました');
}
運用を楽にする情シス流の管理術
GASを長期間安定して運用するためのノウハウを共有します。これらは公式ドキュメントには書かれていませんが、実務では非常に重要なポイントです。
GASの棚卸しを定期的に行う
組織でGASを使っていると、いつの間にか誰が何のために作ったかわからないスクリプトが増殖します。年に1回はGASの棚卸しを行い、不要なスクリプトやトリガーを整理しましょう。
棚卸しの際にチェックすべき項目は、スクリプトの作成者が現在も在籍しているか、トリガーが設定されているか、最終実行日はいつか、何のための処理なのかがドキュメント化されているか、です。
以下のコードで、現在設定されているトリガーの一覧を取得できます。
function listAllTriggers() {
const triggers = ScriptApp.getProjectTriggers();
const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('トリガー一覧');
// ヘッダー
sheet.clear();
sheet.appendRow);
triggers.forEach(trigger => {
sheet.appendRow[
trigger.getHandlerFunction(),
trigger.getTriggerSource(),
trigger.getEventType(),
trigger.getUniqueId()
]);
});
}
コメントとREADMEシートの重要性
半年後の自分は他人です。「何でこんな処理書いたんだっけ？」と悩む未来の自分のために、コードにはしっかりコメントを残しましょう。特に、なぜその処理が必要なのか（Why）を書くことが重要です。
また、スプレッドシートの先頭に「_README」というシートを作成し、そのスプレッドシートとGASの概要を記載しておくことをおすすめします。
/**
* 日次売上レポート自動作成スクリプト
*
* 【概要】
* 毎朝6時に前日の売上データを集計し、Slackに通知する
*
* 【トリガー設定】
* - 時間ベース: 毎日午前6時〜7時
* - 関数: createDailyReport
*
* 【注意事項】
* - 月初は前月の集計も行うため、処理時間が長くなる
* - 祝日は営業日判定で除外している
*
* 【更新履歴】
* 2026-01-15 田中: 初版作成
* 2026-02-01 鈴木: 祝日除外機能を追加
*/
function createDailyReport() {
// ...
}
テスト環境の作り方
本番のスプレッドシートで直接GASを編集するのは危険です。必ずテスト用のコピーを作成して、そこで動作確認をしてから本番に反映しましょう。
ただし、単純にスプレッドシートをコピーしても、GASは一緒にコピーされません。スクリプトエディタから「プロジェクトをコピー」を選択するか、以下の手順でテスト環境を作成します。
- 本番スプレッドシートをコピーする（「ファイル」→「コピーを作成」）
- コピーしたスプレッドシートでスクリプトエディタを開く
- 本番のGASコードをコピー＆ペーストする
- コード内のスプレッドシートIDをテスト用のIDに書き換える
- テスト環境でトリガーを設定して動作確認
本番とテストでスプレッドシートIDが異なる場合、スクリプトプロパティを使ってIDを外出しにしておくと、コードの書き換えが不要になります。
function getSpreadsheetId() {
// スクリプトプロパティから取得
const id = PropertiesService.getScriptProperties().getProperty('SPREADSHEET_ID');
if (!id) {
throw new Error('スクリプトプロパティにSPREADSHEET_IDを設定してください');
}
return id;
}
function myFunction() {
const ss = SpreadsheetApp.openById(getSpreadsheetId());
// ...
}
本当によくある質問と本音の回答
GASとPythonやJavaScript、どっちを覚えるべきですか？
Google Workspaceを業務で使っているなら、まずGASを覚えることをおすすめします。GASはJavaScriptベースなので、GASを覚えればJavaScriptの基礎も身につきます。そして何より、環境構築が不要という点が大きい。Pythonは環境構築でつまずく人が多いですが、GASはブラウザさえあれば今すぐ始められます。
ただし、大量データ処理やAI・機械学習をやりたいならPython一択です。GASは6分制限があるので、大規模処理には向きません。用途に応じて使い分けるのがベストです。
GASのコードをGitHubで管理すべきですか？
個人で使う程度なら、正直そこまで必要ありません。GASにはバージョン管理機能があり、過去のバージョンに戻すことも可能です。ただし、チーム開発や複数プロジェクトで同じコードを使い回す場合は、claspというツールを使ってGitHub管理にすると便利です。
claspを使えば、ローカルのVSCodeなどでGASを編集できるようになります。シンタックスハイライトやコード補完が効くので、開発効率が上がります。
AIにGASを書いてもらうのはアリですか？
大いにアリです。ChatGPTやClaudeにGASのコードを書いてもらい、それをベースに修正を加えるのは非常に効率的な方法です。ただし、AIが生成したコードをそのままコピペして「動かない」と悩む人も多いです。
AIは完璧ではないので、生成されたコードは必ず自分で確認し、必要に応じて修正してください。特に、スプレッドシートIDやシート名などの固有情報は、自分の環境に合わせて書き換える必要があります。AIに「このコードが動かないんだけど」と質問すれば、修正案も提案してくれますよ。
ぶっちゃけこうした方がいい！
ここまで色々と解説してきましたが、正直なところをぶっちゃけますね。
GASが動かなくて困っている人の8割以上は、ログを見ていないです。エラーメッセージをちゃんと読めば、原因の大半は特定できます。「動かない」と思考停止する前に、まずスクリプトエディタの「実行数」を開いて、直近の実行結果を確認してください。エラーが出ていれば、そのメッセージをそのままGoogleで検索すれば、だいたい解決策が見つかります。
次に、SpreadsheetApp.getActiveSpreadsheet()を使うのをやめましょう。これがトリガー実行時の不具合の最大の原因です。スプレッドシートIDをスクリプトプロパティに保存して、openById()で開く。これだけで、トリガー関連のトラブルの半分は解消します。面倒でも、この書き方を習慣にしてください。
そして、try-catchとログ出力を必ず入れること。エラー発生時に何が起きたかわからないと、デバッグに何倍もの時間がかかります。最初から入れておけば、問題発生時に「あ、このエラーね」と一発で原因がわかります。後から入れるのは面倒なので、最初のコーディング時に入れる習慣をつけてください。
最後に、これが一番重要なんですが、複雑なことをGASでやろうとしないでください。GASはあくまで「ちょっとした自動化」に最適なツールです。大規模なデータ処理、複雑なビジネスロジック、高い信頼性が求められる処理は、GASではなく専用のシステムやクラウドサービスを使うべきです。
「GASならタダだから」という理由で無理やりGASで実装して、結局トラブルだらけで工数がかかる、というケースを何度も見てきました。GASでできることとできないことを見極めて、適材適所で使うのが一番賢い選択です。シンプルな処理をシンプルなコードで書く。これがGASを楽に運用するための最大の秘訣だと、10年以上の経験から断言できます。
スプレッドシートでGASが動かないことに関する疑問解決
GASが急に動かなくなったのですが、コードは変更していません。何が原因でしょうか？
コードを変更していないのにGASが動かなくなる原因として、まず考えられるのはGoogleのシステム変更です。ブラウザの仕様変更、GASランタイムの更新、関連サービスのAPI変更などが影響している可能性があります。また、トリガーの実行時間制限に達している場合や、OAuth認証の期限切れが発生している場合もあります。デプロイをやり直す、権限を再承認する、ログを確認するといった手順で、一つずつ原因を切り分けていくことをおすすめします。
「このアプリはブロックされます」と表示されて実行できません。どうすればいいですか？
このエラーは、スクリプト実行ユーザーが処理対象のファイルにアクセス権限を持っていない場合に発生することがあります。スプレッドシートやGoogleドキュメントなど、GASがアクセスしようとしているファイルの共有設定を確認してください。また、Google Workspaceを使用している場合は、組織管理者がサードパーティのスクリプト実行を制限している可能性もあります。管理者に確認するか、別のアカウントで試してみてください。
トリガーが設定した時間に実行されないのですが、なぜでしょうか？
時間ベースのトリガーは、正確に設定した時間に実行されるとは限りません。「1時間ごと」に設定した場合でも、実際には1時間前後のずれが生じることがあります。また、タイムゾーンの設定ミスにより、想定と異なる時間に実行されていることもあります。スクリプトエディタの「実行数」から、実際にトリガーが実行された時間を確認してみてください。また、トリガーの1日あたり90分という実行時間制限に達していないかも確認が必要です。
V8ランタイムに移行したらエラーが出るようになりました。どう対処すればいいですか？
V8ランタイムはRhinoランタイムと完全な互換性があるわけではありません。特に、for each…in構文、Date.prototype.getYear()、constへの再代入、XMLリテラルなどは、V8では動作しません。エラーメッセージを確認し、問題のある構文を特定して修正してください。for each…inはfor…ofに、getYear()はgetFullYear()に置き換えるなどの対応が必要です。古いコードをコピペして使っている場合は、特に注意が必要です。
doPost関数のログが確認できません。どうやってデバッグすればいいですか？
doPost関数は外部からのリクエストで実行されるため、通常のconsole.logでは実行ログを確認できないことがあります。対処法として、スプレッドシートに直接ログを出力するカスタムログ関数を作成する方法、doPost関数を呼び出すテスト用関数を作成してデバッグする方法、GCPプロジェクトに紐づけてログエクスプローラで確認する方法があります。開発段階では、まずスプレッドシートへのログ出力から試してみることをおすすめします。
今すぐパソコンやスマホの悩みを解決したい！どうしたらいい？
いま、あなたを悩ませているITの問題を解決します！
「エラーメッセージ、フリーズ、接続不良…もうイライラしない！」
あなたはこんな経験はありませんか？
✅ ExcelやWordの使い方がわからない💦
✅ 仕事の締め切り直前にパソコンがフリーズ💦
✅ 家族との大切な写真が突然見られなくなった💦
✅ オンライン会議に参加できずに焦った💦
✅ スマホの重くて重要な連絡ができなかった💦
平均的な人は、こうしたパソコンやスマホ関連の問題で年間73時間（約9日分の働く時間！）を無駄にしています。あなたの大切な時間が今この悩んでいる瞬間も失われています。
LINEでメッセージを送れば即時解決！
すでに多くの方が私の公式LINEからお悩みを解決しています。
最新のAIを使った自動応答機能を活用していますので、24時間いつでも即返信いたします。
誰でも無料で使えますので、安心して使えます。
問題は先のばしにするほど深刻化します。
小さなエラーがデータ消失や重大なシステム障害につながることも。解決できずに大切な機会を逃すリスクは、あなたが思う以上に高いのです。
あなたが今困っていて、すぐにでも解決したいのであれば下のボタンをクリックして、LINEからあなたのお困りごとを送って下さい。
ぜひ、あなたの悩みを私に解決させてください。
まとめ
スプレッドシートでGASが動かない原因は、権限設定の問題、トリガーの設定ミス、実行制限の超過、コードのエラー、ブラウザや環境の問題、Googleのシステム変更など、多岐にわたります。トラブルシューティングの基本は、ログを確認して問題を特定し、一つずつ原因を切り分けていくことです。
2026年1月31日にRhinoランタイムが廃止されたことで、古いスクリプトを使い続けていた場合は動かなくなっている可能性があります。V8ランタイムへの移行がまだの場合は、早急に対応してください。
GASは非常に便利なツールですが、Googleの公式サポートは受けられないという点を理解しておく必要があります。定期的にリリースノートをチェックし、重要な変更には早めに対応する習慣をつけましょう。また、本番環境で稼働しているスクリプトは、月に1回程度は動作確認を行う「定期メンテナンス」の意識を持つことで、突然の障害を防ぐことができます。問題が発生した際は、この記事を参考にしながら、冷静にトラブルシューティングを進めてください。
コメント