Google Workspaceの自動化をAIに書かせる｜Apps Scriptで詰まる所と回避策

「スプレッドシートの集計を朝ごとに自動化したい」「条件に合うメールの内容を一覧へ移したい」。このような仕事をClaude CodeなどのAIへ頼めば、実際に動作するコードは数分ほどで形になります。プログラミングに詳しくない人でも、立ち上がりの速さを実感できるはずです。

難しいのは完成後です。法人の導入を支援するなかで当社へ特に多く届くのは、「作成までは順調だったが、実用化の段階で先へ進めなくなった」という相談です。実行時の警告で進めない、しばらくすると結果が来なくなる、異常表示がないまま処理数だけゼロになる、といった問題が起こります。

関連する解説も複数確認しましたが、多くは「AIなら自動化を手軽に作れる」という説明が中心で、実行時間の上限に軽く触れる程度でした。認可画面の通過方法、外部リクエストの確認、障害を発見する仕掛け、連携サービスを有効化する手順など、本番運用で必要になる論点はほとんど説明されていません。

そこでこの記事では、コードの完成後につまずきやすい箇所に焦点を絞ります。当社では商談履歴や日報の作成、管理表のステータス更新、記事下書きの公開など、Google Workspaceを使った複数の自動処理を稼働中です。その過程で遭遇した制約と、現場で使っている対策を順に紹介します。公式の上限も、調査日を添えてまとめました。

この記事に記載した制限は、Google公式「Apps Script の割り当てと制限」とGoogle Cloud公式ヘルプ（未確認アプリの警告について）を2026年8月18日に確認して整理したものです。Claude Codeについては同日、Claude Code公式ドキュメント（セキュリティ）で仕様を確かめました。数値や仕様は今後変わる可能性があります。社内資料などへ転用する場合も、公式ページで最新情報を必ず確かめてください。なお、第三者の記事にある数値は引用していません。上限の一部では、外部記事の説明と公式表に相違が見つかったためです（詳しくは後述します）。つまずいた事例と対策は、当社内での利用と法人支援を通じて得た一次情報に基づきます。

「書ける」と「動き続ける」は別の話

はじめに、この領域で当社が感じている変化をお伝えします。以前と現在では、作業が難しくなる地点が変わりました。

コードを書く工程は、実際に軽くなった

Google Workspaceには、自動化を実現するApps Scriptが備わっています。追加料金をかけず、スプレッドシートやGmail、カレンダー、ドライブをプログラムで操作できる仕組みです。「表やメールに決められた手順を自動で実行させる機能」という理解で問題ありません。

かつては、この実装自体が非エンジニアにとって大きな障壁でした。文法を覚え、教材を読み終えても、自社業務へ合わせる段階で手が止まりがちです。AIによって、この負担は確実に小さくなりました。目的を日本語で説明し、表の構成を渡せば、実行可能な案を作ってもらえます。

難所は「その後」に移った

一方、当社の経験では、自動化を1本仕上げる全時間に対し、コーディングが占める部分は限定的です。むしろ次の作業に時間を使います。

• 実行時に警告が現れ、次の画面へ進めなくなる
• 連携先を利用する箇所に限って、理由不明の失敗が起こる
• 手動なら通るのに、自動運転へ切り替えると成果が返らない
• 前の週には稼働していた処理が、今週は通知もなく沈黙する
• 最初の実行時に、蓄積されたデータまで一括で対象になる

これらは、どれもプログラムの文法ミスではありません。そのためAIへ単に修正を求めても直らず、環境上の制限や設定を疑い、現象から根本原因を絞り込むための知識が欠かせません。

既製の連携口と、自作の仕組みの使い分け

具体論へ進む前に、最初の選択肢を整理しましょう。業務によっては、最初から作る必要がないケースもあります。

2つの道がある

Claude CodeでGoogle Workspaceを操作する手段は、主に2種類あります。

ひとつは、準備済みの連携手段を利用する方法です。用意された接続機能を介し、AIがカレンダーや文書へ直接アクセスします。初期設定後は「本日の予定を確認して」のように日本語で依頼できます。詳細は連携の記事をご覧ください。

もうひとつは、この記事で解説する独自構築です。Apps Scriptで処理を用意し、指定した時間または条件を合図に自動実行させます。

