NessGate

NessGate

NessGate にドメインとクライアントの機能を伝えると、そのクライアントがどのように接続できるか、そして何が不足しているかを教えてくれます。 1 回の呼び出しで、「このドメインを使いたい」という情報を、根拠を示した具体的な接続プランに変換します。使用するプロトコル、エンドポイント、トランスポート、そしてサービスが公開している認証情報を正確に示します。まだ接続できない場合は、サービスに不足しているフィールドを特定します。

curl -sX POST https://nessgate.com/connect/supabase.com \
  -H 'content-type: application/json' \
  -d '{"client":{"supports":[{"protocol":"mcp","auth":["oauth2","none"]}]}}'

{
  "domain": "supabase.com",
  "outcome": "credentials-required",          // ready | credentials-required | incomplete | no-compatible-method
  "connection": {
    "protocol": "mcp",  "transport": "streamable-http",
    "endpoint": "https://mcp.supabase.com/mcp",
    "auth": { "type": "oauth2",
              "authorizationEndpoint": "https://api.supabase.com/v1/oauth/authorize",
              "tokenEndpoint":         "https://api.supabase.com/v1/oauth/token",
              "scopes": ["projects:read", "database:write", "…"] }
  }
}
// → everything needed to connect is known; you just supply your own credentials
//   (which never touch NessGate). No scores; each field links back to its source.

推測はせず、正直な結果を 5 種類で示します。ready（認証情報なしですぐ接続可能）、credentials-required（必要な情報は揃っています。あとは独自のシークレットを用意するだけです）、incomplete（サービスの公開情報が不足しており、NessGate が不足しているフィールドを正確に示します）、broken（宣言された場所から応答がありますが、その内容が宣言自体と矛盾しています）、no-compatible-method（クライアントが扱える方法がありません）。リソースごとの結果を確認する場合は、/explore に ?readiness=1 を追加してください。ドメインが公開している情報の生の一覧を確認する場合は、従来のリゾルバー GET /discover/{domain} を使えます。こちらは変更なく、引き続き利用できます。

自分で作ればよいのでは？

作ることはできます。無理ではありませんが、永続的な作業になります。ドメインから実際に接続できる状態にするには、あらゆるディスカバリー標準（ARD、A2A、llms.txt、api-catalog、OpenAPI、ORD、host-meta、ANP、UCP、AID、MCP、GB/Z 185.4…）を読み込み、追跡する必要があります。さらに、それぞれの認証方式（OpenAPI のセキュリティスキーム、MCP OAuth のメタデータチェーン RFC 9728 → RFC 8414、A2A のカードスキーム）に対応し、サーバー固有の挙動、タイムアウト、リダイレクト、各ホップでの SSRF 対策を処理し、すべてを一つの形式に正規化したうえで、プロトコルの変更に合わせて対応を続けなければなりません。NessGate はそれらすべてを担い、必要に応じて読み取ります。検出したドメインやリソースのデータは保存せず、中立性を保ちます。これにより、互換性レイヤーではなく、エージェントを作ることに専念できます。無料のオープンソース（Apache-2.0）で、独立して実装できます。nessgate.com が消えても、各ドメインのファイルはそのドメイン上に残ります。

逆方向、つまり、受信する自動呼び出し元が何を宣言し、何を証明できるかを記述する実験的なパッケージが @nessgate/inspect（0.x）です。段階的で出所が明確な事実（claimed / cryptographically-verified / network-verified / directory-attributed）を扱い、判断もスコア付けも行いません。詳しくは docs/integrations.md §5 をご覧ください。

サービスを公開していますか？エージェントに見つかる前に、自分でテストしましょう。

npx @nessgate/resolver yourdomain.com    # exit 0 = agents can connect; otherwise it names the exact missing field

オープンな readiness 判定をローカルで実行します（報告内容が外部に送信されることはありません）。3 回観測し、厳格に判定します。不安定なエンドポイントは失敗となります。CI に組み込んで、公開情報から接続できる状態を保ちましょう。

