otr-protocol

OTR プロトコル

AI エージェントコマースのためのマーチャント信頼レイヤー
エージェント経済に向けた、決定論的で検証可能なオープンソースのマーチャント信頼スコアリング
プロトコル v4.1

仕様 • スコアリングアルゴリズム • クイックスタート • パッケージ • コントリビューション

---

課題

AI エージェントは、消費者に代わって購入を決定する機会が増えています。エージェントコマースのスタックが形になりつつありますが、重要なレイヤーが欠けています。

┌──────────────────────────────────────────────────────────────────┐
│                  AI Agent Commerce Protocol Stack                 │
├──────────────────────────────────────────────────────────────────┤
│                                                                   │
│   Visa TAP ·············· Agent Identity Verification             │
│   Google UCP ············ Structured Data Exchange                 │
│   Stripe ACP ············ Payment Processing                      │
│                                                                   │
│   ┌───────────────────────────────────────────────────────────┐   │
│   │  OTR Protocol ·····  MERCHANT TRUST VERIFICATION  ◀━━━━━ │   │
│   │                      "Is this merchant safe to buy from?" │   │
│   └───────────────────────────────────────────────────────────┘   │
│                                                                   │
│   Visa TAP answers "Who is the AI agent?"                         │
│   Google UCP answers "What products are available?"               │
│   Stripe ACP answers "How do I pay?"                              │
│   OTR answers "Should I trust this merchant?"  ◀━━ ONLY OTR      │
│                                                                   │
└──────────────────────────────────────────────────────────────────┘

OTR がなければ、AI エージェントは状況を把握できず、正規の小売業者と巧妙な詐欺サイトを見分けられません。その結果、消費者が詐欺の被害に遭うリスクが高まり、エージェントコマースのエコシステム全体への信頼が損なわれます。

ソリューション

OTR（Open Trust Registry）は、6 つの検証ディメンション、10 層の不正対策パイプライン（レイヤー 0：Google Web Risk による単独投票の拒否権＋レイヤー 1～9：コア検出エンジン）、および3 層の改ざん不可能な監査証跡を使用して、決定論的で検証可能なマーチャント信頼スコアを提供します。完全なオープンソース（MIT）で、機械可読であり、AI エージェントによる利用を前提にゼロから設計されています。

主な特性

• 決定論的 -- 同じ入力からは常に同一の出力が生成されます。どのバリデーターでも、あらゆるスコアを再現できます。
• 検証可能 -- すべてのデータソースに一般公開でアクセスできます。非公開の要素や独自シグナルはありません。
• 偽造不可能 -- 公開評価において、検証ディメンションの重みは 40％です。SEC の提出書類、Wikidata のエントリー、10 年間のドメイン運用実績は偽造できません。
• 改ざん防止 -- SHA-256 ハッシュチェーン＋Base L2 ブロックチェーンへのアンカリング＋IPFS の月次スナップショット。
• 公平 -- 信頼を金銭で買うことはできません。スコアはサブスクリプションのレベルではなく、行動を反映します。
• カテゴリ対応 -- 3 つのサイトカテゴリ（ecommerce／saas／non_commerce）に、カテゴリごとに調整されたスコアリング重みを適用します。
• 安全性優先 -- Google Web Risk のレイヤー 0 による単独投票の拒否権：フラグが付いたドメインはスコアが 0 になり、ステータスが SUSPENDED になります。

クイックスタート

# Verify any merchant instantly
npx @otr-protocol/validator verify nike.com

# Output:
# ┌──────────────────────────────────────────────┐
# │  nike.com                             GOLD   │
# │  Trust Score: 88/100   Category: ecommerce   │
# │  OTR-ID: OTR-1C-7F3A2B9E4D1C-K4             │
# │                                              │
# │  Verification:   85  ██████████████░░        │
# │  Security:       80  █████████████░░░        │
# │  Governance:     72  ████████████░░░░        │
# │  Transparency:   75  ████████████░░░░        │
# │  Data Quality:   65  ██████████░░░░░░        │
# │  Fulfillment:    --  (COLD mode)             │
# └──────────────────────────────────────────────┘

AI エージェント向け（MCP サーバー）

