暗号化 ― 鍵管理が暗号の強度を決める ― 生成AI時代のアーキテクチャ超入門

flowchart LR
    USER([ユーザー])
    subgraph IN_TRANSIT["In Transit (通信時)<br/>TLS 1.3 / mTLS"]
        NET[暗号化された通信路]
    end
    subgraph IN_USE["In Use (処理時)<br/>TEE / 準同型暗号"]
        MEM[メモリ上で計算]
    end
    subgraph AT_REST["At Rest (保存時)<br/>TDE / AES-256"]
        DB[(暗号化DB)]
        FILE[(暗号化ファイル)]
    end
    USER -->|TLS| NET
    NET --> MEM
    MEM --> DB
    MEM --> FILE
    classDef user fill:#fef3c7,stroke:#d97706;
    classDef transit fill:#dbeafe,stroke:#2563eb;
    classDef use fill:#fae8ff,stroke:#a21caf;
    classDef rest fill:#dcfce7,stroke:#16a34a;
    class USER user;
    class IN_TRANSIT,NET transit;
    class IN_USE,MEM use;
    class AT_REST,DB,FILE rest;

種類	対象	代表技術
保存時（At Rest）	DB・ファイル・バックアップ	TDE（Transparent Data Encryption、DB透過暗号化）・AES-256
通信時（In Transit）	ネットワーク通信	TLS 1.3・mTLS
処理時（In Use）	メモリ上・計算中	TEE（Trusted Execution Environment、CPU内の隔離実行領域）・準同型暗号

処理時暗号化は発展途上で実装が難しいですが、保存時と通信時は既に標準技術として確立しており、現代システムでは必須要件です。

対称鍵暗号と公開鍵暗号

暗号化の2つの根本原理で、使い分けが重要です。どちらか一方では足りず、現代システムは両方を組み合わせて使います。

	対称鍵暗号	公開鍵暗号
鍵	1つ（共有）	2つ（公開/秘密）
速度	速い	遅い（1000倍）
鍵配布	難しい	容易
代表	AES-256	RSA・ECDSA
用途	大量データ暗号化	鍵交換・署名

現代のTLSは両方を併用し、公開鍵暗号で対称鍵を安全に交換し、本体データは高速な対称鍵で暗号化するハイブリッド方式が標準です。

TLS / HTTPS

通信の暗号化のデファクトスタンダードで、HTTPにTLSを乗せたのがHTTPSです。現代ウェブは TLS 1.3 が最新で、TLS 1.0/1.1 は既に廃止、1.2 は最低限、1.3 が推奨です。

バージョン	状態
SSL 3.0以下	禁止（脆弱）
TLS 1.0 / 1.1	廃止（主要ブラウザで対応終了）
TLS 1.2	最低限・後方互換
TLS 1.3	推奨・高速・安全

TLS証明書は Let’s Encrypt で無料で取得でき、CloudFront・ALB（Application Load Balancer、AWSのL7ロードバランサ）等のマネージドサービスなら自動更新が可能です。有料の EV 証明書はUX向上効果が薄れ、現代ではほぼ不要とされています。

ハッシュ化（一方向関数）

元データから一方向に変換し、元に戻せない関数がハッシュです。パスワード保存・データ改ざん検知・電子署名等に使われます。暗号化と混同されがちですが、復号できないのが根本的な違いです。

用途	アルゴリズム
パスワード保存	bcrypt・Argon2・scrypt
改ざん検知	SHA-256・SHA-3
電子署名内部	SHA-256・SHA-384
レガシー（非推奨）	MD5・SHA-1

パスワードに一般ハッシュ（SHA-256）を使うのは厳禁です。高速すぎて総当たりされます。Argon2 や bcrypt のように「意図的に遅い」ハッシュを使い、「ソルト」（ユーザーごとに違う文字列）を必ず付けます。

鍵管理（KMS）

暗号化の要である鍵を安全に管理する仕組みが KMS（Key Management Service）です。鍵をアプリ側で平文で持つのは厳禁で、専用のハードウェア（HSM）や KMS で管理します。クラウドなら標準サービスとして提供されています。

サービス	特徴
AWS KMS	AWS統合・安価
Google Cloud KMS	GCP統合
Azure Key Vault	Azure統合・Secret管理も
HashiCorp Vault	OSS・マルチクラウド
ハードウェアHSM	FIPS 140-2 Level 3対応

鍵は定期ローテーション（自動更新）するのが基本で、KMS は透過的にこれを実現します。

Envelope Encryption

Envelope Encryption は、大量データを効率的に暗号化する標準パターンです。データは高速な対称鍵で暗号化し、その鍵自体を KMS の鍵で暗号化する入れ子構造で、安全性と性能を両立します。