https://nessgate.com で公開中 · 仕様 · 憲章 · API

_{NessGate は、ドメインがすでに公開している標準を読み取ります。それらの標準を定義することも、データを保存することもありません。常にドメインが権威を持ちます。}

利用方法

埋め込み可能なライブラリ — 依存関係がなく、対象ドメインから直接フェッチします（実行時に nessgate.com への依存はありません）。fetch が利用できる環境ならどこでも実行でき、Node、Deno、Workers、エージェントのランタイムに対応しています。（ブラウザーでも実行できますが、ブラウザーから読み取れるのは CORS ヘッダーを送信する 他の ドメインに限られ、ほとんどの .well-known ファイルは CORS ヘッダーを送信しません。そのため、ブラウザーから任意のドメインを解決する場合は、オープン CORS を送信する以下のホスト型エンドポイントを使用してください。）@nessgate/resolver として公開されています。

import { resolve } from "@nessgate/resolver";      // or "https://nessgate.com/resolver.mjs"
const { resources } = await resolve("example.com");

ホスト型エンドポイント — オープン CORS 対応、認証不要：

curl https://nessgate.com/discover/example.com

MCP — 同じ検索機能をツール（discover_domain）として https://nessgate.com/mcp で利用できます。公式 MCP Registry に com.nessgate/nessgate（ドメイン検証済みリモートサーバー）として登録されているため、MCP 対応クライアントから直接インストールできます。

統合する（約5行）

エージェントにドメインを渡せば、使うものが返ってきます。標準ごとのコードは不要です。これをツール、 検索ステップ、またはオンボーディングフローに追加します。

import { resolve } from "@nessgate/resolver";           // dependency-free, no key, no account
const { resources } = await resolve(domain);            // reads the domain directly
for (const r of resources)
  console.log(r.type, r.url, "←", r.sourceUrl);         // normalized record + where it came from
// each r: { source, type, url, sourceUrl } — pick the one your agent needs (OpenAPI, A2A, MCP, …)

SDK を使わない場合、ホスト型エンドポイントは HTTP GET を 1 回実行するだけです（GET https://nessgate.com/discover/{domain}。CORS はオープンで、認証は不要です）。また、MCP ツール discover_domain も同じ形式の結果を返します。新しい標準の追加は、上流に新しいアダプターを追加するだけです。統合方法を変更する必要はありません。

統合ガイドの全文 — ライブラリ、HTTP、MCP クライアントの設定（stdio のみのクライアント向け mcp-remote ブリッジを含む）：docs/integrations.md。

原則

NessGate は無料で中立的なインフラストラクチャです — 憲章をご覧ください。利用や閲覧に料金を請求することはなく、ランキングや掲載枠を販売することもありません（そもそも存在しません）。アカウントを保持せず、ドメインデータも保存しません。ドメインの情報は要求に応じて読み取ります（回答はエッジで最大 10 分間キャッシュされます）。クロールやインデックス登録は行わず、所有権や安全性について主張することもありません — ドメインが提供する情報を報告し、それぞれの情報源へのリンクを示します。仕様はオープンで、リファレンス実装は Apache-2.0 ライセンスです。 誰でも独自のリゾルバーを実行できます。nessgate.com が消えても、すべてのドメインのファイルはそのドメイン自体に残ります。

アーキテクチャ

