paceproof

PaceProof

PaceProof は、あらゆるプロバイダーの Ed25519 署名付きコンピュート証明レコードを検証し、どのレコードが真正であるかを正確に示します。

署名が欠落している、不正な形式である、または改ざんされているレコードが「検証済み」の合計に含まれることはありません。人間が読みやすい出力でも --json 出力でも、毎回、個別に集計して報告します。

PaceProof は証明に署名したり、証明を生成したりしません。別の場所ですでに署名されたレコードを取り込んで、検証、レポート作成、ダッシュボード表示を行う、中立的で読み取り専用のレイヤーです。署名済みレコードのディレクトリ、ファイル、URL を指定すると、実際に実行されたコンピュートの内容と実行者、そして各レコードの署名が正しく検証されるかどうかを、検証可能な形で示します。

インストール

paceproof-cli は npm と PyPI の両方で公開されています。

npm install -g paceproof-cli
# or
pip install paceproof-cli

どちらのコマンドでも paceproof バイナリがインストールされます。別のツールとの名前の競合を避ける必要がある場合は、両方のレジストリでエイリアスとして利用できる paceproof-cli も使用できます。

ソースからビルドする場合（コントリビュートする場合や、公開済みリリースではなくリポジトリの正確な状態を使いたい場合に便利です）：

TypeScript（MCP サーバーを含む npm パッケージ）：

git clone https://github.com/RudrenduPaul/PaceProof.git
cd PaceProof/packages/cli-ts
npm install
npm run build
node dist/bin.js --help

Python（PyPI パッケージ、独立した再実装）：

git clone https://github.com/RudrenduPaul/PaceProof.git
cd PaceProof/packages/cli-py
pip install -e .
paceproof --help

上記の公開済み npm install -g paceproof-cli と pip install paceproof-cli のコマンドは、この README の作成時にクリーンな環境で新規に実行しました。以下のクイックスタートの出力は、そのインストールで実際に得られたものであり、捏造したものではありません。

目次

• 機能
• クイックスタート
• CLI コマンドリファレンス
• ライブラリ API リファレンス
• 検証の仕組み
• 比較
• PaceProof とは何か、なぜ存在するのか
• FAQ
• コントリビュート
• ライセンス

クイックスタート

paceproof init
paceproof report ./paceproof-example

paceproof init は、新しい Ed25519 のサンプルキーペアと、証明レコードのサンプルを 7 件生成します。そのうち 3 件は正しく署名されており、4 件は意図的に破損しています（ペイロードの改ざん、誤ったキーによる署名、不正な形式の署名、署名の欠落）。これにより、verify／report で成功するケースだけでなく、実際の失敗ケースも確認できます。

公開済み npm パッケージを実際に実行した際の出力：

$ paceproof report ./paceproof-example

PaceProof report -- source: ./paceproof-example
generated at: 2026-08-04T02:54:30.898Z

== VERIFIED ==
  records: 3
  compute total: 144.50 gpu_hours

== UNVERIFIED (never counted in verified totals above) ==
  records: 4
  compute total: 1009 gpu_hours
  reasons:
    - rec-004: signature does not match record contents
    - rec-005: signature does not match record contents
    - rec-006: signature must decode to 64 bytes, got 4
    - rec-007: schema validation failed: (root) must have required property 'signature'

== BY PROVIDER ==
  acme-cloud: verified=132 gpu_hours (2 records); unverified_count=0
  beta-compute: verified=12.50 gpu_hours (1 records); unverified_count=0
  gamma-hpc: verified=(none); unverified_count=2
  delta-cloud: verified=(none); unverified_count=2

== BY WORKLOAD TYPE ==
  training: verified=128 gpu_hours (1 records); unverified_count=1
  inference: verified=12.50 gpu_hours (1 records); unverified_count=1
  idle: verified=4 gpu_hours (1 records); unverified_count=1
  unknown: verified=(none); unverified_count=1

いずれかのレコードの検証に失敗すると、verify はゼロ以外の終了コードを返します（実際の実行での終了コードは 1 で、未検証のレコードが 4 件あります）。

$ paceproof verify ./paceproof-example
Verified: 3
Unverified: 4
  FAIL rec-004: signature does not match record contents
  FAIL rec-005: signature does not match record contents
  FAIL rec-006: signature must decode to 64 bytes, got 4
  FAIL rec-007: schema validation failed: (root) must have required property 'signature'
