Claude in Chrome が思い通りに動かないときのトラブルシューティング

ログイン・認証の画面で止まる

ログインフォームへの入力まではうまくいったのに、認証後に次のページへ進めない、あるいはセッションが切れてしまう問題です。

主な原因:

• 2段階認証（2FA）の要求（Claude in Chromeでは自動処理できません）
• SSO（シングルサインオン）のリダイレクト先で止まる
• Cookieやセッションの期限切れ

対処法:

2段階認証が設定されているサービスへのログインは、現時点でClaudeが自動処理できません。あらかじめブラウザ側でログイン済みの状態にしてからClaude in Chromeのタスクを開始するのが確実です。

セッション切れの問題は、タスクの実行間隔が長い場合に起きやすいです。タスク冒頭に「まず[サービス名]にログインしているか確認して、セッションが切れていたら再ログインして」という確認ステップを加えると対応できます。

CAPTCHAで止まってしまう

Claude in ChromeはCAPTCHAを自動解除することができません。これは現在の仕様です。

現実的な対処法:

対象サービスでIPアドレスやCookieに基づくCAPTCHAスキップが有効な場合は、一度ブラウザから手動ログインしておくと、以降のCAPTCHA表示が省略されることがあります。Google系サービスでは、アカウントにあらかじめログインしておくと、CAPTCHA表示頻度が大幅に下がります。

どうしてもCAPTCHAを回避できないサービスは、Claude in Chromeによる完全自動化の対象外と考えて、手動とClaudeの組み合わせで運用するのが現実的です。

PDFや動的コンテンツが読み取れない

ウェブ上のPDFをClaudeに読ませようとしたり、JavaScriptで動的に生成されるグラフや表を取得しようとしたりした場合に失敗するケースです。

PDFの読み取りについて:

ブラウザ内蔵のPDFビューアで表示されるPDFは、ClaudeがDOMからテキストを取得しにくい構造になっています。代替策として、PDFのURLをClaudeに確認してもらい、そのURLを直接Claude.aiのチャットにアップロードする方法が確実です。

動的コンテンツについて:

APIで非同期取得されるデータは、ページのHTMLには記述されていないため読み取れないことがあります。「ページのソースではなく、現在画面に表示されているテキストだけを読んで」と明示的に指示すると改善することがあります。また「スクリーンショットを撮って内容を教えて」と視覚情報をもとにした処理を依頼する方法も有効です。

実行が途中で止まる・エラーで終了する

複数ステップのタスクを実行させていると、中途半端なところで処理が停止してしまうことがあります。

コンテキスト超過の場合:

長時間・多ステップのタスクは、コンテキストウィンドウを使い切ってしまうことがあります。タスクを小さな単位に分割して、それぞれを独立したセッションで実行しましょう。「1〜10番のURLを処理して」「11〜20番のURLを処理して」のように明示的に範囲を区切ると安定します。

ネットワークエラーやタイムアウトの場合:

ページの読み込みが重い場合に発生しやすいです。「タイムアウトになった場合は10秒待ってからリトライして」と指示に加えると、Claudeが自動でリトライを試みます。

処理が止まったときは、まず自分で手動でそのページを開いてみましょう。対象サービスがメンテナンス中や障害中であれば、Claude in Chromeではなくサービス側が原因です。

タスクは完了したのに結果が期待と違う

Claudeが「完了しました」と報告しているが、実際の処理が期待と違う状態になっているケースです。

代表例:

• フォームへの入力は終わっているが「保存」ボタンを押さずに終わっている
• 検索結果の1ページ目しか処理していない
• 条件に合わないアイテムも一緒に処理してしまっている

対処法:

タスクの指示に「処理後に必ず確認ステップを入れて」と付け加えると、Claudeが自己チェックを行うようになります。「○件処理したら、処理件数と対象の名前を一覧で報告して」のように検証しやすいアウトプット形式を指定するのも効果的です。

複数ページにわたる処理は「次のページがある場合はページネーションボタンを押して続けて、なければ終了して」のように終了条件を明確にしておく点が肝心です。

