監査ログを追っていて、深夜2時に共有ドライブのファイルが更新されている記録に当たったことはないでしょうか。実行者欄には社員の名前が入っている。本人に確認すると「その時間は寝ていた」と返ってくる。
多くの場合、犯人は侵入者ではなくその社員が半年前に作った自動化フローです。フローはオーナーの権限で動くため、ログ上は本人の操作と見分けが付きません。「誰がやったか」は記録されているのに、「何が実行したか」は記録されていない状態です。
Workspace Studio の管理機能に、この欠けている軸を埋める変更が入ります。ただし、いちばん知っておくべきなのは何ができるかではなく、どこまでが対象なのかのほうです。
実行者欄だけでは、人と自動化を分けられない
自動化フローが起こす事故は、単発の誤操作より厄介です。設定した本人が忘れていても毎日動き続けるうえ、動作としては正規の権限内なので、アラートにも掛かりません。
調査の場面で困るのは、次の切り分けができない点です。
- その操作は人が意図してやったのか、フローが定期実行したのか
- フローだとして、それはどのフローなのか
- そのフローは今も動いているのか、止めたはずのものなのか
監査ログに端末やオーナーの欄が増えた話は監査ログに増えた2つの欄で扱いましたが、そこでも実行の主体が人か自動化かという軸は埋まっていませんでした。
追加されるのは「どのフローが実行したか」
今回の変更で、Google は2つの側から手当てをしています。
1つ目は、監査イベントへのフロー文脈の付与です。 ドライブでのファイル編集や Gmail での送信といった操作の監査イベントに、一意のフロー識別子とオーナーの情報が含まれるようになります。これによって、ログ上で人の操作とフローの実行を切り分けられます。
2つ目は、管理コンソールの Agent access management ダッシュボードです。 ここでは、全フローの一括停止に加えて、個別のフローについて特定の OAuth スコープだけを止められます。 たとえば、あるフローからドライブへのアクセスだけを剥がし、他の動作は残す、といった止め方です。
さらに、セキュリティ調査ツールから監査イベントを起点に Agent access management のページへ直接遷移できます。「怪しい操作を見つけた」から「そのフローを止める」までが1本の線でつながる設計です。
展開時期は、迅速リリースのドメインで2026年8月20日から（機能が見えるまで最大3日）、計画的リリースのドメインで2026年9月1日から（同じく最大15日）とされています。
対象は「これから作るフロー」だけ
ここが本題です。
Agent access management に表示されるのは、展開後に新規作成されたフローです。 既存のフローへの対応は今後とされています。監査ログに付くエージェント文脈も同様で、新規作成されたフローにのみ適用されます。
つまり、冒頭のような「半年前に誰かが作って、今も動いているフロー」は、この機能では追えないし、止められません。
| 新規作成のフロー | 展開前から動いているフロー | |
|---|---|---|
| ダッシュボードでの一覧 | 表示される | 表示されない（今後対応） |
| フロー単位のスコープ停止 | できる | できない |
| 監査ログのフロー識別子 | 付く | 付かない |
この非対称は、実務では厄介な形で効きます。新しく作られたフローほど管理が効き、古くて実態が分からないフローほど管理が効かないという、望ましさと逆の順序になるからです。ダッシュボードを開いて「フローが3件しかない」と見えたとき、それは3件しかないという意味ではありません。
棚卸しの順番
対象範囲が分かると、やることの順番も決まります。
1. 既存フローを人力で洗い出す。 ダッシュボードには出てこないので、ここは Studio 側の一覧と作成者へのヒアリングで埋めます。退職者・異動者がオーナーのフローを優先してください。オーナーが不在のまま動き続けるフローは、止める判断をする人がいない状態です。人ではない ID の棚卸しについてはサービスアカウントの残留も同じ考え方が使えます。
2. 外向きの動作を持つフローから確認する。 Webhook や外部共有を含むフローは、事故が起きたときに回収できません。ステップ種別ごとに止める制御はWorkspace Studioの新管理設定で追加されており、こちらは既存フローにも効きます。追跡は新規フローだけでも、遮断は既存フローにも掛けられるという組み合わせで使うのが現実的です。
洗い出しの実務では、「フローの一覧」よりも「フローが触っているデータ」で並べ替えるほうが判断が速くなります。同じ1本のフローでも、社内スプレッドシートの行を追記するだけのものと、顧客情報を含むファイルを外部と共有するものでは、追えないことの重みがまったく違うからです。前者は追えなくても実害が想像できますが、後者は事故が起きたときに「いつから」「何件」を答えられません。
3. 残すと決めたフローは、作り直すかを検討する。 業務上必要で今後も使い続けるフローなら、展開後に作り直すことで管理と監査の対象に入ります。作り直しのコストと、追えないまま運用し続けるリスクを比べる判断になります。すべてを作り直す必要はなく、外部へ出るもの・機密データに触れるものだけで十分なことがほとんどです。
次にやること
まず、自社のドメインが迅速リリースか計画的リリースかを確認したうえで、展開日を境に「これ以降に作られたフローは管理対象」という線が引かれることをチームで共有してください。 この日付を知らないまま棚卸しを始めると、ダッシュボードの表示件数を実数だと誤読します。
そのうえで、オーナーが退職・異動している既存フローを最優先で洗い出してください。 止めるにせよ作り直すにせよ、判断できる人がいるうちに手を付けるほうが安く済みます。
Google Workspace の自動化フローの棚卸し、監査ログを使った調査体制の整備、ノーコード自動化のガバナンス設計については、グリームハブの IT・Google Workspace 無料相談で承っています。フローの本数と業務への組み込み具合によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- New enterprise security controls for Workspace Studio enable expanded collaboration use cases — Google Workspace Updates
- Securely manage AI and agent access to Workspace data with the AI control center — Google Workspace Updates
- Now available: Create AI agents to automate work with Google Workspace Studio — Google Workspace Updates
- OAuth log events — Google Workspace Admin Help
