株式会社ホコサキ

@cloudflare/computerをアーキテクチャから理解する

天京祐輔
天京祐輔
@cloudflare/computerをアーキテクチャから理解する

AIエージェントに「何かをさせる」とき、意外と見落とされがちなのが 実行レイヤー の設計です。
LLMがどれだけ賢くても、ブラウザを開いてフォームを埋める「手」がなければ何も起きません。
@cloudflare/computer はその「手」を担うパッケージです。

Playwright や Browser Use を知っていても、このパッケージが何者でどこに位置するのかはすぐには分かりにくい。
その構造的な立ち位置と、APIのない業務システムへの適用可否を自分で判断できるようになることを、この記事のゴールにします。

@cloudflare/computer とは何か――エージェントに「手」を渡すレイヤー

ひと言で言うと、 仮想コンピュータ環境をAPIとして提供するOSS です。
スクリーンショットの取得・座標クリック・テキスト入力といった操作プリミティブを、エージェントが呼び出せる形に抽象化しています。
インストールは npm install @cloudflare/computer で完了します。

Cloudflare が進める Project Think の文脈では、「実行ラダー」の Browser Run 層に位置します。
実行ラダーとは、タスクの複雑さに応じて Dynamic Workers → Browser Run → Sandboxes と段階的に重い実行環境を使い分ける設計思想のことです。
JavaScript の評価程度なら Dynamic Workers で十分、ブラウザ操作が必要なら Browser Run、コンパイルが必要な重処理なら Sandboxes、という具合です。

@cloudflare/computer はこの Browser Run 層で動き、エージェントフレームワーク（Agents SDK）とヘッドレスブラウザの間を橋渡しします。
重要なのは、 これ自体はエージェントフレームワークではない という点です。
LLMに何をするか判断させる部分は別途用意する必要があります。
@cloudflare/computer は「判断された操作を実際に実行する」役割に徹しています。

パッケージの中心にあるのは Workspace という概念です。
SQLite と R2 をバックエンドに持つ仮想ファイルシステムで、git リポジトリやファイルを事前に配置しておくこともできます。
エージェントが操作中に生成したファイルや状態を、セッションをまたいで保持できる構造になっています。

Playwright・Browser Use との構造的な違い――「手順を書く」vs「判断して動く」

この3つは「ブラウザを操作する」という点では共通していますが、設計思想のレイヤーが根本的に違います。

Playwright は 操作手順をコードで事前定義する手続き型 のツールです。
セレクタを指定してクリック、テキストを入力、ボタンを押す、という一連のステップをコードに書き下ろします。
UIのセレクタが変われば即座に壊れますが、動作が決定的で再現性が高く、デバッグもしやすい。
定型業務の高速・大量処理には今でも最強の選択肢です。

Browser Use は LLMが画面状態を見て次の操作を都度決める自律型ループ のフレームワークです。
「今の画面はこう。次に何をすべきか？」をLLMに問い合わせ、返ってきた指示をブラウザに実行させ、また画面を読んで次を判断する、というサイクルを回します。
UIが変わっても自分で読み取って対応できる柔軟性がある一方、LLMの呼び出しコストと応答時間がかかります。

@cloudflare/computer は Browser Use のような 自律ループを自前で組む際の実行エンジン として機能します。
Browser Use がフレームワーク層（判断ロジックを含む）であるのに対し、@cloudflare/computer は純粋に「操作を実行する」層です。
この2つは競合というより、「フレームワーク層を自前にするかライブラリに任せるか」の選択に近い。

使い分けの判断軸を整理するとこうなります。

  • Playwright が向いているケース: 操作フローが固定されている、UIの変更頻度が低い、コストと速度を最優先したい
  • Browser Use が向いているケース: タスクが自然言語で与えられる、UIが頻繁に変わる、プロトタイピングを素早くしたい
  • @cloudflare/computer（自前エージェントループ）が向いているケース: 判断ロジックを自分で設計したい、Cloudflare Workers 上でインフラ管理なしに動かしたい、Durable Objects による状態管理を活用したい

エージェントの自律性の設計に踏み込みたいエンジニアにとって、@cloudflare/computer は実行エンジンとして有力な選択肢になります。

APIのない社内システムを叩く――スクリーンショット→判断→操作のループをコードで見る

「APIが公開されていない社内Webシステムに自動でアクセスしたい」というニーズは、実務でよく出てきます。
ログインして、特定の条件でフォームを送信して、帳票をダウンロードする、といった作業です。
Playwright で書けないわけではありませんが、画面構成が変わるたびにセレクタを直す運用は地味につらい。

ここで @cloudflare/computer を使った自律ループが効いてきます。
エージェントがスクリーンショットを取得し、LLMが「次に何をすべきか」を判断し、その指示を computer API で実行する。
これを目標達成まで繰り返します。

import { Computer } from "@cloudflare/computer";

// Durable Object 内で初期化
const computer = new Computer(this.ctx, this.env);

// 1. 現在の画面をスクリーンショットとして取得
const screenshot = await computer.screenshot();
// → base64 エンコードされた PNG が返る

// 2. LLM にスクリーンショットを渡して次の操作を判断させる
const action = await llm.decide(screenshot, goal);
// action = { type: "click", x: 320, y: 480 } など

// 3. 判断に従って操作を実行
if (action.type === "click") {
  await computer.click(action.x, action.y);
} else if (action.type === "type") {
  await computer.type(action.text);
}

// 4. 再度スクリーンショットを取って状態を確認し、ループへ

