シュレーディンガーの Claude in Chrome タブ：見ていないと、働かない

Chrome のバックグラウンドのタブで働く AIエージェントは、なぜ遅くなり、眠り込み、サポートチャットまで切断させてしまうのか。

私は普段から、いくつもの作業を並行して進めるタイプだ。7 月中旬のある午後、Claude in Chrome に 3 つの仕事を同時に頼んだ。1 つ目のタブでは私たちのブラウザのポップアップ検出機能のチェック、2 つ目のタブでは動画に合う BGM 探し、3 つ目のタブでは Origin Energy のサポートに送る苦情の下書き。電気料金の請求を 1 件間違えられていたのだ。3 つとも動き出したのを見届けてからブラウザをバックグラウンドに回し、ターミナルに戻って、Claude Code で自分の AI 開発チームを回す作業を続けた。私にとってエージェントを使う意味はまさにそこにある。何体ものエージェントがそれぞれ勝手に働いてくれて、一つひとつ見張っていなくていい。

しばらくしてブラウザに戻ってみると、3 つのうち進んでいたのは 1 つだけだった。残りの 2 つは居眠りでもしているようで、少し待っても、タブを何度か切り替えてみても、そのままだった。

たいていの人がまず疑うのは、ネットワークが遅いか、その日のモデルの反応が遅いかだろう。でもネットワークやモデルのせいなら 3 つが揃って遅くなるはずで、1 つだけ動いているのは説明がつかない。私は長年ブラウザを作ってきたので、すぐに別の答えが頭に浮かんだ。Chrome がバックグラウンドのタブを減速させている。

これは Chrome の欠陥というわけではない。ブラウザとしてはむしろ当然の動きだ。見ていないページが全速で動く理由はないし、人はタブを何十個も開きっぱなしにする。それが前面か背面かに関係なく全部全速で動いていたら、ノート PC のバッテリーは半日でなくなってしまう。問題は、ブラウザの中のページが、もう人が見るためだけのものではなくなったことだ。AIエージェントもそこで働いている。人にとってバックグラウンドのタブは「今は要らないもの」だが、エージェントにとっては、ダウンロードを待っていたり、返金の手続きを進めていたり、切れてはいけないサポートチャットをつないでいたりするタブかもしれない。誰も見ていないタブにも、やるべき仕事はある。

ブラウザのルールは人のために作られていて、エージェントにはどうにも合わない。

7 月 16 日に手作業で試して、原因がこれだと確かめた。私たちが AIエージェントのために作っているブラウザ Embiody に「AI タブ」という機能を入れると決めたのも、その日だ。最近になって、そのときのテストをきちんとやり直した。知りたかったのは 3 つ。Chrome はバックグラウンドのタブをどこまで遅くするのか。どんなときにページを丸ごと凍結するのか。そしていちばん厄介な問いとして、ページはまだ開いているのに、エージェントが間違った内容を読んでしまうことはあるのか。結果は、予想よりずっと悪かった。

1. 8 分たったのに、ページは 1 分半しかたっていないと思っている#

まず用意したのは、1 秒に 1 回進むごく普通のカウントダウンページだ。書き方は購入ページや決済ページのカウントダウンと同じにした。1 回進むたびに、同じマシン上の小さなサーバーへ進み具合を報告させる。こうしておけば、ブラウザがページを凍結しても、実際に何が起きたかはサーバー側に記録が残る。

このページを 2 つ開いた。1 つは Claude in Chrome に開かせ、もう 1 つは比較用に自分の手で開いた。そして両方を 8 分間、目に入らない状態にした。隠し方は 3 通り試した。別のタブに切り替える、別のウィンドウで完全に覆う、ウィンドウを最小化する。3 通りとも結果はほぼ同じだった。

ページが見えなくなってから最初の 1 分は何も変わらず、カウントダウンは 1 秒に 1 回進んでいた。ところが 1 分ほどたつと、1 分に 1 回しか進まなくなった。8 分後、現実には 480 秒たっているのに、ページは 90 秒ほどしかたっていないと思っていて、390 秒も遅れていた。8 分かけて朝ごはんを食べに出て、戻ってきたら家の時計が 1 分半しか進んでいなかった、というようなものだ。しかもウィンドウを前に戻すと、カウントダウンは 1 秒に 1 回のペースに戻るのだが、失われた数分が取り戻されることはなかった。

