修士論文 v2.41

デジタル文書の真正性検証: ３層認証アーキテクチャの設計と実装

神戸情報大学院大学情報技術研究科情報システム専攻

学籍番号：24024 氏名：白石鷹也

提出日：2026年1月16日

内容梗概

従来の卒業証明書や資格証明書などの文書の真正性検証には3つの課題があった。第一に、印刷技術の発達により偽造が容易となり目視では真偽判定が困難である。第二に、発行機関への照会には1〜2週間と手数料が必要で非効率である。第三に、検証に際し不要な個人情報の開示を求められる場合がある。本研究では、上記の課題の解決策として、暗号学的証明技術と生体認証を組み合わせた文書真正性検証フレームワーク「Tri-CertFramework」を提案する。本フレームワークは、発行機関による登録確認・暗号学的証明・生体認証署名の3層認証で偽造を暗号学的に不可能とし、証明データをPDFに埋め込むことで発行機関への照会なしに即時検証を実現し、必要最小限の情報開示でプライバシーを保護する。システムは、利用者登録のRegistrar Console、検証鍵管理のExecutive Console、証明生成のProver、検証のVerifierで構成される。事例として、卒業証明書を対象に実装し、想定ユーザーによる評価を得た。検証の結果、従来1〜2週間を要した検証が約3秒で完了し、「実務と心理両面の負担軽減になる」など好評価を得た。本フレームワークは医療資格証明など多様な文書に応用可能である。

第1章序論

1.1 研究の背景

現代社会は、様々な「文書」の信頼性によって支えられている。企業間の契約書、行政機関が発行する戸籍謄本や住民票、医療機関の診断書、教育機関の卒業証明書など、これらの重要書類は社会生活の基盤として機能している。

しかしながら、これら重要書類の真正性を担保する現在の方法には、深刻な信頼性の問題がある。2024年から2025年にかけて、静岡県伊東市長の学歴詐称疑惑や、東京都知事のカイロ大学卒業疑惑が再燃するなど、学歴証明の信頼性に関する社会問題が連日報道された [1][2]。これらの事例は、現代の印刷技術では目視での真偽判定が極めて困難であり、卒業証書を提示しても疑惑が晴れないケースがあることを示している。

また、朝日新聞の報道によれば、採用時に候補者の経歴を確認する「リファレンスチェック」を行う企業が急増している [1]。これは、従来の証明書提示だけでは信頼性が不十分であることの裏返しでもある。学歴詐称が発覚した場合、採用取り消しや懲戒解雇の対象となるだけでなく、企業側も採用プロセスの見直しや信用失墜といった損害を被る。

このような状況は学歴証明に限定されるものではない。企業の重要書類（契約書、決算報告書など）の改竄、行政文書の偽造、医療資格の詐称など、文書の真正性に関わる問題は社会の様々な場面で発生している。デジタル化が進む現代において、「その文書・ファイルが正式なものであるか」を確実に検証できる仕組みの構築は、社会全体の喫緊の課題となっている。

1.2 真正性検証とは

本研究における「真正性検証」とは、図1.1に示す3つの要素を確認するプロセスを指す。

発行元の正当性: その文書が、正当な権限を持つ機関・個人によって発行されたものであるか
内容の完全性: その文書が発行後に改竄されていないか
所有者の本人性: その文書を提示している人物が、正当な所有者本人であるか

