Agents SDK のブラウザがターンをまたいで生き残る — ログインしたまま10分間、Durable Object の hibernate も越える

要約

Cloudflare Agents SDK に browserTool が入りました。エージェントへ Browser Run のブラウザを渡し、後続のターンでも同じブラウザへ戻れます。

何が解決されたかは、これまでの制約を思い出すと分かります。

エージェントにブラウザ操作をさせる構成では、ターンごとにブラウザが使い捨てられるのが普通でした。1ターン目でサイトを開いてログインし、2ターン目で続きの作業をしようとすると、セッションが切れていてログインからやり直しになります。結果として「1ターンで全部終わらせる」設計を強いられ、ログインが必要なサイトでの多段作業は現実的に組めませんでした。

今回はここが変わりました。 公式の説明は「サイトを開き、ページを調べ、あとで戻ってきたときに、タブ・Cookie・ログインセッションがそのまま残っている」です（ブラウザセッションが生きている限り）。

Durable Object が hibernate してもブラウザは生き続けます。 これが効きます。Durable Object は使われていない間は休止するのが前提の仕組みで、「エージェントが考えている間に裏側が止まる」という構造がありました。 ブラウザが hibernate を越えるなら、ユーザーの返信を待っている間もログイン状態が保たれます。

モデルがブラウザを操作する方法はコード生成です。 モデルは Chrome DevTools Protocol（CDP）を使うコードを書いて実行します。あらかじめ用意されたクリックやスクロールのコマンドを選ぶ形ではありません。スクリーンショットは画像として返るため、画像対応モデルと UI でそのまま扱えます。

必要バージョンは Agents SDK v0.28.0 以降です。

組み込み方は公式が手順で示しています。agents/browser から Browser と browserRun を、agents/browser/pi から browserTool を import します。provider: browserRun(this.env.BROWSER) で Browser を作り、Pi Durable harness の中で Harness.open の前に this.registry.install({ name: "browser", tools: [browserTool({ ctx, browser, loader: this.env.LOADER })] }) を呼びます。Lifecycle.install(this).use(this.browser).use(this.harness) でブラウザと harness を登録します。

挙動の細部。 Pi の会話ごとに既定でアクティブなタブが1つ割り当てられます。ログインと Cookie はブラウザ内で共有されます（タブ単位ではない）。

制約は3つあり、これが設計に直接効きます。

1. 既定のアイドルタイムアウトは10分
2. セッションが期限切れまたはクラッシュした場合、ツールは新しいブラウザを作って restarted: true を返す
3. そのときそれまでのタブとログイン状態は失われる

料金・プラン別の差は changelog に書かれていません。 Browser Run の料金体系に依存します。

AI SDK と TanStack AI 向けのアダプタがあり、他の harness も公開された Browser / CDP API 経由で接続できます。

何が変わったか

• browserTool が Agents SDK に追加（v0.28.0 以降）
• ターンをまたいで同じブラウザへ戻れる — タブ・Cookie・ログインセッションが残る
• Durable Object の hibernate を越えてブラウザが生存
• モデルは CDP を使うコードを書いて操作（固定コマンドの選択ではない）
• スクリーンショットは画像として返る（画像対応モデル・UI でそのまま扱える）
• Pi の会話ごとに既定で1つのアクティブタブ。ログインと Cookie はブラウザ内で共有
• 既定のアイドルタイムアウト 10分
• 期限切れ・クラッシュ時は新しいブラウザを作り restarted: true を返す（タブとログイン状態は失われる）
• AI SDK / TanStack AI 向けアダプタあり。他の harness は Browser / CDP API 経由で接続可能
• 必要なバインディング: BROWSER、LOADER

業務インパクト（一般企業向け）

1. 「ログインが必要な業務サイト」がエージェントの射程に入った

社内の業務で使うシステムは、ほぼすべてログインが必要です。毎ターンでログインし直す前提では、エージェントに任せられる作業は「ログイン不要な公開情報の取得」に限られていました。 ログイン状態が残るなら、社内システムへ入ってから複数画面をまたぐ作業——申請の起票、一覧からの抽出、画面間の転記——が構成として組めます。

ただしこれは「やっていい」という話ではありません。 組める構成が増えたぶん、どこまで任せるかを決める必要が出たという変化です。

2. 認証情報の扱いが設計の論点になる