もっと大事なのは、Claude in Chrome が開いたページも、私が手で開いたページも、まったく同じ振る舞いをしたことだ。遅れは Claude のほうが 387～391 秒、私のほうが 392 秒。つまり Claude とは関係がない。Chrome で開いていて誰も見ていないページは、どれもこうなる。Chrome でエージェントを動かす人なら誰でもぶつかる、ということだ。

（Windows 11、Chrome 157.0.8103.39、Claude 拡張機能 1.0.106、2026 年 11 月 11 日、マシン 1 台、各ケース 1～2 回。）

ここで当然の疑問がわく。Claude in Chrome のタブは、ほとんどずっとバックグラウンドにいる。バックグラウンドのタブが 1 分に 1 回しか動かないなら、いったいどうやって仕事を片づけているのか。実際、ちゃんと終わらせてはいるのだ。

2. 起きているのは、エージェントが触っているタブだけ#

それを確かめるため、実際の作業に近いテストページを作った。ウェブサイトでいちばんよく見る 2 種類の「待ち」を載せてある。1 つ目はダウンロードで、ページに「90 秒後にダウンロードが始まります」と表示され、カウントダウンが 0 になるとダウンロードボタンが押せるようになる。2 つ目はエクスポートで、ページには「エクスポート処理中」と表示され、2 秒ごとにサーバーへ終わったかどうかを問い合わせる。サーバーは 90 秒後に「終わった」と返す。

そのうえで、Claude in Chrome にこの作業を 2 つ同時にやらせた。1 つはタブ A、もう 1 つはタブ B。Claude はまず A に取りかかり、B はバックグラウンドで手つかずのまま。結果はこうだった。

下は 2 回目の B で、ウィンドウを前に戻した瞬間からの映像だ。ページが「どれだけ待ったか」に注目してほしい。

ページは実時間で 378 秒待って、それでもまだ 6 秒残っていた。90 秒の待ちが 6、7 分に延びたわけで、これがまさに 7 月のあの午後に私に起きたことだ。エージェントはずっと働いていた。ただし働いていたのはいつも A で、B はバックグラウンドで 1 分に 1 回ずつのろのろ進んでいた。やっと B を見に来たときには、とっくに終わっているはずのカウントダウンがまだ続いていた。しかもこれは運がいいほうだ。エージェントが B に一度も戻ってこなかったら、1 分に 1 回のペースでは、この 90 秒のカウントダウンは 30 分近くかかっていた。

不思議なのは、エクスポートのほうはほとんど影響を受けなかったことだ。サーバーが 90 秒で完了を返し、エージェントはそのわずか 3 秒後に気づいた。

どちらもバックグラウンドのタブでの待ちなのに、Chrome はなぜダウンロードのカウントダウンだけを遅くして、エクスポートは見逃したのか。

違いは、2 つの待ちの書き方にある。カウントダウンは自分で目覚ましをかけている。この 1 秒の目覚ましが鳴ったら次の目覚ましをかけ、それが鳴ったらまたその次をかける、というふうに、目覚ましが前の目覚ましにつながって鎖になっている。エクスポートのほうは折り返しの電話を待っている。サーバーに問い合わせて、返事が来てから次の問い合わせを予約するので、毎回、相手の返事を起点に新しく始まる。Chrome には、鎖になった目覚ましだけを狙ったルールがある。ページが見えなくなってしばらくたつと、そういう目覚ましは 1 分に 1 回しか鳴らせない。だからカウントダウンは遅くなり、折り返しの電話を待つエクスポートはこのルールの対象外になるわけだ。

つまりバックグラウンドの減速は、ページ全体を一律に遅くするわけではない。遅くなるかどうかは、ページの書き方で決まる。でも、これはまだ最悪の話ではない。

3. 20 秒後、ページは完全に止まる#

ここまでの減速は、少なくとも最後にはたどり着く。次のは本当にぎょっとした。Claude in Chrome は新しいタブを、既定でバックグラウンドに、つまり今見ているタブの後ろに開く。テスト用のタブを 1 つ開かせて放っておいたら、たった 20 秒でページが完全に止まった。カウントダウンは 1 分に 1 回どころか、まったく進まない。エージェントが戻ってきて何か操作するまで、ずっとそのままだった。これを 4 回見たが、毎回 20 秒前後で、しかもその間ずっとブラウザのウィンドウは画面に出ていて、覆われても最小化されてもいなかった。