どちらを選ぶか

選び分けの基準は複雑ではありません。

• 利用者が頼んだタイミングだけ実行できればよい → 用意済みの連携機能を選ぶ
• 利用者が不在でも、所定の時刻・条件で実行したい → 独自の自動処理を用意する

両者の違いは重要です。既製の連携手段が働くのは、AIとやり取りしている最中に限られます。「朝8時に毎日集計する」「指定列の変更を検知して通知する」など、人の操作を待たずに走らせる仕事には、別途自動実行の構成が必要です。

役割分担の実例

当社は2つの方法を使い分けています。普段の情報確認や文章作成には既製の接続機能を使い、時刻起点の処理と表の更新を起点にする処理はApps Scriptへ任せています。記録の集約、日次報告の生成、管理表の状態更新などが後者の例です。

さらに、そのApps Scriptの作成そのものをClaude Codeへ依頼しています。ここからは、その方法を中心に説明します。

公式が定める主な上限

設計へ入る前に確認しておきたい制限値があります。未確認のまま実装すると、完成後に設計全体をやり直す事態になりかねません。

2026年8月18日時点の公式値

Google公式の「割り当てと制限」から、実務で影響しやすい数値を抜き出します。通常アカウントとGoogle Workspaceアカウントで上限が分かれる項目もあります。

• 各実行に使える時間：6分／実行（一般・Workspaceで共通）
• 自動処理の総実行時間：一般は90分／日、Workspaceは6時間／日
• 登録可能な自動処理：20／ユーザー／スクリプト
• 同時実行できる処理数：30／ユーザー
• 外部通信の利用回数：一般は20,000／日、Workspaceは100,000／日（1回の応答上限は50MB）
• スプレッドシートのカスタム関数：30秒／実行
• 設定情報への読み書き：一般は50,000／日、Workspaceは500,000／日
• メールで指定できる宛先：一般は100／日、Workspaceは1,500／日

他社記事と食い違っていた箇所

調査のなかで見つかった相違点も共有します。一部の解説では「一般アカウントなら6分、Google Workspaceなら30分」と案内されています。当社でも以前、その数値をもとに構成を考えたことがありました。

ところが、2026年8月18日に確認した公式表では、一般・Workspaceとも1回あたり6分／実行です。両者で異なるのは1回の時間ではなく、自動処理の総実行時間（90分／日と6時間／日）でした。

設計に効いてくるのは2つ

業務で早い段階から影響するのは、1回の実行時間と自動処理に使える総時間です。

1回ごとの上限は、処理をどれだけ大きな単位にできるかを左右します。数千行を一括処理する設計は、この制約を考えた時点で候補から外れます。

日ごとの総時間は、実行間隔をどこまで短くできるかに関係します。1分間隔の処理が複数あると、消費時間は予想以上の速さで増えます。当社では複数の定期処理を動かしていますが、短周期の仕事を1本へ集約し、内部で目的別に分岐する構成を採っています。これは登録上限（20）を温存するうえでも有効です。

書けたのに動かない6つの詰まりどころ

ここから中心テーマへ進みます。当社が現場で経験し、原因の特定に手間取った6つの地点をまとめました。

1. 承認の警告から進めない——開始操作をしても警告で遮られ、実行まで到達しない
2. 連携サービスが有効化されていない——対象サービスを利用する処理だけエラーになる
3. 受信した通信を真正と確認できない——外部連携の呼び出し元を確かめる情報が得られない
4. 制限時間を超えて終了する——データ増加後、処理が最後まで到達しなくなる
5. プログラムによる更新を検知しない——手入力では動く処理が、自動更新には反応しない
6. 通知が相手まで到達しない——本体は正常終了しても、メッセージだけ受信されない

いずれにも共通するのは、作成直後の簡単なテストでは見つけにくいことです。少数データの手動確認では通り、本番を開始してから姿を現します。次節から対策を個別に解説します。

承認画面で止まったときの解き方

多くの利用者が最初に遭遇する問題です。技術に詳しくない方が単独で解決するのは容易でなく、この画面を理由に諦めるケースも少なくありません。

何が起きているか

作ったプログラムがメールや表計算など、利用者個人のデータを扱うサービスへ接続するとき、Googleは本人の同意を求めます。安全を守るための正常な確認です。

