ブラウザー統合AI時代の企業ガバナンス: シャドー自動化を防ぐ実装指針

ブラウザー上でAIが要約・操作・提案を行う機能が、実験機能ではなく日常機能になりつつあります。Geminiのブラウザー統合や、MCP連携を含むAI操作機能の拡大は、企業にとって生産性の機会である一方、統制空白を一気に広げます。

参考: https://forest.watch.impress.co.jp/、https://www.itmedia.co.jp/news/。

なぜ既存統制が効きにくいか

多くの企業統制は、SaaS単位または端末単位で設計されています。しかしブラウザー統合AIは「閲覧コンテキスト」を横断して扱うため、従来の境界だけでは不足します。

代表的なギャップは次の通りです。

• 機密タブ内容が要約経由で外部に出る
• ユーザー意図と実行アクションの差分が見えにくい
• 入出力ログの保持条件が曖昧
• DLPがあってもAI経路を見逃す

まず整備すべきガバナンス基盤

データ分類と利用許可の紐付け

• public/internal: 要約・書き換え許可
• restricted: マスキング前提で限定許可
• regulated: AI操作を原則禁止

「部署単位で一律ON/OFF」より、データ分類で制御した方が事故と反発を減らせます。

IDとデバイスポスチャを連動

同じユーザーでも、管理端末と私物端末で許可レベルを変えるべきです。アクセス制御を端末状態とロールの積で評価します。

ログはメタデータ中心に

生プロンプトを全面保存すると逆にリスクが増えます。通常はメタデータ（誰が、どの分類で、何を実行したか）を保持し、インシデント時のみ限定的に詳細を参照する方式が安全です。

現実的な導入ステップ

1. エンジニア/サポートの小規模パイロット
2. 部門別の許可ユースケース明文化
3. 高リスク分類にdeny-by-default適用
4. 提供側仕様変更の四半期レビュー

全面禁止は現場で迂回経路を生みやすく、全面開放は統制不能になります。段階導入が最も再現性があります。

技術的に優先すべき対策

• ブラウザーポリシーで機能/拡張の制御
• 機密情報のインラインマスキング
• セキュアWebゲートウェイで未承認AIエンドポイント制限
• CASB/DLPとの連携で送信経路を可視化

効果測定の指標

• ポリシー配下で実行されたAI操作比率
• 高リスク操作のブロック件数と誤検知率
• 提供機能更新からポリシー反映までの時間
• 許可ユースケースでの作業短縮効果

ブロック件数だけで評価すると、利用価値を見誤って過剰規制になりがちです。

まとめ

ブラウザー統合AIに必要なのは抑圧ではなく「飼いならし」です。利用レーンを明確に設計し、データ分類と権限を結びつけられる企業ほど、速度と信頼を同時に維持できます。