「Googleが、社員みたいに働くAIを出したらしいですね。うちも入れたほうがいいですか」。今週、そう聞かれる担当者の方もいると思います。
先に答えを書きます。今週やるべきことは、導入の判断ではありません。「AIに、社員と同じように身分と権限を渡すとしたら、誰が何を許可するのか」を社内で決めておくことです。 今回の発表で変わったのはモデルの賢さよりも、AIの立場のほうだからです。
2026年10月8日、Google Cloudが年次イベント「Gemini at Work 2026」で、仕事用の汎用エージェント「Gemini agent」を発表しました。出典はこちらです。
お断りしておくと、当社はこのエージェントをまだ触れていません。ここに書くのは、公式発表で確認できたことと、それを法人としてどう読むかだけです。性能や導入効果についての説明は、すべてGoogle自身によるものです。
Googleの説明をそのまま借りると、Gemini agentは「仕事のための、ひとつの汎用エージェント」です。質問への回答、調べものや資料づくりといった知識労働、画像や動画の作成、コードを書いて動かすことまでを、ひとつの入口で引き受けます。
これまでのチャット型のAIと違うのは、次の3点です。
つなげる先も広く書かれています。Gmail・ドライブ・ドキュメントなどのGoogle Workspaceに加えて、Microsoft 365、Slack、Salesforce、ServiceNow、Jira、各種のデータ基盤、そしてMCP（AIを外部ツールにつなぐ共通の規格）に対応したサーバー。使うモデルも、Googleの Gemini だけでなく、AnthropicのClaudeを含めて、仕事ごとに選び分けるとされています。
つまり、「AIに質問する」道具から、「AIに仕事を預ける」仕組みへ、Googleが正面から舵を切った発表です。
発表の中で、法人の担当者にいちばん読んでほしいのはここです。
Gemini agentは、チームの「同僚」として常駐させることができます。その同僚エージェントには、専用のメールアドレス（@agents.自社ドメイン の形）と、専用の保存場所が与えられます。そして、あなたやチームのメンバーが渡した情報にだけアクセスできる、とされています。
さらにGoogleは、すべてのエージェントが自分の身分を持ち、「社員と同じように」管理され、必要最小限の権限で動くと説明しています。エージェントがした操作は監査の記録に残り、それは人ではなくエージェントの行為として記録される、とも書かれています。
これを社内の実務に引き直すと、こうなります。
AIが、アカウントを持つ「もう一人のメンバー」になる。 社員が入社するときには、誰がアカウントを発行するか、どのフォルダを見せるか、辞めたらいつ止めるかを決めますよね。同じことを、AIについても決める必要が出てきます。
ここで起きやすい失敗は、「設定した人の権限をそのままAIに渡す」ことです。部長が自分の権限でエージェントを作れば、そのエージェントは部長が開ける文書をすべて開けてしまうかもしれません。今回の発表は、まさにそれを避けるために「AIには人とは別の身分を」と言っています。この考え方は、当社が先日書いたAIツールに渡すアカウントと権限は、人と同じにしないとそのまま重なります。
Googleは統制の考え方を、4つの問いで整理しています。
| Googleが挙げている問い | 社内で決めること |
|---|---|
| このエージェントは誰か | 誰の申請で作るか。持ち主は誰か |
| 何をしてよいか | どの部署の、どのフォルダ・どのシステムまでつなぐか |
| 何をしたか | 監査の記録を、誰が、いつ見るか |
| 何に触れてはいけないか | 機密区分のどこから先は、AIに開かせないか |
これに対応する道具として、権限を細かく分けて管理者が承認する仕組み、エージェントが外とやりとりする範囲を区切る仕組み、会社のルールをエージェントの通信にまとめて当てる仕組み、プロジェクトごとにAIの利用料の上限を決めて超えたら止める仕組み、などが紹介されています。
道具はそろってきています。ただ、表の右側を埋めるのは、Googleではなく自社です。 右側が空のまま導入すると、道具がいくら整っていても、「誰でも作れて、誰も見ていないエージェント」が社内に増えていきます。部署ごとにAIツールが増えすぎる問題はこちらの記事で書きましたが、エージェントは道具よりも動ける範囲が広いぶん、同じことが起きたときの影響も大きくなります。
公式発表を読んでも、確認できなかったことがあります。法人の判断に直結するものばかりなので、はっきり書いておきます。
つまり、「入れるかどうか」を判断する材料は、まだそろっていません。 ここで慌てて契約を足す理由はありません。
やることは3つです。どれも、エージェントが来る前にしかできない準備です。
1. 「AIに身分を渡すときの申請の流れ」を決めておく。 誰が申請し、誰が承認し、どの範囲をつなぐか。社員のアカウント発行の流れを下敷きにすれば、ゼロから考える必要はありません。最低限、「持ち主がいないエージェントは作らない」「つなぐ範囲は申請書に書く」の2つだけでも決めておくと、後で効いてきます。
2. Workspaceの共有設定を見直しておく。 同僚エージェントは「渡された情報だけ」を見る、と説明されています。ただ、渡す側の社員が、そもそも広すぎる範囲を開けられる状態なら、渡す範囲も広くなりがちです。粗い共有設定は、AIが入る前に直すのがいちばん安く済みます。詳しくはGemini を社内に配る前に決めることにまとめています。
3. 「AIが外に出す一歩」に、人の確認を残すと決めておく。 何日も自分で動くエージェントは、メールを送る、ファイルを共有する、システムの値を書き換える、といった「取り返しのつかない操作」に手が届きます。どの操作の手前で人が確認するかは、エージェントの賢さとは関係なく、自社で決めることです。考え方は承認ゲートの置き方で書いています。
まだ決めなくていいことも書いておきます。
当社は自社のマーケティングを、AIエージェントで運用しています。そこで分かったのは、AIに任せる範囲を決めるのは、AIの性能ではなく「間違えたときに取り返しがつくか」だということです。外に出る直前には、必ず人の承認を挟んでいます。どこに承認を置いているかは私たちの働き方で公開しています。
Gemini agentのような「仕事を預かるAI」が各社から出てくると、差がつくのはどの製品を選んだかではなくなります。AIに身分と権限を渡す手順を、社内で持っているかどうかです。この手順を、自社の業務に合わせて一緒に作りたい場合は、お問い合わせからご相談ください。
※本記事は2026年10月11日時点で、Googleの公式発表で確認できた内容にもとづいています。提供条件や料金は今後変わる可能性があります。最新の情報は上の公式ページでご確認ください。