ただし、その確認が安全性に懸念があるかのような警告文で表示されることがあります。自作した処理でも、出所の分からない外部アプリのように見えてしまいます。

公式に書かれている条件

2026年8月18日に参照したGoogle Cloud公式ヘルプでは、「機密または制限付きスコープ（アクセス可能な範囲）を利用しながら、同意画面の設定や検証申請が済んでいない場合」などに警告が出ると説明されています。

同時に、見落とせない例外も公式に示されています。利用者を同じドメイン内だけに限る社内アプリなら、検証を受ける必要がないという内容です。

実務での対処

この条件を踏まえると、取るべき対応は分かりやすくなります。

社内専用であれば、使える人を組織内のアカウントだけに設定します。一般公開するアプリ向けの申請は不要で、多くの社内自動化はこの設定で進められます。

警告が残る場合、当社では目的が伝わるプロジェクト名へ変更し、自社管理のクラウドプロジェクトに接続し直す方法で解消できました。初期状態では触れない管理項目も、接続先を変更すれば同意画面を自社側で設定できます。

紐づけ直した後の落とし穴

ただし、この作業には続きがあります。管理先を変更すると、それまで正常だった機能が一時的に使えなくなる場合があります。

新しい管理プロジェクトでは、連携先サービスを呼び出す機能がまだ無効だからです。ドライブや文書へ触れる処理が失敗するため、管理画面から対象機能を手動でオンにします。

当社もこの段階で作業が止まりました。エラーだけでは有効化不足と判断しにくく、実装ミスだと思って調査に時間をかけたためです。「管理先の変更後に機能を有効化する」という流れを知っていれば、数分で対応できます。

承認作業そのものについて

運用手順として、もうひとつ覚えておく点があります。同意を求める画面が別ウィンドウで表示され、AIから操作しづらいことがあります。

当社では構築をAIへ任せつつ、承認ボタンを押す場面だけ本人に3回対応してもらう形で進めています。あらかじめ工程へ組み込めば、予期せぬ中断と誤解せずに済みます。

時間の上限を前提に組み替える

続いて問題になるのが、処理に使える時間です。実装前から制限を前提に構成を決めなければなりません。

症状の出方が厄介

この問題を見逃しやすい理由は、完成直後には不具合が見えないことです。テスト対象が10件なら数秒で完了しても、運用開始から3か月後に800件へ増えると、急に途中終了するようになります。

さらに、一部分は正常に終わっているため、失敗通知が発生しない場合があります。後で触れる「気づかないまま停止する」代表例です。

組み替えの型

解決には、処理単位の設計を変更します。当社で用いる方法は3種類です。

型1：完了した対象を記録する。管理表の末尾へ「処理済み」用の列を1つ用意し、終了した行に印を付けます。次回は印がない行だけを探します。時間切れになった場合でも、次回は未完了の続きから再開できます。当社の管理表でも同じ列を設けています。

型2：1回に扱う量を制限する。「各実行は最大50件」と定め、超えた分を次回へ送ります。短い周期で実行する構成なら、実用上の待ち時間はほぼ増えません。

型3：負荷の高い仕事を別環境で行う。長時間かかる処理を、この仕組みへ無理に載せない選択です。後ほど説明する接続元の制限もあり、当社では一部を手元のパソコンで動く常駐処理へ移しました。

初回だけは特別扱いする

実体験から得た注意点を追加します。初回稼働では、蓄積済みの過去データが一斉に対象になる可能性があります。

当社が一覧の状態変更をきっかけに連絡する仕組みを導入した際、最初の実行で以前のデータもすべて処理され、通知が大量に送られる事故が発生しました。コードとしては想定どおりでも、業務上は明らかな失敗でした。

そのため同種の通知を停止し、結果を記録用の一覧へ書くだけの運用に切り替えています。この経験から得た要点は以下です。

外から呼ばれる仕組みを作るときの注意

少し技術的な話ですが、業務への影響が大きい一方で一般的な説明にはあまり登場しないため、ここで詳しく扱います。

やりたくなること

自動処理の範囲を広げると、外部サービスを起点に処理を開始する構成が欲しくなります。たとえば、チャット上のボタン操作によって管理表を書き換えるケースです。

