リモート署名とは。実装要件への翻訳

Q: リモート署名サービスを選ぶとき何を確認すべきですか？

まずそのサービスが本当にリモート署名か立会人型かを証明書の名義で確認します。そのうえでJT2Aガイドラインのどのレベル相当か、SAD（署名認可）の方式は何か、認証セッションの有効期間を変更できるか、監査ログに何がどれだけ残るか、長期署名（LTV）に対応するか、料金体系は件数課金か利用者数課金かを確認してください。

Q: リモート署名を使えば長期保存の対策は不要ですか？

不要にはなりません。リモート署名はどう署名するかの方式であり、署名済み文書を7年・10年と保存して検証可能に保つには長期署名（PAdES/LTV）の設計が別途必要です。証明書の有効期限や暗号の陳腐化に備えて検証材料を文書に埋め込み、タイムスタンプで時刻を固定する仕組みを、方式選定と同じタイミングで検討してください。

電子署名の方式選定をしていると、「リモート署名」という選択肢が候補に挙がることがあります。ところがこの言葉は、クラウド型の電子契約サービス全般を指すものと誤解されやすく、社内の議論が噛み合わないまま進んでしまうことがあります。リモート署名は、利用者ごとの署名鍵を事業者のサーバー（HSM）に置いて預かる方式であり、事業者が自社の鍵で署名する立会人型とは構造がまったく異なります。

この記事は、署名機能の方式を選定する事業会社の意思決定者と開発責任者に向けて、リモート署名ガイドラインの用語を実装要件に翻訳し、電子処方箋という国内で大規模に動いている実例で確かめます。制度・仕様の確認時点は2026年7月18日です。

この記事の要点

電子署名は「署名鍵がどこにあるか」でローカル署名とリモート署名に分かれます。マイナンバーカード（JPKI）はローカル署名の代表です

リモート署名は利用者ごとの鍵をクラウドで預かる当事者型のクラウド版で、事業者の鍵で署名する立会人型とは別物です

核心は鍵認可（SAD）の設計です。カードのPINに代わって「署名指示者＝鍵の持ち主」を何で担保するかがすべての起点になります

JT2Aガイドラインはセキュリティレベル1〜3を定義し、鍵生成・鍵インポート・鍵保持・鍵認可の4点を重視します

電子処方箋のHPKIセカンド電子証明書が国内最大級の実例です。マイナンバーカードが認証を担い、署名鍵はクラウド側という役割分担は設計の参考になります

リモート署名とローカル署名。分岐点は「鍵がどこにあるか」

電子署名は、署名鍵の所在によって2つに分かれます。

ローカル署名は、鍵が手元のデバイスにある方式です。マイナンバーカード（JPKI）はこの代表で、秘密鍵はICチップから外に出ない設計になっています。署名処理はカードの中で行われ、外に出るのは署名結果だけです。鍵を使う権限の担保はPINが担います。カードを持っていてPINを知っている人だけが署名できる、という素直な構造です。

リモート署名は、鍵が事業者のサーバー（HSM）にあり、利用者の指示で署名する方式です。日本のJT2Aリモート署名ガイドラインは、リモート署名事業者を「署名者の署名鍵を設置・保管するサーバとそのサーバ上で署名者の指示に基づき、電子署名を行う機能を提供する者」と定義しています。

この2つを比較すると、リモート署名の難しさが1点に集約されることが分かります。「署名しろ」と指示してきたのが本当に鍵の持ち主かを、カードのPINの代わりに何で担保するのか。ローカル署名では物理的なカードの占有とPINの知識で解決していた問題を、ネットワーク越しに解き直す必要があるということです。

項目	ローカル署名	リモート署名
鍵の所在	手元のデバイス（ICカード等）	事業者のサーバー（HSM）
代表例	マイナンバーカード（JPKI）	HPKIセカンド電子証明書等
鍵を使う権限の担保	PINの入力	認可データ（SAD）の設計
利用者側の前提	カードとリーダー（またはNFC対応スマホ）	ネットワーク接続と認証手段
主な設計負担	読み取りUXとPIN管理	認可・鍵管理・監査ログ

