Google Cloud、Gemini Enterprise Agent Platformを一般提供へ。ただし真の課題は制御にある
Google Cloudは7月29日、拡張版Agent Platformを発表してからわずか3カ月後に、Gemini Enterpriseの複数機能を一般提供した。今回のリリースにより、永続メモリ、7日間の実行、エージェントID、ガバナンス、評価、可観測性が、より広範な本番利用に対応する。対立軸は明確だ。自律稼働が長くなるほど価値は高まる一方、ソフトウェアが重大な誤りを犯す時間と権限も増える。
これは単なるエージェント構築ツール群ではない。Googleは、AIモデルと、それが変更し得る企業システムとの間に位置する運用レイヤーを提供しようとしている。このレイヤーには、コンテキストの保持、権限の割り当て、操作の記録、ポリシーの適用、そして数日間にわたるワークフロー全体での成果測定が求められる。
AmazonとMicrosoftも、それぞれBedrock AgentCoreとMicrosoft Foundryを通じて、同じ制御ポイントを狙っている。競争の中心は、どの企業が最も高性能なモデルを提供するかだけではなくなった。セキュリティチーム、開発者、事業責任者が承認できる水準まで、自律的な業務を管理可能にできるクラウドはどこかが、ますます重要になっている。
Google Cloud、エージェントのプレビュー版を本番プラットフォームへ
今回のリリースにより、Gemini Enterprise Agent Platformは野心的なフレームワークから、企業が導入・統制できる運用システムへと近づく。
Googleは4月22日、Vertex AIの進化形として現行プラットフォームを発表した。掲げた目的は、モデルへのアクセス、エージェント開発、デプロイ、セキュリティ、最適化を単一の環境に統合することだった。同社はまた、今後のVertex AIサービスとロードマップの更新は、独立した製品ラインではなくAgent Platformを通じて提供するとしていた。
3カ月後、Googleは中核となる7つの機能を一般提供した。Agent Memory Bankはセッションをまたいで構造化されたコンテキストを保持する。Agent Runtimeは最大7日間に及ぶ非同期処理をサポートする。Agent Identityは、アクセス制御と監査のために各エージェントへ専用IDを付与する。
Agent Gateway、Agent Registry、Agent Evaluation、Agent Observabilityが制御レイヤーを完成させる。これらは連携して、ツール接続の管理、デプロイ済みエージェントのカタログ化、挙動の測定、実行の追跡を担う。GoogleはAgent Platform updateでこれらの機能を説明し、エージェントを安全に拡張するという観点から今回のリリースを位置付けている。
最も目立つ変更は、7日間のランタイムだ。従来のチャットボットはセッション内で応答し、次のリクエストを待つ。長時間稼働するエージェントは、営業プロセスの管理、サプライチェーン状況の監視、オンボーディングプロセスの数日間にわたる調整を担える。
この永続性は、エンジニアリング上の課題を変える。エージェントには、永続的な状態、復旧ロジック、権限境界、そして各操作の記録が必要になる。ユーザーがアプリケーションを閉じた後も同じプロセスが稼働し続ける場合、一時的なモデルエラーはより深刻な問題になる。
Memory Bankは、選択した事実を構造化スキーマに抽出することで、この課題の一部に対応する。エージェントに会話ログのすべてを再構築させることなく、設定、アカウント履歴、過去の判断を保持できる。Googleによれば、この設計は長期間にわたる処理で低レイテンシーのパーソナライゼーションを支える。
保存されたメモリと生の会話履歴の違いは重要だ。会話ログには、無関係な詳細や古くなった指示を含め、発言されたすべてが含まれる。構造化メモリは、今後も有用であり続けることを意図した情報を選択する。ただし、その選択プロセス自体が新たな障害点にもなる。システムが誤った推論を保存する可能性があるからだ。
そのためGoogleは、ランタイムとメモリを組み合わせて提供している。ランタイムが処理を継続させ、Memory Bankがそのコンテキストを利用可能な状態に保つ。どちらの機能も単独ではエージェントの信頼性を保証しないが、組み合わせることで、単一リクエストを超えるワークフローに開発者が取り組めるようになる。
今回のリリースでは、Googleのモデルだけで構築されるエージェントを超えて、プラットフォームの対象範囲も広がる。発表時、GoogleはModel Gardenを通じて、200を超える自社製、サードパーティ製、オープンモデルにアクセスできるとしていた。この選択は、顧客が別のプロバイダーのモデルを選ぶ場合でも、Googleがデプロイとガバナンスを制御したいことを示している。
この戦略により、Agent PlatformはGeminiの配布チャネル以上の意味を持つ。Googleはこれを、異種混在のエージェント群のためのインフラとして位置付けている。組織がそのID、レジストリ、ゲートウェイ、モニタリングサービスを、こうしたエージェント群に共通する統制機能として扱うなら、プラットフォームは成功する。
Google Cloudがエージェント制御で競争する理由
企業の購入判断を制約する要因は、モデルの利用可能性ではなく、エージェントの操作に伴う運用リスクへと移りつつある。
試作段階のエージェントは、限定的なデータセットと少数のツールで動作できる。本番環境のエージェントは、顧客記録、社内アプリケーション、認証情報、承認フロー、コンプライアンス要件に直面する。接続が1つ増えるごとに、エージェントの有用性と潜在的な被害範囲の両方が拡大する。
Google Cloudは、エージェント専用に設計されたIDモデルでこれに対応している。Agent Identityは、単にサービスアカウントを再利用するものではなく、ネイティブなアイデンティティおよびアクセス管理のタイプだ。Googleによれば、実行環境にアクセスを紐付け、最小権限を適用し、IDライフサイクルを管理し、否認防止可能な監査記録を生成する。
最小権限とは、定義されたタスクに必要なアクセスだけを付与することを指す。この考え方自体はよく知られているが、エージェントでは実装が難しくなる。エージェントの計画は実行中に変わり得るうえ、広範な目的を追求する中で複数のツールを呼び出せるためだ。
従来のサービスアカウントは、アプリケーションが変更または廃止された後も有効なまま残ることが多い。チームが統合を追加するにつれて、権限が蓄積する可能性がある。Googleの発表では、Best Buyが、孤立したアカウント、不明確な所有権、拡大する権限を繰り返し発生する問題として挙げている。
専用のエージェントIDは、説明責任をより明確な単位にする。管理者は、どのエージェントが操作したのか、何にアクセスしたのか、誰が所有者なのか、どの実行環境が操作を認可したのかを確認できる。人が各ステップを承認せずにエージェントが判断を下す場合、この可視性は不可欠になる。
Agent Gatewayは、その次の境界に位置する。エージェント、モデル、ツール間のやり取りを一元化する。管理者はID条件や自然言語ルールを適用でき、Model Armorはプロンプトインジェクション、ツールポイズニング、データ漏洩についてトラフィックを検査する。
プロンプトインジェクションは、悪意のある、または信頼できないコンテンツがエージェントの指示を操作することで発生する。ツールポイズニングは、侵害されたツールの説明や応答がエージェントの挙動を変えることを指す。エージェントがファイルへのアクセス、メッセージ送信、記録の更新、ソフトウェアの変更を行える場合、いずれの攻撃もより重大な結果を招く。
Agent Registryは、別の問題である組織内の無秩序な拡散に対処する。企業全体のエージェント、サーバー、接続をカタログ化する。チームは既存コンポーネントを見つけられ、管理者は所有者の特定とデプロイの監視を行える。
レジストリが、重複または安全でないエージェントを自動的に停止するわけではない。直接的な貢献は可視化にある。組織の中央チームが存在を把握していないソフトウェアに対し、一貫した統制を適用することはできない。
Googleのタイミングは、パイロットプロジェクトと統制された本番システムの隔たりが広がっていることを反映している。多くのチームは、モデル、プロンプト、複数のAPIを使って有用なエージェントを組み立てられる。一方で、ID、メモリ、評価、インシデント調査のための共通システムを備えるチームは少ない。
このギャップはクラウドプロバイダーに圧力をかける。顧客は、既存インフラと統合できる運用統制機能を好む。IDポリシー、ロギングシステム、ネットワーク制御、データサービスは、すでにクラウド環境内に存在する。そうした基盤を再利用できるなら、エージェントプラットフォームの魅力は高まる。
同じ力学は、独立系エージェントフレームワークにも圧力をかける。オープンなフレームワークは、開発者に移植性と柔軟性を提供できるが、企業チームには依然としてランタイムとガバナンスの基盤が必要だ。Googleはオープン標準とAgent Development Kitをサポートしているが、マネージド運用レイヤーは自社クラウドのより深い利用を促す。
したがって戦略上の賞品は、モデル利用量を超える。勝者となるプラットフォームは、企業がエージェントを登録し、権限を付与し、トレースを確認し、性能を判断するための標準的な場所になり得る。こうした統制機能がワークロードを取り囲むと、その移行はより複雑になる。
メモリ、ID、評価を結び付ける仕組み
Googleの中核的な賭けは、実行、権限、コンテキスト、測定が1つの制御プレーンを共有するとき、自律エージェントは管理可能になるというものだ。
Agent Runtimeは実行環境を提供する。Memory Bankは選択されたコンテキストを維持する。Agent Identityは、システムが誰を行為者として扱うかを決定する。Agent Gatewayはモデルとツールへのアクセスを統制し、Registryは何がデプロイされたかを記録する。
EvaluationとObservabilityがそのループを閉じる。Observabilityは、推論トレース、ツール利用、レイテンシー、実行挙動を含め、エージェントが何を行ったかを記録する。Evaluationは、結果が期待される基準を満たしたかを問う。
Googleは両機能を1つのエンジンに統合している。開発者は、構築時とデプロイ後に同じ測定ロジックを使用できる。同社によると、評価の選択肢には、事前定義済みメトリクス、カスタムPython関数、モデルベースの評価者、Google DeepMindと開発した適応型ルーブリックが含まれる。
この一貫性は重要だ。オフラインベンチマークは、実際の環境を十分に表せないことが多い。テストデータセットでは、すべての顧客リクエスト、変化するツール応答、権限状態を予測できない。オンライン評価は、リリース後の性能低下や挙動ドリフトを特定できる。
挙動ドリフトとは、エージェントの明示された目的が変わらなくても、結果が時間とともに変化することを意味する。モデル更新、改訂されたプロンプト、新たなデータソース、変更されたツールが、その変化を引き起こし得る。継続的なモニタリングは、チームが変化の始点を特定する助けとなる。
ただし、評価によって主観的判断がなくなるわけではない。モデルベースの評価者は、評価を行うモデルのバイアスや弱点を引き継ぐ可能性がある。カスタムメトリクスは、容易に測定できる代替指標を最適化する一方で、重要なビジネス成果を見逃す場合がある。
本番運用チームには、明確な成功基準がなお必要だ。顧客サポートエージェントであれば、解決の質、ポリシー遵守、エスカレーションの正確性、顧客の負担によって測定できる。応答速度だけに焦点を当てると、自信に満ちているが誤った回答を報いることになりかねない。
評価が運用上のアクションを引き起こせる場合、統合アーキテクチャはさらに有用になる。スコアの低下を受けて、エージェントの権限を縮小したり、作業を人間に引き継いだり、ワークフローを停止したりできる。Googleの発表はモニタリング機能を説明しているが、顧客は依然として適切な介入ポリシーを設計する必要がある。
AT&Tは、メモリに関する具体例を示している。同社によると、営業エージェントはMemory Bankを用いて過去の顧客対応から事実を統合し、間が空いた後でも会話を再開できるようにしている。また、アプリ、音声、Webチャネルをまたぐ継続性の実現にも取り組んでいる。
この事例は、利点とリスクの両方を示している。記憶されたコンテキストにより、顧客は同じ情報を繰り返す必要がなくなる。一方で、不正確または過度に広範なメモリは、チャネルをまたいで伝播し、その後の判断に影響を与える可能性もある。
Commerzbankは、ガバナンスの側面を示している。同銀行は、発見可能性、ポリシー適用、アクセス管理、可観測性、監査のために、Agent RegistryとAgent Gatewayを評価しているという。その関心は、中央集約型のレイヤーが規制対象の組織にとってなぜ魅力的なのかを示している。
WellSkyは、中央集約型のレジストリを使用して、エージェントをカタログ化、バージョン管理し、そのライフサイクル全体で管理しているとしている。同社はこのカタログをコンプライアンスポリシーおよび本番承認と連携させている。これは消費者向けAI機能というより、ソフトウェア資産管理に近い。
CodeMenderは、同じ仕組みをソフトウェアセキュリティへと拡張している。Googleはこれを、コードの脆弱性を発見、検証し、修正案を提示する管理型エージェントと説明している。中核となる推論はクラウドで実行される一方、コンパイル、テスト、エクスプロイトのシミュレーションは、顧客が管理するサンドボックスまたは分離された仮想マシンで実行される。
CodeMenderの設計には、人間による承認の工程が残されている。開発者は変更案をローカルdiffとして受け取り、エージェントが本番リポジトリへ直接コミットすることはない。Googleは、顧客のコードを基盤モデルの学習に使用しないとも述べている。
この境界は示唆に富む。CodeMenderは分析とパッチ作成を自動化するが、開発者の責任を取り除くものではない。誤った変更が新たな脆弱性を生んだり、本番環境を混乱させたりしかねない箇所で、人間によるレビュー工程が自律性を的確に制限している。
知識集約型のエージェントにも、同様の境界が必要だ。チームは検索可能なナレッジベースを用いて社内の根拠情報を整理できるが、検索機能だけでエージェントの行動が許可されるわけではない。コンテキスト、権限、検証は、依然として別個の設計判断である。
AWSとMicrosoftも同じ制御レイヤーを構築している
Googleの機能群が差別化されるのは、競合のないカテゴリーによるものではなく統合によるものだ。最大手クラウド競合各社も、現在では比較可能なエージェント基盤を提供している。
Amazon Bedrock AgentCoreは、エージェントのロジックと管理型インフラを分離する。そのRuntimeは、分離、スケーリング、セッション、認証ゲート、可観測性の仕組みを提供する。開発者はオーケストレーションループの制御を維持し、Memory、Gateway、Identityなどのサービスを接続できる。
AgentCore runtimeは、異なるフレームワークで書かれたコードをホストできる。このアプローチは、単一のエージェントフレームワークを採用せずに管理型インフラを利用したいチームに訴求する。また、Amazonの競争上の対応をGoogleのプラットフォームと直接比較可能にしている。
AWSは、自動化ワークロード向けの専門的なID・認証情報サービスを提供している。IDに関するドキュメントによれば、AgentCore Identityは認証、認可、サードパーティ認証情報、監査証跡をサポートする。そのワークロードIDは、エージェント固有の属性を加えつつ、確立されたIDパターンに従っている。
Microsoft Foundry Agent Serviceも、ランタイム、オーケストレーション、ID、安全性、可観測性を組み合わせている。その管理型ランタイムはセッションを分離でき、Microsoft EntraがIDとロールベースのアクセス制御を提供する。Application Insightsはトレースと本番監視を支援する。
Microsoftは、Microsoft 365とCopilotを通じた追加の配布面で優位性を持つ。すでにEntra、Teams、SharePoint、Microsoft 365を使用している組織は、Foundryを既存の業務環境の拡張として捉えられる。GoogleもGoogle Workspaceおよびクラウドデータ製品を通じて、同様の主張を展開できる。
Microsoftは、一部の外部ホスト型エージェントについて、可観測性と評価のために登録することも可能にしている。外部エージェントの制御機能はOpenTelemetryトレースを使用し、Foundryがランタイムをホストまたは呼び出すことなくエージェントを監視できるようにする。外部エージェント向けの人間による評価やレッドチームスキャンなど、関連するいくつかの機能は引き続きプレビュー段階にある。
したがって、3つのプラットフォームは同じ論点の異なる形を反映している。エンタープライズエージェントには、管理された実行環境、永続的なコンテキスト、ID、ツールガバナンス、監視が必要である。クラウド各社は、これらのサービスをすべてのエージェントを支える標準基盤にしたいと考えている。
Googleの優位性は、新たに利用可能になったスタックの一貫性にある。Runtime、Memory Bank、Identity、Gateway、Registry、Evaluation、Observabilityが、単一の製品群に収まっている。Gemini Enterpriseは、制御されたアプリケーションを通じてエージェントを従業員に配布することもできる。
課題は、統合されたスタックがより優れた運用成果を生むことを証明する点にある。類似した機能名が、より高い信頼性を示すわけではない。顧客は、統合の品質、ポリシーの精度、インシデント対応、地域での利用可能性、フレームワークのサポート、各システムの運用に必要な労力を評価するだろう。
ポータビリティも、依然として未解決の問題である。Googleは、Agent Platformがサードパーティ製モデルとオープン標準をサポートするとしている。しかし、そのIDタイプ、メモリスキーマ、レジストリ、評価エンジン、ゲートウェイポリシーを中心に構築されたエージェントは、移行コストが高くなる可能性がある。
AWSとMicrosoftも同等の依存関係を生み出している。両社の管理サービスは、顧客に代わってプラットフォーム固有の選択を行うことで、エンジニアリング作業を減らす。そのトレードオフはクラウドコンピューティングでは一般的だが、自律型エージェントでは、ガバナンスデータや行動履歴もプロバイダーにひも付くため、重要性が増す。
したがって企業は、モデルのポータビリティと運用上のポータビリティを区別すべきである。エージェントの背後にあるモデルの切り替えは、設定変更で済むかもしれない。一方で、そのID履歴、永続メモリ、評価記録、ゲートウェイポリシー、監査証跡を移すことは、より大規模な移行となる。
競争の行方は、最も長い機能リストによって決まるわけではない。セキュリティレビューの通過と、信頼できる本番動作の維持に必要な作業を、プラットフォームがどれだけ削減できるかにかかっている。その成果には、ローンチ発表を超える証拠が必要だ。
未解決のリスクは、ガバナンスが追随できるかどうかだ
エージェントの制御機能は既知のリスクを減らすが、より長い実行時間とより広いツールアクセスは、ダッシュボードだけでは自動的に解決できない障害モードを生み出す。
7日間稼働するエージェントには、古いデータ、矛盾する指示、期限切れの認証情報、予期しないツール動作に遭遇する機会が増える。また、初期のミスを後続の判断によって増幅させる可能性もある。したがって、ランタイムの継続時間は能力であると同時に、リスク増幅要因でもある。
永続メモリは別の緊張関係を生む。エージェントが好みや過去の判断を記憶すれば、パーソナライゼーションは向上する。一方で、システムが何を抽出すべきか、その情報をどれほど保持すべきか、ユーザーがどう修正できるかをチームが判断しなければならず、ガバナンスはより難しくなる。
構造化スキーマは規律をもたらすが、スキーマ設計はポリシー上の選択である。営業エージェントは、機微な個人情報を保持せずに顧客アカウントの製品関心を把握する必要があるかもしれない。社内エージェントは、すべての推測的なコメントを確定事項として扱わずに、プロジェクトの決定事項を把握する必要があるかもしれない。
Agent Identityは、どのソフトウェアアクターがアクションを実行したかを示せる。しかし、それだけでなぜそのアクションが起きたかを説明できるとは限らない。完全な調査には、エージェントへの指示、モデルのバージョン、取得されたコンテキスト、ツールの応答、メモリ状態、ポリシー判断、評価結果が必要になる可能性がある。
可観測性は、その証拠の多くを収集できる。しかし、すべてを記録すれば、プライバシーとストレージに関する懸念が生じる。詳細な推論トレースには、顧客情報、機密文書、機微なツール出力が含まれる可能性がある。
チームは、どのトレースを安全に保持できるか、誰がそれを閲覧できるかを決めなければならない。また、法的義務に整合する保存期間とマスキングポリシーも必要となる。中央集約化はこれらの選択の適用を支援するが、選択自体を簡単にするものではない。
自然言語によるゲートウェイルールも、同様に慎重な検討が必要だ。ポリシーを表現しやすくする一方で、セキュリティ制御は敵対的な条件下でも予測可能に動作しなければならない。組織は、同等の要求に一貫した判断が下されるか、ポリシーの競合時に安全に失敗するかをテストすべきである。
Googleは、Model Armorがプロンプトインジェクション、ツール汚染、データ漏えいへの防御を支援するとしている。こうした保護機能は、エージェントが安全であることの証明ではなく、多層的なシステムにおける制御策として扱うべきだ。あらゆる悪意ある指示や侵害された統合を予測できるフィルターは存在しない。
Googleの発表に含まれる顧客のコメントは、心強いものではあるが限定的だ。これらは、独立した比較測定ではなく、選定された導入事例や評価を説明している。この更新では、プラットフォーム全体のエラー率、セキュリティインシデント率、運用労力の定量的な削減は示されていない。
新たに利用可能になった製品として、この欠如は理解できる。しかし、購入者は一般提供開始を、すべてのワークロードで成熟した性能を示す証拠として扱うべきではない。最も強力な検証は、測定可能な制御の下で継続的に本番利用されることから得られるだろう。
影響の大きいアクションには、人間によるレビューが依然として必要である。CodeMenderは、開発者にパッチの承認を求めることで、この原則を示している。金融送金、アカウント閉鎖、本番環境の変更、法的に重要なコミュニケーションには、同様に明確な境界が求められる。
適切な自律性の水準は、可逆性に依存する。アクションの確認と取り消しが容易であれば、エージェントにはより大きな自由を与えられる。不可逆的な判断や外部に影響する判断には、より狭い権限、より強固な評価、信頼できるエスカレーションが必要となる。
企業には、プラットフォームチーム以外の責任主体も必要だ。セキュリティ担当者はアクセスルールを定義でき、事業責任者は許容される成果を定義する。法務・プライバシーチームは、どの情報をメモリまたはログに取り込めるかを決める。
責任の共有がなければ、Agent Registryは、誰も積極的に統治しないシステムのカタログになるおそれがある。評価ダッシュボードは、対応プロセスなしにスコアを生み出しかねない。ID記録は、インシデント後の帰属を確立できても、インシデントを防げるとは限らない。
Googleは、信頼できるコントロールプレーンに必要なコンポーネントを揃えた。残る問いは、組織がそれらのコンポーネントを強制力のある運用慣行へと変えられるかどうかだ。技術は判断を可視化できるが、説明責任は依然として人にある。
Gemini Enterprise拡張後に注目すべき点
次の段階は、さらなるエージェントのデモではなく、実際の導入、検証されたガバナンスの成果、競合他社の対応によって測られる。
最初の指標は、7日間のワークフローに関する本番環境での証拠である。顧客は、完了率、介入頻度、復旧動作、複数ステップにわたって連鎖する失敗の件数を記録すべきだ。信頼性の高い長時間動作が実証されれば、Agent Runtimeが短いチャットセッションを超えるというGoogleの主張は強まる。
完了率が低ければ、逆の方向を示すことになる。永続的な実行環境の到来が、計画の信頼性を上回る速さで進んでいることを示唆するだろう。重要なのは、エージェントが7日間稼働し続けるかではなく、定められた範囲内で有用な作業を完了できるかである。
2つ目の指標は、Agent IdentityとGatewayが監査やインシデント時にどのように機能するかだ。企業には、権限が適切に限定され、認証情報のライフサイクルが正しく終了し、調査担当者が重大なアクションを再構成できることを示す証拠が必要である。金融、医療、通信におけるレビューの成功は、Googleのガバナンスに関する主張を裏付けるだろう。
セキュリティチームは、導入の成功だけでなく、防止された事象も確認すべきである。有用な開示には、ブロックされたインジェクションの試行、拒否されたツール呼び出し、ポリシーの競合、不正動作するエージェントを特定するまでに要した時間が含まれる。集計レポートは、顧客の詳細を公開せずに購入者が制御策を比較する助けとなり得る。
第三のシグナルは、AWSとMicrosoftの対応だ。両社はすでに、ランタイム、ID、メモリ、ゲートウェイ、オブザーバビリティのサービスを提供している。次のリリースで、Googleが意味のある先行を確立したのか、それとも台頭しつつあるクラウドの基準に追随しただけなのかが明らかになる。
フレームワークとテレメトリーのポータビリティは、特に重要になる。外部ホスト型エージェントトレースへのMicrosoftの対応は、その一つのアプローチを示している。AWSは、マネージドランタイム内でのフレームワークの柔軟性を重視している。Googleは、統合された体験が顧客に実用的な選択肢を放棄させるものではないと示さなければならない。
購入担当者は、同じ代表的なワークフローで各プラットフォームをテストすべきだ。そのテストには、長時間実行タスク、権限変更、注入された指示、失敗したツール、メモリの修正、評価のリグレッションを含める必要がある。機能チェックリストだけでは、システム全体が負荷の下でどのように振る舞うかは分からない。
開発者は、プラットフォームが障害を理解可能なものにしているかも問うべきだ。トレースが有用なのは、結果を、それに責任を持つ指示、コンテキスト、ツール、ポリシー、モデルに結び付けられる場合に限られる。システムがこうした関係を整理しなければ、テレメトリーを増やすほど混乱が深まる可能性がある。
ナレッジワーカーにも関連する懸念がある。永続的に動作するエージェントは、メモ、文書、会議、過去の意思決定に対して、ますます行動を起こすようになる。AIワークフローは、こうしたコンテキストの整理に役立つ可能性がある。しかし、企業内でのアクションには、明示的な権限付与とレビューが必要だ。
Google Cloudは現在、主要なエージェント制御機能を一般提供に移行した。これは重要なプロダクト上の転換であり、自律型のエンタープライズ業務が解決済みであることの証明ではない。本当の試練は、エージェントが数日にわたって稼働し、システムの境界をまたぎ、開発者が予測していなかった条件に遭遇したときに始まる。
エージェントの権限を拡大する前に、実務的な問いを一つ投げかけるべきだ。チームは、そのエージェントが起こし得る最も重大な損害をもたらす行動を再現し、停止し、安全に元に戻せるだろうか。答えが不確かなら、まず新しい制御機能を使ってワークフローを限定すべきだ。一般提供によって、より広範な展開は可能になる。だが、それを責任あるものにするには、証拠、責任の所在、そして規律ある制限が不可欠だ。
