Gemini agentが自分のメールアドレスを持つ。AIに社員と同じ権限を渡す前の5点

AI エージェントの案件で、見積書に載りにくい行がある。「このエージェントを、社内の何者として扱うか」である。アクセス権、ログ、止め方、費用の付け替え先。どれも開発の話ではなく、社内の制度の話なので、どちらが決めるのか曖昧なまま進みやすい。

2026 年 10 月 8 日、Google Cloud が年次イベント Gemini at Work 2026 で「Gemini agent」を発表した。目を引いたのは性能の数字ではなく、エージェントに社員と同じ形の身分を与えるという設計である。

発注側が読むべきなのは「便利そうだ」ではなく、自社の案件で誰がこの身分を設計するのかである。

机に真鍮の名札プレートが4枚並び、手前に鍵が1本ずつ、奥に受付簿と投函箱が置かれている

公表されている事実

Google Cloud の発表（2026 年 10 月 8 日）に書かれているのは次の内容である。

身分を持つ: 業務を任せる「coworker agent」には専用の Workspace アカウントが与えられる。メールアドレス（発表では @agents.company.com の形）・カレンダー・ドライブ・社内ディレクトリへの掲載を持つ
本人ではなく自分として動く: エージェントは利用者の権限を借りるのではなく自分の身分で動き、共有された範囲しか見えない。変更履歴にはエージェントの名前で残る
下請けを作る: 仕事ごとに一時的な下位エージェントの一団を作り、それぞれにも身分を与えて、並列・直列に進める
帰っても動き続ける: 「hours or days」かかる仕事は、利用者がノート PC を閉じた後もクラウド側で継続する（上限時間の記載は無い）
権限と監査: 各エージェントは暗号的に検証できる身分を持ち、最小権限で動く。身分はログと、エージェントが起動した仮想マシンにも刻まれる。すべての操作がエージェント名義の監査証跡に残る
隔離と関所: エージェントは独自のネットワーク境界を持つ「Agent Sandbox」で動き、通信はすべて「Agent Gateway」（発表では AI 向けのネットワークファイアウォールと説明）を通り、方針を実時間で適用する
費用の止め方: Cloud Billing Console でプロジェクト単位の実時間の支出上限を設定でき、上限に達するとそのプロジェクトのエージェントが停止し、ワンクリックで再開できる。プロジェクト単位の集計は部門への費用付け替えに使える
モデルを選ばない: Gemini 系と Anthropic の Claude 系を現時点で束ね、将来は他の非公開・公開モデルも対象とする。仕事ごとに最も安く性能が出るモデルへ振り分ける
つなぐ先: Google Workspace・Microsoft 365・Slack・コマンドライン、Jira・Salesforce・ServiceNow・BigQuery・Snowflake などの業務システム、および任意の MCP サーバー
提供状況: 分野別の特化版は金融・法務が preview、行政・医療・小売が coming soon。Gemini agent 本体の提供開始時期と価格は発表に記載が無い

数字としては、TPU 8i が前世代比で価格性能 80% 改善、直近 1 年で 1 兆トークン超を処理した顧客が約 500 社、という値が示されている。いずれも自社公表値である。

発注者・企業への影響

ここから先は見立てである。

1. 「誰の権限で動くか」が見積依頼の必須項目になる

従来の AI 案件は、利用者がログインし、その人の権限でAI が動く作りが多かった。この前提だと、権限の設計は既存の社内ルールの流用で済む。

エージェントが自分の身分で動く作りに変わると、社員でも委託先でもない第三の区分を社内に作る必要が出てくる。誰が申請し、誰が承認し、退役時に誰が止めるのか。これは開発会社が決められない。

見積依頼の段階で「このエージェントは人の代理か、独立した主体か」を書いておくと、各社の見積書で権限設計の行が揃う。書かないと、A 社は既存ログインの流用で安く、B 社は身分管理の仕組みごと作って高く出し、比較にならない。外部へ出すデータの線引きはAI開発で外部APIに送ってよいデータの決め方に 4 区分で整理した。

2. 監査ログは「作る」から「残す」へ論点が移る

操作ごとにエージェント名義の証跡が残る仕組みが基盤側にあるなら、ログを作る行は見積書から減る方向に動くと考えられる。代わりに残るのは、次のような自社側の決めごとである。