なお、クラウド契約サービスで多数派の**立会人型（事業者の鍵で署名）**とは別物である点に注意してください。リモート署名は利用者ごとの鍵をクラウドで預かる当事者型のクラウド版です。この区別は電子署名の当事者型・立会人型を開発要件に翻訳するで整理しています。サービス比較の場で「クラウド署名」という言葉が出てきたら、それが立会人型なのかリモート署名なのかを最初に確認してください。証明書が誰の名義で発行されるかを聞けば、たいていその場で判別できます。

ガイドラインの用語を実装に翻訳する

JT2Aガイドライン（パートI〜III）を読むと、耳慣れない3文字略語が並びます。中心概念は次の3つです。

用語	意味	実装で対応するもの
SAD（Signature Activation Data）	署名鍵を活性化する認可データ。ICカードならPINに相当	利用者だけが生成できる認可トークン・認証結果
SAM	署名鍵の活性化を行うモジュール	HSM内・耐タンパ環境の認可検証ロジック
SAP	SADを収集するプロトコル	利用者→サーバーの認可フロー設計

読み解き方はこうです。ICカードでPINを入力する行為を3つに分解し、それぞれをネットワーク越しに成立させる設計を求めている、と考えると腑に落ちます。利用者が示す認可の証拠がSAD、それを検証して鍵を使えるようにする耐タンパな部品がSAM、認可の証拠を安全に集めてくる経路がSAPです。

ガイドラインが重要視するのは鍵生成・鍵インポート・鍵保持・鍵認可の4点で、セキュリティレベルを1〜3で定義します（レベル2が認定認証業務と同等、レベル3がeIDAS適格電子署名と同等）。欧州の規格 EN 419241-1 では単独制御の保証レベルとして SCAL1/SCAL2 という概念があり、デジタル庁の委託調査報告書（2024年3月）が国内基準への取り込みを検討しています。

これを実装要件に落とすと、最低限次の4つを設計することになります。

利用者認証: 総務省・法務省・経産省の電子署名法3条Q&Aは、固有性の要件を満たす例として2要素認証（パスワード＋ワンタイムパスワード等）を明示しています。何をSADの源にするかはここから逆算します
署名指示の否認防止: 「利用者の意思のみに基づいて機械的に」署名されること。認可（SAD）なしにサーバー側の判断で署名できる構造を作らないことが要点です。運用の都合で管理者が代理署名できる裏口を用意すると、この前提が崩れます
鍵管理: HSMでの鍵生成・保持が前提です。参照文書としてCRYPTREC鍵管理指針やNIST SP 800-130Aが挙げられています。利用者ごとの鍵を大量に抱えるため、鍵のライフサイクル管理が設計上の大きな塊になります
監査ログ: 誰がいつ何に署名を認可したかの記録です。ガイドラインのパートIは監査要件を細かく規定しています。後から「この署名は本人の指示によるものだ」と説明する材料は、このログしかありません

発注の観点で言えば、この4項目のうち最も見積もりから抜け落ちやすいのは鍵管理と監査ログです。署名APIが動くところまでは分かりやすい成果物ですが、利用者数が増えたときの鍵のライフサイクル管理と、監査に耐えるログ基盤は後から足すと高くつきます。

動いている実例。電子処方箋のHPKIリモート署名

概念だけだと抽象的なので、国内で大規模に動いている実例を見ます。電子処方箋です。厚生労働省の「電子処方箋における電子署名について」によると、医師・薬剤師の署名には2方式があります。

ローカル署名: HPKIカードをリーダーにかざしてPIN入力し、処方箋ごとに署名します
リモート署名: 本人認証を通すと、クラウドで管理されるHPKIセカンド電子証明書の鍵で署名します。認証は原則1日1回で、以降はトークンで署名要求が処理されます

ここには実務上の切実な事情があります。医師が1日に何十枚も処方箋を発行する現場で、1枚ごとにカードをかざしてPINを入力する運用は成立しません。リモート署名は、この業務量の問題に対する回答として選ばれています。リモート署名を選ぶ動機は多くの場合「セキュリティを上げたいから」ではなく「業務量に耐える署名フローが要るから」だという点は、自社の要件を考えるうえでも参考になります。

さらに興味深いのは認証手段です。HPKIカードのほか、マイナンバーカード（利用者証明用の4桁パスワード）やスマホのFIDO生体認証でも認証でき、署名自体はクラウドのHPKI鍵で行われます。つまり、JPKIの利用者証明用証明書が「本人認証（SADの担保）」を担い、署名鍵はリモート側にある、という役割分担です。

