🔬 3候補を実測で潰して確定させた——「たぶんこれ」で止めていた頃、同じ不具合に3回はまった

料理の味が「なんか薄い」とき、塩・だし・火加減の3つを一気に全部変えたことがあるでしょうか。

味は直ります。

でも次に同じ「薄さ」になったとき、どれが原因だったかわかりません。

また3つとも変えて、また直った気になります。

この繰り返しをやっていると、「直し方」ではなく「偶然」で乗り越えているだけです。

原因が積み上がらないまま、同じ壁に何度でもぶつかります。

わたしが個人開発を始めた頃、ツールが止まるたびにこれをやっていました。

「なおった、よかった」で次に進む。それを繰り返していました。

あなたは今、こうなっていませんか？

• AIツールが動かなくなって「たぶんネットかな」と再起動だけで終わらせた
• 同じエラーが3回目に出て、ようやく本腰を入れて調べ始めた
• 1つ原因らしきものを見つけたら、他の候補は確認せず「たぶんこれ」と閉じた
• 直った理由がわからないまま「直ってよかった」で次に進んだ

先に結論を言います。同じ穴に繰り返し落ちるのは、原因を「たぶん」で確定させているからです。

この記事では、わたしが実際に遭遇したChrome（Googleのブラウザ）の起動タイムアウトを、3つの候補を実測で1つずつ潰して確定させた話を書きます。

確定の仕方を変えてから、翌月の調べ直しがゼロになるまでの経緯も、一緒にお伝えします。

Chromeが180秒で止まった、あの夜

何をやっていたときの話か

わたしは毎日の作業の一部を自動化するツールを動かしています。

その中に、ブラウザ（Chromeというインターネットを見るソフト）を自動で動かす処理があります。

使っているのはPlaywrightというプログラムの部品です。

「指定したWebページを自動で開いて、決まった操作をくり返す」という処理をコードで書くために使います。

ある夜、その処理が突然動かなくなりました。

起動しようとすると180秒、つまり3分待ってから止まります。

ログには TimeoutError: Waiting for browser to launch exceeded 180000 ms と表示されていました。

この 180000 ms はPlaywrightの初期設定値です。

「ブラウザが起動しないまま3分経過したら諦める」という動作を意味します。

3分待ってエラー。また3分待ってエラー。夜の9時を過ぎてから、それが何度も続きました。

「もう今夜は諦めようか」と何度か思いながら、それでも原因を調べ続けました。

3つを「たぶん」でなく順番に潰すことにした

経験上、「突然動かなくなる」には、よくある原因のパターンがあります。

今回すぐに思いついたのは、次の3つです。

1つ目は「パソコンの処理能力が限界に達した」という可能性（「リソース枯渇」という現象です）。

2つ目は「前回の処理が中途半端に終わって、使用中の目印が残ったまま」という可能性（「孤児ロック」と呼びます）。

3つ目は「プログラムからブラウザを呼び出す設定に問題がある」という可能性（「channel設定」の部分です）。

以前のわたしなら「1番目っぽいな」と感覚で決めて、再起動していました。

でも今回は、1つずつ実測で確認することにしました。

どれが外れで、どれが当たりかを、数字と事実で確定させる。それが今のわたしのやり方です。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順

1つ目の候補：パソコンの体力切れを数字で確かめる

「体力切れ」とはどういう状態か

パソコンには、同時にこなせる作業量に限りがあります。

たとえばブラウザを10個開いて、動画を再生しながら、さらに重いファイルを処理しようとすると、全体がもたつき始めます。

これがリソース（処理能力・記憶力）が不足している状態です。

ブラウザが起動できないときも、「パソコン全体が限界を超えている」という原因であることがあります。

他のアプリも遅くなったり、全体がカクカクしたりしている場合は、この可能性が高いです。

逆に言えば、ブラウザだけが止まって他は快適に動いているなら、体力切れの可能性は低いです。

今回のケースも、他の処理は普通に動いていました。

実際に数字を確認した

感覚ではなく、パソコンの使用状況を確認するツールを使って数字を直接見ました。