Apps Scriptでは、この目的に使える外部リクエスト用の入口を公開できます。専用アドレスへ通信が送られると、登録した処理が開始されます。

そこで直面する制約

課題は、アクセスしてきた相手が正規の送信元かを確かめる方法です。

一般的な外部連携では、リクエストに付いた署名が正しいか検査します。ところが当社で試したところ、Apps Scriptの入口からは通信に含まれる付帯情報を参照できませんでした。つまり署名検証に必要な材料を取得できません。

この点を扱う解説は多くありません。よくある手順は、受信用の入口を作り、そのアドレスを連携先へ登録するところで説明を終え、検証できない制約までは触れていないのが実態です。

当社が採った回避策

当社は代替策として、URLへ秘密の合言葉を埋め込む方式を選びました。専用アドレスの末尾に推測されにくい文字列を加え、処理開始時に一致を確認します。異なる場合は、その後の操作を行いません。

この対策にも明確な弱点があります。URLを知られると、合言葉も同時に知られてしまいます。そこで、利用範囲を次の条件へ絞っています。

• 更新を許可する場所を事前に絞る（当社では指定した3列だけに制限）
• 入力可能な値も決めておく（用意した候補以外の値は拒否）
• 操作を行った人の情報を記録一覧へ保存する
• 元へ戻せない処理の前には確認操作を加える

要するに、「入口の検証に限界があるため、実行可能な操作を小さく限定して補う」という考え方です。金額の決定や社外送信など、誤動作の影響が大きい仕事はこの入口から実行させません。

もう1つの時間制約

外部サービスから起動する場合は、別の時間制限にも注意が要ります。連携元が非常に短い時間で返答を求めるケースです。数秒以内に応答できなければ、先方では失敗として処理されます。

この場合は、入口で受付完了だけを即時に返し、本処理を後続へ回す構成にします。画面にはすぐ反応を表示し、実際の作業は数十秒後に終える流れです。

反応しない自動処理と、その回避策

次に説明するのは、当社の運用事例のなかでも発見までに特に時間がかかった現象です。

「編集されたら動く」は、人の編集にしか反応しない

Apps Scriptには、スプレッドシートのセル変更を検知して自動で処理を始める機能があります。担当者が状態を更新した瞬間に次の仕事を開始できるため、便利な仕組みです。

しかし、ここには大切な仕様があります。プログラムがセルへ値を設定しても、この機能は動きません。きっかけになるのは、画面から人が編集した操作です。

実際に起きたこと

当社では、管理表のステータスが指定値へ変わると後続処理を始める仕組みを使っています。担当者が画面から入力していた間は、問題なく実行できていました。

のちに、チャットのボタン操作でも同じセルを変更できるよう拡張したところ、ボタンによる変更時だけ次の処理が始まらない状態になりました。セルの内容は変わっているにもかかわらず、連動部分が反応しません。

理由は先ほどの仕様です。ボタン経由の変更はプログラムからの書き込みなので、編集検知の対象外になります。

回避策

当社では、編集検知だけに任せず、一定間隔で管理表を巡回する処理も追加することで解決しました。1分間隔で条件に該当する行を探し、まだ処理されていないものを実行します。

この構成なら、手入力は直後に、ボタン操作は1分以内に後続処理へ進みます。同じ対象を重複処理しないよう、完了済みの印を付ける列も使います。

届かない通知に気づくための設計

6つ目の問題は、プログラム上は成功している一方で、成果だけが受信者へ届かないという状態です。

原因1：受け取る側の参加設定

チャットツール内の非公開スペースへ投稿するときは、通知を送る主体がその場所へ参加していなければ投稿を拒否されます。それでも処理本体が最後まで進み、記録だけ見ると成功に見える場合があります。

そこで当社は、異常時の連絡先を通常の通知先とは別に用意しています。通常の送り先が失敗原因なら、同じ宛先へエラーを送っても確認できないためです。

原因2：接続元による遮断

実際に経験した別の例もあります。承認された下書きを自社サイトで公開する自動化を作った際、Apps Scriptから送った通信がサイトへ到達しませんでした。

調査すると、サイトの防御機能が、通常とは異なる接続元をブロックしていたことが原因でした。コードではなく、通信を送る場所の問題です。

