営業資料はDrive、商談はCRM、議論はSlackにあります。マーケティング担当がその情報から施策を作るとき、Agentの導入で決めるべきなのは、どこから情報を得て、誰の権限で動き、どこへ成果を返すかです。
Googleは2026年10月8日にGemini agentを発表しました。持続するクラウド実行、coworkerの独立したID、動的subagent、Skills、企業向けツールとガバナンスを説明しています。Gmailの補助機能だけではありません。
Budaは、チャット、ファイル、Terminal、Browser、Preview、Gitを一つのAgent Workspaceにまとめます。両方とも継続的な仕事を目指すため、判断軸は「どちらだけが自律的か」ではなく、業務記録の置き場所と成果の確認方法です。
Googleは既存の組織にAgentを配置する
Googleの発表では、Workspace、Microsoft 365、Slack、CLI、外部アプリからアクセスできます。Salesforce、ServiceNow、データベース、Git、Jira、MCP serversとの接続、社内のtools／Skills registryも説明されています。
具体例では、マーケティング責任者がイベント担当AgentをChatに加え、準備文書を依頼します。Docsのコメントで呼びかけることもでき、編集はAgent自身の名前で履歴に残ります。
coworkerはWorkspaceアカウント、メール、カレンダー、Drive、社内ディレクトリ上のIDを持ち、共有された情報を参照します。一方、動的subagentは並列・順次作業のために作る一時的な担当です。恒久的な役割と、一回の仕事の分担は別に管理します。
Gemini SparkやGeminiモデルとも区別が必要です。Agentは仕事を実行する層で、基盤モデルは別の選択です。GoogleはGeminiとClaudeの利用、さらにモデル選択を広げる計画を示しています。
Budaは作業現場を確認できる形にする
Agent Workspaceの各タブは同じクラウドコンピューターを見ています。ファイルを開き、コマンドやブラウザー作業を確認し、アプリをプレビューし、Gitの差分を読むことができます。
営業データをCSVに整理し、スクリプトで分析し、出典付きの報告と施策案を作るような仕事では、最終回答だけでなく実際の成果物を点検できます。
Agent DriveとSpace Driveは、個別Agentのファイル・記憶と、明示的に共有するチーム資料を分けます。個人用Driveのファイルが自動的に全体へ共有されるわけではありません。
作業が見えることと、企業のポリシーを強制することは異なります。この仕組みだけで、Googleが説明するAgent GatewayやID伝播、監査と同等の制御をBudaに帰属させることはできません。
同じ施策案で接続の負担を比較する
営業の声から新製品の施策案を作る試行を設計します。実施済みの速度測定ではありません。
**Geminiでは：**既存文書とChatをcoworkerに共有し、CRMの接続資格と権限を確認してDocsに案を作ります。引用の根拠、AgentのID、権限変更、同僚による引き継ぎを点検します。
**Budaでは：**承認済み入力と業務定義を共有場所へまとめ、出典索引、分析ファイル、施策案を生成します。ファイルやBrowser、Gitで確認した成果だけを業務システムへ返します。
Googleは既存文書の移動を減らせる可能性があります。Budaはウェブ、ファイル、コードから生まれる成果を一つの確認場所に集めます。入力準備、接続維持、権限設定、結果の書き戻しまで含めて比較してください。
購入前に確認する四つの問い
| 問い | Gemini agent | Buda |
|---|---|---|
| 正式な情報源はどこか | 接続と共有の範囲 | 入力資料、Drive、tools |
| IDを誰が管理するか | coworkerとsubagent、会社のポリシー | Space、Agent、メンバー、外部権限 |
| 人が何を確認するか | 文書、履歴、利用可能な監査ログ | ファイル、コマンド、Browser、Git |
| 成果をどこへ返すか | 元のシステムと引き継ぎ | 承認したファイルや検証済み接続 |
主要情報が管理されたWorkspaceと業務システムにあり、管理者が接続とポリシーを維持するなら、Geminiの組み込み型を先に試すのが自然です。
ウェブ調査、ファイル加工、スクリプト、アプリ制作をまたぎ、明確な入力資料と見える実行環境を作りたいならBudaを試す価値があります。Googleに複数Agent機能がないからではなく、作業と成果の整理方法が違うからです。
併用では正本の入力と承認済み出力を一つずつ決めます。更新責任者を決めないまま、両方に同じ顧客レコードを書かせないでください。
公表された機能を実アカウントで確認する
GoogleはID、認可、監査、sandbox、Agent Gateway、費用制御を説明しています。導入前に自社アカウントで利用できる機能と、管理者の設定が必要な機能を確認します。
プラン、地域、管理設定、connector、公開範囲を確認したうえで、テスト資料を使い、見える情報、拒否される操作、残る記録を調べます。BudaのSpaceと外部権限にも同じ確認が必要です。
最初の試行で残す五つの成果
一つの反復業務に必要最小限の入力を渡し、次を要求します。
- 出典、日付、リンク、業務定義の一覧。
- 実際の報告書、表、スクリプト、施策案。
- 実行者のID、使ったシステム、拒否された操作。
- 足りない入力、失敗、判断待ちの項目。
- 責任者が受け入れた版、返却先、次回の保守担当。
別の同僚が元担当者のアカウントを借りずに確認・継続できるかを試します。資料不足、再説明、権限問題、確認時間を記録し、どちらが速いかを先に決めません。
BudaではWorkspaceに入力と基準を用意します。反復手順はSkillにし、適切なものがあればBuda AIのMarketplaceで検索してインストールできます。引き継げる仕事を作ってから自動化を広げます。