Macなら「アクティビティモニタ」というアプリが使えます。

Spotlight（画面右上の虫眼鏡マーク）から「アクティビティ」と入力すると起動できます。

メモリ（パソコンの作業スペースにあたる部分）の使用率は68% でした。

CPU（処理のエンジン部分）の使用率は14%前後を行き来しています。

どちらも余裕のある数字です。

経験上、限界に近くなるとメモリは90%以上に達します。

CPUは80〜100%近くに張り付いて、マウスカーソルの動きまで遅くなります。

今回は両方とも余裕がありました。

「パソコンの体力切れ」は、この時点で候補から外れました。

コマンドラインを使う場合は top コマンドでもCPUとメモリを確認できます。

top -o mem と入力すると、メモリ使用量の多い順にプロセスが並びます。

ビジュアルで直感的に把握するなら、アクティビティモニタのほうが早いです。

「たぶん体力切れではない」ではなく、「測ったら、数字として体力切れではなかった」という記録が残ります。

この「測ったら外れた」という記録が、あとで意味を持ちます。

2つ目の候補：「使用中の札」が残っていないか確かめる

孤児ロックという現象

プログラムが途中で強制終了すると、「今使っています」という目印を残したまま終わることがあります。

本来は「作業が終わったら目印を消す」という手順があります。

でも急に止まると、その「消す」という手順が実行されません。

次に起動しようとすると、残っている目印を見て「あ、別のプログラムが使っているな」と判断して入れなくなります。

でも実際には、もう誰もそこにいません。

これを「孤児ロック」と言います。「鍵がかかったままで、かけた本人がいなくなった」状態です。

Chromeが異常終了したとき、プロファイルフォルダに SingletonLock というファイルが残ることがあります。

このファイルが残っていると、次の起動時に「すでに起動中」と判断されて弾かれます。

確認した結果

今回は SingletonLock ファイルの有無を直接確認しました。

ターミナル（文字を打ち込んでパソコンに指示するアプリ）で検索すれば、ファイルの存在を確かめられます。

結果は0件 です。残っているロックは一つもありませんでした。

2つ目の候補も外れました。

「孤児ロックかもしれない」が、「孤児ロックは残っていなかった」に更新されました。

これで2つが確実に外れ、残るは3つ目だけです。

外れた事実を確認することにも、意味があります。

次に同じ症状が出たとき「前回はロックじゃなかった」という記録があれば、確認の優先順位を下げられます。

1つ1つ「違った」と言える状態にしてから次へ進む。

このリズムが積み重なると、後の調べ直し時間が大きく変わります。

3つ目の候補：呼び出し方の設定で確定した

channelとはどんな設定か

プログラムからブラウザを自動で起動するとき、「どのブラウザを使って起動するか」を指定する設定があります。

Playwrightの設定ファイルに channel という項目があります。

channel: 'chrome' と書くと「Googleが配布している公式Chromeを使ってください」という意味になります。

channel: 'chromium' と書くと「Playwrightが管理しているChromiumを使ってください」という意味になります。

ChromiumはChromeのベースになっているオープンソース版です。

Playwrightをインストールするとき npx playwright install chromium というコマンドを実行すれば、Chromiumは自動でダウンロードされます。

でもGoogleの公式Chromeは、別途インストールが必要です。

テレビのチャンネルに似た仕組みです。

「1チャンネルを映して」と指示しても、その放送が受信できる設備がなければ映りません。

channel: 'chrome' と書いても、Chromeがインストールされていない環境では動きません。

この違いが今回の核心でした。

ここで原因が確定した

設定ファイルを確認すると、channel: 'chrome' という記述がありました。

でも、その実行環境にはChromeがインストールされていませんでした。

存在しないブラウザを探し続けて、タイムアウトの制限時間である180秒 を全部使い切っていたわけです。

channel: 'chrome' の行を削除したところ、Playwrightはデフォルトのchromiumで起動するようになりました！

起動時間は3〜5秒 に戻りました。

「リソース不足でもなく、孤児ロックでもなく、channel設定だった」と確定しました。

