Chromeの新規タブが遅い原因を調査したら、Mark Tab Managerの大量Tab Groupsだった

最近、Chromeの動作が妙に重くなっていました。

特に気になっていたのが、新しいタブを開くときの引っかかりです。

最初はChrome本体の問題か、開いているタブの数が多すぎるのかと思っていました。

しかし調べていくと、原因は普段使っていたChrome拡張機能「Mark Tab Manager」と、Chromeに大量に残っていたTab Groupsでした。

Mark Tab ManagerをOFFにすると軽くなった

私はChrome拡張の「Mark Tab Manager」を使っています。

この拡張には、同じドメインのタブをまとめてTab Groupにしてくれる機能があり、タブを大量に開く使い方ではかなり便利です。

ところが最近Chromeが重くなってきたため、原因を切り分けるために拡張機能をいくつかOFFにしてみました。

すると、

Mark Tab ManagerをOFFにしたとき、新規タブを開く動作が明らかに軽くなりました。

そこで、

Mark Tab Managerが何か大量のデータを処理しているのでは?

と疑って調べてみることにしました。

Chromeに大量のTab Groupsが残っていた

Chromeに保存されているTab Groupsを確認してみると、大量のグループが残っていました。

正確には数えていませんが、300個前後はあったと思います。

しかも現在開いているタブのグループだけではありません。

すでに使っていない、過去に作成されたTab Groupまで大量に残っていました。

どうやらMark Tab Managerでグループを整理するときの操作が原因だったようです。

「Close group」と「Delete Group」は違う

Mark Tab ManagerでTab Groupをまとめて消すときには、

  • Close group
  • Delete Group

という選択肢があります。

私はこれまで「Close group」を選ぶことが多かったのですが、どうやらこれだとタブは閉じても、Chrome側にTab Groupの定義が残るようです。

つまり、

Close group
↓
タブは閉じる
↓
Tab Groupの情報はChromeに残る

という状態になっていたようです。

長期間Mark Tab Managerを使い続けた結果、使われなくなったTab Groupsが少しずつ蓄積。

最終的には数百個になっていました。

Mark Tab ManagerはそれらのTab Group情報も参照・処理しているようで、数が増えすぎると動作が重くなっていたのではないかと考えています。

保存されているTab Groupsを表示する

Chromeに保存されているTab Groupsは、ブックマークバーから確認できます。

まずChromeのブックマークバーを右クリックします。

そこで、

Show tab groups

をONにします。

するとブックマークバーにTab Groupsが表示されるようになります。

ここには、現在開いているTab Groupだけではなく、現在使っていない保存済みのTab Groupsも表示されます。

私の環境では、ここに大量のTab Groupsが並んでいました。

不要なTab Groupを削除する

不要なTab Groupは、

Tab Groupを右クリック
↓
Delete

で削除できます。

つまり、1グループにつき2クリックです。

操作自体は簡単なのですが、問題は私の場合数百個残っていたことです。

一括削除する方法は見つからなかった

当然、

全部一括で削除できないのか?

と思って調べました。

しかし、少なくとも私が調べた範囲では、ChromeのUIから保存済みTab Groupsを一括削除する簡単な方法は見つかりませんでした。

仕方がないので、

右クリック → Delete
右クリック → Delete
右クリック → Delete
...

と、ひたすら手動で削除しました。

数百個あるので、かなり面倒です。

ただし1個につき2クリックなので、単純作業として全部消しました。

全部削除したらMark Tab Managerが軽くなった

大量に残っていたTab Groupsをすべて削除したあと、Mark Tab Managerを再び有効にしてみました。

すると予想通り、Mark Tab Managerの動作がかなり軽くなりました。

そして、気になっていたChromeの新規タブ作成時の重さも改善しました。

今回の原因は、

Mark Tab Managerが重い

というより、

Mark Tab Managerを長期間使用
↓
Close groupを使ってグループを閉じる
↓
ChromeにTab Groupの定義が残る
↓
数百個まで蓄積
↓
Mark Tab Managerが大量のTab Groupsを処理
↓
Chromeの新規タブ作成などが重くなる

という流れだった可能性が高そうです。

まとめ

Mark Tab Managerを使っていて、最近Chromeが重くなってきた場合は、Chromeに保存されているTab Groupsの数を確認してみるとよいかもしれません。

特に注意したいのが、

「Close group」と「Delete Group」の違い

です。

Close groupだけを使い続けていると、タブは消えてもTab Groupの定義自体はChrome側に残り続けるようです。

確認方法は、

ブックマークバーを右クリック
↓
Show tab groups をON

です。

不要なものが大量に表示された場合は、

右クリック
↓
Delete

で削除できます。

私の環境では300個前後まで増えていましたが、すべて削除したところMark Tab ManagerもChromeも軽くなりました。

「Mark Tab Managerを使っている」「Chromeの新規タブが最近妙に遅い」

という場合は、一度Tab Groupsが大量に残っていないか確認してみることをおすすめします。