ウィンドウははっきり見えているのに、どうしてその中のページが急に止まってしまうのか。

比較のため、同じページを普通のやり方でバックグラウンドのタブに開いてみた。こちらは 3 分たっても動いていて、1 分に 1 回まで落ちただけだった。となると、20 秒という数字は Claude in Chrome と関係があるはずだ。しばらくタブバーを眺めていて、ようやく見えた。エージェントの最後のコマンドから 20 秒ほどたつと、Claude のタブグループがひとりでに折りたたまれる。そしてタブグループが折りたたまれると、Chrome はその中の一度も表示されていないタブを凍結する。次の動画では、タブバーに注目してほしい。

どちらも、それだけを見れば筋が通っている。Claude in Chrome は、自分が開いた大量のタブにタブバーを占領させたくないので、手が空いたらグループをしまう。Chrome は、折りたたまれたグループを「しばらく使わないから引き出しにしまった物」のように扱い、メモリを節約するためにその引き出しの電源を落とす。ところが、筋の通った 2 つのルールが重なると、エージェントがひと息ついた瞬間に、エージェントがバックグラウンドで開いたタブが全部眠ってしまう。

とはいえ、エージェントが実際に操作しているタブなら大丈夫だろう、と思うかもしれない。エージェントに A と B の 2 つのタブを任せ、最初の 3 分間は 30 秒ごとに A を読ませた。A はその間ずっと普通に動いていたが、誰も触らない B は 2 分目からほぼ止まった。次に、B を読むように切り替えさせた。B はすぐに目を覚ましたが、30 秒ほどすると、放っておかれたばかりの A が凍結された。

つまり、エージェントがタブに触れても、そのタブが起きていられるのは 20～30 秒だけだ。エージェントがほかの作業に移ったり、少し長めに考え込んだりしただけで、グループが折りたたまれ、タブも一緒に眠ってしまう。人にとっては、ブラウザがメモリを少し節約してくれただけの話だ。エージェントにとってはずっと深刻で、さっきまでいたページが動かなくなったことを、エージェント自身はまったく知らない。

4. サポートに YES は届かなかった#

凍結されたのがカウントダウンなら、何かが遅れて終わるだけで済む。凍結されたのがサポートチャットなら、仕事そのものが失敗する。オンラインのサポートチャット、ネットバンキング、試験のページ、チケットの順番待ち。どれもあなたがその場にいることを前提にしていて、数秒おきにこっそりサーバーへ「まだいます」と伝えている。ちょっとサポート側の立場になってみてほしい。相手から 45 秒間なんの反応もなかったら、どう思うだろう。もういなくなったと考えて、セッションを閉じるはずだ。7 月に私が Origin Energy に送った苦情も、まさにこういうチャットを通していた。

そこで、そういうサポートページを作った。10 秒ごとにサーバーへ生存確認を送り、サーバーは 45 秒間何も届かなければチャットを終了する。チャット開始から 1 分後、サポートからこう届く。「Reply YES and I will refund it today.」（YES と返信していただければ、本日中に返金します。）

今回も Claude に 2 つのタブを任せた。まず A で別の仕事を片づけさせ、これに 1 分半かかった。次に、ターミナルでコマンドを実行しに行くときと同じように、1 分半ブラウザに触れない。最後に B のサポートページに戻って YES と返信する。その間ずっとウィンドウは画面に出ていて、前面には私のタブ、Claude のタブグループはその後ろにあった。普段の使い方そのもので、変わったことは何もない。

エージェントが手を止めて 20 秒後、Claude のタブグループが折りたたまれ、B のサポートページが凍結され、生存確認の送信も止まった。1 分ちょっとたってエージェントが B に戻ると、そこにはこう表示されていた。

Chat ended: no check-in from this page for 83 s. Please sign in again to start a new chat. （チャットは終了しました：このページからの生存確認が 83 秒間ありません。新しいチャットを始めるには、もう一度サインインしてください。）

ここで注意してほしいのは、サーバーが見ているのはページが黙っている時間で、チャットを開いている時間ではないことだ。ページが生存確認を送り続けているかぎり、どれだけ放っておいても切れない。B が切れたのは、凍結されてから 83 秒間、ひと言も発しなかったからだ。