確定までにかかった時間は40分 ほどです。

「たぶんリソースかな」と感覚で動いていた頃、同じ問題を再発させた回数は3回 でした。

確定の仕方を変えてから、再発回数はゼロです。

CMO時代は「たぶんX」で仕事が終わっていた

報告書の文化が体に染みついていた

個人開発を始める前、会社でCMO（マーケティング責任者のような役職）を経験していた時期があります。

月3,000万円規模の広告を動かす仕事をしていました。

あの頃は「原因はたぶんAです、対策はBを進めます」という報告書を1時間で書いて、会議を終わらせるのが仕事でした。

「断言」ではなく「方向性と対策の提示」ができれば十分で、それが評価される文化でした。

「たぶん」は報告の中でほとんど突っ込まれません。

次のアクションにつながっていれば、原因の確定まで求められることはほとんどありませんでした。

会議を30分で終わらせる技術と、原因を30分で確定させる技術は、全く別のものです。

前者を磨いてきた分だけ、後者が欠けていることに気づくのが遅れました。

個人で動くと、同じ穴に3回落ちた

会社を出て個人で開発を始め、同じ不具合に3回 連続で落ちたことがあります。

1回目：「たぶんネットワークが不安定だったかな」と再起動して直ったと判断しました。

2回目：また同じ症状。「前回と同じ環境の詰まりかな」と環境を再構築しました。

3回目：また同じ。

ここで初めて本腰を入れて調べ始めました。

3回合計で4〜5時間 を使いました。

最初の1回で実測まで確定させていれば、40分 で終わっていたはずです。

会社にいるとき、問題の修正は「誰かが担当する」ものでした。

個人でやると、2回目も3回目も、自分が同じ時間を使います。

「たぶん」で閉じることのコストが、組織と個人とでは全然違います。

この差に気づいたのが、3回目のときでした。

組織の中では「速く次に進む」ことが合理的な場面があります。

個人で動く場合は「遅くても確定させる」ことが、長期的に速くなる選択です。

「○○でも△△でもなく□□」という記録の型

型を変えてから、調べ直しがゼロになった

今は、原因が確定したとき、必ずこの形で記録を残しています。

「リソース不足でもなく、孤児ロックでもなく、channel設定だった」

外れた候補2つと、確定した原因1つをセットで書きます。

読んだとき、どれが外れでどれが当たりか、一瞬でわかります。

次に似た症状が出たとき、この記録を見れば「前回は最初の2つが外れだった」と確認できます。

3つを全部調べ直さなくて済むので、2回目の確認時間が格段に短くなります。

具体的には、次の4点をセットで記録しています。

1. 症状（どんなエラーが、いつ、どの処理で出たか）
2. 外れた候補（確認して違ったこと、確認方法も一緒に）
3. 確定した原因（実測した事実と数字）
4. 適用した修正（何をどう変えたか、変更したファイルや設定名）

今回のChromeの例なら「TimeoutError 180秒 / リソース正常（メモリ68%・CPU14%）・SingletonLock 0件 / channel設定をchrome→削除してchromiumで解消」と書きます。

この1行があるだけで、次に同じ症状が出たとき、確認の順番と方法がわかります。

なぜ「たぶん」で残すと機能しないのか

「たぶんAだった」という記録は、次に読み返しても情報がありません。

「Aかもしれないし、Bかもしれない。確認はしていない」という内容と、ほぼ変わらないからです。

次に同じ症状が出たとき、また1から全部調べ直しになります。

「Aでも、Bでもなく、Cだった」という記録は、1秒 で意味がわかります。

「前回Aは外れた。今回もAから疑うのは非効率」と判断できます。

文字数で言えば後者のほうが少し長いです。

でも、記録を書く5分 は、翌月の40分の調べ直し を防ぎます。

記録の保存場所は何でもかまいません。

iPhoneのメモアプリでも、テキストファイルでも、同じ効果があります。

大事なのは「次に似た症状が出たとき、すぐ開ける場所に置く」ことです。

キーワード検索できるツールなら、症状の単語で引けるのでなお良いです。

