本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第4弾として、暗号化について解説する記事です。
現代システムは保存時／通信時／処理時の3層で守るのが基本です。本記事では対称鍵・公開鍵暗号、TLS、ハッシュ、KMS、Envelope Encryptionなどの暗号技術を解説し、暗号化の強度は鍵管理の強度と同じという実務の鉄則を示します。
本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』も参考にしてみてください。
この記事の結論
- 転送時・保存時・アプリケーションの3層で暗号化する
- 鍵管理はKMSに任せる（自前管理しない・90日ローテーション）
- パスワードはArgon2id / bcrypt+ソルト（SHA-256単独は厳禁）
- 暗号アルゴリズムの自作は絶対にしない。AI生成の暗号コードも専門家レビュー必須
この記事を読む前に
本記事は認証・認可・暗号化といったセキュリティ用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「セキュリティと認証の基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそも暗号化とは何か
暗号化とは、ざっくり言えば「データを読めない形に変換し、正しい鍵を持つ人だけが元に戻せるようにする技術」です。
手紙の封蝋を想像してください。封蝋（暗号化）を施せば、途中で誰かが覗いても中身は読めません。ただし封蝋を作る印章（鍵）を盗まれたら、誰でも開封・偽造できてしまいます。デジタルの暗号化も同じで、アルゴリズム自体は公開されていても、鍵が安全に管理されている限りデータは守られます。逆に言えば、暗号化の強度は鍵管理の強度と同じです。
なぜ暗号化が重要なのか
DBをバックアップごと盗まれても、暗号化されていれば読めません。情報漏洩ニュースのほとんどは平文保存が原因です。GDPR・個人情報保護法・PCI DSSはいずれも個人情報・クレカ情報の暗号化を要求し、違反時は数億〜数十億の制裁金が課されます。現代ブラウザはHTTPを警告表示するため、通信の平文送信は事実上禁止です。
そして重要なのは、暗号化は「入れたから安全」ではなく鍵の管理が全てだということです。暗号化したつもりで鍵を平文で置いている事故が後を絶ちません。
暗号化の3つの場所
| 種類 | 対象 | 代表技術 |
|---|---|---|
| 保存時（At Rest） | DB・ファイル・バックアップ | TDE・AES-256 |
| 通信時（In Transit） | ネットワーク通信 | TLS 1.3・mTLS |
| 処理時（In Use） | メモリ上・計算中 | TEE・準同型暗号 |
処理時暗号化は発展途上ですが、保存時と通信時は標準技術として確立しており、現代システムでは必須要件です。
基本の道具立て
対称鍵と公開鍵 ― TLSは両方のハイブリッド
対称鍵暗号（AES-256）は1つの鍵で暗号化・復号する高速な方式で、大量データの暗号化に使います。公開鍵暗号（RSA・ECDSA）は公開鍵と秘密鍵のペアを使い、鍵配布が容易ですが1000倍遅い。現代のTLSは、公開鍵暗号で対称鍵を安全に交換し、本体データは高速な対称鍵で暗号化するハイブリッド方式が標準です。
TLSのバージョンはTLS 1.3が推奨（1.2が最低限）で、TLS 1.0 / 1.1は主要ブラウザで廃止済みです。証明書はLet’s Encryptで無料取得でき、CloudFront・ALB等なら自動更新されます。
ハッシュ ― パスワードには「意図的に遅い」ものを
ハッシュは元に戻せない一方向変換で、暗号化とは根本的に違います。改ざん検知にはSHA-256を使いますが、パスワード保存にSHA-256単独は厳禁です。高速すぎてGPUで総当たりされます。Argon2idやbcryptのように「意図的に遅い」ハッシュを使い、ユーザーごとに違う「ソルト」を必ず付けます。
KMSとEnvelope Encryption ― 鍵はアプリで持たない
鍵をアプリ側で平文で持つのは厳禁で、KMS（AWS KMS・Cloud KMS・HashiCorp Vault等）で管理し、定期ローテーションを自動化します。大量データにはEnvelope Encryptionが標準パターンです。
データ --- [DEK: データ暗号鍵] ---> 暗号化データ
│
└── [KEK: KMS鍵] ───> 暗号化されたDEKデータは高速な対称鍵（DEK）で暗号化し、その鍵自体をKMSの鍵（KEK）で暗号化する入れ子構造で、安全性と性能を両立します。S3やBigQueryの裏側もこの方式です。
TDEとクライアントサイド暗号化
TDE（透過的データ暗号化）はDB自体が自動でデータを暗号化する機能で、マネージドDBなら有効化するだけで保存時暗号化が完了します。ただしTDEはあくまで保存時のみで、通信やメモリは別途対策が必要です。さらに強い保護が要る場合（パスワードマネージャー・機密メモ等）は、アプリ側で暗号化してから送るクライアントサイド暗号化（ゼロ知識設計）で、サーバー側ですら平文を見られない状態を作れます。代償は検索・集計の不可と、鍵紛失時の復旧不能です。
どう選べばいいのか ― 機微度とアルゴリズムの数値Gate
暗号化の強度はデータの機微度で決めます。公開情報はTLSのみ、一般業務データはTLS+TDE、個人情報は+列単位暗号化、クレカ情報はPCI DSS準拠のトークン化（Stripe等の決済代行トークンで扱い、自社DBにカード番号を持たない）、金融・医療の極秘データはHSM+クライアント暗号化まで引き上げます。フルクラウドならマネージドKMS+TDEで暗号化は標準有効にでき、規制対応の8割はカバーできます。
※ 2026年4月時点の標準値です。
| 用途 | 推奨 | NG / レガシー |
|---|---|---|
| 対称鍵暗号 | AES-256-GCM | AES-128-ECB・DES・3DES |
| 公開鍵暗号 | RSA 4096 / ECDSA P-256以上 | RSA 1024 |
| パスワードハッシュ | Argon2id / bcrypt cost 12以上 | MD5・SHA-1・SHA-256単独 |
| TLS | 1.3（または1.2） | SSL / TLS 1.0 / 1.1 |
| 乱数生成 | CSPRNG（crypto.randomBytes） | Math.random() |
| 鍵ローテーション | 90日 / 漏洩時は即時 | 永続使用 |
PBKDF2を使う場合は反復回数が古い設定のままだと突破されるため、最低600,000回以上（OWASP推奨）が必須です。標準アルゴリズムから一歩も外れないのが鉄則で、自作暗号は絶対禁忌です。
3つのシナリオで考える
個人開発・スタートアップの場合
プラットフォームの標準暗号化に全乗りしてしまいましょう。VercelやSupabaseであればTLSもat-rest暗号化も標準で有効ですし、パスワードも認証SaaSに委譲すればハッシュ化まで彼らの仕事になります。自分でやるべきことは「暗号化を無効にしない」ことだけ、と言ってもいいくらいです。
中小SaaSの場合
マネージドKMSとTDE、個人情報の列単位暗号化で規制対応の8割はカバーできます。クレカ情報についてはStripeなどのトークン化を使って、自社DBに持たないのが鉄則です。鍵のローテーション90日も、KMSの自動化で人手を介さない仕組みにしておいてください。
大企業・規制業種の場合
金融・医療の極秘データであれば、FIPS 140-2認定のHSMとクライアントサイド暗号化まで引き上げる必要があります。鍵管理者とデータ利用者の職務分掌や、レガシーなDESやSHA-1が残っていないかという暗号化アルゴリズムの棚卸しも、監査サイクルに組み込んでおくべきでしょう。
AI判断軸 ― AIに書かせるのはラッパーコードだけ
AIに暗号化コードを書かせてはいけない理由
AIは暗号化の「使い方」を書けますが、「正しい使い方」かどうかの判断は信用できません。AES暗号化のコードを生成させると、ECBモード（同じ平文ブロックが同じ暗号文になる危険なモード）を使ったり、初期化ベクトル（IV）を固定値にしたりするコードが出てくることがあります。原則は「AIに書かせるのはKMS / SDKの呼び出しコードだけ」です。KMSの encrypt / decrypt 呼び出し、TLS設定、bcryptのハッシュ化呼び出しのようなラッパーコードは任せて問題ありませんが、暗号アルゴリズムの実装や鍵生成ロジックは避けるべきです。
KMSのローテーション設定をIaCで宣言する
AWS KMSの鍵ローテーション設定はTerraformで1行ですが、この1行がないと鍵が永久に固定されます。AIにTerraformを書かせるとKMSリソースは作成するがローテーション設定を省略するケースがあるため、CIのtfsecルールで「ローテーション設定がないKMS鍵」を検知する仕組みが有効です。
やってはいけないこと
「暗号化したつもりで漏洩している」構造の典型を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 鍵をソースコード / .envにハードコード | Git履歴に永久に残り数秒でBotに拾われる → KMS / Secrets Managerに入れる |
| 独自暗号アルゴリズムを実装 | 専門家ですら避ける領域 → AES / TLS標準ライブラリに寄せる |
| MD5 / SHA-1 / ソルトなしでパスワードハッシュ | GPUで一瞬で突破される → Argon2id+ソルトにする |
| AES-ECBモードを使う | 2013年Adobe事件（1.5億件解読）と同じ地雷 → AES-GCMにする |
| 鍵ローテーションを実施しない | 「いつか漏れる」前提の保険がない → 90日自動ローテーションにする |
| AI生成の暗号コードをそのまま採用 | 古いアルゴリズムや固定IVが混入する → 専門家レビューを必須にする |
筆者メモ ― 「暗号化済み」が実は守れていなかった事例
2013年10月のAdobe情報流出事件では、約1億5千万件のパスワードが「暗号化された状態」で流出しましたが、同じ鍵・ECBモード・共通のパスワードヒント欄という実装上の欠陥が重なり、暗号文のパターン解析で実用的に解読されました。2022年のLastPass流出では、暗号化されたパスワード金庫自体が窃取された上、一部ユーザーのPBKDF2反復回数が古い設定のままで総当たり耐性が低いことが判明しました。
どちらも「暗号化した」と「守れている」が別物であることを突きつけた事件です。暗号化は入れるだけでは不十分で、鍵の寿命・経路・置き場所まで説明できるかが問われます。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 通信暗号化（TLS 1.2 / 1.3・mTLS要否）
- 保存暗号化（TDE・KMS・列単位）
- 鍵管理（KMS / Vault / HSM）とローテーション頻度
- パスワードハッシュ（Argon2id / bcrypt+ソルト）
- クライアントサイド暗号化の必要性
- 署名（コード・コンテナ・契約書）
言語化した答えはADRとして残します。書き方の具体例は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事は暗号化について、対称鍵・公開鍵・TLS・ハッシュ・KMS・Envelope Encryption・実務の鉄則まで含めて解説しました。如何だったでしょうか。
3層で暗号化し、鍵はKMSに任せ、パスワードはArgon2/bcrypt+ソルト、暗号コードは専門家レビューを通す。これが2026年の暗号化設計の現実解です。
次回はネットワークセキュリティ（FW・WAF・IDS/IPS・DDoS対策）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS Key Management Service も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（55/95）