データ --- [DEK: データ暗号鍵] ---> 暗号化データ
            │
            └── [KEK: KMS鍵] ───> 暗号化されたDEK

KMS を直接使ってデータを暗号化するとネットワーク往復で遅くなりますが、Envelope 方式なら KMS 呼び出しは最初だけで、以降はローカルで暗号化できます。AWS S3・BigQuery の裏側もこの方式です。

鍵管理はKMSに任せる。アプリ側で鍵を持たないのが鉄則です。

TDE（透過的データ暗号化）

TDE は、DB自体が自動的にデータを暗号化する機能で、アプリ側のコード変更不要で保存時暗号化を実現できます。クラウドDB・エンタープライズDBの標準機能で、有効化するだけで保存時暗号化が完了します。

DB	TDE対応
PostgreSQL（マネージド）	RDS・Cloud SQL で自動
SQL Server	TDE標準機能
MySQL	8.0以降対応
Oracle	TDE標準機能
BigQuery・Snowflake	標準で常時暗号化

「暗号化＝ TDE」と誤解する人は多いですが、TDEはあくまで保存時暗号化で、アプリ→DB間の通信やアプリ内メモリは別途対策が必要です。

クライアントサイド暗号化

アプリ側で暗号化してからサーバーに送る方式で、サーバー側ですら平文を見られない状態を作れます。LastPass・1Password・Signal・Proton Mail 等の「ゼロ知識設計」がこれです。

メリット	デメリット
サーバー漏洩でも安全	サーバー側で検索・集計不可
真のエンドツーエンド	鍵紛失で復旧不可能
規制対応が容易	実装難易度高い

クレカ番号・パスワード・機密メモなどは、サーバーで復号の必要がない限り、クライアントサイド暗号化を検討する価値があります。

電子署名と改ざん検知

データの真正性（本物か）と完全性（改ざんされていないか）を保証するのが電子署名です。公開鍵暗号の応用で、送信者が秘密鍵で署名し、受信者が公開鍵で検証します。

用途	例
契約書	DocuSign・クラウドサイン
コード配布	コード署名・ソフトウェア配布
コンテナイメージ	Cosign・Notary
SBOM（Software Bill of Materials、ソフトウェア部品表）	ソフトウェア構成証明

特にサプライチェーン攻撃対策として、コンテナイメージの署名（Cosign）が近年急速に普及しています。

判断基準

① 扱うデータの機微度

暗号化の強度はデータの機微度で決まります。公開情報に強い暗号化は過剰で、逆に個人情報に弱い暗号化は犯罪的です。

データ種別	推奨暗号化
公開情報	TLS のみ
一般業務データ	TLS + TDE
個人情報	TLS + TDE + 列単位暗号化
クレカ情報	PCI DSS準拠・トークン化
極秘・医療・金融	上記 + HSM・クライアント暗号化

② クラウド採用度

クラウド各社のマネージド KMS・TDE を使えば、暗号化は標準で有効になります。オンプレミスだと鍵管理を自前で設計する必要があり、難易度が跳ね上がります。

環境	推奨
フルクラウド	マネージドKMS標準利用
ハイブリッド	Vault + クラウドKMS
オンプレ中心	自社HSM・鍵管理専門家必要
超機密	FIPS 140-2 Level 3 HSM

ケース別の選び方

一般的なWebサービス・SaaS

TLS 1.3 + マネージドKMS + TDE有効化。CloudFront/ALBでTLS終端、RDS/BigQueryはTDE標準、パスワードはArgon2を使います。これだけで規制対応も含めて8割カバーできます。

クレジットカード情報を扱うEC

PCI DSS準拠 + トークン化。カード番号そのものを自社DBに保存せず、Stripe・Adyen などの「決済代行のトークン」（例：tok_xxx）で扱います。自社DBから漏洩してもカード情報が出ない設計にします。

パスワードマネージャー・秘密メモ系サービス

クライアントサイド暗号化（ゼロ知識）。サーバーは暗号文のみを保管し、復号はユーザー端末で完結させます。サーバー侵害でも平文は守られる代わりに、復旧手順の設計が最難関になります。

金融・医療・政府系の高機密データ

FIPS 140-2 Level 3 HSM + 列単位暗号化 + 鍵の監査ログ。鍵へのアクセス1つ1つを監査ログに残し、職務分掌で鍵管理者を分離します。

暗号化の数値Gate・アルゴリズム選定表

暗号化は「使えばOK」ではなく、アルゴリズムとパラメータを正しく選ぶ必要があります。以下が2026年4月時点の標準値です。