Google Play Consoleの内部テストで「Something went wrong on our end」が出た → 20分待ったら解決した話

Androidアプリを、Google Play Consoleの「内部テスト」を使って実機にインストールしようとしたところ、少しハマりました。

結論から書くと、

AABをアップロードした直後は、内部テスト用URLが発行されていても、すぐにはアプリをダウンロードできない場合があるようです。

私の場合は、20分ほど待ったところ正常にダウンロードできました。

起きたこと

Google Play ConsoleからAAB(Android App Bundle)ファイルをアップロードし、内部テストのリリースを作成しました。

内部テスト用のURLも発行されたので、そのURLをAndroidスマートフォンで開き、Google Playからアプリをインストールしようとしました。

ところが、ダウンロードしようとすると次のエラーが表示されました。

Error Something went wrong on our end. Please try again.

「Google側で何かエラーが起きている?」

「AABの作り方がおかしかった?」

「署名やGoogle Play Consoleの設定を間違えた?」

などと疑いました。

20分後にもう一度試してみた

設定を変更せず、そのまま20分ほど経ってから再び内部テスト用URLを開いてみました。

すると、今度は普通にGoogle Playからダウンロード・インストールできました。

AABを再アップロードしたわけでもありません。

つまり今回については、AABや内部テストの設定ミスではなく、Google Play側の処理がまだ完了していなかった可能性が高そうです。

URL発行=すぐインストール可能、ではない

少し紛らわしいのが、

内部テスト用URL自体は先に使える状態になる

という点です。

URLが発行されると、こちらとしては「もう配信準備が終わった」と思ってしまいます。

しかし実際には、その裏側ではアップロードしたAABから端末向けのAPKを生成するなど、Google Play側で何らかの処理が続いているようです。

その処理が終わる前にインストールしようとすると、

「Something went wrong on our end. Please try again.」

のような、かなり曖昧なエラーになる場合があるようです。

同じ症状が出たら、まず少し待ってみる

Google Play Consoleの内部テストで、

AABのアップロードは成功している 内部テストのリリースも作成できている テスターとして正しいGoogleアカウントを使っている 内部テスト用URLも開ける なのに「Something went wrong on our end」と表示される

という状態なら、設定を変更する前に10〜30分程度待ってから再度試してみるのがよさそうです。

今回の私の環境では、約20分で正常にインストールできるようになりました。

まとめ

Google Play ConsoleでAABをアップロードして内部テストを開始したところ、内部テスト用URLからインストールしようとして、

「Something went wrong on our end. Please try again.」

というエラーが出ました。

しかし、約20分後に同じURLから試したところ正常にインストールできました。

どうやら、

「内部テスト用URLが発行された」=「Google Play側の配信準備が完全に終わった」

とは限らないようです。

同じエラーに遭遇した場合、AABや署名、Play Consoleの設定をすぐに疑って変更するのではなく、まずは少し時間を置いて再度試してみるのがおすすめです。

Google Play Consoleは処理状況が分かりにくいこともあるので、今回のようなケースもある、という備忘録でした。

WSL2環境にてcargo competeでatcoderにログインする

環境

  • windows 11
  • visual studio code
  • WSL2
  • Rust

cargo competeとは?

  • cargo compete new abc300 とすると問題別のRustファイルを作ってくれて、テストケースもダウンロードしてくれる(下記画像)

  • cargo compete test a でa問題の全テストケースをチェックしてくれる
  • (cargo compete submit a で提出は、最近はできないと思う)
  • ojのような物です https://github.com/online-judge-tools/oj

cargo compete login atcoder に失敗(と、解決方法)

それでも提出はできない

  • すぐさま cargo compete submit a するも、error: Submission rejectedとなる
  • (そういえばojもいつからか自動提出はrejectされるようになってた記憶)
  • 提出はブラウザからコピペすることにしましょう

でもログインはしておいた方がいい

  • 「ログイン通すのは面倒そうだからやらなくていいか!」とはならない
  • abc300は過去のコンテストだからログインなしでテストケースダウンロードできるけど、開催中のコンテストはログインユーザーしかダウンロードできなかったはず
  • なので、開催中コンテストでcargo competeを使う人は、Cookieコピペのログインまで通しておかないと、本番で困ることになる
  • コンテスト前には cargo compete login atcoder と入力してログイン状態が維持できているか確認しておくと、さらに良い

2026/01/17 開催中コンテストで動作確認

  • ログイン済み
  • cargo compete new abc441✅
  • cargo compete test a✅
  • cargo compete submit a❌️

codingame (こどげ) Soak Overflow💦🤖Summer Challenge 2025 参加記 全280位 Gold

コンテストページ

私の結果

  • 280位 Gold🏆️
  • (Legendは166位まで)

感想

  • 166位までがLegendなので行きたかった
  • (途中、Gold 10位あたりのこともあった)
  • 参加者(提出者)3500人ほど

