PageSift は Web ページや PDF・Office 文書などを Markdown と構造化データに変換する、Rust 製のコンテンツ抽出エンジンです。1.2 では新しい crate pagesift-itna を追加しました。itna（名前は "anti" の逆さ読みです）は、アクセス障壁 —— レート制限、ログイン壁、ブロック、JavaScript チャレンジ —— に遭遇したときの「回復経路」を担います。

最初に立場をはっきりさせておきます。itna はデフォルトでオフです。有効化は設定ファイルに [itna] enabled = true と明示した場合だけ。そしてこの記事で書くのは「どうやって壁を破るか」ではなく、むしろ逆の話です。いつ諦めるか、いつ一歩だけ進むか、その規律をどうコードに固定したか —— それが itna の本体です。

1. いきなりリトライしない。まず分類する

障壁に当たったときの最悪の初手は、反射的にブラウザを起動して再試行することです。相手が「来るな」と言っているのか、「少し待て」と言っているのか、「本人確認が必要」と言っているのかで、正しい対応はまったく違います。

itna はまず HTTP 実行の結果を分類します（pagesift-itna の classify）。

結果	分類
429 / 503 + Retry-After	Throttled（制限中）
ログイン壁 / 401	Login
403 / ブロック検知	Blocked
チャレンジ / CAPTCHA 検知	Challenge

そして分類ごとに、次に取れる行動を型で縛ります。エスカレーション（ブラウザ実行への移行）を許可するのは Blocked と Challenge のときだけです。Throttled と Login は、コード構造の時点でブラウザに進めません。テストにも throttling_and_login_never_escalate という、そのままの名前の断言があります。

これは設計として当然の判断です。429 は「ペースを落とせ」という合図であって、ブラウザで押し切る理由にはなりません。ログイン壁の向こう側は認証情報の問題で、レンダリングの問題ではありません。

2. エスカレーションの規律：最大で一度だけ、同じ出口で

Blocked / Challenge の場合でも、無制限に粘ることはしません。試行管理（Attempts）の上限は生成時に固定されています。

Attempts::new(timeout, 2, 1)

総試行は最大 2 回、そのうちブラウザ試行は最大 1 回。しかも 2 回の試行は**同じ egress（出口）**を使います。IP を変えて何度も叩く、という挙動は構造的に存在しません。

さらに、分類が Blocked / Challenge でもエスカレーションが許可されない条件があります（browser_allowed の門番）。

engine = "http" と明示されたリクエスト
任意のカスタムヘッダを持つリクエスト
認証情報を含む「センシティブ」なリクエスト（後述）
スクリプト発見モードのリクエスト

つまりエスカレーションは「素の公開ページ取得」に対してだけ開かれた、狭い経路です。

3. ネットワーク予算は共有し、尽きたら失敗する

ブラウザに進んだ後も、好きなだけリクエストを飛ばせるわけではありません。itna は 1 リクエスト全体に 1 つのネットワーク予算（NetworkBudget）を持たせます。内訳はナビゲーション 16 回、リソース 128 回、そして HTTP 側とブラウザ側で共有する単一の deadline です。

HTTP 側はリダイレクトのたびに、ブラウザ側は CDP のリクエスト傍受層でサブリクエストのたびに、この予算を消費します。尽きたらどうなるか —— こっそり続行するのではなく、エラーとして失敗します（fail-closed）。予算外の通信が「なかったこと」になる設計にはしていません。

そして全試行の軌跡 —— どのエンジンで実行し、どういう結果だったか、ブラウザ実行が何回あったか —— は、結果ドキュメントの metadata.pagesift.itna（失敗時はエラーの詳細内）に記録されます。回復経路を通ったかどうかは、後から必ず検証できます。

4. セッションは四つ組で隔離する

回復経路でブラウザを使う以上、セッション（Cookie 等の同一性）の扱いが安全の核心になります。itna のアイデンティティプールは、セッションを以下の四つ組をキーにリースします（pagesift-policy の IdentityKey）。

owner × origin × egress × fingerprint

リース取得時には、リクエスト先 URL の origin がキー内の origin と完全一致することも検証します。owner が違えば、同じサイトでもセッションは絶対に混ざりません。owner を持たない匿名リクエストはプールに入らず、使い捨てセッションになります。

そして共有そのものが禁止されるケースがあります。

Cookie / Authorization / Proxy-Authorization ヘッダを含む、またはサイト認証情報が設定されたリクエスト（センシティブ判定）
任意のカスタムヘッダを持つリクエスト

センシティブ判定については、正直に書くと、当初の想定より実装のほうが厳しくなっています。「認証情報付きは共有しない」という方針を実装したら、結果としてカスタムヘッダが 1 つでもあれば共有もエスカレーションも両方止まる形になりました。安全側に倒れた結果なので、そのまま採用しています。

