ERROR_CAPTCHA_UNSOLVABLE CapSolver エラーの修正方法

要約

• ERROR_CAPTCHA_UNSOLVABLE は、その試行で CapSolver が CAPTCHA を認識できなかったことを意味します。このコードだけでは、単一の普遍的な原因は特定できません。
• 設定を変える前に、errorCode と errorDescription を確認してください。不正なタスクデータ、アカウントエラー、タイムアウト、サイト側によるトークン拒否は、それぞれ異なる状況です。
• 現在のページで使われているチャレンジの種類とパラメータを、対応する公式タスクリファレンスと照合してください。
• 明確な試行上限の範囲でリトライし、常に「今のチャレンジ」を正しく記述する入力を使ってください。同じ失敗の繰り返しは、無限ループではなく原因調査が必要です。
• タスク内容・タイミング・エラーをマスクした形で記録し、再現可能な問題としてサポートに調査を依頼できるようにしておきましょう。

スクリプトが CAPTCHA タスクを送信し、結果を待ち、ERROR_CAPTCHA_UNSOLVABLE を受け取ることがあります。次の明白な一手は「再試行」ですが、自動リトライは、ページ状態が変わっていたり、リクエストがもはや現在のチャレンジを正しく表していなかったりすると、同じ問題を繰り返すだけになります。

CapSolver は、このエラーを、不正な入力やタスクのタイムアウトとは別に文書化しています。この区別がトラブルシューティングの出発点です。本ガイドでは、このコードが何を示しているのか、どの点を確認すべきか、そして再試行に意味があるかどうかをどう判断するかを説明します。このワークフローは、許可されたテストおよび自動化を対象としています。1つのパラメータを変えればすべての失敗が解決することを約束するものではなく、アクセス制限を「無制限リトライしてよい許可」とみなすものでもありません。

ERROR_CAPTCHA_UNSOLVABLE とは何を意味するか

ERROR_CAPTCHA_UNSOLVABLE は、送信した試行で認識に失敗したことを報告するものであり、「解決済みの答えが送信待ちで存在する」状態ではありません。

公式のエラーコードリファレンス では、このエラーを「CAPTCHA が認識されなかった」と説明しています。同じ項目で、このエラーに対する料金控除はなく、再試行を推奨すると明記されています。ただしこの課金に関する記述は、この特定のコードのみに対するものです。あらゆるブラウザワークフローの失敗や、あらゆる種類の API 失敗に一般化すべきではありません。

原因を決めつける前に、レスポンス全体を読みましょう。API は errorId、errorCode、errorDescription を用いてサービスエラーを表現します。それらの値をタスクのコンテキストと一緒に保存し、「CAPTCHA に失敗した」などの一文に集約しないでください。そうしないと、クライアント側のタイムアウトやパース例外が、あたかもソルバーサービスからのレスポンスと同じように見えてしまいます。

CAPTCHA は、アプリケーションワークフローの1段階に過ぎません。「ソリューションが生成されなかったサービス」と「生成されたソリューションをアプリケーションが拒否した」ケースでは、調査すべき範囲が異なります。これらの段階を分けて考えることで、本来別問題である箇所にリトライポリシーを誤適用することを防げます。

まず、どの段階で試行が止まったかを特定する

失敗が、リクエスト送信中なのか、結果取得中なのか、アプリケーション側の処理中なのかを区別します。

createTask ドキュメント では、結果を同期的に返すタスクと、識別子(ID)を返す非同期タスクの違いを説明しています。非同期タスクでは、作成時に ID を受け取っても、それはまだ「解決成功」を意味しません。既存の ID を使って 結果取得フロー に従い、最終的な結果を確認します。

クライアントがレスポンスを全く受信していない場合は、その事実を記録してください。通信障害に対して、架空のサービスエラーコードをでっちあげてはいけません。同様に、レスポンスにすでに解決済みソリューションが含まれ、その後サイト側で拒否されたのであれば、そのアプリケーションエラーも別個に保持します。後段での拒否は、前段のサービスレスポンスを遡って ERROR_CAPTCHA_UNSOLVABLE に変えるものではありません。

「送信」「タスクID(あれば)」「結果またはエラー」「アプリケーション側の結果(到達した場合)」という短いタイムラインを作りましょう。多くの場合、このタイムラインだけで、ブラウザ録画全体や秘匿情報を含むフルリクエストダンプを出さずとも、サポートが最初に尋ねたい情報を満たせます。

現在のチャレンジとリクエストパラメータを確認する

再試行する前に、そのタスクが、ページ上で現在使われているチャレンジと本当に対応しているかを比較します。

まず CAPTCHA のファミリーとバリアントを確認します。見慣れたウィジェットに似ているというだけでは、タスクタイプを選ぶ根拠として不十分です。ページが想定している CAPTCHA ファミリーを確認し、そのファミリーの最新のタスク仕様を参照してください。他のチュートリアルの文字列を少し変えただけの、新しいタイプ名をでっちあげてはいけません。

