mcpField
G
Graviti

Graviti

認証済みおすすめリモート
graviti.thesingulariti.aiビジネス・マーケティング07 週間前に更新
リポジトリ公式サイト

Graviti について

Gravitiは、エージェント経由のコマース向けに決定論的なスコアを算出する、監査可能なエンジンです。エージェントやチームによる商品推薦の評価を想定し、ランキングエンジンと署名付きの検証可能なインデックス履歴を公開します。支払いは順位に影響しません。

主な機能

  1. 01決定論的な推薦スコアリング
  2. 02コマースデータ向けMCPツール7種
  3. 03署名付きハッシュチェーン台帳
  4. 04ペイロード整合性とリプレイ検査
  5. 05カナリアによるドリフト検出

活用シーン

  1. 01指定した意図に基づくブランド比較
  2. 02主張と説明責任記録の確認
  3. 03公開インデックスペイロードの検証
  4. 04ランキング挙動のドリフト監視

MCP 対応

ホスト型Streamable HTTPエンドポイント、またはstdioで動作する`graviti-mcp` npmパッケージを通じて、7つのツールを提供します。どちらも公開されたスコアリングエンジンを使用します。

設定

リモートサーバーはインストール不要です。クライアントを選んで設定をコピーするか、ワンクリックで導入できます。

エンドポイントhttps://graviti.thesingulariti.ai/api/mcp
インストールコマンドをコピー
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

コマンドはターミナルで実行し、JSON は各クライアントの MCP 設定に貼り付けて再起動します。認可が必要なサーバーは初回接続時にログインを求めます。

ツール

7
パラメーター型必須説明
questionstringはい購入者が質問で用いた表現
intent_profileenumいいえ購入者の意図の表現スタイル。省略された場合は質問から推定します。anxious_first_timer | technical_buyer | price_shopper | general

詳細

graviti-engine

Graviti を支える決定論的なスコアリングエンジンです。Singulariti が開発した、エージェントを介したコマースのための信頼インフラです。このリポジトリの目的は、サイトの中心的な主張である「スコアリングは監査可能です」を、単なる宣言ではなく検証可能にすることです。ここにある src/engine.ts は、本番環境ですべてのレコメンデーションをランク付けする正確なモジュールです。MCP サーバー、ウェブコンソール、公開エンドポイントはすべて、このファイルをインポートします。非公開のランキング経路はありません。

どのエージェントからでも1分以内に利用できます

Graviti は2つの経路で MCP に対応しており、どちらもこのエンジンを通じて、同じ7つのツール(match_intent、get_verified_claims、category_landscape、get_accountability_log、get_ledger、get_gap_report、report_conversion)を提供します。

リモート(最速) — ホストされた Streamable HTTP エンドポイント。認証もアカウントも不要です。

{ "mcpServers": { "graviti": { "url": "https://graviti.thesingulariti.ai/api/mcp" } } }

ローカル — stdio 経由の graviti-mcp npm パッケージです。

{ "mcpServers": { "graviti": { "command": "npx", "args": ["-y", "graviti-mcp"] } } }

このパッケージにはインデックスのスナップショットが同梱されており、起動時に最新の公開済みインデックスを取得し、署名付き台帳と照合して検証します。固定された鍵、2つの独立した台帳経路、リプレイガードは、下記の scripts/verify-payload.mjs と同じ手順です。改ざんまたはリプレイされたペイロードが使われることはありません。(Claude Desktop の場合は claude_desktop_config.json、Cursor の場合は .cursor/mcp.json を使用します。その他のクライアントの設定については graviti.thesingulariti.ai/use-graviti をご覧ください。)

2つの原則

  1. 検証は有料です。ランキングは決して有料になりません。 ブランドは、自社の主張に対する継続的な独立監査の費用を支払います。検証ステータスはランキングにまったく影響しません。matchIntent() の適合スコアの構成を読み、支払いに関するシグナルが含まれていないことを確認してください。
  2. 支払いで得られるのは速度であり、結果ではありません。 ブランドは再評価を迅速化するために支払うことができます。支払いによって短縮されるのは所要時間であり、判定が変わることはありません。