• ステートレスな Cloudflare Worker が 1 つ（src/worker.js）あり、静的サイト（public/。run_worker_first を指定したアセットバインディング経由）、リゾルバー API、MCP サーバー、ドメインごとのページ、サイトマップを提供します。データベースはありません。
• リゾルバー（GET /discover/{domain} と、埋め込み可能な public/resolver.mjs）は、ドメインが公開している情報を読み取り、1 つの回答に正規化し、ドメインに直接アクセスします。データは保存しません。回答はその都度新たに計算され、エッジで 10 分間キャッシュされます。パリティテストにより、Worker とライブラリの正規化結果がバイト単位で一致すること、および packages/resolver/index.mjs（npm パッケージ）と public/resolver.mjs の内容がバイト単位で一致することを保証します。
• **アダプターアーキテクチャ — 4 つのディスカバリーチャネル。**サポート対象の標準ごとに小さな独立したアダプターがあり、各アダプターは 4 つのチャネルのいずれかを使ってドキュメントを見つけます。
  • well-known — ドメイン上の固定パス（または複数のパス）に GET します：llms.txt、ard-catalog（ARD / ai-catalog）、a2a-agent-card（A2A）、api-catalog（RFC 9727）、ai-info.json、openapi、ord（Open Resource Discovery）、awp（ドラフト）、host-meta（RFC 6415）、anp（Agent Network Protocol /.well-known/agent-descriptions）、ucp（Universal Commerce Protocol /.well-known/ucp）。
  • link-rel — ホームページの <link rel="ard"> を解析し、リンク先を GET します（ard-link）。
  • robots — /robots.txt の Agentmap: ディレクティブを解析し、リンク先を GET します（ard-agentmap）。
  • dns — _agent.<domain> に対して DoH TXT ルックアップを行います（aid：v=aid1;u=<uri>;p=<proto>;a=<auth>）。 ARD：NessGate は、ARD の規範的なドメイン解決を実装しています。/.well-known/ard.json を取得し、<link rel="ard"> 関係を遵守します（ARD v0.91 §5.1 ではどちらも**必須（MUST）**です）。さらに、robots の Agentmap: サーフェスにも対応しています。ARD の任意のページ内 JSON-LD は、一般的なウェブクローリングでのみ検出されますが、NessGate はクローリングを行いません。ARD の DNS メカニズムは §5.1 で説明されていますが、まだ規範的に仕様化されていません（レコードタイプもパラメーターもありません）。どちらも実装されていません。推測したレコードを公開すれば、準拠を偽ることになります。ANP と UCP は新興の仕様です。AID TXT レコード（_agent にある v=aid1）と AWP はドラフトであり、採用を主張せず、現状のまま読み取ります。注：aid アダプターは AID TXT メカニズムであり、IETF の DNS-AID ドラフト（_agents.<domain> にある SVCB）ではありません。後者は別のメカニズムであり、実装されていません。
• **GB/Z 185（中国、スマートエージェント相互接続）— 185.4 は対応、185.5 は制限付き。**NessGate は GB/Z 185.4 のエージェント記述（「ACS」）を正規化します。ACS は GB/Z 拡張（エージェント識別コード aic、mTLS スキーム、certificate ブロック）を持つ A2A 系のカードであり、コンテンツに基づいて認識され、gbz-185-4 としてラベル付けされます。これらのフィールドと来歴は保持されます。認識はドメイン優先です。NessGate がすでに読み取るエージェント記述の場所で ACS が提供されていれば、正規化されます。GB/Z 固有の .well-known パスを推測することはありません。****GB/Z 185.5 のディスカバリーは、ドメインにネイティブな場所を持たないフェデレーションゲートウェイサービスであるため、ホスト型リゾルバーの対象外であり、自動検出されることはありません。埋め込み可能なライブラリでは、オプトインかつ Node 専用の呼び出し（resolve(domain, { gbz: { gatewayUrl, fetch, query } })）として公開されています。呼び出しは、呼び出し元から渡された認証済みの fetch（mTLS／OIDC は利用者側で用意してください。NessGate は認証情報を埋め込みません）を使って、参照実装の実在する …/acps-adp-v2/discover エンドポイントに POST し、返された ACS レコードを正規化します。エンドポイントを推測することも、準拠を偽ることもありません。
• Cloudflare KV（NESSGATE_KV）には、IP をキーとする概算の時間単位のレート制限カウンターのみを保存し、1 時間以内に期限切れになります。それ以外は何も保存されません。
• レート制限：Cloudflare ネイティブのエッジリミッター（バースト、コロ単位、結果整合性が最終的に得られる仕組みで、設計上は概算）を、概算の KV 時間単位上限の前段に配置しています。これは不正利用対策であり、グローバルな厳密な計数を目的とするものではありません。
• SSRF 対策：DoH によるプライベート／予約済み IP の事前確認、同一ドメイン内のみのリダイレクト（≤ 3）、1 MB の上限、8 秒のタイムアウト、HTTPS のみを使用します。プローブは、公開されている well-known パスに対する読み取り専用の GET です。DNS リバインディングによる TOCTOU の時間枠については src/worker.js に記載されていますが、ここでは重要ではありません（Worker の外向き通信先にはプライベートネットワークがなく、プローブは何も保証しません）。
• アカウント、メールアドレス、保存されたドメインデータはありません。

