CAPSOLVER
ブログ
CAPTCHA画像認識 vs トークン解決:どちらを選ぶか

CAPTCHA画像認識 vs トークン解決:どのように選ぶか

Logo of CapSolver

Sora Fujimoto

How to use CapSolver

22-Oct-2026

まとめ

  • CAPTCHA画像認識は画像を読み取る/分類する処理であり、トークンソルブは対応するCAPTCHA連携向けのレスポンス値を返す処理です。
  • 「画像が出るかどうか」ではなく、「あなたのアプリケーションが次に何を必要としているか」に基づいてAPIを選択してください。
  • CapSolver の ImageToTextTask は画像データを受け取り、認識したテキストを直接返します。一方、reCAPTCHAトークンタスクはウェブサイトのパラメータを使い、まったく異なる結果仕様になります。
  • 画像分類の出力は reCAPTCHA のレスポンストークンではありません。周辺のチャレンジワークフローも依然として重要です。
  • どの方式を選ぶ場合でも、ソルバーが成功を返したかどうかと、アプリケーション側のリクエストが成功したかどうかは別々に確認する必要があります。

CAPTCHA画像認識とトークンソルブのどちらを選ぶかは、実務的な問いから始まります。「この後、アプリケーションは何を期待しているのか?」という点です。テキストフィールドなら画像に表示された文字が必要かもしれません。reCAPTCHA 連携であればレスポンストークンを期待します。前者の結果を後者のインターフェイスに送っても、「どちらもCAPTCHAを解く」と表現されていても動作しません。

CapSolver は、認識タスクとトークンタスクを別々にドキュメント化しています。本ガイドでは、それぞれの入力・出力・連携時の責任範囲を比較し、認可されたテストや自動化で適切な出発点を選べるよう解説します。特定のプロバイダを順位付けするものでも、あらゆるCAPTCHAが同一のリクエストで処理できると仮定するものでもありません。

画像認識とトークンソルブの違いは?

画像認識は画像の内容に関する答えを出し、トークンソルブは対応する認証システム向けのレスポンス値を出します。

これはAPIレベルでの区別です。サービスがどのような内部モデルを使っているか、ブラウザが内部的に関与しているかどうかを決めるものではありません。連携作業において有用なのは、「どんな情報を送信し」「どんな結果を受け取るか」という点です。

CAPTCHA には複数の見た目があります。歪んだ文字を読ませるもの、画像選択式のチャレンジ、さらには画像パズルがないものもあります。画像が表示されているという事実だけでは、アプリケーションが「完了」と見なす入力形式は判断できません。

判断ポイント 画像認識 トークンソルブ
典型的な入力 テキストとしてエンコードされた画像バイト列+タスク固有の指示 WebサイトのURL、サイトキー、タスク固有のパラメータ
典型的な出力 認識された文字列または分類結果 CAPTCHAレスポンストークン
呼び出し側が用意すべきもの 現在のチャレンジに対応する正しい画像 正しいCAPTCHA種別と、現在ページのパラメータ
その後に残る作業 想定されたアプリケーションの手順で回答を利用し、受理を確認する 想定された連携方法でトークンを送信し、受理を確認する
よくあるミスマッチ 分類出力を認証トークンとして扱ってしまう トークンを画像文字入力欄へ送ってしまう

ここでの比較はよくあるタスク契約を説明したものであり、普遍的なスキーマではありません。共通の結果パーサーを実装する前に、必ず該当タスクのドキュメントを確認してください。

いつ画像CAPTCHA認識を選ぶべきか?

ワークフローが「手元に画像があり、その内容について定義された答えが必要」という状況なら、画像認識を選択します。

たとえば、テキストCAPTCHAを備えたアプリケーションの認可されたテストでは、すでに表示中のCAPTCHA画像へアクセスできているかもしれません。次のステップでは、その文字列が必要です。OCRタスクはそのテキストを提供できますが、実際に文字を入力し結果を確認する責任はテスト側に残ります。

テキスト認識にはサイトキーではなく画像データが必要

公式の ImageToText タスクリファレンス では、画像のBase64エンコードされた内容を格納した body が必須とされています。WebサイトURLはこのタスクではオプションです。サイトキーだけを渡しても画像がなければ、入力要件を満たしません。

Base64 はバイナリデータをテキスト文字で表現する方法であり、画像を高品質化する処理ではありません。トリミングが雑なCAPTCHAや古いCAPTCHA画像は、エンコードしたところで不適切なもののままです。

ImageToTextTask では、改行や data:image/...;base64, のプレフィックスを除いた画像コンテンツを、タスクリファレンス通りに使用してください。送信する画像には、ページ上の無関係なコンテンツや個人情報を含めないようにします。

以下のリクエストボディは、画像用のプレースホルダを明示した公式スキーマに沿う例です。これはスキーマ例であり、実際のソルブを行っているわけではありません。POST https://api.capsolver.com/createTask で使用する前に、キーと画像の値を置き換えてください。

json Copy
{
  "clientKey": "YOUR_API_KEY",
  "task": {
    "type": "ImageToTextTask",
    "body": "BASE64_IMAGE_CONTENT"
  }
}

