長期署名とLTV。PAdES・XAdES・CAdESの地図

電子署名の導入プロジェクトでは、「署名を付けられるか」に議論が集中しがちです。しかし本当に難しいのは、付けた瞬間ではなく10年後に検証できるかのほうです。署名した当日は問題なく検証できていた文書が、数年後にビューアを開くと警告表示になる。この現象は珍しいものではなく、長期署名の設計を省いた結果として普通に起こります。

この記事は、契約書や記録文書を長期保存する必要がある事業会社の意思決定者と、署名機能を実装・選定する開発責任者に向けて、長期署名の3つの形式（PAdES・XAdES・CAdES）とLTVの考え方を、実装と発注の判断に必要な粒度で整理します。制度情報の確認時点は2026年7月18日です。

この記事の要点

• 電子署名が時間とともに検証できなくなる理由は2つ、証明書の失効・期限切れと暗号の陳腐化です
• 長期署名は「検証に必要な材料を文書と一緒にパッケージし、タイムスタンプで時刻を固定し続ける」技術です
• 形式は対象データで分かれます。PDFならPAdES、XMLならXAdES、任意のバイナリならCAdES。実務の主戦場はPAdESです
• レベルはB→T→LT→LTAの階段。保存年限が証明書の有効期間を超えるならLT以上、10年級ならLTA＋定期的な再タイムスタンプ運用が基本線です
• 費用は構築だけでなくタイムスタンプの運用コストまで含めて見積もります。クラウド署名サービス利用時はLTV対応の有無と対応レベルを仕様確認の項目に入れてください

なぜ「長期」が問題になるのか

電子署名は署名した時点では有効でも、時間が経つと2つの理由で検証できなくなります。

第一に、証明書の失効・期限切れです。 署名に使った電子証明書には有効期限があり、数年で切れます。マイナンバーカードの署名用証明書も同じです。期限が切れた後、あるいは何らかの理由で失効した後に文書を検証しようとすると、「この証明書は現在有効ではない」という結果しか得られません。必要なのは「現在有効か」ではなく「署名した時点では有効だった」ことの証明なのですが、その材料が文書に含まれていなければ後から示せません。

第二に、暗号の陳腐化です。 暗号アルゴリズムは年月とともに危殆化します。計算機の性能向上と攻撃手法の進歩によって、10年前に十分だった暗号強度が今も安全とは限りません。ハッシュアルゴリズムの世代交代の歴史を思い出せば、これが理論上の話ではないことは明らかです。

一方で、契約書や記録文書は7年、10年と保存します。署名の検証可能性をその期間にわたって維持する仕組みが長期署名で、原理は単純です。検証に必要な材料を文書と一緒にパッケージし、タイムスタンプで時刻を固定し続ける。この2つに尽きます。

発注の観点で押さえておきたいのは、この課題が署名方式の選択とは独立に発生することです。当事者型で作ろうと立会人型のサービスを使おうと、文書を長く残すなら長期署名の設計は必要になります。方式選定の議論に集中していると、この論点が要件から抜け落ちがちです。

3つの形式は対象フォーマットで分かれる

長期署名の標準は、署名対象のデータ形式ごとに3系統あります。名前は違いますが、中身の考え方は共通です。

形式	対象	主な用途
PAdES	PDF	契約書・請求書・証明書類。実務の主戦場
XAdES	XML	行政手続き・業務間データ連携
CAdES	任意のバイナリ	ファイル形式を問わない汎用

実務で最初に触れるのは、ほぼPAdESです。PDFの中に署名・証明書・検証情報を埋め込む構造になっており、Adobe Acrobatなどのビューアが検証結果を表示してくれます。受け取り側が特別なツールを用意しなくても署名の状態を確認できるため、体験を作りやすいのが強みです。契約書や請求書のように「人が読む文書」を扱う場合、PAdES以外を選ぶ理由はあまりありません。

XAdESは、XMLデータに対する署名です。行政手続きの電子申請や、企業間のデータ連携で使われます。人が読む文書ではなく構造化データを対象とするため、検証結果をユーザーに見せる設計は自前で作ることになります。

CAdESは、ファイル形式を問わない汎用の形式です。画像でも独自バイナリでも署名できますが、その分「検証結果をどう見せるか」「署名ファイルと本体ファイルをどう対応づけて保管するか」を自分で設計する必要があります。

3つのうちどれを選ぶかは、ほぼ自動的に決まります。扱う文書の形式が何かを確認すれば、形式の選択は終わりです。設計上の判断が必要になるのは、次に述べるプロファイルのほうです。

プロファイル。B → T → LT → LTA の階段