エンドポイント

エンドポイント	用途
GET /discover/{domain}	リゾルバーです。 サポート対象のアダプター（llms.txt、well-known パス経由の ARD/ai-catalog、rel="ard" リンク、robots Agentmap:、A2A エージェントカード、RFC 9727 api-catalog、ai-info.json、OpenAPI、ORD、AWP、host-meta、ANP、UCP、AID、GB/Z 185.4）を通じてドメインが公開している情報を読み取り、正規化された回答 {domain, provenance, note, discovered[], resources[], checked[]} を返します。各リソースには source とネイティブの sourceUrl が含まれます。CORS はオープンで、認証は不要です。発見したドメインやリソースのデータは保存せず、クロールもしません。キャッシュは10分、IPあたり120リクエスト/時です。
GET /explore/{domain}	エビデンスベースのリゾルバー（v2、追加機能）です。 /discover のすべての戻り値に加え、上限付きの 委任型 検出を行います。ドメインが宣言した明示的な機械可読ポインター（llms.txt インデックス内のリンク、ARD/api-catalog エントリー）を深さ2までたどります。クロスホストは、公開者がターゲットを指定している場合に限り許可されます。また、ドメインの検証済み名前空間について、公式 MCP Registry と連携します。各レコードには evidence クラス（publisher-hosted / publisher-declared / namespace-verified）と provenance チェーンが含まれます。厳密な上限を設けています（深さ ≤2、ホスト ≤8、リクエスト ≤24、全体のバイト数上限、各ホップで SSRF チェック）。ステートレスで、クロールせず、AI も使用せず、所有権を主張しません。?org=1（組織検出）を指定すると、同一の登録可能ドメインに属する妥当なホスト群（ホームページにリンクされたサブドメインと、少数の一般的な候補リスト。最大6ホスト × 3パス）を追加で調べ、same-domain-host として検証済みのリソースのみを報告します。これにより、「リソースが example.com ではなく developers.example.com にある」ケースに対応します。/discover に変更はありません。
GET /explore/{domain}?readiness=1	接続準備状況（オプトイン、追加機能）です。 /explore のすべての戻り値に加え、サービスが公開している独自のメタデータに基づいて評価した、接続可能な各リソースの readiness ブロックを返します。状態は ready / credentials-required / incomplete（公開が不十分な具体的なフィールドを示す missing[] を含む）/ broken（宣言されているものの、実際に失敗が確認された状態）で、読み取り専用であり、スコアは付けません。OpenAPI の servers[] と securitySchemes、A2A カード、MCP OAuth メタデータチェーン（RFC 9728 → RFC 8414）を解決します。上限付きで SSRF 対策済みです。認証情報が NessGate に渡ることはありません。デフォルトの /explore（フラグなし）に変更はありません。
POST /connect/{domain}	接続プランです。 リクエスト本文 { client: { supports:[{protocol,versions?,transports?,auth?}], prefer? } }。クライアントが宣言した機能を、ドメインが公開している情報と照合し（スコアなしの決定論的な共通部分）、1つの結果を返します。結果は ready / credentials-required / incomplete / broken / no-compatible-method のいずれかで、接続プラン（エンドポイント、トランスポート、バージョン、認証メタデータ）とその provenance を含みます。読み取り専用です。クライアントの機能は入力としてのみ扱われ（保存されません）、接続はクライアントから直接行います。
POST /mcp	Model Context Protocol サーバー（Streamable HTTP、ステートレス、認証なし）で、3つの読み取り専用ツールを公開します。discover_domain（/discover と同じ回答）、connect_domain（POST /connect と同じ）、check_readiness（/explore?readiness=1 と同じ）です。
GET /{domain}	人間向けのドメインページです。リゾルバーの結果を人間向けに表示します（ライブ検出）。
GET /resolver.mjs	埋め込み可能なリゾルバーライブラリです（npm の @nessgate/resolver としても公開されています）。
GET /openapi.json、/llms.txt、/spec、/sitemap.xml、/robots.txt、/.well-known/security.txt、/.well-known/api-catalog	マシンによる検出とドキュメント

