
Sora Fujimoto
AI Solutions Architect

AIエージェントがWebをあなたの代わりに閲覧するとき、CAPTCHAは最大の障壁です。保護されたページはエージェントをブロックし、フォームは提出を拒否し、タスクは人間の介入を待って停止します。
Hermes AgentはNous Researchによって開発された自己改善型AIエージェントで、$5のVPSからGPUクラスターまでどこでも動作し、Telegram、Discord、Slack、WhatsApp、Signal、メールなど、すでに使用しているすべてのチャネルでアクセスできます。また、ブラウザを操作してページをナビゲートし、ボタンをクリックし、フォームを埋め、データを抽出することもできます。しかし、他のブラウザ駆動エージェントと同じように、CAPTCHAで詰まってしまいます。
CapSolverはこれを完全に変えるものです。Hermesが接続するChrome拡張機能にCapSolverをロードすることで、CAPTCHAは自動的かつ見えない形でバックグラウンドで解決されます。コードは必要ありません。あなたの側からのAPI呼び出しも不要です。プロンプトエンジニアリングのテクニックも不要です。
最高の点は、エージェントにCAPTCHAについて言及する必要がないということです。ただ、提出する前に少し待つように指示するだけで、エージェントが「Submit」をクリックする頃にはすでにCAPTCHAは解決されています。
Hermes Agentは、Nous Researchによって開発されたオープンソースの自律型AIエージェントです。3つの原則に基づいて設計されています:永続的なメモリ(セッション間であなたやプロジェクトを記憶)、自律的なスキル作成(経験からプロセスを学び、次回に再実行)、インフラの柔軟性(小さなVPS、Dockerコンテナ、サーバーレスサンドボックス、または独自のGPUボックスで動作)。

