すべての記事

FourA Digest: 2026年8月14日 - 8月21日

実用的なOrganization管理機能、遮断要因を特定するProxy Finder、同一クエリに対するページの重複回答を排除したBrowser。

ハイライト

以前の組織機能は、1人しか保持できない単一の行にすぎませんでした。現在は管理可能な専用ページとなり、同僚の招待、ロールの割り当て、会社請求のキー作成が可能になっています。また、Proxy Finderは「試行回数上限」といった曖昧なエラーを廃止し、遭遇した具体的なブロック要因を報告するようになりました。さらにBrowser機能では、同一ページに対して一貫したブラウザシグネチャを維持する改修を実施しました。

新機能

実用的な組織管理機能

従来は同僚を追加する際に問い合わせメールが必要だったため、チーム内で重複して別個のサブスクリプションを契約するケースが発生していました。

Dashboardに組織専用ページが新設され、3つのロールが利用可能になりました。OwnerはAPIキーの請求先となるサブスクリプションを保持するため組織内に1名のみ存在し、所有権の譲渡によって変更できます。Adminは使用状況、請求、メンバーを管理します。Memberはサービスを利用します。招待はメールアドレス経由で送信され、未登録のユーザーに対しても有効です。

組織内の全メンバーが組織所有のキーを作成したり、個人のキーを組織に移行したりできるため、開発者が会社の業務利用で個人宛てに請求される事態を防げます。組織キーの使用量はOwnerのプランに課金され、確認画面には常にどのプランから支払われるかが明記されます。キーの名前変更は全メンバーが可能ですが、再生成、無効化、削除の権限はOwnerとAdminに限定されます。これらは実行した瞬間に全同僚の利用が停止するためです。

Overview、Detailed Metrics、Recent Activity、キー一覧には共通のOwnerフィルターが適用されます。MemberがOwnerのクォータ詳細を閲覧する必要はないため、Usage & LimitsおよびBillingは個人表示のまま維持されます。

Proxy Finderの推測処理を排除

「Download maxTry limit reached」というエラーは、全エグジットがブロックされたのか、全エグジットが無応答だったのか、あるいは正常にページを取得できたものの独自ルールによって破棄されたのかを区別できませんでした。これら3つはそれぞれ対処法が根本から異なります。

失敗したタスクにattemptReportが含まれるようになりました。応答がなかったエグジット数、識別済みの防御システムに拒否された数およびそのベンダー名、validate.statusによって拒否された数、そして防御の兆候がなくHTTP 200を返したもののvalidate.dataのみに合致しなかった数が明示されます。簡潔な要約文もあわせて出力されます。

特に最後のカウントが重要です。マッチしないコンテンツルールは、従来の測定基準では全方位からのブロックと完全に同じ挙動に見え、いくらリトライしても解決しません。(validateルールの判定仕様の詳細を参照してください。)

もう1つの改善点はプロファイルです。従来のProxy Finderはエグジットのみをローテーションし、クライアントシグネチャを変更していませんでした。そのため、特定のブラウザプロファイルを拒否するサイトでは、プール内の全エグジットで拒否が発生していました。現在は拒否を検知すると、既存のリトライフロー内でプロファイルも切り替えるため、タスクあたりのrequest数やクレジット消費は変わりません。ご自身でprofileを固定している場合は何も変更されません。なお、最も難度の高いターゲットにおいては、送信するプロファイルよりも接続先エグジットの品質が依然として重要です。

Browserのシグネチャ矛盾を解消

BrowserにUser-Agentを要求する処理は、以前は要求しない方がましなほどでした。3つのレイヤーがそれぞれリクエストの送信元を別々に認識していたため、1つのリクエストがWindows、Mac、そしてフリートで実行されていないバージョンをすべて同時に名乗ることがありました。現在は一度決定された1つの値が、起動、ページ、ページが開始するworkerなど、すべての場所に引き継がれます。

Client Hintsはその文字列から生成されるため、sec-ch-ua、プラットフォーム、navigator.platformの間で整合性が保たれます。クリアランスクッキーはexitとUser-Agentの組み合わせに紐づくため重要ですが、レスポンスには実際に送信された文字列が返されます。レンダラーに関する判定もドキュメント内とworker内で一貫した結果を返すようになり、積み重なる微弱なシグナルの1つが解消されました。

あわせて以下の3点もリリースされました:

  • クロックがexitに追従。 Browserはexitが存在する国のタイムゾーンで動作するため、ローカル時間をレンダリングするページには現地の訪問者と同じ表示が反映されます。国が不明な場合、クロックは変更されません。
  • WebRTCが他のトラフィックと同一経路を維持。 プロキシ設定はブラウザがTCP経由で送信するトラフィックを対象とします。WebRTCはその経路上にないため、ページがICE candidateを要求すると別の応答が返されます。Browserは、リクエストにexitが含まれている場合は常にこれを無効化します。
  • アンカー付きURLのコストを適正化。 #reviewsで終わるURLで毎回タイムアウトが発生していた問題を解消し、通常の処理速度に戻りました。

ルーティングの低コスト化と、正確な集計を行うDashboard

Impervaはブロックページだけでなく正常なページにもスクリプトを挿入しますが、Autoが両者を判別できず、正常なページでも不要にブラウザへエスカレーションされていました。あるレンタカーサイトでは6回の試行で75クレジットと27.5秒を消費していましたが、現在は1回の試行、10クレジット、約6.5秒で完了します。セッションなしのリクエストに対する拒絶レスポンス内にセッションを付与して返すサイトがありますが、全4種類のエンジンがエスカレーション前にそのセッションを即座に送り返すようになりました。

Overviewのクレジットカードでは、消費されたすべてが表示され、請求対象としてラベル付けされていました。成功報酬型の課金体系では両者に差が生じ、その差額は実質的なコストに直結するため、カード上には両方が表示されるようになりました。請求対象の数値が大きく表示され、その下に消費分が製品別および合計で表示されます。Requestsカードも同様に分割されています。期間と詳細度も個別のコントロールになり、30分から1年、カスタム範囲まで指定可能になり、「1D」と表示されながら30日間を開いていたピルUIは廃止されました。

Playgroundでは、carryボタンで前回のレスポンスのプロファイルを選択できるようになり、手入力していないプロファイルで送信されたリクエストでも、成功したバージョンを再実行できるようになりました。すべてのパラメータはAPIリファレンスに記載されています。

内部仕様

Proxy Finderはホストごとに保持する履歴を増やし、従来の十数件から32件のエグジットを保持するようになりました。本番環境のA/Bテストでは、難易度の低いターゲットでは同等、難易度の高いターゲットでは改善が見られ、フリート全体のレイテンシを維持したまま、ページ取得の中央値時間が5.5秒から3.8秒に短縮されました。1つのターゲットでのみ逆の結果が出たものの、原因はまだ特定できていないため、個別に計測を継続しています。

失敗する運命のタスクは、いずれにせよ失敗します。違いは、1分でチケットをクローズできるか、それとも見当違いの計測に午後を費やすかという点にあります。