Google Cloud Next '26は、2026年4月22日から4月24日の3日間、アメリカ・ラスベガスのMandalay Bayにおいて開催されるGoogleのクラウドサービスに関する世界最大級のイベントです。「ディープ ラーニング、刺激的なセッション、共同での問題解決など、充実した 1 週間になることでしょう。業界の専門家や、あなたと同じ課題や機会に直面している同業者から直接学ぶチャンスです。Next 26 を終える頃には、他では得られない斬新なアイデア、最先端のスキル、行動につながる知見を身につけていることでしょう。」と銘打っており、AIコンテンツで大いに盛り上がった昨年や一昨年にも勝るとも劣らないイベントとなることが期待されます。
私たちNTTインテグレーションも、Google Cloudに精通した専門家として、技術イノベーションの最新動向を取り入れ、顧客に対するソリューション提供に活かしていくことを目指して参加しています。
このような貴重な機会ですので、現地からいち早くブログで最新情報や熱量を発信してまいります。
本記事は、Google Workspace Studioの実践ノウハウを100本紹介する連載「Google Workspace Studio活用方法100本ノック」の一つ（番外編）となります。
今回は、Google Cloud Next '26 Las VegasにてWorkspace Studioのセッションがあったのでそのセッションへの参加報告ブログとなります！
Jakob 氏はセッションの冒頭、ドローンの比喩でこの問題を説明しました。
かつてのラジコン飛行機は、物理や機体構造を熟知した一部の愛好家だけが扱えるものでした。彼らは晴れた日に風のない広い野原を選び、リスクを徹底的に管理した上で飛ばしていました。しかし今の子どもはドローンをボタン一つで飛ばし、フリップ飛行まできめます。技術の民主化が進んだ一方で、「環境のリスクは変わっていない」。むしろ、部屋の中をドローンが飛び回るぶん、危険は増した可能性すらあると話しました。
Workspace Studio はまさにそのドローンです。知識ワーカー全員がエージェントを作れるようになった。「誰もが手にした時、それを守る保護者（= 管理者）は何ができるのか」というのがこのセッションの問いです。
具体的なリスクとして挙げられていたのは、アカウントの乗っ取り・侵害、プロンプトインジェクション、インサイダーリスク、意図しないデータの過共有・流出の 4 つです。いずれも「悪意のある行為者」がいなくても起こりえます。たとえばサポートチケットを処理するエージェントが、解決策として機密情報を誤って外部に送信してしまうケースは、誰の悪意もなく発生します。
Sourya 氏はひとつ前のセクションで挙げたリスクに対して「多層防御（Multi-layer Defense）」という考え方で臨むと説明しました。
4 層の構造で、上から Identity（誰がやったかを確実にする）、Studio Controls（管理者による制御）、Abuse Prevention（モデル・アカウントレベルの悪用防止）、Runtime Protections / DLP（実行時のデータ保護）と並んでいます。
「これらが個々に機能するだけでなく、組み合わさることで非常に強固なガードレールになる。フローが実行するアクションは、ユーザーが手動でやるよりむしろ安全になる」と Sourya 氏は述べていました。
フローを作らせる前の段階から制御することができます。GWS の管理者コンソールに、アプリ単位・ステップ単位・サードパーティ単位で細かく制限をかける設定が追加されているので、段階的なロールアウトにも使えます。まず小規模のパイロットグループに展開し、問題がなければ徐々に全体へ広げるという運用に向いているとのことでした。
アカウント乗っ取り防止も追加されます。Google のヒューリスティクスで不審なアカウント状態を検知し、高リスクなフローを作成しようとした場合は再認証を要求します。「ユーザーがカフェで席を外した隙に別の人がノートパソコンを操作してフローを作ってしまう」というシナリオへの対策として紹介されていました。
最も印象的だったのが Human in the loop 機能です。管理者ポリシーで「高リスク」と設定されたアクション（例：外部ユーザーへのメール送信）が発動しようとする直前に、ユーザーに確認通知が届きます。ユーザーは内容を確認してから「送信する」か「キャンセルする」かを選べます。デモでは実際にこの UI が動作する様子が示されていました。
エージェントの帰属表示（Attribution）も導入されます。Workspace 内で何らかのアクションが行われた際に、「これはフローが○○ユーザーの代理で実行した」と分かるラベルが表示されます。人間がやったのかエージェントがやったのかが一目で分かるようになります。管理者ポリシーでオン/オフを切り替え可能とのことです。
実行時の DLP は 3 層構造です。Gemini DLPは Gemini がアクセスできる Workspace データ（メール・チャットなど）を制限します。Studio DLP はフローが扱うコンテンツの機密度と情報の受け取り手を組み合わせたルールで制御します。Resource DLP は既存の DLP ルールを活用し、データが組織外に出ないよう最終ラインで防ぎます。「一つ前の層で見逃されても、次の層が補完する。最後の Resource DLP は、人間が誤って承認してしまったケースですら保護する」と Jakob 氏はまとめていました。
Admin 管理ダッシュボードが追加されます。組織内で動いているすべてのフローを一覧で確認でき、誰が作ったか・何のデータにアクセスしているか・アクティブかどうかを確認できます。フローの一時停止も管理者側から可能です。「ユーザーが休暇中にフローが誤動作してメールを大量送信し続けるが、連絡がつかない」というケースへの対処として挙げられていました。
エンドツーエンドの監査ログも提供されます。フローの設定から実行まで全ステップが記録され、誰の代理で何が行われたかまで追跡できます。API および BigQuery コネクタへのエクスポートも対応予定で、既存のアラートシステムやダッシュボードに組み込めるとのことです。
会場からは実装の詳細に踏み込んだ質問が相次ぎました。
Attribution のサードパーティ対応については、まず第一フェーズはファーストパーティ（Studio 内）のエージェントから始まり、サードパーティへの拡張は計画中とのことでした。フロー停止時のユーザー通知は現状 UI 上のみ（Gmail 等のフローアイコンに赤いドット）で、メール・チャット通知については検討中でフィードバックを集めているとのことです。
エージェントとユーザーの権限分離については、現状はエージェントがユーザーの権限を引き継ぐ設計です。「社内ポリシー文書はユーザーにコピー不可だが、エージェントには読ませたい」といったケースへの対応は検討中だと述べていました。
フロー設定の Admin Console API 対応は現時点で UI 中心です。監査ログの Reporting API 対応はロードマップに入っており、フローのプログラムによる管理も要望として把握しているとのこと。Slack など外部ツールへのアラート通知は現状 Google Chat のみですが、Custom Steps を使えば Slack の Webhook に通知を飛ばす回避策は今でも作れる、というその場のアドバイスが印象的でした。
Workspace Studio 絡みのセッションは全体的に少なく、このセッションには「すでに自社展開を検討している人」が明確に集まっている感じがありました。Q&A の質が高く、「フロー所有者が退職したらどうなるか」「共有フローのバージョン管理は」「管理者が一括デプロイできるか」など、実際の運用を想定した質問が多く出ていました。
デモ中のスライドトラブルには「スライドをオフにしてオンにしたら直りました。テクノロジーってそういうもの」という登壇者の軽口に会場が笑うシーンもあり、雰囲気は和やかでした。機能の完成度より方向性を見せるセッションだったかなと感じました。
Google Cloud、Google Workspaceに関する お問い合わせはこちら
XIMIX®はNTTインテグレーションが所有する登録商標です。（商標登録第６７５５２３４号）