reCAPTCHA v2 については、タスクリファレンス に、対象ページ URL・公開 sitekey・サポートされるタスクバリアント・オプションフィールドが記載されています。これらの入力は、同じ「現在のページ」と「そのウィジェット」を表している必要があります。フィールド名が正しくても、無関係なデモから値をコピーしてきた場合は、自分のワークフローに対してはやはり誤った入力です。

意味のあるページ変化のあとで、パラメータを取り直す

ワークフロー中にナビゲーション、チャレンジのリフレッシュ、環境変更、別フォームへの移動などが行われた場合は、入力を再確認します。

保存済み設定が、昨日のデプロイを指していたり、同じページ上の別ウィジェットを表していたりする可能性があります。ブラウザで観察した情報と、ソルバーに送るリクエストを結び付けておきましょう。フォームに複数の検証ステップがある場合、「最初に見つかった sitekey」ではなく、どのステップからパラメータを取得したのかを明確にします。

CapSolver detector の手順 を使うと、ブラウザの開発者ツール経由で CAPTCHA パラメータを確認できます。検出された値をタスクリファレンスと見比べてください。検出機能は証拠を集めるためのものであり、「検出された値を使えば必ず成功する」と保証するものではありません。

オプションフィールドは「必要なときだけ」使う

別のサンプルに含まれているからといって、タスク固有のオプションを漫然と追加してはいけません。現在のページおよびドキュメントがそれらを要求しているときにのみ使います。

オプションフィールドが無いことが、そのまま「認識失敗の原因」と決まるわけではありません。推測で proxy や action などを追加すると、かえって新たな不整合を作りかねません。まずは小さく、ドキュメントに沿ったリクエストをページの実際の状態と照合し、正当な根拠のある設定だけを一つずつ変更してください。

また、アカウントの秘密情報は、ページの公開識別子と分けて扱いましょう。もしレスポンスがアカウントキーや残高の問題を報告しているのであれば、その問題を最優先で解消してください。認識リトライを繰り返しても、不正なアカウント資格情報は修正されません。

CapSolver ボーナスコードを利用しましょう

自動化用の予算を今すぐ増やしましょう！
CapSolver アカウントへチャージする際にボーナスコード CAP26 を利用すると、チャージ金額に対して 5% のボーナス が無制限に付与されます。
今すぐ CapSolver ダッシュボード で引き換えてください。

リトライに意味があるかどうかを判断する

リトライが有効なのは、その操作がまだ許可されており、ページ状態が最新で、次の試行に明確な終了条件が設定されている場合です。

公式ドキュメントの「再試行を推奨」という記述は、「無制限ループ推奨」という意味ではありません。アプリケーションに見合った試行回数の上限と全体的な締切を設定してください。入力を確認したのにもかかわらず同じレスポンスが続くようであれば、自動的にリクエスト数を増やすのではなく、いったん停止して証拠を収集しましょう。

新しいタスクを作成することは、新しい試行を開始することです。既存の非同期タスクの結果を問い合わせることは、その試行の結果を観察することです。リトライループの中でこれらを混同しないでください。最初のタスクがまだ保留中なのに create を繰り返し呼び出すと、元のタスク結果を早く知れるわけではなく、単に試行回数が増えるだけです。

ブラウザテストの場合は、テストランナーのリトライ挙動も確認しましょう。Playwright のリトライドキュメント では、失敗したテストが再実行されること、およびリトライ時だけ成功するテストが「フレーク」(不安定)とみなされることを説明しています。テスト全体のリトライは、ソルバークライアント内部のリトライに加えて、CAPTCHA 解決ステップ自体を再実行する可能性があります。リトライの判断を意図的に行い、二重のレイヤーが見えないところで試行回数を増やさないようにしましょう。

単一の制御された比較を行う

観測された不整合を修正した後は、小さな範囲で許可されたチェックを1回だけ行い、前回と比較します。

変更内容・タスクタイプ・返却された結果・アプリケーションが最後まで完了したかどうかを記録してください。複数の無関係な設定を一度に変えてしまうと、たとえリトライが成功しても、どの変更が効いたのか分かりません。制御された比較は、問題再発時にも使える「再利用可能な証拠」を残してくれます。

終了条件にも意味を持たせてください。完了していないタスクは、その理由とともに「未完了」のまま残しておくべきです。成功した観測であるかのように空のデータオブジェクトを返して隠蔽してしまうと、失敗が見えなくなり、その後のレポートを損なう可能性があります。

統合を変更する前に、似たエラーを区別する

次に何を確認するかは、「正確なエラー種別」に基づいて選びます。

