「経理の担当者が作った承認フローが、承認結果を社外のチャットツールに通知していた」。ノーコードの業務自動化を導入した組織で、半年後くらいに出てくる相談の典型です。作った本人に悪意はなく、むしろ仕事は速くなっています。 問題は、そのフローが社外へ出ていることを誰も把握していなかった点だけです。
こうなると、多くの組織が採る対処は「ノーコード自動化そのものを禁止する」になります。現場が作れなくなり、依頼が情シスに戻り、結局スプレッドシートの手作業に戻る。止める粒度が粗すぎるために、効いていた部分まで一緒に止めてしまう わけです。
Workspace Studio の管理設定に、この粒度を細かくする変更が入ります。
追加されるのは「止め方の細かさ」
Google は Workspace Studio に対して、エンタープライズ向けのセキュリティ制御を追加すると案内しています。管理者側で設定できるようになるのは、次のような制御です。
- フローで使えるステップの種類を個別に無効化する
- Gemini によるデータアクセスを無効化する
- データを外部と共有するステップについて、実行前にエンドユーザーの確認を強制する
- Webhook 連携を無効化する
これらは「Workspace Studio を使わせるか、使わせないか」という組織単位のオン・オフとは別の層にあります。使わせたうえで、外に向かう動作だけを個別に閉じられる というのがこの変更の本質です。
適用時期は、迅速リリースのドメインで 2026年8月20日から（機能が見えるまで最大3日）、計画的リリースのドメインで 2026年9月1日から（同じく最大15日）とされています。自社のテナントがどちらかによって、確認できるタイミングが2週間以上ずれます。
いちばん先に見るのは Webhook
締める順番には理屈があります。データが組織の外へ出るかどうかで、事故の取り返しがつくかどうかが変わる からです。
社内のドライブにファイルを作る、スプレッドシートの行を更新する、社内メンバーにチャットを送る。これらは間違っていても社内で回収できます。一方、Webhook で外部URLへ POST する、外部ユーザーとファイルを共有する。こちらは送信した時点で回収できません。
そのため確認は Webhook から始めます。Workspace Studio の Webhook は、宛先として http:// または https:// を含む完全なURLを指定する仕様で、セキュリティ上の理由から変数を使った動的なURLは指定できず、固定のURLとして保存されます。つまり管理者から見れば、Webhook を使っているフローの宛先は列挙できるはずのもの です。
順序としてはこうなります。
- 現在 Webhook を含むフローが存在するかを洗い出す
- 宛先URLのドメインが、把握している委託先・利用サービスと一致するかを確認する
- 説明のつかない宛先があれば、そのフローの作成者に用途を確認する
- 業務上不要と判断できるなら、組織部門単位で Webhook 連携を無効化する
4番目までいきなり飛ばないほうがよい理由は、すでに業務が Webhook 前提で回っている可能性があるからです。止めた翌日に「通知が来ない」という問い合わせが来て、慌てて戻すという展開はよくあります。
外部共有ステップに「本人確認」を挟む意味
Webhook を止めても、外部とのファイル共有ステップは残ります。ここに使えるのが、外部へデータを共有するステップに対してエンドユーザーの確認を強制する設定です。
この設定が変えているのは、フローの性質を「全自動」から「半自動」へ落とす ことです。禁止でも放任でもない中間の状態を作れます。
実務での効き方は明確で、外部共有が「気づかないうちに起きる」ことがなくなります。フローを作った本人が、実行のたびに外へ出ることを画面で見る。事故の多くは悪意ではなく無自覚から起きるので、無自覚を潰す設定は禁止よりも費用対効果が高い ケースが多いと考えています。
一方で、確認を挟めば当然その分だけ自動化の価値は下がります。夜間に無人で回したいフローには使えません。外部共有を含むフローは自動実行に向かない、という前提を組織で共有する材料 として使うのが現実的です。
Gemini のデータアクセスと DLP は別の層
Gemini によるデータアクセスの無効化も同じ管理画面から設定できますが、これは外向きの制御とは別の軸です。フローの中で Gemini に何を読ませるかという話であり、外部へ出す話ではありません。
さらに、データ損失防止（DLP）による制御も用意されています。Gemini 側の DLP は、コンテンツの条件やラベルにもとづいてドライブのデータへのアクセスを制限します。フロー側の DLP は、参照したデータ・利用したデータ・出力の可視範囲といった条件に応じて、フローの実行そのものをブロックしたり、エンドユーザーによる確認を強制したりする方向で拡張されるとされています。
ここまで来ると、設定できることは十分に細かくなります。逆に言えば、細かすぎて初期設定で全部を詰めようとすると終わりません。 外向きの経路を閉じるところまでを先にやり、DLP による条件付き制御はラベル運用が回り始めてから着手する、という順序を推奨します。ラベルが整備されていない状態で条件を書いても、条件が発火しないだけだからです。
Workspace Studio を組織としてどう位置づけるかという上流の設計はノーコードでAIエージェントが乱立する前にで扱っています。また、Apps Script 側で外部通信をどう抑えるかはURL 許可リストの考え方と共通する部分があります。
次にやること
管理コンソールで Workspace Studio の設定画面を開き、Webhook 連携の項目が表示されているかを確認してください。迅速リリースのドメインなら8月下旬、計画的リリースなら9月中旬までには見えているはずの項目 です。表示されていない場合はロールアウト待ちなので、リリース設定を確認したうえで待ちます。
表示されていたら、無効化する前に、既存フローの棚卸しを先に済ませてください。止めてから探すのではなく、把握してから止める。この順序を逆にすると、業務が止まった状態で調査することになります。
ノーコード自動化の棚卸し、組織部門ごとの許可範囲の設計、外部連携が必要な業務の切り分けについては、グリームハブのIT・Google Workspace 無料相談で承っています。既存フローの本数と業務への組み込み方によって進め方が変わるため、個別にご相談ください。お問い合わせからどうぞ。
Sources
- New enterprise security controls for Workspace Studio enable expanded collaboration use cases — Google Workspace Updates
- Manage access to steps and starters in Workspace Studio — Google Workspace Admin Help
- Webhook を使用してフローを他のサービスに接続する — Workspace Studio ヘルプ
- Control Gemini sources for Workspace Studio flows — Google Workspace Help
- スタートガイド: Workspace Studio の設定に関する管理者向けガイド — Google Workspace Help
