# PDFの見た目の署名は、デジタル証明書ではありません

Lutrakitの [PDF署名](/ja/pdf-shomei/) は、手書きまたは画像の署名をPDFページに配置し、新しいPDFをブラウザーからダウンロードするためのツールです。無料で、アカウントは不要で、選択したPDFや署名画像をアップロードしない設計です。ただし、作られるのはページ上の見た目の印です。証明書ベースのデジタル署名、適格電子署名、文書が改ざんされていないことを示す暗号学的証明ではありません。

相手が「見える署名画像でよい」と明示し、文書のリスクが低い場合に使ってください。デジタル証明書、本人確認、タイムスタンプ、長期検証、監査ログ、適格署名ワークフローが必要な場合は、このツールでは足りません。

このガイドは境界を説明するものです。法的助言ではなく、特定の手続きで見た目の署名が有効かどうかを判断するものではありません。

## 混同されやすい3つの「署名」

「署名」という言葉には複数の意味があります。

| 用語 | 平易な意味 | Lutrakit PDF署名でできること |
| --- | --- | --- |
| 見た目の署名 | ページに見える手書き、文字、スキャン、画像の印。 | 可能。1ページ以上に視覚的な印を配置する。 |
| 電子署名 | 法域や文脈により、多様な電子的行為や記号を含み得る広い法的カテゴリ。 | 状況によって意思表示の一部になり得るが、Lutrakitは本人確認や法的要件を検証しない。 |
| デジタル/証明書署名 | 証明書やデジタルIDに紐づく暗号学的署名。PDFソフトで検証できることが多い。 | 不可。証明書署名や暗号学的検証データは作らない。 |

欧州委員会のeSignature資料は、eIDASにおける電子署名を「単純」「高度」「適格」の3段階で説明しています。高度電子署名には、署名者との結びつき、識別可能性、署名者の管理、後続変更の検出可能性が求められ、適格電子署名ではさらに適格な作成装置と適格証明書が必要です。参照: [What is eSignature](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/467109069/What%2Bis%2BeSignature)、[eSignature FAQ](https://ec.europa.eu/digital-building-blocks/sites/spaces/DIGITAL/pages/880312429/eSignature%2BFAQ)。

技術的なデジタル署名は、名前を描くこととは異なります。NISTはデジタル署名を、未許可の変更検出や署名者の認証に使われる暗号学的仕組みとして説明しています: [FIPS 186-5](https://csrc.nist.gov/pubs/fips/186-5/final)。PDFでは、ETSI PAdESがPDFデジタル署名と長期検証のプロファイルを定義しています: [ETSI EN 319 142-1 V1.2.1](https://www.etsi.org/deliver/etsi_en/319100_319199/31914201/01.02.01_60/en_31914201v010201p.pdf)。

AdobeのAcrobat文書も、証明書署名と通常の見た目の署名を区別しています。証明書署名は証明書ベースのデジタルIDを使い、真正性や完全性の確認に関係します。表示される署名と非表示の署名の両方があり得ます: [certificate signatures in Acrobat](https://helpx.adobe.com/uk/acrobat/kb/certificate-signatures.html)。

## このツールが向いている場面

見た目のPDF署名が向いているのは、次の条件がそろう場合です。

- 相手が見える署名、イニシャル、確認印を求めている。
- 文書のリスクが低い。
- 相手とのやり取り以上の本人確認を必要としない。
- 改ざん検出用の証明書署名を必要としない。
- 送信前に出力PDFを目視確認できる。
- 相手がこの形式を受け入れる。

例として、ドラフトへの確認印、学校が見た目の署名を受け入れる許可書、非公式な合意へのイニシャル、受け手が明示的に認めた低リスクの社内フォームがあります。

一方、公証、規制対象の金融・医療フォーム、移民・行政手続き、特定の電子署名サービスを求める契約、「デジタル証明書」「適格電子署名」「PAdES」「AATL」「タイムスタンプ」「検証済み署名」と書かれたワークフローには使わないでください。

## ブラウザー内ツールとしての動き

現在のLutrakitでは、PDFを選び、署名を描くか画像を読み込み、必要ならキャプションを付け、1ページ以上に配置して出力をダウンロードします。PDFと署名データはブラウザー内で処理されます。再利用用署名は、利用者が保存を選んだ場合だけ、このサイト用のブラウザー保存領域に残ります。Lutrakitアカウントに保存されるわけではありません。

実装上限は変更される場合があります。現在のソースでの主な上限は次のとおりです。

- 選択PDF: 最大100 MB。
- 読み込み署名画像: PNG、JPEG、WebP。圧縮ファイル5 MBまで、各辺4096 pxまで、最大1600万ピクセル。
- 1つのPDFに配置できる署名: 最大32個。
- 1つの配置署名PNGの作業量: 展開後8 MBまで。
- 1回の署名処理全体: 展開後32 MBまで。
- 保存できる再利用署名: 最大8件。1件ごと、全体とも保存上限あり。

これらはブラウザーのメモリを守るための上限です。大きいPDFや特殊なPDFが必ず成功する保証ではありません。

## 実例: 低リスクな確認書

イベント担当者から「イベント手順を読んだことを確認します」という1ページPDFが届き、見える署名でよいと返信されたとします。

1. [PDF署名](/ja/pdf-shomei/) を開きます。
2. PDFを選びます。
3. 署名を描くか、使ってよい署名画像を読み込みます。
4. 必要なら氏名と日付などのキャプションを付けます。
5. 署名欄に配置します。
6. 共有端末では再利用用に保存しません。
7. 署名済みPDFをダウンロードします。
8. ビューアーでページ、位置、読みやすさ、日付、ファイル名を確認します。
9. ビューアーに署名パネルがある場合、見た目の印を証明書署名と誤解しないよう確認します。

期待される結果は、指定した場所に署名画像が見えることです。期待してはいけない結果は、画像を置いただけでPDFが証明書署名済み、または暗号学的に検証済みになることです。

この例を再現するときは、ブラウザー、OS、サンプルファイル、配置、ダウンロード名、Networkでの非アップロード確認を記録してください。

## プライバシーと保存署名

一度だけ使い、保存しない署名は、出力を作るための一時的な印として扱えます。再利用用に保存する場合は、`localStorage` が同じオリジンに対してセッションをまたいで残ることを理解してください。MDNの [Window.localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) も、この保存の性質を説明しています。同じブラウザープロファイルを使える人が、保存済みサイトデータを見たり使ったりできる可能性があります。

実務上のルールは単純です。共有PC、学校、図書館、職場の端末では、安全で許可されている場合を除き、再利用署名を保存しないでください。不要になったらツールの削除操作を使い、必要に応じてサイトデータも消します。

## 送信前チェックリスト

見た目の署名付きPDFを送る前に確認します。

- 署名が正しいページにある。
- 重要な文字を隠していない。
- キャプションが正しく、誤解を招かない。
- 出力ファイル名が分かりやすい。
- ダウンロード後にPDFが開ける。
- 相手が見た目の署名を受け入れる。
- 証明書、タイムスタンプ、監査ログ、適格署名を求められていない。
- 必要なら署名前の元PDFを別に保存している。

相手が後から「有効なデジタル署名」を求めた場合、見た目の署名PDFを編集し続けても要件を満たせません。指定された署名方法を使ってください。