運用手順書

• デプロイフロー： commit → npm run deploy（デプロイ前の必須ゲートとして回帰テストスイート全体を実行し、BUILD_ID を使ってビルドに git SHA を付与します）→ npm run check （回帰テストとライブスモークチェックを実行します。これには、本番環境の /version がローカルの HEAD と一致することの確認も含まれます）→ push。CI（GitHub Actions）は push のたびに回帰テストスイートを実行します。デプロイはワークステーションから実行するため、デプロイスクリプトのゲートが実質的な本番環境のゲートとなります。
• ビルドの検証： すべてのレスポンスに含まれる GET /version と X-NessGate-Build ヘッダーで、デプロイされた正確なコミットを確認できます。
• テスト： npm test — セキュリティ上重要なロジック（正規化、SSRF／プライベート IP の検出、プローブコンテンツの検証、thin normalization、worker↔library↔npm の同等性）を対象とする、ネットワークに接続しない回帰テストスイートです。
• ロールバック： npm run rollback（または npx wrangler rollback [version-id]。バージョンは npx wrangler deployments list で確認できます）。
• ログ： npx wrangler tail nessgate。
• CSS の変更： すべてのページのスタイルシートリンクにある ?v=N を更新してください（アセットはキャッシュされるため、バージョン指定のない CSS の変更はブラウザーに反映されません）。

設定

wrangler.toml は、アセット（run_worker_first）、KV、[[ratelimits]] バインディングを設定します。D1 データベース、cron トリガー、シークレットはありません。リゾルバーはステートレスです。

npm パッケージ

packages/resolver/ は、GitHub Actions Trusted Publishing（OIDC、トークンレス、プロベナンス付き）を通じて @nessgate/resolver として公開されています。詳しくは .github/workflows/publish-resolver.yml をご覧ください。index.mjs は、パリティテストによって public/resolver.mjs とバイト単位で同一に保たれています。

ライセンスとコントリビューション

リファレンス実装は Apache-2.0（LICENSE）でライセンスされています。WordPress プラグインは、WordPress.org の要件に従って GPL でライセンスされています。プロトコルは公開されており、独立して実装できます。CONTRIBUTING.md、命名／商標ポリシーを定めた TRADEMARK.md、および憲章をご覧ください。誰でも許可を求めることなく互換性のあるリゾルバーを構築できます。独立した実装は脅威ではなく、目標です。標準となるリゾルバー／正規化ロジックは public/resolver.mjs と src/worker.js にあります（パリティテストによってバイト単位で同一に保たれています）。

セキュリティ関連の連絡先

[email protected]（/.well-known/security.txt をご覧ください）、 [email protected]、[email protected]、[email protected]。