破壊的変更の検知は、「無料で止まる入力検証」→「402 の宣言」→「有料の差分・互換レポート」の3層に分かれます。今回測った4経路はどれも未払いでは 402 を返し、宣言価格は4本とも 0.02 USDCでした。つまり検知の中身は買うまで返りませんが、入口が正しいか・課金前に何を弾くかは無料で確かめられます。
実測で差が出たのは不正入力の扱いです。/compat-check・/contract・/changes は壊れた入力を課金前に 400 で返しました。一方 /compat はJSON として壊れている場合だけ 400 で、schema が正しい JSON Schema でなくても402 のまま通りました。「無料で弾かれる」と期待してパイプラインを組むと、/compat だけ課金されてから失敗します。
| 経路 | 方法 | 2回の応答 | 本文（2回とも同一） | payment-required | 応答時間 | 宣言価格（USDC） |
|---|---|---|---|---|---|---|
/compat-check | GET ?url= | 402 / 402 | 27,357 B | 5,728 B | 683 / 445 ms | 0.02 |
/compat | POST JSON | 402 / 402 | 21,172 B | 3,120 B | 306 / 154 ms | 0.02 |
/changes | GET ?from=&to= | 402 / 402 | 20,238 B | 2,804 B | 283 / 161 ms | 0.02 |
/contract | GET ?url= | 402 / 402 | 26,872 B | 5,528 B | 288 / 187 ms | 0.02 |
同時刻の無料面は /openapi.json 200・175,454 B・168 ms・58 paths、/product.json 200・683,011 B・385 ms、/contract/sample?url=… 200・2,679 B・151 ms、/health 200・2,089 B・163 ms、/status.json 200・22,156 B・7,869 ms でした。status.json の初回は他より2桁近く遅く、これは集計処理のコストで、経路の生死とは別です。
402 の形は4経路とも同じで、本文 x402Version=1・accepts[0] はscheme / network / maxAmountRequired / resource / description / mimeType / payTo / maxTimeoutSeconds / asset / extra の10項目、maxAmountRequired=20000（6桁で 0.02 USDC）、network=base、maxTimeoutSeconds=60。ヘッダ側は V2 表記です。
支払いを伴わない不正入力を7通り投げました。結果は5件が 400（本文 126〜570 B・132〜156 ms）、2件が 402 です。
\n| 送ったもの | 応答 | 本文 | 応答時間 | error |
|---|---|---|---|---|
/compat-check?url=not-a-url | 400 | 271 B | 147 ms | invalid_url |
/compat-check?url=http://127.0.0.1:8080/x | 400 | 351 B | 147 ms | blocked_target（loopback_address） |
/contract?url=not-a-url | 400 | 271 B | 156 ms | invalid_url |
/changes?from=2026-99-99&to=2026-01-01 | 400 | 570 B | 132 ms | invalid_period |
POST /compat（{not json） | 400 | 126 B | 139 ms | invalid_json |
POST /compat（schema:\"nope\"） | 402 | 21,172 B | 151 ms | —（課金宣言） |
POST /compat（schema:{type:\"object\"}） | 402 | 21,172 B | 163 ms | —（正常） |
つまり /compat の課金前検証は「UTF-8 の JSON オブジェクトか」までで、schema が JSON Schema として意味を持つかは見ていません。自分の連携では、課金前に自分の側で schema の型を検査するのが安全です。additionalProperties や required の綴り間違いは 402 を通り、0.02 USDC を払った後に unsupported_input になり得ます（この先の応答は未確認）。
なお /compat-check は URL の形式だけでなくループバック宛を課金前に拒否しました。SSRF 対策としては妥当ですが、社内ホストの互換性を測りたい買い手は、この経路では測れないという制約にもなります。
無料の /contract/sample?url=… は 200・2,679 B・18項目を返し、出力契約の弱点まで宣言します。当方の /gas を対象にした実測では error_shape_declared=false、weakness[0].code=declared_fields_are_schema_keywords でした。内容は「properties が納品の実フィールド名ではなく JSON Schema のキーワード（type・example）で埋まっている」という指摘です。
これは検知器の使い方に直結します。変更前後で properties を比べれば差分は出ますが、その差分が「利用者が使うフィールドの変更」とは限らないからです。契約が弱い相手では、契約の差分だけを破壊的変更の証拠にしないのがよく、実際の 200 の本文（買った納品）と突き合わせる必要があります。
サンプルは無料なので、本番の検知を組む前に、対象の契約がどの程度「読める」かを 1 回 0 円で確認できます。18項目のうち sample と sample_note が無料部分で、paid_route と sample_source が購入先を示します。
無料の /status.json（22,156 B）で4経路の納品記録を見ると、/compat 2件（最終 2026-10-13）、/compat-check 1件（最終 2026-10-15）、/contract 2件（最終 2026-10-17）、/changes は 0件（data_status=no_data）でした。4本とも 402 は返りますが、買われた回数は同じではありません。
402 が返る＝検知が実績あり、ではありません。検知器を選ぶときは、「今払えるか」を 402 で、「過去に納品されたか」を /status.json で分けて見てください。
" }, { "見出し": "この実測で分からないこと", "html": "/compat-check の verdict や /changes の events[] の中身・精度・鮮度は未確認です。数字はすべて「400 が返るところ、402 が返るところ、無料の 200 が返るところ」までです。api breaking change detector をタイトルに置いただけで、順位は測っていません。課金前に何を弾くかの全体は /ja/x402-usage、402 の読み方は /ja/is-x402-endpoint-alive、スキーマ変更の4経路は /ja/schema-change、カタログの差分は /ja/catalog-diff に実測でまとめています。仕様の全体は /openapi.json（58 paths）、出力契約の無料サンプルは /contract/sample で読めます。