入力欄も送信ボタンも、すでにグレーアウトしていた。YES はもう送れず、サポートは電話を切ったあとで、返金の話は宙に浮いた。エージェントが代わりにサインインし直すこともできないので、あなたが戻ってきて、最初から並び直すしかない。同じ作業を Embiody でも、エージェントが同じく 1 分半離れる条件で走らせた。こちらのサポートページは 10 秒ごとに生存確認を送り続け、ずっと Connected と表示されたまま。YES は無事に届き、サポートからは「Done, the refund is on its way.」（完了しました。返金の手続きを進めています。）と返ってきた。左が Chrome、右が Embiody で並べるとこうなる。

こう反論したくなるかもしれない。さっき、サーバーの返事を待つ書き方なら減速の影響を受けないと言ったし、サポートの生存確認もまさにその書き方なのに、なぜ切れたのか。その通りで、減速だけならサポートページは 10 秒ごとに生存確認を送り続けられた。壊したのは凍結のほうだ。減速は、自分でかけた目覚ましを 1 分に 1 回しか鳴らせなくするだけ。凍結は、ページ全体の電源を落とす。中のものは全部止まる。自分でかけた目覚ましも、折り返しの電話を待つ処理も同じように止まるのだから、生存確認が止まるのも当然だ。

では、拡張機能がグループを折りたたまないようにすればいいのでは。実は、折りたたむのは 1 つの状況に限られている。ウィンドウの前面に表示されているタブが、あなたのタブであるときだ。試しに Claude のタブグループを専用のウィンドウに移し、前面のタブが Claude のタブになるようにしてみた。すると拡張機能は折りたたまず、サポートページは減速されるだけで、11 分間ずっとつながっていた。でも、わざわざ Claude のためだけに別のウィンドウを開く人がいるだろうか。Claude のタブグループは、あなたが使っているウィンドウの中にある。

Claude in Chrome の立場から見ると、身動きがとれない。あなたと同じブラウザ、同じウィンドウを共有しているからだ。折りたたまなければ、Claude のタブはあなたのタブバーに広がったままで邪魔になる。折りたためば、Chrome が自分のルールで凍結する。折りたたむのは拡張機能自身の製品上の判断で、凍結は Chrome のルールだから、拡張機能が変えられるのは前者だけだ。それに、たとえ一度も折りたたまなかったとしても、Claude のタブはあなたのタブの後ろにあって、やはり見えず、やはり減速される。

エージェントが人のために設計されたブラウザに間借りしているかぎり、ここから抜け出す道はない。そしてエージェントはブラウザなしではやっていけない。ウェブは人のために作られたものだし、人とエージェントが同じブラウザで、同じサイトを使って並んで働くのが、これからの流れなのは明らかだからだ。

（2026 年 11 月 12 日、Chrome 157.0.8103.51、拡張機能 1.0.106、各 1 回。）

5. 誰かが見ているとページは思っている。でも何も描かれていない#

話がここで終わりでも、すでに大きな問題だ。だが、もっと気づきにくい問題も見つかった。今回はページは凍結されておらず、タイマーも正確で、ページ自身は自分が表示されていると思っている。それなのに、画面はほとんど動いていなかった。

進捗バーが 2 本あるページを作った。緑のバーは時間に合わせて、1 秒に 1 目盛り進む。赤のバーは、ブラウザが実際に描いたフレームに合わせて、1 フレームごとに少しずつ進む。Claude にこのページをバックグラウンドのタブで 2 分間操作させた。まず 1 回クリックして音楽を再生し、あとは 10 秒ごとにリストをスクロールしてページを読む。最後に、私がそのタブを前面に出した。

前面に出た瞬間、緑のバーは満タンで、赤のバーはほとんど進んでいなかった。タイマーでは 184 秒たっていたのに、描かれたフレームは 620 ほど。通常の 1 秒 60 フレームなら 11,000 前後になるはずだ。最初の 100 秒で描かれたのはわずか 387 フレームで、平均すると 1 秒に 4 フレーム足らず。人の目にはスライドショーにしか見えない。ページは見られているつもりでいたが、レンダラーは実際にはそれを描いていなかった。

画面の描画が遅い。それが何か問題になるのか。数字をアニメーションで見せたがるサイトはたくさんある。企業サイトのトップにある「導入企業 98,765 社」のようなもので、ページを開くと 0 からカウントアップして、2、3 秒後に最終的な数字で止まる。そういうページをエージェントがバックグラウンドで開くと、何も描かれていないので、数字が途中で止まったままになることがある。