ログイン状態を保持したブラウザが、エージェントの制御下に10分間残ります。 ここが従来と決定的に違います。使い捨てなら「1ターンで終わる」ことが実質的な安全弁になっていました。その安全弁が外れました。

決めるべきことは具体的です。(1) どのアカウントでログインさせるか（個人の認証情報を渡すのか、エージェント専用のアカウントを作るのか）。(2) そのアカウントの権限範囲（読み取りだけか、更新も許すか）。(3) 10分という寿命を長いと見るか短いと見るか。 公式は「既定」と書いているので、変更の余地があると読めますが、changelog には変更方法が書かれていません。

3. restarted: true の扱いは実装側の責任

セッションが落ちると新しいブラウザが作られ、ログイン状態は失われます。 ツールは restarted: true を返すので検知はできますが、そのあと何をするかは実装する側が書く必要があります。 再ログインするのか、人へ戻すのか、作業を中断するのか。

ここを書かないと、ログイン前提の作業がログインなしで続行されます。 エラーで止まるのではなく、ログイン画面に対して作業を続けようとする挙動になり得ます。公式は「中断されたツール呼び出しの挙動については説明していない」と明記しており、ドキュメントを読む必要がある箇所として示しています。

4. モデルがコードを書いて操作する、という点の評価

CDP を使うコードをモデルが生成します。固定されたコマンドの組み合わせより柔軟ですが、何が実行されるか事前に列挙できません。 サンドボックスの外に出る操作ではないものの、「どのサイトへアクセスできるか」はネットワーク側で制御する話になります。許可するドメインを絞る設計が、実装の前に必要です。

5. 10分という数字を業務に当てる

人が確認を挟む設計にすると、10分は意外と短いです。エージェントが作業して人へ確認を求め、人が会議から戻って返信する——これで10分を超えます。超えるとログイン状態が失われます。人の承認を挟む構成では、承認待ちの間にセッションが切れる前提で組む必要があります。逆に、人を挟まず連続して動く構成では10分は十分です。この差が設計を分けます。

副業・個人活用視点

1. 「ログイン後の多段作業」は案件になりやすい領域

RPA が入っている領域と重なります。ログインして、一覧を開いて、条件で絞って、エクスポートする——この類の作業は、どの会社にもあります。これまでエージェントで組みにくかった理由がセッションの寿命だったなら、その制約が外れたことは営業材料になります。

ただし提案の形は変わります。 「全部自動化します」ではなく、**「10分で終わる単位に切って、その中で完結させます」**という設計の説明が必要です。制約を理解した提案は、理解していない提案より通ります。

2. v0.28.0 という版数が、記事の鮮度を決める

web_fetch が v0.28.0 以降、web_search が v0.27.0 以降、そして今回の browserTool も v0.28.0 以降です。Agents SDK のバージョンごとに使えるツールが変わっている段階です。「どの版で何が使えるか」の対応表を自分で作って公開すると、検索で拾われます。 公式は個別の changelog に散らしているので、まとまった形は需要があります。

3. 試して書ける題材として条件が良い

必要なのは Cloudflare アカウントと Browser Run です。 大掛かりな環境構築が不要で、ログイン状態が本当に残るか、10分で本当に切れるか、restarted: true が返るかは自分で確かめられます。公式が書いていない箇所——アイドルタイムアウトの変更方法、中断されたツール呼び出しの挙動——を実験で埋めた記録は、公式ドキュメントの代わりとして読まれます。これは一次情報を作る作業です。

4. 認証情報の設計を語れると、単価が変わる

ログイン状態を保持するエージェントを提案する立場になると、認証情報をどう扱うかを必ず聞かれます。 エージェント専用アカウントの作成、権限の最小化、セッションの寿命。ここを実装の前に説明できる人は、実装だけを請ける人と単価が違います。 今回の変更は、その説明が必要になる構成を現実的にしたという意味で、提案の土台が1つ増えたと見るのが正確です。

5. 「hibernate を越える」の意味を説明できる価値

Durable Object の hibernate は、Cloudflare を触っていない人にはまず伝わりません。 「使われていない間は止まる」「止まっても外部のブラウザは生きている」という2段の説明が必要です。この手の「基盤の挙動を前提にした機能」を平易に説明できるかどうかは、技術記事の読まれ方を分けます。機能の列挙は誰でも書けますが、なぜそれが難しかったのかを書ける人は少ないです。