ハイライト
ダッシュボード上で、自身のAPI keyに対してrequestを直接構成、送信、および再実行できるようになりました。新しいプレイグラウンドは3つの製品すべてに対応しており、実行間でcookie、プリセット、履歴を保持します。これに伴い、2つの信頼性に関する修正が行われました。数週間にわたり静かに機能低下していたunblocker: trueが再びエンドツーエンドで動作するようになり、BrowserがCloudflareのパッシブチャレンジによるcf_clearance cookieを確実にキャプチャするようになりました。
新機能
ダッシュボード プレイグラウンド
/dashboard/#playgroundが本格的なワークベンチになりました。3つの製品タブ（Single、Proxy Finder、Browser）、URLバー、header、body、そして各製品の実際のスキーマに合わせて公開された製品ごとのすべてのフラグが用意されています。requestを送信すると、JSON、HTML、テキストの表示モードでレンダリングされたresponseを確認できます。Ctrl/Cmd+Kを使用して、responseペイン全体を検索できます。大量のHTMLを読み取る必要がある場合は、responseをフルビューポートに展開できます。
私たち自身が使いたい形を目指して構築する中で、いくつかの機能が生まれました。
- 受信したcookieはホストごとのジャーに保存されます。同じホストへの次のrequestにはこれらが自動的に付与され、送信前に任意のcookieを検査、編集、または削除できます。
- 動作中のproxyレールは、Proxy Finderの実行成功時に返されたすべてのproxy idを収集します。これにより、「使用」をクリックするだけで、再入力することなくSingleまたはBrowserのrequestでそのproxyを再利用できます。
- requestをプリセットとして保存できます。履歴ダイアログから、過去20回の実行のいずれかを再実行できます。
- curl再現ツールは、ターミナルから同じrequestを送信するために実行する正確なコマンド（
x-api-keyを含む）を表示します。
プレイグラウンドは有効期限の短い内部tokenに署名するため、プレーンテキストのキーがダッシュボードの外に出ることはありません。クォータ、メトリクス、およびlast_used_atは、自身のコードからrequestを送信した場合と同様に、選択したキーに対してカウントされます。
unblocker: true が再びエンドツーエンドで動作
過去数週間にわたり、unblocker: trueを指定したSingleおよびProxy Finderのrequestが静かに機能低下していたビルドの問題を特定しました。バイパスが実際に組み込まれないままビルドがリリースされていたため、ハンドシェイクレベルのアンチボット壁をクリアすべきrequestが、代わりに一般的なrequestシグネチャを受け取っていました。本来であれば通過できたはずのサイトからブロックされていました。
修正はデプロイ済みです。以前はクリアするためにBrowserが必要だった3つのCloudflareインターセプタを含む、11の実環境ターゲットでエンドツーエンドの検証を行いました。Single単体でこれらを通過できます。Proxy Finder + Browser + Singleのチェーンフロー（proxyを検出し、Browserからcf_clearance cookieを取得し、Singleにそのcookieと同じproxyを付与してページrequestを送信する）は、1回のラウンドトリップで完全なHTMLを返します。
この問題は当社の責任です。unblocker: trueはリリース当日は動作していましたが、定期的な再ビルドの際に静かに破損しました。ここ数週間の間に、保護されたサイトに対してunblocker: trueを指定してrequestを実行し、200を期待したところで403が発生した場合は、これが原因です。もう一度お試しください。
BrowserがCloudflareのパッシブJavaScriptチャレンジに対応
Cloudflareには2つのチャレンジモードがあります。アクティブモード（HTTP 403とインターセプタ）にはすでに対応していました。パッシブモードはより巧妙です。ページはすぐに200を返しますが、Cloudflareが非同期のJavaScriptプローブを注入してクライアントのフィンガープリントを採取し、その後初めてcf_clearance cookieを発行します。この修正前は、プローブが完了する前にBrowserがresponseを確定させていたため、クリアランスcookieがジャーに保存されませんでした。
BrowserはSet-Cookieイベントを明示的にリスンし、body内にパッシブチャレンジのマーカーを検出した場合はcf_clearanceを待機するようになりました。ポーリングや固定の猶予期間はなく、Cloudflare以外のサイトで余計な待ち時間が発生することもありません。テストスイート内の12の実環境ドメイン（うち3つはパッシブパス）において、クリアランスcookieが確実に返されるようになりました。
APIエッジにおけるSSRFの脆弱性を修正
有効なpk_live_... API keyは、当社のプライベートネットワークへのアクセスを許可するものではありません。APIは、ホスト名リテラルまたはDNS解決がRFC 5735、6598、またはIPv6の予約ブロックに該当するターゲットを拒否するようになりました。第2の防御線として、すべてのバックエンド製品で同じチェックが実行されます。
表面上は何も変わりません。内部ネットワークへのプローブのクラスを、TCPハンドシェイクが完了する前に遮断します。
ブログに独自のソーシャルプレビューを追加、ページネーションを修正
すべてのブログ記事において、記事のタイトルと抜粋がブランドカード上にレンダリングされた独自のOpen Graph画像が生成されるようになりました。foura.ai/blog/...のリンクをDiscord、LinkedIn、Slack、またはTwitterに貼り付けると、一般的なフォールバックではなく、記事固有のプレビューが表示されます。
ブログインデックスのページネーションが静かに破損していました。「Older」ボタンを押すと、ページ1に戻されていました。パスベースのURL（/blog/page/N/）で再構築し、スマートウィンドウ付きの番号付きナビゲーションを追加し、ページ分割されたシリーズに対して適切なrel=prev/nextリンクタグを追加しました。古い?page=NのURLは新しい形式に301リダイレクトされるため、これまでにクロールされたデータが失われることはありません。
内部の仕組み
Model Context Protocolに対応するすべてのLLMツール向けに、当社のMCPサーバーがmcp.foura.aiで稼働を開始しました。認証は、REST APIに対して使用するのと同じpk_live_... Bearer tokenです。これにより、3つの製品がツール（Single、Proxy Finder、Browser）として公開され、いくつかのプロンプトも提供されます。FourAをClaude CodeやMCP対応のエージェントに組み込んでいる場合、ローカルブリッジを実行する必要はなくなります。
以前のプレイグラウンドが不十分だったためにダッシュボードの利用を控えていた方は、ぜひ今週お試しください。これは、APIターゲットに対して何か問題が発生した際に、現在私たち自身が使用しているインターフェースです。