3 秒で 0 から 98,765 までカウントアップするページを作り、Claude にバックグラウンドの新しいタブで開かせ、別の作業をさせてから、10 秒後に戻って数字を読ませた。結果はこうだ。

次の動画は、エージェントが別の作業をしている間、2 つのバックグラウンドのタブで何が起きていたかを映したものだ。

Chrome で 3 回とも違う数字になったのは、ページがバックグラウンドに隠れたまま 1 フレームも描かれず、数字が 0 のままだったからだ。エージェントが読みに来た瞬間に拡張機能がページを「表示中」にし、数字はそこでやっとカウントアップを始める。エージェントはそれが終わるのを待たないので、その時点までに進んだ数字を読むことになる。走っている人の写真を撮るようなもので、いつシャッターを切っても、写るのはコースの途中にいる姿だ。

いちばんまずいのは、エージェントが「この数字は間違っているかもしれない」と教えてくれないことだ。エラーは出ないし、まだ終わっていないアニメーションを見たのだと知るすべもない。エージェントから見れば、ページが開き、数字が読めて、すべて順調だ。一度しか読まなければ、間違った数字を事実としてあなたに渡す。しかもこれは、私が作ったテストページにすぎない。エージェントがバックグラウンドのタブで、コンサートのチケットやタイムセールの商品を取りに行っていたらどうなるか、想像してみてほしい。

（2026 年 11 月 12 日、Chrome 157.0.8103.51、拡張機能 1.0.106。）

6. シュレーディンガーのタブ#

ここまで来て、シュレーディンガーの猫を思い出した。あの有名な思考実験では、箱を開けるまで、猫が生きているのか死んでいるのか誰にも言えない。Chrome の中のエージェントのタブも似たようなものだ。見ている間はちゃんと働く。見ていないと、1 分に 1 回しか動いていないかもしれないし、もう凍結されているかもしれない。エージェントがタブを操作するのは、箱を開けて中をのぞくようなもので、タブはしばらく目を覚ます。エージェントが離れると、箱はまた閉じる。しかも今回は、その箱が目に見える。ひとりでに折りたたまれる、あのタブグループだ。

エージェントがいくつもの仕事を同時に進めるとき、操作できるタブは一度に 1 つだけで、残りは箱の中に閉じ込められている。遅くなっているだけのもの、もう凍結されたもの、普通に見えて実は描かれてすらいないもの。そして、どのタブがどの状態にあるのか、エージェント自身はまったくわかっていない。だからこれは、少し速いか遅いかという話ではない。エージェントが返してくる結果を信用できるかどうかを左右する話だ。

裏で何が起きているのかを知るため、Chromium 156 のソースコード（テストした 157 と同じ振る舞いをする）と、Claude in Chrome 1.0.106 拡張機能のコードを突き合わせて読んだ。すると、7 つのルールが積み重なっていることがわかった。

7. 7 つのルールは、実際に何と書いてあるのか#

この節では、ここまでの話に出てきた 7 つのルールを、Chromium のソースコードと照らし合わせて 1 つずつ説明する。とことん突き詰めたい人や、自分でソースを確かめたい人向けだ。何が起きるかだけ知りたいなら、「バックグラウンドのタブは減速され、凍結され、描かれない」とわかっていれば十分で、8 節「Chrome の制限をオフにすればいいのでは？」まで飛ばしても、そのあとを読むのに困ることはない。

1. 隠れたページの中で鎖になったタイマーは、猶予期間を過ぎると 1 分に 1 回しか起きられない。 Chrome のソースコードでは、これを intensive wake-up throttling（集中的なウェイクアップの抑制）と呼んでいる。どういう意味か。さっきの「自分でかけた目覚まし」のことだ。タイマーが発火し、そのコールバックの中で次のタイマーをセットする。Chrome はこの鎖が何段つながっているかを数えていて、7 段目以降は、ページが一定時間隠れていれば、そうしたタイマーは 1 分に 1 回しか発火できない。カウントダウンはまさにこの書き方なので引っかかる。サーバーの返事のあとにセットしたタイマーは 1 段目から数え直しになるので、エクスポートやサポートの生存確認は影響を受けない。ページが隠れてからの猶予期間は通常 60 秒で、エージェントがバックグラウンドで開いて一度も表示されていないタブも 60 秒。別のタブへの切り替え、ウィンドウが完全に覆われること、ウィンドウの最小化は、どれも「隠れた」扱いになる。ほかに、もっと緩い制限が 2 つある。どのタイマーも 1 秒に 1 回より多くは起きられないこと。それから、隠れて 10 秒たつと、すべてのタイマーのコールバックを合わせて CPU の 1% しか使えないこと。こちらはコールバックの中で重い処理をしているページでしか問題にならない。（third_party/blink/renderer/platform/scheduler/main_thread/page_scheduler_impl.cc。段数は third_party/blink/renderer/core/scheduler/dom_timer.cc）

