Gemini Spark が Chrome と統合、ログイン済みアカウントと保存パスワードで Web 作業を代行

要約

Google の常時稼働型エージェント Gemini Spark が、Chrome と直接統合されました。ユーザーの許可のもと、デバイス上のデスクトップ Chrome を使って Web 上の作業を代行します。

代行の中身が今回の要点です。Spark は、ログイン済みのアカウントと保存されたパスワードを利用します。公式が挙げている例は、保存しておいた物件の内見予約をスケジュールする、航空券の選択肢を調べる、といった「面倒な Web の用事」です。ログインが必要なサービスの中に入って操作するため、対象になる作業の範囲は「公開情報を調べる」よりずっと広くなります。実装としては、今年前半に Gemini in Chrome 向けに導入された auto browse 機能を利用しています。

エージェントに渡される権限が一段上がった、と捉えるのが正確です。これまでの「ブラウザを開いてページを読む」から、「ユーザーとしてログインした状態でサービスを操作する」へ移っています。人が普段ブラウザでやっていることのほぼ全域が、代行の対象になり得ます。

安全面については2つの仕組みが示されています。1つはプロンプトインジェクション攻撃に対する保護です。Web ページの内容を読んで動くエージェントは、悪意あるページに書かれた指示に従ってしまうリスクを構造的に抱えます。ログイン済みセッションを持った状態でこれが起きると被害が大きくなるため、対策が明示されているのは妥当です。もう1つは、決済のような機微な操作についてユーザーの確認を必要とする設計です。必要なときには制御をユーザーへ戻す、とされています。完全な自動化ではなく human-in-the-loop を残した構成です。

提供はまず米国から開始し、その後の拡大が予定されています。あわせて Google AI Pro の加入者向けに、160を超える国と地域で Gemini Spark 自体が利用可能になりました。Chrome 統合は米国先行ですが、Spark の提供範囲は大きく広がっています。

何が変わったか

• Gemini Spark がデスクトップ Chrome を操作して Web 作業を代行できるようになった
• ログイン済みのアカウントと保存されたパスワードを利用する（ユーザーの許可が前提）
• Gemini in Chrome 向けに導入された auto browse 機能を利用する
• プロンプトインジェクション攻撃に対する保護が組み込まれている
• 決済のような機微な操作ではユーザーの確認を必要とし、制御をユーザーへ戻す
• Chrome 統合の提供はまず米国から。今後拡大予定
• Google AI Pro 加入者向けに、160を超える国と地域で Gemini Spark が利用可能に
• 公式が挙げる用途例: 保存済み物件の内見予約、航空券の選択肢の調査

業務インパクト（一般企業向け）

企業で考えるべきことは、Chrome プロファイルという単位です。Spark はデバイス上のデスクトップ Chrome を使います。業務端末で業務アカウントにログインしている Chrome プロファイルであれば、そこに保存されたセッションと認証情報が代行操作の対象になり得ます。SaaS の管理画面、経費精算、社内ポータル、顧客管理ツール。日常的にログインしたままにしているものは多いはずです。

これは「AI にどのデータを見せるか」という従来の論点とは質が違います。データの閲覧ではなく、ユーザーとしての操作が委譲されます。SaaS 側から見れば、正規にログインしたユーザーの操作として記録されます。監査ログ上、人がやったのかエージェントがやったのかを区別できるかどうかは、サービスごとに異なるでしょう。

したがって、実務的な第一手は業務端末での利用可否を明示することです。Chrome 統合が米国先行である今は、日本国内の組織にとっては判断の猶予がある状態です。この間に、業務プロファイルと個人プロファイルの分離、業務端末での Gemini Spark の利用ポリシー、許容するなら対象業務の範囲を決めておくのが順当です。ブラウザの管理ポリシーで制御できる範囲がどこまでかも、あわせて確認が必要です。

プロンプトインジェクション対策が明示されている点は評価できますが、これは「対策している」であって「解決した」ではありません。Web ページの内容を読んで動作するエージェントにとって、これは構造的な攻撃面です。ログイン済みセッションを持つエージェントが不正な指示に従った場合の被害は、情報漏洩に留まらず操作の実行にまで及びます。リスク評価では、対策の存在を前提にせず、被害が起きたときの範囲で考えるのが安全です。

一方で、機微な操作でユーザー確認を挟む設計は、業務利用を検討するうえで前向きな材料です。完全自動ではなく確認を挟む構成なら、承認プロセスと組み合わせて運用できる余地があります。どの操作が「機微」と判定されるのかの粒度が、実際の使い勝手を左右します。

副業・個人活用視点

個人利用では、素直に効く場面が多い機能です。予約、比較検討、フォーム入力といった、判断はほぼ不要だが手数が多い作業は誰にでもあります。ログイン済みの状態で操作してくれるなら、これまで自動化しづらかった領域がまとめて対象になります。

副業の文脈で有望なのは、リサーチと事務作業の圧縮です。複数のサービスにログインして情報を集める、定型のフォームを埋める、といった作業は単価が上がりにくい割に時間を取られます。ここを代行できれば、単価の高い作業に時間を回せます。

ただし、クライアントのアカウントを扱う場合は話が別です。受託先の管理画面にログインしたプロファイルでエージェントを動かすのは、契約上も実務上も避けるべきです。何が実行されたかを自分で完全に把握できない状態で、他人のシステムを操作させることになります。クライアント作業用のブラウザプロファイルは分離し、そちらでは Spark を有効にしない、という運用が最低限の線引きになります。

パスワードの保存についても再考の機会です。Chrome に保存したパスワードがエージェントの操作対象になるということは、Chrome のパスワード保存範囲がそのままエージェントの権限範囲になるということです。重要度の高いアカウント（金融、主要な業務基盤）を Chrome に保存しているなら、専用のパスワードマネージャへ移すことを検討する価値があります。

現時点で Chrome 統合は米国先行なので、日本からはまだ試せません。ただし Google AI Pro での Spark 自体の提供国は大きく広がっているため、Chrome 統合が来る前に Spark の挙動そのものに慣れておくことはできます。