このように相手側の制御で止まるケースは、こちらの実装を修正し続けても解決できません。当社では、処理の担当を次のように分離しました。

• Apps Scriptでは、公開許可の指示を受け付けて待ち行列へ登録するところまで行う
• 手元のパソコンで動く常駐処理が、数分間隔で待ち行列を見に行く
• サイトへの実反映はローカルのパソコンから実施する（許可済みの接続元なので遮断されない）

この分担には追加のメリットがありました。サイト接続用の認証情報をクラウド環境へ保管せずに済みます。秘密情報は手元の環境だけに置けます。

教訓

2例の共通点は、「自分側の処理は完了したのに、受信側の条件で到達しない」ことです。このため、処理の成否表示を確認するだけでは異常を見つけられません。

止まったと気づくための3点セット

ここまでをまとめると、重要な考え方が見えてきます。自動化は一度の成功ではなく、故障を検知できる状態まで整えて初めて完成します。

1：失敗を握りつぶさない

AIが生成したコードには、異常が発生しても記録せず、そのまま先へ進める処理が含まれることがあります。全体は止まらないので、表面上は安定しているように映ります。

しかし運用上、これは非常に危険です。失敗を隠したまま正常に見せてしまうからです。当社ではこの構成を認めず、想定可能なエラーを個別に扱い、必ず内容を記録させます。

2：実行の記録を残す

開始と終了の時刻、対象件数、発生したエラーを記録します。なかでも処理した件数は欠かせない指標です。

対象ゼロのまま成功扱いが続くことが、表面化しない停止でよく見られるからです。エラーではなく、対象を見つけられていないだけの状態です。ファイルの移動や条件変更、権限切れなど原因は複数ありますが、件数の変化を追えば異常を発見できます。

3：気づける場所へ通知する

ログを保存するだけでは十分ではありません。担当者が日常的に確認する場所へ異常を知らせます。

通知には、失敗した処理、発生日時、取るべき次の対応を含めます。対応方法がなければ、受信者は原因調査から始めなければならず、復旧が遅れます。

また先に説明したように、エラー連絡は通常通知とは異なる宛先へ送ります。

この3つは、指示しないと入らない

ここで覚えておきたいのは、単に「自動化して」とAIへ依頼しても、この3要素が自動的に加わるとは限らないことです。

AIはまず、指定された主処理を動かすことへ集中します。運用の安全策は、プロンプトで求めて初めて実装されます。当社では3点を依頼用テンプレートへ組み込みました。定期処理の全体設計は定期実行の記事でも紹介しています。

AIへ依頼するときに渡す4点

手直しを少なくするには、AIへ何を伝えればよいのでしょうか。当社が依頼時に必須としている4項目を説明します。

1：材料の実物

最も大きな効果があるのは、対象表のヘッダーと、内容を示すサンプル1行をそのまま渡すことです。

「取引先を管理する表です」という説明だけでは、AIが列配置を想像するしかありません。実際の形が分かれば推測がなくなり、参照列のずれによる作り直しを避けられます。

ただし、サンプルを共有する前に、顧客名や金額、連絡先などを必ず伏せます。必要なのは列構造なので、値は架空のデータで十分です。共有範囲の判断は情報の扱いの記事で解説しています。

2：失敗したときの動き

途中で異常が出た際、全体を停止するのか、その行を飛ばして最後に報告するのかを指定します。方針を渡さなければ、エラーを表に出さない処理が選ばれやすくなります。

3：頻度と件数

1日1回なのか1分ごとなのか、1度に扱うデータが何件かを伝えます。規模と周期が分かれば、制限時間を見越した構成を最初から提案できます。800件へ増えてから停止に気づくより、初期設計で備えるほうが負担は小さくなります。

4：触ってよい範囲

参照のみ許可する場所と、更新を認める場所を区別します。当社では、書き込み可能な列を具体的に指定する運用です。意図しない変更を防止でき、後からコードを見る人にも設計意図が伝わります。

依頼文の例

以上の情報をまとめると、次のような頼み方になります。