2. タブグループが折りたたまれると、中のタブが凍結される。 グループが折りたたまれた瞬間、Chrome は中のすべてのタブに「凍結」の票を投じる。直近 5 分以内に表示されたタブは保護され、一度も表示されていないタブはその場で凍結される。凍結とは、ページのコードがひとつ残らず止まることだ。遅くなるのではなく、まったく動かない。引き出しの電源を落とすのと同じだ。（chrome/browser/ui/views/tabs/browser_tab_strip_controller.cc が票を投じ、components/performance_manager/freezing/freezing_policy.cc が決める）

3. Claude in Chrome は、20 秒ほど手が空くと自分のタブグループを折りたたむ。 これはウィンドウの前面のタブが Claude 自身のタブでないときだけ起きる。次に仕事があるときは、拡張機能がまずグループを展開する。ルール 3 とルール 2 を合わせたものが、さっき見た「20 秒で完全に止まる」の正体だ。拡張機能がグループを折りたたみ、Chrome が中のタブを凍結する。

4. 拡張機能は、操作中のタブに「誰かが見ている」と思い込ませる。 拡張機能は操作のたびに、その直前にデバッグ用のプロトコルで、フォーカスエミュレーション（Emulation.setFocusEmulationEnabled）というスイッチをオンにする。これは何をするのか。Chrome に「このタブは見られている」と伝えるのだ。するとページの visibilityState は visible になり、タイマーも隠れたページのようには抑制されなくなる。ウィンドウ全体が最小化されていても、だ。操作から 20 秒ほどたつと、拡張機能はこのスイッチをまたオフにする。

ルール 3 と 4 を合わせると、ある奇妙な現象にも説明がつく。エージェントが最後に操作したタブが、グループが折りたたまれても凍結されないことがあるのはなぜか。拡張機能がわざと守っているのだろうと思っていたが、コードを読むと、まったくの偶然だった。グループが折りたたまれると、Chrome は中のタブ一つひとつに凍結の命令を送る。エージェントが最後に触れたタブは、その時点ではまだフォーカスエミュレーションがオンなので、自分は見られていると思い込んで命令を拒否する。ところが Chrome 側は拒否されたことに気づかず、そのタブを「凍結済み」と記録して、二度と命令を送らない。フォーカスエミュレーションがオフになり、タブが本当に見えなくなっても、凍結しに戻ってくる者はいない。

別の言い方をしよう。寮の管理人が夜、消灯の見回りに来る。部屋の中からあなたが「まだ人がいます」と声をかけると、管理人は帳面に「消灯済み」と書いて立ち去り、もう戻ってこない。あなたが眠ってしまったあとも、明かりは一晩中ついたままだ。このタブが起きていられるのは、「グループが折りたたまれる」と「フォーカスエミュレーションがオフになる」が、たまたまこの順番で起きたからにすぎない。拡張機能も Chrome も、そう設計したわけではない。さっきエージェントが A から B に移ったとき、A は逆の順番に当たった。先に A のフォーカスエミュレーションがオフになっていたので、グループが折りたたまれた時点で A はもう見えておらず、凍結の命令は届いた瞬間に効いた。

5. 実際には画面に描かれていないページは、フレームが 1 秒に 1 回に減らされる。 フォーカスエミュレーションでページをだまし、見られていると思わせることはできても、画面を描く部分まではだませない。Chrome には viz というコンポジット（合成）サービスがあり、ディスプレイの更新に合わせて各タブに「次のフレームを描き始めて」という合図（BeginFrame）を送っている。あるタブのフレームが 3 回続けて、どのウィンドウにも実際には描かれなかった場合、その合図は 1 秒に 1 回に落ちる。ソースのコメントにも、はっきり「we throttle BeginFrames to 1 per second」と書いてある（components/viz/service/frame_sinks/compositor_frame_sink_support.h、kUndrawnFrameLimit = 3）。そのため、ほかのタブの後ろにあるタブや、最小化されたウィンドウの中のタブでは、タイマーが普通に動いていても、requestAnimationFrame（ウェブページがアニメーションを描くのに使う関数）は 1 秒に 1、2 回しか動けない。舞台に向けたカメラのようなものだ。役者は演技を続けているのに、カメラは配信を誰も見ていないことに気づいて、1 秒に 1 枚の撮影に切り替えてしまう。私が計測した 1 秒 4 フレーム足らずのうち、余分な 2、3 フレームは、たぶん拡張機能がスクリーンショットを撮るついでに描かれたものだ。