ブランドの状態に紐づくスコア調整は、固定され、開示されているライフサイクルペナルティ(LIFECYCLE_PENALTY:フラグ付き −0.05、品質低下 −0.15)のみです。これは監視対象の品質シグナルに基づき、支払いステータスには左右されません。また、取り消し済みのブランドはスコアリングから完全に除外されます。

このコードを読んで検証できること

  • スコアリングは決定論的です。 ブランドインデックスに対する純粋関数であり、I/O、ネットワーク、乱数、学習済みパラメーターはありません。エンジンへの入力は、インデックス、質問文、任意の意図プロファイルのみです。同じ入力なら、毎回同じスコアが得られます。
  • コンバージョンデータがスコアリングに使われることはありません。 エンジンにコンバージョンの入力はありません。このファイルでコンバージョンに関する記述を grep しても、何も見つかりません。アトリビューション済みコンバージョンイベントは、非公開のトランスポート層に請求記録(実際の獲得に対する支払い)としてのみ存在します。このモジュールはそれらを参照しないため、構造上、適合スコアに影響を与えることはできません。
  • 公開データからスコアを再現できます。 このエンジンが本番環境で処理するインデックス全体は公開されています。エンジンに指定すれば、本番環境のスコアを正確に再現できます。
  • すべてのペイロードに構造化された開示情報が含まれます。 disclosure() をご覧ください。rank_influenced_by_payment: false、支払った人、支払っていない人、支払いによって得られる内容を、すべてのレスポンスで機械可読形式で示します。
  • 対象範囲外の質問には推測ではなく拒否を返します。 matchIntent() の in_index: false ブランチをご覧ください。

実行する

npm install
npm run demo -- "best magnesium supplement"
npm run demo -- "cheapest cold plunge with a chiller"
npm run demo -- "best magnesium supplement" --json     # the full machine payload agents receive

このデモでは、data/sample-index.json にある公開インデックスの小規模な実データ(5 つのカテゴリ、約 100 のブランド、主張、出典 URL、説明責任ログを含む)を使ってエンジンを実行します。全体を確認するには、index-full.json を取得して差し替えてください。エンジンは任意の BrandIndex を受け付けます。

カナリアを実行する

npm run canary

Graviti では、カナリアベースのドリフト検出を実施しています。既知の正解がある対象を、本番ビルドのたびにシステムに通します(パネル A — 正解となるルーティングクエリ、「スコアに NaN が一つもない」「カタログ階層のブランドがランキングに入らない」といった構造上の不変条件、有名な回答が勝ってはならない敵対的なケース)。また、監査クローラーの各サイクルでも、既知の対象を通します(パネル B — サイトが管理する 3 つの出典ページ。1 つは安定、1 つは意図的にドリフトさせたもの、1 つは意図的に削除したもの)。パネル A との不一致があればビルドは失敗します。パネル B の誤読はセンサー自体の故障を意味し、そのクロールサイクルでは実際の主張を一切更新しません。どちらかがもう一方の正解データになることがないよう、2 つのパネルは独立して管理されています。

scripts/canary-panel-a.ts は、パネル A の公開サブセットです。サンプルインデックスが対応するケースを、このリポジトリが公開する実際のエンジンで実行するため、秘密情報なしでビルドと同じカナリアを実行できます。両方のパネルの稼働状況は pulse.json の canaries ブロックで公開されており、人間が読みやすい形式は /pulse で確認できます。

台帳を検証する

インデックスのバージョン履歴はハッシュチェーンになっています。各エントリーは、正規化されたインデックス全体の内容の SHA-256 と前のエントリーのハッシュを記録し、公開鍵(data/public-key.pem。/public-key.pem でも配信)に照らして Ed25519 署名され、OpenTimestamps を介して Bitcoin にアンカーされています。過去のエントリーを書き換えると、その後のすべてのハッシュが無効になります。Graviti であっても記録を編集できません。

npm run verify:ledger           # verifies the committed ledger snapshot, then checks it against the live index
npm run verify:ledger -- --live # fetches and verifies the current live ledger instead

このスクリプトに秘密情報や Graviti が運用するインフラは必要ありません。すべてのエントリーのハッシュを再計算し、チェーンをジェネシスまでたどって、すべての署名を公開鍵で検証します。Bitcoin のアンカーは、llms.txt の手順に従い、/ots/v<N>.ots の証明を使ってオープンソースの OpenTimestamps クライアントで個別に再検証できます。

