homula2026年10月8日、Google Cloud は年次イベント「Gemini at Work 2026」で、単一の万能エージェント「Gemini agent」 を発表しました（Google Cloud 公式ブログ・Thomas Kurian CEO 基調講演より）。質問への回答からナレッジワーク、資料作成、コーディングまでを「1つのプロンプト窓」から実行する——という発表自体も大きいのですが、日本企業の経営・IT・情報セキュリティ部門が本当に注目すべきは、その裏にあるもう一つの発表です。
それは、エージェントが 自分専用の社員メールアドレス（@agents.company.com）・カレンダー・Drive・社内ディレクトリ上の存在を持つ「同僚エージェント（coworker agent）」 になる、という設計思想です（TechCrunch・2026年10月8日）。これは「賢いアシスタントが1つ増えた」話ではありません。エージェントを、入社し・権限を持ち・仕事の記録が残る『社員』のように扱い始めたという、統制設計上の転換点です。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の「PoCから本番・全社へ」を日々支援しています。本稿では、Google の発表を追いかけるだけでなく、「エージェントが社員になる」とは統制上どういう意味か、そして日本企業がベンダーを問わず引いておくべき設計線を整理します。
「Gemini agent」とは何か——部門別エージェントを1つに束ねる
まず、発表の骨格を押さえます。Google は従来、用途ごとに複数のエージェント体験を提供してきましたが、今回それらを 「あなたの、単一で万能な仕事用エージェント（your new single, universal agent for work）」 に集約しました。要点は次の通りです（出典はいずれも公式ブログ）。
- 指示ではなく目的を渡す：「Work now starts in the prompt window（仕事はプロンプト窓から始まる）」として、利用者は手順ではなく**目的（objectives）**を渡し、完成物を受け取る。
- 常駐して走り続ける：クラウド上で実行され、ノートPCを閉じても数時間〜数日かかる仕事を継続する。Web・iOS・Android・デスクトップ・コマンドライン・Workspace・Microsoft 365・Slack などから同じ記憶・文脈で呼び出せる。
- モデルは仕事ごとに選ぶ：各ジョブを最適なモデルに振り分ける。現時点で Google の Gemini 系モデルに加え、Anthropic の Claude 系モデルも選択可能とされ、将来はさらに他のモデルも加えると明記された。
- 標準で外部につながる：Confluence・Microsoft Office・Teams・Slack・Jira・Salesforce・ServiceNow・BigQuery・Snowflake、そして任意の MCP サーバーに接続する。
ここまでは、私たちが以前「スーパーエージェント」として整理した「乱立したエージェントを単一の入口へ束ねる」潮流の、最大手による製品化と見ることができます。注目すべきは、Google がこれを**「統合 × オーケストレーション × 統制」を一体で持つ基盤**として打ち出した点です。特に3つ目——統制——が今回大きく踏み込みました。
最大の転換点——エージェントが「同僚」になる
Gemini agent は、一度きりのタスクをこなす「ツール」としてだけでなく、役割を持って働き続ける「同僚エージェント（coworker agent）」 としても振る舞います。発表によれば、同僚エージェントは次のような専用の身分を与えられます。
- 自分専用の
@agents.company.comメールアドレス と永続的なストレージ。 - メール・カレンダー・Drive を備えた Workspace アカウントと、社内ディレクトリ上の存在。
- 同僚は、Chat スペースに追加したり
@メンションしたり、ドキュメントのコメントで指名したりして依頼する。編集履歴にはそのエージェント自身の名前で記録が残る。 - そして決定的に、「利用者の身分ではなく、エージェント自身の身分で動き、共有された範囲しか見ない」。
これは「AIが人間になる」という話ではありません。重要なのは身分の帰属先です。従来、多くのエージェントは「それを起動した人間の権限」や「共有サービスアカウント」で動いていました。同僚エージェントは自分の名前で動き、自分の名前でログが残る。つまり「誰がやったのか分からないAIの作業」が、原理的に「どのエージェントがやったか」に紐づくようになります。
この設計は、私たちが「AIエージェントに“それ専用のID”を」で論じた非人間ID（NHI）と最小権限の考え方を、大手がそのまま製品の前提に据えたものです。便利さの裏返しとして、「社員を1人雇うときと同じ問い」がそのままエージェントにも必要になります。
「同僚」を迎えるなら、人事と同じ問いが要る
Google は今回、ガバナンスを4つの問いに整理しました。**「そのエージェントは誰か／何をしてよいか／何をしたか／決して触れてはならないものは何か」**です。発表された統制機能を、この4つに対応づけると次のように読めます。
| 問い | Google が示した仕組み | 企業側で設計すべきこと |
|---|---|---|
| 誰か（Identity） | 各エージェントに暗号学的に証明される固有IDを付与。ログや起動したVMにも刻印される | 「どのエージェントを、誰の責任で、いつ作るか」の発行・承認プロセス |
| 何をしてよいか（Authorization） | 管理者が承認するロールベースの細粒度権限。外部接続へは OAuth 等で身分を伝播 | 業務に必要な最小権限の設計。過剰権限の棚卸し |
| 何をしたか（Audit） | すべての操作を、人ではなくエージェントに帰属する監査証跡へ記録。リアルタイム監視も可能 | 自社の保持期間・証跡要件との整合。横断的な突合 |
| 触れてはならないもの（Policy） | Agent Sandbox（専用ネットワーク境界）内で実行し、全通信を Agent Gateway＝「AIネットワーク・ファイアウォール」が通過。例：「“Need to Know”区分の文書は開かせない」 | データ区分・DLP ポリシーの定義と、適用範囲の設計 |
加えて見逃せないのがコスト統制です。Cloud Billing Console で**プロジェクト単位のリアルタイム上限（spend caps）**を設定でき、上限に達するとエージェントが一時停止、ワンクリックで再開できるとされています。トークン消費とサンドボックス費用をプロジェクト単位で追えるため、部門別のチャージバックにも使えます。これは、私たちが「トークン浪費は終わった」で指摘した「使い方の統制」が、課金基盤の既定機能として降りてきたことを意味します。
「同僚エージェント」を迎えることは、**入社・権限付与・そして退職（オフボーディング）**の設計を迫ります。自分のメールと権限を持つエージェントを作るのは簡単でも、役割が終わったときに確実に権限を剥奪し、資産を回収する手順がなければ、やがて「誰も管理していない、権限だけ持った元・同僚」が社内に積み上がります。発行と同じ重さで、停止・削除のプロセスを最初から設計してください。
日本企業にとっての意味——「乗るか・束ねるか」を分けて考える
Google の発表には、日本企業の事例も具体的な数字とともに並びました。Googleの発表によれば、SOMPO は1万以上のカスタムエージェントを構築しモデル開発を1週間から1日へ短縮、NTT DOCOMO は年間45万時間を創出、日立（Hitachi）は最大30%の生産性向上、といった成果が示されています（いずれも公式ブログ。ベンダー公表値のため、自社適用時は条件の確認が前提です）。業種特化版は金融サービスと法務がプレビュー、政府・ヘルスケア・小売が今後とされています。
一方で、冷静に線を引くべき点もあります。
- 「万能な1つのエージェント」への集約は、便益と同じだけブラスト半径を広げる。メール・ドライブ・基幹データに同じ身分で届くエージェントは、1つの入口が突破されれば被害範囲が最大化します。だからこそ Google 自身が Sandbox・Gateway・監査を前面に出したわけで、統制は後付けではなく初日からの前提です（Futurum による分析も、識別情報・権限・監査・サンドボックス・ゲートウェイを一体で論じています）。
- モデル選択の自由は、ロックイン回避の鍵。Gemini agent が Claude も選べ、MCP に対応することは、「入口は選び、裏側は標準で束ねる」という設計を取りやすくします。日本企業の多くは SAP・Salesforce・ServiceNow・kintone・独自基幹系が混在するため、接続と統制の土台をベンダー中立の標準（MCP 等）で持っておく価値は変わりません。
- 提供時期・課金・権限の細部は未確定な部分がある。プレビュー段階の機能も多く、同僚エージェントの権限継承やサブエージェントのライフサイクルなど、公開情報だけでは詰め切れない論点が残ります。本番適用は、自社のデータ区分・監査要件に照らした検証が前提です。
homula の観点——「どのエージェントに乗るか」より「土台をどう持つか」
今回の発表が示すのは、エージェントを社員のように扱う時代には、人事・IT・セキュリティが持っていた統制の型が、そのままエージェントにも必要になるという現実です。身分の発行、最小権限、監査、停止、そして費用の上限——これらは特定ベンダーの機能名ではなく、どの基盤を選んでも企業側が設計し続ける責務です。
homula は、この土台づくりを一気通貫で支援します。MCP を活用したエンタープライズ向け統合プラットフォーム Agens は、200以上のツールと構築ゼロで接続し、「入口は選び、裏側は標準で束ねる」構成を取りやすくします。そのうえで Agens Control が、承認フロー・DLP・5年分の監査ログ・RBAC を提供し、本稿の4つの問い（誰か／何をしてよいか／何をしたか／触れてはならないもの）に、ベンダー横断で答えられる状態を作ります。
進め方としては、最初から「万能な1体」を全社に配るのではなく、(1) 守るべきデータ区分と権限の棚卸し → (2) 身分・承認・監査の土台を敷く → (3) 1業務で同僚エージェントを試し、停止・削除まで含めて検証 → (4) 横展開、という順序を推奨します。大手の製品力は「乗る」価値がありますが、乗る先がどこであっても壊れない統制を自社側に持つことが、本番・全社への分岐点になります。
まとめ
2026年10月の Gemini agent 発表が示したのは、エンタープライズAIの焦点が 「どれだけ賢いか」から「同僚として、どう迎え・どう統べるか」へ 移ったという事実です。要点は3つです。
- 身分が主役になった：エージェントが自分のメール・社員ID・暗号学的IDを持ち、自分の名前で動き、自分の名前でログが残る。「誰がやったか分からないAI作業」が原理的に減る一方、発行・権限・停止の設計責任が増す。
- 統制は初日からの前提：単一の万能エージェントは便益とブラスト半径を同時に広げる。Sandbox・Gateway・監査・リアルタイムの費用上限は、後付けではなく設計の起点。
- 土台はベンダー中立で持つ：モデル選択の自由と MCP 対応は、ロックインを避け「入口は選び、裏側は標準で束ねる」ための鍵。どの基盤に乗っても、身分・承認・監査・費用の統制は自社が設計し続ける。
「どのエージェントに乗るか」の議論を、「同僚を迎える準備ができているか」へ一段引き上げること。それが、AIエージェントを本番と全社へ、そして説明責任を伴う運用へと運ぶための次の一歩です。
エージェントを「社員のように」迎える統制——身分・承認・監査・費用の上限を、ベンダーを問わず自社の土台として持ちたい。そんな段階に来た企業のために、homula は接続・承認・監査の設計から、同僚エージェントの試行と内製化までを一気通貫で支援します。