OTR MCP サーバーは標準の Model Context Protocol を使用し、すべての MCP 互換クライアントで動作します。

Claude Desktop／Claude Code -- claude_desktop_config.json に追加します。

{
  "mcpServers": {
    "otr": {
      "command": "npx",
      "args": ["@otr-protocol/mcp-server"]
    }
  }
}

Cursor／Windsurf／Cline -- .cursor/mcp.json または同等のファイルに同じ設定を追加します。MCP 仕様を実装しているクライアントであれば、すぐに利用できます。

これで、あらゆる AI エージェントが自然言語でマーチャントを検証できます。

「nike.com は信頼できますか？」 --> OTR は、信頼スコア 88/100、バッジ GOLD、および証拠ソース付きの 6 ディメンション（Verification、Security、Governance、Transparency、DataQuality、Fulfillment）の内訳を返します。

2 つの MCP ツール — 1 回の呼び出しで完全な回答

ツール	説明	返される内容
verify_merchant	1 回の呼び出しで完全な加盟店プロフィールを取得	信頼スコア（0-100）、バッジ、6 つのディメンションの内訳、安全性ステータス（Google Web Risk）、サイト分類（ecommerce/saas/non_commerce）、事業体データ、ポリシー URL、データソース
search_registry	OTR 加盟店レジストリを検索	スコア、バッジ、おすすめ情報を含む、ページ分割された加盟店リスト

設計理念： AI エージェントは、1 回のツール呼び出しですべての必要な情報を取得できるようにするべきです。verify_merchant は信頼性評価に加え、購入機能、リンク、ポリシー URL、データの鮮度を返すため、複数の呼び出しを連鎖させる必要はありません。

TypeScript SDK

import { OtrClient } from "@otr-protocol/sdk";

const otr = new OtrClient();
const result = await otr.verify("nike.com");

console.log(result.trustScore);   // 88
console.log(result.badge);        // "GOLD"
console.log(result.dimensions);   // { verification: 85, security: 80, ... }

// Search the registry
const results = await otr.search("electronics", { minScore: 70 });

コアスコアリングエンジン

import { calculateTrustScore } from "@otr-protocol/core";

// Deterministic: same inputs always produce identical outputs
const result = calculateTrustScore({
  hasSecFiling: true,
  hasStockSymbol: true,
  stockExchange: "NYSE",
  hasWikidataId: true,
  trancoRank: 500,
  domainAgeYears: 15,
  // ... 40+ evidence fields
});

console.log(result.trustScore);  // 88
console.log(result.badge);       // "GOLD"
console.log(result.tier);        // "TIER_4"

アーキテクチャ

                         ┌─────────────────────────────────┐
                         │       AI Agent / Application      │
                         │   "Should I buy from example.com?" │
                         └──────────────┬──────────────────┘
                                        │
                    ┌───────────────────┼───────────────────┐
                    │                   │                    │
              ┌─────▼─────┐     ┌──────▼──────┐    ┌──────▼──────┐
              │ MCP Server │     │  REST API   │    │   SDK       │
              │  (stdio)   │     │  /api/otr   │    │  npm pkg    │
              └─────┬──────┘     └──────┬──────┘    └──────┬──────┘
                    │                   │                    │
                    └───────────────────┼───────────────────┘
                                        │
                         ┌──────────────▼──────────────┐
                         │      OTR Scoring Engine       │
                         │   @otr-protocol/core          │
                         │                               │
                         │  ┌─────────────────────────┐  │
                         │  │ 6 Dimension Evaluators   │  │
                         │  │ Verification | Security  │  │
                         │  │ Governance | Transparency│  │
                         │  │ DataQuality | Fulfillment│  │
                         │  └─────────────────────────┘  │
                         │  ┌─────────────────────────┐  │
                         │  │ 10-Layer Anti-Fraud      │  │
                         │  │ Domain Age | SSL | DNS   │  │
                         │  │ Pattern | Tranco | ...   │  │
                         │  └─────────────────────────┘  │
                         │  ┌─────────────────────────┐  │
                         │  │ Brand Fast-Track         │  │
                         │  │ SEC + Tranco + Wikidata  │  │
                         │  └─────────────────────────┘  │
                         └──────────────┬──────────────┘
                                        │
              ┌─────────────────────────┼─────────────────────────┐
              │                         │                          │
     ┌────────▼────────┐    ┌──────────▼──────────┐    ┌─────────▼─────────┐
     │  Public Data     │    │  Merchant Bridge     │    │  Immutable Audit   │
     │  Sources         │    │  (Verified Only)     │    │  Trail             │
     │                  │    │                      │    │                    │
     │  SEC EDGAR       │    │  Product Catalog     │    │  SHA-256 Hash      │
     │  Wikidata        │    │  Order Data (agg)    │    │  Chain             │
     │  Tranco List     │    │  Delivery Metrics    │    │  Base L2 Anchoring │
     │  DNS Records     │    │  Tracking Numbers    │    │  IPFS Snapshots    │
     │  SSL Certs       │    │  (desensitized)      │    │                    │
     │  Finnhub.io      │    │                      │    │                    │
     │  Google Web Risk │    │                      │    │                    │
     │  Website Scan    │    │                      │    │                    │
     └─────────────────┘    └──────────────────────┘    └───────────────────┘

