2026 年 5 月 22 日、InfoQ が Cloudflare Completes Its Agent Infrastructure Stack with Browser Run Rebuild and Six-Layer Platform を公開しました。Cloudflare は Browser Run（旧 Browser Rendering）を再構築し、6 層エージェントプラットフォーム（モデル / メモリ / ツール / ブラウザ / ワークフロー / 監査）を一体提供する形に整えました。これにより **「AI エージェントが本物のブラウザを操作して業務を進める」運用が、スケール / セキュリティ / コストの三点で実用域に入りました。これまで「ブラウザ自動化はリッチクライアント前提 / 安定性難」だった世界が、「Edge 上のサンドボックスブラウザを宣言的に起動」**するモデルへ移行します。
受託で中堅企業の AI エージェント業務適用を支える立場では、これは 「Web 業務 SaaS の自動操作 / スクレイピング監視 / 入力代行」といった典型ニーズに、Cloudflare 6 層基盤 + 監査ログ + コスト統制を組み合わせた受託パッケージを設計する好機を意味します。これまで Cloudflare AI エージェント CLI 受託 で扱った エージェント CLI 選定、Cloudflare Mesh プライベートネットワークエージェント受託 で扱った エージェント網内化、Cloudflare Workflows v2 受託 で扱った バックエンドオーケストレーションを 一段統合した上位レイヤを整理します。
なぜ「6 層統合が分水嶺」なのか
| 観点 | 自前 / 単機能組合せ | Cloudflare 6 層統合 |
|---|---|---|
| モデル層 | OpenAI / Anthropic 直叩き | Workers AI + 外部モデル抽象 |
| メモリ層 | Redis / 自社 KV / 自前ベクトル | Durable Objects + Vectorize |
| ツール層 | プラグイン散在 | MCP 統合 + Tool Registry |
| ブラウザ層 | Puppeteer / Playwright + EC2 | Browser Run（Edge サンドボックス） |
| ワークフロー層 | Step Functions / Temporal | Cloudflare Workflows v2 |
| 監査層 | 自前ログ集約 | Logpush + Trace 統合 |
| デプロイ単位 | 5 種類以上のサービスを別々 | 単一 wrangler.toml |
| コスト予測性 | 月次で変動大 | Edge 単価で予測容易 |
つまり 6 層統合は 「ばらばらの SaaS を糊付けする属人運用」から 「単一プラットフォーム上で宣言的に組み立てる」運用への分水嶺です。
受託案件で活きる 3 つの構造変化
構造 1: 「業務 SaaS の API なし → 手作業」から「ブラウザ操作で自動化」へ
中堅企業の業務システムには 「公式 API がない」「Excel ダウンロード → 加工 → アップロード」といった 手作業ループが多数残っています。Browser Run + ワークフローは 「人間がブラウザでやっていた操作」をそのままエージェント化でき、API 化のコストをかけずに自動化を実現できます。これは Mastra AI エージェント業務連携受託 で扱った 業務連携を、Web UI 直接操作レイヤで拡張するアプローチです。
構造 2: 「ブラウザ自動化は Puppeteer + EC2」から「Edge ブラウザサンドボックス」へ
これまで Puppeteer / Playwright + EC2 / GKEで運用していた ブラウザ自動化基盤は、起動コスト / メンテ / セキュリティで運用工数が嵩みました。Browser Run は Edge 上の使い捨てブラウザを 数百ミリ秒で起動し、実行後即破棄するため、コスト / 安全性 / スケールが同時に改善します。これは Cloudflare Sandboxes GA AI エージェント隔離実行受託 で扱った エージェント隔離の ブラウザ版です。
構造 3: 「監査ログは別系統」から「実行と監査が一体」へ
エージェントが業務システムを操作する場合、「誰がいつ何を実行したか」の 完全な監査トレースが必須です。6 層統合では Workflow → Browser Run → ツール呼び出し → モデル推論が 同一 trace_id で連結され、Logpush 経由で SIEM へ配送できます。これは GitHub 内部リポ侵害 + VSCode 拡張開発者エンドポイント統治受託 で扱った 開発者統治の 本番エージェント版です。
受託で提供する「エージェントブラウザ基盤」5 フェーズ
フェーズ 1: 現状診断（2 週間）
- 業務手作業ループ棚卸し（操作 / 頻度 / 工数）
- API 化済 / 未対応 SaaS 区分
- 既存自動化（Puppeteer / RPA）の運用課題
- セキュリティ要件 / 監査要件
- 自動化候補プロセス優先順位付け
フェーズ 2: アーキ設計（2〜3 週間）
- 6 層配置設計（Workers / Durable Objects / Workflows / Browser Run）
- セッション管理（認証 / Cookie / 2FA）
- 監査ログスキーマ（trace_id / actor / target / result）
- フォールバック / 再実行設計
- ガバナンス（実行承認 / 影響範囲制御）
フェーズ 3: PoC 構築（3〜4 週間）
- 代表 3〜5 業務プロセスで PoC
- Browser Run + Workflows の実装
- 監査ログ → SIEM 配送
- 失敗ケース / 例外処理
- 利用者向け承認 UI
フェーズ 4: 本番展開（4〜8 週間）
- 段階展開（PoC 業務 → 全業務）
- 認証基盤統合（SSO / 2FA / シークレット管理）
- 障害監視 + アラート
- 利用者教育 + 承認フロー
- コスト / 利用状況ダッシュボード
フェーズ 5: 月次運用レビュー（継続）
- 自動化カバー率 / 成功率
- 新規業務追加判断
- SaaS UI 変更追従
- 監査ログレビュー
- コスト最適化（Workers / ブラウザ起動回数）
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| モデル | Workers AI / Anthropic / OpenAI | Bedrock / Gemini |
| メモリ | Durable Objects / Vectorize / D1 | Redis / Postgres |
| ツール統合 | MCP + Cloudflare Bindings | LangChain Tools |
| ブラウザ | Cloudflare Browser Run | Playwright + Lambda |
| ワークフロー | Cloudflare Workflows v2 | Step Functions / Temporal |
| 監査 | Logpush + SIEM（Splunk / Datadog） | 自前 BigQuery |
| シークレット | Workers Secrets / Vault | 1Password Connect |
| CI/CD | Wrangler + GitHub Actions | GitLab CI |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| Web SaaS の手作業ループが多い | API 化済で自動化完結 |
| 月次 / 週次の定型業務 | 単発の調査作業 |
| 監査要件あり（金融 / 医療 / 公共） | 内部試験のみ |
| RPA からの近代化検討中 | 既存 RPA で満足 |
| グローバル / マルチリージョン業務 | 単一拠点完結 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象業務範囲 | 自動化対象の SaaS / プロセス | 業務影響度 |
| 認証情報管理 | 共通アカウント / 個別 SSO | コンプライアンス適合 |
| 失敗時 SLA | 検知 → 通知 → 復旧 | 業務継続要件 |
| 承認フロー | 自動 / 手動承認 / ハイブリッド | リスク許容度 |
| 監査ログ保持 | 期間 + 暗号化 + アクセス制御 | 法令要件 |
| 退場時引き渡し | コード + Workflow + 評価セット | 自社運用継続性 |
価格モデル — エージェントブラウザ基盤パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 170 万円〜（6 週間） | 棚卸し + 3 プロセス PoC | レポート + ロードマップ |
| Lite | 55 万円〜 / 月 | 業務プロセス 5〜15 | 月次レビュー + 改善 |
| Standard | 120 万円〜 / 月 | プロセス 15〜40 | + 監査統合 + ダッシュボード |
| Enterprise | 240 万円〜 / 月 | プロセス 40 超 / 全社展開 | + 専任 SRE + ガバナンス |
| 初期構築 | 440 万円〜（一括） | 6 層基盤 + 認証統合 + 監査 | 全プラン共通オプション |
顧客側 ROI 試算（業務プロセス 20 / 手作業時間 月 320h 想定）
| 項目 | 既存（手作業 / 簡易 RPA） | エージェントブラウザ基盤導入後 | 差分 |
|---|---|---|---|
| 手作業工数（月） | 320h | 60h | -260h |
| プロセス変更対応工数 | 月 40h | 月 10h | -30h |
| 失敗 / 手戻り発生 | 月 25 件 | 月 4 件 | -21 件 |
| 監査対応工数 | 80h | 25h | -55h / 年 |
| ブラウザ自動化インフラ費 | 月 60 万円 | 月 18 万円 | -42 万円 / 月 |
| 年間効果 | — | — | 約 3,300 万円相当 + 監査適合性向上 |
時給 8,000 円換算で 年間 2,500 万円超の工数削減 + インフラ費 504 万円削減。Standard プラン（年額 1,440 万円）でも 6 ヶ月以内で回収可能です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 「全業務を一気に自動化」で混乱
「6 層基盤があるから何でも自動化」と 20 プロセス同時展開すると、監査 / 例外処理が破綻します。3〜5 プロセスから段階導入します。
落とし穴 2: 認証情報を平文 / KV 保管
「とりあえず動かす」で Cookie や API キーを Workers KV に直書きすると、漏洩リスクが直撃します。Workers Secrets / Vault 統合を初期設計に組み込みます。
落とし穴 3: SaaS UI 変更追従を後回し
業務 SaaS は 3〜6 ヶ月で UI が変わるため、変更検知 → 自動アラート / 自動修復を設計初期に入れます。
落とし穴 4: 監査ログを後付け
「動いてから監査を整える」では、遡及で監査要件を満たせないことが多発します。初期構築時から trace_id 連結 + Logpushを必須にします。
落とし穴 5: 人間の承認ループ抜きで全自動化
「全自動で完結」とすると、SaaS UI 変更時の暴走 / 業務影響が大きくなります。「自動 → 警告 → 人間承認 → 実行」の境界を業務影響度別に設計します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | 手作業ループ棚卸し + 自動化候補抽出 |
| Week 3〜4 | 6 層アーキ設計 + 認証 / 監査設計 |
| Week 5〜7 | PoC 実装（3 プロセス） |
| Week 8〜9 | カナリア環境 + 監査検証 |
| Week 10 | 本番第 1 プロセス展開 |
| Week 11 | 失敗ケース / SLA 検証 |
| Week 12〜13 | 月次運用レビュー定例化 |
まとめ — 「ばらばらの SaaS 糊付け」から「単一プラットフォーム上の統合運用」へ
Cloudflare 6 層エージェント基盤の完成は、**「業務自動化はばらばらのツール + 属人運用」前提を覆し、「単一プラットフォーム上で宣言的に組み立てる」**設計の現実性を示しました。受託で中堅企業の業務 DX を支える立場では、6 層アーキ設計 + 認証統合 + 監査 + 月次運用を一体で提供する 「エージェントブラウザ基盤」が、新しい主力サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「業務 SaaS の手作業ループが多い」「Puppeteer + EC2 の運用が辛い」「RPA を近代化したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