実測と記録を長く続けるために

全部を実測しなくていい

全ての問題に対して実測まで確定させるのが正解、とは思っていません。

1回直って、その後2回 以上再発しなかった問題なら、「たぶん」で次に進む判断は正しいです。

確認コストのほうが、調べ直しコストより高くなる場面があります。

わたし自身は「同じ症状が2回 再発したもの」だけ実測で確定させるルールにしています。

判断基準は「次も自分が時間を使う可能性があるか」の1点です。

今回のChrome問題は、前の月に2回再発していたので実測まで踏み込みました。

再発していなければ、そのまま進んでいたと思います。

「確認するかどうか迷う」こと自体もコストです。

「2回再発したら確認する」というルールを先に決めておくと、迷う時間がゼロになります。

記録はシンプルから始めていい

最初から複雑なシステムを作る必要はありません。

iPhoneのメモアプリに「原因：channel設定（リソース・ロックは違った）」と1行書くだけで十分です。

重要なのは「たぶん」という言葉を使わないことです。

「確定した」か「まだ確認していない」かを、1行で区別するだけです。

確認した方法も短く書き添えると、再現性が上がります。

たとえば「メモリ68%・CPU14%で正常を確認（アクティビティモニタ）」「SingletonLock 0件（ターミナルで確認）」のような形です。

この区別があるだけで、記録の使い勝手が大きく変わります。

記録を残すのは5分 です。

取り戻せる時間は、翌月・翌々月の調べ直しを合わせると数時間になります。

自動化で手間がゼロに近づいた

今は、作業のログが自動で記録される環境を使っています。

なにかを潰して確定させたとき、確定した原因と外れた候補が自動でドキュメントに入ります。

翌週に「あれ、なんで直ったんだっけ」と思っても、3秒 で確認できます。

仕組みの核心は、エラーが発生したときにログを構造化して書き出す点です。

「症状・確認した候補と結果・最終的な原因・修正内容」を決まったフォーマットで自動保存しています。

フォーマットを先に決めておかないと、ログが溜まっても検索できません。

逆にフォーマットが決まれば、症状のキーワードで検索するだけで過去の記録が全部引けます。

ログファイルの1エントリは error_type / checked / root_cause / fix という4項目のJSONで管理しています。

シンプルですが、これだけで「あの症状のとき何が外れて何が当たりだったか」を一発で引けます。

この仕組みを使い始めてから、同じ問題に引き戻される回数が体感で大幅に減りました。

2025年の秋 頃から使い始めて、もうすぐ1年になります。

仕組みの全体像が気になる方は、フッターのリンクにまとめています。

「記録を自動化したい」という方に向けて書いています。

今日から1つだけやること

「たぶん」を1件だけ「確定」に変える

記事を読んだあと、1つだけやってみてください。

最近「たぶんこれが原因だった」と閉じた問題を、1件だけ掘り起こします。

候補が2〜3あれば、1つずつ確認して「○○ではなかった」を記録するだけです。

時間は15〜30分 あれば十分です。

「たぶん」を「確認したら違った」に変えるだけで、次の自分に情報が残ります。

一度「外れた候補」の記録が残ると、次に似た症状が出たとき確認の手間が減ります。

この積み重ねが、調べ直しの時間を少しずつ返してくれます。

確定させる相手は、最近のエラーでも昔のトラブルでもかまいません。

「あのときなんで直ったんだろう」と今でも引っかかっているもの。

それが一番いい素材です。

最後に

Chromeが180秒 で止まった夜は、正直かなりつらかったです。

同じエラーを3分ごとに見続けて、なんでこうなったかわからないまま時間が過ぎていく感覚は、なかなかしんどいです。

でも「channel設定だった」という確定の記録が残ったおかげで、次に似た症状が出たとき、3秒 でそこを確認できました。

「リソースじゃない、ロックじゃない、前回はchannelだった」と、記録が語ってくれました。

「たぶん」で止めていた頃の自分に、1つだけ言いたいことがあります。

候補を3つ立てたなら、確定するまで1つずつ潰してから次に進んでください、と。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順