01 / SIGNED RECORDS
署名された記録
一件ごとの署名は確かめられる。しかし、このままでは前後のつながりは分からない。
OPEN SOURCE / SELF-HOSTED
信頼とは、真実の保証ではなく、嘘の帰属可能性である
データが通った道を、検証できる形で残す。
誰が何を受け取り何を出したかを署名付きで記録し、処理の経路としてつなぐ。
受け手が、自分の環境でその経路を確かめられる。
— 主張は、読むものではなく実行して確かめるもの。
TAMPER DEMO
偽造は、次の境界で止まる
3 組織を起動し、途中で payload を偽造する。下流には届かない。以下は実行の実出力。
provin tamper demo — three organizations, one forged payload
[1/6] starting three organizations (manufacturer / distributor / retailer), each with its own registry …
[2/6] manufacturer ingests lot LOT-2026-08-06: signed FirstDrop credential issued (did:dplaax:mfg.poc.dplaax.dev:org:mfg:pipeline:lot-emissions:process:reporter)
credential hash sha256:fdd3e6684bfa495ca0c2e08468260f417000dfb05983b45735f610f3d245029d
[3/6] distributor transforms and delivers → retailer verifies the chain and ACCEPTS
retailer delivery records: 1 (bound to verified evidence view sha256:4da4cd872f35ae635c6ec666d2d2e1266a2345f57193477180a9ec3bdb7b8fd4)
[4/6] adversary republishes the manufacturer envelope with a FORGED payload (lot swapped)
[5/6] relay HALTS at the next boundary — signature no longer matches the recorded output
retailer delivery records: 1 (unchanged — the forged payload never arrived)
[6/6] evidence survives: exported bundle re-verifies offline → PASS
done in 12s — trust is not a guarantee of truth; it is the attributability of lies.
手元で再現するのに要るのは Docker だけ:
git clone https://github.com/provin-line/e2e
cd e2e
make demo初回はイメージのビルドを含めて数分、以降はおよそ 20 秒で完走する。assertion 付きの全量は scenarios/supplychain にある。
MANIFESTO
内容が真実であることは、
原理的に証明できない
これは技術の未熟ではなく限界そのものである。
AI の台頭は、この限界を例外から常態に変えた。
検証不能な処理段 — AI 推論、人間の判断 — がパイプラインの標準部品になり、 同時に、もっともらしい成果物の偽造コストがゼロに近づいたことで、 「内容の出来栄えから信頼を推定する」という従来の経路が閉じた。
内容を保証できないなら、残る手段はひとつしかない。嘘の事後コストを上げることである。 事後コストは帰属なしには発生しない — 誰の嘘か特定できないものは、罰することも、 訴えることも、評判を下げることもできない。そして組織間で、単一の運営者を置かずに 帰属を成立させる方法は、境界ごとの署名の連鎖しかない。
この抑止には成立条件がある。守る価値のあるアイデンティティを持ち、帰結が届く相手にしか効かない。 だが、この条件は企業社会ではすでに満たされている。企業とは、失えば存続できない信用を 積み上げた主体であり、組織間の経済はもともと「名前を賭けた約束」で回ってきた。 契約も、監査も、簿記も、内容の真実を保証する装置ではない。嘘を帰属可能にする装置である。
ゆえに、AI 時代の信頼とは「内容が正しいことの証明」ではなく、 「すべての主張が、失うものを持つ主体に、否認不能に帰属していること」 である。 provin は、その帰属をデータパイプラインを用いて、組織間で、運営者なしに、 暗号的に成立させる選択である。
— 帰属は、意思決定の道具になる — 入口では断り、事後では辿る。
WHAT YOU CAN DO
受け取る前の確認にも、
問題が起きたあとの調査にも
入口の判断と、あとからの追跡。どちらにも同じ来歴記録を使う。
- 使う前に確かめる 署名と前後のつながりを確認し、自分たちのルールに合わないデータは、その場で受け入れない。
- 問題の入り口まで戻る 最終出力から記録をさかのぼり、どの処理でつながりが切れたか、誰がその区間を発行したかを追う。
- 時間がたっても確かめ直す 保存した来歴記録をもう一度検証し、データの出どころや扱われ方を説明する材料にする。
- 相手のシステムに頼らず検証する 受け手や第三者が証拠一式を持ち出し、自分の環境と判断基準で同じ記録を確かめる。
— 「含まれ得ない」と言えるのは、誰かが「これで全部だ」と保証したときだけ。
CLAIM SEMANTICS
排除を語れるのは、
署名ではなくクレーム
すべての記録には、処理が何であったかの宣言 — transformationClaim — が乗る。その宣言が何を保証するかを確定させるのが、provin wire profile の仕事。
検証で本当に知りたいのは、しばしば「含まれているか」ではなく「含まれ得ないか」 — このロットは、あの出力に使われ得たか。この排除の推論を成立させるのは、署名でもハッシュ連鎖でもない。発行者が「宣言した入力が、この出力の情報源のすべてだ」と保証したこと — クレームの閉世界性である。
| ラベル | 閉世界性 |
|---|---|
provin:filter | closed — 宣言した入力が情報源のすべて |
provin:convert | closed |
provin:filter-convert | closed |
provin:aggregate | closed fold — 宣言した入力集合の畳み込み |
provin:enrich | conformant-closed — 排除推論は適合フローに限る |
provin:generate | open — 宣言した入力の外に情報源を認める |
provin:sink-receipt | identity — 変換ではなく受領 |
- 同じ形、違う保証 —
provin:enrichとprovin:aggregateは同じ N:1 の形。しかし enrich はチェーンが覆わない外部データを結合するため、排除推論は適合フローに限って成立する。形では区別できないものを、クレームが区別する。 - AI 推論は open —
provin:generateの支配的な情報源はモデルの重み、すなわち学習コーパス。これを aggregate と宣言すれば、何も閉じていない出力に閉世界の読みを偽って許可することになる。検証不能な処理段を、来歴の語彙として正しく扱う — マニフェストが立てた問題への、語彙のレベルでの答え。 - 保証が偽なら、保証した主体に帰属する — 閉世界の保証は、宣言が正しいときに成立する。誤った宣言は偽の排除推論を導く — そしてその保証は、署名した主体に否認不能に帰属する。この非対称は設計の欠落ではなく、設計そのもの。
supplychain は、線形プロファイルに加えて入力集合の束縛(SOURCE_SET_BINDING)まで要求する厳格プロファイルと、検証済み evidence view に束縛された exact-view 配送を 3 組織構成で確認済み。 — 嘘のコストは、具体的な現場でだけ発生する。
USE CASES
組織やシステムをまたいでも、
データの流れを追える
provin が役に立つのは、データが組織やシステムの境界を越え、誰が扱い、何が入り、何が出たのかを受け手が確かめられなくなったとき。
受け渡しごとに「どの入力からどの出力を作ったと誰が主張しているか」を署名付き credential として記録し、受け手はその証拠を自分の環境と方針で確かめられる。 今あるリネージュ管理や業界システムを置き換えるのではなく、その管理が切れる受け渡し部分に、あとから検証できる記録を残す。
-
不具合の影響範囲をたどる
製造業のリコールや複数サービスをまたぐ ETL/ELT では、問題のある入力がどの出力まで使われたかを追う必要がある。
処理ごとの記録をつなぎ、問題のある入力からその先の出力までをたどる。
※ 公開 E2E のrecallで署名された入力から宣言された派生先（線形連鎖）への追跡を、branchingで分岐・フィルタ配送を確認済み。 -
組織間で受け渡したデータを照合する
サプライチェーンや企業間 API では、どのデータを受け取り、何を返したのかを双方で照合できる記録が必要になる。
署名付き記録を受け手の環境へ持ち込み、その場で検証する。
※ 公開 E2E のsupplychainで、3組織を模したデータの受け渡しと検証を確認済み。 -
元のシステムがなくなったあとも検証する
監査の時点で、元のサービスや鍵の提供先が残っているとは限らない。それでも、当時の処理経路を確かめられる状態を保つ必要がある。
検証に必要な記録をまとめて保存し、稼働中のシステムから切り離した環境でも再検証する。
※ 公開 E2E のarchiveverifyとaggregatebundleでオフライン検証を、auditsurvivalで再起動後の永続性を確認済み。 -
処理の成功と配送の失敗を分けて残す
処理が終わったことと、次のシステムへ届いたことは同じではない。IoT やイベント処理では、この差をあとから判別できる記録が必要になる。
処理と送信の記録を分けて残し、「処理は成功したが届かなかった」状態を追う。
※ 公開 E2E のlosswindowで、配送ロスが送信記録に残ることを確認済み。 -
集約に使った入力を確かめる
集約値だけが残っていても、どのセンサ値や特徴量が使われたのかは分からない。出力と入力の組み合わせを残す必要がある。
入力の集合への署名付きコミットメントを記録し、特定の入力がその集合に含まれていたかを検証する。
※ 公開 E2E のsensoraggregateとaggregatebundleで、入力集合への署名付きコミットメントと包含照合を確認済み。
— 署名の連鎖は、データが動くその瞬間にしか作れない。
HOW IT WORKS
受け取ったら確かめ、
渡す前に記録する
データが流れる、その場で来歴をつなぐ。
01
受信
入力と直前の記録を受け取る
02
検証
署名と連続性を確かめる
03
処理
評価・変換を実行する
04
署名
入出力を新しい記録に束ねる
05
受け渡し
データと来歴を次へ渡す
処理を始める前に、受け取ったデータと来歴記録を照合する。 処理が終わったら、生成側のプロセスが入力・宣言した処理・出力を署名付きで記録し、次へ渡す。 署名が証明するのは記録の帰属で、宣言された処理内容そのものの正しさではない。
あとからログを集めて推測するのではなく、データが動いた時点で来歴を残す。 受け手が証拠一式 — 記録に加えて、検証に要る鍵・コントローラ文書 — を保管しておけば、 発行元のデータベースが変わったあとでも同じ内容を検証できる。
CURRENT INTERFACES
いま接続できるもの
現在の 0.x 実装で使える接続方法と実行構成。予定中のアダプタは含まない。
- HTTP push — JSON データを Source Process に取り込み、最初の署名付き記録（FirstDrop credential）を発行する。
- Core NATS — 処理間のイベントを配送し、operator / account JWT と subject grant で組織境界を構成する。
- ConnectRPC + Protobuf — DID、スキーマ、チェーン、credential/resolver、監査の 5 サービス API を公開する。
- JSON processing — JSON Schema（既定 2020-12）で入出力を検証し、JSONata でフィルターと1対1の変換を実行する。
- Custom Process contract — 用途ごとの入出力を、共通のパイプライン契約へ接続する。
プロトコルと実装の関係
dPLaaX は、データを引き渡す境界で何を記録し、その記録をどうつなぎ、検証するかを定めるプロトコル。provin はその参照実装として、通信仕様（wire profile）、実行環境、各種サービス、運用者向け CLI を提供する。did:dplaax と dplaax.*.v1 は、このプロトコルで使う識別子と API の名前空間になる。
現在の構成
- provin node —
cmd/network（管理系）とcmd/pipeline（データ処理系）の 2 バイナリ構成。同一ホストでも別ホストでも動き、連携は wire 経由のみ。証拠保存はファイルベースで、現在の参照用ストアは YAML とファイル。 - NATS — データ処理系で、処理間のイベントを運ぶ。
- 認可判定（PDP）と認証 — API の認可には、o3co、OPA、Cedar、またはプロセス内の static backend を選択（backend 実装は companion ライブラリ由来）。static は許可リストであり、認証機能ではない。
provin node 自体は、データベースなしでも動作する。ストレージと PDP はインターフェースで差し替えられるが、データベースを使うレジストリや、特定のデータベース連携は同梱していない。選択する認証プロバイダー、PDP、アダプターによっては、別途データベースや外部サービスが必要。
— 一つの証明では、嘘は帰属できない。
WHY THE COMBINATION
署名だけでは、
経路までは分からない
署名が示すのは、一件の記録。前後の記録とログを重ね、処理の流れとして検証する。
検証結果
- 署名 確認
- 発行者 確認
- 連続性 確認
署名された記録 記録はある。経路はまだ見えない。 一件ごとの署名は確かめられる。しかし、このままでは前後のつながりは分からない。
前後の記録をつなぐ 入出力の記録がつながり、経路が見える。 直前の記録と入出力のハッシュを結び、処理の経路としてつなぐ。
別の環境で検証する 受け手が、自分の環境から経路を確かめる。 受け手が証跡を持ち出し、署名・発行者・入出力の連続性を自分の環境で確かめる。
- 署名 — その記録が変わっていないと分かる 誰が発行したか、署名後に内容が変わっていないかを確認する。一件の前後で何が起きたか、途中に記録を残さなかった処理境界が抜けていないかは、署名だけでは分からない。
- Transparency Log — 登録後の削除や差し替えを見つける 記録が存在したことと登録順を残し、あとからの削除や差し替えを見つけやすくする。隣り合う記録が同じデータの入出力か、受け取った実データが記録と一致するかは、ログだけでは分からない。
- 認証・認可 — 組織の内側を守る 組織内では、共通の ID とポリシーで利用者や操作を管理。データが組織の外へ出ると、その管理は付いていかない。受け手が自分で確かめられる記録が必要になる。
provin の組み合わせ
- データを渡す境界ごとに署名する — その時点の発行者、処理、入出力を記録する。
- 前後をハッシュでつなぐ — 直前の記録と入出力のハッシュを結び、処理のつながりを確認する。
- 追記型のログに残す — 署名付き記録、送信・受領記録、監査結果を保持し、欠落や変更をあとから調べる。
- 証拠一式を持ち出す — 必要な記録を bundle にまとめ、発行元の環境から離れた場所でも検証する。
一件ずつの署名を一本の線につなぎ、どこへでも持ち出せる記録にする。これが provin の基本。
— 検証とは、他人の主張を自分の環境で再演すること。
VERIFICATION
一件の署名ではなく、
前後のつながりを見る
最終出力だけを見ても、どの入力と処理からできたのかは分からない。前後の記録を照合し、その経路を追う。
- 記録の完全性 誰が発行した記録かを確認し、署名後に内容が変えられていないかを検出する。
- 処理のつながり 直前の記録への参照と入出力のハッシュを照合し、記録どおりにつながっているかを見る。
- 別の環境での再検証 必要な記録と権限情報を持ち出し、稼働中のネットワークから離れた場所で同じ結果を確かめる。
EVIDENCE
設計主張ではなく、実測結果
すべての数字は公開 commit に固定されたスナップショット上で測定され、独立に監査できる。
改竄停止(公開 E2E)
0
改竄ペイロードの下流配送
三組織構成の E2E(単一ホスト・プロセス分離)で改竄を注入 — 中継は停止し、受信側の配送記録は増加しなかった
性能(bench)
~123 µs
クレデンシャルあたりの受理経路コスト
連鎖深さに線形 — メモリ内解決で深さ 512 まで実測
186 ms → 45 ms
解決キャッシュの効果(深さ 32 の配送)
1 ms/呼の解決遅延を課した条件で実測 — TTL・バイト数で有界なオプトイン実装
トランスポートをインプロセスのストアに置換して測定した値 — ネットワーク配備における下界。各ベンチマークは模していない要素を明記している。
— 何を保証しないかを言えることも、帰属の一部である。
SCOPE
検証すると、
ここまで分かる
確かめるのは、記録されたデータの受け渡しと、そのつながり。
- 誰が発行したか — 署名から、各処理の記録を発行した主体を確認する。
- あとから変わっていないか — 署名後の変更を検出し、受け取った記録の完全性を確認する。
- 前後の処理がつながっているか — 直前の記録と入出力のハッシュを照合し、記録された経路をたどる。
- 別の環境でも同じ結果になるか — 必要な記録を持ち出し、受け手や第三者の環境でもう一度検証する。
GET STARTED
まずは動かしてみる
Go 1.25 でビルドできる。まずはテストを実行し、技術仕様ページのサンプルで署名付き記録と検証結果を確かめる。
git clone https://github.com/provin-line/oss
cd oss
make build
make test認証を含む E2E 構成、CLI、設定例もリポジトリに入っている。固定した入力を使った検証サンプルは、技術仕様ページで確認できる。
STATUS
コードもテストも、
公開中
現在は 0.x の PoC。実装と E2E は公開済みで、手元でも動かして確かめられる。これは本番運用の認証ではなく、公開した試験条件での挙動を再現できる形で示すスナップショット。
現在の公開スナップショットは実証論文の評価ライン — provin OSS v0.3.0、provin e2e v0.2.0、provin auth v0.2.1、dPLaaX spec v0.1(draft)。公開 E2E は process 版と Docker Compose 版の両方で 11 シナリオ — 3 組織間の受け渡し、分岐、集約、リコール、再起動、配送ロス、オフライン検証 — を完走している。
認証(provin auth)の既定は LEGACY_DID_LOGIN@1 — DID Document の関係(authentication / assertionMethod)は検証しない。OWNER 契約(関係検証・三者 kid 一致・audience 必須)は main で配線済みで次リリースに乗る。現行リリース v0.2.1 は LEGACY のみ。
provin は 0.x の PoC。詳しい検証条件と対象範囲は、公開 E2E・技術仕様・実証論文(近日公開)に記載。