$ echo $?
1

同じデータからダッシュボードを生成します。

paceproof dashboard ./paceproof-example --out dashboard.html

この README のために、TypeScript 版と Python 版の両方を paceproof-example に対して実行しました。どちらも上記と同じ検証済み／未検証の件数と合計値を出力しました。

機能

• プラグイン可能なデータソースアダプター。 ingest は、ドキュメント化された Adapter インターフェース（TypeScript インターフェース、Python ABC）を通じて、任意の入力を標準スキーマに正規化します。付属の jsonl アダプターは、すでに標準形式になっている改行区切り JSON を読み込みます。ComputeLedger のネイティブエクスポート用など、プロバイダー固有のアダプターも、アグリゲーター、レポートレンダラー、CLI の配線に手を加えることなく、同じインターフェースを実装できます。
• Ed25519 検証と、検証済み／未検証の厳密な分離。 すべてのレコードについて、スキーマの有効性と署名の有効性を確認します。いずれかの検査に失敗したレコードが、検証済みの合計に気付かれないまま混入することはありません。検証済みと未検証の件数および計算量の合計は、互いに重複しない集合から算出され、すべてのレポートで並べて表示されます。
• 独立して実装され、パリティテスト済みの 2 つの実装。 TypeScript パッケージ（npm）と Python パッケージ（PyPI）は、それぞれ独立した実装であり、どちらかをラップしたものではありません。同じ入力に対し、両方ともバイト単位で同一の report --json 出力を生成します。CI ジョブでは、共通のフィクスチャを使って TypeScript CLI の出力と Python CLI の出力を双方向に比較し、差異があればビルドを失敗させます。
• 自己完結型の静的 HTML ダッシュボード。 paceproof dashboard は、CSS をインライン化し、JavaScript を使わない単一の HTML ファイルを生成します。CDN フォントも外部スクリプトもなく、リモートへのリクエストも一切行いません。現在はシンプルなライトテーマのみを提供しており、ダークモード切り替え機能はまだありません。
• エージェント呼び出し用の MCP サーバー。 paceproof mcp は、verify、ingest、report を呼び出し可能なツールとして公開する Model Context Protocol サーバーを起動します。これにより、オーケストレーションを行うエージェントは、人間向けの CLI にコマンドを渡す代わりに、PaceProof をプログラムから呼び出せます。ツールハンドラーは、CLI 自体が呼び出すアグリゲーターおよびレポート関数を薄くラップするもので、MCP 用に別途再実装することはありません。
• 後付けではなく、設計段階からセキュリティを強化。 集計用のバケットは Object.create(null) で構築されるため、攻撃者が制御する provider や compute_unit の値（"__proto__" など）によって Object.prototype が汚染されることはありません。PaceProof が行う唯一のネットワーク呼び出し（ingest <url>）には、30 秒のタイムアウトと 50 MiB のレスポンス上限が適用されます。この上限は Content-Length ヘッダーを信用せず、実際にストリーミングされたバイト数に対して適用されます。すべてのスキーマフィールドには明示的な最大長が設定されているため、検証の実行前に過大な入力によってメモリを枯渇させることはできません。

CLI コマンドリファレンス

以下の各表は、公開済みの paceproof-cli npm パッケージ（v0.1.0）の実際の --help 出力からそのまま引用したものです。

paceproof init [path]

サンプル鍵ペアと、署名が有効／無効なサンプルレコードを含むサンプルディレクトリを作成します。

引数	説明
path	作成するディレクトリ（デフォルト：./paceproof-example）

paceproof verify <path>

<path> にあるすべてのレコードの Ed25519 署名を検証します。

オプション	説明
--json	人間が読みやすい表の代わりに、構造化 JSON を出力します
--adapter <name>	入力の読み取りに使用するアダプター（デフォルト：jsonl）

paceproof ingest <path-or-url>

指定したアダプターで入力を処理し、正規化された標準スキーマのレコードを JSONL として出力します。

オプション	説明
--adapter <name>	使用するアダプター（デフォルト：jsonl）
--out <file>	標準出力の代わりに、JSONL の出力をファイルに書き込みます

paceproof report <path>