用途	推奨アルゴリズム	NG / レガシー
対称鍵暗号	AES-256-GCM（認証付き暗号）	AES-128-ECB・DES・3DES
公開鍵暗号	RSA 4096bit / ECDSA P-256以上	RSA 1024・DSA
ハッシュ（パスワード）	Argon2id（メモリ64MB・時間2）/ bcrypt cost 12以上 / scrypt	MD5・SHA-1・SHA-256単独
ハッシュ（改ざん検知）	SHA-256 / SHA-384 / SHA-3	MD5・SHA-1
TLSバージョン	TLS 1.3（または 1.2）	SSL / TLS 1.0 / 1.1（全廃止）
乱数生成	CSPRNG（`crypto.randomBytes` 等）	`Math.random()`
鍵ローテーション頻度	90日 / 漏洩時は即時	永続使用
TLS証明書有効期限	90日（Let’s Encrypt 自動更新）	1年以上の手動管理
耐量子暗号（将来検討）	ML-KEM / ML-DSA（NIST 2024年発表）	—

「Argon2id（2015年 Password Hashing Competition 優勝）」が2026年時点のパスワードハッシュの鉄板。bcrypt も継続使用可能ですが、新規は Argon2id が第一候補。「PBKDF2 は反復回数（iteration）が古い設定」のまま使うと突破されるため、最低 600,000回以上（OWASP 2023推奨）必須です。

標準アルゴリズムから一歩も外れないのが鉄則。自作暗号は絶対禁忌です。

暗号化運用の鬼門・禁じ手

暗号化で事故る典型パターンを整理します。どれも暗号化したつもりで漏洩している構造を持ちます。

禁じ手	なぜダメか
鍵をソースコードにハードコード	Git履歴に永久に残る、公開リポジトリなら数秒でBotに拾われる
鍵を .env に平文で置きGitコミット	同じく即漏洩。KMS / Secrets Managerに入れる
独自暗号アルゴリズムを実装	セキュリティ専門家ですら避ける。AES / TLS標準ライブラリに寄せる
MD5 / SHA-1でパスワードハッシュ	GPUで一瞬で総当たり突破。Argon2id必須
ソルトなしでハッシュ化	レインボーテーブル攻撃で破られる。ユーザーごとに固有のソルト
TLS 1.0 / 1.1を有効のまま運用	顧客監査・金融認定でNG。TLS 1.2以上、理想は 1.3
鍵ローテーションを実施しない	「いつか漏れる」前提の保険なし。90日ごとに自動ローテーション
AES-ECBモードを使う	2013年 Adobe 事件（1.5億件のパスワードが ECB + 同じ鍵 + 共通ヒント欄で実質解読）と同じ地雷
PBKDF2の反復回数が古い	LastPass 2022年流出で古い反復回数のユーザーがより脆弱に。OWASP 2023の600,000回以上を採用
証明書の有効期限切れでサービス停止	Let’s Encrypt + 自動更新で回避。手動管理は事故の温床
AI生成の暗号コードをそのまま採用	AIは古いアルゴリズム（MD5 / DES）を提案することがある。必ず専門家レビュー

2013年 Adobe 事件（約1.5億件のパスワードが「暗号化された状態」で流出したが、ECBモード + 共通ヒント欄で実用的に解読）、2022年 LastPass 流出（暗号化ボルトのコピーが奪取、古い PBKDF2反復回数のユーザーが高リスクに）は、「暗号化した」と「守れている」は別物という教訓を突きつけました。

暗号化は「入れる」と「守れる」の間に深い溝がある。鍵管理が全てを決めます。

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用が前提になると、暗号化はAIが間違えやすい領域として注意が必要です。AIコード生成は時に古い暗号アルゴリズムを提案（MD5・DES等）したり、鍵をソースコードにハードコードしたりすることがあります。

KMS・TLS・Cosign・Argon2 といった標準機能に寄せるのは、単に便利だからではありません。これらは採用実績が膨大でAIの学習データが豊富なため、生成コードがハルシネーションを起こしにくく、使い方の定石が確立しています。また世界中のセキュリティ研究者が継続的に脆弱性を監査しており、問題が見つかれば即座にパッチが配布されます。

AI時代に有利	AI時代に不利
マネージドKMS（自動選定）	自作鍵管理コード
TLS 1.3標準設定	手動の暗号化実装
コード署名（Cosign）	未署名のコンテナ
自動ローテーション	固定鍵の永続利用

AI生成コードは必ず人間がレビューし、暗号まわりは特に警戒すべきです。AIが生成した暗号化コードをそのまま本番投入は事故の温床です。

暗号コードはAI生成をそのまま信じない。必ず専門家がレビューします。

筆者メモ — 「暗号化済み」が実は守れていなかった事例

「暗号化してるから大丈夫」が崩れた事例が、近年の大型漏洩の多くを占めている、という話は業界の定番です。