6. 覆われたウィンドウや最小化されたウィンドウも、見えていない扱いになる。 Windows では、Chrome はウィンドウがほかのウィンドウに完全に覆われているかを自分で判定し、覆われていれば中のタブを隠れたものとして扱う（ui/aura/native_window_occlusion_tracker_win.cc、既定で有効）。ウィンドウが最小化されると、コンポジット領域全体が 0×0 になる（desktop_window_tree_host_win.cc）。

7. バックグラウンドのレンダラープロセスも格下げされる。 レンダラープロセスに見えているタブが 1 つもなければ、Chrome はそのプロセスの優先度を最低まで下げ、Windows に EcoQoS を要求する。EcoQoS とは、CPU をいちばん省電力な周波数で動かし、処理を高効率コアに回す仕組みで、その代わりに速度が落ちる（base/process/process_win.cc、kUseEcoQoSForBackgroundProcess は既定で有効）。このルールはウィンドウが本当に見えているかどうかを見るので、フォーカスエミュレーションではだませない。

7 つのルールはどれも、それ単体では理にかなっている。だが積み重なると、エージェントのタブは厄介な立場に置かれる。ページは自分が見えていると思っているのに、タイマーは抑制されているかもしれない。エージェントがついさっき操作したのに、少したつと凍結されているかもしれない。凍結されてはいないのに、画面はほとんど動かない。どのタブが起きていてどのタブが眠っているのか、拡張機能を書いた人たちにさえ言えないかもしれない。結局は同じところに戻ってくる。ブラウザのルールは、人のために作られている。

8. Chrome の制限をオフにすればいいのでは？#

Chrome のルールが原因なら、起動オプションでオフにすればいい、と思うかもしれない。一部はその通りだ。--disable-background-timer-throttling、--intensive-wake-up-throttling-policy=0、--disable-renderer-backgrounding、--disable-backgrounding-occluded-windows で、タイマーの抑制とプロセスの格下げはオフにできる。でもフレームのルールはオフにできない。画面に描かれていないタブは、タイマーの抑制を無効にしたからといって普通のフレームが戻ってくるわけではないので、カウントアップ途中の数字を読んでしまう問題はそれでも起きる。

9. 同じテストを Embiody で#

私たちは、AIエージェントのために作った Windows 用ブラウザ Embiody を開発している。エージェントは、そのために作った MCP サーバー BrowserDo を通じて Embiody で作業する。Claude Code と Codex ならコマンド 1 つ、Cursor と Claude Desktop なら設定を数行追加するだけでつながる。AI タブ機能の出発点は、あの 7 月の午後だった。自分は自分の仕事を続けながら、エージェントにいくつものことを同時に進めてほしかったのだ。

そこで、ここまでのテストをすべて、Embiody でも同じ条件で走らせた。変えたのは、ブラウザを Embiody に、ツールを BrowserDo にしたことだけだ。結果はこうなった。

Embiody では、タブ B はほかのタブの後ろにあって、誰も触らず、ウィンドウが最小化されていても、時間どおりに終わる。エージェントがバックグラウンドで操作しているページは描かれ続け、統計の数字は一度で正しく読め、サポートチャットはつながったままだ。ただしこれは、エージェントが使っているタブだけの話だ。あなたが自分で開いたタブは、これまでどおりの省電力ルールでバックグラウンドでは抑制されるので、ブラウザにエージェントがいるからといって、あなたのタブの電力消費が増えるわけではない。箱の中の猫は、ずっと起きている。公平のために言っておくと、今回は Windows マシン 1 台で、Embiody は各テスト 1～2 回しか走らせておらず、大規模なテストにはほど遠い。それでも少なくともこれらの場面では、違いははっきりしている。