受け取った内容を検証する — 転送の完全性

台帳が証明するのは、公開された内容です。転送経路までは確認できません。TLS 終端プロキシ、CDN、キャッシュ、ロードバランサーが Graviti のオリジンとお使いのプロセスの間にあり、そのいずれかがペイロードを変更しても、差分を記録する台帳エントリーはありません。台帳 v25 以降、各エントリーの署名済みコアには、公開されたすべてのペイロードの sha256 マニフェスト(files.artifacts)が固定されているため、検証は転送経路の受信側で行います。信頼する前に検証してください:

npm run verify:payload                                             # /index-full.json
npm run verify:payload -- /index.json /data/categories/magnesium-supplements.json /llms.txt

scripts/verify-payload.mjs は依存関係がなく(Node ≥ 20)、失敗があるとゼロ以外のコードで終了します。次の処理を行います。

  1. 台帳を独立した2つの経路から取得します。このリポジトリの raw.githubusercontent.com 上のスナップショットと、オリジンの /ledger.json です。両方のチェーンを検証し、ヘッドを相互照合します(フォークが発生している場合や、オリジンが公開ミラーより古い台帳を配信している場合は、明確に失敗します)。
  2. スクリプトに埋め込まれた固定済み署名鍵を使って、すべての Ed25519 署名を検証します。配信された /public-key.pem は固定済みの鍵と相互照合され、不一致は失敗として扱われ、信頼の根拠にはなりません。
  3. 実際に受信したペイロードの sha256 を再計算し、ヘッドエントリーの署名済みマニフェストと比較します。
  4. リプレイ攻撃を防ぎます。ヘッドではなく、古いエントリーのマニフェストと一致するペイロードは、古いものの有効な署名がある状態です。リプレイされた昨日のデータは見抜きにくい攻撃であるため、個別の失敗として報告されます。

Node がない場合でも、curl、jq、sha256sum を使った2つのコマンドで中核的な検証ができます。期待されるハッシュはミラーのスナップショット(独立した経路)から、実際のハッシュはお使いの環境に届いたバイト列から取得します。

curl -s https://raw.githubusercontent.com/sclaytonmyosin/graviti-engine/main/data/ledger.json \
  | jq -r '.entries[-1].files.artifacts["/index-full.json"]'
curl -s https://graviti.thesingulariti.ai/index-full.json \
  | jq -cjS 'del(.generated_at, .integrity)' | sha256sum

2つのハッシュは一致する必要があります。(JSON ペイロードは、揮発性のエンベロープフィールド generated_at と integrity を削除した後、キーを再帰的にソートし、空白を除いた正規形式でハッシュ化します。この2つのフィールドにはビルド時刻と固定対象エントリー自身のハッシュが含まれるため、固定された内容に含めることはできません。/llms.txt は正確なバイト列をハッシュ化し、jq の処理は行いません。)完全な保証を得るには、ミラーとオリジンの台帳が一致し、署名チェーンが検証されることも確認してください。上記の手順1〜2、または npm run verify:ledger を実行します。

正直なところ、検証の境界はここです: 検証に成功すれば、お使いのプロセスの境界まで届いたバイト列が、Graviti の署名付きで Bitcoin にアンカーされた記録と一致することが証明されます。検証に成功した後のランタイム内部やモデルのコンテキストウィンドウに対しては、暗号学的な保証は及びません。お使いのスタックがその後データを変更した場合、公開者側の仕組みではそれを検知できません。できる限り使用箇所の近くで検証してください。最後のホップはお使いの側で管理します。

Graviti のトラフィックを検証する — アウトバウンドの流入元特定(ブランド向け)

Graviti がブランド独自のサイトへのおすすめリンクを生成する際、決定的な UTM(utm_source=graviti、utm_medium=<surface: agent|console|scan|landscape|report>、utm_campaign=<category>、utm_content=<brand>)と署名付きの gvt トークンを付与します。これにより、リンクを受け取ったブランドは、偽装可能な UTM 文字列を信頼するのではなく、流入元が Graviti であることを証明できます。このトークン(gvt1.<surface>.<category>.<brand>.<YYYYMMDD>.<sig>)は、台帳の署名に使われるものと同じ鍵で Ed25519 署名されており、おすすめの表示面を特定しますが、ユーザーは特定しません。ユーザー識別子、クリック ID、クリックごとの値は含まれません。仕様の全文は docs/ATTRIBUTION.md をご覧ください。

