Google Cloudは2026年10月8日（米国時間、日本時間9日）、年次イベント「Gemini at Work 2026」で、仕事全般を引き受ける汎用エージェント「Gemini agent」を発表した。The Registerによれば、同社CEOのトーマス・クリアン氏は、これを「仕事のための、単一で汎用のエージェント」と紹介し、「指示だけでなく、目標を与える」ものだと説明した。Reworkedによれば、エージェントはGoogle Workspace、Microsoft 365、Slackの中で動き、Jiraなどの業務ツールや、社内外のMCPサーバーにもつながる。
今回の発表で目を引くのは、性能よりもガバナンスの機能だ。Google Cloudの公式ブログを引く報道によれば、エージェントは1体ごとに人とは別のIDを持ち、行動はそのエージェントの名前で監査記録に残る。外部との通信は「Agent Gateway」という関門を必ず通り、費用はプロジェクトごとに上限を決められる。上限に達すると、エージェントは止まる。いわば「社員証」を持たせ、入館の記録と経費の枠を管理したうえで働かせる設計である。
一方で、現時点で使えるのは一部の企業に限られる。料金の詳しい体系も示されておらず、日本での提供は発表されていない（10月11日時点）。それでも、エージェントにどこまでの権限を渡し、どう記録を残し、いくらまで使わせるかは、どの製品を選ぶ場合でも導入前に決めておくべき論点だ。本稿では、発表されたガバナンス機能を4つの軸に分けて整理し、OpenAIのdotsやAmazonのセラー向けエージェントと比べる。そのうえで、SNSの運用代行や案件管理の業務に当てはめ、契約前に確かめるべき項目をまとめる。
何が発表されたか──「目標を渡す」汎用エージェントと、エージェント専用のID
Gemini agentは、これまで用途ごとに分かれていたGoogleの業務用AIを、1つの入口にまとめるものだ。Reworkedによれば、Web、AndroidとiOSのスマートフォン、デスクトップ、コマンドラインから使える。処理はGoogleのクラウド上で動くため、どの入口から話しかけても記憶が引き継がれる。標準で使えるツールには、SlackやMicrosoft Teams、Microsoft Office、Confluence、Git、Jira、Salesforce、ServiceNow、BigQuery、Snowflakeなどが並ぶ。これ以外のサービスとはMCP（Model Context Protocol）でつなぎ、社内のサーバーにも社外のサーバーにも接続できる。
もう一つの柱が、人と並んで働く「コワーカーエージェント」である。beri.netによれば、コワーカーエージェントは1体ごとにWorkspaceのアカウントを持つ。中身は「@agents.company.com」形式のメールアドレス、カレンダー、Drive、社内ディレクトリへの登録だ。社員はこのエージェントをChatのスペースに加えたり、@メンションしたり、ドキュメントのコメントでタグ付けしたりできる。エージェントが編集した内容は、版の履歴に本人の名前で残る。作業は数時間から数日かかってもクラウド上で続き、担当者がノートPCを閉じても止まらない。
The Registerによれば、クリアン氏は「すべてのGemini agentは、あなたのIDとは別の、自分自身のIDを持つ」と述べた。エージェントは作業ごとに一時的なサブエージェントも作れ、サブエージェントもそれぞれIDを持つ。使うモデルは作業に合わせて自動で選ばれ、現時点ではGeminiのモデルと、AnthropicのClaudeのモデルを使い分ける。ほかのモデルにも今後対応する予定とされる。モデル選びと単価の考え方は、Gemini 4 Argonの記事で整理した。
ガバナンス機能を4軸に分解する──最小権限・監査の帰属・通信ポリシー・支出上限
機能の一覧を眺めても、導入する側が何を決めればよいかは見えにくい。そこで本稿は、報道とGoogleの技術文書に書かれた機能を、「何を見せるか」「誰がやったことになるか」「どこと通信してよいか」「いくら使ってよいか」の4つの問いに置き換えて整理した。この区分はGoogleが示したものではなく、本稿によるものだ。
| 軸 | 発表・文書で確認できた機能 | 導入側が決めること |
|---|---|---|
| 最小権限（何を見せるか） | コワーカーエージェントは「共有されたものだけを見る」（beri.net）。権限はOAuthで引き継がれる（Futurum）。役割に応じてアクセスが制限され、他社のソフトには「Googleでログイン」の仕組みで自分自身としてサインインする（Reworked） | エージェントに共有するフォルダ・チャンネル・ツールの範囲 |
| 監査の帰属（誰がやったことになるか） | すべての行動が、人ではなくエージェントの名前で記録される。サブエージェントもIDを持ち、ドキュメントの編集履歴にもエージェントの名前が残る（Reworked）。公式ブログは、エージェントを「暗号学的に証明され、社員のように統制される」と表現している（beri.net） | エージェントごとの責任者と、ログを誰がどの頻度で見るか |
| 通信ポリシー（どこと通信してよいか） | エージェントの通信はすべてAgent Gatewayを通る。Googleはこれを「AIのネットワークファイアウォール」と呼び、ルールは一度書けばすべてのエージェントに効く（Reworked）。技術文書によれば、明示的なポリシーがない接続は初期状態で拒否される | 接続を許す外部ツール・MCPサーバーの一覧 |
| 支出上限（いくら使ってよいか） | 上限はCloud Billingのコンソールでプロジェクトごとに設定し、トークンとサンドボックスの費用を数える。上限に達するとそのプロジェクトのエージェントが止まり、コンソールのワンクリックで再開できる（beri.net）。費用は部門ごとに付け替えられる（Reworked） | プロジェクトの切り方と、上限の金額、止まったときの再開担当 |
技術文書を読むと、通信ポリシーの中身はもう一段具体的だ。Agent Gatewayは、利用者とエージェント、エージェントとツール、エージェント同士のやり取りを、ネットワークの出入口で取り締まる。Gemini Enterpriseで使えるのは、エージェントから外に出ていく通信を管理するモードだけである。接続先は「Agent Registry」という台帳に登録して管理し、1つのゲートウェイで最大5,000件まで扱える。オプションの「Model Armor」は、プロンプトインジェクション（外部の文章に紛れ込ませた指示でAIを操る攻撃）や情報の持ち出しを検査する。自然な文章で書いたルールでツールの使い方を縛る機能もある。通信の記録はCloud LoggingやCloud Traceで見られる。ただし、技術文書にはプレビューか正式提供かの記載がない。
注意したいのは、支出上限がプロジェクト単位でかかる点だ。beri.netが指摘するように、1つの作業が暴走して上限に達すると、同じプロジェクトにいる他のエージェントもまとめて止まる。止まったエージェントに届いたメールがどう扱われるかも、Googleは説明していない。上限は使いすぎを防ぐ安全装置である一方、締め切りのある業務を止める原因にもなる。この点は後の章で、プロジェクトの切り方として扱う。
提供段階と料金──「追加料金なし」と「料金は未公表」をどう読むか
導入の時期を考えるうえで、どの段階まで使えるようになっているかを押さえておきたい。Android Headlinesは、プライベートプレビューで、対象は一部のGemini Enterprise契約者だと伝えた。Reworkedも、現在使えるのは限られた数の企業だとしている。FuturumとReworkedによれば、業界別の版では金融と法務がプレビューに入り、政府・医療・小売は後に続く予定だが、時期は示されていない。Futurumは、汎用エージェント、Agent Gateway、支出上限がいつ本番の提供になるかについて、Googleがほとんど日付を示さなかったと指摘している。
料金についての報道は、読み方に注意が要る。Reworkedは、Googleの広報担当者の話として、Gemini Enterpriseを提供している範囲では、エージェントは追加料金なしで使えると伝えた。この範囲には、既存のWorkspaceのビジネス版とエンタープライズ版の契約も含まれる。Futurumは、Workspaceでコワーカーとして働くエージェントに、席ごとのライセンス料を取るつもりはないとの説明を受けた。ただし、料金の詳細は提供が広がる時期に示すとしている。一方で、支出上限が数えるのはトークンとサンドボックスの費用である。そのため、エージェントの「席代」はかからなくても、処理した量に応じた費用は発生すると読むのが自然だ。単価や、どのモデルにいくらかかるかは、本稿が確認した資料では公表されていない。
日本での提供時期や、日本語での使い勝手についても、確認できた資料には記載がなかった。日本の企業や事務所にとっては、すぐに契約を検討する段階ではない。ただ、この発表で示された「エージェントにIDと予算を持たせる」という管理の考え方は、他社の製品を評価するときの物差しとして先に使える。
dots・Amazonと並べる──ガバナンス機能の有無
常に動き続けるエージェントは、この2週間で各社から相次いで発表された。OpenAIのdotsの記事とAmazonのセラー向けエージェントの記事は、主に「何を任せるか」を扱った。ここでは、4つの軸に沿って、3つの製品の管理機能を並べる。各社の資料に記載がない項目は「確認できず」とした。これは機能がないという意味ではなく、公開情報から読み取れないという意味だ。
| 項目 | Google Gemini agent | OpenAI dots | Amazon Seller Assistant |
|---|---|---|---|
| エージェントのID | 1体ごとに人とは別のID。コワーカーエージェントはWorkspaceのアカウントとメールアドレスを持つ | 利用者のアカウントに置く。組織の中の独立したIDは確認できず | セラーのアカウントの中で動く |
| 権限の設定 | 共有したものだけを見る。役割に応じたアクセス制限 | 操作ごとに4段階のCustom Rules。パスワードの変更と送金は必ず人に戻る | 提案だけか実行までかを選ぶ。プラグインでは、アクセス範囲の制限と人による承認 |
| 監査ログ | エージェントの名前ですべての行動を記録する | 定期作業の実行状況は確認できる。操作の監査ログは確認できず | プラグインの操作を監査記録に残す |
| 通信ポリシー | Agent Gatewayで、全エージェントの外部との通信を一括で管理 | 確認できず（接続するアプリは利用者が選ぶ） | 確認できず（データはAmazonの基盤の中にとどまるとされる） |
| 支出上限 | プロジェクトごとに上限を設定し、達すると停止 | 確認できず（料金は月額プランで、追加料金は未定） | 確認できず（広告費の上限などはセラーが自分で設定する） |
| 日本での提供 | 発表されていない | 日本は除外地域ではないが、日本を名指しした記載はない | 常時稼働型とプラグインは日本での時期が未発表 |
表から読めるのは、各製品が想定している「管理する人」の違いだ。dotsは、担当者が自分の仕事を任せる道具として作られ、権限は個人が細かく決める。Amazonは、出品という1つの業務に絞り、承認と記録を用意している。Gemini agentは、情報システムの部門が全社のエージェントを一括で管理する前提に立つ。通信と支出の管理を組織の側に持たせているのはこのためだ。複数のクライアントや所属クリエイターを抱える事務所・代理店では、担当者ごとの設定だけでは管理しきれなくなる。組織として権限と予算を管理する仕組みがあるかどうかは、製品を選ぶときの一つの基準になる。
SNS運用代行・案件管理に当てはめる──プロジェクトの切り方が権限と予算を決める
4つの軸のうち、運用の設計に最も効くのは、プロジェクトをどう切るかである。支出上限がプロジェクト単位でかかり、費用も部門ごとに付け替えられる以上、プロジェクトの切り方がそのまま予算と停止の単位になる。以下は、事務所や代理店の代表的な業務を例に、本稿が4つの軸で設計案を示したものだ。Googleの推奨する構成ではなく、実際の設定項目がこの通りに使えるかは、提供が始まった時点で確かめる必要がある。
| 業務 | 最小権限 | 通信ポリシー | 支出上限の単位 |
|---|---|---|---|
| クライアント別のSNS運用代行（投稿案の作成、数値レポート） | そのブランドのDriveフォルダと共有チャンネルだけを共有する | そのブランドの分析ツールとSlackに限って許可する | クライアントごとに1プロジェクト。費用をそのまま請求の根拠にできる |
| 案件管理（Jiraのチケット更新、締め切りのリマインド） | 案件管理のボードだけ。契約書のフォルダは共有しない | Jiraと社内のChatに限る | 締め切りに関わるため、重い集計とは別のプロジェクトにする |
| キャスティング候補の調査 | 公開情報と社内の実績表。所属クリエイターの個人情報は別に管理する | 外部への送信は許可しない（下書きまで） | 調査用のプロジェクト。上限は低めに設定し、止まっても業務に響かない |
| 月次の大量集計・過去投稿の分析 | 読み取りのみ | データの置き場所に限る | 単独のプロジェクト。暴走しても他の業務を巻き込まない |
考え方の要点は二つある。一つは、時間に追われる業務と、量の多い業務を同じプロジェクトに入れないことだ。大量の集計で上限に達し、投稿予定のリマインドまで止まってしまえば、エージェントを入れたせいで事故が起きる。もう一つは、クライアントや所属クリエイターの情報を、プロジェクトと共有の範囲で物理的に分けることだ。エージェントが自分のIDで動き、行動がその名前で記録される仕組みは、情報が誤って別のクライアントに混ざっていないかを後から確かめるときに役立つ。Threadsの権限独立を扱った「誰に渡し、いつ外すか」の記事で示した、人の権限の棚卸しと同じ作業を、エージェントにも行うことになる。
外部のツールを広くつなげるほど便利になる一方で、守る範囲も広がる。MCPでつながる先が増える流れは、Cloudflare OSとMCPの記事でも取り上げた。Agent Gatewayのように、明示的に許可しない接続を初期状態で拒否する仕組みがあれば、接続先の一覧がそのまま社内の管理台帳になる。仕組みがない製品を使う場合は、接続を許したツールの一覧を運用の側で作っておく必要がある。
契約・導入の前に確認すること
Gemini agentは、日本ではまだ使える段階にない。それでも、エージェントの導入を検討している事務所やD2Cは、どの製品を選ぶ場合でも、以下の項目を販売元や導入の支援会社に確かめておきたい。いずれも今回の発表で論点として示されたか、各種の報道で未回答とされた点だ。
- エージェントは人とは別のIDで動くか。行動の記録はエージェントの名前で残り、誰がいつ見られるか
- エージェントごとに責任者となる人を決められるか。作った担当者が退職・異動したときに、エージェントとその記録をどう引き継ぐか
- 接続できる外部ツール・MCPサーバーを、組織として許可制にできるか
- 支出上限をどの単位でかけるか。上限に達したときに止まる範囲と、再開する担当者
- 処理量に応じた費用の単価と請求の仕組み。エージェントのアカウントが課金対象の席に数えられるか
- 他社のモデル（Gemini agentならClaude）にデータが送られる場合、どの利用規約が適用されるか
最後の項目は見落としやすい。beri.netによれば、GoogleのClaudeに関する文書は「AnthropicのモデルはGoogleの製品ではない」と明記し、別の規約が適用されるとしている。モデルを自動で選ぶ仕組みでは、利用者が意識しないうちに別の会社のモデルが処理を担うことがある。所属クリエイターの未発表の案件や個人情報を扱う場合は、どのモデルに何が送られうるかを契約前に確かめたい。
Google自身の常駐型エージェントは、Gemini Sparkの記事で取り上げたことがある。今回の発表は、エージェントの性能を競う段階から、エージェントを組織の一員として管理する段階に入ったことを示している。エージェントにIDを与え、見せる範囲と通信先を絞り、予算の枠を決め、記録を誰が見るかを決める。これは新入社員を迎えるときの手順とほとんど変わらない。製品が日本に来る前に、この手順を自社の業務の言葉で書き出しておけば、どの製品を選んでも導入の準備は短く済む。
本記事は、株式会社TORIHADAが運営するクリエイターエコノミー専門メディア「CREATORS POST」がお届けしました。最新のマーケティング・クリエイター動向を、実務目線で発信しています。
この記事はAIを活用して書いています。
