分散ワークフロー監査レシート v0

このテンプレートの役割What this template is for

承認・受領・引継ぎなどの「境界点」を、原文や添付そのものを持たずに receipt として封印するための軽量テンプレートです。後から、同じ対象・同じ条件・同じ環境で起きたイベントかを最小情報で説明し、照合する用途を想定しています。 It is a lightweight template for sealing workflow boundary events without storing the original text or attachments, and for later checking whether the same event happened under the same subject, conditions and environment.

安全な sample の見方How to read the safe sample

このページの sample は publish-safe な説明用サンプルです。実社員名、実メール、実内部承認ID、内部 URL、機密メモ全文は含めません。誰がその人かよりも、どの役割で関与したかを優先します。

tags は object map が正です。
event_at はダミーでも意味が分かる値にします。
監査のための説明であり、実データ全文の保管場所ではありません。

できることWhat it can do

業務イベントの境界点を receipt に封印できる
対象や条件を公開せずに、同一イベント要点か照合できる
後から「どの条件・どの環境で起きたイベントか」を最小情報で説明できる

このテンプレートだけでは分からないことWhat this template alone does not prove

ワークフロー全体の管理や自動化
コメント全文や添付本文そのものの保存
権限者本人性の完全証明
法的効力の断定
全履歴の完全再現

kind と固定ルールKind and fixed rules

固定する receipt_kind は workflow_audit です。承認・受領・引継ぎなどの業務イベント向けに固定した kind として扱います。

各束の JSON は JCS（JSON Canonicalization Scheme） で正規化してから sha256 を計算します。
created_at は receipt 発行時刻、tags.event_at は 業務イベント時刻（利用者申告または上位システム時刻） です。
tags は object map が正です。表示や説明では key=value 形式で読めます。

field 対応表Field mapping

receipt field	意味	workflow_audit での使い方	例
`receipt_kind`	テンプレ種別	`workflow_audit` 固定	`workflow_audit`
`created_at`	receipt 発行時刻	RunProof が付与する時刻	`2026-03-25T08:10:00Z`
`tags.event_at`	業務イベント時刻	利用者申告または上位システム時刻	`event_at=2026-03-25T08:00:00Z`
`input_hash`	対象束ハッシュ	承認対象・受領対象などの要点束	`sha256:<hex>`
`output_hash`	結果束ハッシュ	承認結果・受領結果などの要点束	`sha256:<hex>`
`params_hash`	条件束ハッシュ	承認条件、チェックリスト、判断基準束	`sha256:<hex>`
`env_hash`	環境束ハッシュ	ワークフロー名、版、組織単位、テンプレ版	`sha256:<hex>`
`code_ref`	手順参照	任意の作業・コード参照	`git:example/repo@main#workflow_audit_v0`
`run_id`	相関 ID	任意の追跡 ID	`wf_20260325_080000`
`tags`	補助情報	object map が正。表示は `key=value` で読める	`{"event_type":"approval"}`
`prev_receipt_hash`	前の receipt 参照	必要なら連結できるが、v0 では必須にしない	`sha256:<hex>`

Concrete sample：承認フローの handoff / approvalConcrete sample: handoff / approval event

例として、文書の最終承認イベントを示します。承認対象束（input_hash）、承認結果束（output_hash）、承認条件束（params_hash）、ワークフロー環境束（env_hash）をそれぞれハッシュ化して扱います。実名や内部 URL を入れず、役割と段階を短い tags に寄せます。

{
  "receipt_kind": "workflow_audit",
  "input_hash": "sha256:1111...1111",
  "output_hash": "sha256:2222...2222",
  "params_hash": "sha256:3333...3333",
  "env_hash": "sha256:4444...4444",
  "code_ref": "git:example/repo@main#workflow_audit_v0",
  "run_id": "wf_20260325_080000",
  "tags": {
    "event_type": "approval",
    "artifact_type": "document",
    "workflow_stage": "final",
    "actor_role": "reviewer",
    "event_at": "2026-03-25T08:00:00Z",
    "template_version": "workflow_audit_v0",
    "audit_scope": "minimal"
  }
}

完全な request template は Ref に置いています。発行には API キーが必要です。

何を書いてよいかWhat to include

event_at
event_type
artifact_type
workflow_stage
actor_role
audit_scope

書かないほうがよいものWhat not to include

実社員名
実メール
実内部承認ID
内部 URL
機密メモ全文

created_at と event_at の違いcreated_at vs event_at

created_at：receipt 発行時刻
event_at：監査対象イベント時刻（利用者申告または上位システム時刻）

同じ「時刻」でも役割が違うため、発行時刻とイベント時刻を分けて説明します。

分かること / 分からないことWhat it can and cannot show

同一の要点束だったか
どの役割・どの段階で関与したイベントか
最小の監査説明
本人性や法的効力、全履歴の完全再現を保証するものではない

最小 NG 例Minimal NG example

危険な具体性を増やしすぎないため、NG 例も最小限に留めます。

{
  "tags": {
    "event_at": "2026-03-26T10:00:00Z",
    "employee_id": "<real internal id should not be included>",
    "internal_ticket": "<real internal ticket should not be included>",
    "private_url": "<internal url should not be included>"
  }
}

実内部IDを避ける
内部 URL を避ける
実在識別子ではなく actor_role / workflow_stage / event_type を優先する

RefReference files

次の一歩Next steps

テンプレート Ref 補助資料 Docs 一覧

分散ワークフロー監査レシート v0（workflow_audit）Workflow Audit Receipt v0 (workflow_audit)

まず何を見るかWhere to start