node scripts/verify-attribution.mjs 'gvt1.agent.magnesium-supplements.bioptimizers.20260829.<sig>'
# or paste the full landing URL — the script extracts the gvt parameter

依存関係はなく(Node ≥ 20)、鍵は固定済みで、有効な署名の場合に限り終了コード 0 になります。対応する openssl コマンドは仕様書に記載されています。

同期の出所

src/engine.ts、scripts/verify-ledger.mjs(ヘッダーに記載されたライブ取得への適応を除く)、data/ledger.json、および data/public-key.pem は、プライベートな Graviti モノレポをコミット cf24943(2026-08-26)時点で反映したものです。エンジンファイルは一字一句そのままです。再同期はファイルのコピーとこの行の更新だけで済み、現在は台帳スナップショットの同期ごとに自動で行われます。この同期には、ルーブリックのピン留めを含むリリースが反映されています。台帳 v26 以降、各エントリーの署名対象コアには rubric フィールドが含まれます。これは、そのエントリーの下で公開されたすべてのランキングのスコアリングに使われた、コミット済みの正確な src/engine.ts の sha256 と Git blob sha1、およびピン留め元のプライベートリポジトリのコミットとこのリポジトリの URL です。これにより、同期の出所は「記載される」のではなく「検証可能」になります。

# The engine in this repo must hash to exactly what the signed ledger head pins:
git hash-object src/engine.ts
curl -s https://graviti.thesingulariti.ai/ledger.json | jq -r '.entries[-1].rubric.engine_git_blob_sha1'
# — the two must match byte for byte. Equivalently, with no git:
sha256sum src/engine.ts   # must equal .entries[-1].rubric.engine_sha256

blob ハッシュは、正規化せずにコミット済みファイルの生のバイト列に対して git hash-object を実行して計算されます。そのため、このミラーのどのチェックアウトからでも、またはピン留めされたコミット時点のプライベートリポジトリからでも、同じ値を再現できます。したがって、スコアリングの変更は公開され、差分で確認できるイベントです。その変更を含む台帳エントリーには新しいハッシュがピン留めされ、このファイルの履歴には差分が表示されます。このリポジトリのエンジンがこの検証に失敗した場合、ミラーの同期が取れていないか、チェックアウトより新しい台帳と比較していることになります。npm run verify:ledger を実行すると、同じ相互検証が行われ、どちらなのかが示されます。このリリースには、クレームの減衰クラスも含まれます。エンジンの CLAIM_DECAY_CLASSES/CLAIM_DECAY_RULES で定義される、クレームごとの鮮度ポリシー(fast は 45 日、medium は 120 日、slow は 365 日、static)により、開示された期間を過ぎたクレームはすべてのペイロードで「古い — 再検証待ち」とマークされ、クレームの深さがスコアリングに反映される場合は半分の重みでカウントされます。重みは明確に低下しますが、ゼロにはなりません。古いことは、誤りであることを意味しないためです。

レイアウト

src/engine.ts            the engine — types, laws, scoring, disclosure (verbatim production module)
data/sample-index.json   real slice of the public index so the demo runs offline
data/ledger.json         committed snapshot of the public integrity ledger
data/public-key.pem      Ed25519 public key the ledger signatures verify against
demo/run.ts              CLI demo — question in, ranked disclosure-carrying answer out
scripts/verify-ledger.mjs  no-secrets ledger verification (chain, signatures, live index hash)
scripts/verify-payload.mjs client-side transport-integrity check — pinned key, two ledger paths, replay guard
src/attribution.ts       shared outbound-attribution module (UTM scheme, gvt token format, pinned key)
scripts/verify-attribution.mjs  brand-side gvt token verifier — prove a referral came from Graviti
docs/ATTRIBUTION.md      the attribution spec: scheme, token format, signing model, privacy stance

ライセンス

Apache-2.0 — Copyright 2026 Singulariti.

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。