スコアリングの仕組み

6 つの信頼性ディメンション

重みはサイトのカテゴリによって異なります。

#	ディメンション	E コマース COLD	SaaS COLD	AUTH モード	測定対象
1	検証	0.40	0.37	0.10	証券取引所、Wikidata、GLEIF LEI、ドメイン年齢、Tranco ランク、決済プロセッサー
2	セキュリティ	0.15	0.20	0.10	SSL/TLS、DMARC、SPF、DKIM、HSTS、DNSSEC、CSP、CAA、WAF、security.txt（15 のシグナル）
3	ガバナンス	0.20	0.23	0.10	プライバシーポリシー、GDPR/CCPA、利用規約、返金・返品、配送、Cookie 同意（10 のシグナル）
4	透明性	0.10	0.15	0.05	robots.txt、サイトマップ、Schema.org、hreflang、AI クローラーポリシー、llms.txt、会社概要ページ
5	データ品質	0.15	0.05	0.25	E コマース：22 の商品データシグナル。SaaS：12 のプラットフォームシグナル（API ドキュメント、SLA、料金、セキュリティ認証）
6	履行	--	--	0.40	配送速度、返品期間、追跡、配送ポリシー（COLD モードではスコアリング対象外）

各ディメンションの測定内容

ディメンション	評価内容
検証（V）	実在する登録済みの事業者ですか？ SSL 証明書の種類、GLEIF LEI、Wikidata エンティティ、SEC 提出書類、ドメイン年齢、決済プロセッサーの検出
セキュリティ（S）	サイトは技術的に安全ですか？ DMARC、SPF、DKIM、HSTS、CSP、WAF、DNSSEC の設定
ガバナンス（G）	事業運営上のルールに従っていますか？ プライバシーポリシー、返金ポリシー、配送ポリシー、Cookie 同意、規制遵守
透明性（T）	機械可読ですか？ robots.txt、Schema.org 構造化データ、llms.txt、プロトコルエンドポイントの利用可否
データ品質（D）	商品・サービスデータは完全ですか？ 商品数、画像の網羅率、価格形式の一貫性、カテゴリ分類の階層の深さ
履行（F）	約束どおりに商品を届けていますか？ 注文完了率、配送時間、返品率、紛争率（AUTH モードのみ — 加盟店データが必要）

カテゴリによって重みが異なる理由

• E コマース：購入者が購入前にストアを信頼する必要があるため、検証の重みが最も高くなります（0.40）。本人確認のシグナル（SEC 提出書類、Wikidata、ドメイン年齢）は、詐欺サイトへの最も強力な防御策です。
• SaaS：SaaS プラットフォームはユーザーデータを扱い、明確なポリシーが必要なため、セキュリティ（0.20）とガバナンス（0.23）の重みが高くなります。ユーザーは自身の情報への継続的なアクセスを委ねます。
• 非コマース：スコアリング対象外です。商品やサービスを販売していないサイトには、適用可能なコマースのディメンション（商品データ、チェックアウト、履行）がありません。

3 つのサイトカテゴリ