このタスクは認識結果を直接返します。solution.text を読む前にエラーフィールドを確認してください。ほかのCAPTCHAタスクでポーリングが必要だからといって、同じようにループを追加する必要はありません。

画像分類は別の結果を返す

画像分類は文字の書き起こしではなく、画像に関する質問への回答を返します。CapSolver では、reCAPTCHA 画像分類 を、画像と質問を引数に取る別タスクとしてドキュメント化しています。

分類レスポンスは「完了した reCAPTCHA 認証」ではありません。認識インターフェイスを選ぶ場合、アプリケーション側には依然として互換性のあるチャレンジワークフローが必要です。選択された画像領域のリストを、そのままアプリケーションが期待するレスポンストークンとして挿入できるとは思わないでください。

初めての連携では、タスク名を選ぶ前に、まず期待される出力を明確に書き出しましょう。「文字を読み取る」と「reCAPTCHAのレスポンスを取得する」は別の要件であり、両方がサポートチケットのスクリーンショットから始まる場合でも同じではありません。

いつCAPTCHAトークンソルバーを選ぶべきか?

アプリケーションがサポートされているCAPTCHA連携を使っており、必要とされる出力がそのレスポンストークンである場合、トークンソルブを選びます。

reCAPTCHA v2 タスクリファレンス には、websiteURL や websiteKey などのWebサイトパラメータが記載されています。これらはページやCAPTCHA連携を特定するものであり、互いの代用にはなりません。また、公開サイトキーは CapSolver の APIキーではありません。

以下の2つ目のスキーマ例は、reCAPTCHA v2 プロキシレス・タスクの基本形を示しています。これは実行されたリクエストではなく、特定の連携に必要となりうるすべてのオプションパラメータを含むものでもありません。

json Copy
{
  "clientKey": "YOUR_API_KEY",
  "task": {
    "type": "ReCaptchaV2TaskProxyLess",
    "websiteURL": "https://www.yourwebsite.com",
    "websiteKey": "YOUR_RECAPTCHA_SITE_KEY"
  }
}

許可されたページの実際の値を使い、そのCAPTCHAバージョンに対してドキュメント化されているタスクタイプを選択してください。v2、v3、Enterprise を、無関係なタスク名で試行錯誤して選ぶべきではありません。

非同期な createTask フローでは、返ってきたタスクIDを保存し、そのタスクの結果を getTaskResult で取得します。選択したタスク向けにドキュメント化されている solution フィールドを参照し、すべての成功レスポンスが同じフィールドを持つという前提で1つのパーサーを書かないでください。

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

自動化の予算をすぐに増やしましょう!
チャージ時にボーナスコード CAP26 を使うと、毎回の入金額に対して 5% 追加ボーナス が無制限で付与されます。
今すぐ CapSolver ダッシュボード で利用できます。
CapSolver recharge offer showing bonus code CAP26 and a 5% bonus

ソルバーが応答した後、それぞれのワークフローには何が必要か?

どちらのワークフローでも、ソルバーが結果を返した後に、アプリケーションレベルでのチェックが必要です。

テキストCAPTCHAでは、「同じチャレンジに対して」想定フォームが文字列を受け入れたかどうかを確認することになるでしょう。リクエストの実行中に画像が更新されていれば、前の画像に対する回答は、現在のフォームにはもはや正しい結果ではありません。

トークン連携では、「空でない文字列」であることだけでは、アプリケーションがリクエストを受理したことを示しません。Google の reCAPTCHA 検証ドキュメントには、ウェブサイト側のサーバーが行うトークン検証ステップが記載されています。サイトのプライベートな検証シークレットはそのサーバーに属すべきものであり、ソルバーの利用者が他人のシークレットを取得する必要はありません。

Cloudflare も同様に、Turnstile レスポンスのサーバーサイド検証を要求しています。こうしたプロバイダ側のチェックは、「タスクが準備完了」とソルバーが報告することとは別物です。自分で運用しているアプリケーションなら、その検証結果を確認してください。許可された他ワークフローをテストしている場合は、非公開なバックエンドに干渉することなく、ドキュメント化されている成功条件を確認してください。

この区別はデバッグにも役立ちます。失敗が、画像取得なのか、タスク作成なのか、結果取得なのか、結果の送達なのか、アプリケーションでの受理なのかを区別して記録しましょう。最終的なエラー画面のスクリーンショットだけでは、どのステップが問題なのか特定できないことがあります。

返される値についてさらに詳しく知りたい場合は、CAPTCHAトークンとクッキー の説明を参照してください。OCRの回答もレスポンストークンも、それ自体では永続的なブラウザセッションを保証しません。

実際の自動化タスクではどう選べばよいか?

既存のワークフローが消費できる結果を、もっとも小さなインターフェイスで提供してくれる方式を選択します。

アプリケーションが画像からの文字を期待している場合

チャレンジがテキスト画像であり、現在の画像を正当に取得できるならテキスト認識タスクを使用します。画像の取得、エンコード、返却テキスト、フォームのレスポンスを別々のステップとして確認してください。これはOCRにとっての直接的な適合パターンであり、ウェブサイト用のトークンタスクを追加しても、入力欄が期待する要件の解決にはなりません。