各形式には「どこまで検証材料を持つか」を示すレベル（プロファイル）があります。PAdESを例にすると、次の4段の階段になります。

• B（Basic）: 署名だけ。証明書が有効なうちしか検証できません
• T（Timestamp）: 署名にタイムスタンプを付与します。「いつ署名したか」が固定されます
• LT（Long Term）: 検証に必要な材料（証明書チェーン・失効情報）を文書内に埋め込みます。ここからが長期署名で、この埋め込みが**LTV（Long Term Validation）**と呼ばれる考え方です
• LTA（LT + Archive）: 全体にアーカイブタイムスタンプを重ねます。暗号の陳腐化に対しては、期限が切れる前に新しいタイムスタンプを重ね打ちして延命します

階段の意味を、冒頭に挙げた2つの問題と対応させると理解しやすくなります。Tが解決するのは「いつ署名したか」の固定です。LTが解決するのは「その時点で証明書が有効だったこと」を後から示す材料の確保です。LTAが解決するのは「暗号自体が古くなる」問題で、これだけは一度で終わらず継続的な運用が必要になります。

発注・設計の判断はシンプルです。保存年限が証明書の有効期間を超えるならLT以上、10年級ならLTA＋定期的な再タイムスタンプ運用が基本線になります。

判断を早見表にすると次のようになります。

保存年限の想定	推奨レベル	追加で必要になること
証明書の有効期間内で完結	B〜T	特になし（Tで署名時刻は固定しておくと安心）
証明書の有効期間を超える	LT以上	検証材料の埋め込み、失効情報の取得経路の確保
7年〜10年級の法定保存	LTA	再タイムスタンプの運用設計、費用の継続計上

「とりあえず全部LTAにしておけば安全では」と考えたくなりますが、LTAは運用が付いてくるレベルです。何万通もの文書に対して、期限前に再タイムスタンプを打ち続ける仕組みと予算が要ります。保存年限が短い文書まで一律にLTAにすると、必要のない運用コストを抱えることになります。文書の種類ごとに保存年限を棚卸しし、レベルを分けて設計するのが実務的です。

実務への翻訳。4つの論点

保存要件から逆算する。 設計の起点は技術ではなく法定保存年限です。犯収法の確認記録7年のように、まず「何年残さなければならないか」を確定させ、そこからレベルを決めます。保存要件そのものの設計は本人確認記録の保存要件で扱っています。文書の種類ごとに年限が異なる場合は、その一覧を作ることが要件定義の最初の作業になります。

タイムスタンプ運用はランニングコストである。 LTAの再タイムスタンプは「1回作って終わり」ではなく運用です。件数×単価で費用が積み上がります。年間発行通数と保存年限を掛け合わせると、累積の対象文書数は想像以上に大きくなります。初期構築費だけで予算を組むと、運用フェーズで足りなくなる典型的な項目です。再タイムスタンプのバッチをいつ・誰が実行し、失敗時にどうリカバリするかまで運用設計に含めてください。

役割分担を混同しない。 誰が（電子署名）・どこが（eシール）・いつ（タイムスタンプ）という分担はeシールの記事で整理したとおりです。長期署名はこれらを置き換えるものではなく、束ねて時間軸に耐えさせる技術です。「タイムスタンプを付けたから長期保存は大丈夫」という説明を受けたら、それがTレベルの話なのかLTA相当の運用まで含む話なのかを確認してください。

当事者型・立会人型のどちらでも問題は同じ。 署名の2類型のどちらを選んでも、長期保存するなら長期署名の設計が必要です。特にクラウド署名サービスを利用する場合、LTV対応の有無と対応する形式・レベルを仕様確認の項目に入れてください。「PAdES対応」とだけ書かれた仕様書は、Bレベルの署名でも嘘にはなりません。同様に、署名鍵をサーバー側で預かるリモート署名を選ぶ場合も、長期保存の設計は別途必要になります。

発注前チェックリスト

長期署名の要件をベンダーと詰める前に、次を自社で確定させておくと議論が早く進みます。

• 対象文書の種類ごとに法定保存年限を洗い出したか
• 署名に使う証明書の有効期間を確認したか。保存年限がそれを超えるか
• 文書形式はPDFか。PDF以外があるなら、その分の検証体験を誰が設計するか決めたか
• 必要なプロファイル（B/T/LT/LTA）を文書種別ごとに割り当てたか
• LTAが必要な文書について、再タイムスタンプの実行主体・頻度・失敗時の手順を決めたか
• タイムスタンプの年間費用（件数×単価×保存年限の累積）を予算に計上したか
• 検証する側（相手方・監督官庁・自社の監査）が、何を使ってどう検証するか想定したか
• クラウド署名サービスを使うなら、LTV対応の有無と対応レベルを書面で確認したか