カテゴリ	説明	スコアリング
ecommerce	物理・デジタル商品を販売するオンラインストア	商品 D シグナルを含む、6 ディメンションすべてのスコアリング
saas	Software-as-a-Service プラットフォーム	12 の SaaS D シグナルを含む、調整された重み（V=37%、G=23%）
non_commerce	非営利目的のサイト（Wikipedia、政府機関など）	スコアリング対象外 -- 本人確認シグナルのみを返します

非コマースサイト

non_commerce に分類されるサイト（Wikipedia、政府のポータル、ニュースサイトなど）はスコアの対象外です：

• trustScore: null
• badge: null
• scanStatus: "non_commerce"
• 基本的な検証データ（SSL、事業者情報）は引き続き返されますが、数値のトラストスコアは割り当てられません。

理由：非コマースサイトは商品やサービスを販売しないため、トラストスコアの評価項目（商品データ、チェックアウト、履行）は適用されません。

OTR-ID

評価対象の各ドメインに割り当てられる一意の識別子です。

形式：OTR-1{mode}-{fingerprint}-{checksum}

• 1 — プロトコルのバージョン
• mode — C（COLD：事前認証スキャン）または A（AUTH：販売者が認証済み）
• fingerprint — 大文字の 16 進数 12 文字。正規化されたドメインの SHA-256 から導出されます（先頭 48 ビット）
• checksum — Base36 の 2 文字（Luhn mod-36 検証 + 決定論的ソルト）

Example: OTR-1C-7F3A2B9E4D1C-K4

特性：

• 決定論的：同じドメインからは常に同じフィンガープリントが生成されます
• 不可逆：SHA-256 は暗号学的に一方向であり、48 ビットに短縮されるため、元のドメインを復元できません
• 衝突耐性：フィンガープリントの組み合わせは約 281 兆通りです（2^48）

ライフサイクル：

イベント	結果	状態
初回スキャン	OTR-1C を生成	ACTIVE
販売者が認証	OTR-1A にアップグレード（フィンガープリントは同一、チェックサムを再計算）	UPGRADED
ドメインの ID 変更を検出	OTR-ID を取り消し（NULL に設定）、ドメインをコールドスタートに戻す	REVOKED
Google Web Risk がドメインにフラグを付与	スコアを強制的に 0 に設定	SUSPENDED
アンチゲーミング乗数 < 0.10	スコアを強制的に 0 に設定	SUSPENDED

ID の変更は、重み付きシグナルの合計がしきい値の 3 を超えた場合に検出されます：GLEIF 事業体の不一致（3）、ネームサーバーの変更（2）、コンテンツ類似度 < 30%（2）、Wikidata P856 の不一致（2）、ドメインパーキングが 90 日超（2）、SSL 組織の変更（1）。

Google Web Risk（レイヤー 0 の安全性）

Google Web Risk は、ディメンションのスコアリングとは別に、レイヤー 0 の単独拒否判定として機能します：

• フラグが付与されたドメイン → trustScore = 0、otrIdStatus = SUSPENDED、safety.googleWebRisk = true
• ディメンションの重み計算には参加しません
• 他のすべてのシグナルの値に関係なく、それらを上書きします

2 つのスコアリングモード

COLD Mode: Public Assessment (no merchant cooperation needed)
═══════════════════════════════════════════════════════════════
  E-Commerce: V (0.40) + S (0.15) + G (0.20) + T (0.10) + D (0.15) = Score
  SaaS:       V (0.37) + S (0.20) + G (0.23) + T (0.15) + D (0.05) = Score

  Nike (ecommerce):   V=85×0.40 + S=80×0.15 + G=72×0.20 + ...  = 83 GOLD
  Scam site:          V=10×0.40 + S=100×0.15 + G=90×0.20 + ...  = 39 UNRATED
                                                                    ↑ can't game Verification


AUTH Mode: Verified Merchant (merchant provides API access)
═══════════════════════════════════════════════════════════════
  F (0.40) + D (0.25) + V (0.10) + S (0.10) + G (0.10) + T (0.05) = Score

  Good merchant:   F=90×0.40 + D=85×0.25 + ...  = 78 SILVER
  Bad merchant:    F=30×0.40 + D=40×0.25 + ...  = 38 UNRATED
                                                    ↑ bad fulfillment = low score

