# 電子記録印「青色番頭 記録印」技術説明書

作成者：青色番頭 運営者（提出時に氏名・屋号を記入してください）
作成日：2026年8月23日
対象システム：個人事業電子帳簿システム「青色番頭」記録印機能
システムバージョン：0.3.0（記録印の仕組みはスキーマ 0028 で導入。2026年9月6日時点の最新はスキーマ 0081）
文書バージョン：1.2
改訂：2026年9月6日（1.2）—— 第5.1「送付」を「交付（送付）」に改め、利用者の記録であって対象システムによる送信ではないことを明記。第1.2「第三者が独自に検証」の対象を限定。
改訂：2026年9月6日（1.1）—— 付記2「実装との対応」に挙げた実装（確定時のハッシュ保存・検証ページ・連鎖の計算・記録の保護・時刻の記録）がスキーマ 0081 の時点でもそのまま存在することを再確認しました。記録印の仕組み自体に変更はありません。

---

## 第1 本書の目的と位置づけ

### 1.1 目的

本書は、請求書等に付された電子的な記録印（以下「記録印」という。）について、その仕組みと、当該仕組みによって何が確認でき、何が確認できないかを、技術的知識を有しない第三者にも理解できる形で説明することを目的とする。

### 1.2 本書の性質

**本書は、対象システムの開発者兼運営者が作成した説明資料である。** 第三者機関による認証、監査または鑑定を受けたものではない。

本書に記載する仕組みは、公開された標準的な技術のみを用いており、記載された手順に従えば、**第三者が独自に検証を行うことができる。**ただし、第三者が自分の端末で検証できるのは、**手元の文書と記録されたハッシュ値の一致**、および**提出された記録の内部の連鎖の整合性**である。記録が主張する時刻にその記録が存在したこと、運営者が記録全体を作り直していないこと、相手方への送信・到達は、この検証の対象ではない（第7参照）。 本書の記載内容の正確性は、第4および第5に記載する手順を実行することにより、読者自身が確認可能である。

### 1.3 本書が主張しないこと

本書は、次のいずれも主張するものではない。

- 対象文書が電子署名法第3条の推定効を受けること
- 記載された時刻が認定タイムスタンプによる時刻証明であること
- 対象文書の改ざんが技術的に不可能であること
- 対象文書が電子帳簿保存法その他の法令に適合することの保証

法的評価は、本書の記載内容を含む諸事情を総合して、権限ある機関が判断すべき事項である。

---

## 第2 本機能が示せること・示せないこと

本機能の性質を正確に理解するため、最初に範囲を明示する。

### 2.1 示せること

| 内容 | 確認方法 |
|---|---|
| ある文書について、対象システムが特定の日時を発行日時として「確定」の記録を保持していること | 第4の照合手順 |
| 提示されたPDFファイルが、確定時に保存されたPDFファイルと**バイト単位で一致する**こと | 第4の照合手順 |
| 提示されたPDFファイルが、確定時に保存されたファイルと1バイトでも異なること | 第4の照合手順（不一致として検出） |
| 当該文書について、作成・確定・交付の記録・訂正・取消等の操作が、どの順序で記録されたか | 第5の証跡確認手順 |
| 提供された記録の内部整合性が保たれていること、または一部に不整合があること | 第5の連鎖検証手順 |

**「バイト単位で一致する」の意味について。** SHA-256による照合が確認するのは、ファイルが完全に同一であることである。**見た目が同一の文書であっても、印刷後に再スキャンしたもの、別のソフトウェアで再生成したもの、変換や再保存を経たものは、内容が同じでも不一致となる。** 本機能は、確定時に保存されたPDFファイルそのものを配布・保存することを前提としている。

### 2.2 示せないこと

| 内容 | 理由 |
|---|---|
| 記載された日時が、現実世界におけるその時刻であること | 認定タイムスタンプを使用していないため。記録された時刻は、対象システムのサーバーが記録した時刻である |
| 比較対象となるハッシュ値が、発行当時から存在していたこと | 記録の存在時期は対象システムの記録に依拠しており、これを対象システムから独立して証明する仕組みは含まない |
| 相手方が当該文書を受領し、内容を了解したこと | 本機能は発行者側の記録であり、受領の事実を対象としない |
| 相手方が当該請求の内容に同意したこと | 請求書は一方的に発行する通知であり、相手方の合意を前提としない |
| 対象システムの運営者が、過去の記録を事後に作成し直していないこと | 本機能は発行者が自己の記録を示すことを目的としており、運営者の潔白を第三者に対して独立に証明する仕組みは含まない（第7参照） |