Playwright との構造的な差はここに出ます。
Playwright は「ログインボタンは #login-btn にある」とコードに書きます。
このループでは「今の画面を見て、ログインボタンがどこにあるかLLMに判断させる」ので、セレクタを一切書きません。

ただし、 座標ベースのクリックは精度に限界がある 点は正直に言っておきます。
DOMへのアクセスがなく、スクリーンショットだけで判断するビジョン駆動のアプローチは、DOM駆動（Playwright＋セレクタ）と比べると信頼性が落ちます。
あるベンチマーク比較 によると、DOM駆動スタックはビジョン駆動スタックより12〜17ポイントほど高い成功率を示しているというデータもあります。
「UIが変わりやすい・セレクタを書きたくない」という理由でこのアプローチを選ぶ場合は、タスクの成功率を実測して判断するのが無難です。

Durable Objects と Browser Run が支えるアーキテクチャ

@cloudflare/computer が Cloudflare Workers 上で動くことの意味は、インフラ管理が不要になる以上のものがあります。
アーキテクチャの根幹に Durable Objects と Browser Run の組み合わせがあり、これがエージェントとしての振る舞いを支えています。

Durable Objects は、エージェントに「アイデンティティ・永続状態・ヒベルネーション」を与えます。
各エージェントはアドレス可能なエンティティとして存在し、自分専用の SQLite データベースを持ちます。
そして アイドル時のコンピュートはゼロ です。
HTTPリクエストや WebSocket メッセージ、スケジュールされたアラームなどのイベントが来たときだけ起動し、処理が終わればまた眠る。
この非対称なコスト構造は、長時間かかるエージェントタスクを経済的に動かすうえで重要です。

Browser Run はヘッドレスブラウザのサンドボックスとして機能します。
セッションごとに隔離された環境が起動し、クッキー・キャッシュ・セッション情報が残らない使い捨て構造です。
悪意あるサイトや予期しないリダイレクトからエージェントを守る意味でも、この分離は実務上のメリットになります。

制約面も把握しておく必要があります。
Workers の実行時間制限は、長時間のブラウザ操作タスクにとってボトルネックになり得ます。
Durable Objects のヒベルネーション機能がこれを緩和しますが、一連のタスクが単一セッション内で完結しない場合は、状態をどう引き継ぐか設計が必要です。

最小構成のスケルトンはこのようになります。

# wrangler.toml
name = "my-computer-agent"
main = "src/index.ts"
compatibility_date = "2025-01-01"

[[durable_objects.bindings]]
name = "COMPUTER_AGENT"
class_name = "ComputerAgent"

[[migrations]]
tag = "v1"
new_sqlite_classes = ["ComputerAgent"]

[browser]
binding = "BROWSER"

// src/index.ts
import { DurableObject } from "cloudflare:workers";
import { Computer } from "@cloudflare/computer";

export class ComputerAgent extends DurableObject {
  computer: Computer;

  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);
    this.computer = new Computer(ctx, env);
  }

  async fetch(request: Request): Promise<Response> {
    const goal = await request.text();
    await this.runAgentLoop(goal);
    return new Response("done");
  }

  async runAgentLoop(goal: string) {
    // スクリーンショット → LLM判断 → 操作 のループをここに実装
  }
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const id = env.COMPUTER_AGENT.idFromName("agent-1");
    const stub = env.COMPUTER_AGENT.get(id);
    return stub.fetch(request);
  },
};

Durable Object に @cloudflare/computer を組み込む構造はこれだけです。
インフラのプロビジョニングは不要で、wrangler deploy で即座にデプロイできます。

導入前に整理しておきたい制約と「本当に必要か」の判断

正直なところ、@cloudflare/computer はまだ experimental ステータス のOSSです。
Cloudflare 自身も「APIサーフェスは今後数週間で進化し続ける」と明言しており、本番投入する場合は破壊的変更のリスクを織り込んだ設計が必要です。

コスト面では、Browser Run には無料ティアが存在し、実行時間に応じた課金体系が設けられています。
ただし Durable Objects のアイドル時ゼロコストとの組み合わせで実際の費用感がどうなるかは、試験運用で実測するのが確実です。

「そもそも @cloudflare/computer が必要か」という判断は、次の順序で絞り込むのが現実的です。

まず、 対象システムにAPIが存在するか を確認します。
REST API でも内部 API でもあれば、そちらを使うべきです。
ブラウザ操作は最終手段です。

次に、 UIの変更頻度とタスクの確定度 を見ます。
操作フローが固定されていてUIも安定しているなら、Playwright で十分です。
メンテナンスコストも低く、信頼性も高い。

UIが頻繁に変わる、またはタスクが自然言語で与えられる場合に、初めてエージェント型の自律ループが候補に上がります。
そのうえで、エージェントのループ設計を自分でコントロールしたい・Cloudflare Workers 上でインフラ管理なしに動かしたい、という条件が重なったとき、@cloudflare/computer が有力な選択肢になります。

Browser Use のようなフレームワークを使えば、実行エンジンを自前で持たずに同様の自律ループを実現できます。
@cloudflare/computer を選ぶ理由は、Cloudflare エコシステムへの統合・Durable Objects による状態管理・インフラ管理の排除、この3点がそろったときです。

株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援を手がけています。
「APIのない社内システムをどう自動化するか」「エージェント基盤をどう設計するか」といった相談も受け付けています。
気軽に お問い合わせページ からどうぞ。