よくある質問

jp402 は、JPYC（Polygon）で支払える x402 リソース（API・コンテンツ・商品）を見つけるためのディスカバリー scanner です。jp402-registry という公開台帳を「真実の源」として読み込み、一覧・選別・詳細表示します。 独自のデータベースは持たず、台帳を読んで見せることに徹した軽量なアプリです。

いいえ。有志による非公式プロジェクトで、JPYC 株式会社とは資本・運営上の関係はありません （「JPYC」は同社の登録商標です）。”jp402” は x402（HTTP-native 決済プロトコル）を JPYC 向けに準拠拡張した呼称であり、特定企業の製品名ではありません。

既存の汎用 x402 エクスプローラが Base / Solana・USDC に最適化され、Polygon を構造的に外している （チェーンセレクタからの削除など）ためです。jp402 はその「汎用が降りた空白」だけを取り、 JPYC のホームである Polygon に集中することで、他にない発見体験を提供します。 全チェーン対応や網羅性の競争は意図的に追いません。

ディスカバリーの宣言フォーマットの正典を OpenAPI（/openapi.json）に寄せ、 既存の支配的な x402 エクスプローラ（x402scan）の discovery 仕様に準拠しているためです。理由は主に次の通りです。

① 形式そのものは差別化要因ではない。宣言フォーマットは誰でも複製できるため、独自仕様に賭ける意味がありません。 支配的なツールの規約に相乗りした方が、売り手の採用障壁が下がり、エコシステムの合意（相互運用性）が積み上がります。 jp402 は「形式は相乗り、コンテンツ（JPYC / Polygon + 経理連携）で差別化」という方針です。

② 寛容な reader（Postel の法則）。OpenAPI を優先しつつ、Bazaar 形式 （.well-known/x402-catalog.json）など他形式も受け入れ、最後は実際の 402 応答で確定します。 ひとつの規約に依存して壊れないための保険です。

③ 日本固有の要件を綺麗に隔離できる。価格・通貨は x-payment-info、 T 番号や適格請求書などは x-jp402 拡張に分けて記述します。汎用エージェントは標準部分だけ読んで動作でき、 将来 x402 の公式な地域拡張が出れば差し替え可能な粒度に保ってあります。

④ 登録の単位が「発行者の openapi.json 1 本＝1 PR」で閉じる。記事ごと課金のような細かいリソースも、 自分の openapi.json の中の paths（operation）として動的に表現でき、台帳（registry）側を都度書き換える必要がありません。 受取先（payTo）を発行者で 1 つに揃えることで、信頼（着金実績）も 1 本に積み上がります。

いいえ。jp402 は 「載る（listing）」と「信頼される（trust）」を別レイヤーとして扱います。 準拠ファイルを置けば誰でも載れますが、それは推薦を意味しません。各リソースには着金実績などの 信頼シグナルを透明に表示し、利用者・エージェントが自分で判断できるようにすることが scanner の役割です。

jp402（本サイト）と jp402-registry（台帳・標準）はいずれも GitHub で公開しています。台帳は誰でも読める JSON 形式で、 他のツールからも参照できる公共のデータ源として運用しています。

jp402-registry に opt-in 登録（PR）するだけです。自分のドメインに /openapi.json（有料 operation に x-payment-info と x-jp402 を付けた OpenAPI）を publish し、 その URL を台帳（registry.json）に openapi_url として 1 行 PR で追加します。 CI が「スキーマ準拠」と「402 応答が生きているか」を客観的にチェックし、問題なければ掲載されます。掲載は無料です。 （旧 Bazaar 形式の .well-known/x402-catalog.json も後方互換として受け付けます。）

フォーム送信より PR の方が手間がかかるのは事実です。それでも PR を採るのは、公開された「合意」そのものが jp402 の中核的な価値だからです。

運営が送信内容を自前のデータベースに保存する方式にすると、「載せる / 載せない」を運営が握る 中央集権的な台帳になり、jp402 が避けたい構造（一社の都合でチェーンや登録が外される）を 自分で再生産してしまいます。スクレイプやコピーで複製できるデータは差別化になりませんが、売り手が能動的に opt-in した同意の蓄積（公開 PR）は、レイヤーと売り手の合意でしか 作れない複製不能な資産です。

PR 方式なら台帳は誰でも読める公開 JSON のまま保て、他のツールからも参照・fork できる 公共のデータ源になります。運営は可否を判断せず、CI が客観チェックするだけ （承認ではなく疎通検査）です。

手間は「DB 化（＝この価値を捨てる）」ではなく「PR を出しやすくする」方向で下げています。 登録ページにはプロンプトをコピーするだけのエージェント向け 2 ステップ登録を用意し、 AI エージェントに PR の作成そのものを任せられるようにしています。

審査による可否判断はありません。運営が「載せる / 載せない」を決める中央集権的な台帳にはしない方針です。 能動的な opt-in（公開 PR）と、既知の悪性のみを除外する denylist で運用します。 手数料も当面いただきません。

x-jp402 仕様には invoice 区画があり、登録番号（T 番号）や適格請求書発行事業者かどうかを記述できます。 現状は自己申告値の表示で、国税庁の適格請求書 Web-API による実在検証（verified）は 順次対応していく予定です。それまでは「T 番号あり（要実在検証）」のように明示します。

2 通りあります。(1) トップページの「買い手エージェント向け」セクションにあるプロンプトをコピーして、 お使いのエージェント（Claude / ChatGPT / kova / 自作 agent 等）に貼り付ける。 (2) list API GET /api/services を直接呼ぶ。 返り値の services[] から registered かつ信頼度の高いものを選び、 各リソースを x402（HTTP 402）フローで取得して JPYC 決済します。 yen402-mcp を使えば、MCP 経由でこの API を自動的に参照します。

Polygon 上の JPYC 着金を Alchemy 経由でオンチェーン実測しています。 台帳メタデータ（何のリソースか・JPYC 建てか・T 番号の有無）は registry 由来、 実績シグナルはチェーン由来で、両者を突き合わせて「説明つき・実績裏付き」の発見にします。 実測キーが未設定の環境では、デザイン確認用のサンプル表示になります。

permissionless に載れる以上、詐欺的なリソースも準拠ファイルさえあれば掲載され得ます。 ただし allowlist（許可制）は中央集権の再生産になるため採りません。代わりに、payTo（受取先）はオンチェーンの事実なので、着金実績ゼロやアドレス不一致は露見し、 信頼シグナルで自然に下位へ沈みます。既知の悪性は denylist で除外します。 最終的な支払い判断は、買い手側のポリシー（支出上限など）と併用してください。