2026年4月、Google Workspace の監査ログに新しいイベントフィールドが追加され、ログイン・Drive・管理操作の各イベントからより詳細な情報を取得できるようになりました。同時期に Workspace Studio（ワークスペーススタジオ）の Gemini 連携も拡充が続いており、月次監査レポートの自動化を設計する上で「GAS（Google Apps Script）と Workspace Studio Gemini の役割をどう分けるか」という問いを整理する必要が出てきています。
この記事を読んだほうが良い人
- 毎月の GWS 監査レポート（ログイン異常・Drive 外部共有・DLP アラート集計）を GAS スクリプトや手作業でまとめており、自動化の改善を検討している情シス担当者
- Workspace Studio の Gemini 連携機能を月次監査レポートに活用できるか、判断の根拠を探している方
- GAS の属人化スクリプトを整理し、より保守しやすい自動化構成に移行したいと考えている方
月次監査レポート作成の現状
月次監査レポートを作る典型的な流れを整理すると、こうなっています。GAS が Admin SDK（Google が提供する管理者向けの公式 API 群）の Reports API を呼び出し、ログイン失敗・Drive 外部共有変更・DLP アラートの各イベントを取得して Google スプレッドシートに書き出す。担当者がそのシートを目視で確認し、月次サマリーを Docs や PowerPoint にまとめて上長に展開する、という流れです。
2026年4月のログ強化では、リソースの所有者情報フィールドの追加、アクター・リソース属性の拡充（Chrome/Voice/Vault/Assignment ログが対象に追加）、ユーザーデバイス情報フィールドの追加が行われました。ログイン・Drive・管理操作を含む複数のイベント種別が対象になっています。取得できる情報が増えた分、手作業で集計・解釈する作業量も増える傾向にあります。GAS でデータ取得を自動化していても、「集計結果を読んで文章にする」後段の工数は手つかずになりやすく、情シス担当者が月初の数時間をこの作業だけに費やすケースは珍しくありません。
もう一つの問題が属人化です。GAS スクリプトが特定の担当者の My Drive に保存されている場合、その人が異動・退職するとスクリプトへのアクセス権限が失われ、次の担当者が一からコードを読み解く状況になります。「何年か前に誰かが書いたスクリプトが動いているが、誰も仕様を把握していない」という状況は、月次レポートの信頼性に直結するリスクです。
Workspace Studio が普及し始めると「GAS を全部 Studio に置き換えられるのでは」という期待が生まれます。しかしこの期待は設計の前提が少しずれています。Studio は GAS の代替ではなく、担う役割が異なるツールです。ここを整理しておかないと、自動化の設計が途中で行き詰まります。
GAS・Workspace Studio・Gemini ステップの役割を分ける
月次監査レポートの自動化には「取得・集計」「分析・要約」「配信」の3つのレイヤがあります。それぞれに向いているツールを整理すると、以下の通りです。
| レイヤ | 適したツール | 理由 |
|---|---|---|
| ログ取得・集計 | GAS + Admin SDK Reports API | Studio のフローは管理者レポート API への直接接続に対応していない |
| 自然言語要約・ハイライト | Studio 内 Gemini ステップ | 構造化データをテキストサマリーに変換するのは Gemini が得意な処理 |
| 通知・配信 | Workspace Studio フロー | Gmail / Chat / Sheets への出力フローは Studio の得意領域 |
表の最初の行が設計判断の核心です。Workspace Studio のフローは Gmail・Drive・Chat などの Workspace サービスを対象とした自動化を得意としています。一方、管理コンソールの監査ログを取得するための Admin SDK Reports API は、（公式ヘルプの Studio 対応サービス一覧に Admin SDK は含まれていないため）現時点では直接呼び出せるステップとして提供されていません。
なぜ Studio が Admin SDK に接続できないのかという点を補足しておきます。Workspace Studio は Workspace の各エンドユーザーサービス（Gmail、Drive、Chat、Calendar など）を対象とした業務自動化ツールとして設計されており、管理系 API（Admin SDK）は設計スコープ外に位置しています。これはツールの役割分担として意図された設計であり、今後の拡張で変わる可能性はありますが、現時点での設計は「Admin SDK への接続は GAS が担う」という前提で組む必要があります。
「Studio だけで月次監査レポートが完結する」という構成は、現時点では成立しない。これがこの記事での第一の結論です。
GWS 監査ログ自動集計：GAS が担うべき処理
GAS 側が概念的に担うべき処理は3つに整理できます。
- ログ取得: Admin SDK Reports API を通じて対象期間のログインイベント・Drive 共有変更・DLP アラートを取得する
- 集計・整形: イベントを集計し（ログイン失敗件数、外部共有追加件数など）、スプレッドシートの所定シートに書き出す
- スクリプト管理: 属人化を防ぐため、個人の My Drive ではなく共有ドライブ上のスクリプトプロジェクトとして管理する
GAS スクリプトを共有ドライブで管理すると、担当者が替わっても権限を維持できます。Workspace 管理者は共有ドライブの所有権を組織で管理できるため、月次スクリプトの継続運用が担保されます。スクリプトの実行権限も、個人アカウントではなく管理者用の委任済みアカウントまたはサービスアカウントで動かす設計が、長期的な安定運用につながります。
実行タイミングの設計も重要です。月次レポート用のスクリプトは、毎月1日の深夜や翌週営業日の早朝に時刻トリガーで実行するパターンが一般的です。Admin SDK Reports API には呼び出し回数の上限があるため、大規模組織では1回の実行で全イベントをまとめて取得しようとするのではなく、期間を分割して複数回に分けて取得するロジックを検討することを勧めます。
GAS の実行時間には1回あたり最大6分の上限があります。組織規模が大きくなるほどログ件数が増え、この制限に当たる可能性が出てきます。現状の組織規模で GAS の制限に問題なく収まっているなら無理に移行する必要はありませんが、将来の拡張余地として Cloud Run や Cloud Functions への移行を選択肢として把握しておくことが保険になります。
GAS はステップ数の制限がなく、複雑な集計ロジックもコードで記述できるため、データ収集・加工フェーズには引き続き強みがあります。「GAS をなくす」ではなく「GAS が出力したデータを Studio が読む」というパイプライン設計に切り替えることが、現実的な方向性です。
Gemini ステップで対応できること・できないこと
Workspace Studio 内に組み込まれた Gemini 連携ステップ（公式名称: Ask Gemini step。以下「Gemini ステップ」）は、プロンプトでカスタム AI 処理を記述できる機能です（利用には Gemini for Google Workspace へのアクセス権限が必要です）。監査レポートの文脈での対応可否を整理します。
| 対応 | 内容 |
|---|---|
| ○ 可能 | スプレッドシートに書き出したログ集計を自然言語でサマリー化する |
| ○ 可能 | 異常候補の件数をもとに「要確認」「問題なし」の判定文を生成する |
| ○ 可能 | 生成したサマリーを Gmail または Chat に自動送信する |
| △ 要注意 | 「何が異常か」の判定基準が AI に依存するため、再現性・説明責任が担保しにくい |
| × 不可 | Admin SDK Reports API からの直接ログ取得 |
| × 不可 | 複数シート・複数月にまたがるクロス集計（後述する 20 ステップ制限内での実施が困難） |
| × 不可 | 最終的な異常判断の自律実行（監査業務として人間の確認が必須） |
Gemini ステップを使ったサマリー生成では、スプレッドシートから読み込んだ集計数値をプロンプトに組み込み、「先月のログイン失敗件数は前月比で増加しています。特定の時間帯への集中が確認されています」というような自然言語の要約を出力させることができます。プロンプトの設計次第で出力の形式（箇条書き・段落・件数強調など）を制御できるため、報告文書の下書きとして活用する使い方が現実的です。
ただし、Gemini の出力を「監査文書の確定版」として扱うことは推奨できません。理由は2つあります。1つ目は、同じデータでもプロンプトの表現によって出力がばらつくため、再現性が担保しにくいこと。2つ目は、AI が「要確認」と判定した根拠を後から説明する手段がないため、監査証跡として保管した際に「なぜこの件をピックアップしたのか」の説明責任が果たせないケースがあること。Gemini のサマリーは「担当者が確認するための下書き」と位置づけ、最終的な判断と確定版の作成は情シス担当者が行う設計を維持することが、監査業務の信頼性確保に不可欠です。
エディションの事前確認も必須です。 Gemini ステップを利用できる Workspace のエディションは限定されており、全プランで使えるわけではありません。自社の契約エディションで Gemini ステップが利用可能かどうかは、管理コンソールの Workspace Studio 設定または公式の Workspace エディション比較ページで事前に確認してください。設計を進めてから「うちの契約では使えなかった」という状況は避けたい。
ステップ制限を意識した月次フロー設計パターン
公式ヘルプによると、Workspace Studio の1フローあたりのステップ数は最大 20 件です。ユーザー1人あたりの作成可能フロー数は最大 25 件（停止中のフロー含む）です。
月次監査レポートに必要な処理を1フローに詰め込もうとすると、ステップ制限に当たる可能性があります。現実的な対処は「フローを機能単位に分割する」設計です。
以下は分割のイメージです。
- フロー A（ログイン異常レポート）: スケジュールトリガー → スプレッドシートからログイン異常データを読み込む → Gemini ステップでサマリー生成 → Chat に送信（概ね 5〜7 ステップ）
- フロー B（Drive 外部共有チェック）: スケジュールトリガー → スプレッドシートから外部共有データを読み込む → Gemini ステップで要注意件数をハイライト → Gmail で配信（概ね 5〜7 ステップ）
- フロー C（DLP アラート集計）: スケジュールトリガー → スプレッドシートから DLP 集計を読み込む → Gemini ステップで内容要約 → 別シートに転記（概ね 4〜6 ステップ）
各フローを個別に管理することで、ステップ制限に余裕を持たせながら、障害時の切り分けも容易になります。
フローの命名規則と管理台帳を先に決めることを勧めます。 フロー数が増えると「どのフローが月次監査用か」の把握が難しくなります。[月次監査] ログイン異常 [月次監査] Drive外部共有 のように目的がわかるプレフィックスを付けた命名規則を統一し、管理台帳（スプレッドシートや Docs）にトリガー設定・担当者・最終更新日を記録しておくと、後任への引き継ぎが容易になります。
25フロー制限への対応も考慮しておく価値があります。 月次監査専用フローを3〜5本程度作る運用であれば通常は問題になりません。ただし、同じアカウントで他の業務自動化フローも多数作成している場合は、月次監査フローに割り当てられる枠が圧迫される可能性があります。月次監査フローの運用アカウントを分離する（専用の管理者アカウントを設ける）設計が、フロー枠の確保という観点で有効です。
また、管理者は管理コンソールの Workspace Studio 設定から、ステップの種類を OU（組織単位）・グループ単位で制御できます（2026年5月に一般提供済み）。月次レポートフローに必要なステップのみを対象グループに許可するガバナンス設計も、併せて検討する価値があります。
段階的な自動化のロードマップ
現状の環境と工数に応じて、以下の3フェーズで自動化を進めるアプローチが現実的です。一度にすべてを組み上げようとすると、どこで問題が起きたかの切り分けが難しくなります。
フェーズ1：GAS の整備と共有ドライブへの移管
まず GAS スクリプトを個人の My Drive から共有ドライブに移動し、属人化を解消することから始めます。自動実行トリガーを設定し、月初に自動でスプレッドシートへの書き出しが完了する状態を作ります。Workspace Studio を一切使わなくても、この段階だけで月次レポートの安定性は大きく向上します。担当者への依存度を下げることが最初の目標です。
フェーズ2：Workspace Studio で配信フローを追加
GAS が書き出したスプレッドシートを Studio が読み込み、集計結果を Chat や Gmail に自動配信するフローを構築します。フェーズ2では Gemini ステップを使わず、まず「定期的にデータを読んで通知する」仕組みの動作確認を優先します。この段階で Studio の操作感やステップ制限の感覚を掴み、フローの設計を固めます。
フェーズ3：Gemini ステップで要約を追加
フェーズ2の配信フローに Gemini ステップを追加し、集計数値の自然言語サマリーを生成します。プロンプトの設計と出力品質の確認に試行錯誤が伴うため、最初から完成形を求めず2〜3ヶ月かけて改善していく前提で進めることを勧めます。Gemini の出力は「担当者への下書き」として提示し、確定版の送信前に担当者が確認する設計を維持してください。
このロードマップを通じて共通しているのは「GAS が取り、Studio+Gemini が読んで伝え、人間が確認する」という分業構造です。フェーズを分けることでリスクを局所化でき、いずれかのコンポーネントに問題が起きても他のフェーズへの影響を最小限に抑えられます。
5つの問いで設計判断を整理する
月次監査レポートの自動化を設計するときの起点として、以下の5つの問いが使えます。
- 監査ログを直接取得したいか？ → GAS + Admin SDK が必要。Studio だけでは完結しない
- 集計・数値処理が複雑か？ → GAS で整形してから Sheets に書き出す。Studio には整理済みデータを渡す
- 要約・通知を Gemini に任せたいか？ → Studio の Gemini ステップが担える。ただし Gemini for Google Workspace へのアクセスが前提
- ステップ数が 20 を超えそうか？ → フローを機能単位に分割し、GAS 側の処理を増やして Studio のステップ数を抑える
- 異常判断を AI だけに任せていいか？ → 任せない。Gemini は要約担当。最終確認は人間が行う仕組みを維持する
この5つに答えると、自動化設計における GAS と Studio の境界線が自然に決まります。「GAS で取り、Studio+Gemini で読んで伝え、人間が確認する」という分業構造が、現状の機能制約の中での安定した設計パターンです。
なお、Gemini ステップの利用にはエディション確認が前提です（前述のとおり）。
現時点での結論
Workspace Studio の Gemini ステップは「整理されたデータを、自然言語で分かりやすく伝える」作業の自動化に向いています。監査ログの取得・集計という前段は GAS が担い、サマリー生成と配信フローを Studio に担わせる分業設計が、現状で最も保守性が高い構成です。
Studio と GAS を「どちらかを選ぶ」競合関係に置くより、「GAS が作ったデータを Studio が読んで伝える」パイプラインとして捉え直すと、設計の迷いが減ります。この分業構造を一度固めれば、属人化解消と工数削減を同時に進められます。月次監査レポートは毎月発生する定常業務であるため、初期設計への投資は長期的なコスト削減として回収できます。
導入を検討する上での判断ポイントをまとめると、こうなります。現在の GAS スクリプトが個人 My Drive にあるなら、まず共有ドライブへの移管から着手する。その上で Studio による配信フローを追加し、安定稼働を確認してから Gemini ステップの要約機能を段階的に組み込む。どのフェーズでも、Gemini の判断を最終確定とせず、情シス担当者の確認ステップを残しておくことが監査業務としての信頼性を保つ前提条件です。
GWS の機能追加は継続しており、Studio と Admin SDK の連携範囲が今後拡張される可能性はあります。その変化に備えるためにも、現時点での設計を「GAS と Studio の分業」として明確に言語化しておくと、将来の再設計でも判断軸がぶれにくくなります。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。