wallcheck

wallcheck

エージェントに URL を指定するだけで、実際に何が妨げているのかを証拠付きで確認できます。

0.5.0：出荷準備レビュー（Wave 9 のリリース候補）で最終版として確定しました。まだ公開されておらず、ローンチ保留は継続中です。何が証明され、何が未証明なのか、出荷判断にまだ必要なものについては、campaign/LAUNCH-READINESS.mdをご覧ください。

エージェントはボット対策の壁で、何も告げずに動作を止めます。フェッチが 403 を返し、ブラウザーセッションは環境を次々と切り替え、アップロードは開始すらしません。それでも、何が動作を止めたのか、誰の壁だったのかを説明し、証拠を示せるものはありません。wallcheck は URL を一度だけ正直にプローブし、エージェントが実際に遭遇したものを、OPEN、CHALLENGED、WALLED、LOGIN_GATED、RATE_LIMITED、UNREACHABLE に分類します。さらに、ベンダー（Cloudflare、PerimeterX、DataDome、Akamai、Imperva、AWS WAF、Microsoft Azure WAF、Kasada、AWS CloudFront）と、それを裏付ける正確なシグナルも示します。

判定に LLM は一切使いません。分類器は (status, headers, body) のみに基づく決定論的な純粋関数です。同じレスポンスには同じ判定を返します。そのため、CI、インシデントレポート、公開のボット対策インデックスで安全に結果を利用できます。

**v0.2 の新機能：**エージェントの署名付き ID に対応しました。wallcheck keygen は RFC 9421 署名鍵を生成し、wallcheck probe <url> --sign key.json は実際の HTTP メッセージ署名（hmac-sha256、tag="web-bot-auth"）をプローブに付加します。これにより、エージェントは匿名のボットではなく、名前を持つようになります。wallcheck verify-server --key key.json は、正しく署名されたリクエストのみを受け付ける小さなサーバーを実行するため、サイト所有者は自分の側をテストできます。hmac-sha256 はエージェントと所有者の双方向セットアップに対応し、Ed25519（v0.4）は公開ディレクトリのケースに対応します。詳しくはvalidation/wave2/SIGNING.mdをご覧ください。

**0.5.0 の新機能：**所有者側の監査が MCP サーバーに audit ツールとして加わりました（1 回の呼び出しにつき、正直な GET を最大 10 回実行し、probe_url と同じ制限付きフェッチ方式を採用）。Wave 9 のドキュメントレビューでは、測定結果と食い違っていた古い数値をすべて修正し、Wave 9 の確定時点でテスト数は 120 件でした。Wave 10～17 で 428 件になりました（Wave 17 の監査時点では 423 件でしたが、W17-007 のライブ修正で 5 件のフィクスチャが追加されました。詳しくはvalidation/wave17/STABILITY-12.mdをご覧ください）。Wave 18 のバッテリー v10 と W18-007 のライブ修正で 481 件になりました。Wave 19 のバッテリー v11 で 532 件、Wave 20 のバッテリー v12 で 571 件、Wave 21 のバッテリー v13 で 608 件、Wave 22 のバッテリー v14 で 638 件、Wave 23 のバッテリー v15 で 674 件、Wave 24 のバッテリー v16 で 710 件、Wave 25 のバッテリー v17 で 747 件、Wave 26 のバッテリー v18 で 788 件、Wave 27 のバッテリー v19 で 831 件になりました。

**v0.5 の新機能：**分類器は、Wave 5 の拡張で調査した領域に対応しました。Microsoft Azure WAF、Kasada、AWS CloudFront の検出、Akamai の参照トークン拒否ページ、ステータス 444 の判定ルール（リクエストが破棄された場合は拒否であり、決して OPEN ではありません）、そしてページが自身のフォーム用に reCAPTCHA／hCaptcha ローダーを埋め込んでいるだけなのに誤ってチャレンジと判定されるケースの解消です。Wave 5 で見つかった 5 件の不具合はすべて、実際のキャプチャを使ったテストファーストの方法で修正しました（PROBLEMS.md）。インデックスは 500 サイトを掲載するようになりました（Wave 6～7 の拡張と、Wave 18 の 500 行目）。また、Wave 5 では出荷済みの署名機能を使って、署名あり・なしの初の実験を行いました（SIGNED-EXPERIMENT.md）。未登録の鍵では、どの判定も変わりませんでした。これは、キャンペーンの ID 機能が変えるべき測定済みのベースラインです。サイト所有者向けの修正キットでは、監査結果をベンダー確認済みの修正手順に変換できます。 v0.4 の新機能： Ed25519 署名付き ID。署名器は純粋な Python 標準ライブラリで RFC 8032 に準拠した Ed25519 を実装しました（RFC 8032 §7.1 の公式テストベクターとの照合済み）。これにより、wallcheck keygen --alg ed25519 でディレクトリと互換性のある Web Bot Auth キーを生成できます。公開鍵は /.well-known/http-message-signatures-directory ドキュメントで公開され、probe --sign はキーのアルゴリズムを自動検出します。 Wave 4 ではインデックスの 3 つ目のデータポイントも取得し、インデックスに登録された全 154 ドメインを対象に、署名付きエージェントディレクトリの初回調査を実施しました （DIRECTORY.md）。

