Trustviceのレシートは、お客様の文書、プロンプト、応答の本文ではなく、SHA-256ハッシュとメタデータに基づいています。その選択の背後にあるプライバシー設計、それが守るもの、そしてそれだけではお客様を守れない場面についてご説明します。
執筆：The Trustvice team約3分で読了
お客様のデータについての証拠に署名するサービスには、わかりやすい誘惑があります：データを証拠の中に入れてしまうことです。そうすれば検索もサポートも楽になり、より充実したダッシュボードも作れるでしょう。当社は早い段階で、Trustviceのレシートはそうしないと決めました：レシートが持つのは、記述する対象のハッシュであって、コンテンツではありません。
この記事では、その理由と、お客様自身の協力なしには設計の保護が及ばなくなる場面をご説明します。
レシートが役に立つのは、誰かに渡せる場合だけです：監査人、相手方、調停人。その中身は、渡した相手なら誰でも読めます。レシートがコンテンツを持っていたら、共有するたびに何かが漏れることになり、そのつど墨消しを考えなければなりません。
SHA-256ハッシュなら、それを避けられます。64文字の16進数で、コンテンツの正確なバイト列を、それを明かすことなく特定します。するとレシートは、実質的にこう述べることになります：この時刻に、このラベルのもとで、これらのバイト列が提示された。バイト列はお客様の手元に残ります。必要なときにそれを提出すれば、誰でもハッシュ化でき、そのハッシュはレシートと一致するか、しないかのどちらかです。
ここで話を終えれば、お客様を誤解させることになります。ハッシュがコンテンツをよく守るのは1つの条件のもとでだけであり、レシートのいくつかのフィールドはそもそもハッシュではありません。
SHA-256は逆算できませんが、推測はできます。入力の可能性が少ない場合、たとえば「はい」か「いいえ」の回答、メールアドレス、短いコード、既知のテンプレートなどであれば、レシートを持つ誰もが候補をハッシュ化して比較できます。そうしたコンテンツでは、ハッシュ化する内容にランダムな値、つまりノンスを含め、そのノンスを原本と一緒に保管してください。そうすればレシートは、読み手に推測させることなく、存在を証明できます。
お客様が選ぶラベルやその他の自由記述フィールドは平文で書き込まれ、いったんレシートに署名されるとそのまま残ります。注文番号や内部IDなどの不透明な識別子を使い、対応表はお客様の側で保管してください。
ハッシュが特定するのはバイト列であって、意味ではありません。末尾の改行、\nの代わりの\r\n、異なるUnicode正規化は、いずれも別のハッシュになります。テキストの場合は、エンコーディングと改行コードを一度決めて、それを守ってください。構造化されたレコードの場合は、再シリアライズしたものではなく、ハッシュ化した正確なバイト列を保存してください：後でキーの順序が異なるJSON.stringifyを行えば、別のハッシュになります。複数のファイルの場合は、各ファイル自身のハッシュを列挙したマニフェストをハッシュ化し、そのマニフェストを証明してください。
一つの帰結に備えてください：レシートはコンテンツを再現できません。 原本を失っても、レシートは引き続き検証できますが、お客様が提示できる文書について有用なことは何も証明しなくなります。原本は追記専用のストレージに、レシートと並べて保管してください。
どんな設計でも取り除けない限界があります。すでに誰かに渡したレシートは、当社が何をしても、その相手が検証し続けることができます。検証に必要なのはレシートと公開鍵だけだからです。それこそが、レシートを証拠たらしめる性質です。そしてそれが、上の助言が重要である理由でもあります：個人データを平文のフィールドに入れないようにしておけば、レシートの消去という問題が難しくなることはまずありません。レシートはハッシュしか持たないため、通常はお客様自身の保管庫で原本を消去すれば十分です。
当社が署名するのはお客様のデータについての事実であって、データそのものではありません。まずハッシュ化するからこそ、レシートは持ち運べ、検証に当社のストレージへの信頼が必要になることもありません。ただし、推測可能な値を秘匿するものではなく、平文フィールドに書いた内容を守るものでもありません。小さな入力にはノンスを、ラベルには不透明なIDを使い、原本は保管しておいてください。
詳しくはレシートが証明すること、しないことと当社のセキュリティページをご覧ください。
署名付きレシートは、正確で範囲の限られた記述です。有効なTrustviceのレシートが立証する3つのこと、立証しない多くのこと、お客様がなお当社を信頼している点、そして誰も過大に語らないようにレシートを提示する方法を、丁寧に説明します。
約5分で読了
Two correct RFC 8785 implementations can still disagree on key order, big numbers and unpaired surrogates. We walk through each edge case in JavaScript and Python, what our canonicalizers do, and how shared test vectors catch drift.
約8分で読了
What "automatic recording of events" asks of an agentic system, which fields make a log traceable, why self-written logs are weak evidence, how to reconcile retention with erasure, and where signed receipts help and where they do not.
約8分で読了
Trustvice のレシートを検証ツールに貼り付けてください。公開鍵を使って、ブラウザ内で署名を確認します。アカウントは不要です。
Trustvice 360
