Cloudflare Project ThinkとBrowser Runで作る実運用エージェント基盤

CloudflareのAgents Weekで出たProject Think、Browser Run、Workflows制御プレーン再設計は、単発ニュースではなく「エージェント基盤をどう本番化するか」の前提を変えました。これから必要なのは、チャット体験の改善ではなく、常時稼働するソフトウェアワーカーの運用設計です。

参考: https://blog.cloudflare.com/tag/workers/。

要点は3つです。サーバレスの速度、分散システムとしての状態管理、そしてゼロトラスト前提の統制を、同時に満たすこと。どれか1つでも欠けると、PoCは動いても本番は止まります。

何が変わったのか

今回の更新は個別機能よりも「組み合わせ」に価値があります。

Project Think / Agents SDKの進化で、状態保持するエージェント実装が標準化された。
Browser Runで、ブラウザ操作が周辺ツールではなく中核機能になった。
Workflows制御プレーン刷新で、長時間ジョブの同時実行と生成性能が引き上げられた。

これまで多くの企業は、ブラウザ自動化、推論、オーケストレーションを別々の製品で継ぎ接ぎしていました。今回の意味は、その分断を減らして、統一された運用面を持てるようになった点にあります。

本番導入時の基準アーキテクチャ

実務で破綻しにくい最小構成は次の通りです。

Workers（入口層）: 認証認可、レート制御、予算ガード。
Durable Objects（セッション調停）: 状態固定、排他、再実行の責務分離。
Agents SDK + Workers AI（実行層）: 計画、ツール選択、推論トレース。
Browser Run（ブラウザ層）: UI操作、記録、ヒューマンチェックポイント。
Workflows（耐久実行）: リトライ、補償処理、SLAタイマー。
R2/KV/D1（証跡層）: 成果物、監査ログ、ポリシー判断履歴。

重要なのは、これを「6つのサービス」ではなく「1つの内部プロダクト」として運営することです。責任分界を曖昧にすると、障害時に誰も全体を見られません。

Browser Runで運用がどう変わるか

従来のブラウザ自動化は、次の失敗を繰り返してきました。

プランナー側の状態とブラウザ実状態の不整合
失敗時に再現できず、原因特定が遅れる
スクリプト内に認証情報や回避ロジックが散らばる

Browser Runが入ると、少なくとも統制ポイントは中央化できます。実務上は以下が効きます。

リプレイ前提の障害解析: セッション録画IDをインシデント票に必須化する。
段階承認モデル: 高リスクDOM操作前に人手承認を挟む。

この2点で、MTTR短縮とリスク低減を同時に達成しやすくなります。

FinOpsは「成功結果単価」で管理する

エージェントのコスト管理が崩れる典型は、推論費、ブラウザ費、ワークフロー費を別々に監視してしまうことです。見るべき指標は1つの事業KPIです。

CpSO（Cost per Successful Outcome）

CpSO = (推論 + Browser実行 + Workflow実行 + 保存 + 人手レビュー) ÷ 完了した成果件数

さらに業務クラスごとに分けます。

低リスク: 参照中心の調査タスク
中リスク: 業務フロー自動化
高リスク: 更新・送信・決済など副作用あり

クラス別に予算上限、遅延上限、承認ルールをセットで設計すると、コスト爆発と品質劣化を防げます。

先に入れるべきセキュリティ制御

抽象的なAIガバナンスより、被害半径を直接下げる制御から入れるのが実務的です。

ツール呼び出し単位の短命クレデンシャル
実行時の外向き通信制御（allowlist）
永続化前の構造化マスキング
ポリシー判断とアクションIDの不可分な監査証跡
テナント/地域境界に基づくルーティング分離

これらがないと、後で監査対応に詰まり、開発速度は必ず落ちます。

先に用意しておくRunbook

本番前に最低限、次のRunbookを準備してください。

Browserステップのタイムアウト連鎖
ツールアダプタのスキーマ差分による失敗
プロンプト回帰によるトークン急騰
Workflowsキュー滞留とSLA逸脱
幻覚出力が副作用操作に接続したケース

各Runbookは「検知条件」「自動緩和」「人手エスカレーション」をセットで記述し、属人的対応をなくします。

90日導入ロードマップ

0〜30日: 計測とガードレール

成果単位のコスト/遅延を計測
リスク別ポリシーを定義
合成データでカナリア実行

31〜60日: 制御付き本番拡張

実業務ワークフローを2〜3本導入
高リスク操作に承認ゲートを適用
障害管理にリプレイIDを組み込み

61〜90日: 運用定着

クラス別SLOを正式化
予算連動の受付制御を実装
信頼性/コスト/統制の月次スコアカードを公開

まとめ

Project ThinkとBrowser Runは、エージェント開発を「実験」から「運用工学」へ進める転換点です。状態管理、証跡、予算、承認を初期設計に組み込んだ組織が、2026年の本番競争で優位に立ちます。