もう一つはっきりさせておきたいのは、これらの問題が Claude in Chrome に限った話ではないことだ。どの拡張機能や自動化ツールを使っても、Chrome で働くエージェントは Chrome のルールに従うしかない。冒頭のカウントダウンのテストでも、私が手で開いたタブは、Claude のタブと同じく 8 分で 390 秒以上遅れた。今回は出くわさなかったルールも、あと 2 つある。PC のメモリが足りなくなると、Chrome は最も長く見られていないバックグラウンドのタブを破棄し、戻ってきたときに読み込み直す。そしてノート PC が電源から外れていてバッテリーが 20% を切ると、CPU をそこそこ使っているバックグラウンドのタブが凍結される。人なら、席を外している間にこれに当たっても、戻ってから再読み込みすれば済む。午後いっぱい動き続け、いくつものページを同時に面倒みるエージェントは、遅かれ早かれこれにぶつかる。

10. AI には専用のブラウザが要る#

AI で仕事をするようになって数年、ますます確信するようになったことがある。AI には専用のブラウザが要る。Chrome で間に合わせるのは、その場しのぎにすぎない。

Chrome の出来が悪いと言いたいのではない。これらのルールは、画面の前に座っている人がより快適に使えるように、長年かけて磨かれてきたものだ。見えないタブは資源を控えめに使うべきだし、誰も見ていないアニメーションは描かなくていいし、長く使われていないページは凍結したり、破棄したりしていい。拡張機能にできるのは、そのルールの上にもう一枚重ねることだけだ。フォーカスエミュレーションでページに誰かが見ていると思わせたり、タブグループを折りたたんでエージェントのタブがあなたの邪魔をしないようにしたり。でもルールは Chrome のもので、Chrome のアーキテクチャは人のために設計されている。根本から変えないかぎり、拡張機能はつぎはぎで対処するしかない。

さっきのタブ、管理人が「消灯済み」と書いたあのタブこそ、つぎはぎの結果だ。あれが起きていられるのは、2 つの出来事がたまたま決まった順番で起きたからにすぎない。Chrome の新しいバージョンが出れば、その順番はいつ変わってもおかしくない。こうした偶然は、避けることも予測することもできない。Chrome はそもそもエージェントのために設計されていないからだ。

偶然に頼るのをやめるには、ブラウザ自身のルールがエージェントを考えに入れる必要がある。人にとっては、タブが見えているかどうかで、そのタブが資源を使い続けるべきかが決まる。エージェントにとっては、誰も見ていないタブが、あなたのために止められない何かの真っ最中かもしれない。画面の前に誰かがいてもいなくても、働き続けるべきなのだ。これはブラウザエンジンそのものでしか決められない。Embiody の AI タブは、この原則に沿って作られている。

（Embiody：各テスト 1～2 回、2026 年 11 月 11～12 日、同じマシン。）

テストしていないこと#

• Windows マシン 1 台、Chrome は 1 バージョンだけ。7 月に手作業で試したときは、減速がはっきりするのは 5 分後からだったと記憶している。今回（Chrome 157）は 1 分ほどだった。Chrome が変わったのか、私の記憶違いなのかはわからない。
• Mac と Linux は試しておらず、メモリセーバーをオンにした状態も試していない。
• メモリ不足のときのタブの破棄と、バッテリー低下時のタブの凍結は、ソースコードを読んだだけで、計測はしていない。

2 分で自分で試す#

https://embiody.com/lab/background-tab/ を開くと、15 分のカウントダウンが始まる。別のタブに切り替え（ウィンドウを覆っても、最小化してもいい）、2 分後に戻ってきて「Behind by」の欄を見てほしい。離れている間にカウントダウンが失った秒数だ。0 s なら、ページはずっと時間どおりに動いていたことになる。なお、テストページは英語表記だ。

最後に#

Chrome がいつかエージェントのためにこれらのルールを変えるのかどうかは、わからない。理由はもっともだ。電力を節約し、メモリを節約し、前面の操作をなめらかに保つのは、ブラウザがまさにやるべきことだ。ただ、ブラウザは画面の前に人が座っていて、一度に 1 つのタブを見ていると想定してきた。今は画面の前に誰もいないかもしれず、タブの向こうではエージェントがいくつものページを同時に面倒みている。

見ていないと、働かない。でもエージェントの仕事は、まさにあなたが見ていない間の仕事なのだ。