毎朝8時にこの一覧を集計する自動処理を作成してください。列名と、値を伏せた見本の1行を共有します。ステータス列が「完了」のデータのみ集計し、結果は別シートへ出力してください。元データは参照に限定し、変更しないでください。通常は1日50件ほどで、最大200件を想定しています。一部の行でエラーが出ても残りは続け、終了後に失敗内容を一括で知らせてください。ログ用シートへ開始時刻・終了時刻・処理数・エラー詳細を書き、異常がある場合は通知を1件送る構成にしてください。

AIが書きがちな6つの地雷

詳しい依頼を渡しても、生成結果の点検は省けません。当社が何度も見つけ、修正してきた典型的な問題を紹介します。

1：失敗を握りつぶす

先ほど触れた問題です。エラーを捕捉しても記録や通知を行わない処理は残さないようにします。

2：全件を一度に処理する

少量のテストデータに合わせて生成されると、将来の増加や上限が考慮されません。完了済みの印、または各実行の件数制限を必ず設けます。

3：表への読み書きを1行ずつ繰り返す

行単位でサービスを呼び出し続けると、通信回数が増えて処理速度が著しく低下します。データは一括で取得し、一括で反映する構成へ変えます。実行時間の制約にも直接関係するポイントです。

4：認証情報や識別子の直接記述

アクセス用の秘密文字列やファイル識別子を、コード本文へ埋め込む提案が出る場合があります。この書き方は採用しないでください。当社では、秘密情報をコード外の設定領域へ置き、プログラムから設定名で取得する方法に統一しています。

理由は2点です。第一に、コードを共有すると秘密情報まで一緒に渡る危険があります。第二に、履歴管理へ保存した情報は、現在のコードから削除しても過去記録に残るためです。当社はさらに、AIが対象ファイルへアクセスする直前に機械的に遮断する仕組みも利用しています。

5：時刻の扱いが曖昧

日時を扱う自動処理では、基準とする地域の時間が指定されていないケースがあります。深夜処理が前日分へ入ったり、日付が1日ずれたりする原因となり、日次集計では重大な問題になります。

6：手で動かす前提のまま

利用者が画面上で操作することを前提にすると、自動実行へ変更した瞬間に失敗する可能性があります。手動テストだけ成功し、定期処理では動かない場合に疑うべき代表的な原因です。

そして、実行前の確認

6項目とは別に、手動テスト時にも注意が必要です。実行対象として選ぶ処理を間違える事故が起こり得ます。

当社でも、今選んだつもりの処理ではなく、直前まで選択していた別の処理が起動した経験があります。本番用の操作を誤って走らせると元に戻せない場合があります。開始ボタンを押す直前に、選択中の名前を画面で再確認しましょう。基本的な確認ですが、現実に発生するミスです。

設計から異常検知まで、実務で使える自動化づくりを支援します
初回のご相談・お見積りは無料です

無料相談を確認する →

よくある質問

Q. プログラムを書けない人でも作れますか

作成は可能です。ただし、コードの生成と、安定した実運用は異なる段階として考える必要があります。

この記事で紹介した問題の多くは、文法ではなく利用環境や設定に関する知識で解決します。認可の進め方、利用上限、通知が失敗する条件を理解すれば非エンジニアでも対応でき、反対にそれらを知らなければ技術者でも同じ地点で迷います。

Q. 既製の連携口があるのに、なぜ自作するのですか

適している業務が異なるからです。用意済みの連携手段は、AIと対話している間にだけ実行されます。利用者からの指示を起点にする作業なら、それで十分です。

独自構築が必要なのは、人が操作しなくても指定時刻や条件で開始したい仕事です。朝の定期集計や表の変更通知などが該当し、当社では両方式を併用しています。

Q. 実行時間の上限は、Google Workspaceなら緩和されますか

2026年8月18日に確認した公式表では、1回の処理時間は一般・Workspaceの両方で6分／実行です。異なるのは自動処理の合計時間で、一般90分／日、Workspace6時間／日となっています。

この数値は、一部解説と公式情報に差があった項目です。実装前には公式ページを開き、その時点の最新値を必ず確認してください。

Q. 動いていたのに、いつの間にか止まっていました

当社の経験では、主な原因を次のように分類できます。

• 対象ファイルの場所や名前が変わった（見つからないまま処理数ゼロで成功扱いになる）
• 認証の期限切れ、またはアクセス権の変更が起きた
• データ増加により制限時間を超え、途中で終了した
• 受信側の設定変更後、通知が受け付けられなくなった
• 自動実行の設定そのものが削除された

