Webを操作するAIエージェントを作ったことがあれば、きっとこの壁にぶつかったはずです。開発環境では動いた自動化が、本番環境では失敗する。ページが読み込まれない。サイトにブロックされる。数秒で終わるはずのタスクが、数分もかかる。
原因はコードではありません。ブラウザです。
多くの自動化インフラは、DockerコンテナでヘッドレスChrome（画面を表示しないChrome）を動かしています。低コストでスケールでき、デプロイも簡単だからです。しかし、ヘッドレスブラウザには根本的な制約があり、本番環境ではそれが積み重なっていきます。順に見ていきましょう。
ヘッドレスの4つの問題
┌─────────────────────────────────────────────────────────────────┐
│ ヘッドレスブラウザが失敗する理由 │
├────────────────┬────────────────┬───────────────┬───────────────┤
│ │ │ │ │
│ 互換性 │ 検出 │ 性能 │ 信頼性 │
│ │ │ │ │
│ GPUがないと │ ボット対策に │ 起動待ちで │ 結果が │
│ 表示できない │ 遮断される │ 速度が落ちる │ 安定しない │
│ │ │ │ │
│ ┌──────────┐ │ ┌──────────┐ │ ┌──────────┐ │ ┌──────────┐ │
│ │ WebGL │ │ │Cloudflare│ │ │コンテナの│ │ │ タスクA │ │
│ │ Canvas │ │ │PerimeterX│ │ │ 起動に │ │ │ ✓ │ │
│ │ 動画 │ │ │ DataDome │ │ │100秒以上 │ │ │ タスクB │ │
│ │ 複雑な │ │ │ Turnstile│ │ │ かかる │ │ │ ✗ │ │
│ │ JS │ │ │ CAPTCHA │ │ │ │ │ │ タスクC │ │
│ └──────────┘ │ └──────────┘ │ └──────────┘ │ │ ? │ │
│ │ │ │ └──────────┘ │
└────────────────┴────────────────┴───────────────┴───────────────┘
1. 互換性：そもそも動かないサイト
ヘッドレスブラウザは、リソースを節約するためにGPUレンダリングを省いています。しかし、最近のWebアプリはGPUレンダリングを前提に作られています。
本物のGPUレンダリングがないと動かないもの
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
銀行ポータル ████████████████████ セキュリティ部品が動かない
セッションの検証に失敗する
業務ダッシュボード ██████████████████░░ グラフが表示されない
複雑なUI部品がフリーズする
ECサイトの決済 █████████████████░░░ 決済フォームが誤作動する
商品の3D表示が動かない
WebGLアプリ ████████████████████ まったく動かない
汎用的なデータや空のデータを返す
動画配信サービス ███████████████░░░░░ 再生に問題が出る
DRMの検証に失敗する
レガシー業務アプリ ██████████████████░░ ActiveXやJavaのプラグイン
特定のブラウザが必要
本物のブラウザは、GPUアクセラレーションを標準で備えています。実際のハードウェアの上で動くので、WebGL、Canvasフィンガープリント、ハードウェアアクセラレーションによるレンダリングがすべてそのまま動きます。小細工も偽装も必要ありません。お使いのブラウザで動くものは、WebRunでも動きます。
2. 検出：フィンガープリントで見破られる
ボット対策システムは、数百ものシグナルをチェックします。ヘッドレスブラウザは、その大半で引っかかります。
┌─────────────────────────────────────────────────────────────────┐
│ フィンガープリントの比較 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ヘッドレスブラウザ 本物のブラウザ │
│ ────────────────── ────────────── │
│ │
│ navigator.webdriver: true → navigator.webdriver: false│
│ User-Agent: HeadlessChrome → User-Agent: Chrome/131... │
│ WebGL Vendor: ❌ 汎用 → WebGL: ✓ NVIDIA/AMD/Intel │
│ Canvas Hash: ❌ 合成 → Canvas: ✓ 固有で安定 │
│ GPU Queries: ❌ 実機なし → GPU: ✓ 本物のシグネチャ │
│ Mouse Events: ❌ 機械的 → Mouse: ✓ 自然な動き │
│ Plugins: ❌ 空の配列 → Plugins: ✓ 標準的な構成 │
│ Screen: ❌ 既定の800x600 → Screen: ✓ 実際の解像度 │
│ │
│ ⚠️ ブロック ✓ 通過 │
│ │
└─────────────────────────────────────────────────────────────────┘
自動化だと見破られないためのステルスプラグインは、既知の特徴を書き換えてごまかしますが、検出システムの更新のほうが速いのが実情です。本物のブラウザには、ごまかすべき点がありません。はじめから本物だからです。
3. 性能：速さがものを言う
従来のブラウザ自動化は、設計上どうしても遅くなります。コールドスタート、コンテナのオーケストレーション、LLMだけに頼った判断が、あらゆるステップで遅延を生みます。
最初の操作までの時間
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
従来型 ████████████████████████████████████████ 100秒以上
└─ コンテナ → ブラウザ → ページ → LLM → 操作
WebRun █░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1秒未満
└─ 常に起動済みのブラウザ、CNNとLLMのハイブリッド
タスク完了までの時間
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
従来型 ████████████████████████████████████████ 2〜5分
└─ LLMを順番に呼び出し、失敗すれば再試行
WebRun ████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 約45秒
└─ 100ミリ秒未満の判断と並列処理
1分あたりの操作数
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
従来型 ████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 15〜25
WebRun ████████████████████████████████████████ 60〜100
└─ 4倍
WebRunは、画像認識モデル（CNN）と言語モデル（LLM）を組み合わせたハイブリッド構成です。すばやい判断には画像認識モデルを、複雑な推論には言語モデルを使います。ほとんどの操作は、従来のシステムが最初のLLM呼び出しを終える前に完了します。
4. 信頼性：安定した結果
互換性の問題、検出によるブロック、性能の問題が重なると、どれだけ失敗するかが読めなくなります。
インフラ別のタスク完了率
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
（バーは左から順に：成功、一部成功、失敗）
ヘッドレス ██████████████ ████████ ████████████
コンテナ [ 60% ] [ 15% ] [ 25% ]
↑ タイムアウト
↑ ブロック、クラッシュ
本物の ██████████████████████████████ ████ ██
ブラウザ [ 85%以上 ] [ 10%] [5%]
↑ 想定外のケース
↑ サイトのダウン
失敗の内訳（ヘッドレス）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ボット対策による遮断 ████████████████░░░░ 失敗全体の40%
レンダリングの失敗 ██████████░░░░░░░░░░ 失敗全体の25%
タイムアウト ████████░░░░░░░░░░░░ 失敗全体の20%
JavaScriptエラー ██████░░░░░░░░░░░░░░ 失敗全体の15%
本物のブラウザなら、このうち上の2つ（ボット対策による遮断とレンダリングの失敗）は完全になくなります。検出される要素も、レンダリングに失敗する原因もないからです。
アーキテクチャの違い
┌─────────────────────────────────────────────────────────────────┐
│ │
│ 従来のスタック WebRunのスタック │
│ │
│ ┌───────────────────┐ ┌───────────────────┐ │
│ │ Docker │ │ 本物の │ │
│ │ コンテナ │ │ デスクトップ環境 │ │
│ │ │ │ │ │
│ │ ┌───────────────┐ │ │ ┌───────────────┐ │ │
│ │ │Headless Chrome│ │ │ │ 本物のChrome │ │ │
│ │ │ （GPUなし） │ │ │ │ （GPUあり） │ │ │
│ │ └───────────────┘ │ │ └───────────────┘ │ │
│ │ + │ │ + │ │
│ │ ステルスパッチ │ │ ネイティブAPI │ │
│ │ プロキシ切り替え │ │ 実機 │ │
│ │ LLM単独の判断 │ │ CNNとLLM │ │
│ │ 再試行ロジック │ │ 自動復旧 │ │
│ └───────────────────┘ └───────────────────┘ │
│ │
│ 複雑 │ 壊れやすい │ 遅い シンプル │ 安定 │ 高速 │
│ │
└─────────────────────────────────────────────────────────────────┘
比較の結果
| . | ヘッドレスコンテナ | 本物のブラウザ |
|---|---|---|
| 互換性 | GPUに依存するサイトで失敗 | ハードウェアを完全にサポート |
| 検出 | ボット対策システムにブロックされる | すべてのフィンガープリントチェックを通過 |
| 性能 | コールドスタートに100秒以上、タスクに2〜5分 | 1秒未満で起動、タスクは約45秒 |
| 信頼性 | 完了率60〜70% | 完了率85%以上 |
| メンテナンス | 絶えずパッチが必要 | パッチは不要 |
まとめ
ヘッドレスコンテナが失敗する理由は4つあり、しかも互いに重なり合います。GPUレンダリングがないとサイトが正しく動かないこと。ボット対策システムが自動化の特徴を見つけてブロックすること。コールドスタートで速度が落ちること。そして、それらが重なって結果が安定しないことです。
本物のブラウザは、この4つをアーキテクチャの段階で解決します。GPUアクセラレーションを標準で備えているので、サイトは正しく表示されます。フィンガープリントが本物なので、検出されるものがありません。インスタンスは常に起動済みなので、すぐに応答します。そして、すべてが想定どおりに動けば、信頼性は自然とついてきます。
Webは進化しました。次は、ブラウザのインフラが進化する番です。
違いを確かめてみませんか？app.webrun.aiから今すぐ始められます。無料トライアルあり、クレジットカードは不要です。