この構造は、設計パターンとしてそのまま応用できます。認証を担う仕組みと、署名鍵を持つ仕組みを分離する。認証には広く普及した手段（マイナンバーカード、FIDO）を使い、署名鍵は業務要件に合った証明書をクラウドで管理する。利用者に新しい認証デバイスを配らずに、当事者型の署名を業務量に耐える形で実現できます。

ただし、この分離には設計上の責任が伴います。認証の強度が下がれば、署名の否認防止も同時に弱くなります。認証セッションの有効期間（電子処方箋では原則1日1回）をどう設定するかは、業務効率と否認防止のトレードオフを直接決める設計判断です。「認証は1日1回でよいか」は、UXの話ではなくリスク評価の話として扱ってください。

開発・発注時の論点

どのレベルを狙うかを最初に決める。 3条の推定効（固有性）まで求めるなら、2要素認証と鍵認可の設計が必須です。一方、社内ワークフローの承認記録程度であれば要件は軽くなります。ここを決めずに設計を始めると、後から要件が上振れしてHSMや監査ログの追加が発生し、コストが跳ね上がります。

HSMは運用コストで効く。 鍵の世代管理・バックアップ・監査対応を含めて見積もってください。HSMの購入費だけを見て「意外と安い」と判断するのは危険です。実務では、自前構築よりリモート署名サービスの利用が現実解になるケースが多いはずです。自社で構築すべきなのは、署名が事業の中核機能であり、鍵の取り扱いを外部に委ねられない事情がある場合に限られます。

長期保存とセットで考える。 署名した文書を7年、10年残すなら長期署名（PAdES/LTV）の設計が別途必要です。リモート署名は「どう署名するか」の方式であり、「署名した文書をどう残すか」は別の設計課題です。この2つを同じ会議で決めておかないと、後から文書形式の変更が必要になることがあります。

「リモート署名対応」の中身を確認する。 サービス選定時は、JT2Aガイドラインのどのレベル相当か、SAD（署名認可）の方式は何かを、仕様確認の項目に入れてください。「リモート署名に対応しています」という一文からは、レベルもSADの設計も読み取れません。

サービス選定チェックリスト

リモート署名サービスの比較検討に入る前に、確認すべき項目を整理します。

そのサービスは本当にリモート署名か、それとも立会人型か。証明書は誰の名義で発行されるか
JT2Aガイドラインのセキュリティレベル1〜3のどれに相当すると説明されるか。その根拠は何か
SAD（署名認可）はどう構成されるか。署名指示の直前に認証を要求できるか、セッション単位か
認証セッションの有効期間は設定変更できるか。自社の業務量とリスク評価に合わせられるか
認可なしに事業者側の判断で署名できる経路（管理者による代理署名等）が存在しないか
監査ログには何が記録されるか。誰が・いつ・どの文書に・どの認証手段で認可したかが揃うか。保存期間は
鍵の生成場所・保持形態と、利用者が退会した場合の鍵の扱い
署名形式は何か。長期署名（LTV）に対応するか、どのレベルまでか
料金体系は署名件数課金か利用者数課金か。自社の件数予測でどちらが有利か

自社実装を検討する場合は、これに加えてHSMの調達・冗長化・鍵バックアップの手順書整備・定期的な監査対応の工数を見込んでください。署名まわりの領域全体の見取り図はeKYC完全マップ2026、記事を読む順序はeKYC記事の学習パスにまとめています。組織名義の発行元証明で足りる文書であれば、そもそも個人の署名鍵を扱う必要はなくeシールの領域になります。

まとめ

リモート署名は署名鍵をHSMで預かり、利用者の指示で署名する方式です。立会人型とは別物で、当事者型のクラウド版と理解してください
核心は鍵認可（SAD）の設計です。「署名指示者＝鍵の持ち主」を2要素認証等で担保します
JT2Aガイドラインはセキュリティレベル1〜3を定義し（レベル3はeIDAS適格相当）、鍵生成・鍵インポート・鍵保持・鍵認可の4点を重視します。欧州EN 419241-1のSCAL概念の国内取り込みも検討されています
電子処方箋のHPKIセカンド電子証明書が国内最大級の実例です。マイナンバーカードが認証を担い署名鍵はクラウド側という役割分担は、設計パターンとして応用できます
リモート署名を選ぶ動機は多くの場合、業務量に耐える署名フローが必要だという運用要件です。狙うレベルを先に決めてから設計に入ってください
HSMは購入費より運用コストで効きます。長期保存の要件とセットで方式を決め、サービス選定では「リモート署名対応」の中身を具体的に確認してください