v0.3 の新機能： サイト所有者向け監査。wallcheck audit <domain> は、6 項目のチェックを通じてサイトのエージェントアクセス状況を評価します。robots.txt の AI エージェント向け指示、llms.txt の妥当性（HTML のソフト 404 は 不合格）、サイトマップ、フィードの検出、API の検出、Web Bot Auth の署名付きエージェント対応状況です。各項目を根拠と具体的な修正方法とともに PASS／WARN／FAIL で示し、A〜F の評価にまとめます。初回の実サイト監査 （validation/wave3/AUDITS.md）では、私たち自身のサイトが D／F 評価となりました。他の誰かのサイトより先に、自分たちのサイトに実際の改善作業が必要だと監査で判明しました。v0.3 では分類器に AWS WAF の検出も追加され、調査結果が Bot Wall Index の作業用一覧に統合されました（Waves 6〜7 の拡張後、499 サイト）。

対象外

wallcheck は、CAPTCHA の解決、フィンガープリントやユーザーエージェントの偽装、壁・レート制限・アクセス制御の回避または突破を決して行いません。プローブは自身を識別します（ユーザーエージェント wallcheck/<version>）。重要なのは、検出＋根拠＋標準です。エージェントが名前を特定できる壁はバグ報告につながります。署名付きエージェント ID（Web Bot Auth、RFC 9421。v0.2 でプロトタイプをリリース済み。SPEC.md を参照）は、エージェントがそもそも匿名ではなくなるための仕組みです。

使い方

CLI

# No install needed beyond Python 3.11+ (standard library only):
PYTHONPATH=src python3 -m wallcheck probe https://www.upwork.com

# Or install the package:
pip install .   # then: wallcheck probe <url> [--json]

出力例（実際の実行結果全体は DOGFOOD.md を参照）：

https://example.com -> OPEN
  status: 200
  vendor: none detected
  elapsed: 87ms
  evidence:
    - STATUS_200

終了コード：OPEN の場合は 0、それ以外の判定では 1、使用方法のエラーでは 2 です。CI に対応しています。--json は次の安定した単一オブジェクトを出力します： {url, final_url, status, verdict, vendor, evidence[], elapsed_ms, redirect_chain[]}。

署名付きプローブとサイト所有者側での検証：

PYTHONPATH=src python3 -m wallcheck keygen --out wallcheck-key.json
PYTHONPATH=src python3 -m wallcheck probe https://example.com --sign wallcheck-key.json
PYTHONPATH=src python3 -m wallcheck verify-server --key wallcheck-key.json --port 8799

自サイトのエージェントアクセス状況をサイト所有者側で監査する場合：

PYTHONPATH=src python3 -m wallcheck audit example.com [--json]

7 項目のチェック（robots.txt、llms.txt、サイトマップ、フィード、API、署名付きエージェント対応状況、セキュリティ連絡先）により、各項目を PASS／WARN／FAIL と根拠、修正リストとともに示し、評価を付けます（セキュリティ連絡先のチェック追加後は 14 点満点。それ以前の評価は 12 点満点です）。評価が A／B の場合は終了コード 0、それ以外は 1 です。

サイトが配信するページの情報露出スキャン（オプトイン、同一ページを 1 回だけ取得）：

PYTHONPATH=src python3 -m wallcheck probe https://example.com --exposure [--json]

ページ自体が匿名の訪問者に渡す、キーのような情報を分類します。CANDIDATE_EXPOSURE（公開されるべきではないサーバー秘密情報の分類）、PUBLIC_BY_DESIGN（フロントエンドキー、アプリ ID）、VISITOR_TOKEN（短期間有効な JWT）です。検出結果にはフィンガープリントのみを含め、パターン、分類、長さ、SHA-256 のプレフィックスを示します。値そのものは含めません。手法と開示ルールについては campaign/EXPOSURE-LAYER.md を参照してください。

判定