トラストバッジ

バッジ	スコア	AI エージェントのアクション
PLATINUM	90-100	高い確信をもって安全に推奨できます
GOLD	80-89	高い信頼性があり、AI エージェントに推奨されます
SILVER	70-79	通常の注意を促したうえで推奨します
BRONZE	60-69	表示のみとし、ユーザーに独自の確認を促します
UNRATED	0-59	信頼性データが不十分であることをユーザーに警告します

95 以上のスコアでは、人によるレビューを推奨します。上限はありません。safety.status が "DANGEROUS"（Google Web Risk）の場合は、スコアにかかわらず推奨しないでください。

10 層の不正対策エンジン

OTR は、10 層の検出パイプラインを通じて、不正サイトによるシステムの悪用を防ぎます：

Layer 0  Safety Check        Google Web Risk API — malware/phishing one-vote-veto (instant block)
Layer 1  Domain Age          Certificate history analysis (crt.sh)
Layer 2  SSL Security        HTTPS/HSTS verification, self-signed detection
Layer 3  DNS Security        DMARC, SPF, DKIM policy completeness
Layer 4  Domain Pattern      Brand impersonation (amaz0n-deals.xyz), suspicious TLDs
Layer 5  Tranco Rank         Independent traffic ranking verification
Layer 6  Content Analysis    Phishing keywords, parked domains, empty pages
Layer 7  Redirect Chain      Cross-domain redirect detection
Layer 8  Cross-Signal        Multi-signal correlation and accumulation rules
Layer 9  Anti-Gaming         Signal-brand mismatch, identity-gameable gap, template suspect
         ▼
         Layer 0 DANGEROUS = immediate rejection (one-vote-veto)
         Single CRITICAL signal = immediate rejection
         Fraud score > 30 = rejection
         Anti-gaming multiplier applied to gameable dimensions

アンチゲーミング検出パターン（レイヤー 9）

パターン	発動条件	乗数
シグナルとブランドの不一致	操作可能な項目の平均値 ≥ 80 + Tranco/Wikidata/SEC なし + Identity < 30	0.5x
Identity と操作可能な項目のギャップ	Identity < 20 + 操作可能な項目の平均値 > 70 + 確立された ID なし	0.7x
テンプレートサイトの疑い	ドメイン登録から 1 年未満 + Tranco/Wikidata/SEC なし + 操作可能な項目の平均値 > 60	0.5x
ドメイン年齢ゲート（6 か月未満）	ドメイン登録から 6 か月未満	50 を上限とする
ドメイン年齢ゲート（1 年未満）	ドメイン登録から 1 年未満	75 を上限とする

実際のアンチゲーミングの適用例

シナリオ	旧 v3 スコア	新 v4 スコア	変化
Nike（正規ブランド）	83 GOLD	83 GOLD	--
詐欺サイト（技術面は完璧）	39 UNRATED	35 UNRATED	-4
詐欺サイト + アンチゲーミング	28 UNRATED	22 UNRATED	-6

データの完全性

OTR は、過去のスコアが改ざんされないよう、3 層の不変監査証跡を使用します：

Layer 1: PostgreSQL Hash Chain (real-time, $0/year)
├── Every score change records SHA-256 hash
├── Each record links to previous via prev_hash
├── Any modification breaks the chain → detectable
└── verifyChainIntegrity() → instant verification

Layer 2: Base L2 Blockchain Anchoring (daily, ~$0.37/year)
├── Daily chain-head hash written to Base L2 smart contract
├── Externally verifiable by anyone
├── AWS KMS hardware security for signing keys
└── Transaction hash stored in otr_l2_anchors table

Layer 3: IPFS Monthly Snapshots (monthly, $0/year via web3.storage)
├── Full registry exported as content-addressed JSON
├── CID (Content Identifier) is immutable
├── Anyone can retrieve and verify the snapshot
└── CIDs recorded in otr_snapshots table

公開検証エンドポイント：

GET /api/otr/audit/chain-integrity     Verify hash chain completeness
GET /api/otr/verify/:domain/history    Score history with trend data
GET /api/otr/audit/l2-anchors          Base L2 anchoring records
GET /api/otr/audit/snapshots           IPFS snapshot CID listing

