構想から5年。JNSAで保証レベルTF（タスクフォース）を立ち上げてから4年かかりましたが、2026年4月8日にJNSAサイトにて「署名保証ガイドライン第1.00版（JNSA SAG-1:2026）」を公開しました！
私はこの保証レベルTFのリーダーおよびエディタとしてこのガイドラインの執筆に携わって来ました。とは言えこれはJNSA電子署名WG（ワーキンググループ）のメンバーとの4年にわたる議論と整理の結果です。私一人では到底ここまで到達することはできませんでした。また米国国立標準技術研究所（NIST）の「NIST SP 800-63: Digital Identity Guidelines（デジタルアイデンティティガイドライン）」が無ければそもそもこのガイドラインを作成することもありませんでした。NIST SP 800-63は本ガイドラインの考え方のベースであり参照先です。NIST SP 800-63は現在Revision 4となっていますが、実はRevision 2の時の名称は「NIST SP 800-63-2: Electronic Authentication Guideline」でした。つまり「電子認証ガイドライン」または「認証保証ガイドライン」だったわけです。
電子署名も昔と違い当人認証技術を利用したオンラインサービス化して来ています。現在の電子署名は、「身元確認」＋「署名プロセス（当人認証）」＋「署名データ（第三者検証）」の3ステップに加えて「運用（ガンバナンス）」の4部構成で構成されており、オフラインであるローカル署名方式においても同様の整理が可能です。こう書くとNIST SP 800-63の整理では電子認証（電子署名との対比から今後こう書きます）は、「身元確認」＋「認証プロセス（当人認証）」の2ステップに加えて「フェデレーション」の3部構成になっています。こう書くと最初の2ステップはほぼ同じと言うことがわかります。
| part | JNSA SAG-1:2026 [SxAL] | NIST SP 800-63 [xAL] |
|---|---|---|
| 1 | 身元確認 [SIAL] | 身元確認 [IAL] |
| 2 | 署名プロセス（当人認証）[SPAL] | 当人認証 [AAL] |
| 3 | 署名データ（検証）[SDAL] | フェデレーション [FAL] |
| 4 | サービス運用（ガバナンス）[SOAL] | --- |
この違いがどこから来るのかと言えば電子署名と電子認証に求められる要件が異なるからです。電子認証は「現在端末の前に座っている利用者の本人性の保証（リアルタイムの本人性保証）」なのに対し、電子署名は「署名データから過去に署名者/利用者の意思の保証（過去の本人性保証）」となっています。それぞれで何ができるのかを整理すると以下となります。
| 認証機能 | 何が確認できるか |
|---|---|
| 身元確認 | アイデンティティの確認 |
| 当人認証 | 端末の前の自然人が身元確認済みの当人であることの確認 |
| セッション | 当人による操作の継続の確認 |
| 署名機能 | 何が確認できるか |
|---|---|
| 身元確認 | アイデンティティの確認 |
| 署名プロセス | 端末の前の自然人が身元確認済みの当人であり署名者であることの確認 |
| 署名データ | 検証による身元確認済みの自然人によるデータ内容に関する保証の確認 |
最初の2つはほぼ同じ内容ですが、3つ目が異なります。逆に言えば電子認証でも後からデータ内容に関する保証の確認（例：操作ログ等による確認）が可能であれば、電子署名と言えます。
署名保証ガイドラインの4つ目の保証レベルであるサービス運用保証レベル（SOAL）は該当する概念はNIST SP 800-63には直接はありません。これはレガシーな電子署名であり、ローカル署名の認証局においてはCP/CPS（証明書ポリシー/認証局運用規定）に相当するものです。ガバナンスと言う意味および利用者からの信頼を得るための宣言と言う意味ではサービス運用保証レベル（SOAL）はとても重要であり、本来は電子認証でも必要な保証レベルと考えています。フェデレーションは少しガバナンス的な意味は持つかもしれませんね。
閑話休題
さて長々と理解が難しい話を書いて来ましたが、私のQiitaでは本記事をパート⓪（ゼロ）として解説をして行きたいと考えています。以下の主な項目に分けてパート①～⑤に分けて解説して行きましょう。
①電子署名の定義（1.2.章）
・本人の身元（Identity）：署名者が誰であるか識別できること
・本人の意思（Approval）：署名が署名者本人に帰属すること
・非改ざん（Tamper-evidence）：署名後に文書が変更されていないこと
②電子署名方式の整理
2.2.1.章 ローカル署名方式：（既存の署名鍵を保有したPKI署名）
2.2.2.章 リモート署名方式：（署名鍵のリモート保管によるPKI署名）
2.2.3.章 認証記録署名方式：（ログインによる署名）
2.2.4.章 事業者署名方式：（立会人型署名等の事業者による署名保証）
③電子署名の保証レベル
2.3.1.章 署名者身元保証（SIAL）：署名者の身元確認による本人性の保証
2.3.2.章 署名プロセス保証（SPAL）：署名時の当人性と署名意思確認の保証
2.3.3.章 署名データ保証（SDAL）：署名データ自体の信頼性に関する保証
2.3.4.章 サービス運用保証（SOAL）：運用ポリシー遵守に関する信頼性の保証
④電子署名リスク管理（ESRM）
3.2.章 ステップ0：定義と初期保証レベルの仮置き（サービスの定義と保証レベル）
3.3.章 ステップ1：リスクアセスメントの実施（署名リスクの特定/分析/評価）
3.4.章 ステップ2：基本策と最終保証レベルの決定（リスク対応と調整による決定）
3.5.章 ステップ3：文書化（署名サービスの承認規定と運用規定の作成と公開）
3.6.章 ステップ4：署名サービス運用と再評価（運用開始後と一定期間後の再評価）
⑤付属書（電子署名関連情報）
A.署名保証レベル適合宣言書（規定）
B.承認目的署名と発行元保証署名（参考情報）
C.電子委任（参考情報）
D.トラスト設計（参考情報）
以上の内容は出来るだけID系の方でも理解できる言葉を選んで書いたつもりです。もう1つの目的が現在ID系とPKI系に分かれている技術の橋渡しをこの「署名保証ガイドライン」とおこなえればと願いつつ書きました。なお別途JNSA電子署名WGにて勉強会も計画しています。せっかく作ったので宣伝して行こうと言う一環になります。掲載は不定期になりますが出来れば週1回程度の頻度で更新して行ければと考えています。ご興味があればID系の方も是非ご覧ください！
署名保証ガイドライン解説シリーズ
| 章 | タイトル | 概要 |
|---|---|---|
| -- | リリースしました！ | 署名保証ガイドライン第1.00版の概要 |
| 1 | 電子署名（と電子認証）の要件 | 電子署名（電子認証）とは？ |
| 2.1 | 署名サービスの基本モデル | 電子署名の基本モデルの定義 |
| 2.2 | 各種署名方式の整理 | ローカル署名と認証技術を使った様々な署名 |
| 2.3 | 電子署名の保証レベル：SxAL | SIAL/SPAL/SDAL/SOALの解説 |
| 3 | 電子署名リスク管理：ESRM | リスク管理と保証レベルの選択 |
| A | 適合宣言と情報公開 | 信頼のための宣言と情報公開 |
| B | 承認目的署名と発行元保証署名 | eシール的署名とは |
| C | 電子委任の整理 | 委任状モデルと問合せモデル |
| D | トラスト設計 | 署名と認証による信頼設計 |