決めること	誰が決めるか
ログの保存期間	発注側（社内規程・業界規制に従う）
誰がログを見られるか	発注側
基盤のログを自社の保管先へ書き出すか	両者で設計
月次で何をレビューするか	発注側（運用）

4 つのうち 3 つは発注側の宿題である。開発会社の見積書には載らないが、決まっていないと検収の基準が書けない。AI開発の検収で合格条件を先に決めておく話と同じ構造である。

3. 「閉じても動き続ける」は費用と事故の形を変える

人が画面を見ている間だけ動く AI なら、費用は使った時間に比例し、止めたいときは画面を閉じれば止まる。数日動き続ける作りでは、誰も見ていない時間に費用が増え、誰も見ていない時間に失敗する。

発表に支出上限と一括停止・再開の仕組みが入っているのは、この性質への対処だと考えられる。発注側が決めるのは次である。

1 件あたりの上限額と、月あたりの上限額
上限に達したときに、止めるのか、人に渡すのか
止まったことを誰に通知するか
途中で止まった仕事の後始末（中途半端な更新をどう戻すか）

4 つ目が抜けやすい。数日かかる処理が 3 日目で止まったとき、書き込み済みのデータをどう扱うかは設計の話なので、見積依頼に書けば各社が見積もる。書かなければ誰も見積もらない。従量での費用の膨らみ方はトークン課金とはに内訳を書いた。

4. 下位エージェントが増えると、精度の責任の所在がぼやける

仕事ごとに一時的な下位エージェントが作られる設計では、最終の出力がどの段で間違えたのかを追うのが難しくなる。身分が刻まれた証跡が残るなら追跡は可能だが、「追跡できる」と「合否を判定できる」は別である。

実務上は、中間成果物のどこに検査点を置くかを契約前に決める話になる。全段を人が見るなら自動化の意味が薄れ、最終出力だけ見るなら誤りの原因が特定できない。精度を誰がどう測るかはAIの精度評価は誰がやるかでベンダー・自社・第三者の 3 つの型に分けて比較した。

5. 提供時期と価格が未公表のものは、前提にして見積もらない

発表には Gemini agent 本体の提供開始時期も価格も書かれていない。分野別の特化版は金融・法務が preview で、他は coming soon である。

この状態で「基盤側の標準機能で足りるので安く作れます」という提案が来た場合、安さの根拠に期限と条件が付いている。確認する文面は決まっている。

提案が前提にしている機能は、今日自社の契約で使えるか（preview か、一般提供か）
使えない場合の代替手段を用意するか、使えるようになるまで待つのか
提供条件や価格が変わったときの修正は、保守に含むか別途か

同じ論点はGemini 4 Argonが限定提供から始まった件でも扱った。発表の時点で使えるものと、使えるようになる予定のものを混ぜた提案は、比較の土俵が崩れる。

見積もりを取るときに揃える 4 点

複数社に出すなら、次を同じ文面で書く。

エージェントの身分（人の代理か、独立した身分か。独立なら申請・承認・停止を誰がやるか）
ログの保存期間と閲覧範囲（規制で決まっている場合はその根拠も）
1 件・月あたりの費用上限と、上限に達したときの動作
検査点の置き場所（最終出力だけか、中間成果物も見るか）

この 4 つは、どの基盤を使う提案でも同じ形で聞ける。無料で見積り・相談の案件票では扱うデータの範囲と利用者の区分を選択式で揃えているので、各社が同じ前提で権限設計を見積もったかを横並びで確認できる。

まとめ

今回の発表で変わったのは、AI の性能ではなくAI の身分である。社内ディレクトリに載り、メールアドレスを持ち、自分の名前でログに残る主体が増えていく流れだと考えられる。

発注側がやることは 2 つ。エージェントを社内の何者として扱うかを先に決めること、そして提供時期が未公表の機能を安さの根拠にした提案を、そのまま比較表に並べないことである。

参考・出典

Google Cloud ブログ「Welcome to Gemini at Work 2026」（2026 年 10 月 8 日） https://cloud.google.com/blog/products/ai-machine-learning/welcome-to-gemini-at-work-2026
Google ブログ「Google Cloud introduces the Gemini agent」（2026 年 10 月 8 日） https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/gemini-at-work/