セキュリティアーキテクチャ
PDF Proのプライバシー主張が実際にどう機能するか。
このページのすべての内容はブラウザのDevToolsで検証できます。基本ルール：私たちがあなたのファイルにアクセスできないようにする — たとえアクセスしたくても。以下は、そのルールが暗号、ストレージ、リクエスト層でどのように実施されているかの説明です。
memoryクライアントサイドWebAssembly・JS
lockAES-256-GCM
verifiedECDSA P-256
cloud_offクライアントサイド暗号化ストレージ
4つのアーキテクチャの柱
4つの技術的選択がセキュリティの姿勢を定義します。これらはポリシー文書ではなく、ブラウザ上で動作するコードによって実施されます。
1. ローカルファースト処理
PDF表示、注釈付け、フォーム入力、圧縮、結合、変換、署名はすべてWebAssemblyとJavaScriptを介してブラウザ内で完全に実行されます。これらのツールでは、ファイルデータがデバイスから外に出ることはありません — ネットワークタブで確認できます。
2. クライアントサイドでの鍵生成
ファイルを共有する場合、暗号化鍵はタブ内のWeb Crypto APIによって生成されます。鍵はメモリ内、URLフラグメント内、またはパスフレーズモードでは受信者のデバイス上でPBKDF2を介して導出されます。サーバーが鍵を見ることはありません。
3. クライアントサイド暗号化ストレージ
保存されるのはAES-256-GCMの暗号文と初期化ベクトル（パスフレーズモードではPBKDF2ソルトも）のみです。鍵がなければ、このデータは暗号学的にランダムなバイト列と区別できません。ルートデータベースアクセスがあっても復号はできません。
4. 誠実なAI境界
AIツール（チャット、要約、翻訳）が機能するには読み取り可能なテキストが必要です。私たちはクライアントサイドでテキストを抽出し、そのテキストのみをモデルプロバイダーに送信します — PDFファイル自体、画像、埋め込み添付ファイルは一切送信しません。詳細はAIセクションをご覧ください。
暗号化フロー（セキュア転送）
PDFをセキュア転送にドロップして生成されたリンクを共有するまでの、バイト単位の詳細な解説。以下の各ステップは、暗号文の保存を除いてブラウザ内で実行されます。
送信者 — ブラウザ内
// 1. generate a fresh 256-bit key
key = crypto.subtle.generateKey({name:"AES-GCM", length:256})
// 2. random 96-bit IV per file
iv = crypto.getRandomValues(new Uint8Array(12))
// 3. encrypt the PDF bytes locally
ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes)
// 4. upload ciphertext + iv — nothing else
id = await fetch("/api/transfer", {method:"PUT", body: ct, headers:{"x-iv": hex(iv)}})
// 5. URLフラグメント（#）にキーを含む共有リンクを構築する
link = `https://pdfpro.tools/s/<ID>#<KEY>`
▼
サーバー — 暗号文のみを保存
ciphertext = opaque bytes // キーなしでは復号できない
iv = 12-byte nonce
expiry = 24 h (free) / 30 d (Pro)
// URLフラグメント（#...）はブラウザによってサーバーに送信されない
▼
受信者 — ブラウザ内
// 1. ブラウザがページを読み込む。「#...」フラグメントはクライアントサイドに留まる
rawKey = location.hash.slice(1)
// 2. fetch the ciphertext
ct = await fetch("/api/transfer/" + id)
// 3. decrypt locally using Web Crypto
pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct)
// 4. ファイルは受信者のダウンロードフォルダに届く
セキュリティ保証は送信者のステップ5と受信者のステップ1に依存します：#以降のURLフラグメントは、準拠したブラウザによってサーバーに送信されることはありません。これがリンク自体が復号のクレデンシャルとなる仕組みです。
パスフレーズモードでは、送信者のステップ1がPBKDF2-SHA256(passphrase, salt, 310_000)に置き換えられます。ソルトはサーバーサイドに保存され、パスフレーズは帯域外で受信者と共有されます。
署名フロー（ECDSA P-256）
PDF署名にはNIST P-256曲線上のECDSAを使用します。秘密鍵はブラウザ内で生成され、文書はデバイスから外に出ることはありません。
秘密鍵の生成
ECDSA P-256鍵ペアがブラウザ内の
crypto.subtle.generateKeyによって生成されます。秘密鍵はパスワードでラップされたJSON Web Key（JWK）にエクスポートされ、ローカルに保存できます。SHA-256ハッシュと署名
PDFバイトはクライアントサイドでSHA-256によってハッシュ化されます。そのハッシュは秘密鍵によって署名されます。署名はCMSコンテナ（PAdES-B-Bプロファイル）としてPDFに埋め込まれます。
オフライン検証可能
公開鍵（文書と共に配布されるか、フィンガープリントとして提供）を持つ誰でも、オフラインで署名を検証できます。サーバーへの往復は必要ありません。
これではないもの
当社の署名は暗号学的に検証可能ですが、eIDASに基づく適格電子署名（QES）ではありません。整合性の改ざん防止証明であり、内部ワークフローに適していますが、法的拘束力を持つ規制グレードのものではありません。
AI機能 — 境界について誠実に
AIチャット、AI要約、翻訳には読み取り可能なテキストが必要です。デバイスから送出されるもの、されないものを正確に説明します。
ブラウザ内でテキストを抽出
PDFはpdf.jsによってローカルで解析されます。抽出されたテキスト（スキャンPDFの場合はOCR出力）のみがメモリに保持されます — 元のファイルはデバイス上に留まります。
プロバイダーにはテキストのみ送信
そのテキスト文字列をAIプロバイダー（Anthropic / OpenAI）に送信します。PDF自体、埋め込み画像、フォント、フォームデータはいかなるAIモデルにもアップロードされません。
コンテンツのトレーニング利用なし
プロバイダー契約により、お客様のコンテンツを使ったトレーニングは無効化されています。リクエストはステートレスです — 各リクエストはセッションにスコープされます。
これが重要な場面
文書に規制対象コンテンツ（PHI、機密情報、法的特権情報）が含まれており、テキスト抽出でさえ機密性が高い場合は、AI機能をスキップしてローカルツール（表示、注釈、署名、圧縮、変換）を使用してください — それらは100%ブラウザ内で動作します。
脅威モデル — 防御できること、できないこと
脅威モデルを明確にすることはマーケティングより有益です。アーキテクチャが実際に防御できることと、その限界を説明します。
shieldアーキテクチャが防御するもの
- PDF Proのスタッフがサーバー上であなたのファイルを閲覧すること（私たちは鍵を保持しません）。
- 転送ストアのデータベースレベルの侵害（攻撃者が見えるのは暗号文であり、ファイルではありません）。
- ファイルコンテンツの裁判所命令による開示（私たちが提供できるのは暗号文のみです — それが私たちが持っているすべてです）。
- メールサーバーへの機密添付ファイルの保持（メールサーバーを通過するものは何もありません）。
- 署名済みPDFの改ざん（ECDSA署名の検証がバイト単位の変更を検出します）。
warningブラウザベースのツールでは防御できないもの
- 侵害されたエンドポイント（デバイス上のマルウェア）— 鍵は信頼できるデバイスのメモリ上に存在する必要があります。
- URLフラグメントを盗み見る人物 — 共有リンクはファイル自体と同様に扱ってください。
- パスフレーズモードでの脆弱なパスフレーズ — PBKDF2はブルートフォースを遅延させますが、6文字のパスフレーズを安全にはしません。
- 受信者による復号済みファイルの転送 — トランスポートセキュリティは受信者がPDFを保存した時点で終了します。
- ブラウザ自体の侵害またはページに注入する悪意ある拡張機能。
「ハッキング不可能」という主張はしません。エンドツーエンド暗号化は侵害のコストを大幅に高めます — すべてのリスクを排除するものではなく、特にエンドポイントにおいてはそうです。最も機密性の高いケースでは、セキュア転送と別のパスフレーズおよび信頼できる経路での鍵交換を組み合わせてください。
関連資料
よくある質問
PDF Proは私のファイルを復号できますか？
いいえ。暗号化鍵はユーザーのブラウザ内で生成・保持されます。セキュア転送では、サーバーはAES-256-GCMの暗号文と初期化ベクトル（パスフレーズモードではソルトも）のみを保存します。鍵が当社のインフラに届くことはありません。データベースへの完全アクセスがあっても、当社の運営者はあなたのファイルを復号することはできません。
何がローカルで実行され、何がサーバーで実行されますか？
表示、注釈付け、フォーム入力、圧縮、結合、変換、署名はすべてWebAssemblyとJavaScriptを介して100%ブラウザ内で実行されます — ファイルデータがデバイスから外に出ることはありません。AI機能（チャット、要約、翻訳）はローカルでテキストを抽出し、そのテキスト（PDFファイル自体ではなく）のみをモデルプロバイダーに送信します。
PDF Proはどのアルゴリズムを使用していますか？
対称暗号化（セキュア転送）にはAES-256-GCM、パスフレーズ導出鍵には310,000回反復のPBKDF2-SHA256、デジタル署名にはNIST P-256上のECDSA、文書ハッシュ化にはSHA-256を使用します。これらはすべてブラウザのネイティブWeb Crypto APIを介して実行されます。このAPIは監査済みで標準化されており、当社が実装したものではありません。
これは法的拘束力のある電子署名ですか？
PDF Proの署名は暗号学的に検証可能（SHA-256ハッシュ上のECDSA P-256、PAdES-B-Bプロファイル）ですが、eIDASまたは同等の規制に基づく適格電子署名（QES）ではありません。QESグレードの法的拘束力には、認定トラストサービスプロバイダーが必要です。
パスフレーズを忘れたり共有リンクを失くしたりした場合はどうなりますか？
ファイルは永久に回復不能になります。これがエンドツーエンド暗号化のトレードオフです — 私たちは最初から鍵を持っていなかったため、回復経路はありません。パスフレーズはパスワードマネージャーに保存し、リンクは確実な場所に保存してください。
ファイルアクティビティのサーバーサイドログを保持していますか？
運用ログ（リクエストタイミング、エラーコード、レート制限用IPアドレス）は保持しますが、平文のファイルコンテンツや暗号化鍵は一切保持しません。ログは短期間のスケジュールで保持されます — 現在の保持期間についてはプライバシーポリシーをご覧ください。
裁判所命令によってファイルの開示を強制されることはありますか？
私たちが提供できるのは、保有しているもの（暗号文）のみです。復号鍵は送信者のデバイスまたは受信者が保持するURLフラグメント内に留まっており、その暗号文は復号できません。召喚状によって私たちが保存したことのない鍵を遡及的に回復することはできません。
暗号に関する主張を自分で検証するにはどうすればよいですか？
ブラウザのDevToolsを開き、ネットワークタブでセキュア転送のアップロード中にページから送出されるものを確認してください。元のPDFではなく暗号文がサーバーにPUTされているのが分かります。暗号化コードはWeb Crypto APIを呼び出します。これは当社のコードではなく、ブラウザに組み込まれており、誰でも検査できます。
プライバシーはアーキテクチャであり、マーケティングではありません。
セキュア転送を試して、ネットワークタブを自分で確認してください。ファイルは平文でアップロードされることはありません。
lockセキュア転送を試す