**本機能の位置づけは、「発行者が、自らの業務システムに残された記録を、検証可能な形で提示できるようにするもの」である。**

---

## 第3 技術的な仕組み

### 3.1 用いている技術

本機能は、次の2つの標準技術のみを用いる。いずれも国際的に広く使用され、仕様が公開されている。

**(1) 暗号学的ハッシュ関数 SHA-256**

米国国立標準技術研究所（NIST）が策定した標準規格（FIPS PUB 180-4）に定められた計算方法である。任意の長さのデータから、64桁の16進数（256ビット）の値を算出する。

この計算には、次の性質がある。

- **同一のデータからは、常に同一の値が算出される**（再現性）
- **データが1バイトでも異なれば、通常、算出される値は大きく変化する**（雪崩効果）
- **算出された値から、元のデータを復元することは事実上できない**（一方向性）
- **異なるデータから同一の値が算出される可能性は理論上存在するが、これを意図的に発生させることは、現在知られている技術では実用上極めて困難であるとされている**（衝突困難性）

SHA-256は、金融機関の決済システム、電子証明書、ソフトウェアの配布時の完全性確認等、社会基盤において広範に使用されている。**2026年時点において、SHA-256に対する実用的な衝突攻撃は知られていない。**

**(2) ハッシュ連鎖（ハッシュチェーン）**

記録を時系列に並べ、各記録に「直前の記録から算出したハッシュ値」を含める構造である。

この構造により、過去の記録を1件でも改変すると、それ以降のすべての記録のハッシュ値が変化する。**したがって、一部の記録だけを改変して整合性を保つことができない。**

### 3.2 なぜ内容の同一性を確認できるのか

文書を確定した時点で、そのPDFファイル全体からSHA-256の値を算出し、記録する。**このとき生成したPDFファイルを保存し、以後の配布はすべてこのファイルを用いる。**

後日、提示されたPDFファイルから同じ方法でSHA-256の値を算出し、記録された値と比較する。

- **一致する場合**：提示されたファイルは、確定時に保存されたファイルとバイト単位で一致する
- **一致しない場合**：提示されたファイルは、確定時に保存されたファイルと何らかの点で異なる

前記3.1の雪崩効果により、金額の1桁、日付の1文字を変更しただけでも、算出される値は大きく異なるものとなる。したがって、**内容を改変したうえで同じハッシュ値を保つことは、実用上極めて困難である。**

なお、不一致は必ずしも改変を意味しない。**印刷後の再スキャン、別のソフトウェアによる再生成、形式変換、再保存等を経た場合も不一致となる。** 不一致が検出された場合、その原因は個別に確認する必要がある。

---

## 第4 第三者による照合手順

**本手順のうち、PDFのハッシュ値の算出は、対象システムに依存せず、汎用のソフトウェアのみで実行できる。** ただし、比較対象となるハッシュ値の記録そのものは、対象システムまたは対象システムから提出された記録に依拠する（第2.2および第7.2参照）。

### 4.1 準備するもの

- 検証対象のPDFファイル
- 当該PDFに記載された文書ID、発行日時および検証URL

### 4.2 手順1：PDFのハッシュ値を算出する

一般的なパソコンに標準搭載されている機能で算出できる。

**Windowsの場合**

コマンドプロンプトを開き、次を実行する。

```
certutil -hashfile "対象ファイルのパス" SHA256
```

**macOS・Linuxの場合**

ターミナルを開き、次を実行する。

```
shasum -a 256 "対象ファイルのパス"
```

いずれも、64桁の16進数が表示される。

### 4.3 手順2：記録された値と照合する

PDFに記載された検証URLを開くと、当該文書について記録された次の情報が表示される。

- 文書ID
- 文書のハッシュ値（SHA-256、64桁）
- 発行日時
- 文書種別
- 現在の状態（有効・訂正済み・取消済み）

**手順1で算出した値と、検証ページに表示された値を目視で比較する。**

