Google Cloudは2026年10月8日、企業向けイベント「Gemini at Work 2026」で、さまざまな業務をまとめて任せられるAIエージェント「Gemini agent」を発表した。質問への回答だけでなく、資料作成やコードの実行まで対応し、仕事の内容に応じてGoogleのGeminiやAnthropicのClaudeを使い分ける。さらに、チームで働くエージェントには専用のメールアドレスやカレンダーを持たせ、人間の社員と同じように仕事を依頼できる仕組みも構想している。長期記憶や数日間にわたる自律実行は、すでにGoogleの企業向けAI基盤で実現されていた。今回の発表で注目されるのは、こうした機能を日常業務に組み込み、AIエージェントが継続的に役割を担う「同僚」として働けるようにする点だ。
長時間の自律実行は既存技術、今回の焦点は業務との連携
Googleは2026年4月のCloud Nextで、Vertex AIを発展させた「Gemini Enterprise Agent Platform」を発表していた。
これは、開発者がAIエージェントを構築・実行し、アクセス権限や活動状況を管理するための基盤だ。従業員が利用するGemini Enterpriseアプリは、この基盤を通じて社内データや外部サービスと連携する。
長時間にわたるタスクの実行環境や、会話をまたいで利用者の好みや過去のやり取りを記憶する仕組みも、この時点ですでに紹介されていた。
Googleの公式発表を時系列で振り返ると、長期記憶と実行基盤は4月、最大7日間の連続実行は7月、費用の上限設定は8月、Google Workspaceの複数アプリをまたぐ操作は9月に発表されている。
今回の発表では、それらの機能を組み合わせ、個人のさまざまな仕事を引き受けるエージェントと、チーム内で継続的な役割を担うエージェントへと発展させる方針が示された。
| 発表日 | 発表された機能・利用方法 | 今回の発表との関係 |
|---|---|---|
| 4月22日 | 長時間のタスク実行、Memory Bank、エージェントのID管理と統制 | 継続的に業務を遂行するための基盤を整備 |
| 7月29日 | Agent Runtimeで最大7日間の連続実行、記憶・ID管理機能の提供拡大 | 数日間にわたる自律実行は既存の基盤で対応 |
| 8月26日 | プロジェクト単位の月額支出上限、API呼び出しの一時停止・再開 | 自律実行に伴う費用を管理する仕組み |
| 9月9日 | Workspaceの各アプリから、別のアプリの資料や表を作成 | アプリを切り替えずに業務を依頼できる仕組み |
| 10月8日 | 複数モデルを利用するGemini agent、専用Workspaceアカウントを持つ同僚エージェント | 業務の文脈と役割を維持しながら、継続的に仕事を任せる構想 |
※Googleの公式発表を時系列で整理したもの。各機能は提供段階や対象製品が異なるため、同じ製品の機能追加や一般提供への移行を示す一覧ではない。また、7月に発表された「最大7日間」という実行時間が、新しいGemini agentにもそのまま適用されるとは限らない。
9月のWorkspace関連の発表では、Google Chatの会話を基にGoogle Slidesの資料を作成したり、Gmailの長いやり取りを要約してGoogle Docsにまとめたりする機能が紹介されていた。
Google Docsからメールの下書きを作成し、利用者が内容を確認してから送信する使い方も示されている。
つまり、GoogleのAIエージェントは、すでに複数のアプリを横断して成果物を作成できる段階に達していた。
10月の発表では、こうした業務を担うエージェントに、モデルの選択機能や記憶、チーム内での役割を持たせることで、単発の作業だけでなく、継続的な仕事を任せられるようにする構想が示された。
Gemini agentは、AnthropicのClaudeも使い分ける
今回発表されたGemini agentは、その名前とは異なり、GoogleのGeminiモデルだけを使う仕組みではない。
Googleは、仕事を実行するエージェントと、その内部で推論を担うAIモデルを別々の要素として設計している。現時点ではGeminiとClaudeに対応し、将来的には他社の非公開モデルやオープンモデルにも対応する方針だ。
この設計には、企業が蓄積した業務知識や作業環境を、AIモデルの更新に合わせて毎回作り直さなくて済むようにする狙いがある。
例えば、ある仕事ではGeminiを利用し、別の仕事ではClaudeを選択しても、エージェントが利用する社内システムとの接続設定やスキル、業務の文脈は維持される。
AIモデルの性能競争が続くなか、企業が特定のモデルに業務環境全体を依存させずに済むようにする仕組みだ。
こうした業務環境を支えるのが、「ツール」と「スキル」である。
ツールは、エージェントが業務システムに接続して情報を取得したり、操作を実行したりするための手段だ。一方、スキルは、特定の業務に必要な指示や知識、作業手順を再利用できるようにまとめたものを指す。
Googleは、外部システムと接続するためのModel Context Protocol（MCP）にも対応し、企業内で共有するツールやスキルを登録できるとしている。
どれほど高性能なAIモデルでも、必要な社内資料にアクセスできなければ、適切な回答や成果物を作ることは難しい。
また、社内で使われる指標の定義や承認手続きを理解しているかどうかによっても、完成した資料や分析結果の実用性は変わってくる。
そのため、AIモデルを柔軟に切り替えられるようになるほど、モデルとは独立して業務知識や接続設定を維持できる仕組みの重要性が高まる。
ただし、今回の発表では、GeminiとClaudeをどのような基準で選択するのか、モデルの使い分けによって品質や費用がどの程度改善するのかといった詳細は明らかにされていない。
また、Claudeに対応しているからといって、Gemini agentの業務環境をGoogle Cloud以外の基盤へそのまま移行できるわけではない。
利用するAIモデルを変更できることと、エージェントの実行基盤そのものを自由に移行できることは、区別して考える必要がある。
4種類の記憶で、アプリをまたぐ仕事を引き継ぐ
Googleが説明するGemini agentはクラウド上で動作し、利用する端末やアプリが変わっても、同じ記憶や業務の文脈を引き継げるように設計されている。
ノートPCを閉じた後も、数時間から数日かかる仕事を継続できるという。
そのために用意されているのが、役割の異なる4種類の記憶だ。
| 記憶の種類 | 保存・参照する情報 |
|---|---|
| 作業中の記憶 | 現在進めている仕事の内容や、その途中で得られた文脈 |
| 知識の記憶 | 文書や人とのやり取りから得た、構造化された知識 |
| 手順の記憶 | 業務の進め方や、エージェント自身が作成したスキル |
| 実行履歴の記憶 | 過去に実行した仕事や、その経験 |
この分類で重要なのは、単に長い会話を記憶するだけでなく、過去に得た知識や経験を次の仕事に活用できるようにしていることだ。
例えば、進行中の仕事で決まった方針や修正内容を引き継ぐには、作業中の記憶が役立つ。
一方、いつも仕事を依頼している担当者を見つけたり、社内で決められた手順に沿って作業を進めたりするには、蓄積された知識や手順も必要になる。
つまり、記憶の役割が、会話を継続するためのものから、業務そのものを継続するためのものへと広がっている。
Googleは今回の発表で、利用者が「来週、いつもの地域イベント担当者との会議を設定して」と依頼する例を紹介した。
エージェントはGoogle Chatのスペースに参加しているメンバーや、過去のイベントに関する会話履歴から担当者を特定する。
そのうえでカレンダーの予定を確認し、社外の参加者も含めてメールで日程を調整するという。
これまでなら、利用者が担当者の名前やメールアドレスを調べ、必要な情報をその都度AIに伝える必要があった。記憶を活用することで、そうした手間を減らせる可能性がある。
ただし、過去の情報を記憶していることと、その情報が現在も正しいことは別の問題だ。
担当者が異動したり、社内の業務手順が変更されたりすれば、以前の記憶がそのまま使えるとは限らない。
エージェントが自ら作成したスキルについても、誤った手順を保存してしまえば、同じ間違いを繰り返す可能性がある。
今回の発表では、記憶の保存期間や削除方法、エージェントが作成したスキルの検証方法について、詳しい説明は示されていない。
継続的に業務を任せるには、記憶を増やすだけでなく、情報を適切に更新し、古くなった知識や誤った手順を修正できることも重要になる。
専用アカウントを持つAIの「同僚」は、誰の権限で働くのか
今回の発表でもう一つ注目されるのが、チームの一員として働く「同僚エージェント」という構想だ。
このエージェントには専用のGoogle Workspaceアカウントが与えられ、メールアドレスやカレンダー、Google Driveを利用できるようになる。
社内のユーザーディレクトリにも表示されるため、従業員は人間の同僚と同じように、Google Chatのスペースへ招待したり、文書のコメントで名前を指定して仕事を依頼したりできる。
エージェントが文書の編集を提案した場合には、そのエージェントの名前で変更履歴が記録されるという。
これは、特定の作業を一時的に分担する「サブエージェント」とは異なる。
サブエージェントは、ある仕事を効率よく進めるために必要な処理を分担する存在だ。
一方、同僚エージェントは、継続的な役割と専用の作業領域を持つ。プロジェクトの進行管理や部門のデータ分析など、一定の担当業務を持つ社員に近い位置づけになる。
ただし、AIエージェントに専用アカウントを持たせる場合、重要になるのがアクセス権限の管理だ。
Googleによると、同僚エージェントは仕事を依頼した利用者のIDではなく、自分自身のIDを使って動作する。
また、チーム内で共有された情報だけにアクセスできるようにするという。
個人向けエージェントが利用者本人の幅広い業務を理解するのに対し、同僚エージェントはチームで共有する情報の範囲にアクセスを限定する設計だ。
専用のIDを持つことで、エージェントごとにアクセス権限を設定し、誰がどの操作を行ったのかを記録しやすくなる。
Googleは7月に提供を拡大した「Agent Identity」でも、必要最小限の権限を与える仕組みや、実行環境とIDを結びつけたアクセス管理、活動履歴の監査について説明していた。
今回の発表では、外部システムへの接続時にOAuthなどを利用してエージェントのIDを引き継ぎ、コードを実行する環境にもそのIDを関連づける仕組みが紹介されている。
通信の制御には「Agent Gateway」を利用する。
Googleによれば、サンドボックスと外部環境の間だけでなく、エージェント同士の通信にも企業のセキュリティポリシーを適用できるという。
例えば、特定の機密区分に属する文書へのアクセスを禁止するルールを設ければ、個々のエージェントに同じ設定を繰り返し行う負担を減らせる。
ただし、適切なアクセス権限を与えたからといって、エージェントが常に正しい判断を下せるわけではない。
閲覧を禁止された文書へのアクセスを防げても、閲覧を許可された文書の内容を誤解する可能性は残る。
チームの一員としてAIに仕事を任せるなら、アクセス権限の設定だけでなく、どの操作を自動実行させ、どの段階で人間の確認を必要とするかも決めなければならない。
今回紹介された日程調整の例だけでは、エージェントが社外へのメールを常に利用者の確認なしで送信できるとは判断できない。
AIエージェントを継続的に業務へ参加させるには、専用アカウントやアクセス制御に加え、重要な判断へ人間が適切に介入できる仕組みも欠かせない。
自律実行の費用は、モデルの単価だけでは判断できない
AIエージェントを企業で継続運用する際には、費用の管理も重要な課題になる。
Googleは8月、エージェントの利用料金を管理するため、プロジェクト単位で月額支出の上限を設定できる機能を発表した。
設定した上限に達すると、エージェントによるAPI呼び出しが一時停止され、管理画面から再開できる。
今回の発表でも、トークン使用量やサンドボックスの利用費用を監視し、支出が上限に達した場合に処理を停止する仕組みが紹介された。
ここで区別したいのが、AIモデルの選択を最適化する「Smart Routing」と、費用の上限を設定する機能だ。
Smart Routingは、仕事の内容に応じて適切なモデルを選択する仕組みである。
一方、支出上限の設定は、エージェントが利用できる予算を制限するためのものだ。
安価なモデルを選んだとしても、何度も処理をやり直したり、必要以上にツールを呼び出したりすれば、最終的な費用は増える。
また、予算の上限に達した時点で処理を停止できても、依頼した仕事が完了しているとは限らない。
企業にとって重要なのは、AIモデルが1回応答する際の単価だけでなく、実際に利用できる成果物を完成させるまでに、どれだけの費用がかかるかという点だ。
繰り返し実行する仕事では、同じ推論を毎回やり直さないことも費用削減につながる。
Googleは今回、BigQueryとKnowledge Catalogを組み合わせ、社内で使われる業務用語の定義を統一し、生成したクエリを保存して再利用する方法を紹介した。
一度作成したレポートは、保存済みのクエリを使って再実行できるため、その都度生成AIに問い合わせる必要がなくなる。
これにより、同じクエリを生成するためのトークン費用を削減できる。
ただし、生成AIのトークン費用が不要になることと、処理全体が無料になることは異なる。BigQueryなどでクエリを実行するための費用は、別途発生する可能性がある。
自然言語で業務の処理内容を作成し、繰り返し実行する部分は保存済みの処理に任せる。
こうした役割分担は、毎回AIモデルに同じ判断をさせる費用を抑えるだけでなく、実行内容を確認しやすくする効果も期待できる。
ただし、保存したクエリが常に正しいとは限らず、元となるデータの構造や業務上の定義が変われば、処理内容を見直す必要がある。
機能の提供状況にも注意が必要だ。
Google Cloudの10月2日付リリースノートによると、BigQueryなどのData Cloudに接続して、元データを移動せずに問い合わせる機能や、Knowledge Catalogとの連携はプレビュー段階にある。
今回発表された構想に含まれる機能が、すべて同じ条件で利用できるわけではない。
また、10月8日の基調講演では、新しいGemini agentのすべての機能について、一般提供の開始日や対象地域、対応する料金プランが一覧で示されたわけではない。
紹介された企業の導入成果についても、Gemini Enterprise全体を対象とした事例が多く、新しいGemini agent単体の業務完了率や総費用を独立して測定した結果とは区別する必要がある。
企業が実際に導入を判断するには、日常的に繰り返している業務を対象に、どれだけの割合で最後まで仕事を完了できるか、どの程度の手戻りが発生するか、成果物の完成までにいくらかかるかを検証することが重要になる。
加えて、利用するAIモデルが変わっても、作業履歴やアクセス権限を適切に管理できるか、必要な場面で人間が判断に介入できるかも確かめる必要がある。
今回のGemini agentが目指しているのは、質問に答えるAIから、業務の文脈を理解し、継続的に仕事を引き受けるAIへの進化だ。
複数のAIモデルを利用できることや、専用アカウントを持たせられることは、そのための手段にすぎない。
今後問われるのは、それらの仕組みを組み合わせることで、実際の業務をどこまで確実かつ効率的に完了できるようになるかという点だ。