<path> にあるレコードを取り込んで検証し、集計して概要レポートを作成します。

オプション	説明
--json	人間が読みやすい表の代わりに、構造化 JSON を出力します
--adapter <name>	入力の読み取りに使用するアダプター（デフォルト：jsonl）

paceproof dashboard <path>

レポートから、自己完結型の静的 HTML ダッシュボードを 1 つ生成します。

オプション	説明
--out <file>	出力する HTML ファイルのパス（デフォルト：paceproof-dashboard.html）
--adapter <name>	入力の読み取りに使用するアダプター（デフォルト：jsonl）

paceproof mcp

verify、ingest、report を呼び出し可能なツールとして公開する MCP サーバーを起動します。現時点では TypeScript パッケージのみが対象です。Python パッケージから paceproof mcp を実行すると、npm パッケージを案内するメッセージを表示し、ゼロ以外の終了コードで終了します。

すべてのコマンドは、失敗時または検証失敗時に実際にゼロ以外の終了コードを返し、すべてのサブコマンドで --help を利用できます。

ライブラリ API リファレンス

npm パッケージは内部機能も直接エクスポートしています（package.json の main／types は CLI エントリーポイントだけではなく、実際のライブラリコードを指しています）。これにより、CLI をシェルから実行する代わりに、カスタムアダプターを構築したり、別のツールに検証ロジックを組み込んだりできます。このインターフェースは TypeScript 専用です。Python パッケージが提供するのは CLI のみで、ドキュメント化されたインポート API はありません。

import { getAdapter, verifyRecords, summarize } from 'paceproof-cli';
import type { Adapter } from 'paceproof-cli';

const records = await getAdapter('jsonl').read('./paceproof-example/records.jsonl');
const outcomes = verifyRecords(records);
const report = summarize(outcomes);

エクスポート	シグネチャ	機能
Adapter	interface Adapter { readonly name: string; read(input: string): Promise<RawRecord[]> }	上述の拡張ポイントです。新しいプロバイダーのエクスポート形式を正規レコードに正規化するために実装します。
getAdapter(name)	(name: string) => Adapter	登録済みのアダプターを名前で検索します（jsonl は組み込みです）。名前が登録されていない場合は例外をスローします。
verifyRecord(raw)	(raw: RawRecord) => VerificationOutcome	単一のレコードについて、スキーマ検証と署名検証を行います。
verifyRecords(raws)	(raws: RawRecord[]) => VerificationOutcome[]	バッチ内の各レコードに対して verifyRecord を実行します。
summarize(outcomes)	(outcomes: VerificationOutcome[]) => ReportSummary	検証結果を集計し、paceproof report --json が出力するものと同じ、プロバイダー別・ワークロードタイプ別の検証済み／未検証の構造にまとめます。
verifyRecordSignature(record)	(record: AttestationRecord) => SignatureCheckResult	以下で説明する正規 JSON エンコーディングを対象に、Ed25519 署名のみを確認します（スキーマ検証は別途行います）。
canonicalizeRecord(record)	(record: Record<string, unknown>) => Uint8Array	署名の計算と検証に使う正規バイトエンコーディングを生成します。キーを辞書順に並べ、UTF-8 を使用し、不要な空白は含めません。
buildCli()	() => Command	公開 CLI 自体が実行する Commander.js の Command インスタンスを返します。引数解析を再実装せずに、CLI を組み込んだり拡張したりできます。

個別に生成される API ドキュメントサイトはありません（CI で TypeDoc をビルドする設定はまだありません）。サイトができるまでは、上の表がリファレンスです。すべてのシグネチャは記憶に基づいて再構成したものではなく、2026-08-03 に packages/cli-ts/src/ を直接検索して確認したものです。

検証の仕組み

すべてのアテステーションレコードは、単一の標準 JSON Schema（schema/attestation-record.schema.json）に照らして検証される JSON オブジェクトです。これは、TypeScript パッケージと Python パッケージの両方に同一のバイト列で含まれ、どちらもこのスキーマを使って検証します。レコードには record_id、issued_at、provider、hardware、workload_type、compute_amount、compute_unit、issuer_public_key、signature が必要です。すべての文字列フィールドには明示的な最大長が設定されているため、不正な入力や過大な入力は、まず解析して後から制限するのではなく、すぐに拒否されます。

