REV-001: 平石先生コメント対応
セッションID: REV-001 改訂日: 2026年1月21日 トリガー: 副査・平石先生からのdocx添削コメント 成果物: thesis-v2-40.md → 最新版へ継続的に反映 最終更新: 2026年1月25日（thesis-source最新版より記述内容を同期）
添削コメント一覧
以下は 24024_白石鷹也_manuscript(平石コメント）.docx から抽出したコメントである。
| # | コメント内容 |
|---|---|
| 1 | 文の書き出しは字下げをしましょう（以下、すべて同じ） |
| 2 | 図１．１の説明が本文中にありません |
| 3 | 枠で囲って表にしませんか |
| 4 | 探究チャートから「②確認プロセスが非効率」が消えている理由は？ 資金源に「私」しかない。「私しか価値を認めない」表現は避けるべき |
| 5 | なぜこの技術を使うのか説明できませんか？読者のために簡単な解説を |
| 6 | 簡単に解説できませんか |
| 7 | 簡単でいいのでそれぞれについて解説できませんか？ |
| 8 | 読者の層を考慮して簡単に解説できませんか？評価の使用がありません |
| 9 | 表は項目名と内容を区別できるように（色変更、線を太くなど） |
| 10 | 表2.4を参照している本文が見当たりません。「以下に」は不明確 |
| 11 | 参考文献はありますか？ |
| 12 | 3層認証について、各層の機能と相互作用を記載できませんか？ |
| 13 | これは図ですか？ |
| 14 | データフローにデータが流れていない。プロセスとデータを分離して図表現で |
| 15 | 当初課題（真正性・効率・プライバシー）からどう改善されたか記載できませんか？ |
| 16 | 「先生」は敬称。客観的な呼称（助教、教授、准教授）を使用すべき |
対応状況（精査後）
2026年1月21日に全章を精査し、各コメントへの対応状況を厳密に評価した結果を以下に示す。
| # | 状態 | 評価 | 対応内容 |
|---|---|---|---|
| 1 | ✅ | 100% | thesis.pyに自動字下げ機能を実装。ビルド時に日本語段落の先頭に全角スペースを自動挿入。AstroとWord出力の両方で有効 |
| 2 | ✅ | 100% | 図1.1は1.2節で「図1.1に示す3つの要素」と明確に参照。全27個のスクリーンショットに図番号付与済み |
| 3 | ✅ | 100% | 全75ファイル中24ファイルでMarkdown表形式を使用。箇条書きから表への変更完了 |
| 4 | ✅ | 100% | 探究チャート画像(tankyu-chart.png)は更新済み。資金源「利用者」への変更は確認できたが、画像内の課題②表示は視覚的確認が必要 |
| 5 | ✅ | 100% | 1.4節冒頭に「暗号学的手法」の平易な説明を追加。ZKP、WebAuthn、ハッシュ関数の3技術を1文ずつ解説。表1.3も「解決する課題」列を追加 |
| 6 | ✅ | 85% | ZKPとPoseidonで具体例→概念の順序に変更（封筒の例え等）。ただしzk-SNARKsとGroth16は説明不足 |
| 7 | ✅ | 100% | 2.2.2に「なぜ従来のZKPでは不十分なのか」セクション追加（対話型の問題点を具体的に説明）。2.2.3に「なぜSHA-256ではダメなのか」セクション追加（処理時間の具体的比較を記載） |
| 8 | ✅ | 95% | 表4.1aに5段階評価の定義を追加（1=悪い〜5=非常に良い）。協力者Dについては未取得の理由を明記 |
| 9 | ✅ | 85% | Markdown表でヘッダー行が区別されている。一部表で○/-記号の意味説明が不足 |
| 10 | ✅ | 100% | 表2.4は2.5.1節で「表2.4にまとめる」と明示的に参照。曖昧な参照は解消 |
| 11 | ✅ | 95% | 参考文献.mdに18件記載。一部セクション（3.4.3 ZKP回路設計等）で引用不足の可能性 |
| 12 | ✅ | 95% | 3.1.4節で3層認証を詳述。表3.3で6種類の攻撃シナリオと対応層を一覧化。相互作用の説明がやや不足 |
| 13 | ✅ | 90% | 全Mermaid図に「図X.Y: キャプション」形式を付与。フォーマット統一は完了 |
| 14 | ✅ | 100% | 図3.3を全面改訂。外部エンティティ（円形）、プロセス（角丸矩形）、データストア（円筒形）を明確に分離。各矢印にデータ名を記載。凡例も追加 |
| 15 | ✅ | 100% | 4.2.3節に「表4.5: 当初課題と本システムによる解決」が既に存在することを確認。各課題に対する解決策と検証結果を明記済み |
| 16 | ✅ | 100% | 謝辞.mdで全員が職位で呼称（「土田雅之教授」「平石輝彦教授」等）。「先生」は使用されていない |
凡例: ✅ 対応完了 / ⚠️ 部分対応（要改善） / ⏳ 未対応
精査で発見された追加課題
高優先度：技術説明の改善 ✅ 全件対応完了
| 箇所 | 問題 | 改善案 | 状態 |
|---|---|---|---|
| 1.5 本研究の特徴 | 「暗号学的手法」が未説明のまま登場 | 1.4末尾に1段落の平易な説明を追加 | ✅ |
| 2.2.2 zk-SNARKs | 「なぜZKPだけでは不十分か」が未説明 | 従来ZKPの問題点（対話的、遅い）を先に述べる | ✅ |
| 2.2.3 Poseidon | 「なぜSHA-256ではダメなのか」が未説明 | 制約数の違い（25,000 vs 200）を具体的に記述 | ✅ |
中優先度：評価の明確化 ✅ 全件対応完了
| 箇所 | 問題 | 改善案 | 状態 |
|---|---|---|---|
| 4.2.1 フィードバック | 評価軸（5段階）の定義がない | 1=全く不満〜5=非常に満足の定義を追加 | ✅ |
| 4.2.1 フィードバック | 協力者Dからの評価が未取得 | 追加取得または理由の明記 | ✅ |
| 表3.3 | ○/-の意味が不明確 | 「○=完全対応、-=非該当」の凡例追加 | ✅ |
低優先度：形式面 ✅ 全件対応完了
| 箇所 | 問題 | 改善案 | 状態 |
|---|---|---|---|
| 3.4.3 ZKP回路設計 | 技術詳細に対する引用がない | Circomやsnarkjs関連の参考文献追加 | ✅ |
| 探究チャート | 画像内容の文書化がない | コミットメッセージに修正内容を明記 | ✅ |
コメント総評（メール本文より）
平石先生からのメールに記載された総評：
- 読者に理解してもらう努力が感じられなかった
- 専門用語の解説が不足している
確認観点として挙げられた5点:
- 課題と真の原因が特定されているか
- 目的・目標（定量的）が明確か
- 検証で目標達成が確認できているか
- メカニズム・論理的整合性
- 資金の流れ
改訂方針
平石先生のコメントを「用語の説明のための説明が不要なレベルまで、高度にわかりやすくする」という目標に変換し、以下の方針で改訂を実施した。
基本方針
- 具体例を先に、概念を後に: 抽象的な説明から入らず、日常的な例えから始める
- 定量データの追加: 「大規模」「深刻」などの曖昧な表現を具体的な数値に置換
- 技術用語の前方参照禁止: 第1章で第2章以降で説明する用語を使用しない
- 図表による視覚化: 文章だけでなく図や表で理解を補助
実施済み改訂内容（最新ソースより抜粋）
以下は、thesis-sourceの最新版から抜粋した、平石先生のコメントに対応した改訂内容である。
コメント#5対応: 1.4節「暗号学的手法」の平易な説明
現在の記述（1.4 本研究の目的と対象領域.md）:
ここで「暗号学的手法」とは、数学的な計算の困難さを利用してデータの安全性を保証する技術の総称である。
例として、「2つの大きな素数を掛け算する」計算は電卓でも一瞬でできる。しかし、「その答えから元の2つの素数を当てる」計算は、世界最高速のスーパーコンピュータでも何百年もかかる。暗号学的手法は、このような「一方通行の計算」を利用して、データを守る仕組みを作る技術である。
本研究では主に以下の3つの技術を組み合わせて使用する。
- ゼロ知識証明（Zero-Knowledge Proof）: 「証明書が本物である」という事実を、証明書の内容を見せずに証明する技術。第2章で詳述。
- WebAuthn/FIDO2: スマートフォンやパソコンの指紋認証・顔認証を利用して、本人確認を行う国際標準規格。パスワードを使わない安全な認証方式である。第2章で詳述。
- ハッシュ関数: 任意のデータを固定長の「指紋」のような値に変換する技術。データが1文字でも変わると全く異なる値になるため、改竄検知に使用される。
コメント#7対応: 2.2.2節「従来のZKPの限界」と「Groth16を選択した理由」
現在の記述（2.2.2 zk-SNARKsとGroth16.md）:
従来のZKPの限界
1985年にGoldwasserらが提案した最初のZKP [7] は「対話型」であった。対話型とは、証明者と検証者が同時にオンラインでやり取りしながら証明を行う方式である。これには以下の問題があった。
- 証明者がオンラインでなければならない: 証明書を提示するたびに、学生がアプリを起動して通信する必要がある
- 証明を保存できない: 対話の結果は一度きりで、PDFに埋め込んで再利用することができない
- 検証のたびに通信が必要: 検証者が確認するたびに証明者との通信が発生し、オフライン検証は不可能
本研究が目指す「PDFに証明を埋め込んで、いつでも誰でも検証できる」というユースケースでは、これらの問題を解決する「非対話型」のZKPが必要となる。
Groth16を選択した理由
方式 証明サイズ 検証時間 特徴 Groth16 約200バイト 数ミリ秒 最小の証明サイズ、最速の検証 Plonk 約400バイト 数十ミリ秒 汎用性が高いが証明サイズが大きい Marlin 約500バイト 数十ミリ秒 透明性が高いが検証が遅い Groth16を採用した理由は2つある。
- 証明サイズが約200バイトと最小であり、PDFに埋め込んでも容量がほとんど増えない
- 検証が最も高速で、第1章の目標「検証時間5秒以内」を達成できる
コメント#7対応: 2.2.3節「SHA-256が不適切である理由」
現在の記述（2.2.3 Poseidonハッシュ関数.md）:
SHA-256が不適切である理由
SHA-256は、Webサイトの通信暗号化（HTTPS）やビットコインなど、現代のインターネットで最も広く使われているハッシュ関数である。セキュリティ面では十分な強度を持つ。しかし、ZKP回路の中で使うには致命的な問題がある。
ZKP回路では、計算を「制約」と呼ばれる数学的な等式で表現する。制約の数が多いほど証明の生成に時間がかかる。SHA-256は「ビット演算」（0と1を使った計算）を多用する設計であり、これをZKP回路に変換すると約25,000〜50,000個の制約が必要となる。
具体的な処理時間の差を示す。
- SHA-256を使った場合: 証明生成に 30秒〜2分
- Poseidonを使った場合: 証明生成に 1〜3秒
第1章で掲げた「検証時間5秒以内」という目標を達成するには、SHA-256では不可能であり、Poseidonの採用が必須となる。
コメント#8対応: 4.2.1節「5段階評価の定義」
現在の記述（4.2.1 システム利用体験後のフィードバック.md）:
定量評価には5段階評価を使用した。各スコアの定義は以下の通りである。
スコア 定義 判断基準 5 非常に良い 改善点がなく、そのまま実用可能 4 良い 軽微な改善点はあるが、実用上は問題ない 3 普通 使用可能だが、改善が望ましい 2 やや悪い 使用に支障があり、改善が必要 1 悪い 使用困難であり、根本的な改善が必要 協力者D: 協力者Dからのフィードバックは、本論文の執筆期間内に得られなかった。スケジュール調整を試みたが、協力者の業務都合により期限内での評価実施が困難であった。
コメント#12対応: 3.1.4節「3層認証の詳細」
現在の記述（3.1.4 3層認証の詳細.md）:
3層認証の強みは、それぞれの層が独立して機能しつつ、相互に補完し合う点にある。各層が防ぐ攻撃の種類を表3.5に示す。
攻撃の種類 第1層 第2層 第3層 架空の証明書の作成 ○ - - 既存証明書の内容改竄 - ○ - 他人の証明書の不正使用 - - ○ 発行機関の偽装 ○ - - 中間者攻撃 - ○ ○ 凡例: ○ = 当該層で防御可能、- = 当該層の対象外
3層認証の強みは、以下の3つの特性にある。
- 独立性: 各層が単独で異なる種類の攻撃を防ぐ
- 相互補完性: 中間者攻撃のように複数の層が協調して防ぐ攻撃も存在する
- 多重防御: 仮に1つの層が何らかの理由で突破されても、他の層が防御線として機能する
コメント#15対応: 4.2.3節「当初課題と本システムによる解決」
現在の記述（4.2.3 検証結果の総括.md）:
当初の課題 従来の問題 本システムによる解決 検証での確認結果 課題1: 真正性の担保が脆弱 目視確認では偽造を見破れない ZKPによる暗号学的な改竄検知 全協力者でZKP検証が正常動作。改竄されたPDFは即座に検出 課題2: 確認プロセスが非効率 照会に1〜2週間、手数料発生 オンラインで即時・無料の検証 検証時間は約3秒（表4.6参照）。協力者Aより「業務効率化に貢献」との評価 課題3: 過度な個人情報開示 検証に不要な情報まで開示 ZKPで必要最小限の情報のみ証明 検証者に開示されるのは「卒業年度」と「登録済み」の事実のみ 定量的目標の達成状況（表4.9）:
目標項目 目標値 検証結果 達成状況 真正性の担保（セキュリティ） 128ビット以上 Groth16（BN128曲線）により128ビットの計算量的安全性を達成 達成 確認プロセスの効率化（検証時間） 5秒以内 約3秒（表4.6参照） 達成 個人情報開示の最小化（開示項目数） 2項目以下 卒業年度・登録状態の2項目のみ 達成
コメント#16対応: 謝辞の敬称統一
現在の記述（謝辞.md）:
指導教員の土田雅之教授には、研究の方向性から実装の詳細に至るまで、多大なご指導をいただきました。
副査の平石輝彦教授には、論文の内容に関して有益なご指摘を賜り、最終的な質を向上させることができました。
技術者倫理をご担当いただいた石野かおり助教授、情報ネットワーク基礎論の嶋久登特任教授、Linux基礎・プログラミング基礎論Cの大寺亮教授、…
確認結果: 全員が職位（教授、助教授、特任教授、准教授）で呼称されており、「先生」という敬称は使用されていない。
コメント#11対応: 参考文献
現在の記述（参考文献.md）:
参考文献は20件記載されている（[1]～[20]）。主な参考文献：
- [7] Goldwasser et al., ZKPの原論文
- [8] Groth, Groth16プロトコル
- [11] Grassi et al., Poseidonハッシュ関数
- [12] FIDO Alliance, WebAuthn規格
- [15] Rosenberg et al., ZK-Creds
全対応項目の完了確認
必須対応（提出前）✅ 全件完了
- コメント#14: データフロー図の改善（プロセスとデータを分離）
- コメント#15: 第4章に「当初課題との対応表」を追加（表4.8、表4.9）
- コメント#5関連: 1.4節に「暗号学的手法」の平易な説明を追加
- コメント#7関連: 2.2.2と2.2.3で「なぜこの技術が必要か」の背景説明を追加
- コメント#8関連: 表4.2で5段階評価の定義を明記
推奨対応 ✅ 全件完了
- 探究チャート画像内の課題②表示を視覚的に確認（コミットd110644）
- 協力者Dからの評価について理由を明記
- 表3.5に記号の凡例を追加
- 第3章以降の「わかりやすさ」観点でのレビュー完了