最終手法

  • MOVE全探索からの、攻撃は各エージェントで個別に評価関数からBest解を採用
  • 相手の行動をほぼ予想していない
    • 敵がボム持っていて、範囲内に味方がいたらそこに投げてくる予想、くらい

前半:LLM

  • 最初はGeminiにコーディングさせ、手を加えずに提出
  • 各エージェントごとにMOVE&攻撃を評価関数のBestで決定
  • ゲームの把握、試行錯誤に役立った👍
  • 欠点
    • ひっそりバグを埋め込む
    • コードが長くなる(最終1000行)
  • なので後半は手書きで、方針もコードも書き直し(最終655行)

後半:手書き

  • MOVE全探索 O(5^エージェント数)
    • とはいえ「動き回るとボムを避けれるかも」というのがあるので「停滞禁止」とした O(4^エージェント数)
  • MOVEが決まった状態で、各エージェントの攻撃は評価関数のBestで決める
  • 評価値 = MOVE評価値 + ∑(各エージェントの攻撃評価値)
  • これのBestを採用

コンテスト終了3日前?サイトが重い...

  • これくらいから皆が「時間いっぱい計算・探索させる」&「提出しまくり」になるのか、サイトが重くなる
  • 提出して様子を見ることが困難に
  • これにて撤退😭
  • ★知見:上記の理由により、終盤に全力出すよりも中盤でリードしておくほうがストレスが少なそう(次回やる)

Q.「自分の評価関数Botで相手の行動を予想できるのか?」

  • そうは思えなかった
  • 撃っては引く人もいるだろうし、フォーカスして1体を倒す人もいるだろうし、カバー重視の人もいるだろう
    • とはいうものの、皆はランキングが上がるように調整して提出するので傾向はあるはず
    • 自分の評価関数くらいしか予想の道具がない
    • 「自分の評価関数で相手を予想」それでいいらしい

評価関数ガチャで右往左往

  • 上位がLegendに行った後、私はGold内で10位あたりに居たこともあった
    • (とはいえ評価関数ガチャでの勝ち&運で想定以上に(割り振られた150戦でたまたま)勝ったのだろう)
    • BOSSに勝ててなかったので、近そうで遠い距離かも
  • 評価関数ガチャは知識を重ねている感じがしない😭

コンテスト後のタイムライン

ふまえて、やりたいこと

  • MCTS, DUCT, 聞いたことはある...🤔程度
  • 聞いたことがあるだけだと「今回の設定で適用できそうか?」判定できない
  • 次回に向けてthunderさんの本📕を買いました
    • 追記:読んだけど、取れる選択肢が多い場合にDUCTをどう使えばいいのか?など
    • 過去門とDUCTを実際に使っている人から学ぶ必要がありそう
  • bowwowさんの「ローカル自己対戦でパラメタ調整」は取り入れたい
  • simanさんの「claude codeにジャッジコードを読ませてルールの細かいところを聞くとソースコードの場所も教えてくれるので便利」
  • 自分の2手先など読む(評価したい)ならビムサ
    • (🤔相手も2回動くので盤面結構違うよね)
  • 相手の行動予想ならminimax (自分の評価関数使用)
    • 方針:1手読み。双方択を山登りで作って最後にminimax https://x.com/viewlagoon/status/1949782629588595096
    • (🤔相手の行動Best5が予想できたとして、それに対応するこちらの手も5種類決まるが、最終的にどれにする?)
  • 山登り:これを使えばMOVEと攻撃を混ぜて最適化できたかも

D - Home Garden セグ木で殴る

解説

code

#include <atcoder/lazysegtree>
using namespace atcoder; // 忘れがち

// 区間加算・区間和取得
struct S{
    long long value;
    int size;
};
using F = long long;

S op(S a, S b){ return {a.value+b.value, a.size+b.size}; }
S e(){ return {0, 0}; }
S mapping(F f, S x){ return {x.value + f*x.size, x.size}; }
F composition(F f, F g){ return f+g; }
F id(){ return 0; }

int main(){
    cin.tie(0);
    ios::sync_with_stdio(false);

    std::vector<S> v(200000+10, {0, 1});
    atcoder::lazy_segtree<S, op, e, F, mapping, composition, id> seg(v);

    // input
    ll Q;cin>>Q;
    ll plant_cnt=0;
    ll current_pos=0;
    while(Q--){
      ll ty;cin>>ty;

      if(ty==1){
        // うえる
        plant_cnt++;
      }
      else if(ty==2){
        // T日まつ
        ll T;cin>>T;
        seg.apply(0, plant_cnt, T); // 足す
      }
      else{
        // 収穫
        ll H;cin>>H;
        ll harvest_cnt=0;
        while(true){
          ll h = seg.prod(current_pos, current_pos+1).value;
          if(h>=H){
            harvest_cnt++;
            current_pos++;
          }else{
            break;
          }
        }
        p(harvest_cnt);
      }
    }

    return 0;
}