Gemini Computer Use は「クリックできる」より先に、危険操作の停止線を設計させる
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- AI が画面を見てクリックや入力までできるなら、支払い確定、送信、削除、設定変更のような操作は「押せるか」より「どこで必ず止めるか」が先に決まっていないと危ない。
- この guide の価値は、GUI 自動化の成功率を語ることではなく、危険操作の前で止める仕組みを execution loop の中に最初から入れている点にある。
- Google はそのために、操作理由を短く見せる `intent`、通常実行か確認必須か停止かを分ける `safety_decision`、人間確認へ上げる `require_confirmation` を用意している。
- さらに画面内の隠れた敵対的指示を拾う prompt injection detection もあるが、これは最後の保険であって、権限境界や確認 UI の代わりにはならない。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
このページの新しさは、GUI agent を単なる screenshot ベース自動化としてではなく、policy-aware execution として扱っていることです。Gemini 3.5 Flash 向けに、`intent` で「なぜその操作を選んだか」を出し、`safety_decision` で通常実行、確認必須、停止を分け、さらに screenshot 内の hidden adversarial instructions を走査する prompt injection detection まで用意しています。 つまり、モデルが action を出すだけでは loop が完結しません。実行側が座標変換、操作実行、新 screenshot 取得、確認 UI、停止処理を全部持つ必要があります。便利機能というより、責任分界がはっきりした execution loop です。
なぜ重要か
日本で browser agent や desktop agent を導入する時、現場は「人手削減」と「事故防止」を同時に求めます。前者だけ追うと、請求確定、予約変更、顧客情報送信のような高リスク操作まで自動化したくなります。この guide は、その誘惑に対して「危険操作前の停止」「未信頼画面の検知」「人間承認」を先に置くべきだと示しています。 また、Claude や OpenAI の computer use 系資料と比べると、Gemini は policy と escalation をかなり明示しています。GUI automation を demo ではなく、本番運用の境界設計として読む入口になります。
技術的ポイント
- 実装は continuous loop です。アプリ側が screenshot と prompt を送り、モデルが `function_call` を返し、クライアントが実行し、新 screenshot を `function_result` で返します。
- `intent` は操作理由の短い説明です。完全な安全証明ではありませんが、なぜ今その click を提案したのかを UI に出しやすくなります。
- `safety_decision` は regular、`require_confirmation`、blocked の判定を含みます。高リスク操作では、確認 UI を client 側で実装しないと意味がありません。
- prompt injection detection は screenshot のピクセルを走査し、隠れた敵対的指示を検知して止める opt-in 機構です。ただし page text 全体を安全化する保証ではありません。
- guide 自体が preview 機能として errors and security vulnerabilities の可能性を明示しています。重要業務や取り返しのつかない操作へそのまま入れる前提ではありません。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| intent | 操作意図 | その操作や手順を選んだ理由を短く示す説明。安全性の保証ではなく、確認の手がかり。 |
| safety decision | 安全判定 | 通常実行、確認必須、停止などを分ける判定。高リスク操作の停止線になる。 |
| require confirmation | 確認必須 | 危険操作の前で人間承認を要求する状態。GUI agent では実装側の確認 UI が必要。 |
| execution loop | 実行ループ | 観測、提案、実行、再観測を繰り返す流れ。GUI agent や tool agent の責任分界を決める。 |
| computer use | コンピュータ操作ツール | 画面を見てマウスやキーボード操作を進める tool。 |
| prompt injection | プロンプト注入 | 画面や web 内容に埋め込まれた指示で model の挙動がずれる危険。 |
試すなら
- まず GUI task を「読んで候補を出すだけでよい操作」と「確定前に必ず止める操作」に二分する。
- `require_confirmation` を受けた時の確認 UI と中断処理を先に作る。モデル接続より後回しにしない。
- screenshot に第三者文言が混ざる画面で prompt injection detection を試し、誤検知と見逃しの両方を観察する。
- 実アカウントではなく隔離環境で、ログイン、入力、送信、取消の失敗パターンを small eval として回す。
注意点
- `intent` があるから安全、ではありません。説明が付いても誤操作は起こりえます。
- prompt injection detection は opt-in です。有効化していない環境では、画面上の敵対的指示に対する追加防御が減ります。
- preview 機能なので、業務 critical な操作へそのまま拡張する前に、停止条件と責任者を明確にすべきです。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。