64桁すべてが一致すれば、当該PDFは記録された文書と同一である。

### 4.4 検証ページを用いない照合

検証ページを使用せず、発行者から提出された記録（第6の別紙）に記載されたハッシュ値と直接比較することもできる。**この場合、照合の作業自体に対象システムへの接続は不要である。** ただし、比較対象となる記録の内容は、発行者が提出したものである。

---

## 第5 証跡記録の構造と検証

### 5.1 記録される事項

文書ごとに、次の操作が発生順に記録される。

| 記録される操作 | 内容 |
|---|---|
| 作成 | 下書きとして作成された |
| 確定 | 内容を確定し、ハッシュ値を算出した |
| 交付（送付） | **利用者が**、相手方へ交付した旨とその方法（メール等・郵送・手渡し・その他）を記録した。対象システムは文書の送信を行わず、実際の送信・到達・受領を確認したものではない |
| 検証アクセス | 検証ページが開かれた |
| 訂正 | 新しいバージョンにより訂正された |
| 取消 | 取り消された |

各記録には、次が含まれる。

- 記録の通し番号（文書ごとに1から連番）
- 操作の種類
- 発生日時（協定世界時、ミリ秒精度）
- 直前の記録から算出したハッシュ値
- 当該記録自体のハッシュ値

### 5.2 連鎖の計算方法

各記録のハッシュ値は、次の値をこの順に連結し、SHA-256を算出したものである。

```
文書ID ‖ 通し番号 ‖ 操作の種類 ‖ 発生日時 ‖ 操作内容のハッシュ値 ‖ 直前の記録のハッシュ値
```

**この計算方法が公開されているため、記録の一覧が提供されれば、第三者が独自に再計算し、整合性を確認できる。**

### 5.3 改変の検出

仮に、過去の記録の1件を改変したとする。

改変された記録のハッシュ値が変化する。→ 次の記録が保持する「直前の記録のハッシュ値」と一致しなくなる。→ 以降のすべての記録で不整合が生じる。

**したがって、記録の一部のみを変更した場合、その事実を検出できる。**

**ただし、これは管理権限を有する者が、変更箇所以降のすべての記録を再計算のうえ作り直す可能性を排除するものではない。** 本機能の連鎖構造は、部分的な改変を検出するものであり、記録全体の再作成を防止するものではない（第7.2参照）。

### 5.4 記録の保護

証跡記録を保存するデータベースの表には、記録の追加のみを許可し、変更および削除を禁止する設定が行われている。

**ただし、この設定はデータベースの管理権限により変更し得るものであり、それ自体を改変不能の根拠とはしない**（第7参照）。

---

## 第6 提出書類の構成

紛争または税務調査において本記録を提示する場合、次の構成で提出することを想定している。

| 書類 | 内容 |
|---|---|
| 本技術説明書 | 仕組みと検証手順の説明 |
| 対象文書のPDF | 記録印が付された文書そのもの |
| 記録一覧（別紙） | 当該文書に関する証跡記録の全件。通し番号、操作の種類、日時、各ハッシュ値を含む |
| 照合結果 | 第4の手順により算出した値と記録された値の比較 |

**記録一覧には、個人情報および取引の明細を含めない形式と、含む形式の2種類を用意する。** 提出先および提出目的に応じて選択する。

---

## 第7 前提と限界

本書の信頼性を保つため、本機能の限界を明示する。

### 7.1 記録された時刻について

記録される日時は、対象システムのサーバーが取得した時刻である。認定タイムスタンプ事業者による時刻証明は行っていない。

**したがって、記録された日時は、対象システムの運用記録としての意味を持つにとどまり、それ自体が独立した時刻証明ではない。**

### 7.2 運営者による改変の可能性について

対象システムの開発者兼運営者は、データベースおよびサーバーに対する管理権限を有する。

**したがって、理論的には、運営者が記録全体を事後に作成し直すことは不可能ではない。**

本機能は、この可能性を排除するものではない。本機能が検出できるのは、次の場合である。

- 確定後に、配布済みのPDFの内容が変更されたこと（確定時に保存されたファイルとの不一致として）
- 証跡記録の一部のみが変更され、以降の再計算が行われていないこと

**逆に、記録全体を整合的に作り直された場合、本機能によってこれを検出することはできない。**