2013年10月のAdobe情報流出事件では、約1億5千万件のパスワードが「暗号化された状態」で流出しましたが、同じ鍵・ECBモード・共通のパスワードヒント欄という実装上の欠陥が重なり、暗号文のパターン解析で実用的に解読されました。「暗号化した」と「守れている」が別物であることを世界に突きつけた事件として語り草になっています。

もう一つ、2022年のLastPass情報流出事件も重い教訓を残しました。暗号化されたパスワード金庫（Vault）自体が窃取された上、一部ユーザーのイテレーション回数（PBKDF2 の繰り返し回数）が古い設定のままで、総当たり攻撃への耐性が低かったことが後から判明しました。「暗号化している」だけでなく「どれだけ遅いハッシュを使ったか」まで設計に入れなければならない、という教訓が広く共有されるきっかけになりました。

筆者も過去に、検証用のAES鍵を .env.example に残したままGitに push し、半年後にシークレットスキャンで検知されて慌てた経験があります。本番鍵でなかったので被害はゼロでしたが、鍵の寿命・経路・置き場所まで説明できるかが重要だと痛感した出来事でした。どちらも派手な攻撃ではなく「実装の詰めの甘さ」が致命傷で、暗号化は「入れるだけでは不十分」という教訓を突きつけます。

鍵管理の地味なミスは常に起こる。「入れたか」ではなく鍵の寿命と経路を問います。

よくある勘違い

暗号化してるから安心 → 鍵管理が杜撰なら無意味。鍵がソースコードにベタ書きは頻発する事故
MD5 / SHA-1 でパスワードハッシュ化 → 現代のGPU処理能力では一瞬で突破されます。bcrypt・Argon2が必須。ソルトも忘れない。2013年10月のAdobe事件では、約1億5千万件のパスワードが「暗号化された状態」で漏洩しましたが、ECBモードと共通のヒント欄のせいで実用的に解読されました
通信はLAN内だから暗号化不要 → 内部ネットワークも Zero Trust で暗号化する時代。mTLSが標準
量子コンピュータ時代にRSAは破られる → 事実ですが、実用的な量子計算機でRSAを破るのは未だ先の話です。ただし「今の通信は将来復号される」リスク（Harvest Now, Decrypt Later）は存在し、NIST が2024年に発表した耐量子暗号（ML-KEM / ML-DSA）への移行検討が始まっています

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

通信暗号化（TLS 1.2/1.3・mTLS要否）
保存暗号化（TDE・KMS・列単位）
鍵管理（KMS・Vault・HSM）
パスワードハッシュ（Argon2 / bcrypt + ソルト）
鍵ローテーション（頻度・自動化）
クライアントサイド暗号化（必要性）
署名（コード・コンテナ・契約書）

最終的な判断の仕方

暗号化の核心は暗号化の強度は鍵管理の強度と同じということです。AES-256を使っても鍵がソースコードにハードコードされていれば無意味で、情報漏洩事故の多くは暗号化の不備ではなく鍵管理の杜撰さが原因です。保存時・通信時・処理時の3層で守り、鍵は必ずマネージドKMSに任せるのが合理的な判断になります。TLS 1.3・TDE・Argon2 + ソルトという現代標準を外すだけで事故の温床になるため、「とにかく標準を外さない」が最良の選択です。

もう一つの決定的な軸はAI生成の暗号コードをそのまま信じないことです。AIは時に古いアルゴリズム（MD5 / DES）を提案したり、鍵をハードコードしたりします。マネージドKMS・TLS 1.3・Cosign・Argon2といった標準機能に寄せ、AI生成コードを必ず人間がレビューする運用が、AI時代の防衛線になります。

選定の優先順位

3層で暗号化 — 保存時（TDE）・通信時（TLS 1.3）・処理時、全てをマネージドで扱う
鍵はKMSに任せる — アプリ側で鍵を持たず、自動ローテーションを有効化
パスワードはArgon2 / bcrypt + ソルト — SHA-256単独は厳禁、意図的に遅いハッシュを採用
暗号コードは専門家レビュー — AI生成をそのまま信じず、標準ライブラリから外れない

「鍵はKMS、暗号は標準、レビューは専門家」が基本。自作暗号を避け、標準機能に徹底的に寄せます。

まとめ

本記事は暗号化について、対称鍵・公開鍵・TLS・ハッシュ・KMS・Envelope Encryption・TDE・実務の鉄則まで含めて解説しました。如何だったでしょうか。

3層で暗号化し、鍵はKMSに任せ、パスワードはArgon2/bcrypt+ソルト、暗号コードは専門家レビューを通す。これが2026年の暗号化設計の現実解です。

次回はネットワークセキュリティ（FW・WAF・IDS/IPS・DDoS対策）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。