5. プロキシは「検証済みトンネル」でしか通らない

フィンガープリント付きトランスポートがプロキシを経由する場合、itna は対象ホストをローカルで解決し、SSRF チェックを通した IP アドレスだけをプロキシに渡します。プロキシ側で名前解決をさせる方式（SOCKS5 のリモート解決相当）も含め、対象が検証を通る前にトンネルを開くことはありません。socks5h のような指定でも解決はローカルで行います。

TLS の SNI と HTTP の authority には元のホスト名が残ります。プロキシが受け取るのは「検証済みの IP へのトンネル」だけです。

そして重要なのは失敗時の挙動です。プロキシやトンネルの確立に失敗したら、それはエラーとして返ります。通常のリクエストや直接接続への暗黙のフォールバック（ダウングレード）は存在しません。「プロキシが落ちたから素通しで取りに行く」は、この手の機能では最も起きてほしくない事故だからです。

6. Cookie の引き渡しは、正確な origin と Strict が前提

HTTP 実行からブラウザ実行へ移る際、HTTP 側で得た Cookie をブラウザへ引き渡す機能があります。ここも条件は厳しく固定しました。

引き渡し先は正確な origin に限定され、ホストだけが一致する別スキーム・別ポートへの持ち出しは傍受層で遮断します（唯一の例外は標準的な http:80 → https:443 への昇格のみ）
インポートされる Cookie は一律 SameSite=Strict で設定します（セッションストアが SameSite を保持しないため、橋渡しした Cookie がクロスサイトのサブリソースに付いて出ていかないようにする措置です）
HTTP 側フィンガープリントの Chrome メジャーバージョンと、実行中ブラウザのメジャーバージョンが一致しない場合、引き渡し自体を拒否します

「だいたい同じサイトだから」という曖昧な引き渡しはしません。

7. やらないこと

itna の設計で一番時間をかけたのは、やることより「やらないこと」の線引きです。

ハードウェア同一性は偽装しません。 ブラウザ実行時にやっているのは自動化マーカーの除去だけです。起動引数で Blink の automation マーカーを消し、ドキュメント開始スクリプトで navigator.webdriver を undefined にします。正直に書くと、そのスクリプトにはもう 1 つだけ、window.chrome が存在しない場合に空のオブジェクトを補う処理があります。これはマーカー層の補完であって、UA や GPU、CPU コア数といったハードウェア・同一性パラメータの捏造はしていません。

CAPTCHA は解きません。 対話型 CAPTCHA ウィジェットのあるページは待たずに離脱し、ACCESS_BARRIER エラーに needsHuman: true を付けて返します。ソルバーは内蔵していませんし、今後もその予定はありません。解くべきなのは機械ではなく人間だ、という線引きです。なお、対話型でない JavaScript チャレンジについては、最大 8 秒（かつリクエストの timeout 以内）の有界待機をします。

ブラウザ実行は Chrome / CDP 系だけです。 通常のブラウザ描画では Lightpanda → moli → Chrome のエンジン連鎖を使いますが、itna の経路ではこの連鎖を意図的に切り、Chrome に固定します。理由はシンプルで、マーカー除去も、フィンガープリントも、Cookie の引き渡しも、すべて Chrome の意味論の上で検証しているからです。検証していないエンジンに回復経路を流すくらいなら、Chrome がない環境ではエラーを返すほうを選びました。

8. 証拠の範囲について、正直な注記

最後に、このリリースの証拠の範囲を明記します。

itna の挙動は、すべてローカルに構築した制御可能なフィクスチャに対するリリーステストで検証しています。実在の本番サイトや WAF に対する通過率は、計測していませんし、主張もしません。「どのサイトが通るか」を謳う代わりに、分類・規律・予算・隔離といった挙動の約束がコードとテストで固定されていることを示すのが、このリリースの証拠です。

ついでに書くと、README の速度・品質の数値は 1.1.0 時点の実測のままで、1.2 では再計測していません。速くなったとは言いません。

おわりに

itna は「反・○○」ではなく、"anti" を逆に読んだだけの名前の通り、発想も逆向きです。壁を破る道具ではなく、壁の前での振る舞いに規律を持たせるための仕組み —— 分類して、上げるのは一度だけ、予算が尽きたら止まり、同一性は混ぜず、通れなかったことは記録に残す。抽出エンジンが長く使われるには、通す力より先に、この種の自制が必要だと思っています。

GitHub: https://github.com/YOLOW92/pagesift
crates.io / npm でも公開しています。PageSift 本体は AI / LLM パイプライン向けに、Web・PDF・Office・メール・電子書籍などを Markdown と構造化データへ変換するエンジンです。