Google Apps ScriptがWorkspaceコアサービス化　社内自動化の内製はどこまで進められるか

Google Apps ScriptがGoogle WorkspaceのCore Serviceになったことで、社内の小さな自動化は以前より管理対象として扱いやすくなりました。2026年6月23日のGoogle公式発表では、Apps ScriptがCore Serviceとして提供され、データ保護、管理統制、標準テクニカルサポートが他のCore Services同等になると説明されています。

ただし、これは全社員が自由にスクリプトを動かしてよい合図ではありません。経営側が見るべきポイントは、便利になったかどうかより、どの自動化を内製し、どこからレビューを入れるかです。

Google Apps ScriptのCore Service化で何が変わったのか

Google Apps Scriptは、Google Workspaceのアプリを自動化、統合、拡張するクラウドベースのJavaScriptプラットフォームです。Googleの発表では、Apps Scriptが正式にGoogle WorkspaceのCore Serviceとなり、Google Cloud Terms of ServiceやGoogle Workspace for Education Terms of Serviceの対象になると説明されています。

出典: Google Workspace Updates「Google Apps Script is now a Google Workspace core service with enterprise-grade data protection」(英語)

実務上の意味は、Apps Scriptを「個人が便利に使う小技」ではなく「会社が管理する自動化基盤」として扱いやすくなったことです。
とくにGoogle Workspaceを日常業務の中心にしている会社では、管理表の転記、定型メール、通知、承認前チェックのような作業を小さく内製しやすくなります。

一方で、Core Service化は万能の安全保証ではありません。Apps Scriptは会社のファイル、メール、カレンダー、外部APIに触れる可能性があるため、スクリプトが何を読み、誰の権限で、いつ動くかを見ないと危険です。

ここを取り違えると、「便利な自動化」だったものが、いつの間にか止め方の分からない業務処理に変わります。最初に決めるべきなのは、コードの書き方ではなく管理の線引きでしょう。

既に有効な会社は、追加対応不要でも棚卸しは必要

Googleは、既にApps Scriptを有効にしている組織では、管理者とエンドユーザーの追加対応は不要と案内しています。ここで大事なのは、移行作業が不要という話と、社内点検が不要という話を分けることです。

管理者ヘルプでは、Apps Scriptはデフォルトで組織内のすべてのユーザーとゲストにオンとされています。管理者はGoogle管理コンソールのアプリ > Google Workspace > ドライブとドキュメント > Google Apps Scriptから、有効化や無効化を管理できます。

出典: Google Workspace管理者ヘルプ「ユーザーに対してApps Scriptを有効または無効にする」

確認項目	見ること	判断
有効範囲	全社か、組織部門か、アクセスグループか	全社員に必要かを見直す
無効化影響	作成、編集、実行、トリガー、ウェブアプリ、カスタム関数	止める前に業務影響を見る
既存利用	誰がどのスクリプトを使っているか	台帳化して所有者を決める

まずは管理コンソールでApps Scriptの有効範囲を確認し、次に既存のスクリプトを洗い出します。停止してから業務影響に気づく順番だけは避けてください。

社内自動化を内製してよい範囲

Apps Scriptの内製に向くのは、失敗しても戻しやすく、影響範囲が小さい業務です。たとえばスプレッドシートの転記、定型通知、簡単な集計、フォーム回答の整理は、最初の候補にしやすい領域と言えます。

逆に、顧客への自動送信、契約、支払い、個人情報の更新、外部公開が絡む処理は、人の承認を残すべきです。AIにコードを書かせる場合も、コードの見た目ではなく、実行権限と失敗時の戻し方を確認します。

非エンジニアが業務ツールを自作する流れは強くなっています。小さく試す考え方は、非エンジニアでも業務ツールを自作する時代へでも整理しました。

Apps Scriptでも同じで、まず社内向け、次に承認付き、最後に外部連携の順で広げるほうが安全です。
最初から重要業務を完全自動化する必要はありません。小さく動かしてから広げるのが、社内定着の近道です。

業務	内製判断	理由
管理表の転記	内製候補	影響範囲を限定しやすい
社内通知	内製候補	誤送信時の修正が比較的しやすい
顧客送信	承認必須	誤送信の影響が大きい
支払い処理	専門レビュー	取り消しにくく金銭影響がある

権限とトリガーで見るべき3点

Apps Scriptのリスクは、コードの長さよりも権限と自動実行に出ます。Googleサービスを使うスクリプトではOAuth承認やスコープが関わるため、スクリプトが触るデータ範囲を先に見てください。

出典: Google for Developers「Googleサービスの承認」

• オーナー: 誰のアカウントで作成され、誰が保守するか
• スコープ: Gmail、Drive、Sheetsなど、どのデータへアクセスするか
• トリガー: 時間実行、フォーム送信時、編集時など、いつ自動で動くか
• 停止手順: 誤動作時に誰がどこを止めるか

さらに、Apps Scriptにはサービスごとの割り当てや制限があります。大量のメール送信、頻繁な外部API連携、長時間の集計を任せる場合は、「動いたから本番化」では足りません。

上限、エラー通知、手動復旧をセットで見ます。ここを先に決めておくと、担当者が休んだ日や権限変更の日でも慌てずに済むでしょう。

出典: Google for Developers「Googleサービスの割り当て」

この考え方は、生成AI APIの本番運用にも近いものです。上限や退役日を台帳で追う発想は、生成AI APIの本番運用で上限・退役日を見落とさない管理台帳でも扱っています。

Apps Scriptでも、上限、所有者、次回確認日を残すだけで事故の芽を減らせます。コードより先に運用の置き場所を決める、この順番が現場では効きます。

属人化を防ぐ管理台帳を作る

管理台帳は、立派なシステムでなくても始められます。まずはスプレッドシートで、スクリプト名、目的、所有者、触るデータ、トリガー、最終更新日、停止手順を残す形で十分です。

この一覧があるだけで、担当者しか分からない自動化を減らせます。
「あの人のアカウントで動いていた」が退職後に判明する状態は、できるだけ早く解消しましょう。

退職者や異動者のデータ管理は、Apps Scriptにも関係します。GmailやDriveの引き継ぎだけでなく、自動実行しているスクリプトの所有者も確認してください。

Google Workspaceの退職者対応は、Google Workspaceの退職者データ管理でバックアップ漏れを防ぐにはでも整理しています。データ、権限、自動処理は同じタイミングで見るのが安全です。

また、管理者はApps Scriptの使用状況や、ユーザーが許可したデータアクセススコープを監視、取り消し、制限できます。使わせるか止めるかの二択ではなく、見える化して絞るのが現実的です。

出典: Google for Developers「データアクセスの監視と制限」

ログの見方も決めておきましょう。Apps Scriptは一度便利に動き始めると、誰も見なくなりがちです。月次で危険な実行、失敗通知、権限変更を確認する習慣は、生成AIの利用ログ管理で危険リクエストを見える化するの発想と同じです。

Core Service化で安心材料は増えましたが、運用の責任は会社側に残ります。小さく内製し、記録し、危ない処理だけ承認を残す。この形なら、Apps Scriptを社内自動化の現実的な入口にできます。

よくある質問