なお、この「完了と報告されたのに実際は何も起きていない」という失敗は、Web監視の自動化でも同じ形で現れます。監視が「異常なし」と言い続ける状態の切り分けについては、Web 監視が『異常なし』と言い続けた二週間 に記録しております。

MCPサーバーとの連携でエラーが出る

Claude in ChromeをCoworkのMCPサーバーと組み合わせて使っている場合、接続エラーが発生することがあります。

Coworkの設定画面でMCPサーバーの接続状態を確認しましょう。サーバーが「Disconnected」になっている場合は、Coworkアプリを再起動するとほとんどのケースで復旧します。

それでも解決しない場合は、MCPサーバーのログを確認します。多くのMCPサーバーはエラーをstderrに出力しているため、ターミナルから起動して直接メッセージを確認できます。ポート番号の競合や環境変数の未設定が原因であることが多いです。

切り分けの手順 — 5ステップで原因を特定する

指示文をやみくもに書き直すより、どの層で止まっているかを先に確定させたほうが早く終わります。私は次の順番で確認しております。

1. 同じ操作を自分の手で行う。 ページが開くか、ボタンが押せるか、ログインが通るか。ここで失敗するならサービス側の問題であり、プロンプトを直しても解決しません。
2. タスクを1ステップだけに削る。 「ログインして、レポート画面へ行って、CSVを落として」を「レポート画面を開いて、見出しを読み上げて」だけにします。どのステップで壊れるかがこれで確定します。
3. 失敗した1ステップの前に待機を挟む。 「操作の前に5秒待って」を加えるだけで直るなら、原因はタイミングです。直らないならDOM構造か権限です。
4. 視覚経路に切り替える。 「スクリーンショットを撮って、見えているボタンのラベルを列挙して」と指示します。Claudeが認識できていない要素がここで判明します。
5. 検証ステップを恒久化する。 直った指示文に「操作後、成功メッセージが見えることを確認して。見えなければ報告して停止して」を必ず添えます。

3〜4を飛ばして指示文全体を書き直す誘惑が強いのですが、原因が確定していない書き直しは、たいてい別の失敗を呼び込むだけでした。

公式ドキュメントには書かれていない、運用で気づいた点

3週間、のべ42回の実行ログを見返して分かったことを共有いたします。対象は AdMob 管理画面からの週次レポート取得と、App Store Connect の売上画面の読み取りです。

待機は「3秒」では足りない画面がある。 一般的なページなら3秒で足りますが、AdMob の管理画面のようにグラフを非同期で描画するSPAでは、3秒では表が空のまま読まれてしまいました。6秒に延ばしたところ、空読みは12回中0回になりました。「完全に読み込まれるまで待って」という自然文だけでは、Claudeが判断する「完全」とレンダリング完了が一致しません。秒数を明示するほうが安定します。

「検証ステップ」の効果が最も大きい。 待機指示なし・検証なしの初期プロンプトでは、42回中26回（約62%）しか最後まで到達しませんでした。ここに「秒数指定の待機」と「操作後に成功条件を目視確認して、満たさなければ停止して報告する」の2つを加えた結果、完走は40回（約95%）まで変わりました。平均実行時間は1分48秒から2分21秒へ33秒ほど延びましたが、失敗して手作業でやり直す数分に比べれば、はるかに安い代償です。

失敗した2回は、いずれも「静かな失敗」ではありませんでした。 検証ステップを入れて以降、失敗するときは必ず「成功メッセージが確認できませんでした」と報告して停止します。黙って誤った結果を返すことがなくなった点が、数字以上に大きい変化でした。

同じサイトでも時間帯で挙動が変わります。 管理画面の初回描画は、午前中の混雑時に体感で2倍近く遅くなりました。スケジュール実行に載せる場合は、余裕を持った待機秒数を既定にしておくほうが安全です。

広告管理画面のように「数字が動く」画面では、読み取り結果を必ず前回値と突き合わせます。 メディエーションの優先度調整を任せたときの試行錯誤は、AdMob メディエーションの優先度調整を Claude in Chrome に任せた 3 週間 にまとめております。

MCPサーバーを起動前に検証する