signature フィールドは、他のすべてのフィールドを標準化した JSON エンコーディングに対する Ed25519 署名です。オブジェクトキーは辞書順に並べ、UTF-8 でエンコードし、不要な空白を含めず、数値は先頭の + や不要な末尾のゼロを付けずに表現します。どちらの実装でも同じレコードからバイト単位で同一の標準化 JSON が生成されるため、一方の実装で検証された署名は、もう一方の実装でも検証できます。

レコードが「検証済み」となるのは、スキーマに適合し、かつ署名が有効であるという両方のチェックに合格した場合のみです。それ以外（署名がない、署名をデコードした結果のバイト長が正しくない、署名がペイロードと一致しない、誤った鍵で署名されている）は「未検証」となります。アグリゲーターのコードでは、この2つの集合は常に互いに重複しません。レポート上の表示方法だけの話ではありません。検証済みと未検証の計算量の合計は別々の構造体に集計され、未検証レコードの compute_amount が検証済みの合計に加算されるコードパスはありません。「申告された」数値と「証明された」数値を気付かれないように混同するレポートツールは、検証不能な申告を検証済みに見せかけてしまい、監査証跡の目的を損ないます。

比較

以下のスター数と説明は、2026-08-03に各プロジェクトのGitHub APIリスティングとREADMEをリアルタイムで確認したものであり、捏造したものでも、記憶をもとに再利用したものでもありません。

プロジェクト	スター数	概要	PaceProofとの違い
meghabyte/verifiable-training	10	Stanford NeurIPS 2024の研究コード（「Optimistic Verifiable Training by Controlling Hardware Nondeterminism」）です。ハードウェアの非決定性を排除して、異なるGPU間でもトレーニング実行によってバイト単位で同一の重みが再現されるようにし、チェックポイントのMerkleツリーを構築して、検証者が監査できるようにします。	重みのレベルで「主張どおりに特定のトレーニングが実施されたこと」を証明する、証明書生成の研究プロトタイプであり、取り込み／検証／レポート用のツールではありません。アダプターも、既存の署名済みレコードをプロバイダー横断で取り込む機能も、CLIも、言語間の同等性も、MCP インターフェースもありません。
skypilot-org/skypilot	10,441	20以上のクラウド、Kubernetes、Slurmに対応した、マルチクラウドのAIコンピューティングのオーケストレーションと、コストを考慮したスケジューリングを行います。	コストと利用率の「可視化とスケジューリング」を行うものであり、暗号学的な検証は行いません。署名を検証したり、「検証済み」の数値と「申告済み」の数値を分けたりすることはなく、証明書レコード形式も一切関与しません。
opencost/opencost	6,659	Kubernetesおよびクラウドのコスト監視と、コスト配分の可視化を行います（Apache 2.0、旧Kubecost）。	SkyPilotと同じカテゴリです。請求データやメトリクスデータをもとに使用量とコストを「可視化」するものであり、暗号学的な証明ではありません。Ed25519検証も、検証済み／未検証の区分も、証明書レコードのスキーマもありません。
RudrenduPaul/ComputeLedger	0	プロバイダーに依存しないCLI、ライブラリ、MCP サーバーです。Ed25519署名と改ざん防止機能を備えたローカル台帳を使用して、コンピューティング使用量のレシート（GPU時間、ハードウェア、ワークロードの種類）への「署名」、ハッシュチェーンの作成、独立した検証を行います。	競合ではなく、相互補完的なものです。同じ作者による姉妹プロジェクトであり、この問題における「証明書生成」の側を担います。PaceProofは「取り込み／検証／レポート」の側を担います。ComputeLedgerのレコード、またはEd25519で署名する他のあらゆるソースのレコードを入力すると、検証できる内容をレポートします。

「複数のプロバイダーから署名済みのコンピューティング証明レコードを取り込み、Ed25519署名を検証し、検証済みと未検証の合計を分けて保持する」という、直接比較可能なツールをより広範囲に検索しましたが、2026-08-03時点で、この特定の組み合わせに合致するものは他に見つかりませんでした。最も近い関連カテゴリは、汎用のハードウェア・リモート証明検証（例：veraison/services、スター数47、TPM／SEV-SNP／SGX／TDXの証拠）です。これは別の証明領域（コンピューティング使用量のレコードではなく、ハードウェアの起動時／実行時の状態）を対象としており、コンピューティング証明のスキーマも、アダプターモデルも、コンピューティング時間のレポート機能もありません。