判定	意味
OPEN	配信済み。エージェントが読み取れます。
CHALLENGED	対話型の人間確認チャレンジが提示されました（Cloudflare の「Just a moment」、CAPTCHA ページなど）。対話できないエージェントはここで停止します。
WALLED	強制ブロックページ（「Sorry, you have been blocked」、拒否ページ、本文のない 403 など）。チャレンジすら提示されません。
LOGIN_GATED	ログイン用の壁にリダイレクトされたか、そこでページが配信されました。コンテンツは存在しますが、認証の背後にあります。
RATE_LIMITED	より強い壁の兆候を伴わない HTTP 429。壁ではなく、リクエストの制限です。
UNREACHABLE	取得に失敗しました（DNS／TLS／タイムアウト）または 5xx です。壁であるとは判定しません。

MCP サーバー

npm から利用する場合（インストール不要。PATH 上に Node 20 以降と Python 3.11 以降が必要です。 このパッケージは、同じ Python 標準ライブラリコードを呼び出す薄いランチャーです）：

npx -y @reneturcios/wallcheck mcp
# the same shim also forwards the CLI:
npx -y @reneturcios/wallcheck probe https://example.com

または、このリポジトリから利用します：

PYTHONPATH=src python3 -m wallcheck mcp
# or, installed: wallcheck-mcp

ツール：

• probe_url(url, timeout?)：ライブフェッチを行い、分類オブジェクトを返します。
• classify(status, headers, body)：自分で取得したレスポンスをオフラインで分類します。ネットワークは使用しません。
• scan_exposure(url, timeout?)：ライブフェッチを行い、分類オブジェクトと露出セクション（ページが提供するキーのような情報を分類し、フィンガープリントのみを記録）を返します。probe_url と同じ規律で、正直な GET を 1 回だけ行います。プローブの 64 KB の本文サンプルを対象とします。
• audit(domain, timeout?)：所有者側のエージェントアクセス監査を行い、評価とチェックごとの PASS/WARN/FAIL を返します。probe_url と同じ制限付きフェッチの規律で、対象ドメインに対して正直な GET を最大 11 回行います。

いずれかのコマンドを実行する stdio サーバーとして MCP クライアントの設定に追加するか、GHCR イメージ ghcr.io/cloudcorprecords/wallcheck:0.5.0 を使って Docker 経由で追加します（Dockerfile を参照）。

テスト

完全にオフラインです。記録済みのフィクスチャで純粋な分類器をテストします：

python3 -m unittest discover -s tests -v

エビデンスの提供

validation/ 以下にある取得済みレスポンスはエビデンスです。公開前にエビデンスをサニタイズします。新たに取得したデータ一式には、まず python3 scripts/scrub_captures.py を実行してください。 提供ページには、他のサイトのキー情報が埋め込まれています。スクラバーの墨消しテーブルは露出スキャナー自身のパターンテーブルなので、スキャナーが検出できるものはすべてスクラバーが削除します。非公開の開示資料（validation/monster-finding/）と未公開の候補調査結果（validation/exposure-wave*/）は、どちらも意図的に gitignore されており、決して公開されません。

関連プロジェクト

Rene Turcios によるプロジェクトです。greenlight（問題を主張する前に、エビデンスに基づいて GO/NO-GO を判断する）と mcpaudit（あらゆる MCP サーバーを採点付きで監査する）の姉妹プロジェクトです。共通の基本方針は、決定論的なコア、名前の付いた問題、雰囲気よりエビデンスを重視すること、そして何かを主張する前に実際の対象で実地検証することです。

製品仕様、ロードマップ（Web Bot Auth 署名は v0.2 のプロトタイプとして提供済み、所有者側の監査は v0.3 で提供済み）、Bot Wall Index の計画については SPEC.md を参照してください。検証ラウンドは validation/ にあります。Wave 2 では 77 のプラットフォームパスの深度プロービング（PATHS.md）と署名プロトタイプ（SIGNING.md）を追加しました。Wave 3 では安定性の再プローブ、154 サイトのインデックス、監査の最初のライブ実行（AUDITS.md）を追加しました。Wave 4 では安定性データの 3 つ目の測定値（STABILITY-2.md）、署名済みエージェントのディレクトリ調査（DIRECTORY.md）、Ed25519 を追加しました。Wave 5 では対象範囲の拡大、署名ありと署名なしの実験、所有者向け修正キットを追加しました。Wave 6 では 25 の敵対的な形状に対する分類器の耐性を強化しました。Wave 7 ではインデックスを 499 サイトに拡大し、2 回目のディレクトリ調査（採用例 4 件）と監査一巡を実施しました。Wave 8 ではさらに 46 のプラットフォームでパスを調査し、front-doors ファイルの対象を 65 プラットフォームに拡大しました。Wave 9 では 0.5.0-rc を確定し、監査 MCP ツールを追加しました。Wave 10〜28 では、さらに 19 回の安定性ラウンド（ラウンド 6〜24）と、バージョン 2〜20 の敵対的テスト一式を実施し、テストスイートを 885 テストに拡大して、リリース保留を継続しました。

ライセンス

MIT：詳細は LICENSE を参照してください。