新機能
/api/auto エンドポイントは、あらゆる URL に対し有効なレスポンスを得るための最短経路となりました。ターゲットを指定するだけで機能します。Auto がリクエストを Single、Proxy Finder、Browser のいずれで実行するかを自動選択し、Bot 対策の課題が発生した場合は処理を行い、次の呼び出しで再利用できるセッションを返します。
1 つのエンドポイントであらゆるターゲットに対応し、クライアント側でのモード切り替えは不要です。
これが全体像です。本記事の以降では、動作の仕組み、コスト、および注意点について解説します。
動作の仕組み
Auto の内部には、複数の実行ステップ（安価なものから高価なものへの順）が段階的に配置されています。リクエストごとに、Auto は validate ルールが承認するレスポンスをいずれかのステップが返すまで、順にステップを実行します。
ステップの順序:
- キャッシュされたセッション。 以前の呼び出しによる同一ホストの有効なセッションがある場合、まずそれを使用してリプレイします。最も安価な経路です。
- Proxy Finder。 ローテーションされたプロキシリクエストです。主に IP レピュテーションで保護されているサイトに適しています。
- Browser。 JavaScript を実行し、Bot 対策の課題を解決し、サイトが発行する Cookie を収集するフルレンダリングです。
いずれかのステップで成功すると、Auto は検出されたセッション（使用したプロキシ ID、発行された Cookie、User-Agent）を保存します。同一ホストへの次回のリクエストでは、Auto はまずそのセッションを試行します。それが引き続き有効であれば、高価なステップではなく安価なステップの料金のみが発生します。
最小限の呼び出し例:
curl -X POST "https://api.foura.ai/api/auto" \
-H "X-API-Key: pk_live_..." \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/data",
"validate": { "status": { "accept": [200] } }
}'
トリミングされたresponse:
{
"status": 200,
"data": "...",
"headers": [...],
"meta": {
"rung": "cache",
"solved": false,
"attempts": 1,
"credits": 2
},
"session": {
"proxy": "CLN1B8",
"cookies": [{ "name": "cf_clearance", "value": "..." }],
"userAgent": "..."
}
}
次に何を構築するかにおいて、2つのフィールドが重要になります。meta.rungはどのパスが成功したかを示します。sessionは、同じイグジットを自身で再試行するために/api/single呼び出しに引き継ぐことができるトリプルです。proxyフィールドは不透明なbase36 ID（生IPなし）であり、ログへの記録やシステム間での受け渡しを安全に行えます。
Impact
ここで重要となる数字は2つあります。
保護されたサイトへの最初の呼び出しではBrowserラングが実行されます。レンダリング、解決、cookieの収集を行い、ページを返します。これには約10クレジットかかります。Autoがそのホストに対して有効なセッションをキャッシュすると、以降の呼び出しはそれを再利用します。Single経由なら2クレジット、セッションのcookieが任意のアドレスから機能する場合はProxy Finder経由で4クレジットです。そのため、2回目の呼び出しは初回に比べて最大5倍安くなり、セッションが維持される限り、その後のすべての呼び出しで安価なレートが適用され続けます。ロールアウト中に本番環境でこれを測定したところ、cookie不要のイグジットは（一度見つかれば）、すべてのrequestがProxy Finderを経由していた従来の10クレジットに対し、1回あたり正確に2クレジットで再利用されました。
2つ目の数字について: 失敗したラングには課金されません。Autoが3つのproxyを試行し、4つ目が成功する前にそれぞれが403を返した場合、4つ目のクレジットのみがカウントされます。探索ではなく、配信されたコンテンツに対してのみ料金が発生します。
これがコアとなる価値です。コストの高いラングは1回だけ実行され、安価なラングがその後ずっと実行されます。キャッシュロジックを独自に作成する必要はありません。
本番環境での実際の問題を解決する、注目すべき動作が他にも2つあります。
ジオフェンスされたターゲットによるイグジットの浪費を防止。 サイトがほとんどのイグジットに対して451（または法的ブロックのインタースティシャル）を返す場合、Autoは実際にコンテンツを配信した国を学習します。次の呼び出しでは、まずそれらの国から新しいイグジットを取得し、同時実行負荷をそれらに分散します。そのため、幸運にも成功した単一のイグジットにアクセスが集中してrate limitにかかることはありません。
Validateはすべてのラングで実行。 不正なコンテンツのページ（本文に法的通知を含むステータス200を返すジオブロックなど）がヒットとしてカウントされることはありません。validate.data.failに「legal reasons」が含まれている場合、Autoはラングがそれを通過するまで処理を継続します。キャッシュされたラングでも、他のどのラングでも同様です。何も通過しない場合は、実際の理由とともに明確な失敗が返されます。
For Power Users
Autoで大量のトラフィックを処理する際に重要となる設定項目です。
timeout_msはラング単位ではなく、操作全体のバジェットです。デフォルトは120秒です。Autoはこれを配分します。各サブ呼び出しには min(自身のデフォルトタイムアウト, 残りバジェット) が割り当てられ、残り時間が少なすぎるとラダーは新しいラングの起動を停止します。インタラクティブなレイテンシ重視の処理には20,000を設定してください。ロングテールを許容する一括クロールにはデフォルトのままにしてください。
forceProxyはデフォルトで有効です。forceProxy: falseを設定しない限り、AutoがFourAのオリジンIPからターゲットに接続することはありません。注意点として、一部のサイト（IP信頼度ゲーティングを備えたインタラクティブなCloudflareなど）では、信頼度の低いレジデンシャルイグジットよりも、クリーンなデータセンターIPからのほうが適切に動作する場合があります。そのため、forceProxy: falseによって特定のターゲットの処理が難しくなるどころか、容易になることがあります。特定のホストで繰り返しチャレンジが発生する場合は、これをオフにしてみる価値があります。
ignoreProxies はクライアント側の回避リストです。すでに使い物にならなくなった（クライアント側でレート制限を受けた過去の session.proxy など）プロキシ ID を渡すと、Auto はウォームセッションの再利用、イグジット検索、Proxy Finder へのサブコールなど、すべての処理でそれらをスキップします。これにより、Auto が回避対象として指定されたイグジットを再選択することはありません。
meta を使用して、独自ダッシュボードを構築することも可能です。本日ブラウザ層に到達したホスト、配信あたりの平均試行回数、クリーンな取得に対するチャレンジ解決済み取得の比率などを可視化できます。特定のホストの消費クレジットが突然 2 から 10 に急増した場合、それはセッション劣化のシグナルであり、請求額に反映される前に対処できます。
4 つすべてを組み合わせた例:
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"X-API-Key": "pk_live_..."},
json={
"url": "https://example.com/product/9876",
"timeout_ms": 30000,
"forceProxy": True,
"ignoreProxies": ["CLN1B8", "K7X9AB"],
"validate": {
"status": {"accept": [200]},
"data": {"accept": ['"price":'], "fail": ["captcha", "legal reasons"]}
}
}
).json()
# If Auto delivered, keep the session for the next call to this host
if r.get("status") == 200 and "session" in r:
session = r["session"] # {proxy, cookies, userAgent}
print(r["meta"]["rung"], r["meta"]["credits"], r["meta"]["attempts"])
validate スキーマ自体については、Validate Rules Now Decide What Counts as Success の前回のウォークスルーを参照してください。
次の展開
現在、Auto のロードマップには2つの項目があります。
次は Dashboard へのセッション検査機能の追加です。現在、Auto がホストごとに保持するセッションはサービス内部に存在し、クライアント側で消費状況をデバッグする際に確認する手段がありません。そこで、キャッシュされたセッション、経過時間、有効期限、各セッションの実行ラング履歴を確認できるホスト別セッションビューを構築しています。さらに、ターゲットの仕様が変更されキャッシュが無効だと分かっている場合に、手動でセッションを破棄するボタンも追加します。
その次は、より厳格なコスト制御です。リクエストごとの厳密なクレジット上限設定（この呼び出しでX以上を消費せず、超過する場合は明示的に失敗させる）と、ターゲットがブラウザラングを必要としないチーム向けの「single-only」モードです。どちらも現在はフラグ配下にあります。
Auto の目的は、どの製品を呼び出すかを意識させないことです。ただし、それは何が起きたかを検査できないという意味ではありません。すべてのレスポンスには、実行されたラングと構築されたセッションが含まれます。この2つのフィールドを確認すれば、呼び出しコストの理由を正確に把握できます。