AIエージェントにブラウザ操作を任せる場合、統制の設計は「どこまで操作を許すか」の境界線の引き方で決まる。自律実行の便益は操作を任せる範囲に比例し、統制コストは監視すべき操作の種類に比例する。この2つのバランスを、実装可能な形で決めるのがガードレール設計である。
本記事では、AIエージェントのブラウザ操作を統制する際に決めるべき3要素（操作範囲の境界・実行承認の設計・監査ログの取得)を、実装の選択肢と組織承認の前提を含めて説明する。国内の指針としてはAI事業者ガイドライン（第1.2版）（総務省・経済産業省（2026年3月31日公表））が参照される。
AIエージェントのブラウザ操作で統制が必要になる理由
AIエージェントがブラウザを操作する場合、人が画面を見て判断する代わりに、エージェントが要素を認識してクリック・入力・遷移を自律的に実行する。この自律性が統制対象になる理由は3つある。
第一に、操作の結果が外部システムへ不可逆な変更を加える可能性がある。フォーム送信、データ削除、権限変更など、取り消しのきかない操作をエージェントが実行した場合、その判断根拠と実行者を事後に特定できなければ、障害の原因調査と責任の所在が不明になる。
第二に、操作先のシステムが認証を要求する場合、エージェントに資格情報を渡す必要がある。資格情報の管理によっては、エージェント自体が認証突破の経路になり、本来その権限を持たないユーザーが操作を代行させる手段として使われる可能性がある。
第三に、操作の過程で画面に表示される情報をエージェントが認識する。個人情報や機密情報が含まれる画面を操作対象にする場合、その情報がエージェントのログや学習データとしてどこに残るかを制御しなければ、情報の取扱いに関する社内規程と矛盾する。個人情報保護委員会（生成AIと個人情報の取扱いに関する情報）（個人情報保護委員会）が公表する注意喚起も参考になる。
これら3つの理由から、ブラウザ操作を任せる範囲には境界が必要になる。境界の引き方によって、統制の設計が決まる。
操作範囲の境界を決める3つの軸
ブラウザ操作の範囲を制限する方法は、操作先・操作種別・操作者の3軸で構成する。この3軸の組み合わせが、許可する操作の境界線になる。
操作先による制限
操作を許可するドメイン・URLパターンをリストで定義する。社内システムのみを対象にするか、外部SaaSも含めるか、さらに外部の公開サイトまで許可するかで、リスクの種類が変わる。
社内システムのみに制限する場合、操作結果が内部データに与える影響は監査ログとバックアップで追跡できる。外部SaaSを含める場合、そのSaaS側のAPIまたは監査ログが取得できることを前提にする。外部の公開サイトまで許可する場合、操作結果の記録は取得できず、エージェントが取得した情報の内容も事前に予測できないため、操作後の情報をどう扱うかのルールが別途必要になる。
実装としては、プロキシ経由で許可リストに含まれるドメインのみ接続を通す方式、またはエージェント実行基盤側で操作先URLを検証する方式がある。前者は既存のネットワーク統制と整合するが、プロキシ設定の変更を伴う。後者はエージェント基盤の実装に依存し、基盤が提供しない場合は自前で検証ロジックを追加する必要がある。
操作種別による制限
読み取り専用の操作のみを許可するか、書き込みを伴う操作まで許可するかを分ける。読み取り専用とは、画面の閲覧・検索・ダウンロードなど、データの変更を伴わない操作を指す。書き込みとは、フォーム送信・データ削除・設定変更など、システム側の状態を変える操作を指す。
読み取り専用に制限する場合、操作によるリスクは取得した情報の取扱いに限定される。書き込みまで許可する場合、操作結果の妥当性を事前に検証する仕組み、または操作後に承認を得る仕組みが必要になる。
実装としては、エージェントが実行する操作の種類を監視し、送信・削除など特定のアクションを検出した時点で実行を停止する方式がある。ただし、操作種別の判定はDOM要素の種類や送信先URLから推定するため、誤検知と漏れの両方が発生する。完全な制御が必要な場合は、操作を記録してから実行する「記録→承認→実行」のフローに切り替える。
操作者による制限
エージェントに操作を委任できるユーザーを、役割・部署・権限で絞る。すべてのユーザーにブラウザ操作を許可すると、統制コストが利用者数に比例して増える。利用を特定の業務に限定し、その業務を担当するユーザーのみに操作権限を付与する設計にすれば、監査対象が絞られる。
実装としては、エージェント実行基盤のアクセス制御でブラウザ操作機能を利用できるユーザーを制限する方式、またはエージェントの公開範囲を特定のグループに限定する方式がある。前者は基盤の権限管理に依存し、後者は配布の仕組みに依存する。
実行承認の設計 事前承認と事後監査の使い分け
ブラウザ操作の実行を誰がどの時点で承認するかは、操作の頻度とリスクの大きさで決める。承認の方式は事前承認と事後監査の2つがある。
事前承認
エージェントが操作を実行する前に、操作内容を人が確認して承認する方式。操作の頻度が低く、操作結果が重大な影響を持つ場合に採用する。例えば、顧客データの一括削除、権限設定の変更、外部への情報送信など、誤操作のコストが高い操作がこれに該当する。
実装としては、エージェントが操作計画を生成した時点で実行を停止し、承認者へ通知を送る。承認者が内容を確認して承認すると、エージェントが操作を再開する。承認の判断材料として、操作対象のURL・操作種別・入力データを提示する。
事前承認の制約は、承認待ち時間が発生することである。リアルタイム性が求められる業務には向かない。また、承認者が操作内容を正しく理解できなければ、承認プロセスが形骸化する。承認者が判断できる粒度で操作計画を提示する設計が必要になる。
事後監査
エージェントが操作を実行した後、その記録を保存して定期的に監査する方式。操作の頻度が高く、個別の操作リスクが小さい場合に採用する。例えば、データの検索・集計・画面キャプチャなど、読み取り専用の操作がこれに該当する。
実装としては、エージェントが実行した操作の内容をログに記録し、操作先URL・操作種別・実行ユーザー・実行日時を紐づけて保存する。監査時には、操作ログを定期的にレビューし、想定外の操作先へのアクセスや、過剰な頻度の操作がないかを確認する。
事後監査の制約は、異常を検出した時点で操作が完了していることである。被害の拡大を防ぐには、異常検知のルールを事前に定義し、閾値を超えた操作を検出した時点でアラートを発する仕組みが必要になる。閾値の設定は、通常業務での操作頻度を基準にする。
監査ログの取得 何を記録し誰が閲覧するか
ブラウザ操作の監査ログは、操作内容の記録と実行者の紐付けの2つを満たす必要がある。記録する項目と閲覧権限の範囲は、組織の承認プロセスに依存する。
記録する項目
最低限の記録項目は、操作先URL・操作種別・実行日時・実行ユーザーの4つである。操作種別はクリック・入力・遷移など、DOM操作の種類で分類する。これに加えて、入力内容・取得したデータ・画面キャプチャを記録するかは、情報の機密性と監査の目的で決める。
入力内容を記録する場合、パスワードや個人情報が含まれる可能性がある。これを記録するには、記録データの暗号化と閲覧権限の制限が前提になる。取得したデータを記録する場合も同様である。画面キャプチャは操作の文脈を残せるが、ストレージ容量と閲覧時の情報漏洩リスクが増える。
実装としては、エージェント実行基盤が提供するログ機能を利用する方式と、エージェント側で独自にログを出力する方式がある。前者は基盤の仕様に依存し、記録項目を追加できない場合がある。後者は自由度が高いが、ログの保存先と保持期間を別途設計する必要がある。
閲覧権限の範囲
監査ログを誰が閲覧できるかは、組織の承認プロセスで決まる。監査目的でログを取得しても、その権限が社内で承認されなければ、ログは使えない。
例として、エンタープライズ企業におけるCopilot Studio／Power PlatformのAI基盤ガバナンス構築では、監査ログの取得をPurview前提で設計したが、監査ロールの付与が社内承認されなかった。メール等まで閲覧範囲が及ぶことが理由である。監査目的の大半はエージェント管理基盤へ載せ替えたが、「誰が誰に共有したか」の操作記録だけは代替手段がなく、残存リスクとして記録した。
このケースから、監査設計は「技術的に取得できるか」ではなく「その権限が社内で承認されるか」で決まることがわかる。ログの取得範囲を決める際は、閲覧権限の承認プロセスを先に確認し、承認が得られる範囲で設計する。承認が得られない項目は、残存リスクとして記録し、代替手段を検討する。
ガードレールの実装 統制装置の置き場所
ブラウザ操作の統制装置を実装する場所は、エージェント実行基盤の構造に依存する。統制の思想（入口は止めず出口で締めるガードレール型）は変えず、装置の置き場所を前提に合わせて組み替える。
環境分離による統制
エージェント実行基盤が環境（開発・検証・本番）の概念を持つ場合、環境ごとに操作範囲とコネクタの接続先を分離する。開発環境ではテスト用のダミーシステムにのみ接続を許可し、本番環境では本番システムへの接続を許可する。環境の昇格は承認フローを通す。
この方式は、環境の概念がある基盤では有効である。ただし、エンタープライズ企業におけるCopilot Studio／Power PlatformのAI基盤ガバナンス構築では、Copilotの有償ライセンスが対象組織のほぼ全員に配布された結果、全社展開の主経路は「Copilot Studioへ昇格」ではなく「Agent Builderのままギャラリーへ掲載」へ転換した。Agent Builderは環境の概念を持たず、コネクタDLPの対象外である。そのため、Copilot Studio環境側に置いた統制装置の上を、全社展開の主経路が通らなくなった。
この場合、統制の思想（入口は止めず出口で締めるガードレール型）は変えず、装置の置き場所を「環境」から「人（セキュリティグループ）とデータ（権限・ラベル）」へ再配置する方針で組み替えた。統制設計はライセンスの配布範囲という前提に依存している。前提が変われば、統制の思想ではなく装置の置き場所を組み替える。
権限とラベルによる統制
環境分離が機能しない場合、統制装置はユーザーの権限とデータのラベルに置く。具体的には、ブラウザ操作を実行できるユーザーをセキュリティグループで制限し、操作対象のデータに機密ラベルを付与して、ラベルに応じた操作制限を適用する。
例えば、機密度の高いデータを含む画面へのアクセスは、特定のセキュリティグループに所属するユーザーのみに許可する。そのユーザーが実行した操作ログは、通常より詳細な記録項目を取得し、閲覧権限も限定する。
この方式は、基盤が環境の概念を持たない場合に採用する。ただし、権限とラベルの管理は手動で行うと運用負荷が高いため、自動でラベルを付与するルールを定義するか、既存のDLP（データ損失防止）ポリシーと連携する設計が必要になる。
統制コストと利便性のバランス
ブラウザ操作の統制設計は、統制コストと利便性のバランスで決まる。統制を厳しくすれば安全性は上がるが、承認待ち時間や運用負荷が増え、エージェントの利便性が下がる。統制を緩めれば利便性は上がるが、異常操作の検出が遅れ、被害が拡大する可能性がある。
バランスを取るには、操作の頻度とリスクをマトリクスで整理し、高頻度・低リスクの操作は事後監査、低頻度・高リスクの操作は事前承認という形で割り振る。中間に位置する操作については、操作内容を記録してから実行し、異常検知のルールでアラートを発する方式を採用する。
統制の基準は固定せず、運用開始後のログをレビューして調整する。例として、エンタープライズ企業におけるCopilot Studio／Power PlatformのAI基盤ガバナンス構築では、90日間未使用のエージェントを一律で削除する基準を設けたが撤回した。半年に1回など低頻度で稼働するエージェントが存在するため、未使用期間による一律削除は成立しなかった。
このように、統制の基準は運用実態に合わせて修正する。初期設計で完璧を目指すのではなく、検証結果を材料に基準を決め、決定後に手順書を作る順序を守る。検証、決定、手順書の順序を崩すと手戻りが発生する。決定を急がせる前に、検証結果を材料として先に出す。