よくある質問

Q. リモート署名とは何ですか？

署名鍵を利用者の手元ではなく事業者のサーバー（HSM）に置き、利用者の指示に基づいて署名する方式です。JT2Aリモート署名ガイドラインは、リモート署名事業者を「署名者の署名鍵を設置・保管するサーバとそのサーバ上で署名者の指示に基づき、電子署名を行う機能を提供する者」と定義しています。鍵が手元のICカード等にあるローカル署名との対比で理解してください。

Q. リモート署名と立会人型の電子署名は同じものですか？

別物です。立会人型はサービス事業者が自社名義の鍵で署名する方式で、利用者本人の証明書は不要です。リモート署名は利用者ごとの署名鍵をクラウドで預かり、その本人の鍵で署名するため、当事者型のクラウド版にあたります。サービス比較の場では、証明書が誰の名義で発行されるかを確認すれば判別できます。

Q. SADとは何ですか？

Signature Activation Dataの略で、署名鍵を活性化するための認可データです。ICカードにおけるPINに相当します。実装上は、利用者だけが生成できる認可トークンや認証結果がこれにあたります。関連する概念として、鍵の活性化を行うモジュールをSAM、SADを収集するプロトコルをSAPと呼び、JT2Aガイドラインではこの3つが中心概念になっています。

Q. リモート署名で電子署名法3条の推定効は取れますか？

固有性の要件を満たす設計にすることが前提です。総務省・法務省・経済産業省の電子署名法3条Q&Aは、固有性の要件を満たす例として2要素認証（パスワードとワンタイムパスワード等）を明示しています。加えて、認可（SAD）なしにサーバー側の判断で署名できる構造にしないこと、誰がいつ何に署名を認可したかの監査ログを残すことが必要です。逆に、社内ワークフローの承認記録程度で推定効を求めないなら、要件は軽くできます。

Q. リモート署名の実例はありますか？

電子処方箋が国内で大規模に動いている実例です。厚生労働省の資料によると、医師・薬剤師の署名にはHPKIカードによるローカル署名と、クラウドで管理されるHPKIセカンド電子証明書によるリモート署名の2方式があります。リモート署名では認証は原則1日1回で、以降はトークンで署名要求が処理されます。認証手段にはHPKIカードのほかマイナンバーカードやスマホのFIDO生体認証も使えます。

Q. リモート署名サービスを選ぶとき何を確認すべきですか？

まずそのサービスが本当にリモート署名か立会人型かを、証明書の名義で確認します。そのうえで、JT2Aガイドラインのどのレベル相当か、SAD（署名認可）の方式は何か、認証セッションの有効期間を変更できるか、監査ログに何がどれだけ残るか、長期署名（LTV）に対応するか、料金体系は件数課金か利用者数課金かを確認してください。

Q. リモート署名を使えば長期保存の対策は不要ですか？

不要にはなりません。リモート署名は「どう署名するか」の方式であり、署名済み文書を7年・10年と保存して検証可能に保つには、長期署名（PAdES/LTV）の設計が別途必要です。証明書の有効期限や暗号の陳腐化に備えて検証材料を文書に埋め込み、タイムスタンプで時刻を固定する仕組みを、方式選定と同じタイミングで検討してください。

主な参考資料: JT2A リモート署名ガイドライン（JNSA）、電子署名法3条Q&A（総務省）、厚労省電子処方箋における電子署名について、デジタル庁委託調査リモート電子署名基準の検討（概要）

TodoONada株式会社では、電子署名システムの方式選定・受託開発を行っています。リモート署名サービスの技術評価や署名要件の整理からご相談いただけるほか、マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの開発を方式選定から運用までワンストップで支援しています。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。ご相談はマイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。

この記事に関連するサービス

TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。

マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。