監査可能性｜日次ハッシュチェーンと外部アンカリング、検証手順

01責任分界

当社は、観測事実と方法論の正確性に責任を持ちます。
利用者は、意思決定とその結果に責任を持ちます。

この整理により、当社が負う責任は明確かつ検証可能な範囲に限定されます。「儲かるかどうか」ではなく、「観測が正確か、算出過程が記載どおりか」が問われる対象になります。契約で表示責任を配分することはできますが、データ品質への責任は移転しません。

02監査経路

三層構造の各出力は前層へのポインタを保持します。ひとつの Confidence 値から、生のレスポンスボディのハッシュまで降りられます。

Confidence 92
    ↑ confidence_model_v0.1（因子と重みを公開）
Demand Index 84
    ↑ index_v0.3（算出式を公開）
Normalized volume
    ↑ 較正係数 v0.2（アンカーと推定誤差を公開）
Market: DESIGN > BRANDING > LOGO_DESIGN
    ↑ ontology_v0.2（対応表を公開）
Observation: Coconala cat-1002, listing_count=8,241, 2026-08-25
    ↑ parser_v0.1
Raw object: raw/coconala/2026/08/25/... sha256:e3b0c4...
    ↑ 日次チェーン、外部アンカリング済み

この経路を支える3つの原則

Raw-first。一次資産は生のレスポンスボディであり、集計値ではない。パーサはいつでも書き直せるが、生データは二度と取得できない
Immutable / Append-only。一度書いたオブジェクトは上書きも削除もしない。修正は新しいオブジェクトの追加として表現する
パース結果は一次オブジェクトへのポインタを必ず持つ。再パース時は行を更新せず、新しい parser_version の行を追加する

03日次チェーン

1日1回、取得の成功・失敗を全て記録したマニフェストのハッシュを、前日のチェーンヘッドと連結します。初日の prev_chain_head はゼロ64桁です。

chain_head(D) = SHA256( prev_chain_head || sorted_concat(manifest_hashes) || date )

自社のストレージ内だけで完結したチェーンは、自社が全体を作り直せてしまうため、第三者に対する証明になりません。chain_head は毎日、自社の管理外に固定します。

アンカー 1

OpenTimestamps — ブロックチェーンにアンカー。検証可能性が最も強い

アンカー 2

公開 Git リポジトリへの日次コミット — ホスティング事業者のタイムスタンプに依存。片方が停止しても記録が残る

記録される仕様

各レコードに spec_version を含める。仕様を変更した日はチェーン上で特定可能

日次チェーンレコード
date	chain_head	prev_chain_head	manifests	spec	anchors
2026-08-25	初回実行後に記録	000000000000…000000	coconala — fiverr —	0.2	opentimestamps: — git: —

レコードは新しい日付から順に表示します。manifests はプラットフォームごとのマニフェストファイル（object_key 昇順にソートした全体）の SHA-256 です。

04検証手順

第三者が「過去を遡って書き換えていない」ことを確認する手順です。当社のサーバーを信頼する必要はありません。

検証したい日 D のチェーンレコードを取得するこのページの一覧、または公開 Git リポジトリの chain/D.json から取得します。
D−1 の chain_head が D の prev_chain_head と一致することを確認する一致しなければ、どちらかのレコードが差し替えられています。
D の chain_head を再計算するSHA256( prev_chain_head || sorted_concat(manifest_hashes) || date ) を計算し、レコードの値と比較します。
外部アンカーのタイムスタンプを確認するOpenTimestamps の証明ファイル、または Git のコミット日時が、D の翌日以前であることを確認します。これにより D 以降に chain_head を作り直していないことが分かります。
Signal Validation Log の対象集合ハッシュを照合する事前登録日のレコードに、仮説の対象集合ハッシュが含まれていることを確認します。

マニフェスト行の内容や生データ自体は公開しません。公開するのはハッシュとチェーンであり、これで「後から差し替えていない」ことの検証には十分です。

05取得しないもの

以下は実装上のガードとして組み込んでいます。設計文書に書くだけでは守られないためです。

ログインを要するページ。クローラに認証情報を持たせません。持たせなければ越えられません
個人を特定できる情報（出品者名、プロフィール文、アイコン画像）。出品者ランクや評価件数は集計値として保持しますが、識別子と個人属性を紐づけて保持しません
取引情報、メッセージ、購入者情報
robots.txt で拒否されているパス
有償データプロバイダの規約で再配布が禁止されている範囲

アクセスの規律（頻度、間隔、User-Agent、429/503 時の中断、回避策の不実装）はクローラーについてに記載しています。

06仕様変更の扱い

spec_version はチェーンレコードに記録されます。仕様を変更した日は、チェーン上で特定可能でなければなりません。仕様変更を静かに行いません。

取得仕様は観測開始前に v0.1 → v0.2 へ改訂されたため、チェーン上には spec_version: "0.2" から記録が始まります。v0.1 で取得したデータは存在しません。

指数の算出方法を、後から改竄していないことを第三者が検証できる。