Google Workspace StudioでFlowを作れると知っても、最初に決めるべきことは自動化の内容だけではありません。先に確認したいのは、Flowが何を読めるか、外部に関わるStepでユーザー承認を要求する条件は何か、想定外のとき誰が止めて記録を確認するかです。

この記事の結論は一つです。データ範囲、ユーザー承認の条件、停止・監査の3項目を確認できないFlowは、実データや外部作用へ進めません。Google公式情報を2026年8月23日JSTに確認しましたが、実機Flowは試していません。以下では、公式資料から確認できる機能と、MASTER key側の編集提案を分けて扱います。

まず、告知と自社で使えることを分ける

Googleは2026年8月、Workspace StudioにAgent identities、アクセス管理、監査・observability、管理者設定とhuman-in-the-loop、runtime protectionsを追加すると告知しました。[E1]

ただし、告知されたことと、自社テナントで今すぐ使えることは同じではありません。E1はRapid ReleaseとScheduled Releaseの表示時期を分け、新規Flowへの適用範囲も示しています。E2も、Agent access managementに表示されるのはallowlisted testersが新たに作成したFlowであり、既存Flowは従来どおり動くと説明します。[E1][E2]

また、Workspace Studio本体、外部ユーザーを含むFlowの承認、DLP for Studioでは、対象エディションが同じとは限りません。Business Starterなどの表記だけを見て、DLPまで使えると決めないでください。[E1][E3][E4]

最初に管理者または契約担当へ聞くことは、次の3つです。

  1. 対象エディション、ロールアウト、Studioの表示を満たしているか。
  2. そのFlowが読むデータ、各Stepの読み取り・変更・共有の範囲、管理画面とログの確認場所はどこか。
  3. ユーザー承認を要求する対象Step、実際に確認・承認できる主体と権限・確認場所、停止・制限と監査を担当する管理者は誰か。

Flow所有者、業務レビュー責任者、確認記録を自社で決めることは、Googleが指定する必須の役割分担ではありません。本記事の編集提案です。

1. Flowは何のデータを読むのか

E2によると、新たに作成するFlowは既定で作成者と同じデータアクセス権限を使い、作成者に代わってGoogleデータを読み取り、変更、共有できます。管理者は組織全体または組織部門で既定アクセスを止められ、個別Flowについてもデータアクセスをpauseまたはrestrictできます。[E2]

pauseは進行中・今後の実行を止めます。一方でアクセスをrestrictしたFlowは動作を続けることがあり、期待どおりに動かない可能性があります。制限をかけた事実だけで終えず、状態と実行記録を確認します。[E2]

Geminiを使うStepでは、管理者がWorkspace dataとpublic websitesのどちらを検索対象にできるかを設定できます。どちらも既定で許可されるため、最初の試行で使う範囲を自動的に狭いものと考えないでください。[E2]

確認シートには次を書きます。

  • Flow名または識別子、作成者、Flow所有者
  • データソースと対象Step
  • 読み取り、変更、共有のどこまで含むか
  • 実効アクセス範囲と実行状態を確認する画面・ログ
  • pauseまたはrestrictionを行う管理者と、実行後に見る記録

E1は、新規Flowが最小権限のagent identityと一意の監査可能な識別子で実行される予定を説明します。一方、E2は既定アクセスについて作成者と同じ権限を説明します。これらを、すべてのFlowは作成者の全権限で動く、または常に最小権限で安全に動く、という一つの断定にまとめません。個別Flowの現在の実効範囲は、テナントで確認します。[E1][E2]

2. ユーザー承認は、対象Stepと確認場所を確かめる

E3によると、対象エディションでは、組織外の人を含むWorkspace Studio Flowについて、管理者が機密性のあるStepのユーザー承認を要求できます。[E3]

E4では、DLP for Studioのルールが、参照データ、Step入力、出力を見られる相手などの条件を評価し、block、require user approval、auditを実行する仕組みを説明しています。require user approvalの場合、実行は停止し、ユーザーはWorkspace Studio ApprovalsページでStepを確認・承認してから続行します。選択はログへ記録されます。[E4]