観測された状況	最初に有用な確認項目
ERROR_CAPTCHA_UNSOLVABLE	現在のチャレンジとリクエストを見直し、上限付きリトライを検討
ERROR_INVALID_TASK_DATA	説明文を読み、指摘された入力を修正
ERROR_TASK_NOT_SUPPORTED	ドキュメント上のタスクタイプと対応チャレンジを確認
ERROR_TASKID_INVALID	結果取得に使っている ID を確認
ERROR_TASK_TIMEOUT	タスク結果と、アプリケーションの待機ポリシーを確認
ソリューションは準備済みだが、サイト側で拒否された	トークンの扱いと、アプリケーション側の検証結果を確認

これらは「調査の道筋」であり、「このチェックだけで必ず原因が分かる」という保証ではありません。ケースをエスカレーションする場合は、元のエラーテキストを残してください。広いラベルに置き換えてしまうと、サポートチームが必要とする情報が失われます。

自前のサイトであれば、ブラウザからの送信と、サーバ側の検証レスポンスを比較しましょう。Google の reCAPTCHA 検証ドキュメント は、検証はサーバ側で行うべきであり、レスポンストークンには有効期限があり一度しか使えないことを明示しています。遅すぎるタイミングで使われたトークンや、検証後に再利用されたトークンは、「ソルバーがトークンを生成しなかった」場合とは別の問題です。

ブラウザ側の観察には、Chrome の Network パネルガイド が役立ちます。許可されたページ上で、該当するリクエストとレスポンスを調べてください。必要な情報が、マスクしたリクエスト概要だけで足りるのであれば、認証済みセッション全体をエクスポートするのは避けましょう。

サポートには何を送るべきか

失敗した段階が特定できる、簡潔でマスク済みの記録を送ってください。

含めるべき情報は、タスクタイプ・(あれば)タスクID・おおよそのリクエスト時刻とタイムゾーン・正確なエラーコードと説明・再現性の有無です。失敗前に発生したページや設定の変更も記載します。また、すでにリクエストを最新のタスクドキュメントと照合済みかどうかも明示してください。

CapSolver の API キー・完全なセッションクッキー・完全な解決済みトークン・関連のない個人情報などを、公開のイシューに貼り付けてはいけません。OWASP のロギングガイド は、認証情報やセッション情報を除外または保護すべき理由を説明しています。診断に特に必要とされる追加情報がある場合は、適切なサポートチャネルを使って提出してください。

パラメータ特定のウォークスルー は、「ページがどの入力を使っているのか」が未解決のときに役立ちます。すでに入力が一致しているのに同じエラーが続く場合は、「原因を仮定した説明」ではなく、「入力は一致している」という事実を添えて報告しましょう。

エラーは発生した段階で解決する

ERROR_CAPTCHA_UNSOLVABLE に対して実務的に取るべき対応は、「どの段階で失敗したかを特定し、現在の入力を検証し、上限付きリトライ方針を決め、それでも続く場合は有用な証拠を残す」ことです。

CapSolver のタスクレスポンスと、アプリケーション側の結果とを組み合わせて扱ってください。そうすることで、「解決に失敗したケース」と「後段の統合問題」とを明確に区別できます。

CapSolver で信頼性の高い自動化ワークフローを構築する

まずは 1 種類のサポート対象チャレンジと、1 つの最新リクエストから始め、許可されたワークフローが期待どおり動作することを確認したうえで、徐々に拡張していきましょう。

FAQ

Q: ERROR_CAPTCHA_UNSOLVABLE は、常に sitekey が間違っていることを意味しますか？

いいえ。このエラーは「認識が成功しなかった」ことを示します。入力は確認すべきですが、このコードだけを根拠に、特定のパラメータ不整合の「証拠」とみなしてはいけません。

Q: このエラーは課金されますか？

現在の公式エラーテーブルでは、ERROR_CAPTCHA_UNSOLVABLE に対する控除はないと記載されています。この記述は、この特定のエラーにのみ適用されます。各タスクの課金に関する疑問は、アカウント記録とサポートを利用して確認してください。

Q: 終端エラーが返された後もポーリングを続けるべきですか？

結果待ちとみなすのではなく、報告されたエラーを処理してください。新しい解決試行と、既存タスク結果の取得は別の操作です。

Q: 解決済みソリューションが返ってきたのに、フォーム送信が失敗するのはなぜですか？

解決済みソリューションがあっても、アプリケーション側での受け入れが保証されるわけではありません。あなたが制御している範囲で、ページ状態・結果の扱い・サーバ側検証レスポンスを確認してください。

Q: 同じエラーが繰り返し発生するとき、最初にすべきことは何ですか？

正確なエラー内容を確認し、現在のページ入力をタスクリファレンスと比較し、マスク済みのタスク記録を保持してください。正当な修正や新しい有用な観察結果が得られない状態で、試行を繰り返すのはやめましょう。