hermes modelで切り替え可能Hermesは実際のChromiumブラウザを駆動して本格的な作業を行うことができます — ナビゲート、DOMを読み取り、クリック、タイプ、スクリーンショット、スクレイピング。そのブラウザツール層の特徴は、特定の点で異なります。つまり、単一のバックエンドに強制するのではなく、5つの交換可能なブラウザプロバイダーをサポートしています。
| プロバイダー | タイプ | 拡張機能? |
|---|---|---|
| Browserbase | クラウド | ✗ |
| Browser Use | クラウド | ✗ |
| Firecrawl | クラウド | ✗ |
| Camoufox | ローカル(Firefoxステルス) | ✗ |
| CDPアタッチ | ローカル(任意のChromium) | ✓ |
クラウドプロバイダーは拡張機能をロードできません — リモートブラウザを制御できません。CamoufoxはFirefoxベースで、Chrome MV3拡張機能を実行できません。クリーンな統合ポイントは5番目である:CDPアタッチ、Hermesが別途起動したChromiumに接続するものです。ここにCapSolverが適合します。
これは、OpenClaw(独自のChromiumを起動し、browser.extensions配列を受け入れる)やCrawlee(Playwright起動フラグを制御)などのツールとは異なるモデルです。Hermesでは、拡張機能を事前にロードしたChromeを自前で用意し、DevToolsプロトコル経由で接続します。
CapSolverは、現代のCAPTCHAチャレンジを回避するためのAI駆動のソリューションを提供するリーディングなCAPTCHA解決サービスです。すべての主要なCAPTCHAタイプをサポートし、高速な応答時間を提供し、自動ワークフローにシームレスに統合されます — 无论是ブラウザをPlaywright経由で駆動する場合、APIを直接呼び出す場合、またはこのガイドで説明するように、エージェントのブラウザセッション内でChrome拡張機能を実行する場合でも。
ほとんどのCAPTCHA解決の統合では、コードを書く必要があります — API呼び出しを作成し、結果をポーリングし、隠しフォームフィールドにトークンをインジェクトします。これは、Crawlee、Puppeteer、またはPlaywrightなどのツールで行われます。
Hermes + CapSolverは根本的に異なります:
| 伝統的(コードベース) | Hermes(自然言語) |
|---|---|
CapSolverServiceクラスを書く |
--load-extension=...でChromeを一度起動 |
createTask() / getTaskResult()を呼び出す |
エージェントに話しかけるだけで良い |
page.$eval()でトークンをインジェクト |
拡張機能がすべてを処理 |
| コードでエラー、リトライ、タイムアウトを処理 | 「60秒待ってから送信してください」と指示する |
| 各CAPTCHAタイプごとに異なるコード | すべてのタイプを自動的にサポート |
重要な洞察:CapSolver Chrome拡張機能はアタッチされたブラウザ内で動作します。HermesはCDP経由でそのブラウザに接続し、通常通り操作します。エージェントがCAPTCHAのあるページに移動すると、拡張機能 — 同じChrome内で完全にエージェントに見えない状態で — ウィジェットを検出し、CapSolver APIを呼び出し、ページに解決トークンをインジェクトします。エージェントが「Submit」をクリックする頃には、フォームにはすでに有効なトークンが含まれています。
ただ時間が必要です。 エージェントに「CAPTCHAを解決してください」と指示する代わりに、ただ次のように言います:
「そのページに移動し、60秒待ってからSubmitをクリックしてください。」
それだけです。エージェントはCapSolverが存在することを知らなくても構いません。
統合をセットアップする前に、以下の点を確認してください:
Google Chrome 137+(2025年中盤にリリース)は、ブランド付きビルドで
--load-extensionのサポートを静かに削除しました。 これにより、標準的なGoogle Chromeを使用して自動セッションでChrome拡張機能をロードすることはできません。エラーは表示されません — フラグは単に無視されます。
これはGoogle ChromeとMicrosoft Edgeに影響します。必須です: 以下の代替手段を使用してください:
| ブラウザ | 拡張機能のロード | 推奨? |
|---|---|---|
| Google Chrome 137+ | サポートされていません | いいえ |
| Microsoft Edge | サポートされていません | いいえ |
| Chrome for Testing | サポートされています | はい |
| Chromium(スタンドアロン) | サポートされています | はい |
| Playwrightのバンドル済みChromium | サポートされています | はい |
Chrome for Testingのインストール方法:
# オプション1:Playwright経由(推奨 — Hermesは内部でPlaywrightを使用しています)
npx playwright install chromium
# バイナリのパスは以下のようになります:
# ~/.cache/ms-playwright/chromium-XXXX/chrome-linux64/chrome (Linux)
# ~/Library/Caches/ms-playwright/chromium-XXXX/chrome-mac/Chromium.app/Contents/MacOS/Chromium (macOS)
# オプション2:Chrome for Testingの直接ダウンロード
# 以下にアクセス:https://googlechromelabs.github.io/chrome-for-testing/
# OSに合ったバージョンをダウンロード
インストール後、バイナリのフルパスを記録してください — 次のステップで必要になります。
統合には2つの要素が連携しています:
9222を使用)でCDPを公開。config.yamlの小さな変更:それ自体のブラウザを起動する代わりに、このCDPポートに接続するように指示。これだけで、コードやHermesの修正は必要ありません。
CapSolver Chrome拡張機能をダウンロードし、安定した場所に抽出します:
CapSolver.Browser.Extension-chrome-vX.X.X.zipをダウンロードmkdir -p ~/.hermes/capsolver-extension
unzip CapSolver.Browser.Extension-chrome-v*.zip -d ~/.hermes/capsolver-extension/
ls ~/.hermes/capsolver-extension/manifest.json
manifest.jsonが表示されるはずです — これにより拡張機能が正しい場所にあることが確認されます。
パスのヒント:後でChromeに
--load-extension=...を渡す際には、絶対パス(~ではなく)を使用してください。一部のChrome MV3ビルドでは、カスタムユーザーデータディレクトリのシンボリックリンク下で拡張機能のサービスワーカーが登録されない場合があります。他の場所からシンボリックリンクしている場合、readlink -fを使用して実際のパスを解決し、それを使用してください。
拡張機能の設定ファイル~/.hermes/capsolver-extension/assets/config.jsを開き、apiKeyの値を自分のものに置き換えます:
export const defaultConfig = {
apiKey: 'CAP-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX', // ← ここにあなたのキーを入力
useCapsolver: true,
enabledForRecaptcha: true,
enabledForRecaptchaV3: true,
// ... その他の設定
};
あなたのAPIキーはCapSolverダッシュボードから取得できます。
これは重要なステップです。Hermesとは別に、次の3つの重要なフラグでChromeを一度だけ起動します:
--remote-debugging-port=9222 — DevToolsプロトコルを公開し、Hermesが接続できるように--load-extension=... — CapSolver拡張機能を事前にロード--user-data-dir=... — 他のプロファイルと衝突しない専用プロファイルを使用Hermesにはuser-data-dirの組み込みの慣例があります:~/.hermes/chrome-debug。このパスを使用すると、Hermesのインアプリ/browser connectコマンドも追加のフラグなしで「動作します」。
/path/to/chrome-for-testing/chrome \
--remote-debugging-port=9222 \
--remote-debugging-address=127.0.0.1 \
--user-data-dir="$HOME/.hermes/chrome-debug" \
--load-extension="$HOME/.hermes/capsolver-extension" \
--disable-extensions-except="$HOME/.hermes/capsolver-extension" \
--no-first-run \
--no-default-browser-check \
--no-sandbox
/path/to/chrome-for-testing/chromeを実際のバイナリに置き換えてください。例:~/.cache/ms-playwright/chromium-1200/chrome-linux64/chrome。
ヘッドレスサーバー:Linuxサーバーで物理的なディスプレイがない場合(VPS、EC2など)、下記のベストプラクティスセクションで
Xvfbのセットアップを参照してください。Chrome拡張機能サブシステムはディスプレイコンテキストが必要です。
1回のテスト実行より長く動作するセットアップの場合、起動を小規模なシェルスクリプトでラップし、Chromeをバックグラウンドで実行し、クリーンに再起動し、任意のプロセスマネージャー(systemd、supervisor、runit、OpenRC、Dockerなど)で監視できます。
~/.hermes/chrome-debug.shとして保存し、chmod +xを実行:
#!/usr/bin/env bash
# ~/.hermes/chrome-debug.sh
# CapSolverを搭載したChrome-for-Testingを起動し、
# 127.0.0.1:9222でCDPを公開します。
CHROME_BIN="$HOME/.cache/ms-playwright/chromium-1200/chrome-linux64/chrome"
EXT_DIR="$HOME/.hermes/capsolver-extension"
USER_DATA_DIR="$HOME/.hermes/chrome-debug"
export DISPLAY=:99 # ヘッドレスLinux用 — ベストプラクティスを参照
exec "$CHROME_BIN" \
--remote-debugging-port=9222 \
--remote-debugging-address=127.0.0.1 \
--user-data-dir="$USER_DATA_DIR" \
--load-extension="$EXT_DIR" \
--disable-extensions-except="$EXT_DIR" \
--no-first-run \
--no-default-browser-check \
--no-sandbox \
--disable-dev-shm-usage \
--disable-features=Translate
最も単純な永続的な起動は次の通りです:
nohup ~/.hermes/chrome-debug.sh > /tmp/chrome-debug.log 2>&1 &
プロダクション環境では、任意のプロセスマネージャーでスクリプトを監視してください。最小限のsystemdユニットを~/.config/systemd/user/chrome-debug.serviceに:
[Unit]
Description=CapSolver対応のChrome for Hermes Agent
After=network.target
[Service]
ExecStart=%h/.hermes/chrome-debug.sh
Restart=always
RestartSec=5
[Install]
WantedBy=default.target
その後:
systemctl --user daemon-reload
systemctl --user enable --now chrome-debug
同等のセットアップ(supervisordプログラム、runitサービス、Dockerコンテナなど)は同じように動作します — 統合は何かがchrome-debug.shを実行し続けることを気にしません。
~/.hermes/config.yamlのHermes設定を編集してください。browser:セクション(通常はinactivity_timeoutのみ)を見つけて、cdp_urlを追加:
browser:
inactivity_timeout: 120
cdp_url: http://127.0.0.1:9222
この1行は、Hermesのbrowser_cdpツールが、ステップ3で起動したChromeインスタンスを通じてすべてのブラウザ操作をルーティングすることを指示します。それ自体のブラウザを起動する代わりに。
元に戻す:これはHermes自体への唯一の変更です。元に戻すには、
cdp_urlの行を削除してください。Hermesは、以前使用していたデフォルトブラウザプロバイダー(Browserbase、Browser Useなど)に戻り、他の副作用はありません。
Hermesがすでに動作している場合、新しいcdp_urlを反映させるために再起動してください:
# 直接実行(フォアグラウンドまたは監視ソフトで):
hermes gateway run
# または、Hermesを監視している任意のプロセスマネージャーで再起動 —
# 唯一の要件は、新しい環境/設定が有効になることです。
Hermesには、統合のすべての部分を一度にチェックする組み込み診断コマンドが含まれています:
hermes doctor
これらのシグナルを探してください:
◆ ツールの利用可能性
✓ browser-cdp ← CDPアタッチが動作中
✓ browser
...
◆ API接続性
OpenRouter APIをチェック中... ✓ OpenRouter API
browser-cdpがツールの利用可能性の下に表示されている場合、HermesはCDPエンドポイントを検出しており、統合は正しく接続されています。表示されていない場合、Hermesはツールを無効にします(エラーなし) — その診断を確認してください。
また、Chromeが直接アクセス可能か確認することもできます:
curl -s http://127.0.0.1:9222/json/version
CDPが動作していることを確認するレスポンスは次のようになります:
{
"Browser": "Chrome/<あなたのバージョン>",
"Protocol-Version": "1.3",
"webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/browser/..."
}
CapSolverサービスワーカーの可視性について: Chrome MV3サービスワーカーは積極的にアイドル状態になります。最近のChromeビルドでは、/json/listが実行中のサービスワーカーを完全に省略する場合があります。/json/listに表示されないことは診断的ではないため、CapSolverが動作していることを確認するには、エージェントを通じて本物のreCAPTCHAページをロードし、ページ内ウィジェットの結果を観察してください。ターゲットリストをポーリングするのではなく、これにより確認してください。
これは最も重要なセクションです。設定が完了したら、HermesでCapSolverを使用するのは非常に簡単です。
エージェントにCAPTCHAまたはCapSolverについて言及しないでください。 フォームを送信する前に時間を与えてください。
エージェントはCAPTCHAについて知る必要はありません。拡張機能が背景ですべてを処理します。必要なのは、拡張機能がチャレンジを解決する時間があるように、指示に待機時間を含めることだけです。
Hermesの1回限りモード(hermes -z "...")は、統合テストに最適です。hermes CLIが利用可能な任意のターミナルで実行してください:
hermes -z 'https://www.google.com/recaptcha/api2/demoを開き、ページが完全にレンダリングされるまで60秒待機してください。次に、「Send!」ラベルまたはID「recaptcha-demo-submit」のボタンをクリックしてください。クリック後、5秒待って、ページに表示されているテキストを教えてください。' --yolo
裏で何が起こるか:
g-recaptcha-responseフォームフィールドに挿入されますこの"Verification Success... Hooray!"という文字列はGoogleの確認メッセージであり、フォームに有効なreCAPTCHAトークンが送信された場合にのみ表示されます。
Hermesゲートウェイに接続されている任意のチャネル(Telegram、Discord、Slackなど)から送信してください:
https://example.com/loginに移動し、メールアドレスフィールドに"me@example.com"、パスワードフィールドに"mypassword123"を入力してください。その後30秒待って「Sign In」ボタンをクリックしてください。サインイン後のページは何ですか?
Hermesはリクエストをエージェントにルーティングし、同じChromeに接続し、フォームを入力し、ログインページのCAPTCHAを解決する時間を与え、サインインをクリックし、サインイン後のページの内容を返します。この間、CAPTCHAについて一切言及する必要はありません。
https://example.com/contactを開き、連絡フォームを入力してください:
- 名前: "John Doe"
- メールアドレス: "john@example.com"
- メッセージ: "こんにちは、サービスについて質問があります。"
60秒待ってから「メッセージを送信」をクリックしてください。
ページに表示される確認メッセージは何ですか?
| CAPTCHAタイプ | 通常の解決時間 | 推奨待機時間 |
|---|---|---|
| reCAPTCHA v2(チェックボックス) | 5–15秒 | 30–60秒 |
| reCAPTCHA v2(非表示) | 5–15秒 | 30秒 |
| reCAPTCHA v3 | 3–10秒 | 20–30秒 |
| AWS WAF CAPTCHA | 5–15秒 | 30秒 |
ヒント: 不確実な場合は60秒を使用してください。早すぎる送信よりも少し長く待つ方が良いです。追加の待機時間は基本的に無料です—CapSolverの料金は解決ごとで、秒ごとではありません。
Hermesのどのチャネルでも使用できる検証済みの表現です:
エージェントを混乱させたり、一部のセーフティチューニングモデル(特にGLMシリーズ)で拒否が発生する可能性があるため、以下の表現を避けてください:
技術的に興味のある方のために、アーキテクチャを以下に示します:
あなたのメッセージ Hermesゲートウェイ
──────────────────────────────────────────────────────────
"ページに移動し、 ──► Hermesエージェントがメッセージを受信
60秒待って送信" │
▼
browser_cdp / browser tools
│ (WebSocket経由でws://127.0.0.1:9222に接続)
▼
┌────────────────────────────────────┐
│ chrome-debug Chromium(背景)│
│ │
│ ┌───────────────────────────────┐ │
│ │ CapSolver MV3拡張機能 │ │
│ │ (--load-extensionでロード;│ │
│ │ Chromeでテストする必要があります│ │
│ │ またはChromium—ブランド付きChrome│ │
│ │ 137+はこのフラグを無視します)│ │
│ │ │ │
│ │ 1. コンテンツスクリプトがCAPTCHAを検出 │
│ │ 2. サービスワーカーがCapSolver APIを呼び出し │
│ │ 3. トークンを取得 │ │
│ │ 4. トークンをフォームフィールドに挿入 │ │
│ └───────────────────────────────┘ │
└────────────────────────────────────┘
│
▼
Hermesエージェントが60秒待機...
│
▼
browser_cdp: 送信ボタンをクリック
│
▼
有効なトークンが含まれたフォームが送信されます
│
▼
送信後の確認ページ
Hermesのブラウザツールレイヤーは、5つの交換可能なプロバイダー(Browserbase、Browser Use、Firecrawl、Camoufox、headless Chromium)で構築されています。そのうち3つはクラウド—ブラウザバイナリを制御できないため、--load-extensionフラグを配置する場所がありません。1つ(Camoufox)はFirefoxベースです。5つ目の—CDP接続—は、ユーザーが制御するChromiumを接続できる唯一のセームです。
トレードオフは非常に良いものです:Hermesはデフォルトでクラウドに移行可能ですが、ブラウザ側のスーパーパワー(CapSolver、独自の広告ブロッカー、カスタムMV3ツール、永続的なクッキーなど)が必要な場合は、Chromeを自分で起動し、Hermesに接続するだけです。1行の構成ファイル。完全なコントロール。
--load-extensionが実際に何をするのかChromeが--load-extension=/path/to/extensionで起動すると、そのディレクトリが展開済み拡張機能として扱われます—Chromeの開発者モードで使用されるメカニズムと同じです。拡張機能のマニフェスト、コンテンツスクリプト、サービスワーカーは、Chromeウェブストアからインストールした場合と同じように登録されます。サンドボックスの違いやAPIアクセスの低下はありません—完全に特権を持つ拡張機能です。
CapSolver拡張機能は以降を処理します:
assets/config.jsからのキーを使用してCapSolver APIに認証し、チャレンジの詳細を送信し、トークンをポーリングしますHermesエージェントは完全に無関係です—正常なページを見ているだけです。あなたが指示した時間だけ待って送信します。ページには単に有効なトークンが含まれているだけです。
環境の注意: Chromeのフラグで
--disable-background-networkingを避けてください。これによりCapSolverサービスワーカーの出力XHR/fetchがブロックされ、拡張機能がCapSolver APIに到達できなくなります。ステップ3のレシピでは意図的にこれを省略しています。
~/.hermes/config.yaml必要な変更はbrowser:ブロックにcdp_urlを追加することのみです:
browser:
inactivity_timeout: 120
cdp_url: http://127.0.0.1:9222
--load-extension引数Chromeに渡すべき完全なフラグ一覧:
| フラグ | 目的 |
|---|---|
--remote-debugging-port=9222 |
CDPをTCPポート9222で公開(Hermesが接続するために必須) |
--remote-debugging-address=127.0.0.1 |
CDPをループバックにバインド(セキュリティ—CDPを公開しないでください) |
--user-data-dir=$HOME/.hermes/chrome-debug |
お使いの個人用Chromeと衝突しない専用プロファイル |
--load-extension=/abs/path/to/capsolver-extension |
実際の拡張機能をロード |
--disable-extensions-except=/abs/path/to/capsolver-extension |
二重の保険—この拡張機能のみをロード |
--no-first-run --no-default-browser-check |
Chromeのセットアップウィザードをスキップ |
--no-sandbox |
Chromeのサンドボックスを無効化。Chromiumドキュメントでは「テスト目的のみ」とされていますが、ユーザー名空間/SYS_ADMIN能力が利用できないヘッドレスLinux/Docker環境での標準的なワークアラウンドです。 |
--disable-dev-shm-usage |
コンテナでの/dev/shmの問題を回避 |
assets/config.js~/.hermes/capsolver-extension/assets/config.jsでの最小構成:
export const defaultConfig = {
apiKey: 'CAP-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',
useCapsolver: true,
enabledForRecaptcha: true,
enabledForRecaptchaV3: true,
// ... CapSolverドキュメントで完全なトグル一覧を参照
};
hermes doctorがTool Availabilityでbrowser-cdpを表示しない症状: Hermesを再起動した後、hermes doctorの出力にbrowser-cdpツールが表示されません。
原因: HermesはCDPエンドポイントが構成されている場合にのみbrowser-cdpを登録します—config.yamlのbrowser.cdp_url、BROWSER_CDP_URL環境変数、またはアクティブな/browser connectセッション。チェックは構成の存在であり、到達可能性ではありません(tools/browser_cdp_tool.py:_browser_cdp_checkを参照)。したがって、browser-cdpツールが表示されない最も一般的な原因は、config.yamlにキーが誤ってネストされていること、またはCDPが到達不可能なことではなく、構成のエラーです。
修正:
# 1. キーが"browser:"の下に正しくネストされているか確認
grep -A2 '^browser:' ~/.hermes/config.yaml
# 期待される出力:
# browser:
# ...
# cdp_url: http://127.0.0.1:9222
# 2. そのエンドポイントでChromeが実際に動作しているか確認
curl -s http://127.0.0.1:9222/json/version
# 3. Chromeが起動していない場合、chrome-debugログを確認
tail -n 30 /tmp/chrome-debug.log # または: journalctl --user -u chrome-debug -n 30
症状: Chromeはクリーンに起動しますが、CAPTCHAは解決されず、すべての送信が失敗します。
原因: ブランド付きGoogle Chrome 137+を使用しており、--load-extensionが無視されています。
修正: Chrome for TestingまたはChromiumに切り替えてください。バイナリを確認してください:
/path/to/your/chrome --version
# Chrome for Testing: "Chromium 143.0.7499.4"
# ブランド付きChrome: "Google Chrome 143.0.7499.109" ←動作しません
可能性のある原因:
--disable-background-networkingフラグが含まれていないか確認してください(拡張機能の出力API呼び出しをブロックします)症状: ハーメスを再起動した後の最初のブラウザアクションがタイムアウトしますが、以降のアクションは正常に動作します。
原因: 冷却スタート時のCDPハンドシェイクがHermesのデフォルトのツールタイムアウトを超えることがあります。以降のアクションはウォームなWebSocketを再利用し、高速です。
修正: コマンドを再実行してください。問題が解決しない場合は、config.yamlのbrowser.inactivity_timeoutを増やしてください。
症状: 1つのChromeバージョンから別のバージョンに切り替えた後、Chromeがディスクキャッシュエラーでクラッシュします。
原因: user-data-dirは別のChromeバージョンで作成され、今では互換性がありません。
修正:
# 1. 現在のchrome-debugプロセスを停止(あなたのプロセスマネージャーで)
pkill -f "remote-debugging-port=9222"
# 2. 古いプロファイルを削除
rm -rf ~/.hermes/chrome-debug
# 3. chrome-debugを再起動(プロセスマネージャーで、またはスクリプトを再実行)
nohup ~/.hermes/chrome-debug.sh > /tmp/chrome-debug.log 2>&1 &
/json/listに表示されない症状: curl http://127.0.0.1:9222/json/listはpageエントリのみを返し、service_workerは表示されません。
原因: Chrome MV3サービスワーカーは積極的にアイドル状態になり、最近のChromeビルドでは/json/listエンドポイントがアクティブにイベントを処理している場合でも、それらを表示しないことがあります。
修正: これは診断的ではないため、CapSolverがロードされていることを確認するには/json/listに頼らないでください。代わりに、エージェントを本物のreCAPTCHA保護ページ(例: https://www.google.com/recaptcha/api2/demo)に移動させ、フォーム送信が成功するか確認してください。成功した送信は拡張機能がロードされ、チャレンジを解決している証拠であり、ターゲットリストのエントリが表示されないことは失敗のシグナルではありません。
より長い待機時間は常に安全です。CAPTCHAは通常5〜20秒で解決されますが、ネットワーク遅延、複雑なチャレンジ、またはリトライにより時間が追加されることがあります。30〜60秒が最適な範囲です。
以下のようにしないでください:
"URLに移動し、CAPTCHAソルバーを待ってから送信"
以下のようにしてください:
"URLに移動し、約1分間待ってからフォームを送信"
自然な表現はエージェントにとってより効果的であり、セーフティチューニングされたモデルとも調和しやすくなります。CAPTCHAの周囲で敵対的な表現が使用された場合、一部のGLMクラスモデルで拒否が発生することが観測されています。
各CAPTCHAの解決にはクレジットがかかるため、capsolver.com/dashboardで定期的に残高を確認してください。これにより、中断を防ぐことができます。
--user-data-dirを実際のChromeプロファイルに指定しないでください。代わりに~/.hermes/chrome-debugを使用してください(Hermesの組み込み/browser connectもデフォルトでこのディレクトリをターゲットにしています)。これにより、エージェントのブラウザが個人のブラウジングから完全に隔離されます。
--remote-debugging-address=127.0.0.1は本番環境で必須です。Chrome DevTools Protocolは、ポートにアクセスできる誰にでもブラウザの完全な制御権を与えます。9222ポートをパブリックネットワークに公開しないでください。
Xvfbを使用するChrome拡張機能は、ブラウザを表示したくても表示コンテキストを必要とします。物理的なディスプレイがないLinuxサーバーで、仮想ディスプレイを起動してください:
# Xvfbのインストール (Ubuntu/Debian)
sudo apt-get install xvfb
# 仮想ディスプレイの起動
Xvfb :99 -screen 0 1920x1080x24 &
# Chromeに使用させる (上記のchrome-debug.shランチャーはすでにDISPLAY=:99をエクスポートしています)
export DISPLAY=:99
chrome-debug.shランチャーを使用している場合、上記のexport DISPLAY=:99の行はすでに処理されています。ホストでXvfb :99が実行されていることを確認してください。
chrome &のような緩いコマンドは、親シェルが終了したとき、Chromeがクラッシュしたとき、またはボックスが再起動したときに終了します。chrome-debug.sh(ステップ3)でラップし、既存のスタックで実行しているプロセスマネージャー(systemd、supervisord、runit、Dockerなど)で監視してください。統合はプロセスマネージャーに依存せず、ホストで既に実行されているものを選んでください。
モデルはCAPTCHAを一度も見ることなく、拡張機能が非表示で解決するため、CAPTCHAが多いために最前線のモデルを必要としません。安価でツール対応のモデルで十分です(例: config.yamlでprovider: openrouterとdefault: z-ai/glm-4.6を設定)。すべての知恵は拡張機能にあり、モデルはナビゲート、タイプ、クリックのみが必要です。
Hermes + CapSolverの統合は、エージェントワークフローにおけるCAPTCHA解決の根本的な新しいアプローチを示しています。CAPTCHAを検出するコードを書く、APIを呼び出す、トークンをインジェクトする代わりに、単に:
--load-extension=/abs/path/to/capsolver-extensionと--remote-debugging-port=9222を使用して~/.hermes/config.yamlのbrowser:ブロックにcdp_urlを追加する:
browser:
cdp_url: http://127.0.0.1:9222
cdp_urlは無視されます)CapSolverのChrome拡張機能が残りの処理を担当します — CAPTCHAを検出し、CapSolver APIを介して解決し、トークンをページにインジェクトします。エージェントはCAPTCHAについて一切知らなくても構いません。
これは、自律的なAIエージェントがある場合のCAPTCHA解決の姿です: 目に見えず、自動的で、コードなし。
準備ができましたか? CapSolverに登録する そして初回充電時にボーナスコード
hermeを使用してください!

いいえ。 実際には、メッセージでCAPTCHAやCapSolverについて言及しないでください。拡張機能はバックグラウンドで非表示で動作します。CAPTCHAがページに表示されている場合に解決する時間を与えるために、指示に待機時間を含めてください(例: 「60秒待ってから送信」)。
Google Chrome 137+(2025年中盤リリース)では、ブランド版で--load-extensionコマンドラインフラグが削除されました。これは自動化されたセッションでChrome拡張機能をロードできなくなったことを意味します。このフラグをサポートしているChrome for TestingまたはスタンドアローンのChromiumを使用する必要があります。
いいえ — クラウドプロバイダーはブラウザを他人のインフラで実行するため、セッションに任意の拡張機能をロードすることはできません。このガイドのCDPアタッチパターンがHermesとChrome拡張機能を組み合わせる唯一の方法です。(config.yamlでbrowser.cdp_urlが設定されると、HermesはローカルChromeを通じてブラウザトラフィックをルーティングし、クラウドプロバイダーはその行を削除するまで無効になります。)
はい — --load-extensionをサポートしているあらゆるChromiumベースのブラウザが動作します。使用可能なブラウザには以下が含まれます:
npx playwright installを実行したことがある場合、すでにホストにあります)統合の方法は同じです: --remote-debugging-port=9222 --load-extension=/path/to/capsolver-extensionを任意のバイナリに指定してください。
動作しないもの:
--load-extensionを無視しますはい — CamoufoxはHermesの5つの組み込みブラウザプロバイダーの1つであり、Chrome拡張機能を含まないタスクに最適なステルスFirefoxオプションです。問題はCamoufoxがFirefoxベースであり、CapSolverブラウザ拡張機能がChrome MV3形式で動作するため、1つのセッションで一緒に動作できないことです。
良いニュース: Hermesでは、永続的に選ぶ必要はありません。~/.hermes/config.yamlのbrowser.cdp_url設定は単一のスイッチです — CAPTCHA解決が必要なときにCapSolver対応のChromeに、Firefoxステルスが必要なときにCamoufoxにポイントします。一般的な設定では両方を実行しています:
# 有効な行: プロファイルをコメント/アンコメントで切り替え
browser:
cdp_url: http://127.0.0.1:9222 # CapSolver Chrome(このガイド)
# cdp_url: http://127.0.0.1:9333 # Camoufoxエンドポイント
Hermesを再起動(hermes gateway run、またはホストでゲートウェイを再起動する)すると、数秒で切り替えが適用されます。同じHermes、同じチャネル、同じスキル — 作業に応じて異なるブラウザを使用できます。
/browser connectコマンドはこの設定で動作しますか?はい。Hermesの組み込み/browser connectスラッシュコマンド(インタラクティブhermes TUI内)は、使用したデフォルトのuser-dataディレクトリ(~/.hermes/chrome-debug)と同じポート(9222)をターゲットにしています。chrome-debugサイドカーを設定した後、Hermes内で/browser connectを使用できます。または、config.yamlのbrowser.cdp_urlを永続的な接続に設定してください — 両方とも同じChromeに対して動作します。
統合は完全にチャネルに依存しません。config.yamlでbrowser.cdp_urlが設定されると、CLIのhermes -z、インタラクティブhermes TUI、またはTelegram、Discord、Slack、WhatsApp、Signal、メールからのメッセージから来るすべてのブラウザアクションが、CapSolver対応のChromeを通じてルーティングされます。拡張機能はすべてのケースで同じようにCAPTCHAを解決します。
デモページは素早くテストするためのみに使用してください。Googleの公式reCAPTCHA FAQでは、本番パイプラインで公開デモページに依存するのではなく、専用のテストサイトキーを作成することを推奨しています。
CapSolver Chrome拡張機能はreCAPTCHA v2(チェックボックスおよび非表示)、reCAPTCHA v3、Cloudflare、AWS WAF CAPTCHA、および他の広く導入されているウィジェットを自動的に解決します。コンテンツスクリプトはページ上のCAPTCHAタイプを検出し、それに応じて解決します — あなたの側でタイプごとの構成は必要ありません。(注: Cloudflare TurnstileおよびCloudflare 5秒チャレンジはブラウザ拡張機能では解決されません。これらはCapSolverのAPIでのみ利用可能であり、このガイドの範囲外です。)
CapSolverはCAPTCHAの種類と量に基づいて競争力のある料金を提供しています。最新の料金についてはcapsolver.comをご覧ください。
Hermes Agentはオープンソース(github.com/NousResearch/hermes-agent)であり、自前のハードウェアで無料で実行できます。AIモデルプロバイダーのAPIキー(OpenRouterが推奨されます — Hermesはそれ経由で200以上のモデルをサポートしています)と、CAPTCHA解決用のCapSolverアカウントとクレジットが必要です。
ほとんどのCAPTCHAでは30〜60秒が十分です。実際の解決時間は通常5〜20秒ですが、余分なバッファを追加することで信頼性が確保されます。迷った場合は60秒を使用してください。
はい。Chrome拡張機能は表示コンテキストを必要とするため、Xvfb(X仮想フレームバッファ)が必要です。ホストでXvfb :99 -screen 0 1920x1080x24 &を実行し、chrome-debug.shランチャーでDISPLAY=:99がエクスポートされていることを確認してください(ステップ3のランチャーはすでにこれを処理しています)。また、ほとんどのサーバーカーネルではChromeのサンドボックスが必要とする機能が与えられないため、Chrome引数に--no-sandboxを含めてください。
技術的には可能ですが、タブ/セッションの競合を自分で管理する必要があります。ほとんどのワークロードでは、1つのHermes ↔ 1つのchrome-debugが最もクリーンな設定です。真の並列性が必要な場合、異なるポート(9222、9223、…)で複数のchrome-debugサイドカーを実行し、各Hermesをそれぞれのポートにポイントしてください。
はい。Hermesスキルはプロシージャルメモリ — エージェントが学んだステップのシーケンスです。CAPTCHA保護されたサイトをブラウズするスキルは、アドホックメッセージと同じようにCapSolver統合から自動的に恩恵を受けます。スキル側の変更は必要ありません。