**なお、本記録の提出者と対象システムの運営者が同一である場合、本記録は自己の業務記録としての性質を持つ。** この点は、記録の証拠価値を評価するにあたり考慮されるべき事情である。

一方で、次の事情は考慮に値すると考える。

- 当該記録は、特定の紛争を想定して作成されたものではなく、**通常の業務処理の過程で自動的に生成される**こと
- 同一システム上に、当該文書以外の多数の取引記録が同様に蓄積されていること
- 記録の一部のみを事後に改変するには、連鎖するすべての記録の再計算が必要となること
- 相手方に配布済みのPDFが存在する場合、当該PDFとの照合により、事後の改変を検出できること

### 7.3 SHA-256の安全性について

現時点においてSHA-256に対する実用的な攻撃は知られていないが、**将来にわたり安全性が保証されるものではない。**

暗号技術の進展により当該方式の安全性が低下した場合には、より強度の高い方式へ移行し、移行の事実および時期を記録する。

### 7.4 法令適合性について

対象システムは、電子帳簿保存法における電子取引データの保存要件（取引年月日・取引金額・取引先による検索、範囲指定検索、複数条件の組み合わせ検索、画面および書面への出力）への対応を支援する機能を備えている。

**ただし、法令への適合は、システムの機能のみならず、利用者の設定、入力時期、保存方法および運用状況を含めて判断されるものであり、本書はその適合を保証するものではない。**

---

## 第8 用語

**ハッシュ値**
データから一定の計算方法により算出される固定長の値。同一のデータからは常に同一の値が得られ、データが少しでも異なれば通常は大きく異なる値が得られる。

**SHA-256**
米国国立標準技術研究所が定める標準的なハッシュ計算方法の一つ。算出される値は256ビット（16進数64桁）である。

**ハッシュ連鎖**
記録を時系列に並べ、各記録に直前の記録のハッシュ値を含める構造。過去の記録を改変すると以降のすべての記録に不整合が生じるため、部分的な改変を検出できる。

**確定**
文書の内容を最終のものとして固定する操作。本システムでは、確定時にハッシュ値を算出し、以後PDFの内容を変更しない。

**協定世界時（UTC）**
国際的な標準時。日本標準時はこれに9時間を加えたものである。本システムは記録を協定世界時で保存し、表示時に日本標準時へ変換する。

---

## 付記

本書に記載した技術および手順について、より詳細な確認を要する場合は、次を提供することができる。

- ハッシュ計算の詳細仕様書
- 対象文書に関する証跡記録の全件
- 検証手順の実演

以上

---

〔氏名〕　　　　　　　　印

---

## 付記2 実装との対応（青色番頭の内部資料。提出時は削除して構いません）

本書の記載が、実際の実装のどこに対応するかを示します。

| 本書の箇所 | 実装 |
|---|---|
| 第3.2 文書のハッシュ | 確定時に `SHA-256(配布するPDFのバイト列)` を `app.invoice_record_seals.pdf_sha256` へ保存 |
| 第4 照合手順 | 検証ページ `/verify/<文書ID>`（`src/worker/routes/verify.ts`）。照合はブラウザ側で計算 |
| 第5.2 連鎖の計算方法 | `app.doc_chain_hash()`。区切りは U+001F。詳細は `docs/HASH_CHAIN_SPEC.md` |
| 第5.3 改変の検出 | `app.verify_invoice_chain()` / API `GET /api/invoices/:id/chain` |
| 第5.4 記録の保護 | `app.invoice_events` の UPDATE / DELETE をトリガーで拒否（所有者権限でも拒否） |
| 第7.1 記録された時刻 | `app.invoice_record_seals.finalized_at`（Worker が確定の直前に決め、同じトランザクションで保存） |

**本書の第2.1の表にある「バイト単位で一致する」について。**
青色番頭は、確定時に生成した1つの PDF を保存し、それだけを配布します。
PDF の生成は決定的にしてありますが（`docs/HASH_CHAIN_SPEC.md` 1.1）、
検証はあくまで「保存したそのファイル」を対象にしています。

**第6の「記録一覧（別紙）」について。**
`GET /api/invoices/:id/chain` が、通し番号・操作の種類・日時・各ハッシュを返します。
個人情報を含まない形式です（証跡には氏名・金額・明細を入れていません）。