アプリケーションが reCAPTCHA または Turnstile のレスポンスを期待している場合

ドキュメント化されたパラメータと、正当な連携経路がある場合は、対応するトークンタスクを使用します。画像パズルが存在するからといって、別個の画像分類ワークフローを維持する必要があるとは限りません。CAPTCHA製品とレスポンス契約から検討を始めてください。

ブラウザエージェントがチャレンジを検知したが、連携コンテキストがない場合

ソルバーアクションを要求する前に、エージェントに「どのチャレンジがサポート対象か」「どんな連携コンテキストが利用可能か」を特定させてください。スクリーンショットだけでは、適切な画像入力・サイトキー・コールバック・結果の送達手段が揃っているとは限りません。情報が不足しているときは、モデルに値を「創作」させるのではなく、そこで止まるべきです。

確立されたブラウザワークフローに対しては、ドキュメント化されたブラウザインテグレーションが、やり取りの一部を肩代わりすることもあります。本ガイドでの比較は、実際に利用するクライアントやブラウザで行う統合テストの代わりにはなりません。

どんな点を比較してから方式を決めるべきか?

個々のタスクの表面的な価格を比較する前に、「互換性」「実装工数」「アプリケーションで確認された成果」を比較しましょう。

まず互換性が最優先です。フォーマットがアプリケーションに合っていなければ、低コストのレスポンスも意味がありません。次にチームが維持しなければならない作業、たとえば画像取得、チャレンジ状態の管理、結果取得、最終的な受理チェックなどを考慮します。HTTP APIを使う点は同じでも、ワークフローごとにこうした責任範囲は異なります。

実際に必要なCAPTCHAタイプを反映した、小規模かつ認可されたサンプルで評価してください。失敗を理解できる程度に、入力元の条件は一定に保ちましょう。タスクエラーとアプリケーション側の拒否を分けて記録し、プロバイダ側の「ready」ステータスを、そのままあなたのエンドツーエンド成功率とみなさないようにします。

速度・認識精度・コスト優位性を、この「分類」の違いだけから推測しないでください。これらは特定のタスクと連携に対する測定結果であり、「image」や「token」という言葉そのものから自動的に導かれるものではありません。

期待される答えを中心にワークフローを組み立てる

期待される答えが、「画像文字」「分類結果」「検証用レスポンストークン」のどれかを明確にすることが、最初の出発点としてもっとも有効です。

その答えを現在のタスクドキュメントと照合し、対応する入力を提供し、アプリケーションが完了をどのように確認するかを定義してください。CapSolver はこれらのニーズに対して個別のインターフェイスを提供しており、意図的に選択することで入出力のミスマッチを減らせます。

CapSolver で信頼できる自動化ワークフローを構築する

サポートされているCAPTCHAタイプと認可されたワークフローで、CapSolver を試して みてください。まずは、1つのタスク契約を確実に理解・実装してから、連携範囲を広げていきましょう。

FAQ

Q: CAPTCHA画像認識とトークンソルブは同じものですか?

いいえ。画像認識はテキストや分類結果など、画像についての情報を返します。トークンソルブは、サポートされているCAPTCHA連携向けのレスポンスを返します。アプリケーションが次に何を期待しているかに基づいてインターフェイスを選んでください。

Q: OCR結果を reCAPTCHA トークンとして使えますか?

いいえ。認識された文字列は reCAPTCHA のレスポンストークンではありません。入力形式も検証契約も異なる別物です。

Q: すべてのCAPTCHAタスクでポーリングは必要ですか?

いいえ。CapSolver では ImageToTextTask は直接結果を返す一方、非同期トークンタスクはタスクIDと結果取得の手順を使います。選択したタスクごとのドキュメントに従い、すべてのレスポンスに一律のループを適用しないでください。

Q: AIエージェントにはどちらの方式が向いていますか?

チャレンジ内容とエージェントの実際の連携方法に合致する方式が適切です。画像をキャプチャできるエージェントが、自動的にトークンベースのワークフローも完了できるとは限りません。必要な入力と結果の送達ステップを検証してください。

Q: ソルバーのレスポンスが成功なら、アプリケーションも成功したと見なせますか?

いいえ。アプリケーションが回答やトークンを受け入れ、想定された処理を完了したことを別途確認する必要があります。その結果を個別にチェックし、自動化は自分に許可されたアクセス範囲内にとどめてください。

コンプライアンス免責事項: このブログで提供される情報は、情報提供のみを目的としています。CapSolverは、すべての適用される法律および規制の遵守に努めています。CapSolverネットワークの不法、詐欺、または悪用の目的での使用は厳格に禁止され、調査されます。私たちのキャプチャ解決ソリューションは、公共データのクローリング中にキャプチャの問題を解決する際に100%のコンプライアンスを確保しながら、ユーザーエクスペリエンスを向上させます。私たちは、サービスの責任ある使用を奨励します。詳細については、サービス利用規約およびプライバシーポリシーをご覧ください。

もっと見る

No data