PaceProof とは何か、なぜ存在するのか

AI 研究機関、クラウドプロバイダー、インフラ運用者による計算リソース使用量の申告は、計算リソースに関する議論の量が増えるにつれて、独立した検証が難しくなっています。2026 年 7 月に OpenAI、Anthropic、Google DeepMind、Meta の従業員 1,000 人以上が署名し、最先端 AI 開発のペースを調整するための検証可能なツールを求めた、実在する「Pacing the Frontier」公開書簡は、この業界の議論の一例です。ここでは背景情報としてのみ引用しています。PaceProof はこの公開書簡と提携しておらず、署名者からの要請に応じて開発されたものでもなく、支持や提携を受けていると主張するものでもありません。

この README で明確にしておくべき点を率直に述べます。**実在する「Verified Slowdown」条約はなく、そのような条約は現在存在しません。**この表現は ai-2027.com の推測に基づく予測シナリオに由来するものであり、実際の国際協定、法律、規制機関に由来するものではありません。PaceProof は、そのような条約、法律、規制を実装、施行、または遵守認証するものではありません。このツールに適用される条約、法律、規制は存在しないためです。

PaceProof の実際の機能は、すでにお持ちの計算リソース認証データに対する、中立的で暗号学的に検証可能なレポートレイヤーです。ご自身（または取引先のプロバイダー）が、ComputeLedger、独自の署名パイプライン、あるいは Ed25519 署名付きレコードを生成するその他の手段を通じて、すでに署名済みの認証レコードを作成している場合、PaceProof は暗号学的に有効なレコードを判定し、有効なレコードのみを合計して、無効なレコードとは明確に分けて提示します。これは、社内監査証跡やプロバイダー間の使用量の透明性を確保するうえで、現在役立ちます。存在しない規制に対するコンプライアンスソフトウェアではなく、そのようなものだと主張することもありません。

よくある質問

PaceProof とは何ですか。一般的なコスト監視ツールとの違いは何ですか？ PaceProof は読み取り専用の CLI および MCP サーバーで、計算リソース認証レコードの Ed25519 署名を検証し、検証済みの数値と未検証の数値を厳密に分け、決して統合せずに合計を報告します。SkyPilot や OpenCost のようなコスト可視化ツールは、課金システムが使用量として示す内容を報告します。一方、PaceProof は暗号署名によって実際に証明される内容を報告し、それ以外は暗黙のうちに合計へ加えるのではなく、未検証として明示します。

PaceProof は法律や規制へのコンプライアンスを提供しますか？ いいえ。PaceProof が遵守すべき実在する「Verified Slowdown」条約や同等の規制はなく、PaceProof はいかなる種類のコンプライアンスも主張しません。渡されたレコードの Ed25519 署名を検証し、その結果を報告します。その出力は暗号学的検証レポートとして扱い、法的または規制上の認証として扱わないでください。

PaceProof は認証レコードに署名したり、生成したりしますか？ いいえ。PaceProof は読み取り専用です。すでに別の場所で署名されたレコードを取り込み、検証し、報告します。署名付き計算リソース認証レコードを生成する必要がある場合、それは別の役割です。署名を行う同じ作者の姉妹プロジェクトである ComputeLedger をご覧ください。

PaceProof と ComputeLedger の違いは何ですか？ この 2 つは競合するものではなく、相互に補完するもので、同じ作者によって開発されています。ComputeLedger は計算リソース使用量の受領記録に署名してハッシュチェーンを構築します。PaceProof は、ComputeLedger を含む、Ed25519 署名を行うあらゆるソースから、すでに署名されたレコードを取り込んで検証します。署名付きレコードを作成する必要がある場合は ComputeLedger を、すでにお持ちのレコードを独立して検証する必要がある場合は PaceProof をご利用ください。 不正な署名を持つレコードはどうなりますか？単に破棄されるのですか？ いいえ。スキーマ検証または署名検証に失敗したレコードが破棄されたり、気付かれないまま除外されたりすることはありません。unverified_count に計上され、計算量は unverified_compute_total_by_unit に分けて合計されます。また、失敗した具体的な理由（改ざんされたペイロード、誤ったキー、不正な形式の署名、フィールドの欠落）も併せて報告されます。検証に失敗したレコードの情報が出力から消えることはありません。

