GPG/PGPとは
PGP（Pretty Good Privacy）は、1991年にPhil Zimmermann氏によって開発された電子メールの暗号化・電子署名プログラムです。GPG（GNU Privacy Guard / GnuPG）は、PGPのオープンソース実装であり、現在最も広く使用されています。
GPG/PGPは公開鍵暗号方式を採用しており、以下の機能を提供します：
- 暗号化：第三者に読まれることなくメッセージを送信
- 電子署名：メッセージの真正性と完全性を証明
- 鍵管理：公開鍵と秘密鍵のペアを管理
- 信頼の輪（Web of Trust）：分散型の信頼モデル
GPGは特定企業が管理するサービスではなく、OpenPGPという公開仕様（IETFのRFC）に準拠したオープンな実装である点が重要です。仕様が公開されているため、GnuPG以外にもSequoia-PGP（Rust実装）、OpenPGP.js（JavaScript実装、ProtonMailなどが利用）、RNP（Mozilla発）など複数の独立実装が存在し、相互運用性が担保されています。ここが「特定ベンダーのSaaSに依存する暗号化」と根本的に異なる点です。
仕組み・詳細解説
ハイブリッド暗号方式：公開鍵暗号と共通鍵暗号の組み合わせ
GPG/PGPは、メッセージ本体をRSAやECCなどの公開鍵暗号でそのまま暗号化するわけではありません。公開鍵暗号は計算コストが高く大容量データの暗号化には不向きなため、以下のようなハイブリッド方式を採用しています。
- 暗号化のたびにランダムなセッション鍵（AES-256などの共通鍵）を生成する
- メッセージ本体はこのセッション鍵で高速に共通鍵暗号化する（デフォルトはAES-256、旧バージョンではCAST5やTripleDESも選択可能だったが現在は非推奨）
- セッション鍵そのものは、受信者の公開鍵（RSAやECC）で暗号化する
- 「公開鍵で暗号化されたセッション鍵」＋「セッション鍵で暗号化された本文」をまとめてOpenPGPメッセージとして送信する
受信者は自分の秘密鍵でセッション鍵を復号し、そのセッション鍵で本文を復号します。これにより「公開鍵暗号の安全な鍵配送」と「共通鍵暗号の高速性」を両立させています。TLSのハンドシェイクと基本思想は同じですが、GPGはリアルタイム通信ではなく保存データ・非同期メッセージ（メール、ファイル）向けに設計されている点が異なります。
鍵ペアの構造：マスター鍵とサブキー
GPGの鍵は1個の鍵ではなく、役割の異なる複数の鍵で構成されるのが実務上のポイントです。
| 鍵の種類 | 主な用途 | 運用上の推奨 |
|---|---|---|
| Certify鍵（マスター鍵） | 他の鍵に署名して身元を証明する「鍵の鍵」 | オフライン（USBメモリ等）に保管し、日常端末には置かない |
| Sign サブキー | メールやGitコミットへの電子署名 | 有効期限を1〜2年程度に設定し定期更新 |
| Encrypt サブキー | メッセージ・ファイルの暗号化 | 端末ごとに分けて発行すると鍵漏洩時の被害を局所化できる |
| Auth サブキー | SSH認証への転用（gpg-agentのSSHサポート） | サーバーへのSSHログインをGPGスマートカードで一元管理する用途で使う |
マスター鍵とサブキーを分離しておくと、日常使いの端末が万一侵害されてもマスター鍵自体は無事なため、サブキーだけを失効させて再発行すればよく、身元証明（Web of Trustで積み上げた署名の輪）をゼロからやり直す必要がありません。
信頼の輪（Web of Trust）と鍵の検証
認証局（CA）が身元を保証するX.509証明書と異なり、OpenPGPは参加者同士が互いの鍵に署名し合う分散型の信頼モデルを採用しています。Aさんの公開鍵にBさんとCさんが「本人確認済み」として署名すると、Bさん・Cさんを信頼する第三者はAさんの鍵も間接的に信頼できる、という考え方です。実務では厳密なWeb of Trustの構築より、鍵のフィンガープレント（40桁の16進数、例：gpg --fingerprintで表示）を対面や既知の安全な経路で照合する運用の方が現実的です。
OpenPGPのパケット形式とRFC
OpenPGPのデータ形式（鍵、署名、暗号化メッセージのバイナリ構造）はRFC 4880（OpenPGP Message Format）で標準化され、2024年には暗号アルゴリズムを刷新した後継のRFC 9580（OpenPGP Message Format、通称"Crypto Refresh"）が発行されています。RFC 9580ではEd25519/Ed448やX25519/X448、AEAD暗号モード（OCB、EAX）がネイティブにサポートされ、旧来のMDC（Modification Detection Code）による整合性検証よりも堅牢な仕組みに置き換えられました。GnuPG 2.4系はこの新形式に順次対応が進んでいます。
AIエンジニアとしての実体験
AIエンジニアとして、GPGは日常的に使用するツールの一つです。特に以下の場面で重宝しています：
Gitコミットへの署名
オープンソースプロジェクトや企業のリポジトリでは、コミットへのGPG署名が求められることが増えています。これにより、コミットが確かに本人によるものであることを証明できます。
# GPG鍵の生成
gpg --full-generate-key
# 鍵の一覧表示
gpg --list-secret-keys --keyid-format=long
# Gitへの署名設定
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
# 署名付きコミット
git commit -S -m "Add new feature"
機密設定ファイルの暗号化
AIモデルのAPIキーやデータベース認証情報などの機密情報を、GPGで暗号化してリポジトリに保存することがあります。git-cryptやsopsといったツールと組み合わせると、チーム内で安全に秘密情報を共有できます。
# ファイルの暗号化
gpg --encrypt --recipient user@example.com secrets.yaml
# ファイルの復号化
gpg --decrypt secrets.yaml.gpg > secrets.yaml
# 対称鍵暗号での暗号化（パスワードベース）
gpg --symmetric --cipher-algo AES256 sensitive_data.tar
自社サーバー運用への応用
パッケージ署名の検証
Linux環境でのパッケージ管理において、GPG署名の検証は重要です。不正なパッケージのインストールを防ぐため、リポジトリの公開鍵をインポートして署名を検証します。
# Debian/Ubuntu でのリポジトリ鍵追加
curl -fsSL https://example.com/gpg-key.asc | sudo gpg --dearmor -o /usr/share/keyrings/example-archive-keyring.gpg
# RPM系でのGPG鍵インポート
sudo rpm --import https://example.com/RPM-GPG-KEY
自動化スクリプトでの使用
CI/CDパイプラインでGPGを使用する場合、パスフレーズなしの鍵やgpg-agentの設定が必要になります。
# バッチモードでの復号化
echo "$GPG_PASSPHRASE" | gpg --batch --yes --passphrase-fd 0 --decrypt secrets.gpg
# gpg-agentの事前設定
gpg-connect-agent "PRESET_PASSPHRASE $KEYGRIP $PASSPHRASE" /bye
メリット・デメリット（注意点）
メリット
- 特定ベンダーへの非依存：OpenPGPは公開仕様であり、GnuPG以外の実装（Sequoia-PGP、RNP、OpenPGP.js等）とも相互運用できる。SaaSベンダーが終了しても暗号化資産が失われない。
- 署名と暗号化の両方を1つの仕組みでカバー：メールの真正性証明（署名）と機密性の担保（暗号化）を同じ鍵基盤で扱える。
- エンドツーエンド暗号化（E2EE）：メールサーバーやクラウドストレージなど中間経路を信頼せずに機密性を維持できる。
- ソフトウェア配布の完全性保証で広く実績：Debian/Ubuntu（APT）、Fedora/RHEL（RPM）、Docker Hubのイメージ署名、Gitのコミット・タグ署名など、インフラの基盤技術として長年運用されている。
- オフライン運用が可能：ネットワーク接続なしで暗号化・署名・検証が完結するため、エアギャップ環境でも利用できる。
デメリット・注意点
- UXの複雑さ：鍵生成・公開鍵の配布・信頼設定・有効期限管理など、一般ユーザーには理解が難しい概念が多く、「使いにくさ」が普及の壁になっている（Web暗号化メールの主流がPGPではなくS/MIMEやプロプライエタリE2EEに流れた一因）。
- 秘密鍵紛失時の復旧不能性：秘密鍵とパスフレーズを失うと暗号化データは原理上復号不可能。バックアップ運用（失効証明書の事前発行を含む）が必須。
- メタデータは保護されない：件名・送信者・受信者・送信日時などのヘッダー情報は暗号化されず、本文のみが保護対象（PGP/MIMEでも件名は平文のまま残ることが多い）。
- 鍵失効の反映に時間差がある：失効証明書（revocation certificate）を配布しても、相手側が古い公開鍵をキャッシュしていると気づかれないリスクがある。
- 実装の脆弱性リスク：2017年に報告されたEFAIL（メールクライアントのHTMLレンダリングを悪用した暗号文の内容漏洩手法）のように、暗号アルゴリズム自体ではなくクライアント実装側の不備が問題になった事例もあり、クライアントのアップデートが重要。
- 量子コンピュータへの中長期的な備えが発展途上：現行のRSA/ECC鍵は量子計算機による解読リスクが理論上指摘されており、OpenPGP陣営でも耐量子アルゴリズムの標準化・実装が今後の課題となっている。
混同されやすい用語・類似技術との違い
PGP・OpenPGP・GPG（GnuPG）の関係
この3つは階層関係にあり、しばしば同義に使われますが厳密には異なります。PGPはPhil Zimmermann氏が開発した最初のソフトウェア製品名（後にSymantecが商用版を保有）。OpenPGPはそのデータ形式を標準化したIETFの仕様（RFC 4880 / RFC 9580）。GPG（GnuPG）はOpenPGP仕様を実装したオープンソースソフトウェアです。つまり「PGPという製品の仕組みを、OpenPGPという仕様として公開し、GPGというOSSで実装した」という関係です。
S/MIMEとの違い
| 項目 | GPG/PGP | S/MIME |
|---|---|---|
| 信頼モデル | Web of Trust（分散型・個人間署名） | 階層型PKI（認証局が発行する証明書） |
| 主な利用者層 | 開発者・OSSコミュニティ・技術者 | 企業（Outlookなど組織的なメール基盤） |
| 鍵の入手方法 | 自己生成し鍵サーバー等で公開 | 認証局に申請し証明書を発行してもらう |
| クライアント対応 | Thunderbird（標準搭載）、拡張機能経由 | Outlook、Apple Mailで標準サポート |
age・minisign・SSH鍵署名との違い
ageはGoogleの研究者が中心となって開発したシンプルな暗号化専用ツールで、鍵管理の複雑さを避けるため署名機能や信頼の輪を持たず「暗号化・復号」の一点に機能を絞っています。minisign・signifyも同様に署名検証だけに特化した軽量ツールです。GPGはこれらと異なり「暗号化＋署名＋鍵管理＋信頼モデル」を一体で提供する総合的なツールスイートである点が最大の違いです。また、Gitのコミット署名では近年SSH鍵による署名（git config gpg.format ssh）も選べるようになり、すでにSSH鍵を運用している開発者はGPG鍵を別途用意せずに済む選択肢が増えています。
暗号化と電子署名の違い（GPG内での使い分け）
GPG初心者が混同しやすい点として、「暗号化」と「署名」は逆方向の鍵を使う点があります。暗号化は「相手の公開鍵」で暗号化し「相手の秘密鍵」で復号する（第三者に読まれないようにする）。署名は「自分の秘密鍵」で署名し「自分の公開鍵」で検証する（改ざんされていないことを証明する）。この2つは独立した操作で、gpg --sign --encryptのように組み合わせることも可能です。
実務ポイント：トラブル事例と対策
⚠️ 「gpg: decryption failed: No secret key」エラー
原因：復号化に必要な秘密鍵がキーリングにない
対策：gpg --list-secret-keysで鍵を確認。必要に応じて鍵をインポートする。
⚠️ 信頼の輪（Web of Trust）の問題
症状：「This key is not trusted」警告が表示される
対策：gpg --edit-key <KEY_ID>で信頼レベルを設定。trustコマンドを使用。
⚠️ 鍵の有効期限切れ
症状：署名検証や暗号化ができなくなる
対策：gpg --edit-keyでexpireコマンドを使い有効期限を延長。更新した公開鍵を配布。
⚠️ 「gpg: WARNING: unsafe permissions on homedir」警告
原因：~/.gnupgディレクトリのパーミッションが緩い（グループ・他ユーザーに読み取り権限がある等）
対策：chmod 700 ~/.gnupgおよびchmod 600 ~/.gnupg/*で権限を締める。CI環境ではコンテナ内で毎回鍵をインポートする運用にし、永続化ボリュームの権限にも注意する。
⚠️ GitHubで署名付きコミットが「Unverified」になる
原因：GitHub上に登録した公開鍵と、実際に署名に使ったサブキーが一致していない、またはコミットのメールアドレスが鍵のUIDと不一致
対策：gpg --armor --export <KEY_ID>でエクスポートした公開鍵をGitHubのSettings > SSH and GPG keysに登録し、git config user.emailを鍵のUIDメールアドレスと揃える。
最新動向（2026年）
鍵長・アルゴリズムの推奨（2026年時点）
NISTのSP 800-57等のガイダンスを踏まえると、新規に鍵を作成する場合の実務的な目安は以下の通りです。
| アルゴリズム | 推奨状況 |
|---|---|
| RSA-2048 | 最低ライン。新規発行は非推奨、既存運用の延命に留める |
| RSA-3072 / RSA-4096 | RSAを使う場合の実務上の推奨値。4096は署名・復号がやや遅い |
| Ed25519 / Curve25519 | GnuPG 2.4系のデフォルト。同等以上の安全性で高速・鍵サイズも小さい |
| SHA-1（ハッシュ） | 署名アルゴリズムとしては非推奨。SHA-256以上を使用する |
鍵種別を問わず共通する実務上の注意点として、有効期限（Expire date）を無期限にせず1〜2年程度で設定し、定期的に鍵を更新する運用がベストプラクティスとされています。無期限鍵は紛失・漏洩時に失効の徹底が難しくなるためです。
GnuPG 2.4系とOpenPGP仕様の刷新
GnuPG 2.4では、パフォーマンスの向上と新しい暗号アルゴリズムのサポートが追加されています。特にEd25519とCurve25519がデフォルトで推奨されるようになりました。また前述の通り、OpenPGPの仕様自体もRFC 4880からRFC 9580（Crypto Refresh）へと刷新が進み、AEAD暗号モードのネイティブサポートなど、より現代的な暗号設計への移行が続いています。
耐量子暗号（Post-Quantum Cryptography）への布石
NISTは2024年にML-KEM（旧CRYSTALS-Kyber、鍵交換用）やML-DSA（旧CRYSTALS-Dilithium、署名用）を耐量子暗号の標準として確定しています。OpenPGPコミュニティでも、将来的にこれらのアルゴリズムをハイブリッド方式（既存のECC/RSAと耐量子アルゴリズムを併用する方式）で鍵交換に組み込む検討が進められており、TLSやSSHの分野で先行している耐量子対応の流れがGPG/PGPの世界にも波及しつつあります。現時点で今すぐ対応が必須というわけではありませんが、長期保存が前提の機密文書を扱う場合は動向を注視する価値があります。
代替ツールの台頭
- age：シンプルで現代的な暗号化ツール。GPGよりも使いやすい
- minisign：署名に特化した軽量ツール
- signify：OpenBSD発のシンプルな署名ツール
Keybaseの終焉とその後
GPGの公開鍵の共有・検証に使われていたKeybaseは、Zoom買収後にサービスの方向性が変わりました。代替としてkeys.openpgp.orgやSequoia-PGPプロジェクトが注目されています。
よくある質問（FAQ）
Q. GPGとPGPは同じものですか？
A. 完全に同じではありません。PGPはPhil Zimmermann氏が開発した最初の製品名（現在はSymantec/Broadcomが商用版を保有）、OpenPGPはその仕組みを標準化したIETFの公開仕様（RFC 4880 / RFC 9580）、GPG（GnuPG）はOpenPGP仕様に基づくオープンソース実装です。実務で「PGP」と言う場合、多くはGPGを指しているケースがほとんどです。
Q. GPGキーを作るとき、どのアルゴリズムと鍵長を選べばよいですか？
A. 特別な制約がなければEd25519（署名用）とCurve25519（暗号化用）の組み合わせが2026年時点での実務上の第一候補です。相手先システムがEdDSAに未対応など互換性の懸念がある場合はRSA-4096を選びます。RSA-2048は既存鍵の延命以外での新規採用は避けるのが無難です。
Q. 秘密鍵やパスフレーズを忘れたら暗号化データはどうなりますか？
A. 原理的に復号する手段はありません。GPG/PGPは第三者による復元を想定しない設計であるため、バックドアやマスターパスワードは存在しません。鍵生成時に失効証明書（revocation certificate）を作成し、秘密鍵とは別の安全な場所に保管しておくこと、また秘密鍵自体を暗号化した外部メディアに複数バックアップしておくことが実務上の対策になります。
Q. Gitコミットに署名するにはどうすればよいですか？
A. git config --global user.signingkey <GPGキーID>でGPGキーを設定し、git commit -Sまたはgit config --global commit.gpgsign trueで自動署名を有効化します。GitHubは署名済みかつ登録済みの公開鍵と一致するコミットに「Verified」バッジを表示します。GPG鍵の代わりにSSH鍵で署名する方法（git config gpg.format ssh）も選択できます。
Q. GPGでメールを暗号化すれば、件名や送信者情報も隠せますか？
A. いいえ。GPG/PGPが暗号化するのはメール本文（および添付ファイル）のみで、件名・送信者・受信者・送信日時などのヘッダー情報（メタデータ）はメールプロトコルの都合上、平文のまま経路上に残ります。メタデータ自体を隠したい場合は、Torのような匿名化ネットワークや、メタデータ保護を設計に組み込んだ別の仕組みと組み合わせる必要があります。