複数ソースによるコンセンサス

OTR は単一のデータソースを盲目的に信頼することはありません。外部から取得したすべてのデータポイントは、クロスバリデーションを通過する必要があります。

Source Weights (not all sources are equally trustworthy):
  google-web-risk   1.0   Google Safe Browsing → one-vote-veto on DANGEROUS
  sec.gov           1.0   Government source → highest trust
  dns-query         0.9   Infrastructure → high trust
  tranco-list.eu    0.9   Academic source → high trust
  wikidata.org      0.8   Community source → high but editable
  finnhub.io        0.7   Commercial API → moderate-high trust
  website-scan      0.6   Self-reported → moderate trust
  product-sample    0.5   Product page sampling → public but limited scope
  merchant-api      0.4   Merchant-declared → low trust (can be faked)

Consensus Rules:
  ✓ 2+ sources agree → accepted (high confidence)
  ✗ Sources disagree → rejected (keep existing value)
  ⚠ Single source drift > 30% → anomaly flagged
  🔒 3+ anomalies from one source → auto-quarantine

データの非識別化

加盟店からフルフィルメントデータが提供されると、OTR は 4 段階のプライバシー保護を適用します。

レベル	段階	実施内容
L1	送信前	顧客名 → SHA-256 ハッシュ化、住所 → 国と都市のみ、メールアドレス／電話番号／支払い情報 → 削除
L2	転送中	TLS 1.3 + HMAC-SHA256 署名 + nonce によるリプレイ攻撃対策
L3	サーバー側	即時に統計情報へ集約し、生データは一切永続化されません
L4	監査証跡	ログに記録するのはメタデータ（タイムスタンプ、件数）のみで、内容は一切記録しません

OTR が選ばれる理由

機能	OTR	Trustpilot	BBB	Google Merchant
AI ネイティブ API（MCP サーバー）	対応	非対応	非対応	非対応
決定論的なスコアリング	対応	非対応	非対応	非対応
オープンソースのアルゴリズム（MIT）	対応	非対応	非対応	非対応
信頼性の対価を求めない	対応	非対応	非対応	対応
複数ソースによる検証	6 つの評価軸	1（星）	1（評価）	部分対応
不正操作の検出	10 層	非対応	非対応	非対応
機械可読な出力	完全な JSON	部分対応	非対応	部分対応
改ざん不可能な監査証跡	3 層	非対応	非対応	非対応
カテゴリを考慮したスコアリング	3 種類	非対応	非対応	非対応
適合性テストスイート	対応	該当なし	該当なし	該当なし
データの非識別化	4 段階	該当なし	該当なし	部分対応

パッケージ

パッケージ	説明	npm
@otr-protocol/core	決定論的なスコアリングエンジン ― リファレンス実装
@otr-protocol/mcp-server	AI エージェント（Claude、Cursor、Windsurf、Cline）向け MCP サーバー
@otr-protocol/validator	加盟店の検証用 CLI ツール
@otr-protocol/sdk	アプリケーション統合用 TypeScript クライアント SDK

適合性テスト

OTR の実装はすべて、標準の適合性テストベクターに合格する必要があります。

npm run conformance

テストスイートは決定性を検証します。つまり、同一の入力に対して、すべての実装（TypeScript、Python、Go、Rust）で同一の出力が生成されます。これにより、どのバリデーターで計算しても、加盟店の信頼スコアが同じになることが保証されます。

conformance/test-vectors.json のテストベクターでは、次の項目をカバーしています。

• サイトカテゴリの検出（ecommerce / saas / non_commerce）
• スコアリングモードの検出（COLD と AUTH）
• カテゴリ固有の重みを使用した個別評価軸のスコアリング
• バッジとティアの割り当て（PLATINUM/GOLD/SILVER/BRONZE/UNRATED）
• 不正操作の検出とペナルティの適用
• Google Web Risk による安全性の上書き
• 商用ではないサイトの除外
• エッジケース（空のデータ、null フィールド、境界値）

スコアの完全性

OTR Protocol は、以下の取り組みによって、加盟店の信頼スコアの完全性と独立性を維持しています。