どのケースでも役立つのが、処理件数を継続して保存することです。数の変化を追跡すれば、異常が始まった時点を絞り込めます。

Q. 認証情報はどこに置けばよいですか

プログラム本文へ直接記載してはいけません。Apps Scriptにはコードとは分離して設定を保存できる領域があります。秘密情報はそこへ登録し、処理からは名称を指定して取得します。

ローカルパソコンで実行するものも、専用設定ファイルに保存し、履歴へ入らないよう除外します。当社では加えて、AIが該当ファイルを読む直前に自動でアクセスを止める仕組みを導入しています。

Q. 外部から呼び出される仕組みは、安全に作れますか

制限を理解した設計が前提です。Apps Scriptの受信用入口では通信の付帯情報を取得できず、標準的な署名検証を利用できません。

当社はURLに合言葉を含めていますが、代わりに実行可能な操作を厳しく狭めています。変更できる列と値を限定し、操作者を記録し、元へ戻せない仕事には確認を加えます。外部送信や金額確定は、このルートで扱わない方針です。

Q. どこまで自動化してよいのでしょうか

当社では、後から元に戻せるかを基準にしています。ローカルファイルや社内管理表だけで終わる仕事は、比較的広く自動化できます。一方、外部への連絡、金額や在庫の確定など取り消しが難しい仕事では、最後の確定操作を人に残します。

社外へ出す文面も、当社では自動処理を下書き作成までに限定し、送信は人が担当します。運用上の注意だけに頼らず、自動化側に送信権限を与えない構成で守っています。

まとめ

AIでGoogle Workspaceの自動処理を作る際、完成後に起こりやすい問題を解説しました。重要事項を振り返ります。

• 作業の難しさは、コーディング後へ移っています。AIで実装は速くなり、認可、制限、通知の整備に多くの時間が必要です
• 最初に独自開発の要否を見極めます。人の依頼時だけなら既製連携を使い、無人で定時・条件実行したい場合は自動処理を作ります
• 着手前に公式の制限値を調べます。2026年8月18日時点では1回6分、総時間は一般90分／日・Workspace6時間／日、登録数20、外部通信は一般20,000／日・Workspace100,000／日です
• 第三者の記事だけで数値を決めないことが大切です。実行時間には公式値と異なる説明がありました。設計時は公式情報を直接参照してください
• 承認で進めない場合は、利用者の公開範囲から確認します。社内限定アプリは公式上、検証不要です。管理プロジェクトを変更した後は、接続機能の手動有効化も必要です
• 時間切れには、完了印または件数制限で備えます。初期テストでは見えず、データが増えてから静かに発生する問題です
• 外部起点の処理では通常の署名確認が行えません。合言葉を使う場合は、変更対象と受け付ける値を限定して危険を抑えます
• セル変更の検知は、人による入力だけが対象です。プログラムの書き込みでは始まらないため、定期巡回する処理を組み合わせます
• 正常終了しても通知が届かない場合があります。参加権限や接続元の遮断を疑い、異常通知は通常とは別の宛先へ送ります
• 運用の3点は依頼文へ明記します。エラーを隠さない、実行履歴を残す、確認される場所へ知らせる、という条件です
• AIへ渡す情報は4種類です。値を伏せた実物、異常時の方針、周期とデータ量、変更を許可する範囲を共有します

最初に選ぶなら、毎日成果を確認でき、規模が小さく、実行後も元へ戻せる仕事が適しています。集計を別シートへ出力する処理などが候補です。1本目で3点セットを含む標準形を完成させれば、次の自動化にも同じ設計を展開できます。

当社は法人を対象に、Claude Codeの導入研修と実務支援を行っています。対象業務の選び方から承認設定、上限を考慮した分割方法、停止を検知する運用まで、それぞれの現場に合わせて整理します。稼働中の仕組みの点検や、他部署での実例を参考にした横展開についてもご相談いただけます。初回のご相談とお見積りは無料です。

運用で止まらない自動化を、設計段階から一緒に整えます
ご相談・お見積りは費用なしで承ります

無料相談の詳細を見る →