エクスポート形式が JSONL ではないプロバイダーのサポートを追加できますか？ はい。そのためのアダプターインターフェースです。Adapter インターフェース（TypeScript）または Adapter ABC（Python）を実装します。必要なのは、name と、レコードを正規スキーマに正規化した状態で返す read(input) メソッドです。新しいアダプターの名前を登録する以外に、アグリゲーター、レポートレンダラー、既存の CLI の配線に手を加える必要はありません。

paceproof ingest <url> は任意のネットワーク呼び出しを行いますか？ 明示的に要求した呼び出しだけです。それ以外のコマンドはすべてローカルファイルを対象に動作します。ingest <url> はツール全体で唯一のオプトイン方式のネットワーク呼び出しで、制限も設けられています。タイムアウトは30秒、応答サイズの上限は50 MiBです。この上限は、リモートサーバーが偽装できる Content-Length ヘッダーだけではなく、実際にストリーミングされたバイト数に対して適用されます。

PaceProof は Windows、macOS、Linux で動作しますか？ npm パッケージには Node.js 18 以降が必要で、OS 固有のコードは含まれていないため、Windows、macOS、Linux を含め、Node が動作する環境で実行できます。Python パッケージには Python 3.10 以降が必要で、PyPI では OS Independent として登録されています。どちらも純粋なユーザーランドのツールで、ネイティブコンパイルされた依存関係はありません。

バインディング付きの CLI ひとつではなく、実装が2つあるのはなぜですか？ 各パッケージを、もう一方の言語のランタイムを取り込まずに、それぞれのパッケージレジストリ（npm または PyPI）からインストールできる独立したものにするためです。共有の JSON Schema ファイルと、クロスランゲージのパリティテストスイート（CI で双方向に実行）が両方の report --json 出力の一致を保つため、どちらの実装を選んでも得られる結果は変わりません。

MCP サーバーは Python パッケージで利用できますか？ 現在は利用できません。paceproof mcp は今のところ TypeScript 専用です。Python パッケージから実行すると、npm パッケージを案内するメッセージを表示して、ゼロ以外の終了コードで終了します。それ以外のコマンド（init、verify、ingest、report、dashboard）はすべて、Python で完全に独立した実装となっています。

PaceProof のライセンスは何ですか？商用利用できますか？ MIT です。PaceProof は、ロイヤリティの支払いも、自作コードをオープンソースにする義務もなく、商用利用、改変、再配布ができます。ただし、MIT ライセンスの条件に従って著作権表示とライセンス文を保持する必要があります。

貢献

CI（.github/workflows/ci.yml）では、main へのすべてのプッシュと PR に対して3つのジョブを実行します。TypeScript の lint、型チェック、テスト、Python 3.10 および 3.13 を対象とした Python の lint（ruff）、型チェック（mypy --strict）、テスト（pytest）、さらに TypeScript CLI をビルドして Python CLI をインストールし、各側のパリティテストをサブプロセスとして相手側の CLI に対して実行するクロスランゲージのパリティジョブです。

すべてのチェックをローカルで実行するには、次のコマンドを使います。

# TypeScript
cd packages/cli-ts
npm install
npm run lint
npm run typecheck
npm test        # 60 tests, Vitest

# Python
cd packages/cli-py
pip install -e ".[dev]"
ruff check src tests
mypy src
pytest -q       # 52 tests

スキーマを変更する場合は、リポジトリルートの schema/attestation-record.schema.json と、packages/cli-ts/schema/ および packages/cli-py/src/paceproof_cli/schema/ 配下のコピーを更新し、両方の実装の検証ロジックも更新してください。各パッケージのテストスイートにあるパリティテストが、ローカルのスキーマコピーとルートのファイルを照合し、内容が異なる場合は CI を失敗させます。

リポジトリ全体の構成、署名の計算対象となる正規 JSON のルール、アダプターインターフェースと MCP サーバーの連携については、ARCHITECTURE.md を参照してください。

ライセンス

MIT です。LICENSE を参照してください。