「うちの現場、それぞれが勝手にAIエージェントを作り始めたんですが、誰が何を動かしているのか、もう把握できていません」——ここ最近、Google Workspace を使う中堅企業からこの種の相談が増えました。きっかけは、ノーコードで業務自動化エージェントを組める Google Workspace Studio が誰でも触れるようになったことです。便利な反面、IT 担当者の見えないところで「受信メールを勝手に振り分けて外部に転送するエージェント」のようなものが量産されかねない。動いてはいるが、止め方も中身も誰も説明できない——少し前まで野良マクロや野良 GAS が抱えていた問題が、今度はエージェントという単位で再来しようとしています。
Workspace Studio は、Gmail・ドライブ・スプレッドシート・Google Chat といった日常的に使うアプリを横断して動くエージェントを、プログラミングなしで作れるプラットフォームです。2025 年 12 月に一般提供が始まり、Gemini 3 を土台に「自分宛ての質問を含むメールに返信用ラベルを付け、Chat で自分に通知する」といった要件を自然文で指示するだけで、必要なステップを自動で組み立ててくれます。2 ステップ程度の小さな自動化から 20 ステップ規模の複雑なワークフローまで、同じ仕組みで作って配れる。だからこそ、「作れる人」が一気に増えたいま、受託の役割は『代わりに作ること』から『安全に作って回せる土台を整えること』へ移っています。本記事では、Workspace Studio を業務に入れるとき、どこで事故が起き、受託でどう統制を設計するかを整理します。
「自然文で作れる」が、なぜ運用を難しくするのか
Workspace Studio の魅力は、要件を言葉で書けばエージェントが組み上がる手軽さにあります。ところがこの手軽さが、運用面では逆向きに効きます。
第一に、作った本人しか意図を知らない状態が生まれます。自然文の指示から Gemini が自動でステップを設計するため、出来上がったエージェントの中身（どのデータを読み、どこへ書き、何を外へ送るか）を、作った当人すら正確に把握していないことがあります。「便利だから作った」エージェントが、実は社外ドメインへ添付ファイルを転送していた、という事故は容易に起こります。
第二に、権限がエージェントに引き継がれることの怖さです。エージェントは作成者やそれを使う人の権限で動きます。つまり、強い権限を持つ担当者が軽い気持ちで作ったエージェントは、その担当者と同じ範囲のファイルやメールに触れてしまう。誰が作ったかによって、同じ見た目のエージェントの「届く範囲」がまったく変わるのです。
第三に、数が増えると棚卸しが効かなくなる。一人が複数のエージェントを抱え、部署ごとに似て非なる自動化が乱立すると、半年後には「誰が・何のために・何を動かしているか」の一覧すら作れなくなります。これは Google Workspace CLI で情シス運用を自動化する記事 で扱った「目視の棚卸しが頻度負けする」問題と、根は同じです。
受託が入ると何が変わるのか
ここで受託の出番になります。やることは派手な開発ではなく、「現場が自分で作れる」状態を保ったまま、その周りに崩れない枠を用意することです。
一つは、作ってよいエージェントの線引きを先に決めることです。社外への送信を伴うもの、個人情報や請求情報を読むもの、お金の処理に関わるものは、現場が単独で本番に出さず、IT 側のレビューを通す。逆に、自分の受信トレイ内でラベルを整理するだけのような閉じた自動化は、現場が自由に作ってよい。この「自由にしてよい範囲」と「承認を要する範囲」の地図を最初に引くだけで、事故の大半は防げます。エージェント統制をどこで掛けるかという全体像は、Google Workspace AI コントロールセンターの記事 で扱った考え方とつながります。
もう一つは、作成者の権限ではなく、専用の最小権限で動かす設計です。重要な業務を担うエージェントは、強い権限を持つ個人にひもづけたままにせず、必要なデータだけに触れる専用アカウントへ寄せる。退職や異動で止まらないようにし、漏えい時の被害範囲も限定します。社内ナレッジを横断して扱う用途では、NotebookLM と Workspace Studio で社内 RAG を構築する記事 のように、何を学習・参照させてよいかの線引きまで含めて設計する必要があります。
| 観点 | 現場が単独で作る場合 | 受託で枠を整えた場合 |
|---|---|---|
| 中身の把握 | 作った本人すら曖昧 | 目的・データ範囲を台帳化 |
| 権限 | 作成者の権限で動く | 用途ごとに最小権限を分離 |
| 社外送信・課金処理 | 無防備に通る | 承認フローを必須化 |
| 退職・異動 | 動いていたものが突然止まる | 専用アカウントで継続 |
| 棚卸し | 半年で把握不能 | 一覧と停止手順を整備 |
表のとおり、受託が足すのは機能ではなく「見える化」と「止められる仕組み」です。これがあるかないかで、半年後の運用しやすさがまるで変わります。
弊社の事例: 「便利な自動化」が監査で引っかかったとき
具体例を挙げます。ある人材系の中堅企業（社名は伏せます）から、「現場が Workspace Studio で作った自動化が便利すぎて全社に広がったが、取引先からセキュリティ監査を求められて困っている」という相談を受けました。問題のエージェントは、応募者から届くメールの添付書類を自動で読み取り、要点を抽出してスプレッドシートに転記し、担当者の Chat に通知する、というものでした。現場にとっては手放せない時短ツールです。
ところが中身を一緒に確認すると、いくつも気になる点が出てきました。読み取り対象に応募者の個人情報がそのまま含まれ、その転記先スプレッドシートが「リンクを知っている全員」に共有されたままだったこと。エージェントが作成者である一人の担当者の権限で動いており、その人が見られる範囲のメールすべてに技術的には触れ得たこと。そして、誰がいつこのエージェントを作り、どんなデータを扱っているかを示す記録が、どこにも残っていなかったことです。便利に動いていたぶん、誰も中身を点検しないまま全社に広がっていました。
私たちが行ったのは、自動化を止めることではありませんでした。転記先の共有範囲を必要な担当者だけに絞り、エージェントを個人の権限から切り離して応募管理用の最小権限アカウントへ移し、「どのエージェントが・誰の発案で・どのデータを・どこへ書くか」を一覧化した台帳を整え、社外送信を伴う処理だけは IT 側の承認を挟む形に変えました。現場の使い勝手はほぼ保ったまま、監査で説明できる状態へ作り直したわけです。担当者が「便利だから」と作ったものを、「説明できるから安心して使える」ものに変えた、と言ってもいい。
この案件が示すのは、Workspace Studio の難所が「エージェントを作ること」ではなく、作られたエージェントを誰がどう統制し、止められる状態に保つかにある、ということです。作る難易度が下がったぶん、統制の重みが相対的に増しています。
導入を検討する前に握っておきたいこと
これから Workspace Studio を本格的に使うなら、最初に二つだけ決めておくと後が楽になります。
一つは、「自由に作ってよい範囲」を明文化すること。閉じた個人作業の自動化は現場に任せ、社外送信・個人情報・課金に触れるものは承認を通す。この線引きを先に共有するだけで、野良エージェントの暴走は大きく減ります。もう一つは、重要なエージェントを個人の権限に依存させないこと。専用の最小権限アカウントへ寄せておけば、退職・異動で止まらず、監査でも説明しやすくなります。
現場の自動化が便利に広がってきたが統制が追いついていない、取引先の監査に向けてエージェントの棚卸しと安全化を進めたい、Workspace Studio を全社に展開する前に崩れない土台を作っておきたい——そうしたご相談があれば、グリームハブのお問い合わせからお声がけください。現状のエージェントと共有設定を拝見し、止めるべきもの・直すべきもの・任せてよいものを一緒に仕分けしたうえで、現場の使い勝手を保ったまま安全に回る形へ設計し直します。
