汎用業務エージェントは、単純な画面としては購入しやすく、権限のシステムとしては評価しにくい製品です。質問への回答から、記録の編集、資料作成、クラウドでの作業継続へ進むと、重要な問いが変わります。従業員が監視をやめたとき、この ID は何をできるのでしょうか。10 月 8 日の Google Gemini Agent 発表は、この問いを具体化しました。
Google は、業務アプリと端末をまたいで記憶、スキル、権限を共有する永続エージェントを説明しています。Gemini と Claude のモデルを組み合わせ、さらに非公開・オープンモデルへの対応を計画しています。これはオーケストレーションの主張であり、どのモデルに替えても品質、費用、データ処理要件が変わらない証拠ではありません。
すべてを接続する前に成果を一つ定義する
承認済み文書から社内プロジェクト報告を作るなど、限定したタスクから始めます。必要な資料、計算、出力形式、完了条件、レビュアーを指定します。外部送信と重要な記録変更は対象外にします。比較基準には別モデルの応答速度だけでなく、従来の人による工程を含めます。
Google は Workspace、Microsoft 365、Slack、企業データのコネクターを対象に挙げています。接続面があっても統合作業はなくなりません。ID の対応、情報の鮮度、読み書きの権限、接続失敗を個別に確認します。共通入力欄は複数の認可システムを隠せても、規則を自動的に統一しません。
すべての実行者への権限委任を追う
Google によれば、同僚型エージェントは専用メール、予定表、保存領域、ディレクトリエントリーを持てます。一時的な子エージェントにも ID があります。行為を追跡しやすくなる可能性はありますが、ID 自体は安全な権限ポリシーではありません。子への付与内容、期間、親と子の操作をログで区別できるかを確認します。
発表されたサンドボックスと Agent Gateway は実行とポリシーの境界を提供します。アクセス取消、機密分類、侵害されたツール、普通の文書に紛れた悪意ある指示で試します。文書を読む権限は、それに従う権限ではありません。NIST の ID と権限の議論は最小権限、委任、監査を考える材料ですが、この製品の認証ではありません。
記憶を管理対象データとして扱う
永続的な文脈は、アプリを移るたびに説明し直す手間を減らす一方、会話が終わっても誤った前提を残せます。個人、プロジェクト、組織の記憶を誰が閲覧、修正、制限、削除できるかを明確にします。元の接続権限だけでなく派生文書も含め、異動と資料の撤回を検証します。
スキルにも管理者、改訂履歴、撤回手順が必要です。古い融資メモのテンプレートは、成功したように見える多数のタスクへ同じ誤りを広げます。Google が示した DBS の例は、人が関与する専門エージェントの決定的な連鎖です。広い入口の下に、狭く明示的に管理された工程を置けるという重要な区別を示します。
完成した仕事と修正費用を測る
Google は開発期間の短縮、事務時間の節約、転換率改善など、採用状況と顧客成果を報告しています。企業が示した特定業務の例であり、制限のない委任に対する再現可能な成功率ではありません。商品カタログ案内と自由度の高い従業員業務では、失敗の範囲が異なります。
資料準備、完了、事実修正、レビュー時間、ポリシー違反、意図しない行為、障害復旧まで試行全体を評価します。予算上限で作業を止められても価値は証明されません。モデル振り分け、子エージェント利用、人の手直しを総費用に含め、中断したタスクが別 ID で支出を続けられないかも確かめます。
長期的な購入判断は、利用が増えても制御層を理解できるかです。試行を広げる前にスキル、記憶、評価、ポリシーのエクスポートを試します。他社モデル対応は企業文脈の移植性を自動的には意味しません。統一画面で委任が身近に感じられるからではなく、実測の完了と規則遵守が正当化する場合だけ権限を拡大します。