1. スコアの販売禁止 -- 信頼スコアを購入、後援、または商業的に操作することはできません。プレミアムプラン、スポンサーシップ、パートナーシップがスコアに影響することはありません。
2. 信頼の対価としての支払い禁止 -- サブスクリプションの利用状況が OTR スコアに与える影響は一切ありません。無料プランの加盟店もエンタープライズ顧客も、同一の基準で評価されます。
3. 人為的な変更の禁止 -- すべてのスコアはアルゴリズムによって算出されます。個人がスコアを手動で調整することはできません。
4. アルゴリズムの透明性 -- アルゴリズム全体を MIT ライセンスのオープンソースとして公開しています。誰でもスコアを監査、検証、再現できます。同じドメインを再スキャンすると、同じスコアが生成されます（決定論的なパイプライン）。
5. データのみに基づく評価 -- スコアは独立して検証可能なシグナルを反映します。加盟店が提出したデータは verified=false、scoringWeight=0 としてマークされ、少なくとも 2 つの独立した権威ある情報源による裏付けが必要です。

適用措置： オープンソースコード ＋ 適合性テスト ＋ ガバナンスプロセス ＋ 乗数が累積する 10 層の不正操作検知。

ミッション

OTR は、AI エージェントによるコマースの時代に、公正で透明性の高い信頼レイヤーを構築することを目指しています。規模やブランドの知名度にかかわらず、あらゆる加盟店が、検証可能な実績を通じて信頼を獲得できます。スコアを改善する唯一の方法は、実際の信頼シグナルを改善することです。

公開データソース

OTR は、一般にアクセス可能なデータのみを使用して加盟店を評価します（COLD モード）。加盟店の協力は必要ありません。

ソース	データ	検証可能
DNS レコード	SPF、DMARC、DKIM、DNSSEC、MTA-STS、CAA	はい — 標準的な DNS クエリ
SSL/TLS 証明書	種類（DV/OV/EV）、発行 CA、組織	はい — 証明書の透明性ログ
HTTP ヘッダー	HSTS、CSP、X-Frame-Options、Permissions-Policy	はい — あらゆる HTTP クライアント
ウェブサイトのコンテンツ	ポリシーページ、商品カタログ、Schema.org マークアップ	はい — 公開ウェブページ
Tranco List	ドメインの人気度ランキング（上位 1M）	はい — tranco-list.eu（学術機関）
WHOIS / crt.sh	ドメインの登録期間、証明書の履歴	はい — 公開レジストリ
Wikidata	P856（公式ウェブサイト）によるエンティティ検証	はい — wikidata.org（CC0）
GLEIF	法人識別子（LEI）、ISO 17442	はい — gleif.org
SEC EDGAR	米国の規制関連提出書類	はい — sec.gov
Finnhub / OpenFIGI	証券取引所への上場情報、ティッカーの照合	はい — finnhub.io / openfigi.com
Google Web Risk	マルウェア、フィッシング、望ましくないソフトウェアの検出	はい — Google API

ロードマップ

フェーズ	ステータス	説明
フェーズ 1	完了	オープンソースのスコアリングエンジン、MCP Server、CLI、SDK、適合性テスト
フェーズ 2	完了	ハッシュチェーンの完全性、L2 アンカリング、IPFS スナップショット、複数ソースのコンセンサス、データの非機微化、スコアの減衰、Google Web Risk Layer 0 の安全性、3 つのサイトカテゴリ（ecommerce/saas/non_commerce）、SaaS の D ディメンションにおける 12 個のシグナル、COLD/AUTH スコアリングモード
フェーズ 3	計画中	IETF Internet-Draft の標準化、Python/Go SDK、学術論文

貢献

貢献を歓迎します。詳しいガイドラインは CONTRIBUTING.md をご覧ください。

スコアリングアルゴリズムの変更に関する主な要件：

1. spec/ 内の RFC 形式の提案
2. 適合性テストベクトルの更新
3. 決定性の検証
4. メンテナーによるレビュー

ライセンス

MIT -- ORBEXA

---

プロトコル仕様 • スコアリングアルゴリズム • ガバナンスモデル • 貢献ガイド • 行動規範

_{ORBEXA が構築 -- エージェント型コマースのためのインフラストラクチャ}