0 / 7 節読了

企業が選ぶのはモデルだけではなくなる

Google Cloudが10月8日のGemini at Work 2026で発表した「Gemini agent」は、仕事の入口を一つにまとめる構想だ。質問への応答、文書やメディアの制作、コードの作成と実行を同じエージェントへ任せ、長い仕事をクラウドで続ける。その下で使うモデルには、GoogleのGeminiだけでなくAnthropicのClaudeも置く。

名前にGeminiとあっても、エージェントの仕組みと推論モデルは別の選択になる。公式発表は、仕事に合うモデルが常に最大のモデルとは限らず、先頭に立つモデルも変わると説明する。企業に残すのは、モデルの名前以上に、仕事の文脈、手順、接続先、管理の仕組みという考え方だ。

仕事の継続性をクラウド側に置く

発表では、依頼者がノートPCを閉じても、数時間や数日かかる仕事を継続するとされる。端末ごとに説明し直すのではなく、同じ記憶と文脈を利用する設計だ。必要に応じて一時的なサブエージェントを作り、複数の工程を分担させることも想定する。

また、常設のコワーカーエージェントには独自のWorkspaceアカウントを与える。メールアドレス、カレンダー、Driveなどを持ち、チャットのメンションや文書のコメントを受けて働く。人のアカウントを借りて裏側で操作するのではなく、エージェント自身を仕事の主体として管理する方向だ。

ここで重要なのは、共有された情報を扱うという境界である。アカウントがあることだけで、社内のすべてが読めるわけではない。編集部の見方では、AIの採用を人の入社手続きと同じように考え、所属、担当、閲覧権限、停止の責任者を用意する発想が現実的になる。長時間働くほど、権限が不要になった後も残り続けない管理が必要になる。

四つの記憶が、引き継ぎの負担を減らす

Googleは記憶を、進行中のタスクを保持するセッション記憶、資料や対話から組み立てる意味記憶、手順やスキルを扱う手続き記憶、過去の行動を記録するエピソード記憶に分けて説明した。短い会話履歴だけではなく、業務を継続するための異なる情報を蓄える。

この区別は、企業が何を削除し、何を更新するかを考えるうえでも役立つ。古い製品価格は意味記憶から更新する必要があるかもしれないが、過去にその価格で何を処理したかは監査の記録として残したい。手順が変わればスキルを改訂するが、前の手順で行った作業の履歴まで書き換えるべきではない。

これは編集部の運用上の考察であり、発表された記憶機能の管理画面がすべてこの操作を提供するという意味ではない。導入時には、訂正、削除、保存期限、利用者間の共有範囲を実際の管理機能で確かめる必要がある。覚える量だけでなく、誤った情報を直せるかが信頼性を左右する。

スキルとツールを組織の資産として扱う

スキルは、ある仕事の進め方を繰り返し使える指示や知識のまとまりだ。公式発表は、部署やチームが社内レジストリに登録する形を示す。ツール側も社内で共有でき、業務システムやデータベース、MCPサーバーなどへ接続する。

この設計では、モデルが更新されても、会社の承認手順や資料の作り方を毎回ゼロから書き直す必要を減らせる可能性がある。一方、共有する手順が誤っていれば、その誤りが多くの仕事へ広がる。登録できることと、本番で使ってよいことを同じ扱いにしない仕組みが必要だ。

たとえば見積書を作るスキルなら、価格表の取得、値引きの許可、送付前の確認を分けて定義する。説明文を生成する能力と、取引条件を確定する権限は別にする。その境界を手順と接続権限の両方に持たせることで、モデルを入れ替えた際にも守るべき条件を維持しやすくなる。

管理の中心は、誰が何をしたかを追えること

Googleの発表は、独自ID、必要最小限の権限、監査証跡、サンドボックス、Agent Gatewayを組み合わせる。行動ログは人間ではなくエージェントに帰属させ、外部システムに接続するときもIDや権限を引き継ぐ。通信を方針に沿って管理するという説明もある。

これらは提供側が示す設計であり、自社の設定が適切であることまで自動的に証明するものではない。日本企業が確かめたいのは、既存の文書共有権限をどこまで引き継ぐか、外部へ送る操作をどこで制御するか、事故時にどのログを回収できるかだ。利用者の最終報告だけでは、途中のアクセスや失敗を十分に確認できないことがある。

組織の禁止事項を一度定めて複数のエージェントへ適用する仕組みは、管理の手間を減らす。ただし、例外の申請、緊急停止、権限変更の反映時間まで運用に含めたい。エージェントの数が増えるほど、人が一体ずつ画面を見て判断する方式では追いつきにくくなる。

モデルの自動選択は費用と品質の両方を変える

Smart Routingは仕事に適したモデルへ振り分ける。プロジェクトごとの支出上限に達した場合には、エージェントを一時停止する仕組みも発表された。単価の安いモデルを混ぜるだけでなく、長い作業が使い続ける計算資源やサンドボックスの費用も管理する必要がある。

編集部としては、モデルを選べる自由と、出力の一貫性を確かめる責任をセットで考えるべきだとみる。文章の要約には十分なモデルでも、複雑な権限判断や機密情報を扱う処理では評価結果が違うかもしれない。自動選択を使う場合も、選ばれたモデルと設定を記録し、失敗の原因を追えることが望ましい。

支出上限については、停止後の扱いも重要だ。途中まで作った文書、外部に反映した変更、再開時の重複実行をどう扱うかを決めておかなければ、費用を止めた代わりに作業の整合性を失う。料金の管理は、仕事の状態を管理する仕組みと切り離せない。

日本企業の事例と、新製品の実績を分ける

発表ではSOMPO、NTTドコモ、日立などの活用事例も紹介された。ただし、既存のデータエージェントやGemini Enterpriseの成果を、今回発表された汎用エージェントそのものの導入効果として読むべきではない。イノベトピアの記事も、この区別を指摘している。

導入判断では、発表された構想、現在の対象プランで使える機能、自社で確認できた結果を分ける。一般提供の具体的な時期や価格は、今回確認した発表だけから一式を確定できない。クラウドで長く働くAIを検討する企業ほど、モデルの性能表より先に、記憶の訂正、権限の回収、支出と実行の停止を確認する価値がある。

モデルが変わっても仕事の文脈を保つ設計は魅力的だ。その反面、文脈や手順をどの基盤へ預けるかは、モデル選びとは別の継続的な判断になる。企業向けAIの競争が、回答の賢さから仕事を運用する仕組みへ広がったことを示す発表として読める。

確認日:2026年10月17日。本稿の制作にGemini APIは使用していない。運営会社:RO合同会社の公式HP。

柴亮太
柴亮太の視点