「Disconnected」に気づかないままタスクを走らせて、10分後に空の結果を受け取る。これを何度か繰り返した末に、起動前チェックを1本のスクリプトにまとめました。ポート競合・環境変数欠落・疎通の3点を、タスク開始前に確定させるためのものです。

// preflight.mjs — Claude in Chrome のタスクを流す前に MCP サーバー側を検証する
// 実行: node preflight.mjs
import net from 'node:net';
 
const CHECKS = [
  { name: 'my-mcp-server', host: '127.0.0.1', port: 3333, env: ['MCP_API_KEY'] },
  { name: 'sheets-mcp', host: '127.0.0.1', port: 3334, env: ['GOOGLE_CREDENTIALS_PATH'] },
];
 
function probe(host, port, timeoutMs = 1500) {
  return new Promise((resolve) => {
    const socket = net.connect({ host, port });
    const done = (reachable) => {
      socket.destroy();
      resolve(reachable);
    };
    socket.setTimeout(timeoutMs);
    socket.once('connect', () => done(true));
    socket.once('timeout', () => done(false));
    socket.once('error', () => done(false));
  });
}
 
const failures = [];
 
for (const check of CHECKS) {
  const missing = check.env.filter((key) => !process.env[key]);
  const reachable = await probe(check.host, check.port);
 
  if (missing.length > 0) {
    failures.push(`${check.name}: 環境変数が未設定です (${missing.join(', ')})`);
  }
  if (!reachable) {
    failures.push(`${check.name}: ${check.host}:${check.port} に接続できません`);
  }
  if (missing.length === 0 && reachable) {
    console.log(`OK  ${check.name} (${check.host}:${check.port})`);
  }
}
 
if (failures.length > 0) {
  console.error('\n起動前チェックに失敗しました:');
  for (const line of failures) console.error(`  - ${line}`);
  process.exit(1);
}
 
console.log('\nすべてのチェックを通過しました。タスクを開始できます。');

ポイントは process.exit(1) で明示的に落とすところにあります。チェックが警告を出すだけでは、結局それを読み飛ばしてタスクを走らせてしまいます。落ちる仕組みにしておくと、気づかないまま進むことがなくなります。

疎通に失敗した場合は、そのポートを誰が握っているかを確認します。

# macOS / Linux — 3333番ポートを使っているプロセスを特定する
lsof -nP -iTCP:3333 -sTCP:LISTEN
 
# 前回のプロセスが残っている場合のみ終了させる
kill "$(lsof -t -nP -iTCP:3333 -sTCP:LISTEN)"

私の場合、原因の大半は「前回のMCPサーバープロセスが終了しきっていない」でした。Coworkアプリの再起動で直る、と説明されるケースの実体はこれであることが多いです。Stripe の Webhook をブラウザ側から追いかけたときの手順は Claude in Chrome で Stripe Webhook の HTTP 500 エラーを解決した実践レポート に書いております。

症状別・どの対処から試すか

限られた時間で当たりを引くために、症状ごとの優先順位を表にしました。上から順に試すと、私の環境では平均2手以内で切り分けが終わっております。

判断に迷ったときは、いちばん左の列に戻ります。「症状を一言で言えるか」が曖昧なまま対処を始めると、たいてい遠回りになりました。

Claude in Chrome は自動化の道具ですが、実際に効くのは自動化そのものではなく、失敗したときに「どこで止まったか」を機械が教えてくれる状態をつくることでした。待機秒数と検証ステップ。この2つを加えるだけで、私の週次レポート取得は「毎回見張るもの」から「失敗したときだけ手を出すもの」に変わりました。

次に手を動かすなら、今いちばん失敗しているタスクをひとつ選び、その最後の操作の直後に「成功条件を目視確認して、満たさなければ停止して報告して」の一文を足すところから始めてみてください。効果がもっとも大きく、書き足すのは一行です。

より基本的な使い方から確認したい場合は、Claude in Chrome と Cowork の基本ガイド が出発点になるかと思います。

私自身まだ試行錯誤の途中ですが、同じところでつまずいている方の時間が少しでも減れば嬉しく思います。お読みいただきありがとうございました。