flowchart TD
    subgraph Validation ["真正性検証の3要素"]
        direction TB
        A["発行元の正当性
（誰が作ったか）"]
        B["内容の完全性
（書き換えられていないか）"]
        C["所有者の本人性
（この人のものか）"]
    end

    D["真正性が証明済みの文書"]

    A --> D
    B --> D
    C --> D

図1.1: 真正性検証の3要素

従来、これらの検証は物理的な手段（印影、透かし、特殊インク等）や、発行機関への直接照会によって行われてきた。しかし、デジタル化の進展により、これらの従来手法は限界を迎えつつある。

1.3 現在の真正性検証が抱える課題

1.3.1 課題1：真正性の担保が脆弱

現代の印刷技術やデジタル編集技術の発達により、文書の偽造は年々容易になっている。高品質なスキャナーとプリンターがあれば、紙の証明書を複製することは技術的に可能である。デジタル文書に至っては、メタデータの改竄やPDFの編集が比較的容易に行える。

学歴詐称の問題が後を絶たないのは、卒業証明書の目視確認だけでは真偽判定が極めて困難であることの証左である。さらに、卒業証書を提示しても疑惑が晴れないケースがあるように、証明書単体では十分な証明力を持たない場合も多い [2]。

この問題が発生する根本原因は、現行の証明書システムに暗号学的な検証メカニズムが組み込まれていないことにある。 従来の偽造防止手段である印影、透かし、特殊インクなどの物理的手法は、印刷技術の発展に伴いその有効性を失いつつある。また、目視による確認は検証者の知識や経験に依存し、高度な偽造には対応できない。デジタル文書においても、電子署名の導入は限定的であり、多くの証明書は署名なしのPDFとして発行されている。つまり、改竄を検知する技術的基盤が存在しないため、検証者は偽造を見破る手段を持たないのである。

1.3.2 課題2：確認プロセスが非効率

検証者（例：採用企業）が発行元（例：大学）に直接照会する場合、以下のような非効率が発生する。

時間的コスト: 郵送での確認には往復で1〜2週間を要する
金銭的コスト: 大学への卒業証明書の発行依頼には1通あたり数百円の手数料が発生する。採用候補者100人の経歴確認を行う場合、手数料だけで数万円、担当者の作業時間を含めると相当のコストとなる
人的コスト: 発行機関側においても問い合わせ対応に業務コストが発生する。大学事務局では年度末の繁忙期に証明書発行業務が集中し、対応遅延が発生することもある

特に、大規模な採用活動や、複数の資格確認が必要な業務（医療機関での資格確認など）では、この非効率性は深刻な業務負担となる。例えば、300床規模の病院では医師・看護師など数百人の職員の資格確認が必要であり、更新時期が重なると事務部門の負担は極めて大きい。

この非効率が発生する根本原因は、真正性を検証するための一元的なオンライン検証プロトコルが存在しないことにある。 現状では、各発行機関が独自の確認プロセスを持ち、検証者は証明書ごとに異なる発行機関に個別に問い合わせる必要がある。オンラインで即時に検証できる仕組みがないため、物理的な郵送や電話による照会に頼らざるを得ず、時間と費用が発生する。検証に必要な情報が証明書自体に含まれていれば、発行機関への照会は不要となるが、そのような設計は従来の証明書システムには存在しない。

1.3.3 課題3：過度な個人情報の開示

真正性を証明するために、必要以上の個人情報開示を求められるケースがある。例えば、

卒業の事実だけを確認したいのに、成績証明書の提出を求められる
資格の有無だけを確認したいのに、取得年月日や試験成績まで開示が必要

一般的な成績証明書には以下のような情報が記載されている。

氏名、生年月日、学籍番号
学部・学科・専攻
入学年月日、卒業年月日
履修した全科目名と成績（優/良/可/不可、または A/B/C/D/F）
GPA（累積成績平均）

採用企業が確認したいのは「この人が本当にこの大学を卒業したか」という一点のみであるにもかかわらず、上記のすべての情報が開示されてしまう。これらの詳細な成績情報は検証目的には不要であり、むしろ採用判断に不適切なバイアスを与える可能性もある。個人情報保護の観点から、検証に必要な最小限の情報のみを開示できる仕組みが望ましい。

この問題が発生する根本原因は、従来のデジタル署名技術が「選択的開示」に対応していないことにある。 X.509証明書に代表される従来の電子署名方式は、文書全体のハッシュ値に対して署名を行う。このため、署名の検証には文書全体が必要となり、一部の情報だけを開示して署名を検証することは技術的に不可能である。結果として、検証者は「全ての情報を見せてもらう」か「何も検証できない」かの二択を迫られる。必要な情報だけを選択的に開示しながら、文書の真正性を暗号学的に証明する技術が必要であるが、従来の証明書システムにはそのような機能は実装されていない。

これらの課題は、表1.1のように整理できる。

表1.1: 真正性検証の3つの課題

課題	現状の問題	理想的な解決策
真正性の担保が脆弱	目視確認では偽造を見破れない	暗号学的な改竄検知
確認プロセスが非効率	照会に1〜2週間、手数料発生	即時・無料での検証
過度な個人情報開示	検証に不要な情報まで開示	必要最小限の情報のみ

本研究の探究チャートを図1.2に示す。問題意識として、文書偽造が後を絶たないこと、現行の真正性検証は確認プロセスが煩雑で非効率であること、検証時に過度な個人情報開示が求められることの3点を設定した。これらに対する解決策として、効率的かつプライバシーを保護した文書真正性検証システムを提案する。

本研究の探究チャート

図1.2: 本研究の探究チャート

1.4 本研究の目的と対象領域

本研究では、上述の3つの課題を解決するため、暗号学的手法を用いた新しい文書真正性検証フレームワーク Tri-CertFramework を提案・実装する。本フレームワークで使用する具体的な技術については第2章で詳述するが、本節ではその目的と解決策の概要を述べる。

本研究の対象領域は「デジタル文書全般」の真正性検証である。 本フレームワークは、契約書、診断書、資格証明書、学位証明書など、発行機関が存在し真正性の証明が求められるあらゆるデジタル文書に適用可能な汎用的なアーキテクチャとして設計されている。ただし、本論文では具体的な適用事例として 教育機関における卒業証明書 を取り上げ、システムの設計・実装・検証を行う。

本フレームワークは、以下の3層構造で証明書の真正性を保証する。

層	役割	防ぐ攻撃
第1層：登録確認	発行機関が正規に登録した証明書であることを確認	架空の機関による偽造証明書
第2層：内容保全	証明書の内容が改竄されていないことを暗号学的に検証	正規証明書の内容改竄
第3層：所有者確認	提示者が正当な所有者であることを生体認証で確認	他人の証明書の不正使用

この3層すべてを通過しなければ検証は成功しないため、いずれか1層でも異常があれば偽造が露呈する。各層の技術的詳細は第2章で、実装の詳細は第3章で述べる。

さらに、本フレームワークは以下の利点を提供する。

即時性（PDF埋め込み検証）: 証明データをPDFに直接埋め込むことで、発行機関への照会なしに数秒で検証完了。従来は郵送で1〜2週間かかっていた確認が、ブラウザ上で即座に完了する
秘匿性（選択的開示）: 検証に必要な最小限の情報（「卒業した」という事実と卒業年度）のみを開示し、成績や学籍番号などの詳細情報は一切開示しない

卒業証明書を適用事例として選択した理由は以下の通りである。

社会的関心の高さ: 学歴詐称問題が社会問題化しており、解決へのニーズが明確
評価の容易性: 大学院生という立場から、利用者・発行機関の両方の視点での評価が可能
汎用性の検証: 卒業証明書で有効性が示されれば、他の証明書への応用可能性も高い

本研究では、上記3つの課題に対して以下の定量的目標を設定する。

表1.2: 本研究の定量的目標

課題	定量的目標	根拠
真正性の担保	128ビット以上の計算量的安全性¹	現代の暗号学的基準に準拠
確認プロセスの効率化	検証時間5秒以内	従来の1〜2週間から99.99%以上短縮
個人情報開示の最小化	開示項目2項目以下	卒業年度と登録状態のみ

これらの目標が達成されたかどうかは、第4章の検証において評価する。

本研究の位置づけと範囲

文書真正性検証システムの社会実装を実現するためには、理想的には以下のプロセスが必要である。

要件定義: 実際の発行機関（大学等）と検証機関（企業等）へのヒアリングによる業務要件の把握
プロトタイプ開発: 要件に基づくシステム設計・実装
実証実験: 実機関での試験運用と効果測定
効果検証: 業務効率化、コスト削減、ユーザー満足度の定量的評価
普及戦略: 採用障壁の分析と導入支援体制の構築

しかし、修士課程の1年間という時間的制約の中で、上記すべてを網羅的に実施することは現実的ではない。特に、実機関での本格的な実証実験（ステップ3〜5）には、機関との調整、IRB（研究倫理審査委員会）の承認、長期的な効果測定期間が必要であり、これらは修士研究の範囲を超える。

本研究では、上記プロセスのうち**「2. プロトタイプ開発」を中心に、「3. 実証実験」の予備的評価**までを実施範囲とする。具体的には、以下の3点に注力する。

技術的実現可能性の実証: 暗号学的手法を用いた文書真正性検証が、実用的な性能で動作することを示す
システム設計の具体化: 発行機関・証明書保持者・検証者という3者の関係性を考慮した実装を行う
予備的評価の実施: 少数の協力者による利用評価を通じて、実用化への課題と可能性を明らかにする

本研究は、社会実装に向けた第一段階として「技術的に可能であること」を実証するものであり、大規模な実証実験や普及戦略の策定は今後の課題として位置づける。この位置づけを踏まえ、第4章では上記3点の達成度を評価し、第5章では社会実装に向けた残課題を考察する。

1.5 本研究の特徴

本研究では、前節で述べた3つの課題を解決するため、表1.3に示す技術を採用した。各技術の詳細は第2章で述べる。

表1.3: 本研究で採用した主要技術

技術カテゴリ	本研究での役割	詳細
暗号学的証明技術	内容を開示せずに真正性を証明	2.2節
生体認証技術	証明書所有者の本人確認	2.3節
ハッシュ関数	改竄検知と高速な証明生成	2.2.3節

以下、本研究の特徴として4点を挙げる。

1. プライバシー保護と真正性検証の両立

従来の電子署名やブロックチェーン証明書は、証明書の真正性を保証するために証明書の内容をそのまま開示する必要があった。本研究では、暗号学的手法を用いることで、「卒業の事実」を証明しながら、成績や学籍番号などの詳細情報を一切開示しないことを可能にした。これは、GDPR（EU一般データ保護規則）や日本の個人情報保護法が求める「データ最小化の原則」に適合するアプローチである。

2. 所有者の本人性確認機能の統合

既存のデジタル証明書規格（X.509、Open Badges、Blockcerts等）は、いずれも「証明書が本物であること」は確認できても、「それを提示している人物が正当な所有者であるか」は確認できない。本研究では、生体認証を統合することで、証明書の真正性と所有者の本人性を同時に検証可能にした。これにより、他人の証明書を不正利用する「なりすまし」を防止できる。

3. 完全分散型アーキテクチャ

本システムは、検証時に発行機関のサーバーへの問い合わせを必要としない。検証に必要な情報（検証鍵、登録リスト）は公開リポジトリで配布されており、オフライン環境でも検証が可能である。これにより、発行機関のサーバー障害や、極端な場合には発行機関の消滅後も、証明書の検証が継続可能となる。

4. 実用的なシステムとしての完成度

本研究は理論提案にとどまらず、4つのコンポーネント（発行者向けコンソール、管理者向けコンソール、証明生成UI、検証UI）を実装し、実際に動作するシステムとして完成させた。医療事務従事者を含む協力者による評価では、「実務負担だけでなく心理的負担も軽減できる」との肯定的な評価を得ており、実用化への道筋を示すことができた。

1.6 本論文の構成

本論文は以下のように構成される。

第1章では、本研究の背景、目的、及び課題設定について述べた。

第2章では、デジタル証明書の現状と先行研究を概観し、本研究で使用する技術的基盤（暗号学的証明技術、生体認証技術）について説明する。

第3章では、Tri-CertFrameworkの設計思想とシステムアーキテクチャを詳述し、各コンポーネントの実装について説明する。

第4章では、本システムの検証方法と結果、およびセキュリティ評価と既存手法との比較を行う。

第5章では、プライバシー保護、運用面での考慮事項、応用可能性について考察する。

第6章では、本研究の結論と今後の課題についてまとめる。

第2章先行研究と技術基盤

2.0 章概要

本章では、本研究の基盤となる技術と関連研究について述べる。まず、本章で使用する主要な用語の正式名称を表2.0aに、本研究での役割を表2.0bに示す。

表2.0a: 本章で使用する主要用語（正式名称）

略称	正式名称
ZKP	Zero-Knowledge Proof（ゼロ知識証明）
zk-SNARKs	Zero-Knowledge Succinct Non-Interactive Argument of Knowledge
WebAuthn	Web Authentication API
FIDO2	Fast IDentity Online 2
CTAP	Client to Authenticator Protocol
VK	Verification Key（検証鍵）
PKI	Public Key Infrastructure

表2.0b: 本章で使用する主要用語（本研究での役割）

用語	本研究での役割
ZKP	証明書の中身を相手に見せずに「この証明書は本物です」と証明できる技術
zk-SNARKs	ZKPの具体的な実装手順。軽量で高速に処理できるのが特徴
Groth16	zk-SNARKsをソフトウェアに組み込めるようにしたライブラリ。本システムで採用
Poseidon	一般的な数列をZKP向けの数列に変換する関数
WebAuthn	Webブラウザで指紋認証やUSBキー認証を使えるようにする国際標準規格
FIDO2	パスワードを使わずにログインできる仕組みの業界標準。WebAuthnの上位規格
CTAP	パソコンとUSBキー（認証デバイス）の間でデータをやり取りする通信規格
VK	「この証明は正しい」と確認するために必要な公開データ。誰でも検証に使える
PKI	現在広く使われている電子証明書の仕組み。本研究が改善を目指す対象
X.509	PKIで使われる電子証明書のファイル形式。SSL証明書などで利用されている

以下、2.1節ではデジタル証明書の現状と課題を、2.2節ではゼロ知識証明の基礎理論を、2.3節ではWebAuthnとFIDO2の技術仕様を、2.4節では関連研究を、2.5節では本研究のポジショニングを述べる。

なぜこれらの技術を選んだのか

本研究では、第1章で述べた3つの課題を解決するために、以下の技術を選定した。表2.0cに課題と技術の対応を示す。

表2.0c: 課題と選定技術の対応

課題	根本原因	選定技術	解決の仕組み
真正性の担保が脆弱	暗号学的検証メカニズムの欠如	ZKP（Groth16）	数学的に偽造不可能な証明を生成
確認プロセスが非効率	オンライン検証プロトコルの不在	PDF埋め込み + GitHub公開	検証に必要な情報を証明書自体に含め、発行機関への照会を不要化
過度な個人情報開示	選択的開示技術の欠如	ZKP（選択的開示）	必要な情報のみを開示し、その他は秘匿したまま検証

さらに、本研究では所有者の本人確認という従来の証明書システムでは解決されていない課題にも対応する。WebAuthn/FIDO2を採用することで、証明書の所有者が本人であることを生体認証により保証する。これにより、証明書の「真正性」だけでなく「所有者の正当性」も同時に検証可能となる。

2.1 デジタル証明書の現状

2.1.1 従来のデジタル証明書

現在、デジタル証明書の代表的な規格としてX.509証明書が広く使用されている [4]。X.509は公開鍵基盤（PKI）に基づいており、認証局（CA）が発行者の身元を保証する階層的な信頼モデルを採用している。

しかし、教育証明書の分野では、X.509とは異なるアプローチも登場している。

Open Badges: Mozilla財団が策定し、現在は一般財団法人オープンバッジ・ネットワーク [3] などが推進するデジタルバッジ規格で、JSONベースのメタデータと発行者の署名により、スキルや達成を証明する。
Blockcerts: MITが開発したブロックチェーンベースの証明書規格で、Bitcoinブロックチェーンにハッシュを記録することで改竄耐性を実現する [5]。
European Digital Credentials (EDCI): 欧州委員会が推進する資格証明のデジタル化イニシアチブで、分散台帳技術を活用している [6]。

2.1.2 既存手法の限界

これらの既存手法には、表2.1に示すような限界がある。

表2.1: 既存手法の限界

手法	問題点
X.509/PKI	認証局への依存、長期的な鍵管理の困難さ
Open Badges	発行者サーバーへの検証時アクセスが必要
Blockcerts	トランザクション手数料、スケーラビリティの課題
EDCI	特定の管轄地域（EU）への依存

特に重要な点として、これらの手法はいずれも「所有者の本人性」を証明する機能を持たない。すなわち、証明書が本物であることは確認できても、それを提示している人物が正当な所有者であるかは確認できない。これらの課題に対する解決策は第3章で提案する。

2.2 ゼロ知識証明（ZKP）

2.2.1 ZKPの概要

ゼロ知識証明（Zero-Knowledge Proof）とは、ある命題が真であることを、その命題が真である理由以外の情報を一切漏らさずに証明する暗号プロトコルである。1985年にGoldwasser、Micali、Rackoffによって導入された [7]。

身近な例で説明すると、「自分が20歳以上である」ことを証明したい場面を考える。従来の方法では、運転免許証や保険証を見せて生年月日を開示する必要があった。しかし、ZKPを使えば、生年月日そのものを明かすことなく「20歳以上である」という事実だけを数学的に証明できる。相手は年齢の条件を満たしていることを確信できるが、具体的な生年月日は知ることができない。

ZKPは以下の3つの性質を満たす。

完全性（Completeness）: 命題が真である場合、正直な証明者は検証者を確信させることができる。
健全性（Soundness）: 命題が偽である場合、不正な証明者が検証者を騙すことは（計算量的に）不可能である。
ゼロ知識性（Zero-Knowledge）: 検証者は命題が真であること以外の情報を得ることができない。

本研究では、この技術を卒業証明書の検証に応用する。具体的には、「この証明書が正規に発行されたものである」「内容が改竄されていない」という事実を、証明書の詳細な内容を開示することなく証明できる。

コミットメントスキーム

本システムでは、証明書のハッシュ値と所有者だけが知る秘密の値を組み合わせた「コミットメント値」を使用する。この仕組みを理解するために、日常的な例えを用いる。

クイズ大会で自分の予想を紙に書いて封筒に入れ、司会者に預けておく場面を考える。

封筒を預ける時点では、中身は誰にもわからない（秘匿性）
封筒を預けた後は、中身を書き換えることはできない（束縛性）
正解発表後に封筒を開けて「最初からこの答えを書いていた」と証明できる

コミットメントとは、この「封印された予想」をデジタルで実現する暗号技術である。本システムでは以下のように機能する。

証明書保持者は、証明書のハッシュ値と自分だけが知る秘密の値からコミットメント値を生成
検証者はコミットメント値を見ても、元の証明書内容を復元できない
しかし、証明書保持者が正しい証明書を持っていることは数学的に検証可能

これにより、証明書の中身を見せずに「正規の証明書である」ことを証明できる。

2.2.2 zk-SNARKsとGroth16

本研究では、zk-SNARKs（Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge）の一種であるGroth16プロトコル [8] を採用している。

zk-SNARKsは、ZKPを実用的に使えるようにした技術である。「Succinct（簡潔）」は証明データが小さいこと、「Non-Interactive（非対話型）」は証明者と検証者が何度もやり取りする必要がないことを意味する。従来のZKPでは、証明者と検証者が何度も情報をやり取りする必要があったが、zk-SNARKsでは証明者が一度だけ証明データを生成すれば、検証者はそれを受け取るだけで検証を完了できる。

Groth16の特徴を以下に示す。

非対話型: 証明者と検証者間のやり取りが1回で完結する
簡潔性: 証明サイズが極めて小さい（約200バイト）
高速な検証: 検証時間が数ミリ秒である

これらの特徴により、Groth16はWebブラウザ上での証明生成・検証に適している。証明データが小さいためPDFファイルに埋め込んでも容量がほとんど増えず、検証も瞬時に完了する。

Groth16では、算術回路（Arithmetic Circuit）として表現された計算に対して、その計算を正しく実行したことの証明を生成できる。算術回路とは、足し算と掛け算の組み合わせで表現された計算手順のことである。本研究では、snarkjs [9] ライブラリとCircom回路コンパイラ [10] を使用してZKP回路を実装している。

2.2.3 Poseidonハッシュ関数

ZKP回路内でのハッシュ計算には、ZKPに最適化されたPoseidonハッシュ関数 [11] を使用している。

ハッシュ関数とは、任意のデータを固定長の値（ハッシュ値）に変換する関数である。同じデータからは必ず同じハッシュ値が得られ、データが1文字でも異なれば全く異なるハッシュ値になる。この性質により、ハッシュ値を比較するだけでデータが改竄されていないかを検証できる。

なぜPoseidonが必要なのか

ZKP回路では、計算を「制約」と呼ばれる数学的な等式で表現する。制約の数が多いほど証明の生成に時間がかかる。SHA-256のような従来のハッシュ関数は、ビット演算を多用する設計であり、ZKP回路に変換すると約25,000〜50,000個の制約が必要となる。これは証明生成に数十秒〜数分を要する計算量である。

Poseidonは、ZKP回路での使用を前提に設計されたハッシュ関数である。「有限体」と呼ばれる数学的構造上での演算のみを使用する。

有限体とは、ある素数pで割った余りだけを使う計算の世界である。具体例を示す。

p = 7 の有限体での計算例：
5 + 4 = 9 → 9 ÷ 7 = 1 余り 2 → 結果は 2
3 × 5 = 15 → 15 ÷ 7 = 2 余り 1 → 結果は 1

時計が12時を超えると1に戻るのと同じ原理である。ZKP回路は本来この有限体上で動作するため、Poseidonはビット演算への変換が不要となり、制約数を大幅に削減できる。

表2.1: ハッシュ関数のZKP回路における性能比較

ハッシュ関数	制約数（概算）	証明生成時間	用途
SHA-256	約25,000〜50,000	数十秒〜数分	一般的な改竄検知
Poseidon	約200〜500	1〜3秒	ZKP回路内での計算

本システムでは、PDF文書全体のハッシュ値（改竄検知用）にはSHA3-512を使用し、ZKP回路内でのコミットメント計算にはPoseidonを使用するという使い分けを行っている。これにより、セキュリティと処理速度の両立を実現している。

2.3 WebAuthn と FIDO2

2.3.1 FIDO2規格の概要

FIDO2（Fast Identity Online 2）は、パスワードに依存しない認証を実現するための標準規格である [12]。

従来のパスワード認証には、パスワードの漏洩、フィッシング詐欺、パスワードの使い回しによる被害拡大など、多くのセキュリティ上の問題があった。FIDO2は、指紋認証や顔認証などの生体認証、またはセキュリティキーと呼ばれる専用デバイスを使用することで、これらの問題を解決する。

身近な例では、iPhoneのFace IDやTouch ID、WindowsのWindows Helloがこの技術を採用している。パスワードを入力する代わりに、指紋や顔をかざすだけでログインできる仕組みがFIDO2である。

FIDO2は以下の2つのコンポーネントで構成される。

WebAuthn: W3Cが標準化したWebブラウザ向けの認証API
CTAP2: 外部認証器（セキュリティキー、スマートフォンなど）との通信プロトコル

これら2つの役割分担を図2.2に示す。

┌─────────┐    WebAuthn API    ┌────┐    CTAP2     ┌────────────┐
│ブラウザ │ ←───────────────→ │ OS │ ←─────────→ │ 認証器     │
│(Webサイト)│                   │    │             │(指紋/顔/鍵)│
└─────────┘                    └────┘             └────────────┘
                                                        ↑
                                                  秘密鍵はここに
                                                  安全に保管

図2.2: FIDO2のアーキテクチャ

WebAuthnはブラウザとWebサイト間の通信を担当し、CTAP2はOSと認証器（指紋センサー、USBセキュリティキー等）間の通信を担当する。重要な点は、秘密鍵が認証器の中に閉じ込められ、外部に出ることがないことである。これにより、たとえOSやブラウザが攻撃されても、秘密鍵が漏洩するリスクを最小化できる。

2.3.2 本研究での活用

本研究では、WebAuthnをPDFへの電子署名手段として活用している。

電子署名とは、紙の書類における印鑑や手書きの署名に相当するものである。電子署名があることで、「この文書は確かにこの人が作成・承認した」「文書の内容は署名後に改竄されていない」ということを証明できる。

本研究では、ユーザーが証明書を生成する際に、Touch IDやWindows Helloなどの認証器を使って電子署名を行う。この仕組みの重要な点は、署名に使う秘密鍵がユーザーのデバイス（スマートフォンやパソコン）の中に安全に保管され、外部に出ることがないことである。

具体的には以下の処理を行う。

鍵ペア生成: ユーザーの認証器（Touch ID、Windows Helloなど）内でECDSA P-256鍵ペアを生成
署名生成: 証明書のハッシュに対して署名を生成
公開鍵の埋め込み: JWK（JSON Web Key）形式で公開鍵をPDFに埋め込み

これにより、秘密鍵が認証器の外部に出ることなく、本人確認と署名が同時に行える。例えば、ユーザーがTouch IDに指を置くだけで、本人確認と電子署名が完了する。

2.4 関連研究

2.4.1 学術証明書へのZKP適用

近年、学術証明書へのZKP適用に関する研究が進展している。代表的な研究を以下に示す。

Yilmaz et al. (2023) [13] は、ブロックチェーンベースの学術証明書検証システムに関する体系的文献レビュー（SLR）を実施し、既存システムの課題を整理している。彼らのレビューによると、多くのシステムが以下の共通課題を抱えている。

ブロックチェーンインフラへの依存（ガス代、ネットワーク停止リスク）
オフライン環境での検証が不可能
所有者の本人性確認機能が欠如

ZK-Creds (Rosenberg et al., 2023) [15] は、属性ベースの資格証明にZKPを適用した研究である。選択的開示（例：「卒業年度は2020年以降」のみを証明）を実現しているが、検証には中央サーバーへのアクセスが必要であり、完全なオフライン検証は実現していない。これらの先行研究と本研究の比較を表2.2に示す。

表2.2: 学術証明書へのZKP適用研究の比較

研究	ZKPプロトコル	インフラ依存	オフライン検証	本人性確認
既存ブロックチェーン基盤システム [13]	各種	ブロックチェーン	×	×
ZK-Creds [15]	Bulletproofs	中央サーバー	△	×
本研究	Groth16	GitHubのみ	○	○（WebAuthn）

本研究は、これらの先行研究と比較して、以下の点で独自性を有する。

完全なインフラ独立性: ブロックチェーンや中央サーバーを必要とせず、GitHubの静的ファイルホスティングのみで運用可能である。ZK-Credsは検証鍵を中央サーバーで管理するため、サーバー停止時には検証が不可能となる。一方、本研究では検証鍵をGitHubで公開することで、GitHubが停止しても検証鍵のコピーを保持していれば検証が継続可能である
真のオフライン検証: PDFに埋め込まれた情報のみで完結する検証プロセスを実現している。既存のブロックチェーンベースシステムでは、検証のたびにブロックチェーンネットワークへの接続が必要となり、ネットワーク障害時や航空機内などのオフライン環境では検証ができない。本研究では、証明データをPDFに直接埋め込むため、インターネット接続なしで検証が完結する
WebAuthnによる本人性確認: 証明書の所有者が正当な保持者であることを生体認証により証明可能である。ZK-CredsやYilmazらのレビュー対象システムには、この本人性確認機能が実装されていない。そのため、正規の証明書を入手した第三者による不正使用を防ぐことができない

2.4.2 Self-Sovereign Identity（SSI）

SSI（Self-Sovereign Identity、自己主権型アイデンティティ）は、個人が自身のアイデンティティデータを管理・制御するパラダイムである [14]。従来の中央集権型アイデンティティ管理（企業や政府がデータを保持）に対し、SSIでは個人がデータの主権者となる。

SSIの基本原則

SSIは以下の原則に基づいている。

存在性（Existence）: アイデンティティは独立して存在する
制御性（Control）: ユーザーが自身のアイデンティティを制御する
アクセス性（Access）: ユーザーは自身のデータにアクセスできる
最小化（Minimization）: 開示は必要最小限にとどめる

主要なSSI実装

現在、SSIの実装として複数のプロジェクトが存在し、表2.3にその比較を示す。

表2.3: 主要なSSI実装の比較

プロジェクト	技術基盤	特徴	限界
Hyperledger Indy	許可型DLT	企業向け、高信頼性	参加障壁が高い
uPort/Veramo	Ethereum	開発者フレンドリー	ガス代、スケーラビリティ
ION (Microsoft)	Bitcoin	高いセキュリティ	トランザクション遅延

これらのSSI実装は、W3CのDID（Decentralized Identifiers）仕様 [16] およびVerifiable Credentials Data Model [17] に準拠している。

本研究とSSIの関係

本研究のアプローチは、SSIの原則に沿いつつ、以下の点で差別化される。

文書真正性への特化: SSIは汎用的なアイデンティティ管理を目指すが、本研究は「文書の真正性検証」という特定のユースケースに最適化している。
ZKP+WebAuthnの統合: 既存SSI実装にはない、ゼロ知識証明と生体認証の組み合わせを実現している。
実装の簡素さ: DLT不要のアーキテクチャにより、導入・運用コストを大幅に削減している。

2.5 本研究のポジショニング

2.5.1 既存手法との比較

以上の先行研究・技術基盤の分析を踏まえ、本研究の位置づけを明確にする。

デジタル証明書システムの比較

既存のデジタル証明書システムと本研究を、「分散性」と「プライバシー保護」の2軸で比較する。

quadrantChart
    title "デジタル証明書システムの比較"
    x-axis "中央集権型" --> "分散型"
    y-axis "プライバシー低" --> "プライバシー高"
    quadrant-1 "理想領域"
    quadrant-2 "従来型"
    quadrant-3 "非推奨"
    quadrant-4 "部分的解決"
    "X.509/PKI": [0.2, 0.3]
    "Open Badges": [0.4, 0.2]
    Blockcerts: [0.7, 0.4]
    "SSI Hyperledger": [0.6, 0.6]
    "本研究": [0.85, 0.9]

図2.1: デジタル証明書システムの比較

図2.1に示すように、既存手法にはそれぞれ「分散性」と「プライバシー保護」の両立において課題がある。従来のX.509/PKIは認証局への依存度が高く、Open Badgesは発行者サーバーへの依存がある。BlockcertsやHyperledger系のSSIはブロックチェーンにより分散性を確保しているが、プライバシー保護は限定的である。

技術的特徴の比較

本章で分析した既存手法の技術的特徴を表2.4にまとめる。

表2.4: 技術的特徴の比較

特徴	X.509	Open Badges	Blockcerts	SSI
証明方式	PKI署名	JSON署名	ブロックチェーン	DID/VC
検証鍵管理	CA	発行者サーバー	スマートコントラクト	DLT
オフライン検証	△	×	×	△
選択的開示	×	×	×	△
本人性確認	×	×	×	×
導入コスト	高	低	高	高

この比較から、既存手法には「選択的開示」と「本人性確認」の両方を実現するものがないことがわかる。これらの課題を解決する本研究のアプローチは、次章で詳述する。

第3章システム設計と実装

3.1 設計思想とアーキテクチャ

3.1.1 設計原則

Tri-CertFrameworkは、第1章で述べた3つの課題および第2章で分析した既存手法の限界を解決するため、以下の設計原則に基づいている。

既存手法の限界に対する本研究のアプローチ

第2章で分析した既存手法の限界に対して、本研究では表3.1に示すアプローチで対応する。

表3.1: 既存手法の限界と本研究のアプローチ

既存手法の限界	本研究での対応
X.509/PKI: 認証局への依存、長期的な鍵管理の困難さ	GitHubベースの分散管理、Ledger署名による鍵保護
Open Badges: 発行者サーバーへの検証時アクセスが必要	PDF埋め込みによるオフライン検証
Blockcerts: トランザクション手数料、スケーラビリティの課題	ブロックチェーン不要、無料で即時検証
EDCI: 特定の管轄地域（EU）への依存	地域に依存しないオープンな規格
全手法共通: 所有者の本人性を証明できない	WebAuthn/FIDO2による生体認証の統合

3つの課題に対する解決策

表3.2に3つの課題に対する解決策を示す。

表3.2: 課題と解決策の対応

課題	解決策	効果
真正性の担保が脆弱	改竄耐性（3層認証）	偽造は暗号学的に実行不可能
確認プロセスの非効率性	即時性（PDF埋め込み検証）	1〜2週間 → 数秒に短縮
過剰な個人情報の開示	秘匿性（ゼロ知識証明）	必要最小限の情報のみを開示

本研究の独自性（新規性）

第2章で分析した既存手法との比較から、本研究の独自性を表3.3に示す。

表3.3: 本研究の独自性

観点	既存手法の限界	本研究の解決策
プライバシー	属性が全て開示される	ZKPによる選択的証明
本人性確認	証明書の所有者を確認できない	WebAuthn署名の統合
インフラ依存	ブロックチェーン/サーバー必須	GitHubのみで運用可能
検証環境	オンライン接続が必要	完全オフライン検証対応
鍵管理	ユーザーによる秘密鍵管理	認証器内で鍵を保護

本研究は、ZKPによるプライバシー保護とWebAuthnによる本人性確認を統合した初めての文書真正性検証システムであり、既存手法では達成できなかった「プライバシーと信頼性の両立」を実現する。

設計原則

システム全体として以下の原則を採用している。

分散性（Decentralization）: 中央サーバーへの依存を最小化し、オフライン検証を可能にする
プライバシー・バイ・デザイン: 個人情報の最小限開示を設計段階から考慮
オープン性: オープンソースとして公開し、透明性と監査可能性を確保
段階的セキュリティ: ハードウェアセキュリティモジュール対応により、必要に応じてセキュリティレベルを向上可能

3.1.2 システムアーキテクチャ

Tri-CertFrameworkは、図3.1に示す4つの主要コンポーネントで構成される。

flowchart TD
    subgraph System ["Tri-CertFramework Architecture"]
        %% Top Layer
        subgraph Consoles [ ]
            direction LR
            RC["**Registrar Console**
(Wails/Go)

• 利用者（例：学生）登録
• アクティベーションコード（Salt）発行
• アクティベーションコード
リスト（AllowList）管理"]
            EC["**Executive Console**
(Tauri/Rust)

• VK生成
• Ledger署名
• VKNFT管理"]
        end

        %% Middle Layer
        subgraph GitHub ["GitHub Repository"]
            direction LR
            RegData["**registrations/**
• allowlist.json
• index.json"]
            VKData["**VKNFT/**
• 2025/manifest.json
• 2025/files/*.wasm
• 2025/files/*.zkey
• 2025/files/*.json"]
        end

        %% Bottom Layer
        subgraph WebApps [ ]
            direction LR
            Prover["**Prover**
(Next.js)

• PDF読込
• ZKP生成
• WebAuthn署名
• PDF出力"]
            Verifier["**Verifier UI**
(Next.js)

• PDF読込
• ZKP検証
• WebAuthn検証
• 登録確認"]
        end

        %% Connections
        RC --> RegData
        EC --> VKData
        
        GitHub --- Prover
        GitHub --- Verifier
        
        Prover -- "証明書PDF" --> Verifier
        
        %% Styling
        style Consoles fill:transparent,stroke:none
        style WebApps fill:transparent,stroke:none
    end

図3.1: Tri-CertFrameworkのシステムアーキテクチャ

3.1.3 検証プロセス

本フレームワークはデジタル文書全般に適用可能であるが、以下では教育機関における卒業証明書の検証を具体例として、データフローを説明する。

図3.3に、証明書の発行から検証までのデータフローを示す。

flowchart LR
    subgraph Phase1 ["1. 登録フェーズ"]
        A1[教務課職員] -->|学生情報| RC[Registrar Console]
        RC -->|Salt| A1
        RC -->|activation_hash| AL[(commit-allowlist.json)]
    end

    subgraph Phase2 ["2. VK準備フェーズ"]
        EC[Executive Console] -->|VK生成要求| ZK[ZKP回路]
        ZK -->|verification_key.json| EC
        EC -->|署名要求| LED[Ledger]
        LED -->|署名済みVK| EC
        EC -->|VKNFTバンドル| GH[(GitHub)]
    end

    subgraph Phase3 ["3. 証明生成フェーズ"]
        STU[学生] -->|PDF + Salt| PRV[Prover]
        GH -->|VKNFT| PRV
        AL -->|登録確認| PRV
        PRV -->|ZKP証明| PRV
        PRV -->|署名要求| WA[WebAuthn認証器]
        WA -->|署名| PRV
        PRV -->|証明付きPDF| STU
    end

    subgraph Phase4 ["4. 検証フェーズ"]
        VER[検証者] -->|証明付きPDF| VUI[Verifier UI]
        GH -->|VKNFT| VUI
        AL -->|登録状況| VUI
        VUI -->|検証結果| VER
    end

図3.3: データフロー図

各フェーズにおけるデータの流れを以下に説明する。

1. 登録フェーズ（Registrar Console）

このフェーズでは、発行機関が学生の情報をシステムに登録する。

入力データ:

学生の氏名、生年月日、卒業年度

生成されるデータ:

Salt（ランダムな16桁の文字列）: 学生に渡されるアクティベーションコード
activation_hash: 個人情報とSaltを組み合わせたハッシュ値

出力先:

Salt → 学生（書面またはメールで通知）
activation_hash → commit-allowlist.json（公開リポジトリ）

2. VK準備フェーズ（Executive Console）

このフェーズでは、年度ごとの検証鍵を生成し、署名して公開する。

入力データ:

ZKP回路の定義ファイル（commitment.circom）

生成されるデータ:

proving_key.json: 証明生成に使用する鍵（約50MB）
verification_key.json: 検証に使用する鍵（約2KB）
Ledger署名: 検証鍵の真正性を保証する署名

出力先:

VKNFTバンドル → GitHub（proving_key、verification_key、署名を含む）

3. 証明生成フェーズ（Prover）

このフェーズでは、学生が自身の証明書に対してZKP証明と署名を付与する。

入力データ:

卒業証明書PDF
Salt（アクティベーションコード）
氏名、生年月日

参照データ:

VKNFT（GitHubから取得）
commit-allowlist.json（登録確認用）

生成されるデータ:

ZKP証明（proof.json）: 証明書が正当であることの暗号学的証明
WebAuthn署名: 所有者の本人確認を証明する署名
公開鍵（JWK形式）: 署名検証用

出力:

証明付きPDF: 上記の全データを埋め込んだPDFファイル

4. 検証フェーズ（Verifier UI）

このフェーズでは、検証者が証明付きPDFの真正性を確認する。

入力データ:

証明付きPDF

参照データ:

VKNFT（GitHubから取得）
commit-allowlist.json（登録状況確認用）

検証内容:

ZKP証明の数学的検証
WebAuthn署名の検証
許可リストへの登録確認

出力:

検証結果（成功/失敗）
検証詳細（卒業年度、登録状況など）

3.1.4 3層認証の詳細

本システムの「3層認証」は、図3.2に示す3つの独立した認証メカニズムで構成される。

flowchart TD
    subgraph ThreeLayers ["3層認証構造"]
        L1["**第1層: 発行機関による登録**

• Saltの発行とactivation_hashの計算
• Allowlistへの登録
→ 発行機関が正当に登録したことを証明"]
        L2["**第2層: ゼロ知識証明（ZKP）**

• PDFハッシュ、卒業年度、秘密値のコミットメント
• Groth16[8]による証明生成
→ 文書の内容が改竄されていないことを証明"]
        L3["**第3層: WebAuthn署名**

• 認証器内での秘密鍵による署名
• 生体認証（Touch ID等）との連携
→ 提示者が正当な所有者であることを証明"]

        L1 --> L2
        L2 --> L3
    end

図3.2: 3層認証の構造

この3層構造は、それぞれが異なる観点から証明書の信頼性を担保している。以下、各層の役割と仕組みを詳細に説明する。

第1層: 発行機関による登録

第1層は、「この証明書が確かに正規の発行機関から発行されたものである」ことを保証する。

身近な例で説明すると、銀行口座を開設する際に本人確認書類を提出し、銀行が「この人は確かに存在する正当な顧客である」と認めて口座番号を発行するのと同様である。本システムでは、大学が「この学生は確かに本学を卒業した」と認めて登録を行う。

具体的な処理は以下の通りである。

教務課職員がRegistrar Consoleを使用して、学生の情報（氏名、生年月日、卒業年度）を入力
システムがランダムな値（Salt）を生成し、これを学生に渡す「アクティベーションコード」として使用
入力された情報とSaltを組み合わせて「activation_hash」を計算
このハッシュ値をcommit-allowlist.json（許可リスト）に登録

重要な点は、許可リストには個人情報が直接記録されないことである。記録されるのはハッシュ値のみであり、これを見ても元の個人情報を復元することは計算量的に不可能である。

第2層: ゼロ知識証明（ZKP）

第2層は、「この証明書の内容が発行時から一切改竄されていない」ことを保証する。

従来の電子署名では、署名を検証するために証明書の全内容を検証者に開示する必要があった。しかし、ZKPを使用することで、「卒業証明書の内容が正しい」という事実だけを証明し、具体的な内容（成績、学籍番号など）を開示せずに済む。

具体的な処理は以下の通りである。

学生がProverアプリケーションにPDFをアップロード
アプリケーションがPDFの内容からハッシュ値を計算
このハッシュ値、卒業年度、そして学生だけが知る秘密の値を組み合わせて「コミットメント」を生成
Groth16プロトコルを使用して、このコミットメントが正しいことの証明を生成

生成された証明は約200バイトと極めて小さく、PDFに埋め込んでも容量がほとんど増えない。また、証明からは元のデータを復元できないため、プライバシーが保護される。

第3層: WebAuthn署名

第3層は、「この証明書を提示している人が、証明書の正当な所有者である」ことを保証する。

紙の証明書の問題点の一つは、他人の証明書を借りて自分のものとして提示できることである。本システムでは、証明書の生成時に所有者の生体認証と紐付けることで、この問題を解決する。

具体的な処理は以下の通りである。

証明書生成時に、学生のデバイス（スマートフォンやパソコン）内で秘密鍵と公開鍵のペアを生成
秘密鍵はデバイス内のセキュアな領域（Touch IDやWindows Helloの認証器）に保管され、外部に出ることはない
学生が指紋認証や顔認証を行うと、秘密鍵を使って証明書に電子署名が付与される
公開鍵はPDFに埋め込まれ、検証者は公開鍵を使って署名を検証できる

この仕組みにより、たとえ証明書PDFが他人に渡ったとしても、秘密鍵を持たない人は有効な署名を付与できず、正当な所有者として証明書を提示することはできない。

3層の連携

3層認証の強みは、それぞれの層が独立して機能しつつ、相互に補完し合う点にある。表3.3に各層が防ぐ攻撃の種類を示す。

表3.3: 各認証層が防ぐ攻撃

攻撃の種類	第1層	第2層	第3層
架空の証明書の作成	○	-	-
既存証明書の内容改竄	-	○	-
他人の証明書の不正使用	-	-	○
発行機関の偽装	○	-	-
中間者攻撃	-	○	○

例えば、攻撃者が架空の卒業証明書を作成しようとしても、第1層の許可リストに登録されていないため検証に失敗する。既存の証明書を改竄しようとしても、第2層のZKP検証で改竄が検出される。他人の証明書を盗んで使用しようとしても、第3層の署名検証で本人でないことが判明する。このように、3層それぞれが異なる種類の攻撃を防ぐことで、システム全体として高いセキュリティを実現している。

3.2 Registrar Console

3.2.1 概要

Registrar Console（登録者コンソール）は、教務課職員が学生情報を登録するためのデスクトップアプリケーションである。Go言語とWailsフレームワークで実装されており、クロスプラットフォーム（Windows、macOS、Linux）で動作する。

画面構成

図3.3 にRegistrar Consoleのメイン画面を示す。

Registrar Console メイン画面

図3.3: Registrar Console メイン画面

画面左側に登録フォーム、右側に登録済み学生の一覧が表示される。職員は学籍番号、氏名、生年月日を入力し、「登録」ボタンを押すことで学生をAllowlistに追加する。

技術スタック

表3.4にRegistrar Consoleの技術スタックを示す。

表3.4: Registrar Consoleの技術スタック

コンポーネント	技術
バックエンド	Go 1.21
フロントエンド	React + TypeScript
デスクトップフレームワーク	Wails v2
ハッシュ関数	SHA3-512 (Keccak)

Wailsフレームワークを採用した理由は、Goの高速なバックエンド処理とWebベースのUI開発の柔軟性を両立可能であるためである。また、単一バイナリとして配布可能であり、インストールの手間を軽減できる点も利点として挙げられる。

学生登録機能

学生登録の入力データと出力データは以下の構造を持つ。

// 学生登録の入力データ構造
type StudentInput struct {
    StudentID      string `json:"studentId"`
    Name           string `json:"name"`
    Birthdate      string `json:"birthdate"`
    Salt           string `json:"salt,omitempty"`
    ActivationHash string `json:"activationHash,omitempty"`
    IssuedAt       string `json:"issuedAt,omitempty"`
}

// 登録結果のデータ構造
type RegistrationResult struct {
    StudentID            string `json:"studentId"`
    StudentIDHash        string `json:"studentIdHash"`
    ActivationHash       string `json:"activationHash"`
    Salt                 string `json:"salt"`
    DisplayName          string `json:"displayName"`
    NormalizedName       string `json:"normalizedName"`
    NormalizedBirthdate  string `json:"normalizedBirthdate"`
    AllowlistEntryIndex  int    `json:"allowlistEntryIndex"`
    AllowlistTotalLength int    `json:"allowlistTotalLength"`
    IssuedAt             string `json:"issuedAt"`
}

登録フロー

図3.4 に登録完了後のアクティベーションコード表示画面を示す。

登録完了・アクティベーションコード表示画面

図3.4: 登録完了・アクティベーションコード表示画面

登録が完了すると、学生に配布するアクティベーションコード（Salt）が生成される。このアクティベーションコードは学生本人のみに安全な方法で伝達され、証明生成時に必要となる。アクティベーションコードは一度しか表示されないため、職員は学生に確実に伝達する必要がある。

学生削除機能

図3.5 に学生削除画面を示す。

学生削除確認画面

図3.5: 学生削除確認画面

誤って登録した学生の削除も可能である。削除時には確認ダイアログが表示され、誤操作を防止する設計となっている。

3.2.3 ハッシュ計算アルゴリズム

図3.28にハッシュ計算アルゴリズムの実装を示す。学生の認証に使用するハッシュは、Salt、正規化された氏名・生年月日、および学籍番号から生成される。

// activation_hash: Salt + 正規化氏名 + 正規化生年月日のSHA-512
func hashActivation(salt, name, birthdate string) string {
    h := sha512.Sum512([]byte("activation|" + salt + "|" + name + "|" + birthdate))
    return "sha512:" + hex.EncodeToString(h[:])
}

// student_id_hash: 学籍番号のSHA-512（個人情報保護のため）
func hashStudentID(studentID string) string {
    normalized := strings.ToUpper(strings.TrimSpace(studentID))
    sum := sha512.Sum512([]byte("student-id|" + normalized))
    return "sha512:" + hex.EncodeToString(sum[:])
}

図3.28: ハッシュ計算アルゴリズムの実装（Go）

3.2.4 Allowlistの構造

登録情報はcommit-allowlist.jsonとして公開される。図3.29にAllowlistファイルの構造を示す。このファイルには個人情報は含まれず、ハッシュ値のみが記録される。

{
  "schema": "tri-cert/commit-allowlist@1",
  "updated_at": "2025-11-27T05:37:44Z",
  "entries": [
    {
      "activation_hash": "sha512:c0f81b3fbd581e20ee7f681b72...",
      "student_id_hash": "sha512:db9510df3af0919feac2cd1fab...",
      "created_at": "2025-11-27T05:37:44Z",
      "updated_at": "2025-11-27T05:37:44Z"
    }
  ]
}

図3.29: Allowlistファイルの構造（JSON）

3.2.5 一括登録機能

大規模な教育機関での運用を想定し、CSVファイルによる一括登録機能を実装している。1名1行のCSVファイルをインポートすることで、複数の学生を一括登録可能である。

CSV一括登録画面

図3.6 にCSV一括登録画面を示す。

CSV一括登録画面

図3.6: CSV一括登録画面

CSVファイルの形式は以下の通りである。

studentId,name,birthdate
24001,山田太郎,1999-04-15
24002,佐藤花子,2000-01-20
24003,鈴木一郎,1999-12-01

処理フロー

一括登録は以下の手順で処理される。

CSVパース: ファイルを読み込み、各行を解析
バリデーション: 学籍番号の重複チェック、日付形式の検証
ハッシュ計算: 各学生のactivationHashを計算
アクティベーションコード生成: 暗号学的に安全な乱数でアクティベーションコード（Salt）を生成
Allowlist更新: GitHubリポジトリのJSONファイルを更新
結果出力: 各学生のアクティベーションコードをCSVファイルとして出力

一括登録完了後、各学生のアクティベーションコードを含むCSVファイルのエクスポートが可能である。このファイルは厳重に管理し、各学生に個別に配布する必要がある。

3.3 Executive Console

3.3.1 概要

Executive Console（管理者コンソール）は、ゼロ知識証明の検証鍵（Verification Key, VK）を生成・管理するためのデスクトップアプリケーションである。RustとTauriフレームワークで実装されており、ハードウェアウォレット（Ledger）との連携機能を備える。

画面構成

図3.7 にExecutive Consoleのメイン画面を示す。

Executive Console メイン画面

図3.7: Executive Console メイン画面

Executive Consoleは以下の3つのタブで構成される。

VK生成タブ: 年度ごとの検証鍵バンドルを生成
VK管理タブ: 発行済みの検証鍵を一覧表示・管理
設定タブ: Ledger接続やGitHub連携の設定

技術スタック

表3.5にExecutive Consoleの技術スタックを示す。

表3.5: Executive Consoleの技術スタック

コンポーネント	技術
バックエンド	Rust 1.75
フロントエンド	React + TypeScript
デスクトップフレームワーク	Tauri v2
ZKP回路	Circom[10] 2.1
証明システム	snarkjs[9] (Groth16[8])
署名	Ledger (ECDSA secp256k1)

Tauriフレームワークを採用した理由は、Rustの安全性とパフォーマンスを活用しつつ、Ledgerとの低レベル通信を実装可能であるためである。また、Electronと比較してバイナリサイズが小さく、メモリ使用量も少ないという利点がある。

3.3.2 VK生成プロセス

年度ごとの検証鍵を生成するプロセスは以下の通りである。

回路ファイル準備: Circom[10]で記述されたZKP回路をコンパイル
WASM/ZKey生成: ブラウザで実行可能なWASMファイルと証明鍵を生成
VKハッシュ計算: 検証鍵のSHA3-256ハッシュを計算
バンドル作成: マニフェストファイルとともにZIPアーカイブを作成
Ledger署名: ハードウェアウォレットでZIPのハッシュに署名

VK生成画面

図3.8 にVK生成画面を示す。

VK生成画面

図3.8: VK生成画面

管理者は年度を選択し、「生成」ボタンを押すことでVKバンドルの生成を開始する。生成には数分を要し、進捗状況がリアルタイムで表示される。

バンドル生成完了画面

図3.9 にバンドル生成完了画面を示す。

VKバンドル生成完了

図3.9: VKバンドル生成完了画面

生成が完了すると、VKバンドルのハッシュ値とLedger署名が表示される。管理者はこの情報を確認し、GitHubリポジトリにアップロードする。

Ledger署名プロセス

VKバンドルの署名には、ハードウェアウォレットLedgerを使用する。図3.10〜3.15 にLedger署名プロセスを示す。

Ledger署名待機画面

図3.10: Ledger署名待機画面

Ledger署名タスク受信

図3.11: Ledger署名タスク受信

図3.11に示すように、Ledgerデバイスが接続されると署名タスクがデバイスに送信される。

署名詳細確認（1/2）

図3.12: 署名詳細確認（1/2）

署名詳細確認（2/2）

図3.13: 署名詳細確認（2/2）

図3.12および図3.13に示すように、管理者はLedgerの画面でハッシュ値を確認し、物理ボタンで署名を承認する。

署名確認

図3.14: 署名確認

署名完了

図3.15: 署名完了

図3.14で署名の最終確認を行い、図3.15に示す署名完了画面が表示される。この物理的な承認プロセスにより、秘密鍵がLedgerの外部に出ることなく、安全に署名が行われる。

署名ログ

図3.16 に署名処理のログを示す。

署名処理ログ

図3.16: 署名処理ログ

署名プロセスの各ステップがログに記録され、監査可能性を確保している。

3.3.3 VKNFTバンドル構造

生成された検証鍵は、VKNFT（Verification Key Non-Fungible Token）形式でバンドル化される。なお、現時点ではブロックチェーン上のNFTとしての実装は行っていないが、将来的なオンチェーン管理への拡張を想定してこの名称を採用している。図3.30にVKNFTバンドルのディレクトリ構造を示す。

VKNFT/
└── 2025/
    ├── manifest.json           # メタデータとハッシュ値
    ├── vk_bundle_2025.zip      # 全ファイルのアーカイブ
    ├── vk_bundle_2025.sig      # Ledger署名
    └── files/
        ├── commitment_2025.wasm     # 回路のWASM
        ├── commitment_final_2025.zkey # 証明鍵
        └── vkey_2025.json           # 検証鍵

図3.30: VKNFTバンドルのディレクトリ構造

3.3.4 マニフェストファイル

図3.31にマニフェストファイルの構造を示す。マニフェストファイルには、ファイルの整合性検証に必要なハッシュ値とLedger署名情報が含まれる。

{
  "schema": "tri-cert/vknft-bundle@1",
  "version": 1,
  "year": 2025,
  "generatedAt": "2025-11-26T04:54:22.353Z",
  "files": {
    "wasm": {
      "fileName": "commitment_2025.wasm",
      "sha3_256": "5c26eade3de675ee6c3156be3ac849da...",
      "size": 1747662
    },
    "zkey": {
      "fileName": "commitment_final_2025.zkey",
      "sha3_256": "c128eb21ab54cc8dbd1aea3cf025c269...",
      "size": 254684
    },
    "vk": {
      "fileName": "vkey_2025.json",
      "sha3_256": "fb070e76b1d53fc02216281ce624c918...",
      "size": 3396,
      "declaredHash": "bc6d09e8aed9cda9518ff11b82442174..."
    }
  },
  "ledgerSignature": {
    "scheme": "ledger-hardware",
    "algorithm": "ECDSA_secp256k1_SHA256",
    "signatureBase64": "+1HHKunoARxxPYwr9RYwLTcy5vbj...",
    "publicKeyJwk": { ... }
  }
}

図3.31: マニフェストファイルの構造（JSON）

3.4 Prover（証明生成UI）

3.4.1 概要

Prover（証明者）は、学生が卒業証明書PDFに対してゼロ知識証明とWebAuthn署名を添付するためのWebアプリケーションである。Next.js 15とReact 19で実装されており、ブラウザ上で動作する。

画面構成

図3.17 にProverの初期画面を示す。

Prover 初期画面

図3.17: Prover 初期画面

初期画面では、PDFファイルのドラッグアンドドロップエリアが表示される。ユーザーは卒業証明書のPDFをアップロードすることで、証明生成プロセスを開始する。

技術スタック

表3.6にProverの技術スタックを示す。

表3.6: Proverの技術スタック

コンポーネント	技術
フレームワーク	Next.js 15 (App Router)
UIライブラリ	React 19
スタイリング	Tailwind CSS
ZKP生成	snarkjs[9] (WebAssembly)
署名	WebAuthn API[12]
PDF操作	pdf-lib

セキュリティ設計

Proverはクライアントサイドで完全に動作し、サーバーに機密情報を送信しない設計である。

アクティベーションコード: ユーザーの入力値はブラウザ内でのみ処理
秘密鍵: WebAuthn認証器内で生成・保持
PDFコンテンツ: サーバーにアップロードされない

この設計により、中間者攻撃やサーバー侵害による情報漏洩のリスクを排除している。

3.4.2 証明生成フロー

図3.32に証明生成フローの実装を示す。証明生成は5つのステップで構成される。

// 証明生成の主要ステップ
async function generateProof() {
  // Step 1: Salt検証（Allowlistとの照合）
  const saltResult = await verifySalt(saltInput, studentName, birthdate);
  if (!saltResult.isValid) {
    throw new Error('Salt verification failed');
  }

  // Step 2: PDFハッシュ計算（SHA3-512）
  const pdfHash = await calculatePdfHash(pdfBytes);

  // Step 3: ZKP生成（Groth16[8]）
  const { proof, vkey } = await generateZKProof(
    secret,      // 証明者の秘密値
    pdfHash,     // PDFのハッシュ
    graduationYear
  );

  // Step 4: WebAuthn署名
  const signature = await createWebAuthnSignature(
    proof,
    vkey,
    pdfHash,
    webauthnCredential
  );

  // Step 5: PDFへの証明添付
  const outputPdf = await attachToPdf(pdfBuffer, proof, signature, vkey);

  return outputPdf;
}

図3.32: 証明生成フローの実装（TypeScript）

アクティベーションコード入力画面

図3.18、図3.19 にアクティベーションコード入力画面を示す。

アクティベーションコード入力画面（入力前）

図3.18: アクティベーションコード入力画面（入力前）

ユーザーはPDFをアップロード後、教務課から配布されたアクティベーションコード（Salt）を入力する。アクティベーションコードは学籍番号、氏名、生年月日と組み合わせてハッシュ化され、Allowlistとの照合に使用される。

アクティベーションコード入力画面（入力後）

図3.19: アクティベーションコード入力画面（入力後）

アクティベーションコードの検証が成功すると、「検証成功」のメッセージが表示され、証明生成ボタンが有効化される。

WebAuthn認証

図3.20 にWebAuthn認証ダイアログを示す。

WebAuthn認証ダイアログ

図3.20: WebAuthn認証ダイアログ

証明生成時にWebAuthn認証が要求される。ユーザーはTouch ID、Face ID、Windows Hello、またはセキュリティキーを使用して認証を行う。この認証により、証明書の所有者が本人であることが暗号学的に証明される。

証明生成完了

図3.21 に証明生成完了画面を示す。

証明生成完了画面

図3.21: 証明生成完了画面

証明生成が完了すると、証明付きPDFのダウンロードボタンが表示される。生成されたPDFには、ゼロ知識証明とWebAuthn署名が埋め込まれており、Verifier UIで検証可能である。

3.4.3 ZKP回路の設計

本システムで使用するZKP回路は、Poseidonハッシュ[11]を用いたコミットメントスキームに基づいている。図3.33に回路の概念的な構造を示す。

// 回路の概念的な構造
circuit Commitment {
    // 公開入力
    signal input pdf_sha3_512;      // PDFのハッシュ（有限体に縮小）
    signal input graduation_year;    // 卒業年度

    // 秘密入力
    signal input owner_secret;       // 証明者の秘密値

    // 公開出力
    signal output commit;            // コミットメント値

    // Poseidonハッシュによるコミットメント計算
    commit <== Poseidon(owner_secret, pdf_sha3_512, graduation_year);
}

図3.33: ZKP回路の概念的構造（Circom）

3.4.4 PDFへの証明埋め込み

生成された証明は、PDFのメタデータ（Subject フィールド）にBase64エンコードして埋め込まれる。暗号化されたPDFの場合は、ファイル末尾に追記する方式（tail-append）を使用する。図3.34に証明バンドルのインターフェース定義を示す。

// 証明バンドルの構造
interface ProofBundle {
  version: '1.0';
  hash_method: 'raw' | 'normalized';
  proof: ProofData;
  vkey: VKeyData;
  webauthn_sig: WebAuthnSignature;
  webauthn_pub: JsonWebKey;
  sig_target: SignatureTarget;
}

図3.34: 証明バンドルのインターフェース定義（TypeScript）

3.5 Verifier UI（検証UI）

3.5.1 概要

Verifier UI（検証者UI）は、証明付きPDFの真正性を検証するためのWebアプリケーションである。Proverと同様にNext.js 15で実装されており、オフラインでも動作可能である。

画面構成

図3.22 にVerifier UIの初期画面を示す。

Verifier UI 初期画面

図3.22: Verifier UI 初期画面

初期画面では、PDFファイルのアップロードエリアが表示される。検証者（採用担当者など）は、受け取った卒業証明書PDFをアップロードすることで、検証プロセスを開始する。

技術スタック

表3.7にVerifier UIの技術スタックを示す。

表3.7: Verifier UIの技術スタック

コンポーネント	技術
フレームワーク	Next.js 15 (App Router)
UIライブラリ	React 19
スタイリング	Tailwind CSS
ZKP検証	snarkjs[9] (WebAssembly)
署名検証	WebCrypto API
PDF操作	pdf-lib

オフライン動作

Verifier UIはService Workerを使用してオフラインでも動作する。検証に必要なファイル（検証鍵、WASM）は初回アクセス時にキャッシュされ、インターネット接続がない環境でも検証を実行可能である。これは、セキュリティが重視される企業内ネットワークでの運用を想定した設計である。

3.5.2 検証プロセス

検証は以下の5つのステップで行われる。

const verificationSteps = [
  { id: 'extract',     name: 'データ抽出',   description: 'PDFから証明データを抽出' },
  { id: 'hash',        name: 'ハッシュ検証', description: 'PDFハッシュの一致確認' },
  { id: 'zkp',         name: 'ZKP検証',     description: 'ゼロ知識証明の検証' },
  { id: 'signature',   name: '署名検証',    description: 'WebAuthn署名の検証' },
  { id: 'registration', name: '登録確認',   description: 'Allowlistとの照合' },
];

検証中の画面

図3.23 に検証中の5ステップ表示を示す。

検証プロセス表示

図3.23: 検証プロセス表示

検証は自動的に5つのステップを順番に実行する。各ステップの進捗状況がリアルタイムで表示され、ユーザーは検証の進行状況を視覚的に把握可能である。

検証成功時の画面

図3.24 に検証成功時の結果画面を示す。

検証成功画面（詳細情報）

図3.24: 検証成功画面（詳細情報）

検証が成功すると、以下の情報が表示される。

検証ステータス: 5つのステップすべてが成功
証明書情報: 卒業年度、発行機関名
公開鍵情報: WebAuthn署名に使用された公開鍵のフィンガープリント

検証結果の詳細説明

図3.25 に検証結果の詳細説明画面を示す。

検証結果の説明

図3.25: 検証結果の詳細説明

検証者は各検証ステップの詳細を確認可能である。これにより、非技術者であっても検証結果の意味を理解することが可能となる。

検証失敗時の画面

図3.26、図3.27 に検証失敗時の画面を示す。

検証失敗画面（概要）

図3.26: 検証失敗画面（概要）

検証失敗画面（詳細）

図3.27: 検証失敗画面（詳細）

検証が失敗した場合、失敗したステップが明確に表示される。失敗の原因として想定されるケースを表3.8に示す。

表3.8: 検証失敗時の原因一覧

失敗ステップ	考えられる原因
データ抽出	PDFが証明付きでない、またはファイルが破損
ハッシュ検証	PDFが改竄されている
ZKP検証	証明データが不正、または検証鍵が不一致
署名検証	署名が無効、または公開鍵が改竄されている
登録確認	Allowlistに登録されていない

3.5.3 ZKP検証

Groth16[8]証明の検証は、snarkjs[9]ライブラリを使用して行われる。図3.35にZKP検証の実装を示す。

async function verifyZKP(
  proof: ProofData,
  vkey: VKeyData,
  options?: { calculatedPdfHashHex?: string }
): Promise<boolean> {
  const snarkjs = await import('snarkjs');

  // BN128曲線の素体位数
  const FIELD_MODULUS = BigInt('21888242871839275222246405745257275088548364400416034343698204186575808495617');

  // 公開入力の準備
  const commitField = proof.public_signals.commit.replace('field:', '');
  const pdfField = (BigInt('0x' + pdfHex) % FIELD_MODULUS).toString();
  const year = proof.public_signals.graduation_year;

  // 検証実行
  const isValid = await snarkjs.groth16.verify(
    vkey,
    [commitField, pdfField, year],
    {
      pi_a: proof.proof.pi_a,
      pi_b: proof.proof.pi_b,
      pi_c: proof.proof.pi_c,
    }
  );

  return isValid;
}

図3.35: ZKP検証の実装（TypeScript）

3.5.4 WebAuthn署名検証

WebAuthn[12]署名の検証は、クライアントサイドで完結する。図3.36にWebAuthn署名検証の実装を示す。

async function verifyWebAuthnComplete(
  context: SignatureVerificationContext
): Promise<{ isValid: boolean }> {
  const { webauthn, sig_target, webauthn_pub } = context;

  // 1. clientDataJSONの検証
  const clientDataJSON = JSON.parse(atob(webauthn.clientDataJSON));
  const expectedChallenge = await calculateChallenge(sig_target);
  if (clientDataJSON.challenge !== expectedChallenge) {
    return { isValid: false };
  }

  // 2. ECDSA署名の検証
  const publicKey = await importJWK(webauthn_pub);
  const signedData = concatenate(
    base64ToBytes(webauthn.authenticatorData),
    sha256(base64ToBytes(webauthn.clientDataJSON))
  );

  const isValid = await crypto.subtle.verify(
    { name: 'ECDSA', hash: 'SHA-256' },
    publicKey,
    base64ToBytes(webauthn.signature),
    signedData
  );

  return { isValid };
}

図3.36: WebAuthn署名検証の実装（TypeScript）

3.6 データ構造とプロトコル

3.6.1 証明データスキーマ

本システムで使用する主要なデータスキーマを図3.37、図3.38に示す。

証明データ (proof.json)

{
  "schema": "tri-cert/proof@0",
  "circuit_id": "commitment_poseidon_2025_v1",
  "vkey_hash": "sha3-256:bc6d09e8aed9cda9518ff11b82442174...",
  "public_signals": {
    "pdf_sha3_512": "hex:a1b2c3d4e5f6...",
    "graduation_year": "2025",
    "commit": "field:12345678901234567890..."
  },
  "proof": {
    "pi_a": ["...", "..."],
    "pi_b": [["...", "..."], ["...", "..."]],
    "pi_c": ["...", "..."]
  },
  "registration": {
    "activation_hash": "sha512:c0f81b3fbd581e20...",
    "student_id_hash": "sha512:db9510df3af0919f...",
    "verified_at": "2025-11-27T10:30:00Z"
  }
}

図3.37: 証明データスキーマ（JSON）

署名ターゲット (sig_target.json)

{
  "schema": "tri-cert/sig-target@0",
  "circuit_id": "commitment_poseidon_2025_v1",
  "vkey_hash": "sha3-256:bc6d09e8aed9cda9518ff11b82442174...",
  "pdf_sha3_512": "hex:a1b2c3d4e5f6...",
  "graduation_year": "2025",
  "commit": "field:12345678901234567890...",
  "issued_at": "2025-11-27T10:30:00Z"
}

図3.38: 署名ターゲットスキーマ（JSON）

3.6.2 ハッシュアルゴリズム

本システムでは、表3.9に示すように用途に応じて複数のハッシュアルゴリズムを使用している。

表3.9: ハッシュアルゴリズムの使い分け

用途	アルゴリズム	理由
PDFハッシュ	SHA3-512	高いセキュリティ強度、量子耐性への備え
VKハッシュ	SHA3-256	十分なセキュリティと簡潔さのバランス
学生ID/Activation	SHA-512	広く実装されており、十分な強度
ZKP内部	Poseidon	ZKP回路に最適化された構造

3.6.3 国際化対応

ProverおよびVerifier UIは、日本語と英語の2言語に対応している。翻訳データはJSONファイルで管理され、動的な切り替えが可能である。

第4章検証

4.1 検証方法

4.1.1 検証手順

本システムの検証は、以下の手順で実施した。

Registrar Consoleを使用し、テスト用の学生データを登録する
生成されたアクティベーションコード（Salt）を用いて、Proverにおいて証明ファイル付きPDFを作成する
作成されたPDFをVerifier UIで検証する
利用者（学生視点）および検証者（企業視点）の双方の観点から、システムのUI/UXに関するフィードバックを収集する

4.1.2 協力者

本検証にあたり、以下の協力者の参加を得た。

協力者A: 医療関連資格確認業務における実務経験を有する
協力者B: 学生および企業双方の立場に対する深い理解を有する
協力者C: 現役会社員として営業・技術両面の知見を有する
協力者D: セキュリティ分野に精通している

4.2 検証結果

4.2.1 システム利用体験後のフィードバック

協力者A

初見時の所感

「できた！これは安心できるね」

肯定的評価

本人がこのPDFを厚生労働省の専用ページへアップロードすることで届出が可能となれば、煩雑な事務処理を大幅に削減できる
現在、資格確認はExcelシートによる代行手続きが導入されたばかりであり、エラーの多発により現場は混乱している。本システムが資格確認の標準となれば、実務負担のみならず心理的負担も軽減される可能性がある

今後への期待

証明ファイル付きPDFは、現在在職中の看護師全員を初回登録する際には負担が生じるものの、一度作成すれば期限付きの資格ではないため、以降は新入職者のみを登録すればよい
退職時に証明書の有効期限が失効するシステムであれば、より実用的である

懸念点

大規模病院等における1000人規模の届出に対応可能かという疑問が残る

懸念への対応

アクティベーションコードは1名1行のCSV形式で一括発行できる設計としている
1000人分を手書きで処理する場合と比較して、事務担当者の負担軽減につながるとの評価を得た
定期的に証明書の有効期限が満了する設計を採用し、管理ソフトから登録を抹消することでアクティベーションコードが無効となる機能を実装済みである

協力者B

表4.2に定量評価（5段階評価）の結果を示す。

表4.2: 協力者Bによるシステム評価

評価項目	スコア
Proverの理解しやすさ	4 / 5
Proverの操作しやすさ	5 / 5
Verifierの理解しやすさ	4 / 5
Verifierの操作しやすさ	5 / 5

肯定的評価

円滑に動作した

懸念点

ガイドのみでは仕組みの理解が困難である可能性がある
ZKP等の複雑な技術を簡潔に説明することは困難である

今後への期待

応用例（他分野への適用可能性）の拡大

協力者C

表4.3に定量評価（5段階評価）の結果を示す。

表4.3: 協力者Cによるシステム評価

評価項目	スコア
Proverの理解しやすさ	4 / 5
Proverの操作しやすさ	2.5 / 5
Verifierの理解しやすさ	2 / 5
Verifierの操作しやすさ	5 / 5

肯定的評価

ステップ形式で進行し、各タスクの完了後に自動的に次のステップへ遷移するため、操作手順が明確である

改善要望

Prover関連:

氏名入力時に姓と名の間に空白を挿入しないことを明記する必要がある
認証器を使用できない環境ではProverが利用不可であることを明記する必要がある
「ファイルを選択」ボタンがタップ可能であることが視認しにくい（アイコンの拡大、PDFファイルのみ受付可能である旨の明示等）
生年月日の入力が煩雑である（年・月・日を一括入力可能なUIが望ましい）
日付選択時に再選択が必要となる点が円滑な操作の妨げとなる

Verifier関連:

応募者の学歴を検証する立場（人事担当者）として、教育機関もTri-Cert Frameworkを導入しているという実感を得られる表示が必要である
Proverで付与された証明ファイルが信頼に値する理由が不明確である
「オープンソースであるため安全である」という説明は、非エンジニアには理解しにくい
発行機関が学生をシステムに登録した事実を明示する必要がある
契約者情報（教育機関側と取り決めた公開情報）の表示が必要である（例：神戸情報大学院大学学生課電話番号）

協力者D

協力者Dからのフィードバックは、本論文の執筆期間内に得られなかった。

表4.1に本システムと従来手法の検証時間を比較した性能評価を示す。

4.2.2 性能評価

表4.1: 検証時間の比較

検証方法	所要時間	備考
従来（郵送照会）	1〜2週間	手数料も発生
従来（電話照会）	数日	担当者不在時は遅延
本システム	約3秒	オフライン可能

本システムの処理時間の内訳を表4.1bに示す。証明生成（Prover）と検証（Verifier）では処理内容が異なるため、それぞれの時間を計測した。測定環境はMacBook Pro（M1チップ）、Chrome 120で、5回の試行の平均値である。

表4.1b: 本システムの処理時間内訳

処理	所要時間	内容
証明生成（Prover側）	約2〜3秒	PDFハッシュ計算、ZKP証明生成、WebAuthn署名
検証処理（Verifier側）	約0.5〜1秒	ZKP検証、署名検証、登録確認
全体プロセス	約3秒	証明生成から検証完了まで

検証処理のみに着目すると約0.5〜1秒で完了するが、本論文では利用者の体験全体を考慮し、「約3秒」を代表値として使用する。

4.2.3 検証結果の総括

本節では、4.2.1節および4.2.2節で示したフィードバックと性能評価の結果を総括し、本システムの評価を行う。

協力者の属性と評価傾向

表4.4に示すように、協力者の属性によって評価の観点と傾向に明確な違いが見られた。

表4.4: 協力者属性と評価傾向の対応

協力者	属性	評価傾向
A	医療関連資格確認業務の実務者	実務視点で高評価。大規模運用への懸念はあるが、CSV一括発行機能により解消
B	学生・企業双方の視点を持つ	操作性は高評価（5/5）。技術説明の難しさを指摘
C	営業・技術両面の知見を持つ会社員	UX面で詳細な改善要望。非エンジニアへの説明性を重視

プロトタイプとしての達成度

本検証を通じて、以下の点が確認された。

核心機能の動作確認: ZKP証明生成・検証、WebAuthn署名、登録確認という3層認証の核心機能は、全協力者において正常に動作した。これにより、技術的実証としては成功したと評価できる。

実務適用への可能性: 協力者Aからは「現在の資格確認はExcelシートによる代行手続きでエラーが多発している。本システムが標準となれば、実務負担のみならず心理的負担も軽減される」との評価を得た。これは、本システムが単なる技術実証を超え、実務における課題解決に貢献しうることを示している。

UIの洗練は今後の課題: 協力者Cからは具体的なUI改善要望が多数寄せられた。これらは今後の実用化に向けて対応すべき課題である。

「最小限開示」と「信頼の可視化」のトレードオフ

本検証において、協力者Cから発行機関情報の表示を求める要望が寄せられた。具体的には、「発行機関が学生をシステムに登録した事実を明示する必要がある」「契約者情報（教育機関側と取り決めた公開情報）の表示が必要である」という指摘である。

これは一見、本研究の「必要最小限の情報開示」という設計思想と矛盾するように思われる。本システムはZKPを用いて「検証に必要な情報のみを開示する」という原則に基づいて設計されているからである。

しかし、詳細な分析の結果、このトレードオフは見かけ上のものであることが判明した。協力者Cが求める「発行機関の公開情報」は、学生個人のプライバシーとは無関係な情報である。発行機関名、公式HP URL、問い合わせ先電話番号などは元来公開されている情報であり、これを検証結果に併記しても保持者のプライバシーは一切侵害されない。

すなわち、ZKPが保護すべき対象は「証明書保持者の個人情報」であり、発行機関の公開情報はこの保護対象に含まれない。「表示情報を増やす」ことと「プライバシーを保護する」ことは、保護対象のレイヤーが異なるため両立可能である。

この知見は、プライバシー保護技術の実用化において重要な示唆を与える。技術的な設計思想（最小限開示）とユーザーの心理的安心感（信頼の可視化）は、保護対象を明確に区別することで両立できる。具体的には、検証成功画面に発行機関名、公式HP URL、問い合わせ先を表示することで、技術に詳しくない検証者でも「この証明書の出所を確認できる」という安心感を得られる設計が可能である。

当初課題に対する解決状況

第1章で提示した3つの課題に対して、本システムがどのように改善をもたらしたかを表4.5に整理する。

表4.5: 当初課題と本システムによる解決

当初の課題	従来の問題	本システムによる解決	検証での確認結果
課題1: 真正性の担保が脆弱	目視確認では偽造を見破れない	ZKPによる暗号学的な改竄検知	全協力者でZKP検証が正常動作。改竄されたPDFは即座に検出
課題2: 確認プロセスが非効率	照会に1〜2週間、手数料発生	オンラインで即時・無料の検証	検証時間は約3秒（表4.1b参照）。協力者Aより「業務効率化に貢献」との評価
課題3: 過度な個人情報開示	検証に不要な情報まで開示	ZKPで必要最小限の情報のみ証明	検証者に開示されるのは「卒業年度」と「登録済み」の事実のみ

課題1（真正性の担保）への対応:

従来の紙やPDFによる証明書は、目視確認に依存していたため、精巧な偽造を見破ることが困難であった。本システムでは、3層認証（発行機関による登録、ZKP、WebAuthn署名）により、証明書の真正性を暗号学的に保証する。検証時には、ZKP証明の数学的検証、WebAuthn署名の検証、許可リストへの登録確認が自動的に行われ、いずれか一つでも不正があれば検証は失敗する。

課題2（確認プロセスの非効率性）への対応:

従来は発行元への直接照会が必要であり、郵送での確認には1〜2週間を要し、手数料も発生していた。本システムでは、検証者がWebブラウザ上でPDFをアップロードするだけで、即時に検証結果が得られる。発行機関への問い合わせは不要であり、24時間365日、無料で検証が可能である。性能評価の結果、全体プロセスで約3秒（検証処理のみでは約0.5〜1秒）であり、実務における時間的・金銭的コストを大幅に削減できることが確認された。

課題3（過度な個人情報開示）への対応:

従来は、卒業の事実を確認するためだけに成績証明書の提出を求められるなど、検証に不要な個人情報まで開示させられる問題があった。本システムでは、ZKPの特性を活用し、検証に必要な情報（証明書が正当であること）のみを証明し、それ以外の情報（氏名、学籍番号、成績など）は一切開示されない。検証者が確認できるのは「卒業年度」と「発行機関に登録されている」という事実のみである。

定量的目標の達成度

第1章（表1.2）で設定した定量的目標に対する達成状況を表4.6に示す。

表4.6: 定量的目標の達成状況

目標項目	目標値	検証結果	達成状況
真正性の担保（セキュリティ）	128ビット以上	Groth16（BN128曲線）により128ビットの計算量的安全性を達成	達成
確認プロセスの効率化（検証時間）	5秒以内	約3秒（表4.1b参照）	達成
個人情報開示の最小化（開示項目数）	2項目以下	卒業年度・登録状態の2項目のみ	達成

3つの定量的目標すべてにおいて、設定した基準を満たすことが確認された。

総合評価

以上の検証結果から、本システムは以下のように評価される。

技術的実証: 成功。3層認証の核心機能は全協力者で正常動作
定量的目標の達成: 達成。3項目すべてで目標値をクリア（表4.6）
実用可能性: 高い。実務者からは業務効率化への期待が示された
UI/UX: 改善の余地あり。特に非エンジニア向けの説明性向上が課題
設計思想の妥当性: 確認。プライバシー保護と信頼性の両立は、保護対象の明確化により実現可能
当初課題の解決: 第1章で提示した3つの課題すべてに対して、技術的解決策を提示し、その有効性を検証で確認

4.3 セキュリティ評価

4.3.1 脅威モデル

前節までに述べたユーザー評価は、本システムの操作性や実用可能性に関する評価であった。しかし、本システムは証明書の真正性検証を目的としており、その性質上セキュリティの確保が極めて重要である。ユーザビリティが優れていても、セキュリティ上の脆弱性が存在すれば証明書システムとしての信頼性は担保されない。したがって本節では、ユーザー評価とは別の観点から、本システムのセキュリティ特性について独自の評価を行う。

本システムのセキュリティ評価にあたり、以下の脅威モデルを想定する。

攻撃者A1（外部攻撃者）: 正当な証明書を保持しない第三者が、偽造証明書の作成を試みる
攻撃者A2（内部攻撃者）: 正当な証明書を保持する学生が、他者の証明書の偽造を試みる
攻撃者A3（サーバー侵害者）: GitHubリポジトリまたはVKNFTディレクトリの改竄を試みる

4.3.2 セキュリティ保証

ZKPによる偽造防止

Groth16プロトコルの健全性（Soundness）[8]により、正しいowner_secretを知らない攻撃者が有効な証明を生成することは計算量的に不可能である。この保証は、KEA（Knowledge of Exponent Assumption）とq-SDH仮定に基づいている。

攻撃成功確率: negl(λ)  ※ λはセキュリティパラメータ

WebAuthnによる本人確認

WebAuthn/FIDO2[12]による署名は、認証器内で生成された秘密鍵でのみ作成可能である。認証器から秘密鍵を抽出することは、ハードウェアレベルで防止されている。

Ledger署名によるVK保護

Executive Consoleで生成されるVKはLedgerハードウェアウォレットで署名されており、攻撃者がVKを改竄しても署名検証に失敗する。

これらの保証に基づき、表4.5に想定される攻撃シナリオと対策を示す。

4.3.3 攻撃シナリオ分析

表4.5: 攻撃シナリオと対策

攻撃シナリオ	対策	残存リスク
偽のZKP証明生成	Groth16の健全性	計算量的に不可能
WebAuthn署名偽造	FIDO2ハードウェア保護	認証器の物理的盗難
VKの改竄	Ledger署名検証	Ledger秘密鍵の漏洩
Allowlistの改竄	Git履歴による監査	GitHubアカウント侵害

4.4 既存手法との比較

4.4.1 比較対象

本システムを以下の既存手法と比較し、その結果を表4.6に示す。

従来のPKI署名: X.509証明書[4]による電子署名
Blockcerts: ブロックチェーン基盤の証明書システム[5]
Open Badges 3.0: Verifiable Credentials（検証可能な資格情報）に基づくデジタルバッジ[3]

4.4.2 比較結果

表4.6: 既存手法との比較

評価項目	PKI署名	Blockcerts	Open Badges	Tri-Cert
オフライン検証	△ (失効確認に通信必要)	○	△	○
プライバシー保護	×	△	△	○
中央集権依存度	高	低	中	低
実装複雑度	低	高	中	中
本人確認機能	×	×	×	○
長期保存性	△	○	△	○

4.4.3 本システムの優位性

本システムの既存手法に対する優位性を以下に示す。

ゼロ知識証明によるプライバシー保護: 他の手法では実現困難な、暗号学的に保証されたプライバシー保護を提供する
WebAuthn統合による本人確認: 証明書の所有者が本人であることを同時に証明することが可能である
ハードウェアセキュリティ: LedgerおよびFIDO2認証器による多層的なセキュリティを実現する
GitHubベースの分散性: 特別なインフラストラクチャを必要とせず、標準的なWeb技術のみで検証が可能である

第5章考察

5.1 プライバシー保護の観点

5.1.1 最小限情報開示の原則

本システムは、プライバシー・バイ・デザインの原則に基づき設計されている。

公開されるデータ: ハッシュ値のみ（activation_hash, student_id_hash）
証明に含まれる情報: コミットメント値と証明（元データは含まれない）
検証時に必要な情報: PDF本体と証明データのみ

これにより、第1章で述べた「課題3: 過度な個人情報の開示」を解決している。従来、卒業の事実を確認するためだけに成績証明書の提出を求められるといった問題が存在したが、本システムではそのような過度な情報開示は発生しない。

5.1.2 リンカビリティ分析

プライバシー上の重要な考慮事項として、リンカビリティ（紐付け可能性）の分析を行った。

同一人物の証明書間: 同一のowner_secretを使用した場合、コミットメント値から紐付けが可能である
証明書と個人情報: activation_hashからアクティベーションコード、氏名、生年月日を逆算することは計算量的に困難である[7]
検証者による追跡: オフライン検証であるため、検証行為は発行機関に通知されない

5.1.3 GDPR・個人情報保護法への適合性

本システムの設計は、以下の点でGDPR（General Data Protection Regulation、EU一般データ保護規則）および日本の個人情報保護法に適合している。

データ最小化: 検証に必要な情報のみを開示する
目的制限: 証明書検証という明確な目的に限定して処理する
透明性: オープンソースによりアルゴリズムを公開している

5.2 運用面での考慮事項

5.2.1 鍵管理

本システムにおける鍵管理の責任分担を表5.1に示す。

表5.1: 鍵管理の責任分担

鍵の種類	管理責任者	保管場所
Ledger秘密鍵	学校管理者	Ledgerデバイス内
WebAuthn秘密鍵	学生本人	認証器デバイス内
Salt	学生本人	個人保管（安全な保存が必要）

5.2.2 障害時対応

シナリオ1: 学生がSaltを紛失した場合

Registrar Consoleで新規Saltを再発行
旧Saltの無効化は不要（新activation_hashで上書き）

シナリオ2: VKNFTの喪失

GitHubリポジトリからの復元が可能
Ledger署名の再生成は秘密鍵があれば可能

シナリオ3: 認証器の紛失

新しい認証器で再度WebAuthn登録が必要
過去に発行した証明書の有効性は維持される（公開鍵がPDFに埋め込まれているため）

5.2.3 長期運用

10年、20年といった長期運用を想定した場合、以下の対策が必要である。

暗号アルゴリズムの更新: SHA-3への早期移行により量子コンピュータへの耐性を確保する
回路バージョニング: circuit_idによる回路バージョン管理を行う
後方互換性: 旧バージョンの証明も検証可能なシステム設計を維持する

5.2.4 発行機関消滅時の対応

教育機関の統廃合など、発行機関が消滅した場合においても、本システムでは以下の理由により証明書の検証が可能である。

検証鍵の公開: VKはGitHubで公開されており、発行機関の存続に依存しない
Allowlistのアーカイブ: Git履歴として永続的に保存される
オフライン検証: 検証時に発行機関への問い合わせが不要である

将来的には、ブロックチェーン連携機能の実装により、発行機関が消滅した場合においても証明可能な仕組みをさらに強化することが考えられる。

5.3 応用可能性と社会的意義

5.3.1 他分野への応用

本技術は卒業証明書のみならず、表5.2に示すような多様な文書に適用可能である。

表5.2: 応用可能な分野

分野	対象文書	期待される効果
医療分野	診断書、ワクチン証明、資格証明	医療資格の即時確認、偽造防止
法務分野	公的証明書、契約書	改竄検知、電子契約の信頼性向上
教育分野	成績証明書、資格証明	学歴詐称の防止[2]
企業分野	決算報告書、監査報告書	企業情報の信頼性担保

特に医療分野では、検証に協力した医療事務従事者から高い評価を得ており、資格確認業務の効率化に寄与できる可能性が示唆された。

5.3.2 社会的意義

本研究は単なる技術革新にとどまらず、以下のような社会的意義を有する。

信頼の民主化: 特権的な第三者（認証局等）への依存からの脱却
業務効率化: 公的機関および民間企業双方のコスト削減
デジタル社会基盤: 次世代の信頼インフラの構築

本研究は、マイナンバー制度を超える次世代の本人確認技術の実現に向けた一歩であると考えられる。

5.4 本システムの限界と課題

5.4.1 技術的な限界

本システムには以下の技術的限界が存在する。

量子コンピュータへの脆弱性

本システムで採用しているGroth16プロトコルは、楕円曲線上の離散対数問題の困難性に基づいている[7]。量子コンピュータが実用化された場合、Shorのアルゴリズムによりこの前提が崩れる可能性がある。現時点では実用的な量子コンピュータは存在しないものの、10年から20年の長期運用を想定した場合、ポスト量子暗号（zk-STARKs等）への移行が必要となる。本システムでは、circuit_idによるバージョン管理を導入しており、将来的な暗号方式の更新に対応可能な設計としている。

証明生成の計算コスト

ZKP証明の生成には一定の計算リソースを要する。現在の実装では、デスクトップブラウザ上で証明生成に約2秒から3秒を要する。低性能なモバイルデバイスや旧式のブラウザでは、処理時間が長くなる可能性がある。ただし、検証処理は数十ミリ秒で完了するため、検証者の体験には影響を与えない。

認証器の互換性

WebAuthn認証は、Touch ID（macOS/iOS）、Windows Hello、Android生体認証等の主要なプラットフォームに対応しているが、旧式のデバイスや一部のブラウザでは動作しない場合がある。第4章の検証において、協力者Cから「認証器が使用できない環境ではProverが利用できないことを明記すべき」との指摘を受けた。認証器を持たないユーザーへの代替手段の提供は今後の課題である。

5.4.2 運用上の課題

運用面では、以下の課題が残されている。

導入コストと運用体制

発行機関がTri-CertFrameworkを導入するには、Registrar ConsoleおよびExecutive Consoleのセットアップ、Ledgerハードウェアウォレットの調達、GitHubリポジトリの管理体制の構築が必要となる。大規模な教育機関であれば既存のIT部門で対応可能であるが、小規模な機関にとっては負担となる可能性がある。将来的には、複数機関で共有可能なSaaS型の提供形態も検討すべきである。

ユーザビリティの課題

第4章の検証において、協力者Cから以下の改善要望が挙げられた。

名前入力時に姓と名の間に空白を入れないことの明記
「ファイルを選択」ボタンがタップ可能であることの視覚的明示
生年月日の入力UIの改善（年・月・日の一括入力）

これらは技術的には軽微な修正で対応可能であるが、非技術者ユーザーにとっての使いやすさを検証段階で十分に考慮できていなかった点は反省すべきである。

信頼性の可視化

同じく協力者Cから、「Proverで付与された証明ファイルがなぜ信頼に値するのか分かりにくい」「発行機関が学生をシステムに登録したという事実を強調すべき」との指摘があった。技術的には3層認証により高いセキュリティを実現しているものの、その安全性を非技術者に伝える「信頼の可視化」が不足している。検証結果画面において、発行機関の情報（機関名、連絡先等）をより明確に表示する等の改善が必要である。

5.4.3 検証から得られた反省点

本研究の検証プロセスを通じて、以下の反省点が明らかになった。

検証規模の限界

今回の検証は4名の協力者に限定された。医療事務従事者、会社員、セキュリティ専門家等、多様な背景を持つ協力者を選定したものの、統計的な有意性を示すには不十分なサンプル数であった。ユーザビリティ評価においては、一般的に5名程度で約85%の問題を発見できるとされるが[18]、本研究の目的である「多様なユーザー層における操作性の検証」を十分に達成するには、各ユーザー層（学生、企業人事担当者、発行機関職員等）から複数名ずつ、合計15名から20名程度の協力者を確保すべきであった。限られた時間と人脈の中での検証となったが、より多くの協力者からフィードバックを収集することで、UIの改善点やシステムの理解容易性について、より信頼性の高い知見が得られたと考えられる。

定量評価の不統一

第4章で示した5段階評価（理解しやすさ、操作しやすさ）は協力者B、Cの2名分のみであり、協力者Aからは定性的なフィードバックのみを収集した。評価項目を事前に統一し、全協力者から同一基準での定量データを収集すべきであった。これにより、改善点の優先順位付けがより客観的に行えたと考えられる。

発行機関視点の不足

協力者は主に「利用者（学生）」と「検証者（企業）」の視点からの評価であり、実際の発行機関（大学教務課職員等）からのフィードバックは得られなかった。Registrar Consoleの運用負担、一括登録機能の実用性、既存業務フローとの統合可能性等、発行機関視点での評価が不足している。

長期運用の検証不足

本研究では、システムの機能検証と短期的なユーザー評価を実施したが、数ヶ月から数年にわたる長期運用での課題（鍵の更新、バージョンアップ対応、データ移行等）は検証できていない。実際の教育機関での試験運用を通じた長期的な評価が今後の課題である。

これらの反省点は、今後の研究においてより体系的な評価手法を採用する際の教訓となる。

第6章結論と今後の課題

6.1 結論

本研究では、文書の真正性検証における3つの課題、すなわち真正性の担保が脆弱であること、確認プロセスが非効率であること、および過度な個人情報開示が生じることを解決するため、ゼロ知識証明とWebAuthn認証を組み合わせた文書真正性検証フレームワーク「Tri-CertFramework」を提案し、実装した。

本フレームワークは以下の特徴を有する。

3層認証による改竄耐性: 発行機関による登録、ZKP、WebAuthn署名という3層の認証により、偽造は暗号学的に実行不可能である
即時検証による効率化: PDF埋め込みにより、従来1〜2週間を要していた検証を数秒で完了可能である
ゼロ知識証明によるプライバシー保護: 必要最小限の情報のみを開示し、検証に不要な個人情報は一切漏洩しない
分散型アーキテクチャ: GitHubリポジトリを活用することで、中央サーバーを介さない検証を実現し、発行機関が消滅した場合においても検証が可能である

実装したシステムは、Registrar Console（Go/Wails）、Executive Console（Rust/Tauri）、Prover（Next.js）、Verifier（Next.js）の4つのコンポーネントで構成され、教育機関での実運用を想定した設計となっている。

検証の結果、医療事務従事者から「これは安心できる」「実務負担のみならず心理的負担も軽減できる」といった肯定的な評価を得た。

6.2 本研究の貢献

本研究の学術的・実践的貢献は以下の通りである。

学術的貢献

ZKPとWebAuthnの統合手法の提案: ゼロ知識証明とWebAuthn認証を組み合わせた文書真正性検証スキームを提案した
3層認証モデルの設計: 発行元の正当性、内容の完全性、所有者の本人性を同時に検証可能なアーキテクチャを提示した

実践的貢献

オープンソース実装の公開: 4つのコンポーネントすべてをオープンソースとして公開し、他機関での利用を可能とした
運用ガイドラインの策定: 鍵管理、障害対応、長期運用に関する実践的なガイドラインを策定した
実務者からのフィードバック取得: 医療事務従事者など、資格確認業務に従事する実務者からの評価を得た

6.3 今後の課題と展望

6.3.1 技術的課題

モバイル対応の強化: 現在のProver/Verifier UIはデスクトップブラウザを主な対象としているが、モバイルデバイスにおける操作性の向上が求められる
オフラインファースト設計: Service Workerを活用し、完全なオフライン環境での検証を実現する必要がある
量子耐性暗号への移行準備: Groth16は量子コンピュータに対して脆弱であるため、ポスト量子ZKP（例：STARK）への移行計画を策定する必要がある
大規模運用への対応: 1000人規模の一括処理など、大規模教育機関および医療機関での運用を想定した最適化が必要である

6.3.2 運用面での課題

ユーザビリティの向上: 技術的な専門知識を有さない利用者でも操作可能なUIへの改善が求められる
発行機関間の相互運用性: 複数の機関がTri-CertFrameworkを採用した場合における連携方法の標準化が必要である
法制度への対応: 電子署名法をはじめとする各国の法制度への適合性確認および対応が求められる

6.3.3 展望

本フレームワークは、卒業証明書を起点として、以下の文書などへの展開を想定している。

医療資格証明書（看護師、医師等）
各種国家資格証明書
企業間契約書
行政機関が発行する公的証明書

ゼロ知識証明技術の発展とWebAuthnの普及に伴い、本フレームワークのような分散型かつプライバシーを重視したアプローチが、デジタル社会における信頼基盤として普及することが期待される。

謝辞

本研究は、神戸情報大学院大学情報技術研究科情報システム専攻において実施しました。

指導教員の土田雅之教授には、研究の方向性から実装の詳細に至るまで、多大なご指導をいただきました。深く感謝申し上げます。

また、同期の長須雛子さんには、ゼミナールでの議論を通じて貴重なご意見をいただき、本システムの検証にもご協力いただきました。

在学中にご指導いただいた教員の方々にも感謝申し上げます。技術者倫理をご担当いただいた石野かおり助教、情報ネットワーク基礎論の嶋久登特任教授、Linux基礎・プログラミング基礎論C・プログラミング特論Cの大寺亮教授、プログラミング基礎論Python・Webアプリとデータベースの孫一准教授、Linux応用・ソフトウェア開発特論の奥田亮輔教授、情報セキュリティの宮坂虹槻助教、プログラミング特論Javaの小藪康准教授、要求分析と設計の平石輝彦教授、探究実践演習の炭谷俊樹学長には、本研究の基盤となる知識と技術を学ばせていただきました。

そのほか、事務局のスタッフ様には在学中の様々な手続きでお世話になりました。

皆様のご支援とご協力により、本研究を無事に完了することができました。心より感謝申し上げます。

本システムの実装にあたり、オープンソースコミュニティで公開されているsnarkjs、Circom、Wails、Tauriなどの優れたライブラリを活用させていただきました。これらのプロジェクトの開発者の皆様に感謝いたします。

最後に、研究活動を支えてくれた家族に感謝します。

参考文献

[1] 朝日新聞, “経歴詐称や退職代行見抜くリファレンスチェック採用時の利用急増”, 2025. https://www.asahi.com/articles/ASTBS3SWXTBSULLI003M.html （最終アクセス: 2026年1月9日）

[2] 集英社オンライン編集部ニュース班, “〈伊東市長から小池都知事に飛び火〉「学歴の保証の見返りに…そう見られても仕方ない」カイロ大卒業疑惑が再燃、追及してきた都議が話す”エジプトとの合意書”への違和感”, 2025. https://news.yahoo.co.jp/articles/22f319227a500023bd55d09e388f6e524f9213e2 （最終アクセス: 2026年1月9日）

[3] 一般財団法人オープンバッジ・ネットワーク, “一般財団法人オープンバッジ・ネットワーク”, 2025. https://www.openbadge.or.jp/ （最終アクセス: 2026年1月9日）

[4] D. Cooper et al., “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, 2008. https://datatracker.ietf.org/doc/html/rfc5280 （最終アクセス: 2026年1月9日）

[5] MIT Media Lab, “Blockcerts: The Open Standard for Blockchain Credentials,” 2016. https://www.blockcerts.org/ （最終アクセス: 2026年1月9日）

[6] European Commission, “European Digital Credentials for Learning,” 2023. https://europass.europa.eu/en/european-digital-credentials-learning （最終アクセス: 2026年1月9日）

[7] S. Goldwasser, S. Micali, and C. Rackoff, “The knowledge complexity of interactive proof systems,” SIAM Journal on Computing, vol. 18, no. 1, pp. 186-208, 1989. https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf （最終アクセス: 2026年1月9日）

[8] J. Groth, “On the Size of Pairing-Based Non-interactive Arguments,” in Advances in Cryptology – EUROCRYPT 2016, pp. 305-326, 2016. https://eprint.iacr.org/2016/260.pdf （最終アクセス: 2026年1月9日）

[9] iden3, “SnarkJS: zkSNARK implementation in JavaScript & WASM,” 2023. https://github.com/iden3/snarkjs （最終アクセス: 2026年1月9日）

[10] iden3, “Circom: zkSNARK circuit compiler,” 2023. https://github.com/iden3/circom （最終アクセス: 2026年1月9日）

[11] L. Grassi et al., “Poseidon: A New Hash Function for Zero-Knowledge Proof Systems,” in USENIX Security 2021, pp. 519-535, 2021. https://www.usenix.org/system/files/sec21-grassi.pdf （最終アクセス: 2026年1月9日）

[12] FIDO Alliance, “FIDO2: Web Authentication (WebAuthn),” 2019. https://fidoalliance.org/fido2/ （最終アクセス: 2026年1月9日）

[13] O. Yilmaz et al., “A Systematic Literature Review on Blockchain-Based Systems for Academic Certificate Verification,” IEEE Access, vol. 11, pp. 64679-64696, 2023. https://ieeexplore.ieee.org/document/10163764/ （最終アクセス: 2026年1月9日）

[14] Sovrin Foundation, “Sovrin: A Protocol and Token for Self-Sovereign Identity and Decentralized Trust,” Sovrin Foundation Whitepaper, 2018. https://sovrin.org/library/ （最終アクセス: 2026年1月9日）

[15] M. Rosenberg et al., “ZK-Creds: Flexible Anonymous Credentials from zkSNARKs and Existing Identity Infrastructure,” in IEEE Symposium on Security and Privacy (SP), 2023, pp. 1-18. https://eprint.iacr.org/2022/878.pdf （最終アクセス: 2026年1月9日）

[16] W3C, “Decentralized Identifiers (DIDs) v1.0,” W3C Recommendation, 2022. https://www.w3.org/TR/did-core/ （最終アクセス: 2026年1月9日）

[17] W3C, “Verifiable Credentials Data Model v1.1,” W3C Recommendation, 2022. https://www.w3.org/TR/vc-data-model/ （最終アクセス: 2026年1月9日）

[18] J. Nielsen, “Why You Only Need to Test with 5 Users,” Nielsen Norman Group, 2000. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ （最終アクセス: 2026年1月9日）

付録

A. 回路ソースコード（抜粋）

Circomで記述されたコミットメント回路の概要を以下に示す。

pragma circom 2.0.0;

include "poseidon.circom";

template Commitment() {
    signal input owner_secret;
    signal input pdf_sha3_512;
    signal input graduation_year;
    signal output commit;

    component hasher = Poseidon(3);
    hasher.inputs[0] <== owner_secret;
    hasher.inputs[1] <== pdf_sha3_512;
    hasher.inputs[2] <== graduation_year;

    commit <== hasher.out;
}

component main {public [pdf_sha3_512, graduation_year]} = Commitment();

B. プロジェクト構成

Tri-CertFramework/
├── prover/                    # 証明生成WebUI (Next.js)
│   ├── src/app/
│   │   ├── components/
│   │   │   ├── ProofGenerator.tsx
│   │   │   └── WebAuthnSetup.tsx
│   │   └── api/vknft/
│   └── package.json
│
├── verifier-ui/               # 検証WebUI (Next.js)
│   ├── src/app/
│   │   ├── components/
│   │   │   └── VerificationResults.tsx
│   │   └── utils/
│   │       ├── webauthn-verifier.ts
│   │       └── registration-checker.ts
│   └── package.json
│
├── registrar-console/         # 登録者コンソール (Go/Wails)
│   ├── internal/registrar/
│   │   └── service.go
│   ├── app.go
│   └── main.go
│
├── executive-console/         # 管理者コンソール (Rust/Tauri)
│   ├── src/
│   │   ├── components/
│   │   │   └── VKGenerator.tsx
│   │   └── utils/
│   │       ├── vknft-bundle.ts
│   │       └── ledger-signer.ts
│   └── src-tauri/
│
├── VKNFT/                     # 検証鍵ストレージ
│   └── {year}/
│       ├── manifest.json
│       └── files/
│
└── registrations/             # 登録データ
    ├── commit-allowlist.json
    └── index.json

C. 検証協力者へのインタビュー記録（抜粋）

被験者: 50代女性、医療事務従事者

Q: システムを使った感想は？

A: できた！これは安心できるね。本人からこのPDFを厚労省の専用ページへアップロードすることで届出が可能になれば、こういった煩雑な事務処理が圧縮できる。

Q: 現在の資格確認業務で困っていることは？

A: 現在、資格確認はExcelシートでの代行手続きが可能になったばかりで、エラーの多発などによって現場は混乱している。本システムが資格確認の標準になれば資格確認に対する実務負担だけでなく心理的負担も軽減できる。

Q: 懸念点は？

A: 巨大病院など1000人規模の届出には疑問が残る。

Q: 一括発行機能があればどうか？

A: それでも1000人分手書きより事務方は喜ぶね必ず。証明ファイル付きPDFは初めて現在在職してる看護師を全員登録する時に大変かもだけど、一度作れば期限付きの資格ではないので、新入職のひとに作ればいいだけになる。

本論文のソースコードはGitHubにて公開されています。

128ビットの計算量的安全性とは、攻撃者が暗号を解読するために2^128（約3.4×10^38）回の計算が必要となる難易度を意味する。現在の最高速スーパーコンピュータでも、この回数の計算には宇宙の年齢を超える時間がかかり、実質的に解読不可能とされる。 ↩

修士論文 v2.41

デジタル文書の真正性検証: ３層認証アーキテクチャの設計と実装

内容梗概

目次

第1章 序論

1.1 研究の背景

1.2 真正性検証とは

1.3 現在の真正性検証が抱える課題

1.3.1 課題1： 真正性の担保が脆弱

1.3.2 課題2： 確認プロセスが非効率

1.3.3 課題3： 過度な個人情報の開示

1.4 本研究の目的と対象領域

本研究の位置づけと範囲

1.5 本研究の特徴

1.6 本論文の構成

第2章 先行研究と技術基盤

2.0 章概要

なぜこれらの技術を選んだのか

2.1 デジタル証明書の現状

2.1.1 従来のデジタル証明書

2.1.2 既存手法の限界

2.2 ゼロ知識証明（ZKP）

2.2.1 ZKPの概要

コミットメントスキーム

2.2.2 zk-SNARKsとGroth16

2.2.3 Poseidonハッシュ関数

なぜPoseidonが必要なのか

2.3 WebAuthn と FIDO2

2.3.1 FIDO2規格の概要

2.3.2 本研究での活用

2.4 関連研究

2.4.1 学術証明書へのZKP適用

2.4.2 Self-Sovereign Identity（SSI）

SSIの基本原則

主要なSSI実装

本研究とSSIの関係

2.5 本研究のポジショニング

2.5.1 既存手法との比較

デジタル証明書システムの比較

技術的特徴の比較

第3章 システム設計と実装

3.1 設計思想とアーキテクチャ

3.1.1 設計原則

既存手法の限界に対する本研究のアプローチ

3つの課題に対する解決策

本研究の独自性（新規性）

設計原則

3.1.2 システムアーキテクチャ

3.1.3 検証プロセス

1. 登録フェーズ（Registrar Console）

2. VK準備フェーズ（Executive Console）

3. 証明生成フェーズ（Prover）

4. 検証フェーズ（Verifier UI）

3.1.4 3層認証の詳細

第1層: 発行機関による登録

第2層: ゼロ知識証明（ZKP）

第3層: WebAuthn署名

3層の連携

3.2 Registrar Console

3.2.1 概要

画面構成

技術スタック

学生登録機能

登録フロー

学生削除機能

3.2.3 ハッシュ計算アルゴリズム

3.2.4 Allowlistの構造

3.2.5 一括登録機能

CSV一括登録画面

処理フロー

3.3 Executive Console

3.3.1 概要

画面構成

技術スタック

3.3.2 VK生成プロセス

VK生成画面

バンドル生成完了画面

Ledger署名プロセス

署名ログ

3.3.3 VKNFTバンドル構造

第1章序論

1.3.1 課題1：真正性の担保が脆弱

1.3.2 課題2：確認プロセスが非効率

1.3.3 課題3：過度な個人情報の開示

第2章先行研究と技術基盤

第3章システム設計と実装

第4章検証

第5章考察

第6章結論と今後の課題