ベンダーへの質問としては、「対応するのはPAdESのどのレベルまでか」「アーカイブタイムスタンプの重ね打ちは製品機能か、運用で行うのか」「失効情報の取得に失敗した場合の挙動はどうなるか」の3点が、実装の成熟度を測りやすい項目です。実際に署名済みPDFを検証したときに何が起きるかはPDF署名の検証で扱っています。電子署名や本人確認の領域全体の見取り図はeKYC完全マップ2026、記事の読む順序はeKYC記事の学習パスを参照してください。

まとめ

• 長期署名は「証明書の失効・期限切れと暗号の陳腐化を越えて検証可能性を保つ」技術です。PDFならPAdESが実務の主戦場になります
• 形式（PAdES/XAdES/CAdES）は扱う文書の形式でほぼ自動的に決まります。設計判断が要るのはプロファイルのほうです
• レベルはB→T→LT→LTAの階段。保存年限が証明書の有効期間を超えるならLT以上、10年級はLTA＋再タイムスタンプ運用が基本線です
• LTV＝検証材料の埋め込み。アーカイブタイムスタンプの重ね打ちで延命します。これは一度きりの構築ではなく継続的な運用です
• 費用は構築だけでなくタイムスタンプの運用コストまで見積もります。年間通数×保存年限で累積対象が大きくなる点に注意してください
• クラウド署名サービス利用時は、LTV対応の有無と対応レベルを書面で確認してください。「PAdES対応」だけでは何も分かりません

よくある質問

Q. 長期署名とは何ですか？

電子署名を長期間にわたって検証できる状態に保つ技術です。電子署名は時間が経つと、署名に使った証明書の失効・期限切れと暗号アルゴリズムの陳腐化という2つの理由で検証できなくなります。長期署名は、検証に必要な材料を文書と一緒にパッケージし、タイムスタンプで時刻を固定し続けることでこの問題に対処します。

Q. PAdES・XAdES・CAdESはどう使い分けますか？

署名対象のデータ形式で分かれます。PDFならPAdES、XMLならXAdES、任意のバイナリならCAdESです。中身の考え方は共通で、実務で最初に触れるのはほぼPAdESです。PAdESはPDF内に署名・証明書・検証情報を埋め込む構造で、Adobe Acrobatなどのビューアが検証結果を表示してくれるため受け取り側の体験を作りやすい点が強みです。

Q. LTVとは何ですか？

Long Term Validationの略で、検証に必要な材料（証明書チェーン・失効情報）を文書内に埋め込む考え方を指します。PAdESのプロファイルで言えばLT（Long Term）レベルにあたり、ここからが長期署名です。これにより、署名に使った証明書の有効期限が切れた後でも「署名した時点では有効だった」ことを文書単体から確認できるようになります。

Q. 保存年限に対してどのレベルを選べばよいですか？

保存年限が証明書の有効期間内で完結するならB〜Tで足ります。保存年限が証明書の有効期間を超えるならLT以上が必要です。7年から10年級の法定保存が必要な文書はLTAを選び、アーカイブタイムスタンプの期限が切れる前に新しいタイムスタンプを重ね打ちする運用を組みます。文書の種類ごとに保存年限を棚卸しし、レベルを分けて設計するのが実務的です。

Q. 長期署名の費用はどう見積もればよいですか？

構築費だけでなくタイムスタンプの運用コストを含めてください。LTAの再タイムスタンプは一度作って終わりではなく継続的な運用で、件数×単価で費用が積み上がります。年間発行通数と保存年限を掛け合わせた累積対象文書数で試算し、再タイムスタンプのバッチ実行体制や失敗時のリカバリ手順まで運用設計に含めることが必要です。

Q. クラウド電子契約サービスを使えば長期署名は不要ですか？

不要にはなりません。当事者型でも立会人型でも、文書を長期保存するなら長期署名の設計は必要です。サービス選定時には、LTV対応の有無と対応する形式・レベルを仕様確認の項目に入れてください。「PAdES対応」とだけ書かれていてもBレベルの署名である可能性があるため、どのプロファイルまで対応するかを書面で確認することが重要です。

主な参考資料: e-Gov 電子署名及び認証業務に関する法律、JIPDEC 電子署名・認証センター

TodoONada株式会社では、電子署名の付与・検証システムの受託開発を行っています。保存年限からの長期署名レベル選定、タイムスタンプ運用設計を含む要件定義の段階からご相談いただけます。マイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの開発もワンストップで対応しており、料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。ご相談はマイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。

---

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

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

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

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