Google Android App Functionsはセキュリティの檻を築いたが、ほとんどのAIエージェントはまだ外にいる
GoogleはAndroidエージェントが他のアプリへ入るための管理された経路を構築した。しかし、ほとんどのユーザーは依然としてその経路を確認、管理、あるいは実用的に利用できない。Google Android App Functionsは、承認されたアシスタントがアプリケーションをまたいで特定の操作を検出・実行する方法を定義する。その一方で、広範なエージェントエコシステムが整うより先に、セキュリティアーキテクチャが到来している。
これは単なる未完成のAndroid機能ではない。Googleは、誰がアプリケーション内で操作できるのか、そうした主体が何を検出できるのか、そして開発者がどの操作を公開するのかを決めつつある。こうした選択は、メモの作成、写真の検索、メディアの再生、ショッピングカートの作成を担う将来のエージェントにとってのコントロールプレーンを確立する。
この仕組みは、画面を解釈してタップを模倣することでスマートフォンを操作するエージェントとはGoogleのアプローチを分ける。画面駆動型のシステムはアプリとの深い統合なしに動作できるが、レイアウトの変更や誤解を招くコンテンツの影響を受けやすい。App Functionsはよりクリーンな経路を提供するものの、利用できるのは承認されたエージェントと参加アプリに限られる。
Googleはすでに、GeminiがSamsung Gallery経由で写真を取得する例を含む限定的な統合を実演している。Android 17では、このフレームワークがさらに拡張される。それでも、一般的なAndroidユーザーが、サードパーティ製アシスタントや互換アクションで満たされた汎用エージェントダッシュボードを目にすることはない。
この隔たりが、表面的な矛盾を説明する。この檻が文字通り空というわけではないが、その中にいる存在は少数で、管理され、一般ユーザーには確認しにくい。Googleは周辺の市場を開く前に、まず入口を保護したのである。
Google Android App Functionsはエージェントのアプリへの入り方を変えた
App Functionsは、シミュレートされた画面操作を、Androidが識別・制限できる宣言済みの構造化操作へ置き換える。
アプリ機能とは、アプリケーションが承認された呼び出し元に提供する個別の操作である。メモアプリは「メモを作成」、メディアアプリは「曲を再生」を公開できる。エージェントは、アプリの表示インターフェースを操作する代わりに、構造化されたパラメータを送信する。
公式のApp Functions frameworkは、2つの主体を説明している。プロバイダーアプリがアクションを宣言し、信頼されたエージェントがそれを検出して実行する。AndroidはAppFunctionManagerおよび関連サービスを通じて、このやり取りを仲介する。
このアーキテクチャが重要なのは、視覚的なインターフェースが人間の判断のために設計されているからだ。人はボタンの位置が変わった、宛先がおかしい、購入金額が変わったといったことに気付く。自動化システムは、画面を誤読したり、表示コンテンツに埋め込まれた悪意ある指示に従ったりしても、操作を続けてしまう可能性がある。
構造化された機能は、利用可能な操作を絞り込む。エージェントは、あるアプリに1つの操作を依頼できるからといって、無制限の制御権を得るわけではない。プロバイダーは機能、その入力、返却する結果を定義する。
Androidは機能が有効かどうかも追跡する。機能が存在しない、見つからない、または利用できない場合、実行リクエストは失敗する可能性がある。これは、エージェントにアプリケーションインターフェースへの一般的なアクセスを許可するよりも明確な境界を作る。
このフレームワークは、Android 16に対応するAPIレベル36でプラットフォームに導入された。Googleのドキュメントでは、App Functionsは引き続きベータ版または実験的プレビューとして説明されている。Android 17では、ランタイム登録、アクティビティスコープの機能、更新されたアクセスレベル、より詳細な検出制御が追加される。
これらの変更は、Googleがアプリ横断のエージェント機能をOS上の課題として扱っていることを示す。各アシスタント開発者に独自の統合レイヤーを発明させているわけではない。プラットフォームは共通の識別子、メタデータ、状態管理、リクエスト、レスポンス、権限チェックを提供する。
違いは、シンプルなメモ作成シナリオでより明確になる。エージェントは「ホテルの住所を旅行メモに保存して」と指示を受ける。互換機能を検索し、対象アプリを特定し、タイトルと内容を渡し、結果を受け取る。
一方、画面駆動型エージェントは、アプリを開き、ボタンを探し、ノートブックを選択し、テキストフィールドにフォーカスし、内容を入力して保存を押す必要がある。視覚的な遷移が増えるごとに、曖昧さや操作の余地がシーケンスに入り込む場所も増える。
App Functionsは、エージェントが元の要求を理解したことを保証するものではない。また、アプリがその操作を安全に実装したことを証明するものでもない。だが、終わりのないインターフェース操作を、開発者が明示的に宣言した操作に置き換えることで、攻撃対象領域を縮小する。
これが最初の重要な変化だ。Androidには、アプリケーションについて語ったり画面を起動したりするだけでなく、エージェントがアプリケーション内で操作するためのネイティブな語彙が備わった。
2つ目の変化はより見えにくい。Androidは、通常のアプリケーションが単に想定できるものではない権限の背後に、アプリ横断の実行を置く。この判断により、App Functionsは便利なAPIからゲートキーピングシステムへと変わる。
権限モデルはGoogleとデバイスメーカーに主導権を与える
セキュリティ上の利点は高い能力を持つ呼び出し元を制限することにあるが、同じ制約によって独立系Androidエージェントは門の外に置かれる。
アプリケーションは、特別な権限なしに自らの機能を実行できる。パッケージをまたぐ実行は異なる。AppFunctionManagerでは、呼び出し元のエージェントが、他アプリ内の機能を検出または実行するために承認されたAndroid権限を保持している必要がある。
初期のAndroidフレームワークでは、EXECUTE_APP_FUNCTIONSはアシスタントロールを持つプリインストール済みまたはシステムアプリケーションに割り当てられていた。関連する信頼済み権限は、厳格に管理されたシステムインテリジェンスコンポーネント向けに用意された。permission historyは、Androidがエージェントの実行を特権ロールにどれほど明示的に結び付けたかを示している。
現在のフレームワークは、より細かなアクセスレベルへと進化している。開発者は機能を、アプリ自身、システム呼び出し元、またはAndroidに認定された呼び出し元向けに指定できる。ただし認定は、ダウンロードされたアシスタントがプロンプト表示後に取得できる通常のランタイム権限と同じではない。
この違いが、通常のスマートフォンでこの機能が存在しないように感じられる理由を説明する。ユーザーはカメラ、マイク、連絡先、位置情報へのアクセスを承認することに慣れている。しかし任意のアシスタントをインストールし、標準設定画面から幅広いApp Functions権限を付与できるとは限らない。
Googleは危険な底辺への競争を防いでいる。曖昧な同意プロンプトを1回承認するだけで、あらゆるアプリケーションが公開されたすべての機能を呼び出せるなら、攻撃的なアシスタントは広範な権限を求めるだろう。ユーザーは、どれほど多くの重大な操作が可能になるのか理解しないまま承認してしまう可能性がある。
アプリ横断のエージェントは、受動的なチャットボットとは異なるリスクを伴う。誤った回答は不便なだけである。誤った操作は、間違った相手へのメッセージ送信、私的文書の開示、記録の変更、取引開始につながりうる。
プロンプトインジェクションは、この違いをさらに際立たせる。エージェントは、ウェブページ、メッセージ、文書、画像を読む際に、ユーザーの意図を上書きするよう設計されたテキストに遭遇しうる。最近のmobile-agent researchでは、Androidのアクセシビリティ主導型エージェントが間接的なプロンプトインジェクションにさらされる可能性が特に検討されている。
権限の境界だけで、モデルを操作から完全に守ることはできない。しかし、どのアプリケーションがエージェントとして動作するか、またそのエージェントがどの機能へ到達できるかを制限できる。また、プロバイダーアプリに対して、引数の検証と独自のチェックを適用できる明確な実行経路を与える。
ただし、中央集権的な制御は別の問題も生む。GoogleとAndroidデバイスメーカーは、どのアシスタントが一級のアクセスを受けるかを実質的に裁定する存在となる。独立系エージェントは高度なプランナーを構築しても、公式フレームワークを通じてサードパーティアプリを統括する権限を持てない可能性がある。
この圧力は3つのグループに及ぶ。
まず、アシスタント開発者はAndroidの信頼済み経路に適格となるか、より間接的な手法に頼らなければならない。アプリケーションへのディープリンク、既存のintentの使用、アクセシビリティサービスを介した操作、開発ツールによる操作のシミュレーションは可能だ。だが、どれも同じ標準化されたアクセスを提供しない。
次に、アプリケーション開発者は、どの機能を公開する価値があるかを判断しなければならない。すべての機能には実装、テスト、入力検証、ライフサイクル処理、互換性対応が必要となる。小規模なアプリチームは、それらの機能を呼び出せるエージェントを十分なユーザーが持つようになるまで、導入をためらうかもしれない。
第三に、ユーザーは取引の両側を信頼しなければならない。アシスタントが要求を正しく解釈したこと、そしてプロバイダーアプリが予想外に広範な操作を実行しないことへの確信が必要だ。
これにより、よくあるプラットフォームのコールドスタートが生まれる。エージェントは利用を集める前に有用な機能を必要とする。アプリ開発者は、統合にエンジニアリング時間を割く前に活動中のエージェントを必要とする。GoogleはGeminiと主要パートナーによってこの循環を断ち切れるが、独立系の参加者は依然として同社のアクセス方針に依存する。
したがって、この設計はセキュリティの檻であると同時に、流通の門でもある。実行を制限することで当面の悪用を抑える一方、認定とプラットフォーム特権が、誰に意味のあるAndroid自動化を構築する機会があるかを形作る。
Googleの安全優先設計は導入の問題と衝突する
中核となるトレードオフは単純だ。より厳格な制御はAndroidエージェントの導入を安全にする一方、アクセスが遅いほど、現時点でフレームワークの有用性は下がる。
Googleは2026年2月、App Functionsを目立たないAPIリファレンスの域から公に押し出した。同社のAndroid開発チームはこの機能を初期段階と呼び、プライバシーとセキュリティを基盤的な設計上の優先事項として説明した。
同社は具体的な導入例も示した。Geminiはリクエストを解釈し、Samsung Gallery内のApp Functionを起動し、選択した写真をGeminiインターフェース内に返せる。Samsung integrationによると、この体験はGalaxy S26シリーズで始まり、より多くのSamsung端末へ拡大する計画となっている。
この例は、フレームワークが空のコードの殻ではないことを示している。同時に、展開がいかに限定的かも明らかにする。実演にはGoogleのアシスタント、大手Androidメーカー、ファーストパーティのギャラリーアプリケーション、そして選定された端末が関わっている。
広範なエコシステムは異なる姿になるだろう。ユーザーは適格なエージェントから選択できる。何千ものアプリケーションが文書化された操作を公開する。Androidは、どのエージェントがどの機能を呼び出したか、どのデータが移動したか、どの操作に確認が必要かを表示する。
既存のフレームワークは、その将来を構成する要素のいくつかを提供しているが、完全な公開体験までは提供していない。開発者はメタデータを定義し、機能を公開し、状態を監視し、実行リクエストを処理できる。Android 17では、より動的な登録とアクティビティ固有の動作も導入される。
GoogleのAndroid 17 updateには、テスト用エージェントアプリケーションと、開発向けのADBコマンドが含まれる。ADB、すなわちAndroid Debug Bridgeは、端末を制御・検査するための開発者向けインターフェースである。これらのツールは、消費者向けエージェントが広く対応する前に、プログラマーが機能を検証する助けとなる。
テスト支援は必要だが、導入と同義ではない。開発者は「メモを作成」が期待どおりのレスポンスを返すことを証明できても、実際にそれを呼び出すアシスタントが何人いるかは分からない。互換機能は、数百万台の端末で休眠したままになる可能性がある。
このフレームワークには共有スキーマも必要だ。2つのメモアプリが、似たアクションを異なる名前、引数、結果形式で公開する可能性がある。各プロバイダーが独自の契約を作れば、エージェントは増え続ける独自インターフェース群を理解しなければならない。
標準スキーマがあれば、エージェントは各アプリケーションを記憶するのではなく、能力に基づいて検索できる。Androidのメタデータモデルはスキーマ情報をサポートしているが、有用な相互運用性は依然として、開発者が一貫した定義へ収束できるかにかかっている。
ユーザーコントロールも、未解決の層として残されている。アプリは自らの機能の有効状態を維持でき、より新しいメタデータでは異なるアクセスレベルを表現できる。しかし一般ユーザーには、実務的な疑問に答える分かりやすいモデルが必要だ。
Geminiはメモを作成できても、削除はできないのか。別の認定済みエージェントは、写真を外部共有せずに検索できるのか。承認は一度限りなのか、アプリごとなのか、機能ごとなのか、それとも機密性の高いリクエストごとなのか。問題発生後、ユーザーはアクション履歴を確認できるのか。
Googleは、こうしたコントロールと摩擦のバランスを取らなければならない。無害な操作のたびに確認を求めれば、エージェントの利便性は失われる。広いカテゴリーをまとめて承認すれば、リスクを隠しかねない。有用なシステムには、日常的な操作を迅速に進めつつ、不可逆的または機密性の高い手順の前では停止する仕組みが必要だ。
この問題は権限設計に似ているが、エージェントの意図はタスクの途中で変化する。カメラ権限は、既知のセンサーへのアクセスを許可する。エージェントはリストの読み取りから始め、複数のサブタスクを推論し、複数のアプリを参照し、購入を提案するかもしれない。重大な境界はワークフローの途中で現れる。
だからこそ、単一の権限よりもポリシーが重要になる。Androidは、呼び出し元のID、機能の範囲、プロバイダーのルール、ユーザー設定、取引の機微度、現在のコンテキストを組み合わせる必要がある。
「檻」という比喩が捉えているのは、この設計の一部にすぎない。Androidは、信頼できない単一プロセスを箱の中に隔離しているわけではない。狭く公開された扉を通じて信頼された呼び出し元を調整し、各アプリケーションがその扉の向こうで何が起きるかの責任を保持する仕組みだ。
開発者にとって、当面の判断はなお不透明だ。Google Android App Functionsをサポートすれば、アプリは将来のエージェントワークフローに参加できる。一方で、配布、認定、ユーザー需要がまだ発展途上にあるベータインターフェースへの投資も意味する。
画面操作エージェントは立ち上げが速く、信頼を得にくい
Googleの主な対抗相手は別のモバイルプラットフォームではない。エージェントに人間のように画面を操作させるという近道だ。
画面操作エージェントは、より少ない提携関係で始められる。ピクセルやアクセシビリティツリーを読み取り、どこを操作すべきかを判断し、タップ、スワイプ、テキスト入力を生成する。人間がインターフェースを通じてタスクを完了できるなら、エージェントも同じ経路を試みられる。
この汎用性は魅力的だ。開発者は、すべての対象アプリケーションに機能の公開を求める必要がない。研究者は既存ソフトウェア全体でエージェントをテストでき、スタートアップは統合の交渉前に幅広い対応範囲を示せる。
Google自身のAndroid研究も、このアプローチの確立に貢献した。Android in the Wildデータセットには、複数のAndroidバージョンとデバイスタイプにわたり、30,000件の指示をカバーする715,000件のエピソードが含まれる。多様なインターフェースを通じて行動するシステムを訓練または評価するために必要な規模を示している。
しかし、広範な視覚的制御は、明示的な契約を推論に置き換える。エージェントは、各画面の意味、コンテンツの信頼性、操作によって意図した結果が生じたかどうかを判断しなければならない。
アプリ更新後にはボタンのラベルが変わることがある。ダイアログが想定した対象を覆うこともある。悪意あるページが、モデルが読み取る場所に指示を置く可能性もある。チェックアウトフローでは、最終確認前に手数料が追加されたり、商品が変更されたりすることもある。
人間もこうした状況でミスをするが、エージェントはそれをより速く、より大規模に繰り返しうる。バックグラウンドで動作し、アプリケーションをまたいで処理を続け、ユーザーが直接確認しない情報を扱う可能性がある。
App Functionsは、解釈を別の層へ移す。エージェントは引き続きユーザーのリクエストを解釈するが、各画面の操作方法を推論する必要はない。宣言された操作を選び、型付けされた情報を渡す。
これは、アプリケーションプログラミングインターフェースを使うことと、ブラウザ経由でWebサイトを自動操作することの違いに似ている。通常、APIはより高い安定性と明確な入力を提供する。ブラウザ自動化はAPIを持たないサービスにも到達できるが、レイアウト、セッション、コンテンツの変化に対応しなければならない。
構造化された経路は説明責任も高める。Androidは、呼び出し元パッケージ、対象機能、リクエスト、結果を特定できる。プロバイダーアプリは無効な引数を拒否したり、独自の確認を求めたりできる。プラットフォームポリシーは、機密性の高い機能を通常の機能とは異なる形で扱える。
こうした仕組みがあっても、モデルレベルの防御が不要になるわけではない。侵害されたエージェントは、誤った理由で許可済みの機能を呼び出せる。注意を欠くプロバイダーは、検証の弱い操作を公開する可能性がある。信頼された呼び出し元であっても、曖昧な指示を誤解することはある。
構造化された操作は、有害な行為の信頼性も高めうる。「支払いを送る」機能に到達した悪意あるエージェントは、混乱しやすいインターフェースを操作する必要がない。セキュリティ上の価値は、アクセスの制限、意図の確認、適切なタイミングでの確認要求に依存する。
だからこそ、EXECUTE_APP_FUNCTIONSをあまりに広く開放すれば、アーキテクチャ上の利点の多くが失われる。Googleは、標準のダイアログにこの権限を置くだけで問題が解決したと考えることはできない。プラットフォームには、認定ルールと、ユーザーが理解できる観測可能な挙動が必要だ。
同時に、アクセスを限定し続ければ、画面自動化を使おうとする圧力が生まれる。独立系アシスタントは、出荷を可能にする経路を選ぶ。公式の扉が利用できないままであれば、一部の開発者はアクセシビリティサービス、ADBベースのツール、デバイス自動化へ戻るだろう。
その結果、ポリシー上のパラドックスが生じる。Googleはエージェントにより安全な構造化経路を使わせたいが、より危険な代替手段を置き換えるだけの到達可能性も、その経路に持たせなければならない。
競合他社やオープンソースプロジェクトは、既存アプリ全体でより高い能力を示すエージェントを提供することで、この隙間を活用できる。プロバイダー統合を待たないため、デモではより多くのタスクをカバーできる可能性がある。Googleのシステムは、境界を強制するがゆえに制約が強く見えるかもしれない。
消費者はAPIドキュメントを通してこうしたアーキテクチャを評価しない。エージェントがリクエストを完了できるかどうかに注目する。画面操作型の競合製品が10個のアプリを扱える一方で、Geminiの構造化経路が2つしか対応していなければ、購入判断では抽象的な安全性より能力が優先されるかもしれない。
開発者も、AI workflowsを設計する際に同じ緊張関係に直面する。信頼できる自動化は、予測可能な入力、制御されたアクション、可視化されたレビュー地点に依存する。汎用的なインターフェース制御は到達範囲をもたらし、構造化された機能はより明確な保証を提供する。
Googleは、Androidエージェントを無制限のリモートコントロールに変えることなく、この能力差を埋めなければならない。App Functionsはその仕組みを提供するが、開発者が実際に利用するかどうかを決めるのは、普及とアクセスに関するポリシーだ。
本当の試金石は、檻がマーケットプレイスになるかどうかだ
次の段階は、フレームワーククラスの追加ではなく、アプリの参加、エージェントのアクセス、ユーザーに見えるコントロールにかかっている。
最初に注目すべきシグナルは、App Functionsを公開する本番アプリケーションの数と多様性だ。Samsung Galleryは、写真の取得が個人データと認識しやすいユーザータスクに関わるため、有用な実演例である。しかし、コミュニケーション、生産性、金融、ショッピング、旅行、メディアにまたがる幅広い対応を示すものではない。
主要アプリケーションは、宣伝用のデモアクション以上のものを公開する必要がある。反復的で実用的なワークフローが、このフレームワークがユーザーの有意義な労力を削減できるかを示す。メモの作成、特定の写真の検索、プレイリストの開始、カートへの商品の追加は、初期の試験となる。
複数の独立系アプリ開発者が動作する統合を発表すれば、普及はGoogleのアプローチを強化する。対応がGoogleソフトウェア、端末メーカーのアプリケーション、一部のローンチパートナーに集中したままであれば、その主張は弱まる。
2つ目のシグナルは、Google以外のエージェントに対するアクセスだ。Androidの新しいメタデータはAndroidによる認定済みの呼び出し元に言及しており、単一のファーストパーティアシスタントを超える経路を示唆している。決定的な問いは、認定に何が求められるのか、そして適格なサードパーティエージェントが妥当な条件で競争できるのかという点だ。
信頼できるプログラムには、公表された基準、セキュリティ上の義務、認定取消の手続き、予測可能な審査が必要となる。開発者は、エージェントがどのようにアクセスを得るのか、どのような行為によってアクセスを失うのかを知るべきだ。
こうした詳細がなければ、権限システムはGeminiにとっての私的な配布上の優位性になりかねない。Googleは、厳格なアクセスがユーザーを守ると主張できる一方、競合他社は、同じルールがAndroidのデフォルトエージェントとしてのGoogleの地位を守るものだと主張できる。
複数の認定済みエージェントの存在は、セキュリティ優先という解釈を強めるだろう。ファーストパーティの排他性が続けば、ゲートキーピングという解釈を強める。フレームワークの正当性は、信頼要件と優遇アクセスを区別できるかにかかっている。
3つ目のシグナルは、ユーザー向けのコントロールおよび監査体験だ。Googleのより広範なGemini Intelligence rolloutは、スマートフォンや他のデバイスにまたがるプロアクティブな自動化を約束している。バックグラウンドでのアクションが増えるほど、可視性の重要性は高まる。
ユーザーは、どの機能が存在するのか、どのエージェントがそれらを呼び出せるのか、どの権限が有効なままなのかを確認する必要がある。また、エージェントが何をリクエストし、各アプリケーションが何を返したのかを説明する履歴も必要だ。
有用なコントロール画面は、低リスクな利便性と重大な権限を分けるべきである。曲を再生することに、メッセージの送信や注文の確定と同じ摩擦は必要ない。プラットフォームは、エラーが起こる前にその違いを伝えるべきだ。
確認設計が最も難しい部分になる。プロンプトが多すぎれば、ユーザーは何でも承認するようになる。少なすぎれば、意図しなかった行為にユーザーは驚かされる。コンテキストに応じた承認は、各ワークフローを中断の連続に変えることなく、明確であり続けなければならない。
Googleは、処理がどこで行われるかも説明すべきだ。一部の機能はローカルのアプリケーション状態に対して実行できる一方、アシスタントの推論にはクラウドサービスが関与する可能性がある。ユーザーは、いつデータがデバイスを離れるのか、どの主体がそれを受け取るのかを理解する必要がある。
フレームワークの状態制御は、緊急時の認可取り消しを支えられる。エージェントが予期せぬ動作をした場合、ユーザーは個別のアプリケーションを探し回ることなく、そのクロスアプリ権限を無効化できるべきだ。プロバイダーアプリも、機密性の高い機能を迅速に停止できるべきである。
開発者も運用ツールを求めるだろう。失敗した呼び出しのログ、スキーマ検証、互換性テスト、不正利用の報告、Androidバージョンをまたぐ明確な動作が必要になる。チームが本番環境でそれを運用・サポートできるようになって初めて、フレームワークはエコシステムになる。
Googleの段階的な展開には合理性がある。コントロールが整う前に無制限のクロスアプリ自律性を公開すれば、予測可能な失敗を招くだろう。同社は代わりに、普遍的なアクセスを有効にする前に、権限チェック、プロバイダー契約、テストツール、拡張されるプラットフォームAPIを構築してきた。
懐疑的な見方にも同様に合理性がある。呼び出し可能な機能が少ない安全なフレームワークは、消費者に大きな価値を提供しない。また、厳しく制御された経路は、独立系開発者を、フレームワークが置き換えるために設計されたはずの画面自動化へと押し戻しかねない。
したがって、Google Android App Functionsは、重要ではあるものの未完の移行段階に位置づけられる。Androidには現在、エージェントが限定された操作を発見し実行するためのネイティブな仕組みがある。しかし、この仕組みがオープンで競争的、かつ広く採用されるエージェント市場を支えられることは、まだ示されていない。
今後数カ月は、ローンチパートナー以外での本番導入、外部エージェント向けアクセスルールの公開、そしてユーザーが確認できる権限履歴に注目したい。これらの兆候によって、Googleが共有インフラを構築したのか、それともGemini向けの保護された専用レーンを用意したのかが明らかになる。
Androidの所有者にとって実務的な問いは、AIエージェントが画面を操作できるかどうかではない。実験的なシステムは、すでにそれが可能であることを示している。問われるのは、Androidがユーザーに実質的な制御を手放させることなく、エージェントが個人向けアプリをまたいで行動できるようにするかどうかだ。
開発者にとっては、この判断はより早く迫る。構造化して公開する価値のある、安全かつ有用な操作を見極め、どこで確認を求めるべきかを定義しなければならない。待つことで短期的な作業は避けられるが、ユーザーがインターフェースを開く代わりにタスクを委任し始めたとき、アプリが見えない存在になるおそれがある。
Googleは入口を設け、鍵を取り付けた。次に求められるのは、信頼できるエージェント、独立系開発者、そして一般ユーザーのすべてが、それぞれに必要な鍵を受け取れることを証明することだ。
