MCPとブラウザーエージェントを本番運用するための統制パターン
ZennやQiita、技術ブログの最新投稿を見ると、MCP導入は明らかに実験段階を抜けつつあります。同時に、Operaなどが示すブラウザー操作型エージェントの流れも強まり、「道具として使える」段階に入りました。
ただし、本番で差が出るのは機能量ではなく統制設計です。動くことと、安全に動かせることは別問題です。
MCP導入で加速する部分と危険になる部分
MCPは接続の標準化によって、内部API、ドキュメント、チケット、ファイルシステムを短期間でエージェントから利用可能にします。これは大きな生産性向上です。
一方で、標準化は誤設定の影響範囲も広げます。権限が広すぎるサーバーを1つ公開すると、複数クライアントから同時に危険操作できる状態になります。
典型リスク:
- ツール権限の過剰付与
- 連鎖呼び出しによる副作用の見落とし
- テナント分離不足
- 監査証跡不足
まずはCapability Contractを定義する
MCPサーバーを「接続先」ではなく「能力契約」として定義します。各ツールごとに次を明文化してください。
- 実行主体（誰が使えるか）
- 必須コンテキスト（どの条件で使えるか）
- 許容副作用（何まで許すか）
- 承認方式（自動/遅延/手動）
この契約がないと、後からポリシーエンジンを足しても制御不能です。
ブラウザーエージェントの最小安全設計
ブラウザー操作はAPIがない業務も自動化できる反面、誤操作の破壊力が高いです。最低限以下を実装します。
1. セッション分離
タスクごとに隔離コンテナを使い、TTLを短くし、資格情報キャッシュを共有しない。
2. 行為の許可リスト
既定は読み取り中心。送信、削除、公開、購入などは承認付きにする。
3. 再現可能な監査ログ
DOMアンカー、操作時系列、スクリーンショットハッシュを記録し、後追い検証を可能にする。
4. 持ち出し制御
外向きドメイン制限とペイロード分類で、無制限なデータ投稿を防ぐ。
ポリシーは3層で運用する
- 静的ポリシー: 役割・環境ごとの基本ルール
- 動的ポリシー: 実行時リスク判定
- 人的ポリシー: 高リスク操作の承認導線
低リスクは自動化し、高リスクは素早くレビューする。これが速度と安全性を両立する実務解です。
信頼性設計の要点
冪等ラッパー
全ツール呼び出しにoperation idを付与し、再実行時の意味を固定する。
補償操作
非冪等操作には必ず戻し手順を持つ。設定変更なら、元設定復元をAPI化する。
期限とフォールバック
ツール別に締切時間と失敗時方針（再試行/スキップ/エスカレーション）を明示する。
見るべき指標
- リスク階層ごとの承認遅延
- ポリシーで遮断された操作率
- MCPサーバー別エラー率
- 自動実行後のロールバック頻度
「完了タスク数」だけでは健全性は判断できません。
導入ステップ
Phase 1
- MCP能力棚卸し
- 副作用分類
- 役割行列の草案
Phase 2
- 事前ポリシー判定を強制
- 監査ログ形式を統一
- 承認レーン実装
Phase 3
- 低リスク自動承認拡大
- 高リスクレビュー導線最適化
- 月次統制スコア公開
まとめ
MCPとブラウザーエージェントは、2026年の実運用基盤になりつつあります。競争力の差は採用速度ではなく、統制品質に出ます。
能力契約、実行分離、監査再現性、承認導線。この4点を先に設計すれば、自動化の速度を上げながら技術的負債の増殖を抑えられます。