ここで、資料が示さないこともあります。E3とE4はユーザー承認を示しますが、個別テナントで承認者を別の名前付き担当者へ指定または委任できるかは、この4資料から確認できません。したがって、Flowの実行者が必ず承認する、指定した別担当者が必ず承認する、とは書きません。

管理者には次を確認します。

  • Flowに組織外の人を含むStepがあるか。
  • ユーザー承認が必要になる条件と、対象Stepは何か。
  • 実際に誰がどの画面で確認・承認できると表示されるか。
  • その人の権限が不明な場合、誰が保留を判断するか。
  • 業務上別のレビューを置くなら、誰が下書きと確認結果を引き継ぐか。

最後の業務レビューは、Googleの承認設定とは別です。製品上の承認機能と、自社が決める業務責任を同じものとして扱わないために、別欄へ残します。

3. 止める方法と監査を1枚にする

E1は、Studioの設定・実行イベントをStudio audit eventsへ記録し、Drive編集やGmail送信などの監査イベントへFlowの識別子と所有者情報を含める予定を説明しています。E2はAgent access managementでFlowの一覧、データアクセスの変更、pause、再有効化を扱えると説明します。[E1][E2]

E4は、DLPで検査できない範囲も明示しています。たとえば、抽出テキストの分析は先頭10MBまでで、AI Stepへリンクしたresource、URLで渡したDriveファイルやGmailメッセージの内容・分類ラベルなどには制約があります。DLPを、すべてのリンクや出力を確実に検査する機能とは表現しません。[E4]

管理者と次の1枚を作ります。

確認項目 記録する内容
Flowの識別と所有 Flow名または識別子、作成者、Flow所有者
データ範囲 データソース、対象Step、読み取り・変更・共有の別、確認場所
ユーザー承認 対象Step、設定、実際の確認主体・権限・確認場所
業務レビュー 別レビューを置く場合の担当と、引き渡し条件。MASTER key側の運用提案
停止・制限 pauseまたはrestrictionを行う管理者、実行後の確認方法
監査 確認するログ、確認日時、未確認事項
DLP 対象エディション、対象データ、ルール条件、既知の制約

この表はGoogle指定の必須チェックリストではありません。公式資料にある機能と制約を、AI導入初期の中小企業が確認しやすい単位へ翻訳したMASTER key側の編集提案です。

最初の1件は読む・下書き・プレビューに限定する

最小試行は、Googleの安全保証ではなく本記事の提案です。仮想例として、公開済みの製品仕様を読み、要点を下書きにしてプレビューするFlowを考えます。MASTER key株式会社や顧客企業の実施事例ではありません。

試行前に固定する項目 仮想例
入力 公開情報または合成データのみ
Flowの作用 読み取り、下書き、プレビュー
ユーザー承認 必要になるStep、確認主体、権限、確認場所をテナントで確認
人の確認 下書きの根拠と未確認事項を業務レビュー責任者が確認
外部作用 メール送信、外部共有、Drive編集、Webhookを行わない
記録 Flow識別子、所有者、対象データ、設定、確認日時、停止方法
保留条件 範囲、承認主体、権限、確認場所、根拠が不明

顧客情報、従業員情報、個人情報、契約情報、認証情報、営業秘密は初回試行へ入れません。重要判断をFlowへ任せること、自動承認すること、外部へ送信・共有することも対象外です。DLPや承認の設定が見えていても、個別テナントでの表示、契約、権限、ルールの動作を確認できなければ、実データへ進みません。

今回の次の一歩

管理者または契約担当に、次の5項目を確認して1枚に残します。

  1. 対象エディション、ロールアウト、Workspace Studioの表示。
  2. Flow所有者、データソース、各Stepの読み取り・変更・共有の範囲。
  3. 外部ユーザーを含む機密性のあるStep、承認条件、実際の確認主体・権限・確認場所。
  4. pause・restrictionを行う管理者、制限後の状態、監査記録を確認する方法。
  5. 公開・合成データだけで、読み取り・下書き・プレビューに限定できるか。

一つでも答えが出なければ、今回は使わない。特に、承認設定があることだけで、承認主体、承認後の安全性、業務上の責任分界が確定したとは扱いません。これは新機能を安全と断定する記事ではなく、業務にAIを置く前に、アクセス、承認の条件、レビュー、停止、監査の境界を人が決めるための手順です。

参照元